Modern Language Wishlist
lispcast.com
lispcast.com
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.
Most of the features are not hard to find, but you have to switch languages a lot if you want to use them all.
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.
- 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 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.
>(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.
3 / 2 == 1
import decimal
import fractions
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?
(No seriously, he described Go)
Actually, its Go's standard packages which matches most of these expectations.
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).
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.
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.
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.
Also, the rather new Red language (Rebol-like) http://www.red-lang.org/ seems interesting.
I don't think Go matches all his criteria, though. For instance, Go is not homoiconic.
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.
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.
* 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.)
You might not like the literal syntax for maps in Racket, but it certainly exists.
Typed Racket has lots of math-oriented types; we just wrote a paper about their design here: http://www.ccs.neu.edu/racket/pubs/padl12-stff.pdf
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.
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.
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.
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.
This has never been more relevant.
Anyway, no love for type inference or generic?
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.
I want 12/01/1980 not 12/01/1980 00:00:00 -5
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?
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.
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".
[1] http://en.wikipedia.org/wiki/Set_(mathematics)
Ed: Z is a subset of Q.
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.
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.
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.