What does Mirah language offer over JRuby,Groovy and Scala?
Unlike full-featured languages, which come with their own libraries, Mirrah is more like a different "frontend" to the Java libraries.
Mirrah code does not depend on it's own environment (except the Mirrah compiler at compile time).
That's the main benefit: A different syntax for Java.
According to an interview with Mirah's creator the point of Mirah (which means "ruby" in Javanese) is to create a high-performance variant of Ruby. Enough Ruby-like syntax to make it comfortable to work with, but still close enough to Java and JVM semantics so that it can run without the overhead of a big runtime layer on top of the JVM.
Choice quote:
Much of the benefit of Mirah over similar languages comes down to being so lightweight. In Groovy, Scala, JRuby, Clojure, or Jython, the minute you write "Hello, world", you've shackled yourself to a runtime library. In Mirah, "Hello, world" is just as terse as in JRuby, but has the added benefit of not foisting any dependencies on you; source file goes in, class file comes out, and that's it. I believe the JVM needs a new dependency-free language, and Mirah is my attempt to deliver one.
While JRuby's performance rivals or exceeds other Ruby interpreters, the fastest JRuby code still lags pure Java performance by an order of magnitude. While you can expect the performance of JRuby to improve with the 1.6 release, Mirah is an attempt to break through the performance ceiling and provide an option for programmers looking for execution speeds on par with Java code.
vs. Groovy
Syntax more familiar to existing Ruby/JRuby programmers
Statically typed
vs. JRuby
Statically typed
vs. Scala
Syntax more familiar to existing Ruby/JRuby programmers
The MAIN advantages are static typing (faster performance on the JVM and much easier interop with existing Java libraries) and a familiar syntax (if you come from Ruby).
When dependencies are a consideration (developing an android app, for example) then you shouldn't let this guide your language choice. Using a tool like Proguard will level the playing field.
If you're coming from Ruby, then Mirah is a good choice. If you're coming from Erlang or Haskell, then you'll want Scala. If you're a LISPer, then you'll want to take a look at Clojure.
If your only prior experience is Java then Shame on you! - and you should probably go for Scala - It's rapidly gaining a reputation as the heir apparent to Java, tool support is currently stronger and you'll be in a large community of others who made the same transition, so there are plenty of blogs/tutorials already available.
and Groovy? Groovy is almost never the right choice nowadays...
I use Mirah everyday on Google AppEngine.
Here are my reasons to use Mirah:
no runtime library
very nice syntax
as fast as Java
Having Java under the hood is very helpful too:
solid typesystem
well documented
known solutions for common problems
I did some Groovy, lot of JRuby and none of Scala.
If you know these, try Mirah.
If not, I'd go with JRuby.
Mirah is just another rubyish syntax for java. IMHO not good at all. It knows nothing about generics, and also has poor tooling. Better try ceylon, xtend, scala, kotlin etc.
Mirah compiles to java classes (not sources anymore). Xtend compiles to java sources and so simpler to found out what it does under the hood. Ceylon and scala have their own stdlibs (nevertheless java interop is near to perfect in them both), not sure about kotlin. Kotlin is JetBrains' child and thus tied to IDEA.
JRuby I don't like too. It has too many bugs in java interop. And it also have too many reinvented wheels. I mean encodings (it does not use java strings and regexes but custom strings on top of raw byte buffers), IOs, exception handling, threads etc.
The only advantage of jruby is that it is ruby. Many ruby code will just work as it is.
Groovy OTOH does not reinvent the wheel, it uses well tested java libraries and just adds syntax sugar too them. Also groovy-java interop is great. It can generics. Threads, exceptions, strings, collections - are just java classes as they are in java.
Related
I am going through Scala book by Martin Odersky.
It states that Scala language is highly scalable,reason being that it allows users to add new features which can be utilised as native language support.
It has got me confused with the term 'Scalability'.
I understand that scalability means ability of a software to handle huge amount of data.
So what's the difference here?
In the context of Scala, Odersky usually means that it is scalable in the sense that it can be used for a wide range of tasks, from simple scripting to large libraries to behemoth enterprise applications.
It's good for scripting because of its type inference, relatively low verbosity (compared to Java), and functional style (which generally lends itself to more concise code).
It's good for medium size applications and libraries because of its powerful type system, which means it is possible to write code that mostly or only produces errors at compile time rather than runtime (to the extent that is possible). The Play! framework in particular is founded on this philosophy. Furthermore, Scala runs on the JVM and therefore can harness any of the many, many Java libraries out there.
And it's good for enterprise software because it compiles to JVM bytecode, which already has a great track record in enterprise software; further, the fact that it's statically typed makes the maintenance of very large codebases much easier.
Scala is also applicable to a number of other areas, making it even more "scalable": concurrency/parallelism and domain-specific languages come to mind.
Here is a presentation by Odersky, if you start at slide 6 and go forward, you'll see him explain some other uses of Scala as well.
I have been wondering if Scala has any particular properties that make it inherently dependent on the JVM, or if it could be viable on top of something else. I can see how both the JVM's ubiquity and continued improvements, and the interoperability between Java and Scala, are strong arguments for this strategic choice. However, I understand that for this reason, compromises were made in the language design.
If the days of decline were to come for the JVM, would Scala go down with the ship, or could there be life after the JVM?
There were projects to have Scala running on .NET runtime (discontinued, the person who worked on it is improving the compiler backend for future versions of Scala) and LLVM (stuck). Moreover, there are several backends for Scala -> Javascript (e.g. scala js), so I would say it is possible to untie Scala from the JVM in some sense.
At the same time many Scala APIs depend on Java APIs, many optimizations and inner workings are implemented with respect to the JVM. There is a number of discussions on mailing lists on Scala without JVM, Scala with it's own virtual machine and so on, e.g this one, but as far as I know, the official statement is to support non-mainstream JVMs as well (Avian for example), rather than having an own runtime. This way Scala can be run on iOS and Android (and PCs of course).
As Simon Ochsenreither noted, Avian is not just yet-another JVM, but comes with some distinct advantages compared to HotSpot:
Ability to create native, self-contained, embeddable binaries
Runs on iPhone, Android and other ARM targets
AOT and JIT compilation are both fully supported
Support for tail calls and continuations
An intelligible code base
Responsive maintainers
Open for improvements (value classes, specialization, etc.)
I would think that since they both run on the JVM, Scala and Jython could be used together. How well do they interface? Can you make calls to Scala libraries from Jython? What about Jython libraries from Scala?
Take a look at this report from Daniel Spiewak who, at the recent OSCON, discussed the interoperability issue with various JVM language creators. It won't answer any of your questions, but might give you a better understanding of the possible issues.
One thing, though, I can tell you for sure. Since Scala can be called from Java, then anything that can call Java can call Scala. As for Scala calling Jython, that depends on whether Java can call Jython -- if it can, then it is possible. Interoperability issues might exist, however.
we are considering Scala for a new Project within our company. We have some Junior Programmers with only PHP knowledge, and we are in doubt that they can handle Scala. What are your opinions? Some say: "Scala is a complicated beast!", some say: "It's easy once you got it." Maybe someone has real-world experience?
"My coworkers will not understand Scala" is simultaneously overstating its difficulty and insulting your coworkers.
Scala is not that difficult. It's just another programming language. Any trouble that junior programmers have with Scala is going to be more or less the same trouble they would have with any other language.
Your coworkers are smart. Of course, I don't know them, but it's a pretty safe bet unless your company is the kind of organisation that hires stupid people, in which case, you have bigger problems.
That said, at my company we have some core products developed in Scala, and we don't find that people have any more trouble with it than Java. The code is generally more clear and concise, easier to generalise and reuse, etc.
I guess Scala could be used as a "beginners" language. Even though there are tricky ideas behind it, you dont have to use/explain them in the beginning. If you explain pure OO with Scala, I would say it is straight forward and easily understandable. As Scala reduces a lot of code overhead from other languages it might even be easier to learn concepts with Scala than with Java/C++.
A major drawback I see with Scala as a beginner language is the lack of documentation. Don't get this wrong, the official Scala doc is very good and also the few books that are available are quite useful to get the details of the language, but those have not been written for beginners. For example in Java you find hundreds of books titled something like "Learning OO with Java" you wont find that for Scala which may be a show stopper.
As Hannes mentioned, only do new language introductions within research projects and not productive or even flagship projects. If you have some juniors, that makes the situation even better, take some internal tool, you always wanted and needed and let them create it during a research project. This is also a nice opportunity to experiment with different development-processes. And your juniors most probably like to be challenged and will deliver a good prototype and a very well proofed opinion if Scala can be used as a beginner language.
I believe that most people moving to Scala are experienced and enthusiastic coders. I'd suggest that you get in-house experience with a Scala project with your senior programmers first before forming a strategy for mentoring your junior coders. I'd also suggest that you only involve people who are eager to join in.
I would advocate it. But with the proviso that you have clear guidelines on what language features are acceptable for your team. For example, coding primarily in an imperative style (which is familiar for Java-trained people), or perhaps limiting the employment of recursion or closures.
Also plan for seniors to mentor the juniors. This may take the form of any combination of: pair programming, code reviews, info sessions, regular discussion forums, etc.
The opportunity that scala presents for vastly improved coding on the JVM is too great to pass up. When your seniors get into it I would not be surprised if they find renewed passion for development. When your juniors get into it they will be learning best practice JVM development from the start.
If you choose to go this route, perhaps they'll find easier to use the Scalate framework than a more traditional one like Lift, since it allows mixing HTML with Scala, much in the same way as PHP works.
Scala is a very 'normal' programming language. Any programmer should be able to learn this language. The people that have difficulties learning Scala mostly are experienced with imperative languages and are surprised by the functional concepts. So unexperienced programmers may learn it even faster. In my opinion should be no problem, to assign it to juniors. From a management point of view, I would assign a junior and a senior developer as a team (or more of both, depending on the size of the project).
I think it depends whats more importent for you. If you want to learn as possible about OO Programming and the standard stuff its a bad idea.
But what you really give them is a opportunity to learn something really cool and unique. Witch can be good motivation. Scala has many cool stuff in it. If you can handle Scala you can handle a lot of otherstuff as well.
Talk to the Programmers (all of them) and tell them why you wanne to use scala. Ask if the have to motivation to make and learn something not everybody can do and go the extra mile?
If the are go with it!
My initial thought would be that Scala will be too heavy for them but then I guess because Scala is an OO/Imperitave/Functional hybrid, one could introduce them to the OO/Imperative part of scala until their comfortable, but then again they will probably have bad PHP habits in Scala since scala authors mostly prefer the functional style over the imperative one.
So, it could work, but I would do it for a research project, and definately not for a flagship one.
Edit: Perhaps this should be said also: It seems that functional/OO hybrids like Scala is becoming more popular especially because of how functional languages handles parallel processing as opposed to how we know it in languages like in Java. The amount of cores found in a chip is increasing rapidly, so this is important. However, mentioning PHP, it seems that you are developing web server scripts where threading is less important. PHP doesn't even have threads.
This raises another point. Do you want to develop Scala Web applications i.e. Lift. If so then you have a doubled up learning curve which should also be considered.
Imagine that you would have picked Java and asked whether they could handle Java. If your answer is they could, then they can probably handle Scala.
Scala is only marginally more difficult due to:
No great IDE support. The support ranges from poor to good. Not necessarily an issue for a PHP programmer.
Documentation not as rich as Java
Both Java and Scala have new challenges for a PHP programmer (JVM, new libraries, compiled language, statically typed).
I don't think Scala is a complicated beast, but you do need to understand some of the syntactic sugar and design principles, which would be true of learning Java as well.
Yes, if...
Strategic decision has been made to go with Scala
Company can handle the hit (financial and time) that will come from the steep learning curve.
No, if...
No senior Java, C# or C++ programmers can be put on the project too
Can't find a Scala programmer to act as a lead
Programmers don't have the patience to learn Scala or deal with a language where Jars (libraries) are scattered all over the place, rather than in one or two neat packages like PHP.
*Note: if the junior programmers were C++, C#, or Java Software Engineers rather than PHP, then my answer would be different like, Go for it!
I would not recommend it. My experience of Scala is only from homebrew projects, but I would imagine the currently lousy IDE support, quite frequent API changes and a very flexible syntax (that allows one to hang himself and everybody else participating in the project) would cause a lot of problems in a bigger, more official project.
Give them IntelliJ and throw 'em in the deep end.
Here is a blog post I recently stumbled upon:
http://james-iry.blogspot.com/2008/07/java-is-too-academic.html
It shows that even Java can be too academic to be understood by programmers which have no experience in functional programming. On the other hand, Scala allows to write code the "imperative way", so you can avoid all the FP stuff if you do not understand it. In my opinion, Scala is much more concise than Java, so I guess a "junior programmer" should be able to handle it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
For the next 3 years I will have to work with the JVM (project requirement) using a very specific third party API. They want Java but I've been given leeway to move away from Java. I was hoping we could move back to the .NET framework so I could develop code in F#, being absolutely in love with OCaml. .NET development has been struck down by our customer. It is a no go.
I've turned to looking, reading, and poking around programming blogs/forums trying to understand which language might appeal to me further: Scala or Clojure. Those seem to have the largest community/fan base. Being experienced with ML languages I see lots of people who compare Scala to ML. However, there are some real naysayers when making this comparison. If Scala was that close to ML my productivity and learning curve would benefit making this switch.
The internet is full of misinformation and wonder if I'm suffering from such. I don't like the syntax of Lisp (don't hurt me!) but if Scala has the warts I'm reading (poor IDE support, in flux Unit testing framework, performance issues) I'm wondering if Clojure is the better option. I want to be productive out of the gate, using functions as first class objects, and minimizing concurrency pain.
So anyways, before I spend too much time on the internet and not working... I'm stuck with the JVM, sick of Java and wondering where to go?
In my opinion, both Clojure and Scala don't have great IDE support, if that's really important to you. That said, here's what I can collect from my reading & experience.
Scala's pros
Faster than Clojure thanks to more static typing
Closer to ML (syntax, type-directed programming)
Bigger standard API (Clojure's APIs grow very slowly, because they want to make sure they find the best idioms before making them public. That said, Clojure still has semi-official supplementary APIs)
Better integration practices with the typical Java toolset (Clojure is still making some choices, so less firmly established yet on this regard)
Older than Clojure (but Clojure is built on top of a very old and proven core: Lisp)
People say it has chances to reach mainstream, while they wouldn't say the same about Clojure
Clojure's pros
Incredibly easy, fast and right concurrency thanks to MVCC-based STM and other concurrency mechanisms
Immutability by default helps doing the right thing first
More stable standard API
When things change, usually you don't have to rewrite any existing code
(Scala's collections are being remade again for 2.8)
(I have also read somewhere that it's common knowledge that Scala's Actors implementation needs a rethinking and rewrite.)
Easier to learn (small language, being a (very-clean) Lisp)
An opportunity for you to grow by learning something different
Clojure's performance will only get better with time; there's still room for nice optimizations in the compiler
Scala's tying to Java feels more limiting than Clojure's (interactions between Scala's and Java's static type systems). One could sometimes say the same about Clojure (Object-Orientation's support is not a 1:1 fit, but support for this will soon get better)
Rich Hickey has a gift for making choices that put Clojure in the position of having technical leading features that will be adopted by other languages in the decades to follow. And he also has a gift for explaining them. So use them today in Clojure, or wait to use them in another language in some number of years. :)
On distributed concurrency
If your concurrency needs are distributed, Clojure doesn't yet have anything for this unless you run it on top of Terracotta or something similar, in which case you'll be able to use all its concurrency features. If you do, you will end up with a better distributed concurrency experience than with Scala's Actors, IMO.
Conclusion
IMO Scala tries to do everything, and succeeds at doing most of it. Clojure doesn't try the same thing, but what it focuses on is more than enough and succeeds so well that most people really knowing Clojure wouldn't want to go back to something else. Disclosure: my personal preference goes, of course, to Clojure. I hope I've been able to be objective in what I wrote.
Have you considered Groovy? I don't think it is quite as functional as Scala/Clojure, but it's certainly a lot more functional than Java**. In general, I can get the same work done in Groovy with about 50% of the code it would take me in Java.
This is because Groovy is syntactically similar to Java and provides seamless access to the JDK libraries, but the addition of a lot of language features (closures, meta-programming, properties) and dynamic typing eliminates almost all the boilerplate associated with Java programming.
** I mean functional in the sense of 'functional programming' rather than 'working correctly'
I'll address the points you raised about Scala.
IDE support:
Scala doesn't have the same level or IDE support Java has -- or, for that matter, that F# should have with VS10.
That said, it has one of the best (maybe even the best?) IDE supports on JVM, outside Java. Right now NetBeans is good enough, and people have consistently said IDEA is still better (hearsay). The Eclipse plugin is unstable though.
But you mentioned a 3-years range, and the IDE support for Scala should be greatly enhanced once Scala 2.8 is out, as it will provide some compiler-support for IDEs. There's no release date defined, but it looks to be within the next six months, maybe three. And the Eclipse plugin will be updated right along with it.
In flux unit testing framework:
Yes, if you meant it is vibrant, evolving and well supported, instead of stagnant and abandoned. ScalaTest, Specs and ScalaCheck are top quality frameworks, compatible between themselves, and compatible with other Java frameworks and libraries, such as JUnit and JMock.
The testing frameworks, in fact, are almost a child poster of what is possible with Scala.
EDIT: Scala has basic unit test support in its standard library (scala.testing.SUnit). However, given that many superior, actively-supported and free alternatives have appeared, this has been deprecated and will likely not be part of the library shipped with Scala 2.8.
Performance issues:
I'm unaware of any, aside from the fact that you can write lousy code, just as with any other language. People not used to functional programming will often do stuff that's not efficient, such as not using tail recursion, or concatenating lists, and the paradigm shift that Scala enables brings that to light.
At any rate, you can write Scala code as fast as Java code (even faster with some upcoming features). And you can write Scala code with functional features almost as fast as Java code.
Quite frankly, get another job.
If you are to spend the next three years feeling uncomfortable on what you're doing, you should consider looking for more attractive alternatives.
Even if you manage to get a language you like, if you are part of a team ( which I guess you are ) the rest of the team might not like that language. If the rest of them code in Java and you in "fill in the blank" programming language, then problems may arise.
It is not that bad after all.
Talk with your boss, let him know how do you feel. Start looking for alternatives and have a nice and professional "leave".
There is no reason why you can't still have a good relationship with your current boss. If eventually they have a new project for .net you may come back. Talk about that also with them. Leave your doors open.
Its not really a zero sum game, learn them all!
ps: i vote for Clojure, i find it the most fun!
You should consider yourself lucky that you can use the JVM, because the JVM is becoming more and more popular for alternative programming languages than Java.
Besides Java there's Groovy, Scala, Clojure (a Lisp dialect on the JVM), JRuby (Ruby on the JVM), Jython (Python on the JVM), Jaskell (Haskell on the JVM), Fan (runs on the JVM as well as the .NET CLR) and lots more, and there's also an OCaml-Java, OCaml that runs on the JVM.
So, there's lots of choice in programming languages on the JVM, from purely functional to simple scripting and anvanced OO languages.
Tool support for Scala and Clojure may be immature, but it's steadily improving.
Since you like F#, then Scala is most likely your best bet. I say try it out and form your own opinion - you might find that the things people gripe about are things that don't matter to you, or things you can work around.
Don't forget jRuby, and note that an IDE is optional for non-Java
I think you have a great situation. How many people get permission to choose the implementation language? With everything available for the JVM having your environment chosen is not much of a restriction.
You won't need great IDE support in the less verbose languages
In a language as powerful as Ruby with no type declarations, you don't need an IDE at all
Scala was developed specifically to cure the verbose-java-blues
Count yourself lucky that you have three years of work lined up :-)
Clojure might be fun and provides functional concurrency-safe design patterns
Noop? http://code.google.com/p/noop/ (experimental though)
In terms of IDE support and other doubts you're having, Clojure doesn't do any better than Scala. And for a person with ML/F# background (or generally that in strictly, statically typed FP languages), you'll definitely find Scala much closer to what you're used to.
If you like ML you might like CAL which is more-or-less Haskell 98 for the JVM.
It is high quality and very stable, and has good IDE support on Eclipse, but sadly is no longer under active development.