Live data from Hacker News

Modern Language Wishlist

lispcast.com

31–40 of 75 posts

Re: Modern Language Wishlist

#31
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.

Re: Modern Language Wishlist

#32
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.

Re: Modern Language Wishlist

#34
post #25
post #23

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 f…

Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.

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.

Re: Modern Language Wishlist

#35
post #11

Earlier quoted context omitted.

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)

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.

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.

Re: Modern Language Wishlist

#36
post #25

Earlier quoted context omitted.

Clojure is awesome, but does struggle on the "Good error messages" requirement, which is a problem when you're starting out.

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.

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.

Re: Modern Language Wishlist

#37
post #4

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

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'…

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.

Re: Modern Language Wishlist

#39
post #37

Earlier quoted context omitted.

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'…

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 rest…

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.

Re: Modern Language Wishlist

#40
post #17

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.

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

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.

Post reply on HN