Dynamic languages and the virtual machines that love them

Brian LeGros | June 1st, 2007 | programming  

Talk about crazy groupy love going on for languages running within a VM huh? It’s so exciting to start seeing other languages in the main stream being the basis for new languages rather than C/C++ which seems like the usual choice.

After the announcement that Microsoft would be releasing the DLR, I stumbled upon an article at InfoQ. I don’t know much about how to write runtime environments, but the article made some sense to me. I found the author was kind hard on JRuby since I’m interested in using it, but I do dig a lot of things .NET in general has to offer (first-class generics, formal properties, how easy registration works, the use of delegates, etc). I’m also very interested in what Java offers in this problem domain. It seems like with JSR 223 included in Java 6 and JSR 292 hopefully going through in Java 7, Java and the DLR could provide similar features for dynamic language development when they’re completed.

I don’t have much of an opinion on which approach is better in terms of forming the foundation for dynamic languages, but I think the future of these platforms will likely be determined by: feature support, environment availability, and plain old cool APIs.

Platform Availability: As far as Microsoft’s effort, I noticed that the DLR has been open sourced but the CLR has not. This leaves Mono to integrate with the DLR for platforms other than Windows. Java on the other hand has been fully open-sourced (minus a few proprietary libaries they can’t open up legally from what I understand) and has always had a plethora of platform support. I feels like Mono will really have to step up in terms popularity to compete with the ubiquity of the JRE. Novell is a sponsor of the project, so I really hope it takes off.

Features: I definitely like the idea as a developer of being able to switch around to different languages mid-stream, but I’m not sure that there are that many different constructs in languages that I feel would make me more productive. Additionally, some of the things that the DLR is trying to do in terms of some sort of shared typing system kinda freaks me out. Isn’t the strength from some of the dynamic languages in how they treat their types versus conventional treatment of types in languages such as .NET and Java?

Cool APIs: One of the biggest things I would love to do is build some type of API in Java for JRuby which allowed JRuby to take advantage of some of the JEE frameworks which make programming in Java for enterprise so cool. For example, I’m not sure if this is feasible or not, I’d like to integrate JTA into JRuby one day such that a JRuby developer could put together objects in a business layer and then in an config file of some sort construct AOP advice that would add transactional proxies around the appropriate business objects so that robust transaction management could be introduced into Ruby (if something exists already that is robust as JTA, please correct me). This may be a pipe dream because I’m not too familiar with what is possible via the Invocable interface in JSR 223. Aside from my rant, I think just having access to Java or .NET APIs when is cool since they are so much more mature from a commercial standpoint.

So with that being said, my last question is this: Where is the standardization for ColdFusion as a dynamic language as it applies to JSR 223? From what the JSR spec says, it appears that Macromedia was one of the largest supporters. Do languages written based on Java have to be open source to be compliant with the dynamic language support in Java? I’m not even sure why I’d want it, but it just seems like a missing, logical step to me for some reason. ColdFusion has done an amazing job over the last few years of “glueing” different languages togther, why not implement this spec?

Oh well, I’m probably going crazy over nothing, but if anyone has any feedback, please let me know.



Tags: , ,

Related posts

Discussion

  1. danielroop Says:
    June 2nd, 2007 at 4:44 am

    Brian,

    Correct me if I am wrong, but coldfusion is essentially implemented through a servlet. If they were to make this implementation using JSR, the language would be so much less restrained. For instance you wouldn’t need a server running to unit test or debug you code. Could you imagine cfdebug, and cfcUnit or even cfcBehave in a nice eclipse runner like jUnit, or even better be able to set break points in your cfcs and step through the execution.

    I remember hearing somewhere that Adobe didn’t feel it was necessary to impleent becasue about 2% of the community uses coldfusion in a way it would be helpful. But I believe with coldspring, and transfer, more and more people are moving from the procedural coldfusion into the object oriented coldfusion. And the closer to the JVM the language gets, the better the tools for working with the language will get.

  2. me Says:
    June 2nd, 2007 at 6:39 am

    @Dan

    That’s a good point, I didn’t think of that. Right now it feels like you’re hooking into a server to get the job done when you could just be running in a local context to accomplish the same thing. Netbeans accomplishes this by using Ruby and WebBrick together, I wonder if something as simple as that could help to solve the problem? Maybe a Jetty instance with Adobe’s app server attached that could be started in a local context w/o dependency on a remote app server? Maybe even just a cfcompiler and some type of webserver emulator tied into CFEClipse so that the server isn’t even needed?

    CF8 has the debugging features you’re looking, CFEclipse has the cfc/cfUnit runner in Eclipse for us, but it feels like a chore to do setup. They made it as easy as possible and it still doesn’t feel like I can be as productive as I want like I can when working with Java or .NET.

Add A Comment