Back-end choice for a new dynamic programming language?

Question

I've been developing a Smalltalk variant for just the fun of it and I wonder what would be a fellow stackoverflowers choice when it comes to targeting a back-end. These were my current considerations:

.NET, JVM: These two VM's are mainly for statically typed languages and I assume it would be quite hard to target such a dynamic language like smalltalk.

Python (as source code): Seems to be the simplest way. Also it would be better if I could emit Python bytecode but it's not well documented as other VM's AFAIK (Need to dig Python's source code for details!).

Self made interpreter: Out of the question as it's no fun :-)

LLVM, NekoVM, Parrot are other options I'm checking out. What would be your take on this?

Answer 1

I would choose the JVM, but mainly because I'm familiar with it.

Objective reasons for JVM are: main platforms are supported, many libraries and good performance (within the choices you have given it may have the best performance).

.Net works best on Windows. If you choose it, you should test on Mono to be more platform-neutral.

Python seems a good choice as well. But I think for the JVM more libraries are available.

Parrot is in my opinion too fresh, it needs some time to mature. But an interesting alternative for the future.

The other choices are new to me, I will take a look at them.

Answer 2

.NET as the DLR now that sit on top of the CLR for Dynamic language.

Answer 3

Don't discount .NET or the JVM so quickly. Dynamic languages are being developed for both (e.g. Groovy, JRuby, Jython on the JVM; IronRuby, IronPython on .NET) and .NET is gaining the "DLR" - Dynamic Language Runtime. (See Jim Hugunin's blog for more details.)

Answer 4

JVM as first choice. It would allow for a wide library support from the day one. See how that benefited Clojure.

Also, LLVM might be interesting choice, but I'm not sure how "proven" it is, since I can't have a mature language implementation with LLVM backend.

I would avoid .NET. It would make it harder to gather community and support around the your new language, and you are going to need it soon. Also, it is not cross-platform.

Whatever you choose, you will learn a lot by doing so.

Answer 5

Parrot is really cool, even if they haven't shipped any "real" code yet. But since the project's just for fun, that shouldn't stop you :D.

Answer 6

JVM is more stable, well documented, and in general less likely to be a moving target than .Net Also you're more likely to find people that can help you out if you go open source. With .Net talent is really scarce, and most work for Microsoft, so they won't likely have the time to help out.

Answer 7

Since you are trying to implement Smalltalk, why not consider one of smalltalk-inspired VMs for Ruby like YARV or even rubinius. Both are smalltalk-inspired and aim to be high-performance. YARV will be the new standard Ruby VM.

Answer 8

Do it on .Net, after all you want to do it for fun. So make it a bit challenging. And any findings then can be reported to Microsoft, for improvement in DLR and the languages it supports.

Answer 9

One adavantage of using Parrot is that it ships with tons of example languages, including a Smalltalk variant called ChitChat. So you can use that as a reference to see how someone else has implemented a similar language on Parrot.

Answer 10

You might want to have a look at PyPy -- while this project exists to implement the Python language in (a subset of) Python, the approach they are taking allows multiple front-ends and multiple back-ends (including CLR, JVM, LLVM, C, and even Smalltalk and JavaScript, I think). For example, work on the JIT has been done using Prolog as the front-end language and CLR as the back-end. So you might join the party to implement Smalltalk and later discover you've also helped someone else implement Prolog without knowing it... :-)

Answer 11

Factor (http://factorcode.org/) may offer some useful features for this.

Answer 12

If you're going to look at using .Net, have a look in Beautiful Code -- there's an essay in it about doing dynamic code gen on the .Net CLR.

Answer 13

Definitely .Net using the Dynamic Language Runtime. Your objects will be usable directly by C# and V.Net users by the time you're finished (you are intending to ship something? :-)

In particular, target running under the reduced .Net in SilverLight so you get the latest web rich UI buy-in.

Answer 14

If this is for fun, why not start with the codebase for Squeak, which is open source, and modify it. Smalltalk should have a small runtime, and your small fun variant could start with the bootstrap environment from squeak, which is nearly microscopic, and built up from there.

My big thing against .NET and the JVM is the sheer huge size. Look how small the runtime "operating system to smalltalk" impedence-matching-layer is in Squeak.

Shouldn't fun projects be, well...... FUN? Squeak is many things, businesslike is not one of them, but FUN ... definitely.