views:

423

answers:

5
A: 

Firstly I think that defining your own language is not the way to go.

  • Primarily because the biggest productivity gains you can get for programmers or non-programmers are the development tools. You (and 99.9% of the rest of us) are not going to write tools as good as what is out their.
  • Language design is hard.
  • Language support and documentation, also hard

I would recommend looking for a pre-built solution. If you could find a language that can lock down some functionality, that would be a good starting point. MatLab would be the first that comes to my mind.

Lastly, ditch the natural language part, BASIC, COBOL and YA-TDWTF-Lang all tried and failed at it.


Full disclosure: I work for a company that is developing a generalized domain specific language "system". It's targeted at data-in/text-out applications so it's not apropos and it's not yet to beta. The result is I'm somewhat knowledgeable and biased.

BCS
A: 

What kind of real-time requirement are you trying to fulfill? Is the simulation a hard real-time simulation (some kind of hardware-in-the-loop simulation ==> deadline is less than 1/1000 second)? Or do you want the scripting-system to be "reactive" to user-input ==> 1/10 should be sufficient.

I am no expert regarding MS DLR, but as far as I know, it does not support hard real-time systems. You may want to take a look at the real-time specification for Java (RTSJ)

ralf
+2  A: 

Lua

it's small, fast, easy to embed, portable, extensible, and fun!

Javier
+1  A: 

Lua is definitly the best choice for soft real-time system (like computer games). See http://shootout.alioth.debian.org/ for detailed benchmarks.

However, last time I checked, Lua used a mark-and-sweep garbage collector which can lead to deadline-violation and non-deterministic jitter in real-time systems.

ralf
it's an incremental GC, and you can easily invoke it at each cycle, that makes it do really small steps. as with anything, test first.
Javier
+1  A: 

I believe that you could use theoretically use the DLR, but I'm unsure about support in an XBAP (partially trusted?) scenario.

If you host the DLR you would quickly be able to take advantage of IronRuby or IronPython scripting. You would want to look at these implementations when creating your own language implementation. If you post your question to the IronPython mailing list I'm sure you would get a better reply around the XBAP scenario, and some of the developers there created ToyScript.

BrianLy