What scripting language for our .NET based IDE? [closed]

Question

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?

Miley

Well, it appears like the DLR is not going to be supported in the future, so you'll have to either get rid of the "future proof" requirement or use something other than the DLR. – Extravasate

@Richard - Why would they do that? – Colley

It got merged in the .NET 4.0 framework. And used by the C# dynamic keyword. Not exactly a sign of imminent death. – Njord

@Hans That's completely different. – Extravasate

@Lucas Well, IronRuby is all but dead, and there's a lot of doubt that IronPython will survive, and if neither survive, then there is no point in the DLR. See channel9.msdn.com/forums/Coffeehouse/565848-IronRuby-dead, and blog.jimmy.schementi.com/2010/08/…, and – Extravasate

@Richard - What is more likely is some suits at Microsoft didn't want the responsibility of maintaining those projects. I am sure they would love to see others use the DLR. – Colley

What kind of code do the engineers write? If it is mathematical code or code with lots of physics, F# might actually be an interesting option. (Because of its foundation in math, and it even has support for physical units). Of course, it is not a dynamic language, and it is not immediately intuitive for C++/C# programmers... – Crelin

@Richard The dynamic language runtime (DLR) is a new API in .NET Framework 4. It provides the infrastructure that supports the dynamic type in C# msdn.microsoft.com/en-us/library/dd264736.aspx – Electroplate

@Colley I don't know why - there is quite a bit of confusion about it right now. The Channel9 forum had a discussion thread about it, with lots of speculation, but right now your guess is as good as mine. – Extravasate

@Hans and Lucas: Hmmm, ok, I figured they just used tech from the DLR for dynamic support in the CLR, I was mistaken. However from the sounds of things IronRuby and IronPython may not have any MS support in the future. Then the community will be expected to take over, because they are open source (Apache license). – Extravasate

Answer 1

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.

Miley

Answer 2

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.

Gerent

What does "script-like" actually mean in real life? What features bring scripting languages to the table that are important/helpful that c# does not have. – Miley

My comment was getting over-long, so I edited my answer. Also, one of the main features that sets scripting languages apart is being very dynamic (and dynamically typed). While there are new dynamic extensions in .NET 4.0, C# is still a rather static (and statically typed) language. – Gerent

So the main reason to have a dynmaically typed language is to be able to type less characters? – Miley

No, those are two separate issues. Also, a "dynamic" language is not necessarily dynamically typed. Sorry if my answer is getting a bit confusing. – Gerent

I agree that a "scripting language" should be simple because your users might not be expert programmers. I think there are a lot of C#-based scripting options if you need that power and complexity. I wrote my own interpreter SILK that was designed to be much simpler and easier. – Scion

Answer 3

The future isn't clear for the DLR the currently-supported dynamic languages IronRuby and IronPython. What's unclear is Microsoft's direction on those 2. Until I hear it from The Gu or higher, I'd avoid making a decision on either one of those 2. That doesn't help you today, making a design decision for your users. I get the sense that IronPython will retain support, but that's just baseless speculation.

For .NET scripting, also consider Boo.

Boo is an object oriented, statically typed programming language that seeks to make use of the Common Language Infrastructure's support for Unicode, internationalization and web applications, while using a Python-inspired syntax1 and a special focus on language and compiler extensibility. Some features of note include type inference, generators, multimethods, optional duck typing, macros, true closures, currying, and first-class functions.

• Official Boo Site
• Wikipedia entry for Boo

Hackle

The dynamic language runtime (DLR) is a new API in .NET Framework 4. It provides the infrastructure that supports the dynamic type in C# msdn.microsoft.com/en-us/library/dd264736.aspx – Electroplate

@Lucas: great stuff there with the copy/paste. C# is compiled, not interpreted. The OP wanted options for 'dynamic scripting language'. Not sure what your comment has to do with Boo. – Hackle

copy and paste again :) you said The future isn't clear for the DLR. It is quite clear, unless Microsoft wants to replace it in C# 5+. Even if they do, DLR itself is safe until C#4 is unsupported. – Electroplate

@Lucas: indeed, you're right. The DLR is in place, and will be around at minimum as long as .NET 4, and hopefully much longer. I should correct my wording. – Hackle

Answer 4

I embedded a little C# editor in an app and compiled/ran results

ala

var codeProvider = new CSharpCodeProvider( 
              new Dictionary<string, string> { { "CompilerVersion", "v3.5" } } );

var parameters = new CompilerParameters( );
// add any of your 'library' dlls as references
parameters.ReferencedAssemblies.AddRange( dlls.ToArray( ) );
parameters.OutputAssembly = outputPath;
CompilerResults r = codeProvider.CompileAssemblyFromFile( parameters, sourceFiles );

Rombert

C# would be most attractive for our users. We would just need to make sure that everything you'd usually expect from a sctipting environment (like for example an interactive console) is actually there. – Miley

Answer 5

If you look at the way Microsoft is heading with scripting / automation of their products PowerShell would the thing to target.

Developing your custom host and provider should integrate nicely into your .NET application.

Annapurna