Live data from Hacker News

Clojure: A Lisp that wants to spread

simongray.github.io

301–306 of 306 posts

Re: Clojure: A Lisp that wants to spread

#301
post #63

Earlier quoted context omitted.

Aside from being faster, more mature and with better observability, why is bringing "the JVM along for the ride" different from bringing Racket's runtime along? Also, you do know that Oracle is behind OpenJDK, has been for ten years, and has recently made the JDK completely open-source and free of field-of-use restrictions for the first time in Java's history?

Off topic; But since you work at Oracle, what is the Oracle copyright terms on alternative implementations of Java? (in the light of Android lawsuits). Eg: some research or commercial implementation for a subset of java etc?

What do you mean by "alternative implementations"? OpenJDK is 100% open source, and is entirely governed by its open-source license. You can do whatever you want with -- including take just big or small pieces from it and change them -- it as long as you comply with the license. If you want to use the name "Java", your software must pass the TCK.

Re: Clojure: A Lisp that wants to spread

#302
post #301

Earlier quoted context omitted.

Off topic; But since you work at Oracle, what is the Oracle copyright terms on alternative implementations of Java? (in the light of Android lawsuits). Eg: some research or commercial implementation for a subset of java etc?

What do you mean by "alternative implementations"? OpenJDK is 100% open source, and is entirely governed by its open-source license. You can do whatever you want with -- including take just big or small pieces from it and change them -- it as long as you comply with the license. If you want to use the name "Java", your software must pass the TCK.

No. By alternative implementation I meant eg: some experimental java compiler to a different target eg: say JS / wasm, or a memory efficient class library implementation etc..

Re: Clojure: A Lisp that wants to spread

#303
post #301

Earlier quoted context omitted.

What do you mean by "alternative implementations"? OpenJDK is 100% open source, and is entirely governed by its open-source license. You can do whatever you want with -- including take just big or small pieces from it and change them -- it as long as you comply with the license. If you want to use the name "Java", your software must pass the TCK.

No. By alternative implementation I meant eg: some experimental java compiler to a different target eg: say JS / wasm, or a memory efficient class library implementation etc..

The Java spec is not open source. You could either extract as much or as little from OpenJDK and comply with its open-source license or obtain a spec license if you don't wish to open-source your implementation. In other words, you have the open-source route or the closed source route, but the closed-source route isn't free. (BTW, I am not authorized to speak on behalf of anyone other than myself, so this is just my opinion).

Re: Clojure: A Lisp that wants to spread

#304
post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

> Startup time isn't what is holding the language back.

For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead).

> For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.

More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.

Re: Clojure: A Lisp that wants to spread

#305
post #287
post #281

Earlier quoted context omitted.

Actually quite a bunch of 20 year or older Lisp software is developed in teams. Cyc is developed by a team since the early 80s. Reduce since the mid 70s. The SBCL and CMUCL Lisp implementations come out of the early 80s. Maxima has its roots in the late 60s/early 70s. The commercial Lisp systems from Franz and LispWorks are developed since the mid/end 80s. ACL2 (a theorem prover used in the chip business) comes from…

I don't dispute it has niches where it does well, or at least "works". The implication often given is general purpose productivity superiority.

> The implication often given is general purpose productivity superiority.

The post you responded to specifically used Java as an example, though. Clojure specifically is clearly targeted as an alternative to writing raw Java. A number of other languages rushed in to compete for that space, and while Scala and Kotlin seem to be more popular than Clojure, I have to admit the only JVM app I actually rely on now, uses Clojure.

Puppetdb, specifically. Puppet is a ruby project, but the database component is written in Clojure. I dislike Puppet for many reasons (syntax, coupling, architecture), but not because of its database backend.

Post reply on HN