The world is split I assume between the "new wave" which prefer vim, textmate over eclipse / aptana / vstudio, prefer linux/Mac over windows, prefer dynamic and functional over static and object oriented, prefer git over svn, and prefer fun startups over gray enterprises, and I can't blame them.
However, as much as it may surprise, most developers of this world, as much as they would like to work in a startup, work in a gray, corporate enterprise, write Java, Spring and Hibernate, or .NET, and have no clue about anything beyond that.
Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone.
There are many Enterprise developers who are amazing developers and architects, and can benefit any startup, the more they get close to newer "trends" the more likely the connection will happen.
Young startups will benefit, 40+ enterprise Java architects will benefit, and perhaps the talent wars will have a cease fire.
I'm pushing everyone I know to take a look at Scala, it's here to stay, and if you take a look at play framework, it's looking even more like the next big thing.
It all comes down to the community, if the ruby / rails community will be scala / play friendly, and endorse it as a "ok it's Java but we hate it less", it will help it take off.
As an enterprise developer, I really need something like scala / play to take off, as I won't be able to get ruby on rails / django in the same way I could get play / lift. as much as I think they are great frameworks, it's hard to sell to the enterprise crowd.
I don't understand what you've said here. The two terms are entirely orthogonal. There are functional langauges which are dynamically "typed", and there are functional languages which are statically typed. Lumping the two terms together is misleading and useless.
Static typing (done correctly) is just straight up better than dynamic typing. End sentence. I cannot count the number of times I have had errors at runtime working in python that simply would not have existed at all if I was using a statically typed language. With a sufficiently expressive type system, the types do not get in the way, but you still get compile-time enforced correct static semantics.
I agree. Static typing is great. I don't know why all these scripting languages choose to throw out static typing. If a variable is always going to be an integer I don't know why its important to be able to stick characters, strings or objects into it without seeing any errors. It's good for a beginning programmer perhaps, but even with that I tend to disagree since it encourages bad practices.
At some point I just got tired of seeing the same types of errors and wanted my tools to work a lot better. Python / PHP / Ruby aren't improved by lacking static types. How hard would it be to add static types into PHP, Ruby, or Python?
I'm a big static typing fan, but the facts are out there, startups use Rails and Django, and front end is JavaScript, all are dynamically typed, yet very popular.
A good static typed language that the only difference between it and Ruby / Python is the type system, has a good chance in being accepted by a larger audience of developers, both enterprise and startups.
People prefer dynamic as they don't like to compile, and it provides rapid code / refresh cycles, I don't think anyone would say no to less bugs and better refactoring, and to self explanatory APIs using content assist.
I meant to say "more inclined toward dynamic over static, functional over object oriented." didn't mean to tie functional and dynamic together, thanks for the clarification.
Scala is a great statically typed functional, object oriented language, which allows most people to enjoy both worlds.
Haskell and SML both have sufficiently expressive type systems that I do not ever find myself writing correct code that fails to typecheck. If the code fails to typecheck, I have done something wrong.
(If the code does typecheck, then I have guaranteed a lot of static properties of my code, but it may still be incorrect in terms of dynamic semantics.)
I'm using eclipse, and I can't leave my IDE, but I admire people who managed to free themselves from being dependent on an IDE, autocomplete / content assist. I tried VIM / Emacs / TextMate, didn't work for me, but perhaps I'm too old for new tricks, and already hooked to eclipse's shortcuts (ctrl+1 has no equivalent, I hardly need to write code, it's 50% shortcuts) I did like SublimeText 2, and use it for sass / scss / CoffeeScript and node development.
No parody was intended, I have all respect to all developers where ever they are and what ever IDE / non-IDE they chose to work with.
> Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land.
rpearl already made a similar objection, but I think you're confusing things a bit here. How much of Scala is influenced by Ruby and Python? Aren't the main goodies in Scala related to the type system?
Programmers using those "mainstream" dynamically typed languages don't have terribly much to be smug about, sure they're less verbose than Java, but I'd suggest they should also invest in learning a functional language or two, like Scala.
It's kind of interesting to see that the myth that functional and object-oriented programming are somehow mutually antagonistic is so readily accepted that it can even be perpetuated in an ode to an object-oriented functional language such as Scala.
"Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone."
Groovy does the same thing with less friction and switching overhead.
Nanana... I know both, and Scala and Groovy are complety different tools
Groovy is great to Websites and fast development they remove the code complexity and verbosity of java using type inference, some functional goodies like closures and add DSL capabilities,I use it everyday and it's a very nice tool.
Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example) and is way closer to the functional paradigm than Groovy, but it's more complex.
So you gotta choose wisely so you don't end up with the hammer to a screw kind of problem.
My view:
Groovy is for fast development and WEB stuff mainly because of Grails which is an awesome tool as well.
Scala is more a backend tool when you need Horse Power, but that's because the lang is more complex, I don't like Play and Lift is not as easy to understand as Grails.
> Scala is another kind of tool, it also does type inference and add functional goodies and support DSL BUT it have a deep love to parallelism (actors and non mutable objects as an example)
I believe Groovy also supports actor concurrency via gPars. That said, I still haven't seen anything like Akka on any other language, specifically its distributed processing p2p feature. To me Akka is Scala's 'killer app'. I agree I don't like the new Play framework. I didn't mind the magic being taken away but with taking the magic out, they also killed any form of convenience without providing a replacement.
" I stil haven't seen anything like Akka on any other language".
You can use Akka from java but the messages are effectively dynamically typed which isn't a big deal. However, as Rich Hickey said, a queue is simpler than an actor (Go understands this also). Java has excellent blocking queue implementations. In fact java has libs that support all kinds of concurrent solutions and they are not that complex.
I still like Scala though (and really like Go but my work is on the jvm)
I like Groovy, but I think even the author said once that if he knew about scala, he might have not invented Groovy (if anyone knows the link to the quote, and if it's indeed true, please comment)
It was James Strachan who said that. He is credited with the initial idea and set the project in motion in 2004. He stopped commiting in 2005 and Groovy 1.0 was released in 2007.
He made the scala statement in 2009. He's certainly entitled to his opinion. But I find the title "Author" or "Creator" a little harsh to people like Guillaume Laforge and others who have really brought the project from beta to 2.0 in the 7 years since he quit.
James Strachan set the Groovy project in motion in mid-2003, not 2004. He stopped posting to the mailing list in December 2005. James credits Bob McWhirter as being his co-creator.
Jochen Theodorou led the technical effort on Groovy since then. Other major committers over the last 5 years include Paul King, Alex Tkachman, Cedric Champeau, and Jeremy Rayner. I don't know for sure about before that. Guillaume Laforge's main technical effort was writing some utility functions very early on.
Although Guillaume has the title "Project Manager", he's really No.2 to the real management force behind Groovy, i.e. Graeme Rocher, who leads the Grails development. If Grails switched languages, Groovy would disappear almost overnight as it's not used much in anything else significant. OReilly's total worldwide book sales of Groovy (all titles) over 12 months is 1205 books (http://radar.oreilly.com/2012/04/computer-book-market-2011-p...).
> really brought the project from beta to 2.0 in the 7 years since
A few weeks before Groovy 2.0's "final release" in June this year, Grales 2.1, Griffon 1.0 and Gradle 1.0 were all released, bundling Groovy 1.8. Listen to what Groovy's users are doing, not what its fanboys are saying. Groovy 2.0 is nothing more than beta-quality software offered to production users so they'll "unit test" it in their workplaces. No-one should be using Groovy 2.x until Grails bundles it.
"Groovy 2.0 is nothing more than beta-quality software offered to production users"
Unlike, of course, every other piece of software's x.0 release, which are always 110% battle hardened and tested through years of rigorous process, ensuring no downtime, data loss or corruption, and smooth sailing. Yea, groovy's totally unique in that. I bet they just made some random commits during the final 2.0 bundling without even looking at the keyboard while they typed as well.
Groovy book sales were down. So what? Maybe groovymag has had an adverse impact on oreilly? :)
When Groovy's two biggest users (i.e. Grails and Gradle) each release a major point version (Grails 2.1 and Gradle 1.0) less than a month before Groovy 2.0's release, that says more about what their project managers think about Groovy 2.0's production-readiness than anything they or anyone else might say.
Groovy 2.0 bundles two jars, one for Groovy scripts using Java 7's invoke-dynamic, the other for scripts using type-checking and static compilation available via optional annotations. Invoke-dynamic and type-checking/compilation _can't_ be used together: you need to choose only one jar to use. The roadmap plan is for them to be merged together in Groovy 2.1. Groovy 2.0 should never have been released until it was a single functioning jar.
I don't see the lack of faith thing as much as you. I see it as the features those projects have been working on don't rely on any Groovy 2.0 functionality, so they'll push it out sooner and give people more functionality in those projects now, and explore the impact on Groovy2 on their respective projects after it's release and shakes out.
Yes I am. To the extent I have a vested interest in Groovy, it may or may not be relevant to my original post. My larger point was, as I said before, if the purpose is to offer a 'taste' of dynamic functionality, a la ruby/python, to Java developers, Groovy is a much simpler way to go about it. Should people then get a real hankering for it, you've got more options, either with more groovy, or jruby or jython or scala or what have you. Nothing more.
No, but having young fresh out of college developers prefer it over eclipse/VS, is new (to me), but I have a very narrow point of view of only the people I know from college / work / online.
However, as much as it may surprise, most developers of this world, as much as they would like to work in a startup, work in a gray, corporate enterprise, write Java, Spring and Hibernate, or .NET, and have no clue about anything beyond that.
Scala does a wonderful thing, it allows enterprise developers to taste some of the goodies of Ruby / Python but stay in static Java land. which is great news for everyone.
There are many Enterprise developers who are amazing developers and architects, and can benefit any startup, the more they get close to newer "trends" the more likely the connection will happen.
Young startups will benefit, 40+ enterprise Java architects will benefit, and perhaps the talent wars will have a cease fire.
I'm pushing everyone I know to take a look at Scala, it's here to stay, and if you take a look at play framework, it's looking even more like the next big thing.
It all comes down to the community, if the ruby / rails community will be scala / play friendly, and endorse it as a "ok it's Java but we hate it less", it will help it take off.
As an enterprise developer, I really need something like scala / play to take off, as I won't be able to get ruby on rails / django in the same way I could get play / lift. as much as I think they are great frameworks, it's hard to sell to the enterprise crowd.