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).
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.
I did manage to generate a GWT application from Mirah=>Java once, but the Java source required some massaging. So it's close, but not quite there yet. Soon.
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.
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.
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.
It took a lot of diving into undocumented things; it's definitely at the point where to do much you have to be ready to blaze your own trails. Though while writing Ferrante I factored out a bunch of the icky build things in Pindah, so it's much easier now: 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
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.
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.
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.
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.
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`)?
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).
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:
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...
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 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.
That would be my bet, especially since Java, especially since 1.1, reminded me so much of [Turbo] Pascal in C++ clothing, so it only seems natural to borrow another Pascal-ism.
But Pascal stole from Algol. Nothing new under the sun...
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.
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.
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 :)
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.
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.
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.
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.
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.
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).