Ruby, and Rails was so 2005, at least for some :)
People are on the look out for the next big thing, and the alphadevs are all sniffing around the Functional. Scala, Haskell, OCaml, Erlang, ML, F#, Fortree, Lisp, Clojure, it keeps on going.
Is one of this crowd going to make a break for it?
Stuart Halloway has the knack of being ahead of the curve. He has been getting into Clojure, so much so that he is writing / porting a lot of work to it.
Bruce Tate likes it too, saying:
Functional programming that’s optimized for concurrency like Erlang, fast and type safe like ML, allows persistent data structures like OO, but with immutability.
For more, Stu shared some talks given by the Clojure creator Rich Hickey.
Stu has also been thinking about the next thing in the abstract too, as has Mr Polyglot Ola Bini.
Ola does a good job at splitting up some ideas:
- Better implementation techniques. V8 is an example of this, and so is Hotspot. V8 employs new techniques to drive innovation further, while Hotspot’s engineers continuously adds both old and new techniques to their tool box.
- DSLs. The focus by some people on domain specific languages seem to be part of the larger focus on languages as an important tool.
- Functional semantics. Erik Meijers keynote was the largest push in this direction, although many languages keep adding features that make it easier to work in a functional style. Clojure is one of the new languages that come from this point, and so is Scala. The focus on concurrency generally lead people to the conclusion that a more functional style is necessary. From the concurrency aspect we get the recent focus on Erlang. Fortress also seems to be mostly in this category.
- Static typing. Scala and Haskell are probably the most representative of this approach, in trying to stretch static typing as far as possible to improve both the programmer experience, semantics and performance.
It feels like we are very much living in the land of theory these days. It is easy for us to play though. Many of the languages are on the JVM, so if you are a Java chap who doesn’t fancy the language quite so much these days, you can still play relatively nice.
The theorists wax about how we need to get back to proofs as the only way to scale in two ways: maintainability of a large code base, and for scalable performance (make life easy for MapReduce).
In my gut, I get it. Part of me wants to spend a bunch of time playing with all of these languages.
However, the other side of the brain is cautious. I used to use a little Perl Web framework that I wrote back in the day. I would tweak it for my needs, and knew every line of code. As other developers joined the company, they would extend it for our general desires too. If I had never jumped over to Java (and the many frameworks) and then even Rails, would I REALLY not be more productive?
There has to be a real reason to jump onto something else. I then take Ajax into consideration, and the fact that I spend more and more time thinking about my JavaScript architecture for an application. The balance between server side code and client side ebbs and flows, and feels like an art to get right. Too heavy on the client, and then the server is just a dumb store that doesn’t even do secure validation. If you go the other way, and the server is doing way more than it needs too.
JavaScript is here to stay (at least for a good while). It has closures. With 3.1 and then really Harmony, it is going to get even nicer. But, even today, I actually quite like it, mainly thanks to the libraries that have made working with the DOM and browsers bearable.
Maybe server-side JavaScript is the answer, so you can stay in one world back to front (well, and of course HTML, and SQL, and …). Jaxer is doing a good job there. I am very closely watching to see if the community goes for it.
Web scale could cause a few changes, and Comet / messaging (one reason why Erlang is doing quite well), but even there you can get a LONG way with current technology, especially as they get their act together (e.g. Servlet spec update to codify the great work in Jetty).
Is there going to be a killer app out there in the near term for one of these languages? Will a Rails show up for Clojure? Regardless, I am going to enjoy watching Stu write and talk about it, as I always learn something from him :)
October 15th, 2008 at 10:06 am
Great post, I’ll look into some of these others that I haven’t heard of yet.
I think the web engineer’s toolbelt is going to look quite a bit different 5 from now than 2008 looked in 2003. There are so many new (and old) languages being popularized that are carving out little niches for themselves in web applications (thanks ajax) and it will be interesting to see which ones wins out. We’ve been getting by just fine using the current crop of languages in the post-ajax world, but I think we need to start seeing some languages designed with web “applications” in mind, not just ones designed for web “pages”.
October 15th, 2008 at 10:19 am
Clojure is definitely very cool, and I actually think it’s more likely to catch on than Scala. But I think there’s a key flaw that Clojure doesn’t address and Scala addresses only marginally better: functional programming in its current forms is usually “weird”.
Sure, there are lots of people who will make the claim that functional programming isn’t weird…but they’re usually weirdos.
Like Ola’s recent post about what programming paradigm best describes “real life”, I think a single-paradigm language is not going to cut it in a polyglot age. But I also don’t think a kitchen-sink language like Scala is every going to catch on either, since there’s just “too much” to absorb for average joes like myself. Honestly, though I like some of Scala and Clojure, they still don’t come close to my initial reaction to Ruby: “wow, I don’t even know this language and I understand all of it”.
I think what we really need is a Matz-like attention to syntax…a focus on the “feel” of a language *FIRST* and the backend details afterward. Clojure, like most of its functional bretheren, is a language wrapping a runtime, rather than a runtime built to support a language. Until we start to realize that programmers are the customers–not machines–we’re going to prefer languages like Ruby and Python, even if they’re slower, less concurrency-friendly, and harder to optimize…and we’re going to continue loving them.
October 15th, 2008 at 11:09 am
I definitely believe server-side JavaScript has a lot of potential, that is what I am betting on; there is a great advantage in being able to use a single language on the client and server. However, I believe that the optimum JavaScript server is one that will be “fit” (not too thin, not too small), and complement client side code well. Duplicating the browser environment on the server (as Jaxer does) leads to presentation layers on both the client and server, ironically this is actually the antithesis of Ajax. IMO, Ajax applications need a server that complements, focusing on data storage, data model coding, based on open standards of communication (no black boxing), and allowing the separation of presentation on the client from services provided from the backend. This is the future that I have been trying to aim for with Persevere. Of course I am plugging my project, but I really think Persevere takes the JS language to another level by integrating database schema with JavaScript typing, integrating object identity with RESTful URI, and integrating methods with standard JSON-RPC calls, with a consistency to the language/network/data model.
October 15th, 2008 at 11:29 am
People are so enthusiastic about Javascript.
Let me state that I think Javascript is the wrong solution. It is so extremely limited as a language. The ONLY reason it is a success was because the www is hugely important.
October 15th, 2008 at 11:40 am
I also think that Clojure needs a bit of syntax for the “normal” developer. Maybe a Dylan-esque like syntax could be skinned on top of Clojure.
October 15th, 2008 at 12:23 pm
My language, Kira, is being built around database scalability and bringing type safety to the web along with theorem proving. My goal is to have a language that makes working with the database trivial, safe for n00bs, and secure enough for a bank.
http://www.mathgladiator.com/projects/kira/
October 15th, 2008 at 12:41 pm
Dion,
I think that JS is a great server-side language too. Helps bridge the gap between client-side developers and server-side developers.
I work for a small NY-based startup – 10gen (http://www.10gencom) – and we have an open-source appserver that includes JavaScript as not only a first class citizen, but given our development history, really “first among equals”.
It’s not done – I think that we need to spend a bit of time working out the basic services that should be available in any server-side JavaScript app server, and some of our early decisions for how to handle extensibility and external modules are still worth reviewing – but there have been commercial sites running on it for over 6 months, so it’s clear that there is “there” there :)
Come try it. I hope we can get more people interested in server-side JavaScript in general. As a community, we need to create the same infrastructure and frameworks that other languages offer for web development.
geir
October 15th, 2008 at 12:59 pm
Charles,
Weird may be semi-pejorative (and weirdos definitely is). Unfamiliar is more accurate. When I was unfamiliar with Ruby, I found its syntax ‘weird’, too. In fact, after a while one tends to find all new languages’ syntax needlessly goofy and different – even Ruby’s.
There are many objective measures of syntax – how complex are the parsing rules, is there a lot of overloading of names or symbols, special cases, complex precedence or associativity rules, ties to an ornate type system or type hierarchy notions, context-sensitivity, verbosity, etc. Familiarity is one of the weaker measures, one that Ruby, too, fails for some programmers – it’s not like C/C++/Java. Arrows in hashes and end end end seem pretty tedious to me, but it’s subjective.
I strongly disagree that Ruby has some magical or superior attention to syntax. If you walked up to it and immediately understood it, it is likely because it was already pretty similar to something you already knew. People who already know a Lisp find Clojure immediately accessible too. It says more about the user than the language.
Clojure has a fraction of the syntax of Ruby, never mind Scala. Yes, it may be unfamiliar, but it will take only a few minutes to learn. And it has that great Lisp property – code is data, a property that cannot be properly valued by those who haven’t experienced its benefits. Virtually everyone who advocates that Lisp alter its syntax falls into that category. Clojure is most certainly not a language wrapping a runtime, but a set of core ideas that permeate the data structures, syntax and library.
Functional programming is unfamiliar for most. But what if saying x.name += “cowboy” is no longer a sustainable programming idiom in the face of concurrency? Should we still force languages to allow you to say that, in an effort to preserve familiarity? Languages with different programming models are bound to look different. If they were made to look the same it wouldn’t help things, as there’d be a conflict between the expectations generated by the syntax and the actual model. So if people are going to learn anything truly different from what they already know, they’ll have to deal with it being somewhat unfamiliar.
Towards that end, since it will be different, I’ve strived to make Clojure extremely simple. For people looking to learn functional programming I think they’ll find Clojure among the most approachable ways to do so, as the many Python and Ruby programmers who now grok Clojure will attest.
As far as programmers as customers – sure, but not all customers are the same. One typical customer of Clojure has used Java/C#/C++ for critical, multithreaded applications and would never consider Ruby or Python as appropriate, while envying their succinctness and flexibility. Another is a Ruby/Python programmer coming up against limitations and looking for more power.
Clojure will never be for everyone, but I think it fills a large empty cell in the power/flexibility/robustness matrix.
October 15th, 2008 at 1:12 pm
@mark: Just out of curiousity, what language(s) do you find less limiting than JS?
October 15th, 2008 at 1:48 pm
Some great comments here guys. Thanks.
It is interesting to see how there is a lot of effort on SSJS now (from Jaxer to 10gen to Kris Zyp’s work) as we work out how it makes sense for JS to be on the server.
Some really nice thoughts on Clojure and languages in general too. Fun times :)
October 15th, 2008 at 1:53 pm
I think the allusions to Scala’s complexity are greatly exaggerated. I just did a quick check: The antlr v3 ruby grammar comes in at 502 lines, while the Scala grammar in the official spec is 298 lines. We can quibble about details. But to express that Scala is a kitchen-sink language, in particular by comparison to Ruby, smacks a bit of FUD, in my opinion.
October 15th, 2008 at 1:56 pm
@mark: unless you explain what you think the extreme limits on JS are, we can’t tell whether you’re thinking about the limits that don’t exist or the limits that aren’t very important. (Or maybe you know something about the language I don’t, which is actually why I am hoping you will respond.)
October 15th, 2008 at 3:15 pm
First, let me say that I think the critical mass of usage on the web will make Javascript the next VB (help more people write more software) if not also the next trendy language.
The thing that leaves me flat about Javascript is my lack of understanding of the idioms and notation that would differentiate it from other curly-brace languages. I’m aware of function/object polymorphism and prototype-based versus class-based OO, but those things don’t feel as conceptually different and potentially useful as, e.g., Haskell’s referential transparency, type classes, monads, pattern matching, and lazy evaluation.
October 15th, 2008 at 4:24 pm
One of the problems with Javascript is the lack of a builtin package/module system for programming in the large. Now, after reading this sentence, about 100 people will hurry to quickly respond “yes, but isn’t it lovely that you can build one yourself!” That is true, and it is just as true that you can do amazing things with CPP, m4, and make for languages like C (the sendmail.cf m4 generation should be studied by future generations) However, the problem with this is two-fold:
1) everyone reinvents the wheel which produces friction when two separate library projects with two separate module systems may need to cooperate in maximum harmony
2) the lack of an early namespace binding mechanism inhibits static analysis tools that can be used to build efficient deployables. While V8, SFX, and TraceMonkey are making enormous leaps in runtime optimization, they can’t eliminate extra HTTP requests or prune dead code *before it is downloaded*. This means that packaging of large Javascript apps relies on one of three propositions: 1) load on demand/deferred loading, which can harm performance with excessive roundtrips and 2) manually tweaked build scripts with the human being playing the role of dead-code-eliminator. or 3) an idiomatic/library-proprietary-technique for module declarations that is parsed and dealth with using library specific tooling.
IMHO, they all fall short of having a first class module system as part of the specification that everyone can depend upon.
October 16th, 2008 at 3:49 am
The next big language is a parallel program-language that will take the place of both Java and C++. The NBL already exists. It’s called X10. Check it out: http://en.wikipedia.org/wiki/X10_(programming_language)
October 16th, 2008 at 9:41 am
James Gosling gave a talk on his history of designing languages and had a section on designing Java. The most interesting aspect of it, for me, was that he recognized if he made a language too far from what the masses used, that the language would not be successful (from a market perspective). I have always looked at the lack of success of FP languages in this way. If you are a C++ programmer, then Haskel (insert other FP language here) looks bizarre. Hell, you can even look at same-paradigm languages not getting uptake based on simple syntax decisions (Python comes to mind).
Clojure looks very nice to me, but I probably mildly fall under Charlies weirdo category. I suspect that FP’s success is largely going to be a set of steps in more familiar languages where is it keeps evolving towards the FP paradigm. This will allow those unfamiliar to be weened from their existing programming paradigm. So multi-paradigm languages will likely be the path to FP nirvana. Certainly at some point the massive parallelism of hardware architectures will drive this…
October 16th, 2008 at 9:44 am
I should jump back in and say I think Scala and Clojure are excellent languages; they’re both really cool, look like a lot of fun, and bring more diversity and new solutions to the PL world. My “weirdos” comment was intended to be tongue-in-cheek; I don’t think anyone would dispute FP has had a “weird” rap for a long time. I personally believe FP holds the one true answer to the impending concurrency crisis, be it through Scala or Clojure or Something Else. I also dispute the idea that grammar complexity is an evil. Ruby’s grammar could be the most complex thing in the world; it wouldn’t mean it’s somehow less intuitive or less beautiful. Eventually we’re going to find some middle ground between languages like Ruby and languages like Clojure and Scala, and that will be a great day indeed. For now, none of the current languages is NBL by definition, because there *will be no NBL*, at least not by any definition of NBL that I’ve seen. That meme needs to die a horrible flaming death.
Let’s say it like it is: The Next Big Language is the one you use tomorrow to do real work, whatever language it might be. Use it, love it, and tell others about it. Diversity is king.
October 18th, 2008 at 10:16 pm
All these java.next languages ultimately look too “ugly” to me. Although I’d jump at a chance to use them instead of Java.
I believe Python is winning people over to a beautiful, clean way of writing code. It *did* used to look offputtingly weird to those who were used to C/C++/Java. And lots of people were scared by the meaningful whitespace indentation. But now there are enough new programmers learning it as their first language that those prejudices are dying out. And so …
… if we really care about nice, clean syntax AND functional power. The obvious way to go is Haskell ;-)
I predict that in five years time, the hot language will either be a version of Python which has adopted ideas (Pattern matching arguments, Monads, immutability etc.) from Haskell; or a Haskell-like language which has borrowed some syntactic sugar from Python. Python is a better gateway drug to FP than, say, Ruby because Ruby tends to focus on using Smalltalk-like blocks whereas Python uses comprehensions and higher-order functions.
It may, of course, still run on the JVM and call into Java libraries.
October 19th, 2008 at 3:04 pm
Yeah, I must admit that Python’s syntax grew on me. My initial reaction was “semantically meaningful whitespace? You’ve got to be kidding” But over time, I noticed when glaring at code for the first time, there was something aesthetically appealing about it, less cluttered look.
I really like Scala, but if you look at some hefty apps like LiftWeb stuff, it’s not pretty. I think Haskell got it right by allowing people the choice between syntax based blocks, and layout based blocks.
Human beings possess both powerful linguistic capability as well as powerful spatial-visual capabilities, so why not create a language that leverages both? YML is another example about how the same information can be visually dense and immediately comprehensible vs the equivalent information encoded as XML or S-expressions.
March 20th, 2010 at 1:51 am
Okay I know it’s pretty obscure and everything but I would love for Euphoria to take the place as the next big thing! It’s got C syntax, it’s cross platform, it has a translator to C, garbage handling, a database system, and it can be used for CGI programing.
Plus I always cheer for the underdog, and you can’t get much more underdog then Euphoria http://www.rapideuphoria.com/