Comments on: The next big language; Theory, practice, and the killer app http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app blogging about life, the universe, and everything tech Sat, 08 Sep 2012 07:06:53 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: Jon http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-46338 Jon Sat, 20 Mar 2010 08:51:30 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-46338 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/ 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/

]]> By: Ray Cromwell http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39768 Ray Cromwell Sun, 19 Oct 2008 22:04:18 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39768 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. 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.

]]> By: phil jones http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39763 phil jones Sun, 19 Oct 2008 05:16:37 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39763 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. 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.

]]> By: Charles Oliver Nutter http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39757 Charles Oliver Nutter Thu, 16 Oct 2008 16:44:45 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39757 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. 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.

]]> By: Thomas Enebo http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39756 Thomas Enebo Thu, 16 Oct 2008 16:41:48 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39756 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... 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…

]]> By: Uli W. http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39755 Uli W. Thu, 16 Oct 2008 10:49:39 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39755 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) 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)

]]> By: Ray Cromwell http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39750 Ray Cromwell Wed, 15 Oct 2008 23:24:15 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39750 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. 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.

]]> By: Paul Brown http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39749 Paul Brown Wed, 15 Oct 2008 22:15:02 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39749 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. 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.

]]> By: Kragen Javier Sitaker http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39748 Kragen Javier Sitaker Wed, 15 Oct 2008 20:56:25 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39748 @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.) @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.)

]]> By: Martin Odersky http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app/comment-page-1#comment-39747 Martin Odersky Wed, 15 Oct 2008 20:53:20 +0000 http://almaer.com/blog/the-next-big-language-theory-practice-and-the-killer-app#comment-39747 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. 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.

]]>