Live data from Hacker News

Clojure 1.10 release

clojure.org

61–70 of 97 posts

Re: Clojure 1.10 release

#62

Earlier quoted context omitted.

The deification of Rich Hickey in this thread is amusing. No doubt he's a great developer and language designer, but dogfooding your own language is not exactly novel.

I think the original statement was implicitly about using the language to build large complex systems in industry, not just about "using" the language which I agree would be kind of silly - who would work on a language they don't use in some way? But I always had the impression that most language designers were academics, e.g Alan Kay, Stroustrup, or professional programmers building what were initially 'hobby' langu…

I got the point of the original statement, but again, even building a large and complex system is not unique to Clojure. Go was used internally within Google, Swift within Apple, and Rust within Mozilla, to name a few.

Re: Clojure 1.10 release

#63

Congrats. I'm trying to learn Common Lisp for great good. And, I love that lisp is still alive. I think we still haven't learned all that lisp has to offer. For me personally, I think Clojure (or any lisp) targeting Go would be awesome. The JVM lacks a killer Go "feature" which is _native binaries/easy deployment. Common lisp and many other lisps lack community which is why I think Go+Lisp would make a great combo. G…

No need for Go, GraalVM already allows you to create a native binary:

https://www.innoq.com/en/blog/native-clojure-and-graalvm/

Re: Clojure 1.10 release

#64

Congrats. I'm trying to learn Common Lisp for great good. And, I love that lisp is still alive. I think we still haven't learned all that lisp has to offer. For me personally, I think Clojure (or any lisp) targeting Go would be awesome. The JVM lacks a killer Go "feature" which is _native binaries/easy deployment. Common lisp and many other lisps lack community which is why I think Go+Lisp would make a great combo. G…

As fcurts below mentioned, [Graal's native image generation](https://www.graalvm.org/docs/reference-manual/aot-compilatio...) might be what you want.

It can turn a Clojure app into a single executable with excellent performance and memory characteristics.

Re: Clojure 1.10 release

#65
post #36

Earlier quoted context omitted.

It takes one to know one. (Or so I would like to think.) Rich's writing, presentations, and example of overall conceptual discipline and maturity have helped me focus on the essentials in ways that I could not overstate. I'm glad (but not surprised) to see so much appreciation for him around here, even among non-Clojurists (like myself). At the risk of fanboyism, I am constantly referencing his ideas* to my team, and…

I made the mistake of showing the 'hammock driven development' talk to an employer of mine. He got annoyed by it and said he thought that it was just providing programmers with an excuse for staying away from the computer when they should be writing code.

Has he ever written code that was used in production and he was in charge of the project?

Re: Clojure 1.10 release

#66
post #13

Earlier quoted context omitted.

Maybe, but this was true even when Clojure was younger still. The language changes are overwhelmingly additive; Hickey places great stock in not breaking existing code.

I'm going to bring up again how + used to autopromote ints if your result was out of the primitive int range, and now throws an error instead.

Was your application affected? Did you have to perform an extensive rewrite?

Engineering is all about compromises.

Re: Clojure 1.10 release

#67
post #36

Earlier quoted context omitted.

It takes one to know one. (Or so I would like to think.) Rich's writing, presentations, and example of overall conceptual discipline and maturity have helped me focus on the essentials in ways that I could not overstate. I'm glad (but not surprised) to see so much appreciation for him around here, even among non-Clojurists (like myself). At the risk of fanboyism, I am constantly referencing his ideas* to my team, and…

I made the mistake of showing the 'hammock driven development' talk to an employer of mine. He got annoyed by it and said he thought that it was just providing programmers with an excuse for staying away from the computer when they should be writing code.

It is kind of heartbreaking.

But, although my current manager is excellent at supporting his team and would never think such a thing, let alone say it, the truth is that, unless you're a professional researcher, you really do have to do the hammock-driven thing on your own time, either by working it into your routine or by taking a long sabbatical (as Rich did). It's something I struggle with, even at a very good workplace.

"Nothing is more precious" than the chance to think through a problem over a long term, and as things stand, the best tool for thinking is still the mind, not the keyboard. I can see how that takes a leap of faith when your chief deliverable is code.

Anyway, maybe a better introduction for your typical manager is,

> The most expensive problems are problems of misconception.

Re: Clojure 1.10 release

#68
post #27
post #3

From the perspective of a (fairly large-scale at this point) app developer: I find it great that Clojure places such emphasis on backwards compatibility. In general, migration to newer Clojure versions is completely painless. The language has been designed by experienced and mature people and doesn't go through "let's throw everything out and start again" phases like so many other languages do.

Which languages threw everything out and started again?

Python 3, Perl 6 it looks like Scala 3 is heading that way too.

Re: Clojure 1.10 release

#69
post #20

Earlier quoted context omitted.

If you want to demand perfection, then Clojure isn't going to meet your standards (what would?). The issue here is that, based on the way they (particularly Rich) talk, we can expect they will not do Bloody Stupid things like the old Python 2->3 changeover. Things like big, breaking changes that require architectural changes to keep current, or break all the available tutorials. If the problem can be fixed with a mac…

You don't think a breaking change to + is any more significant than a breaking change to some other part of the language?

A breaking release over 7 years ago, doesn't mean that having no (as far as I know) breaking changes for the last 6 years is any less impressive.

Re: Clojure 1.10 release

#70

While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file. The emacs based tooling had too many compone…

> While I like the language very well, tooling does have issues, even simple things like not distributing Leiningen with Clojure when it is almost essential for any serious development. Version incompatibilities between Leiningen and Clojure creates subtle problems. I also wonder what the experience of using lein in Windows, it seems to install using a mysterious batch file.

Clojure bundles tools.deps since 1.9, and it works great. cljs and figwheel already supports it, as do many others. I prefer it to leiningen, but YMMW.

I use emacs to develop clojure, never had any problems with it :/

> Usage of local jars is extremely difficult, you need to setup a local maven repository and then add dependencies through it, which is a very painful process, esp for hobby projects and prototyping. I should be working on my problem not wrangling with maven.

tools.deps makes this very easy.

Post reply on HN