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.
* 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
I think that the full numeric tower of scheme is what the author had in mind for Math types: big nums, true rationals, strong sense of exactness, etc...
Also, CLOS (Common Lisp) has after, before and around methods for "aspect oriented".
Python is not homoiconic but the ast module allows for wicked stuff.
> Error (managing numeric Imprecision)
Python decimal module does not handle precision error but handles significance, so that(from the doc) "for instance, 1.3 * 1.2 gives 1.56 while 1.30 * 1.20 gives 1.5600". This underrated module also does much more.
Anyway I feel this precision stuff might be a job for numpy/scipy.
This is basically a desciption of Clojure, in particular:
- Explicit model of time (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.
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.
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.
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.
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.
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.
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?
* Racket doesn't meaningfully have a good syntax for literal maps or sets
* Racket doesn't have math-oriented types, AFAIK, even in Typed Racket
* Racket doesn't have units.
* Racket doesn't have aspects (you can obviously add them--see Swindle--
but Swindle is very rare these days, and not the preferred way to write
Racket
* Racket is not interface-based (ditto)
* Racket *supports* immutable values, but mutable (via define) seems more common.
The MLs or Clojure seem a lot closer here.
* Racket is arguably not polymorphic. I'm aware you can do weird stuff by
playing with a bunch of hidden parameters on structures, but the description
sounds a lot closer to OCaml functors to me. (And look no further than
how Racket has for/list, for/hash, for/gvector, etc., for a harsh example of the
limits of that polymorphism.)
Comprehensions such as for/list and for/hash are polymorphic, in that they operate on arbitrary sequences, of whatever type. for/list constructs lists; for/hash constructs hashes. Clojure, a language that takes uniformity of interface much further than Racket, has similar operations.
You're completely right on the math. I had math-oriented types wrong; I assumed that the author wanted the ability to say, "This type is restricted to values defined by this set," which he didn't. Even if he did, I see that Typed Racket actually does support such types, which is awesome. So I'm completely wrong.
Whether e.g. #hash((key . value) (key . value)) counts as a literal hash syntax is interesting. If you want to argue it does, then I'll argue that C does, too, since I can trivially #define my way there through C99 struct assignments and a function that constructs a hash off an array of those structs, or that C# does because I can use an initializer (e.g., "new Dictionary<string, string> {{"Foo", "Bar"}, {"Baz", "Quux"}}"). Literal hashtables and vectors, to me, means something that's visually apart from base syntax forms, specifically so that it stands out to the coder. By this standard, Python, Ruby, Smalltalk, and Clojure would qualify, while Racket, Io, and C# would not. Whether that matters to you depends on what you want.
I don't think that's right about hash tables. In particular, the distinction I would make is that literal hash tables are part of the syntax of the language in Racket, like in Clojure, Python, etc, and not in C# or C. What this means in Racket is that (read (open-input-string "#hash()")) produces a hash table -- that's parsing, not running the hash table constructor.
Racket doesn't have math-oriented types, AFAIK, even in Typed Racket
As far as I know, it uses "machine-oriented" data representation when it can (sufficiently small integers, inexact numbers) and promotes to arbitrary-precision representation when it has to (larger integers, non-integer rationals). I don't know how much more OP expects out of "math-oriented" numbers than what's explicitly listed (no overflow, rational division).
There exists a matrix library, but it might be lacking some desired operations. I'm not sure what OP means by having "equation" as a type.
> Is it just me or did anyone else feel he was talking about Go?
That's really just you:
* Go does not ship with a set collection, no literal or convenient syntax
* Go only ships with with doubly linked lists and no literal or convenient syntax
* Go's literal syntax for the Array and Map builtins is significantly less convenient than that of most other languages (including but not limited to statically typed ones)
* Go is not homoiconic
* Go does not have an extensible syntax
* Go does not have math-oriented numeric types (quite the opposite), neither does it have precision errors (I am not even sure it can meaningfully interact with IEEE-754 error flags)
* Go does not have units (as far as I can tell)
* Go does not have pattern-matching, let alone unification (could have made error reporting good, can't have that)
* Go does not have aspects
* Go does not (as far as I can tell) have any special support for writing parsers
* Go has very little support for immutability
* Go does not have an explicit model of time
* I don't think I've seen any built-in structure serializer and deserializer (equivalent to Lisp readers and writers) in Go
> (No seriously, he described Go)
Only if you're completely delusional, skipped about 60% of his list and gave Go huge leeway on the rest.
Clojure, for instance, is a far better match on this.
Have a look at the "gob" package for serializer and deserializer support for Go types.
As for the syntax-related points, Go offers quite a bit. There's the goyacc tool, the scanner package, the template package (think quasiquote), and a bunch of packages for processing Go code: go/ast, go/scanner, go/parser, go/printer, go/build, go/doc, etc.
For math-oriented numbers, there's the "big" package. Many languages make such numerics much more convenient but you can get pretty far with little effort using just the "big" package.
A lot of this list sounds very much like Postscript:
* Code is stored in an array with the execute flag turned on. Therefore functions can be easily edited (or assembled) as data. First class functions all the way.
* The environment is a dictionary (associative array), which can be swapped with another dictionary at any time (not just at function entry points).
* Garbage collection is standard
I was thinking that it may be an interesting project to write a general purpose Postscript (non-graphics oriented) interpreter, with a decent library, full continuation passing support, a different way of handling the "current dictionary" stack (to allow for static in addition to dynamic variable support), and a swappable parser to allow for additional program definition styles (infix or prefix in addition to the default postfix notation). Just something kicking around in the back of my head for a while.
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).
I am a big fan of Go, but he was certainly not describing this language. A lot the items on the wishlist were math and sciences items (arbitrary precision int, float, rational number; vectors, matrices; units). These are not in the language, and, while they can be in libraries (see big.Int and big.Rat), without operator overloading, I don't think Go is a good fit for these types of applications.
I think a lot of languages could be described by most of the items on the wishlist. I thought Clojure was an extremely close fit, but then I program a lot in Clojure :)
I don't think Go matches all his criteria, though. For instance, Go is not homoiconic.
+ 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.
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.
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.
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?
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.
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!
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?
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/
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".
Actually, from a math perspective, it's kind of nonsensical to talk about type conversion at all. That is, 3, 3.0, and 3/1 are purely notational differences, and all three represent exactly the same object. Since math is theoretically infinite precision, the way you write a number has no impact on the way operations like division act on it, making whether it belongs to Z, or just Q or R a moot point. Now, if you restrict your problem domain to Z, then that affects the operations you're able to do to a number and remain in that domain. That's more like what happens with types in programming; we restrict our domain by default because leaving the integers changes the computer's representation of the number in a way that affects its behavior.
Kind of. But you might say that rational numbers are ordered pairs of integers and positive integers, real numbers are Cauchy sequences of rationals, and complex numbers are ordered pairs of real numbers, and the real number 3 can't be added to (2+i) without converting it to a complex number first.
Those are all valid ways of conceptualizing those sets, but I don't think it changes the point I was making. The real number 3 doesn't need to be "converted" to a complex number to be added to 2+i. 3 is always both a real number and a complex number, which may be represented as either 3 or 3+0*i, and either way gives 5+i when added to 2+i. All the latter notation really does is clarifies what domain you're currently working in, and even so, I've never seen anyone write it out explicitly.
Type conversion is more like if you had the written number 3 and a picture of the point 5 on a number line and someone told you to add them. Naturally, you would write 5 as a number first, because you don't have a useful way to add a number and a picture. But this doesn't change the results of adding the quantities 3 and 5; it's purely an artifact of the way the information was presented to you.
A nice thing about John Conway's construction of the Surreal numbers is that integers are really a subset of the rationals, which are really a subset of the reals, which are really a subset of the surreals. I find this much more elegant than having "merely" finding an embedding of the smaller structure inside the larger one.
Wow, i didn't know any language had something like that. Can't say I'm surprised that it's a feature of Scheme/Lisp.
If OP said "Numerical Tower" in the first place I'd probably have looked it up and understood what he was talking about. Thanks for the info anyway. Learn something new every day on HN.
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.
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
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.