Hacker News Reader

Comment by Mikera | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com