Echo programming language

[Dr.Sid]

Today I came over good name for the language I would use for the sim. And it's going to be: Echo.

So I write this post so google finds it and the name is allocated for me :biggrin:

Really, finding a good name is the hardest task on programming language design :rolleyes:

[OneShot]

I suppose it will be something simple ... like Java or Visual Basic instead of a C++ clone :)

I think it would be good if you could start early on supplying documentation so everybody interested can take a look and start learning and maybe even helping by creating doctrines and the likes.

[XabbaRus]

Sounds interesting. I haven't made any progress with the models....motivation is so hard.....I am alone at home so tell me what you want model wise and I'll provide it. I just need to map the 688VLS with moving tail planes and I have a good ADCAP...what else?

[Red Ocktober]

sorry to burst your bubble Doc, but look here...

http://docs.xmlecho.org/echo-spec.html

Echo
XML Data Processing Language
Bill Lindsey

unless you are the Bill Lindsey mentioned above, then me thinks someone beat you out by about 2 and a half years to the naming rights to 'echo' in the programminglanguage context...

--Mike

[Dr.Sid]

Oh no .. that's why I could not find it under 'Echo programming language' .. well .. for now let's take it as working title.

There is few things I've already decided:

The language will be more or less Basic. I mean no brackets for blocks and no semicolons. I hate redundant symbols.
I'm thinking about indent-only blocks, but otherwise quite Basic-like syntax.

On the other hand it will not be dynamically typed (unlike most of todays scripting languages), because of speed.

The basic types will be float, double, vector, possibly 4x4 matrix, enum, text. At the moment I think there will be no need for integers. There is need for both doubles and floats, since opengl mostly works in floats but some operations must be done in doubles. Maybe I will switch to doubles only in the engine, with floats in GFX only, but I haven't decided yet.

Texts will be fixed length (lets say 1024 bytes), for longer text there will be special type which will link simple texts together (as lines). Such type is already used and it is the command console log where the commands are shown.
This will allow simple text operations to be fast, with some loss on memory side, but sim like this does not use texts much, and there is plenty of memory these days.

The strong aspect will be native access to C-structures. This means that manipulation with ship properties will be fast and will not need any additional support from the simulator code (unlike in Lua for example).

For the beginning I'd like to interpret the syntax trees, which will cache pointers to variables. This means when two ships will use the same script, the code will have to be copied in memory for each platform, but this won't happen too much and this will allow faster execution (speed-memory trade-off, again).

Later it would be possible to actually compile the scripts on the fly. For high time compressions any gained speed is useful, and if there is some spare time, we can throw it to sensor simulation and GFX.

[XabbaRus]

Ok you lost me right after

"The language will be more or less Basic." :)

Could we get this in plain english as to how this will eventually affect the look and the operation of the sim.


My main interest is how the AI will think.

[TLAM Strike]

Today I came over good name for the language I would use for the sim. And it's going to be: Echo.

So I write this post so google finds it and the name is allocated for me :biggrin:

Really, finding a good name is the hardest task on programming language design :rolleyes:
Perhaps the COMSUBSIM logo should now feature an Echo class SSGN? :2ct:

[Dr.Sid]

Ok you lost me right after

"The language will be more or less Basic." :)

Could we get this in plain english as to how this will eventually affect the look and the operation of the sim.

My main interest is how the AI will think.

Well those are just for some other langsmith .. as some may show up.

For the sim it will hopefully mean easy to learn, strong in features, fast to execute .. but these are the design goals so no surprise here :biggrin:

As for AI .. let's discuss main DW shortcomings. In my experience it was lack of documentation and that some things did not work as expected.
Also some AI parts was hardcoded. The language could not handle even missing space and was very error-prone. It was not easy to work with multiple tracks, practically impossible. You could not access object database or mission tasking. Any more ?

All of these will be non-issue in comsubsim. But the most important feature will be support of the author and actual feedback :wink:

[Bubblehead Nuke]

Dr. Sid,

wow, I am impressed. I would not have expected you to design and implement a programming language. Let alone one that would allow us to define parameters and such for the AI to use.

[goldorak]

Dr Sid,

Have you though about developing Comsubsim using a software framework that's platform independent ?
Since you're still in the early stages of development it might be worth looking at the alternative.
You know so that an eventual "porting" to linux/unix/mac osx doesn't require changeing the source code which is always the case if you use windows specific code ?
Since you're already using Opengl for the graphics, why not look at the QT cross platform software framework from trolltech (http://www.trolltech.com) ?
The framework is coded in c++ and the api is quite complete, it spans from network code, to graphics, to gui building.
If you develop the game using QT, then a simple recompile is all that is needed to make it compatibile with linux or unix or mac os x.
Trolltech makes available a license for commercial development and one for open source freeware development. The QT toolkit is the same in either case.

[Dr.Sid]

Bubblehead Nuke: well the only other option was using some existing language. But I happened to have one language almost complete so I just refit it for new mission. Programming language design is more about know how anyway, there is little actual programming.

I plan this to be working on Linux (or Apple). All the platform dependent code is isolated and will be easy to change. I do think about some multiplatform platform like that one you mention, I will look at it. I checked SDL so far but that seemed too limited in some aspects and I would prefer writing the OS interface all again for linux in native linux code. But meybe this Qt stuff will show better.
There are system dependent parts like user input, files, and network. These would have to be redone for each platform and it's not that much code.
Then there is OpenGL and OpenAL which I consider as independent platform itself and they are worked with directly.
All the rest should be common for all platform, including user interface, it's all done manually using OpenGL.

[Hawk666]

Did you consider to use a standard script language like Python ?