Clojure wants to spread all right, like the disease it is.
Could you please stop posting unsubstantive comments to Hacker News? We're trying for something a bit different here.
Clojure: A Lisp that wants to spread
61–70 of 306 posts
Re: Clojure: A Lisp that wants to spread
#62Can we please stop using the verb transpile? Compile is fine, thank you. When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.
There's absolutely nothing wrong with transpile. Yes compiler covers all sorts of things (code -> assembly or code -> different language code...etc). However when I hear "transpile" I immediately think of a language going to another language like when Nim gets converted to C or JavaScript or when Clojure gets converted to Java first. It is a specific form of compilation right?
It is a rather ill-defined form of compilation; i.e., it's not clear what that form is. Compilation means translation from one language to another; every compiler does that. Transpile was born because people were used to the fact that the target language of many compilers is machine code, but it's entirely unnecessary to have a separate word for that, as it doesn't add any information. There could be a meaningful term for the word, to refer to some sort of "shallow" compiler, that compiles a source language to a target language of a similar level of abstraction and preserves the source code structure in the output, but people often use the word in other cases, too. In other words, transpile and compile are synonymous, making the newer, hybrid word redundant.
Re: Clojure: A Lisp that wants to spread
#63Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves. For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure.…
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?
Re: Clojure: A Lisp that wants to spread
#64The dealbreakers with Clojure for me are:
1. Weirdly irregular syntax.
2. Java import statements and Java error backtraces anywhere you want to do real work.
3. Inexcusable renaming and name collisions on basic Lisp functions.
It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cases of using a Lisp or targeting the JVM with a more expressive language.
Re: Clojure: A Lisp that wants to spread
#65Thats last few sentences make no sense. The argument is that uptake is stunted by the JVM's slow startup time, making it unsuitable for commandline utils or desktop apps. However thats easily fixed which was never more hillariously stated than when Rich Hickey did it a decade ago. A blogpost went viral and it was a thunderous critique of Clojure, focused on this single point of slow start up. In the comment section w…
For anyone else wondering, "holy crap, WTF does -client do?" here you go: https://stackoverflow.com/a/198651/931209 And to save folks a click: > The Client VM compiler does not try to execute many of the more complex optimizations performed by the compiler in the Server VM, but in exchange, it requires less time to analyze and compile a piece of code. This means the Client VM can start up faster and requires a smalle…
> A 64-bit capable JDK currently ignores this option and instead uses the Java Hotspot Server VM.
Re: Clojure: A Lisp that wants to spread
#66Earlier quoted context omitted.
I'm curious, what features are missing that stops Clojure from being considered a proper Lisp? From my brief experience it can do most of the same things except reader macros.
The common talking points are * Clojure is based on seqs rather than cons cells. * Clojure renamed certain common functions, like car and cdr, so 30 year old Lisp example code no longer compiles. * Clojure doesn't have implicit tail call optimisation for recursion. * Clojure reveals its host platform when it has runtime errors.
Clojure did not just rename a few functions. It's basically zero source code compatible with Lisps. Not only old example code does not run, nothing runs. No applications, no libraries, no tools, ... It's not even easy to port. It's a rewrite and/or redesign.
Obviously this is okay for people who don't care of the historical baggage (and want to avoid it) and who don't care about the functionality of Lisps, like interactive error handling.
Re: Clojure: A Lisp that wants to spread
#67Thats last few sentences make no sense. The argument is that uptake is stunted by the JVM's slow startup time, making it unsuitable for commandline utils or desktop apps. However thats easily fixed which was never more hillariously stated than when Rich Hickey did it a decade ago. A blogpost went viral and it was a thunderous critique of Clojure, focused on this single point of slow start up. In the comment section w…
Uhm.. I want to give the benefit of the doubt, but frankly this seems deceptive, or at least out of date, unless I'm totally missing something.
Why is there no magical --client / --script option for the Clojure ClI to make startup faster, if this is such an easy solution? Also, you show system time, but the time to load dependencies is in user time, which is slow by the nature of Clojure.
Example:
$ time java -client -classpath /usr/local/Cellar/clojure /1.10.1.492/libexec/clojure-tools-1.10.1.492.jar clojure.main hello.clj
Hello, world
java -client -classpath clojure.main scripts/script.clj 1.39s user 0.08s system 187% cpu 0.788 total
$ time java -classpath /usr/local/Cellar/clojure/1.10.1.492/libexec/clojure-tools-1.10.1.492.jar clojure.main hello.clj
Hello, world
java -classpath clojure.main scripts/script.clj 1.37s user 0.09s system 180% cpu 0.811 total
User time appears slightly slower without the -client option, but probably is not statistically significant. Also, anyone who has worked on more than a toy project with Clojure knows that it's not just about the Hello World startup speed, every dependency you add has a significant impact on Clojure startup time.
Re: Clojure: A Lisp that wants to spread
#68Earlier quoted context omitted.
Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves. For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure.…
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?
I haven’t figured out a way with the JVM / Clojure to compile and distribute a small self-contained bundle nearly as easily as I can with Racket.
And Graal (the option I’m aware of for compiling JVM-based code into a redistributable binary) is definitely Oracle. If I wrote more long-running code, or I could redistribute a stripped down JVM as easily as with Racket’s build tool “raco” I might have a different view, and I’d definitely prefer OpenJDK to Oracle’s.
Re: Clojure: A Lisp that wants to spread
#69My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescri…
Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully.
I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
Re: Clojure: A Lisp that wants to spread
#70My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescri…
Maybe I’m just dense, but I certainly have not been productive with any language on day 3. (Not even Ruby, which feels comfortable faster than most languages.) I sometimes felt productive that soon but I always end up having to rewrite once I learn the language fully. I’ve learned enough languages that I can spot “a person’s first program in X” now pretty easily.
Yeah, same. But it does help a lot having a professionally developed project with lots of high quality, real world examples of how to do things.