Live data from Hacker News

Why I am excited about Clojure

blog.txus.io

31–40 of 173 posts

Re: Why I am excited about Clojure

#31
post #14

That last feature is certainly one of my favorite parts about Clojure. It's one of my favorite parts about Lisps in general actually, but Clojure has a very good handle on it. Having to compile a program before seeing if the changes you made work can be a nuisance. Interpreted programs are slightly better, but being able to make micro-changes to a running instance of a program and seeing in real-time how it affects t…

I could load jars on the fly in Java.

This has been possible in Grails and Play for many years.

You can make a code change and refresh the browser and your changes are reflected.

Re: Why I am excited about Clojure

#32
I am a Ruby guy torn between diving into Haskell or Clojure. Help! Every time I get excited about one feature of one (ClojureScript) I learn the other has something equivalent or potentially better (Haste).

One thing that has put me off on Clojure is 1) the ugly as hell JVM stacktraces, 2) hitting the wall of the number system results in nasty JVM errors if you are used to Ruby's trivial (to the developer at least) handling of numbers of any size, 3) the time it takes to fire up the JVM itself (I like really fast really instant unit tests)

On the other hand, what has put me off on Haskell is that 1) all its users seem like mathematics professors, 2) a lot of its libraries will fail to compile when combined with each other without a lot of hand-holding and carefulness

Re: Why I am excited about Clojure

#33
post #19

Earlier quoted context omitted.

I could load jars on the fly in Java.

TIL that that is possible. Just googled it apparently requires custom class-loader. Thanks for this.

Check out JRebel [1] which works with a plugin to your favorite IDE if you want to make it really easy.

[1] http://zeroturnaround.com/software/jrebel/

Re: Why I am excited about Clojure

#34

I'm more excited about ClojureScript because it runs in the browser as JS, of course. My mind is kind of blown that Go-routines were added to the language as a library (core.async). And so was logic programming (core.logic), optional typing (core.typed), and pattern matching (core.match).

That's the neat thing about Lisp-style macros. You have to sacrifice a little bit of the syntactical sugar that you are used to in most languages, but in return you have the ability to add almost any possible construct to the language natively. It makes it much easier to extend the language as you don't need to hack an interpreter written in C or Java. Half of the core language is already written in macros.

Re: Why I am excited about Clojure

#35
post #25
post #14

That last feature is certainly one of my favorite parts about Clojure. It's one of my favorite parts about Lisps in general actually, but Clojure has a very good handle on it. Having to compile a program before seeing if the changes you made work can be a nuisance. Interpreted programs are slightly better, but being able to make micro-changes to a running instance of a program and seeing in real-time how it affects t…

What I find really surprising is that other languages that have pretty decent REPL support have not embraced it so fully as Lisps have. Connecting to the live[0] instance a Rails or Django app, examining its internal state and making updates that don't involve more or less restarting the app is unusual at best. Ruby and Python borrow a lot from Lisp, including the REPL, but some of the most popular applications of th…

The work done at Xerox PARC with Smalltalk and Interlisp was great.

Imagine having a REPL to your complete OS, not the just the basic CLI that most systems have.

There are a few videos of those days showing up the systems.

Re: Why I am excited about Clojure

#36
The reason I end up with Python, CoffeeScript or Ruby and not a Lisp is the prefix notation and the parentheses.

The parentheses can decrease readability and the prefix math expressions can make the order in which you think up a solution awkward.

http://sourceforge.net/p/readable/wiki/Problem/

http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-va...

Re: Why I am excited about Clojure

#37
post #8

I'm a Python user and I love Clojure. I guess I missed the Go bus. But there's 2 things about it I'm not too fond of. One is due to it's declarative nature (which I love), it's quite difficult to get up to speed with unfamiliar code. The 2nd is due to it's JVM roots. Those stacktraces, man. And when it happens on an anonymous funtion in a not so documented library, ugh. It's like hitting a brick wall. The first, I ca…

There are people working on improving stack traces[1][2], but there is no standard solution yet.

[1] https://github.com/AvisoNovate/pretty

[2] https://github.com/mmcgrana/clj-stacktrace

Re: Why I am excited about Clojure

#38
post #26
post #13

Earlier quoted context omitted.

They both have same roots, the :keyword syntax comes from Common Lisp and others: From Matz (creator of Ruby): Ruby is a language designed in the following steps: * take a simple lisp language (like one prior to CL). * remove macros, s-expression. * add simple object system (much simpler than CLOS). * add blocks, inspired by higher order functions. * add methods found in Smalltalk. * add functionality found in Perl (…

If you remove macros and s-expressions from a simple lisp.. what remains? Genuinely curious. If I'd had to guess I say just the spirit of the language, the macros being reincarnated as the highly dynamic smalltalk method system. The s-expressions being reincarnated as the blocks.

It remains something that people living on a strict OOP+procedural+Algol-like-syntax only are willing to swallow.

...otherwise they'll just go "yuuuck!" or "wtf?" or "this is weird" and walk back away to their cubicles. Ruby is great because it changed the culture by letting the kinds of people that wouldn't have dabbled in functional-ish programming or DSLs put their toes in the meta-water ...now hopefully, some of them will start to take swimming lessons :) (and a few will drown themselves and their friends, of course, but there are prices to pay for enlightenment)

Re: Why I am excited about Clojure

#39
post #20

Earlier quoted context omitted.

Oddly enough I never used this, but maybe named fns might help? ( http://clojure.org/special_forms#Special%20Forms--%28fn%20na... ) (fn my-name [] (throw (Exception. "boom"))) (Sorry, I don't know Clojure internals well enough to have great answers to your explicit questions.) [Edited: thanks to jerf for pointing out the inconsistency in a term I used.]

Named... anonymous... functions? Wuzzah fuzzah?

They allow you to use recursion without the need for a Y-combinator.

Re: Why I am excited about Clojure

#40

I am a Ruby guy torn between diving into Haskell or Clojure. Help! Every time I get excited about one feature of one (ClojureScript) I learn the other has something equivalent or potentially better (Haste). One thing that has put me off on Clojure is 1) the ugly as hell JVM stacktraces, 2) hitting the wall of the number system results in nasty JVM errors if you are used to Ruby's trivial (to the developer at least) h…

I'll try to dispel some of the concerns about Clojure.

1) Stacktraces in JVM may be ugly, but the amount of insight into runtime issues that the JVM offers you is generally way higher than in runtimes like cpython or MRI.

2) Clojure gives you a rather elegant way to work with the different JVM number types as it offers literals for those. I think Java Longs (the integer default) should be long enough as it's a 64 bit value. And on the floating point side the default is a double, which also seems nice to me. See: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/dat...

Above this Clojure offers BigDecimal literals and native ratios.

3) The startup time is gigantic. However, while developing you usually should not have to restart the JVM as you can update the JVM with new bytecode through the REPL. This should also dispel the concern about unit tests (although I'm not sure you can reach the necessary speed, if you talk about < 0.5 second unit tests, because the code needs to be compiled to JVM bytecode 1st. There's definitely still potential there.

Post reply on HN