* 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.
