Decoupling KuMir IDE from language itself

[Sturwandan]

As it seems for me, KuMir language is basically Pascal with improved syntax (such as C-style var declaration) and Russian keywords. However it's missing some important features of Pascal, namely records (or structures) and pointers.
But, if those features would have been added, it would let KuMir become a general purpose programming language, which could be used to write useful programs.
However, if such thing happened it would be nice to have a version of KuMir without graphical user interface, which doesn't depend on Qt or other huge libraries, and can be coupled with regular text editors installed on machine instead of an IDE, perhaps losing some features, such as variable tracing, but being much faster and easier to install.
Of course, I am aware that many (or even most) KuMir programs depend on various Actors, such as Robot. However, this problem can be solved by having a well-defined interface between compiled kumir program and a library implementing an Actor, which in turn would allow to re-implement most Actors in ncurses, Xlib, Tk, Gtk+ or whatever.
A simplest and easiest to use, but not the most efficient solution would be using bidirectional text pipes between compiled executable and actor. Kumir would simply output commands for an actor and if commands had conditions in it, wait for response.
While it's going to be less efficient than a shared library, it would allow much wider range of Actors, including even real robots connected via RS-232 or TCP socket.
Though of course, a hybrid solution is also feasible: compiled program links with a library, which in turn converts library calls into text commands, but can be easily replaced with different library having same interface, but using graphical library directly.

I understand, that this discussion would be more appropriate to an internet forum, than a github issues, however, I am sadly is not aware of any forums where KuMir can be discussed.

[NexSqaud]

This language was created primarily for teaching in schools, not for real use in projects. But you can fork and do whatever you want. Also in the folder devel-doc/actors there are instructions for creating your own actors.

[Sturwandan]

@NexSqaud Why not to have both? If pupils know that language they are learning isn't usable for something practical, aren't they going to think that programming is boring? I think KuMir might become more attractive to learn if it had a stand-alone compiler

[a-a-maly]

@NexSqaud Why not to have both? If pupils know that language they are learning isn't usable for something practical, aren't they going to think that programming is boring? I think KuMir might become more attractive to learn if it had a stand-alone compiler

It has a standalone compiler (to bytecode), and a standalone executor of the "compiled" code, that even supports Robot actor. Those are currently being actively used in online courses on Mirera.ru platform and on silvertests.ru programming portal. It can be used in other online judges, even in programming contents. Though it has two serious limitations: low execution speed and having out-of-the-box support only for 32-bit integers, while 64-bit integers are widely required in contents programming challenges. These two limitations (along with bugs) are now the most importang target.

As it has been said above, everybody can write his own actors and embed them into the IDE or/and into the standalone runner via interfaces as dynamic libraries.
The problem is that "adding those features" (stuctures, pointers, classes, interfaces, inheritance, coroutines, threads, futures, promises, metaprogramming and so on) would make it hard to learn and hard to understand programs in such a language. And it is not an easy technical challenge by itself.
So, for now, the Kumir language stays as simple as it is. Some features might be added smoothly and steadily, but in no way to make Kumir a "general purpose programming language".

[Sturwandan]

@a-a-maly my point is mainly about making the language usable stand-alone, which would mean native-code compiler and some features which are strictly necessary. Out of listed ones it would be structures and pointers.
Look at C language. It has features of Kumir plus structures and pointers and it seems that all other things aren't necessary for its success.

[Sturwandan]

@a-a-maly my point is mainly about making the language usable stand-alone, which would mean native-code compiler and some features which are strictly necessary. Out of listed ones it would be structures and pointers.
Look at C language. It has features of Kumir plus structures and pointers and it seems that all other things weren't necessary for its success.