The Mirah Language: bringing modern features to the JVM without runtime overhead(drdobbs.com)
drdobbs.com
The Mirah Language: bringing modern features to the JVM without runtime overhead
http://drdobbs.com/java/229400307
11 comments
Android is an exciting use case for Mirah. The other JVM languages run into the runtime library and performance problems mentioned towards the beginning of the article.
Kawa Scheme is another JVM language that works well on the Android.
3-part tutorial on how to write Android apps in Kawa: http://androidscheme.blogspot.com/2010/10/introduction-to-an...
3-part tutorial on how to write Android apps in Kawa: http://androidscheme.blogspot.com/2010/10/introduction-to-an...
Here's a Google Tech Talk by Charles on Mirah as an expressive JVM language from last year http://www.youtube.com/watch?v=BWM2iVgeQKM
I looked into using Mirah for Android programming a while back. I took a 3D tutorial for Android (in Java) and tried to do exactly the same in Mirah.
What I found was that it seemed to be (mostly) possible, but there was NO documentation on how to do most things. With someone's help, I got the tutorial working, except for 1 last bit at the end that wasn't really necessary yet. I never did figure out how to do that bit.
This is the tutorial: http://www.droidnova.com/android-3d-game-tutorial-part-i,312...
The part I never got working was the 'queueEvent' bit of the 'onTouchEvent' bit. Without queueing it, I could get it to work, but I could never figure how to queue it like that.
My sources as I left them: https://github.com/wccrawford/Hello-Mirah--Android
Without any documentation or real info out there on Mirah, it was incredibly frustration just to get that far.
I realize it's a new language, but I can't recommend its use at this point. It needs to mature and gather a community before it's worth investing serious time in.
What I found was that it seemed to be (mostly) possible, but there was NO documentation on how to do most things. With someone's help, I got the tutorial working, except for 1 last bit at the end that wasn't really necessary yet. I never did figure out how to do that bit.
This is the tutorial: http://www.droidnova.com/android-3d-game-tutorial-part-i,312...
The part I never got working was the 'queueEvent' bit of the 'onTouchEvent' bit. Without queueing it, I could get it to work, but I could never figure how to queue it like that.
My sources as I left them: https://github.com/wccrawford/Hello-Mirah--Android
Without any documentation or real info out there on Mirah, it was incredibly frustration just to get that far.
I realize it's a new language, but I can't recommend its use at this point. It needs to mature and gather a community before it's worth investing serious time in.
Yes, you are 100% correct. It is a very young language and project.
I've spent the last several days trying to solidify a distribution (.zip), maven artifacts (with David Calavera's help) and refactor the codebase to make it more approachable. Last night I made some edits to the mirah.org web site, and today I may try to work on the wiki. There's definitely a lot missing as far as documentation and support, but we'll get there.
I appreciate your feedback and links to your projects. They will help us learn what needs to be better documented, and also help us produce better error/info messages from the compiler.
We'd also love to have your help :) This is OSS of course, so anything you can do to document your experiences (blog posts, add to wiki on github, ...) will help us and others.
I've spent the last several days trying to solidify a distribution (.zip), maven artifacts (with David Calavera's help) and refactor the codebase to make it more approachable. Last night I made some edits to the mirah.org web site, and today I may try to work on the wiki. There's definitely a lot missing as far as documentation and support, but we'll get there.
I appreciate your feedback and links to your projects. They will help us learn what needs to be better documented, and also help us produce better error/info messages from the compiler.
We'd also love to have your help :) This is OSS of course, so anything you can do to document your experiences (blog posts, add to wiki on github, ...) will help us and others.
I put together Ferrante for Android using Mirah:
It's a huge improvement over a year ago, when I had to get Charles to fix a bunch of compiler issues just to get the simplest of apps to compile: http://github.com/technomancy/Garrett
http://github.com/technomancy/ferrante
It's a huge improvement over a year ago, when I had to get Charles to fix a bunch of compiler issues just to get the simplest of apps to compile: http://github.com/technomancy/Garrett
It looks promising, but I want a few things first as well:
* docs (as mentioned)
* some kind of javadoc / rubydoc mechanism (perhaps there is?)
* a NetBeans plugin
* a pony
OK, maybe I can get by without the last one :-)
* docs (as mentioned)
* some kind of javadoc / rubydoc mechanism (perhaps there is?)
* a NetBeans plugin
* a pony
OK, maybe I can get by without the last one :-)
Docs...yes, we're getting there. Not all the languages features are even documented because they were added very quickly. It's coming along.
I've been thinking about a MirahDoc format. I think we could pretty much do it like JavaDoc. Potentially even make it work with Doclets.
There is an old NB plugin based on the Ruby plugin, but I doubt it works now. We'd love to have help here. The plugin is on github: https://github.com/mirah/mirah-netbeans-plugin. Of course we'd like help supporting Eclipse and IntelliJ too.
I've been thinking about a MirahDoc format. I think we could pretty much do it like JavaDoc. Potentially even make it work with Doclets.
There is an old NB plugin based on the Ruby plugin, but I doubt it works now. We'd love to have help here. The plugin is on github: https://github.com/mirah/mirah-netbeans-plugin. Of course we'd like help supporting Eclipse and IntelliJ too.
That's great feedback for Charles. I suspect he's trying to settle down the language, then push for beautiful docs. The biggest push for accessibility and language adoption is great documentation.
Cool example.
Cool example.
And the best thing about Mirah? It's written in JRuby.
Charles Nutter is insane. I've got to find a way to use this myself. Maybe for his encore he'll rewrite JRuby in Mirah, just to show Mirah is everything Java is and more. Or maybe the world will explode, who knows.
Charles Nutter is insane. I've got to find a way to use this myself. Maybe for his encore he'll rewrite JRuby in Mirah, just to show Mirah is everything Java is and more. Or maybe the world will explode, who knows.
I'd actually love to get Mirah to a point where we could start to write (or rewrite) parts of JRuby in it. We're very close to that point; it can do almost everything we need for large subsections of code.
> Maybe for his encore he'll rewrite JRuby in Mirah
Actually, that was part of the motivation behind Mirah; Rubyists don't want to contribute to the parts of JRuby that are implemented in Java.
Actually, that was part of the motivation behind Mirah; Rubyists don't want to contribute to the parts of JRuby that are implemented in Java.
Well, what would you expect from people who title themselves 'rubyists'? As opposed to 'programmers', 'web developers' or anything meaningful at all.
Are you accusing Charles Nutter of being a nutter?
One amazing thing is the ability to call Mirah from JRuby.
See https://github.com/thbar/opaz-plugdk/tree/master/plugins/Dub... for an example.
See https://github.com/thbar/opaz-plugdk/tree/master/plugins/Dub... for an example.
Pretty neat. Mirah is to Java as CoffeeScript is to JavaScript?
Looks very similar to ActionScript 2, with shades of Scala. Really neat looking language.
Anyone know where the `param: Type` (i.e., parameter name colon type) convention came from? I've seen it more frequently lately, and I wonder if it's easier to parse than Java's `Type param` (or my favorite: `param Type`)?
Looks very similar to ActionScript 2, with shades of Scala. Really neat looking language.
Anyone know where the `param: Type` (i.e., parameter name colon type) convention came from? I've seen it more frequently lately, and I wonder if it's easier to parse than Java's `Type param` (or my favorite: `param Type`)?
I actually officially asked Jeremy Askenas if I can use the phrase "Mirah is the Coffeescript of Java". He gave me his blessing.
The param:type notation I largely just stole from Scala, but it seems (in my novice opinion) easier to parse as well. It also fits better with optional type declarations, which we have in the case of interface impl or class extension (easier to omit syntax on the RHS than on the LHS for a typical parser).
The param:type notation I largely just stole from Scala, but it seems (in my novice opinion) easier to parse as well. It also fits better with optional type declarations, which we have in the case of interface impl or class extension (easier to omit syntax on the RHS than on the LHS for a typical parser).
[deleted]
And oops...that's Ashkenas. Sorry, Jeremy :)
I'm not sure if it's where the 'param: Type' idiom is where it came from originally, but its use in Mirah almost certainly descended from its use in Haskell and ML. Scala also uses it, and its use there is definitely ML/Haskell-inspired. (Haskell technically is 'param :: Type', since ':' is the cons operator, but it's basically the same thing.)
Since languages like Haskell and ML (and Scala, to a lesser extent) do type inference, type annotations are often unnecessary, and so having the type listed after the name probably makes more sense in that context: what's important is the name, and variable-specific type hints are usually there for the compiler, not the human reader. The exception is functions, which very often get type definitions just because it's very helpful to have that information as a human. Since ML/Haskell-like languages have multiple function definitions and rely on pattern matching, the postfix type notation fits in very well:
Since languages like Haskell and ML (and Scala, to a lesser extent) do type inference, type annotations are often unnecessary, and so having the type listed after the name probably makes more sense in that context: what's important is the name, and variable-specific type hints are usually there for the compiler, not the human reader. The exception is functions, which very often get type definitions just because it's very helpful to have that information as a human. Since ML/Haskell-like languages have multiple function definitions and rely on pattern matching, the postfix type notation fits in very well:
func :: type1 -> type2
func a = ...
func b = ...Interesting...and the point about "the name" being the most important thing is really insightful. That's exactly true.
Pascal uses the "param : type" syntax, although I'm not sure it's the first language to do so. I believe it's older than ML. It's funny to "see this more frequently lately" as it's a really old convention. What's old is new again, I guess...
http://en.wikipedia.org/wiki/Pascal_(programming_language)#P...
http://en.wikipedia.org/wiki/Pascal_(programming_language)#P...
ML type annotations use that syntax, so it's probably the grandaddy of them all.
It's easier to parse if your type syntax uses juxtaposition. "Some int" is a valid type, so it would make "<type> <var>" harder to parse. It's hard to tell when the type ends and the variable name starts without backtracking.
It's easier to parse if your type syntax uses juxtaposition. "Some int" is a valid type, so it would make "<type> <var>" harder to parse. It's hard to tell when the type ends and the variable name starts without backtracking.
It's common in statically typed functional languages and an old notation. I believe a key motivation is the analogy between a Set and a Type. Then saying x : Int is like similar to saying x ∈ Z, x is an element of the integers.
I started playing with Mirah last weekend, and I'm probably going to use it in my next project. Native Java speed, Ruby syntax, and JRuby interop are a hard feature list to beat.
One of the things that I extremely love about this is the fact that it compiles down to almost identical java bytecode and then can be run with the java command. The fact that performance is on par with java. That it is basically statically typed ruby on the jvm. In my opinion its what jruby should have been. Its absolutely brilliant and a testament to how languages should be written on the jvm. I think one of the key points as said is to limit overhead in comparison to java.
Has anyone written anything in mirah thats been deployed? I assume it can be built pretty much in the same way as any java project.
Has anyone written anything in mirah thats been deployed? I assume it can be built pretty much in the same way as any java project.
Java without ceremony (I don't know, code casual?)
But last time I tried it, there was massive compile time overhead (30 seconds for hello world, on a eee PC). Has that changed? I'm possibly getting it confused with a bunch of JVM languages that I tried out at the same time.
But last time I tried it, there was massive compile time overhead (30 seconds for hello world, on a eee PC). Has that changed? I'm possibly getting it confused with a bunch of JVM languages that I tried out at the same time.
The compile times have definitely improved, but there's more to be done. At least now you can compile multiple files at once, which saves a lot of hassle :)
Thats often the case with new languages. I remember it took longer than that to compiler Hello World in Scala, but today that is pretty fast.
We've slowly moved more and more of Mirah into Mirah code as well, which will help performance over time. Currently almost all of Mirah is written in (J)Ruby, with according startup and performance overhead. Great for prototyping, and great for extending (we will probably always allow defining language features in Ruby) but not great for quick startup and fast execution.
The checklist for Scala:
- Performance equivalent to Java for equivalent code
Pass.
- No language-imposed runtime library
Failed. 5mb runtime lib.
- No more (or not much more) complicated than Java
It depends. For some, Scala feels much more streamlined than Java. For others (esp. those used to dynamic languages), the type system is a huge pain.
- Beautiful
Certainly much more beautiful than Java.
- Perfect integration with JVM libraries
Use existing JVM libs without change.
- Extensible
Major language features such as actors are all libraries. Very easy to embed DSLs.
- Performance equivalent to Java for equivalent code
Pass.
- No language-imposed runtime library
Failed. 5mb runtime lib.
- No more (or not much more) complicated than Java
It depends. For some, Scala feels much more streamlined than Java. For others (esp. those used to dynamic languages), the type system is a huge pain.
- Beautiful
Certainly much more beautiful than Java.
- Perfect integration with JVM libraries
Use existing JVM libs without change.
- Extensible
Major language features such as actors are all libraries. Very easy to embed DSLs.
Scala is a great language, but the requirement that I ship Scala's libraries if I want to do thinks the Scala way is a nonstarter for the use cases I have. Yes, you can Proguard a lot of that away, but if I use Scala's collections or other libraries, I'm still stuck adding a runtime lib.
As far as the others go...I don't disagree. Perfect integration with Java is perhaps a bit debateable, since you can't overload constructors, can't define real static methods Java can see, and so on. But those are minor items.
I don't intend Mirah to be a Scala-killer either. Scala is more of a platform now than just a language, and if you're on that platform, you have my blessing. If, however, you just want something to replace javac everywhere you use Java today, I believe Mirah is a better fit.
As far as the others go...I don't disagree. Perfect integration with Java is perhaps a bit debateable, since you can't overload constructors, can't define real static methods Java can see, and so on. But those are minor items.
I don't intend Mirah to be a Scala-killer either. Scala is more of a platform now than just a language, and if you're on that platform, you have my blessing. If, however, you just want something to replace javac everywhere you use Java today, I believe Mirah is a better fit.
You are right. It really depends on use cases. In many scenarios, a 5mb lib is just another dep that build tools such as sbt will handle for you. In many others, 5mb overhead to a 500kb mobile app is obviously overkill.
My use case is fine with Scala: no deployment issue, no Java legacy other than using a few libs, and everything else is fresh in Scala. So far I'm very happy with the choice. FP makes things really compact.
I like Mirah for the fact that it can generate Java source code (vs. JVM bytecode). I would imagine there are many cases Java compatibility down to the source code level would be desired.
Anyway, good job!
My use case is fine with Scala: no deployment issue, no Java legacy other than using a few libs, and everything else is fresh in Scala. So far I'm very happy with the choice. FP makes things really compact.
I like Mirah for the fact that it can generate Java source code (vs. JVM bytecode). I would imagine there are many cases Java compatibility down to the source code level would be desired.
Anyway, good job!
If, however, you just want something to replace javac everywhere you use Java today, I believe Mirah is a better fit.
My prayers have been answered! A better java has arrived!
My prayers have been answered! A better java has arrived!
Neat and interesting, I strongly prefer Mirah more than Scala to be the "next Java"
Why? what are the main differences?
gimme optional dynamic typing and I'm sold
I believe it's in there, no? (Requires the java 7 runtime, if memory serves?)
Can you link to an example or something?
Here's the example from Mirah's repo: https://github.com/mirah/mirah/blob/master/examples/dynamic....
It does require Java 7 and there's no plans to make it work on Java 6-. Unlike the rest of Mirah, this feature (if you use it) does require a runtime library, since Java 7 / invokedynamic do not ship anything builtin for choosing a target Java method. We use Attila Szgedi's "dynalink" project, which provides a default dynamic linker based on Java language specification method selection rules.
Long story short: yes, Mirah can support dynamic dispatch as well, but it needs a little bit of runtime library to support that.
It does require Java 7 and there's no plans to make it work on Java 6-. Unlike the rest of Mirah, this feature (if you use it) does require a runtime library, since Java 7 / invokedynamic do not ship anything builtin for choosing a target Java method. We use Attila Szgedi's "dynalink" project, which provides a default dynamic linker based on Java language specification method selection rules.
Long story short: yes, Mirah can support dynamic dispatch as well, but it needs a little bit of runtime library to support that.
Is there something similar for Pythonistas? i.e., something with python-like syntax, static and duck typing, and performance that of equivalent Java?
Ruby syntax is already really similar to Python syntax. Significant indentation is the biggest difference. I actually made a prototype Ruby with significant indentation a la Python and I think most people would have mistaken it for Python at a glance.
Boo, which has both JVM and CLR backends.
The original goal for this was to allow Mirah to be used in places where Java source is required, like GWT apps. We've kept it going over the years (thanks to Ryan Brown, my co-conspirator).