8 ms·

Modern Language Wishlist

98 points by pchristensen 15y ago

ryanmolden 15y ago
This just seems like an everything and the kitchen sink list. I am not convinced supporting every possible use case leads to an approachable/efficient language. It seems akin to arguing my car should also be a boat and an airplane.
- jbrennan 15y ago
  I think it's OK because he said >(plus libraries) So some of this would belong as a language feature and other stuff would be in the standard library (is what I'm imagining at least). I'm a Cocoa guy, and when a lot of people rave about Objective-C, they usually are referring to niceties Cocoa provides. This is sort of what I was imagining as I read along.
- gbog 15y ago
  How far is Python from this list? Macros are missing but the remaining list seem close to me.
  - tomp 15y ago
    Math sucks a lot in Python 2.7: 3 / 2 == 1 Python 3 fixes that, thou, but still it uses floating point numbers instead of rational numbers.
    - emillon 15y ago
      There "from __future__ import division" to fix that.
    - lloeki 15y ago
      > it uses floating point numbers instead of rational numbers. import decimal import fractions
- andrewflnr 15y ago
  It's a heck of a mixed bag, but most of them are orthogonal and would coexist nicely, especially if libraries are allowed to seriously extend the syntax and type system. Seems hard but doable to me.
highwind81 15y ago
This list is more about default library a language should come with rather than language design.
Alind 15y ago
The more I read this article , the more I feel he is not talking about _language_. He is talking about _library_.
- genbattle 15y ago
  Yea he mentions language features like interface-based polymophism, garbage collection, namespaces, first class functions, closures, etc. But then he goes on to talk about I/O methods, string manipulation, CSV output, etc. By which I think he means standard library features. The post really should have been split into language features + standard library features to make it clearer. I may be influenced by the fact i'm into Go at the moment, but i think it covers most of the "features" he talks about, as well as many of the "libraries" (some may not be part of the standard library, but will be available through 3rd party packages). If the author is reading this, I encourage him to have a good honest look at http://golang.org/ http://golang.org/ I don't know if i like his discussion of "math-oriented types" vs. "machine-oriented types". At least as far as I see it (and according to wikipedia[1]), in maths whole integers (Z) are a subset of rational numbers (Q). When in your high-school maths class you say 3 + 2.5 = 5.5, you're really doing an implicit conversion to 3.0 + 2.5 = 5.5 or 3/1 + 5/2 = 11/2. Most languages allow you to also get rid of the bit-size of numbers by just defining "int" or "float" numbers that default to some predetermined bit-width (e.g. 32-bit). Most languages also have libraries or mechanisms (see Go and Python) for large precision numerical calculation so you can have your theoretically infinite size "no-overflow" situation; but that comes at the cost of speed, so we only use these types when it is specifically needed. It's not impossible to use them in all cases, but it is impractical. In the end, a language can't do everything. Most languages focus on providing a good core, along with mechanism for users to extend functionality in any way they see fit. In this case I think the author wants the language to just do everything for him out of the box, without any pesky libraries, and without being bloated or slow. _That_ most certainly _is_ impossible. There is a good reason why no language implements _all_ of these "features". [1] http://en.wikipedia.org/wiki/Set_(mathematics) http://en.wikipedia.org/wiki/Set_(mathematics) Ed: Z is a subset of Q.
  - jacques_chester 15y ago
ww520 15y ago
I am surprised it's not very Lisp-biased. Anyway, no love for type inference or generic?
- baddox 15y ago
  Except for homoiconicity.
  - gecko 15y ago
    Tcl, Forth, Io, and (traditional) Smalltalk are also all homoiconic. You don't have to have a Lisp to get there.
dman 15y ago
Is it just me or did anyone else feel he was talking about Racket? I have never understood why Racket doesnt get the love that it deserves.
- errnoh 15y ago
  Is it just me or did anyone else feel he was talking about Go? I have never understood why Go doesnt get the love that it deserves. (No seriously, he described Go)
  - laktek 15y ago
    Absolutely, that was the first impression I also got when reading the post. Actually, its Go's standard packages which matches most of these expectations.
  - genbattle 15y ago
    I also had the same weird feeling (see my post elsewhere in the thread). I think Go's just still too immature for most people to invest deeply in. Production code can have a lifespan measured in years or even decades, so you want to use a language that's stable and mature, and you want to know that it's going to be around at least as long as your application. Things will change once the 1.0 Stable release rolls around, and people will really start dipping their feet in (and those people who have been dipping their feet might take a dive).
    - errnoh 15y ago
      Yeah. And of course Go doesn't satisfy everything on that list either. But it does satisfy most of it with just the standard library. Go 1 should solve most of the big problems, currently libraries need to keep up with weekly releases and packages are still being moved around.
  - rsanders 15y ago
    This doesn't sound like Go to me, but I've never used it: Homoiconic Code can be manipulated as data. Extensible syntax I find I don't use macros much anymore. I do more with data-oriented programming. But it is nice to have when you need it.
shubber 15y ago
Wrong: first item should be environments as first class types. Much of the rest follows. And you can stick it to smarmy common lisp geeks.
- jballanc 15y ago
  This post does a really good job of analyzing first-class environments and explaining why "first-class environments are useless at best, and dangerous at worst": http://funcall.blogspot.com/2009/09/first-class-environments.html http://funcall.blogspot.com/2009/09/first-class-environments...
  - pnathan 15y ago
    I found his argument a bit of a wash. It boiled down to usual critique of macros, operator overloading, and inheritance: "You don't know what's going to happen". Meh, most of the time it's not a problem, when it is, it's for a good reason, and if it's for a bad reason, you probably should choose a different software package that is written better.
slyall 15y ago
The most obvious thing I can see that he wasn't explicit about was Unicode support. Should be native, just work and included from day one.
- ericn 15y ago
  Good one.
Mikera 15y ago
This is basically a desciption of Clojure, in particular: - Explicit model of time (http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich...) - Homoiconic / Extensible syntax (shared by most Lisps) - Math-oriented numeric types (Clojure maths is arbitrary precision by default, and it has nice things like rational types) - Immutable (Clojure data structures are all immutable) - Garbage collection (inherited from the JVM) - String manipulation (Regular expressions are a built-in type) Most of the other features actually seem more like libraries than language features, but given that Clojure can access the entire Java ecosystem I think you can do all of it from Clojure with relatively little pain.
- jsankey 15y ago
  Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.
  - michaelochurch 15y ago
    I find it interesting that two of the most exciting languages that exist right now are built on top of the VM for one of the worst ones.
    - jsankey 15y ago
      The strength of Java for many years has been the platform, and indeed the surrounding ecosystem, not the language. In that sense it's no surprise that there is a lot of effort going in to providing better languages on that platform.
      - exDM69 15y ago
        The reason I'm not using Clojure is that it's based on the Java platform. I keep hearing that JVM is nice because there are good libraries, but I haven't figured out what the good libraries are. Sure, there are some nice platform independent abstractions for common operating system interfaces like file and network I/O, but it still lacks lots of stuff. The problem with Java libraries w.r.t. modern high level languages is that Java libraries are built on Java abstractions. It doesn't matter how high level the new language is, but when interfacing with Java libs, you have to stick to single dispatch object oriented programming. So in the end, there are many cases where you use the Java library through some wrapper layer written in Clojure or your Clojure code ends up looking a lot like Java. Once you add a wrapper layer shim between your preferred language and the platform, it doesn't matter what's underneath. That's why I like to stick to languages that are built on native code and libraries, C and Posix and Unix API's with some Linux and/or BSD additions. Of course, if you want to run on Windows, all the code has to be duplicated since Win API's are different.
ggchappell 15y ago
I'll add one that people don't seem to think about much: the ability to encapsulate an ongoing computation and grab new values from it at leisure. Examples: Haskell has lazy lists; Python has generators; Unix shells have pipes; in Go you can whip this up pretty easily with a goroutine and a channel; etc. Does his ideal language allow for this?
- ericn 15y ago
  I should add controlled laziness to the list.
chops 15y ago
If you're going to throw everything and the kitchen sink in a language, you may as well include Erlang-type multiprocessing and message passing.
Dn_Ab 15y ago
Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible computing. I don't know how practical that is though. Anyways I've separated out the parts of the list which I think are less common. And listed examples off the top of my head so by no means is the below meant to be exhaustive. The uncommon ones: * Units - F# and Frink * homoiconicity - Lisps, Prolog, Io, Factor, Pure?, ... * macros and extensible syntax - the above list, Nemerle, Dylan * Unification - Prolog, Mercury - logic languages. anyone with type inference. anyone with predicate dispatch, a full example of which I do not know. F# Active patterns and scala extractors are close. * Error (managing numeric Imprecision) - Best I can understand I can only note that I have seen people treat similar concepts with monads. So haskell and any language which allows easy monads. So scala, f#, haskell, clojure, nemerle * Math types - Axiom/Aldor. To an extent, dependently typed languages - not practical. yet? * Polymorphism - Although it sounds more like structural typing. So OCaml, Scala. Also F#, haskell partially. * Aspects - Metaprogramming makes this relatively easy and clean to implement. so anyone with macros too. Arguably, monads are another way to follow the same philosophy. * term rewriting - not common, very niche and not mentioned, but pure-lang allows this and for abstract math programming it is a really fun & powerful concept. * pluggable types - F# has this as type providers. Gosu open types. I have used it in F#. At a start, it is a very awesome way to consume an api. Less Uncommon: * pattern matching - most functional languages. to a small extent the java.nexts * Immutable values - most functional languages * Parser - parser combinators or any language which implements PEGs e.g. Nemerle * Design by contract - eiffel and as a library in most languages * laziness - the usual functional suspects.
- smcj 15y ago
  Great overview, thanks! I added some new stuff to my reading list. :-) Just some notes from a Scala user: Regarding Units: I bundled some work done before by other people into a nicer package/syntax, apart from a few missing bits working with Units looks quite nicely in Scala, even without any special support for it: val mass: Mass[Double] = 4.0 kg val longMass: Mass[Long] = mass asLong val length: Length[Int] = (5 m) * 3 val time: Time[Int] = 1 s val doubleTime: Time[Int] = time + time val temp: Temperature[BigDecimal] = BigDecimal("22.22") k val speed: Speed[Int] = length / time val area: Area[Int] = length * length val volume: Volume[Int] = (23 m) * (1 m) * (1 m) val smallVolume: Volume[Double] = (volume asDouble) / 12.0 val area2: Area[Int] = volume / (23 m) val accel: Acceleration[Double] = (10.0 m) / ((2.0 s) * (1.0 s)) val accelNum: Double = accel toDouble The type annotations are not needed, but helps undestanding the design. Scala will very likely get macros in the next version, together with pluggable types/type providers. Macros not in a Lisp or "extend syntax" sense, but more in a Nemerle sense. Scala macros are written in fully statically typed Scala and are checked at compile time before and after expansion.
michaelochurch 15y ago
Clojure and Scala are both there, except on idiomatic libraries (you might have to use Java libraries). Clojure wins on simplicity of syntax (Scala has a rule that operators ending with ':' associated to the right, which makes an incredible amount of sense once you understand the language but is annoying and arbitrary to beginners) and homoiconicity. Scala wins on pattern matching and robustness (static typing). I'd use Scala for a game, because it's fast (both in terms of human and CPU performance). Both are great languages.
- nickik 15y ago
  Because Clojure is a Lisp we have macros and with macros comes a lot of power. Clojure has a full powered pattern matching library. See this: https://github.com/clojure/core.match https://github.com/clojure/core.match
jhancock 15y ago
All I want: Smalltalk with tail recursion and a process model like erlang (implies immutable values).
akoumjian 15y ago
http://colinm.org/language_checklist.html http://colinm.org/language_checklist.html This has never been more relevant.
Gotttzsche 15y ago
hmm, what exactly does he mean by data-oriented programming? iirc that's something where you don't store data chopped up into objects, but have arrays that keep all the data of one "aspect" of all "objects"... or something like that. something game programmers would use, helps avoid cache misses. is that what he was talking about? if so, what does it have to do with macros?
- ericn 15y ago
  I meant data-driven programming. http://www.faqs.org/docs/artu/ch09s01.html http://www.faqs.org/docs/artu/ch09s01.html More data (and data structures) and less code. It's very common in Lisps and other homo-iconic languages.
  - Gotttzsche 15y ago
    thanks :)
apgwoz 15y ago
Yet, no mention of concurrency/parallelism primitives. sigh
- ericn 15y ago
  Good idea. But they do kind of fall under a "model of time."
  - apgwoz 15y ago
    In fact, the article does mention concurrency in there. I must have read over that thinking right away that they meant UTC/ Time Zone issues again. d'oh!
ajuc 15y ago
+ 1 for easy serialization. Every language should have equivalent of Python pickle module. Sometimes you need specific file format, compatibility between languages, customization, etc - then pickle is not enough. But for my uses pickle was good enough most of the time, and it's stupidly easy to use. No need to change your code in any way. That makes one-off cashing of intermediate results to file system manageable, implementing save/load game is 3 lines of code (counting import). I love it, and I miss it in every other language I use. Javascript has JSON, but writing general code to serialize arbitrary object graph with cycles, functions as field values, properly storing prototype chains, etc is still hard.
webreac 15y ago
First need of a good language: have a simple specification. The full reference manual shall be very concise, complete and readable. Even with a language as simple as javascript, the specification is a nightmare.
jwarzech 15y ago
One thing that always bugs me is that modern languages that ship with fairly strong datetime libraries still make it a pain to deal with just dates. My db can handle just a date why does my language need to treat date as some hack on datetime? I want 12/01/1980 not 12/01/1980 00:00:00 -5
sambeau 15y ago
REBOL is the only language I can think of that comes close to this list. http://rebol.com/ http://rebol.com/
kibwen 15y ago
Here's one he missed: a good package manager. Yes, I realize that's not technically an aspect of a language, in the purest sense. Yes, I realize that this is something that the community can provide. However, I will argue that any new language that neglects to ship a package manager alongside the language implementation is doing a disservice to its users. Go (goinstall) and Rust (cargo) had the right idea.

98 points by pchristensen 15y ago

This just seems like an everything and the kitchen sink list. I am not convinced supporting every possible use case leads to an approachable/efficient language. It seems akin to arguing my car should also be a boat and an airplane.

jbrennan 15y ago
I think it's OK because he said >(plus libraries) So some of this would belong as a language feature and other stuff would be in the standard library (is what I'm imagining at least). I'm a Cocoa guy, and when a lot of people rave about Objective-C, they usually are referring to niceties Cocoa provides. This is sort of what I was imagining as I read along.
gbog 15y ago
How far is Python from this list? Macros are missing but the remaining list seem close to me.
- tomp 15y ago
  Math sucks a lot in Python 2.7: 3 / 2 == 1 Python 3 fixes that, thou, but still it uses floating point numbers instead of rational numbers.
  - emillon 15y ago
    There "from __future__ import division" to fix that.
  - lloeki 15y ago
    > it uses floating point numbers instead of rational numbers. import decimal import fractions
andrewflnr 15y ago
It's a heck of a mixed bag, but most of them are orthogonal and would coexist nicely, especially if libraries are allowed to seriously extend the syntax and type system. Seems hard but doable to me.

highwind81 15y ago

This list is more about default library a language should come with rather than language design.

Alind 15y ago

The more I read this article , the more I feel he is not talking about _language_. He is talking about _library_.

genbattle 15y ago
Yea he mentions language features like interface-based polymophism, garbage collection, namespaces, first class functions, closures, etc. But then he goes on to talk about I/O methods, string manipulation, CSV output, etc. By which I think he means standard library features. The post really should have been split into language features + standard library features to make it clearer. I may be influenced by the fact i'm into Go at the moment, but i think it covers most of the "features" he talks about, as well as many of the "libraries" (some may not be part of the standard library, but will be available through 3rd party packages). If the author is reading this, I encourage him to have a good honest look at http://golang.org/ http://golang.org/ I don't know if i like his discussion of "math-oriented types" vs. "machine-oriented types". At least as far as I see it (and according to wikipedia[1]), in maths whole integers (Z) are a subset of rational numbers (Q). When in your high-school maths class you say 3 + 2.5 = 5.5, you're really doing an implicit conversion to 3.0 + 2.5 = 5.5 or 3/1 + 5/2 = 11/2. Most languages allow you to also get rid of the bit-size of numbers by just defining "int" or "float" numbers that default to some predetermined bit-width (e.g. 32-bit). Most languages also have libraries or mechanisms (see Go and Python) for large precision numerical calculation so you can have your theoretically infinite size "no-overflow" situation; but that comes at the cost of speed, so we only use these types when it is specifically needed. It's not impossible to use them in all cases, but it is impractical. In the end, a language can't do everything. Most languages focus on providing a good core, along with mechanism for users to extend functionality in any way they see fit. In this case I think the author wants the language to just do everything for him out of the box, without any pesky libraries, and without being bloated or slow. _That_ most certainly _is_ impossible. There is a good reason why no language implements _all_ of these "features". [1] http://en.wikipedia.org/wiki/Set_(mathematics) http://en.wikipedia.org/wiki/Set_(mathematics) Ed: Z is a subset of Q.
- jacques_chester 15y ago

ww520 15y ago

I am surprised it's not very Lisp-biased. Anyway, no love for type inference or generic?

baddox 15y ago
Except for homoiconicity.
- gecko 15y ago
  Tcl, Forth, Io, and (traditional) Smalltalk are also all homoiconic. You don't have to have a Lisp to get there.

dman 15y ago

Is it just me or did anyone else feel he was talking about Racket? I have never understood why Racket doesnt get the love that it deserves.

errnoh 15y ago
Is it just me or did anyone else feel he was talking about Go? I have never understood why Go doesnt get the love that it deserves. (No seriously, he described Go)
- laktek 15y ago
  Absolutely, that was the first impression I also got when reading the post. Actually, its Go's standard packages which matches most of these expectations.
- genbattle 15y ago
  I also had the same weird feeling (see my post elsewhere in the thread). I think Go's just still too immature for most people to invest deeply in. Production code can have a lifespan measured in years or even decades, so you want to use a language that's stable and mature, and you want to know that it's going to be around at least as long as your application. Things will change once the 1.0 Stable release rolls around, and people will really start dipping their feet in (and those people who have been dipping their feet might take a dive).
  - errnoh 15y ago
    Yeah. And of course Go doesn't satisfy everything on that list either. But it does satisfy most of it with just the standard library. Go 1 should solve most of the big problems, currently libraries need to keep up with weekly releases and packages are still being moved around.
- rsanders 15y ago
  This doesn't sound like Go to me, but I've never used it: Homoiconic Code can be manipulated as data. Extensible syntax I find I don't use macros much anymore. I do more with data-oriented programming. But it is nice to have when you need it.

shubber 15y ago

Wrong: first item should be environments as first class types. Much of the rest follows. And you can stick it to smarmy common lisp geeks.

jballanc 15y ago
This post does a really good job of analyzing first-class environments and explaining why "first-class environments are useless at best, and dangerous at worst": http://funcall.blogspot.com/2009/09/first-class-environments.html http://funcall.blogspot.com/2009/09/first-class-environments...
- pnathan 15y ago
  I found his argument a bit of a wash. It boiled down to usual critique of macros, operator overloading, and inheritance: "You don't know what's going to happen". Meh, most of the time it's not a problem, when it is, it's for a good reason, and if it's for a bad reason, you probably should choose a different software package that is written better.

slyall 15y ago

The most obvious thing I can see that he wasn't explicit about was Unicode support. Should be native, just work and included from day one.

ericn 15y ago
Good one.

Mikera 15y ago

This is basically a desciption of Clojure, in particular: - Explicit model of time (http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey http://www.infoq.com/presentations/Value-Identity-State-Rich...) - Homoiconic / Extensible syntax (shared by most Lisps) - Math-oriented numeric types (Clojure maths is arbitrary precision by default, and it has nice things like rational types) - Immutable (Clojure data structures are all immutable) - Garbage collection (inherited from the JVM) - String manipulation (Regular expressions are a built-in type) Most of the other features actually seem more like libraries than language features, but given that Clojure can access the entire Java ecosystem I think you can do all of it from Clojure with relatively little pain.

jsankey 15y ago
Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.
- michaelochurch 15y ago
  I find it interesting that two of the most exciting languages that exist right now are built on top of the VM for one of the worst ones.
  - jsankey 15y ago
    The strength of Java for many years has been the platform, and indeed the surrounding ecosystem, not the language. In that sense it's no surprise that there is a lot of effort going in to providing better languages on that platform.
    - exDM69 15y ago
      The reason I'm not using Clojure is that it's based on the Java platform. I keep hearing that JVM is nice because there are good libraries, but I haven't figured out what the good libraries are. Sure, there are some nice platform independent abstractions for common operating system interfaces like file and network I/O, but it still lacks lots of stuff. The problem with Java libraries w.r.t. modern high level languages is that Java libraries are built on Java abstractions. It doesn't matter how high level the new language is, but when interfacing with Java libs, you have to stick to single dispatch object oriented programming. So in the end, there are many cases where you use the Java library through some wrapper layer written in Clojure or your Clojure code ends up looking a lot like Java. Once you add a wrapper layer shim between your preferred language and the platform, it doesn't matter what's underneath. That's why I like to stick to languages that are built on native code and libraries, C and Posix and Unix API's with some Linux and/or BSD additions. Of course, if you want to run on Windows, all the code has to be duplicated since Win API's are different.

ggchappell 15y ago

I'll add one that people don't seem to think about much: the ability to encapsulate an ongoing computation and grab new values from it at leisure. Examples: Haskell has lazy lists; Python has generators; Unix shells have pipes; in Go you can whip this up pretty easily with a goroutine and a channel; etc. Does his ideal language allow for this?

ericn 15y ago
I should add controlled laziness to the list.

chops 15y ago

If you're going to throw everything and the kitchen sink in a language, you may as well include Erlang-type multiprocessing and message passing.

Dn_Ab 15y ago

Most languages have most of the listed features. The most interesting uncommon idea on that list to me is model of time. But only when it allows reversible computing. I don't know how practical that is though. Anyways I've separated out the parts of the list which I think are less common. And listed examples off the top of my head so by no means is the below meant to be exhaustive. The uncommon ones: * Units - F# and Frink * homoiconicity - Lisps, Prolog, Io, Factor, Pure?, ... * macros and extensible syntax - the above list, Nemerle, Dylan * Unification - Prolog, Mercury - logic languages. anyone with type inference. anyone with predicate dispatch, a full example of which I do not know. F# Active patterns and scala extractors are close. * Error (managing numeric Imprecision) - Best I can understand I can only note that I have seen people treat similar concepts with monads. So haskell and any language which allows easy monads. So scala, f#, haskell, clojure, nemerle * Math types - Axiom/Aldor. To an extent, dependently typed languages - not practical. yet? * Polymorphism - Although it sounds more like structural typing. So OCaml, Scala. Also F#, haskell partially. * Aspects - Metaprogramming makes this relatively easy and clean to implement. so anyone with macros too. Arguably, monads are another way to follow the same philosophy. * term rewriting - not common, very niche and not mentioned, but pure-lang allows this and for abstract math programming it is a really fun & powerful concept. * pluggable types - F# has this as type providers. Gosu open types. I have used it in F#. At a start, it is a very awesome way to consume an api. Less Uncommon: * pattern matching - most functional languages. to a small extent the java.nexts * Immutable values - most functional languages * Parser - parser combinators or any language which implements PEGs e.g. Nemerle * Design by contract - eiffel and as a library in most languages * laziness - the usual functional suspects.

smcj 15y ago
Great overview, thanks! I added some new stuff to my reading list. :-) Just some notes from a Scala user: Regarding Units: I bundled some work done before by other people into a nicer package/syntax, apart from a few missing bits working with Units looks quite nicely in Scala, even without any special support for it: val mass: Mass[Double] = 4.0 kg val longMass: Mass[Long] = mass asLong val length: Length[Int] = (5 m) * 3 val time: Time[Int] = 1 s val doubleTime: Time[Int] = time + time val temp: Temperature[BigDecimal] = BigDecimal("22.22") k val speed: Speed[Int] = length / time val area: Area[Int] = length * length val volume: Volume[Int] = (23 m) * (1 m) * (1 m) val smallVolume: Volume[Double] = (volume asDouble) / 12.0 val area2: Area[Int] = volume / (23 m) val accel: Acceleration[Double] = (10.0 m) / ((2.0 s) * (1.0 s)) val accelNum: Double = accel toDouble The type annotations are not needed, but helps undestanding the design. Scala will very likely get macros in the next version, together with pluggable types/type providers. Macros not in a Lisp or "extend syntax" sense, but more in a Nemerle sense. Scala macros are written in fully statically typed Scala and are checked at compile time before and after expansion.

michaelochurch 15y ago

Clojure and Scala are both there, except on idiomatic libraries (you might have to use Java libraries). Clojure wins on simplicity of syntax (Scala has a rule that operators ending with ':' associated to the right, which makes an incredible amount of sense once you understand the language but is annoying and arbitrary to beginners) and homoiconicity. Scala wins on pattern matching and robustness (static typing). I'd use Scala for a game, because it's fast (both in terms of human and CPU performance). Both are great languages.

nickik 15y ago
Because Clojure is a Lisp we have macros and with macros comes a lot of power. Clojure has a full powered pattern matching library. See this: https://github.com/clojure/core.match https://github.com/clojure/core.match

jhancock 15y ago

All I want: Smalltalk with tail recursion and a process model like erlang (implies immutable values).

akoumjian 15y ago

http://colinm.org/language_checklist.html http://colinm.org/language_checklist.html This has never been more relevant.

Gotttzsche 15y ago

hmm, what exactly does he mean by data-oriented programming? iirc that's something where you don't store data chopped up into objects, but have arrays that keep all the data of one "aspect" of all "objects"... or something like that. something game programmers would use, helps avoid cache misses. is that what he was talking about? if so, what does it have to do with macros?

ericn 15y ago
I meant data-driven programming. http://www.faqs.org/docs/artu/ch09s01.html http://www.faqs.org/docs/artu/ch09s01.html More data (and data structures) and less code. It's very common in Lisps and other homo-iconic languages.
- Gotttzsche 15y ago
  thanks :)

apgwoz 15y ago

Yet, no mention of concurrency/parallelism primitives. sigh

ericn 15y ago
Good idea. But they do kind of fall under a "model of time."
- apgwoz 15y ago
  In fact, the article does mention concurrency in there. I must have read over that thinking right away that they meant UTC/ Time Zone issues again. d'oh!

ajuc 15y ago

+ 1 for easy serialization. Every language should have equivalent of Python pickle module. Sometimes you need specific file format, compatibility between languages, customization, etc - then pickle is not enough. But for my uses pickle was good enough most of the time, and it's stupidly easy to use. No need to change your code in any way. That makes one-off cashing of intermediate results to file system manageable, implementing save/load game is 3 lines of code (counting import). I love it, and I miss it in every other language I use. Javascript has JSON, but writing general code to serialize arbitrary object graph with cycles, functions as field values, properly storing prototype chains, etc is still hard.

webreac 15y ago

First need of a good language: have a simple specification. The full reference manual shall be very concise, complete and readable. Even with a language as simple as javascript, the specification is a nightmare.

jwarzech 15y ago

One thing that always bugs me is that modern languages that ship with fairly strong datetime libraries still make it a pain to deal with just dates. My db can handle just a date why does my language need to treat date as some hack on datetime? I want 12/01/1980 not 12/01/1980 00:00:00 -5

sambeau 15y ago

REBOL is the only language I can think of that comes close to this list. http://rebol.com/ http://rebol.com/

kibwen 15y ago

Here's one he missed: a good package manager. Yes, I realize that's not technically an aspect of a language, in the purest sense. Yes, I realize that this is something that the community can provide. However, I will argue that any new language that neglects to ship a package manager alongside the language implementation is doing a disservice to its users. Go (goinstall) and Rust (cargo) had the right idea.