We have an IDE for machine automation that allows its users to develop solutions by connecting objects and components visually. They can also write "plugins" using C++ and C#. The IDE is written using .NET. Its users often are not founded in traditional software development and programming but more in the direction of technical/electrical and automation engineers but they all need to know the basics of C# and C++ programming.
If we were to introduce a macro/scripting language for the IDE itself including an interactive console (designtime only) which language should we chose? It should be a dynamic scripting language that both has a good foundation in .NET and the DLR in that it is future proof and has good support and a decent momentum behind it but also would not have such a steep learning curve for our special developers. Ideally it should be completely intuitive to use if you know C++ and/or C# - even if you are not a rock-solid software developer.
UPDATE: The option that currently is most attractive to us, is to use dynamically compiled C#. Our users could continue to use C#. It even seems to be possible to build an interactive console, as CSI proves. What do you think of this option? Are there any potential pitfalls/downsides that we (due to our lack of experience with scripting in general) just are not aware of yet?
Python (IronPython) would have my vote. It is a dynamic language that you can use for scripting .NET programs, and you can use it interactively (haven't actually tried interactive with IronPython, but you certainly can with "regular" python). Unfortunately, it's not going to be completely intuitive to your C++ and C# devs.
You could just use C# as your scripting language (you can compile and execute the code at runtime), but you wouldn't get an interactive console, and it's not very "script"-like.
I think simplicity is very important in a scripting language. "Hello World" in Python is simply print "Hello World"
, where in C# you would need a namespace, class, static Main method, etc. If you want to use C#, you can simulate that by wrapping the user-supplied code inside of a function definition (or at least a class) before compiling, so their "script" can simply be the function's contents. That will somewhat restrict what they can do in a script, which could be good or bad, depending on what you want. If they need multiple classes and functions, maybe they would need to write a full plugin in your case.
I think we will either roll our own c# based scripting environment, sort of like a much simplified version of the very cool CS-Script or we would integrate CS-Script right away.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With