views:

165

answers:

5

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) wich 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 memento behind it but also would not have such a steep learning curve for our special developers. Ideally it should be completely intuitve to use if you known 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 prooves. 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.

+1  A: 

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.

Bob
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.
bitbonk
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.
Bob
So the main reason to have a dynmaically typed language is to be able to type less characters?
bitbonk
No, those are two separate issues. Also, a "dynamic" language is not necessarily dynamically typed. Sorry if my answer is getting a bit confusing.
Bob
+1  A: 

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.

p.campbell
`The dynamic language runtime (DLR) is a new API in .NET Framework 4. It provides the infrastructure that supports the dynamic type in C#` http://msdn.microsoft.com/en-us/library/dd264736.aspx
BioBuckyBall
@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.
p.campbell
@p.campbell 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.
BioBuckyBall
@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.
p.campbell
+1  A: 

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 );
BioBuckyBall
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.
bitbonk
A: 

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.

bitbonk
A: 

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.

Filburt