Live data from Hacker News

The Future of Clojure

thoughtworks.com

171–180 of 309 posts

Re: The Future of Clojure

#171

> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?

Go, according to its creator Rob Pike:

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." [1]

[1] https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...

Re: The Future of Clojure

#172

Earlier quoted context omitted.

I prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. I feel like I am continuously looking for a better alternative, but it's ha…

> I prefer functional programming, and have a background in functional programming, but I still primarily work with Java... In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets. It sounds like Clojure is perfect for you then. You have all the upsides of Java you mention here with Clojure becaus…

I consider a static type system to be a must-have. If Clojure was more like Typed Racket on the JVM, I would already be using it.

Re: The Future of Clojure

#173

Earlier quoted context omitted.

I'm still salty about Specter[0] not being ~officially recognised as a necessity when using Clojure. [0] https://github.com/redplanetlabs/specter Data driven languages need simple & powerful transformation libraries. `get-in` is repetitive and tiresome to use. Specter and it's ilk make transformations clear and simple. No amount of planning or foresight negates the need for data transformation libraries.

Well, it's not a necessity, and it exists a library that anyone can use, so I don't understand any reason to be salty.

My saltiness has to do with being presented with a situation(whilst still new to clojure) which required quite deep data transformations and using idiomatic core clojure functions for ~3 days before saying there has to be a better way and then searching and ending up on Specter.

It's not a necessity in the same way XPath wasn't a necessity to interrogate XML.

Re: The Future of Clojure

#174

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture in…

Honest question: Why is clojure so much better than the rest?

Compared to other languages, I've found Clojure makes it much easier to iteratively turn an idea into code.

Say you're writing a pure function...

You start with just data and a sense of how the output might look. Let's say I have APIs providing me with a user record and a list of transactions, and I want to get that person's balance...

Maybe you start with some canned data

        (let [person {:name            "Matt"
                      :id              12345
                      :current_balance 100.10}
              txns   [{:person_id 12345 :amt 10}
                      {:person_id 44444 :amt 0.5}
                      {:person_id 55555 :amt 10}
                      {:person_id 12345 :amt 11}
                      {:person_id 12345 :amt -5}
                      {:person_id 66666 :amt 3}]]
          (->> txns
              count)
          )
        => 6
and maybe you want to filter the transactions to just that user

        (let [person {:name            "Matt"
                      :id              12345
                      :current_balance 100.10}
              txns   [{:person_id 12345 :amt 10}
                      {:person_id 44444 :amt 0.5}
                      {:person_id 55555 :amt 10}
                      {:person_id 12345 :amt 11}
                      {:person_id 12345 :amt -5}
                      {:person_id 66666 :amt 3}]]

          (->> txns
              (filter #(= (:id person)
                          (:person_id %)))
              count)
          )
        => 3
then you want to extract the amount for each of those

        (let [person {:name            "Matt"
                      :id              12345
                      :current_balance 100.10}
              txns   [{:person_id 12345 :amt 10}
                      {:person_id 44444 :amt 0.5}
                      {:person_id 55555 :amt 10}
                      {:person_id 12345 :amt 11}
                      {:person_id 12345 :amt -5}
                      {:person_id 66666 :amt 3}]]

          (->> txns
              (filter #(= (:id person)
                          (:person_id %)))
              (map :amt))
          )
        => (10 11 -5)
and sum those amounts

        (let [person {:name            "Matt"
                      :id              12345
                      :current_balance 100.10}
              txns   [{:person_id 12345 :amt 10}
                      {:person_id 44444 :amt 0.5}
                      {:person_id 55555 :amt 10}
                      {:person_id 12345 :amt 11}
                      {:person_id 12345 :amt -5}
                      {:person_id 66666 :amt 3}]]
          (->> txns
              (filter #(= (:id person)
                          (:person_id %)))
              (map :amt)
              (apply +))
          )
        => 16
and add that to the existing balance

        (let [person     {:name            "Matt"
                          :id              12345
                          :current_balance 100.10}
              txns       [{:person_id 12345 :amt 10}
                          {:person_id 44444 :amt 0.5}
                          {:person_id 55555 :amt 10}
                          {:person_id 12345 :amt 11}
                          {:person_id 12345 :amt -5}
                          {:person_id 66666 :amt 3}]
              bal-change (->> txns
                              (filter #(= (:id person)
                                          (:person_id %)))
                              (map :amt)
                              (apply +))]
          (+ bal-change (:current_balance person))
          )
        => 116.1
the function is done!

        (defn update-person-balance [{:keys [id current_balance]} txns]
          (let [bal-change (->> txns
                                (filter #(= id
                                            (:person_id %)))
                                (map :amt)
                                (apply +))]
            (+ bal-change current_balance)))
I posted here as a series of snippets, but this would have been a single block of code, refined and evaluated and refined and evaluated, over and over, in a REPL-integrated editor. It feels like sketching a portrait or sculpting clay.

"But I can do that in any ol' REPL!" you might say. Try Clojure -- really try it, with an nREPL connected to your running application and to your editor, capturing inputs, playing them back, writing evaluation output as comments -- and then tell me you want to go back to your old REPL. A notebook environment is similar, though clumsier IMO.

Come for the REPL-driven-development, stay for the immutability, the Java library ecosystem, the lisp syntax, the concurrency support, etc. I know going on and on about how great Clojure development is is basically a meme at this point, but that's because it's really great!

Re: The Future of Clojure

#175

Earlier quoted context omitted.

I think that the bigger problem is that developers just don't get taught any way to think about coding other than the object-oriented, use-Java-for-everything approach. I sometimes think I could have massively accelerated my ability to produce decent code in any language if I had been forced to work through "The Little Schemer" and "How to Design Programs" before I saw anything else. But that is probably just hindsig…

When I'm coding in Lisp, I want objects with methods and mutable state. I made myself a Lisp dialect with a nice little object system. More precisely, I made it without that object system, but I eventually couldn't stand the situation. I use objects even in small, throwaway programs used once. Sometimes it turns out that they aren't just used once, and the use of objects makes them easier to read later.

FYI - you are an outlier. In my experience once you teach someone about immutable systems, they never want to go back. There are sometimes corner cases where you want mutability. Usually for performance reasons; and in those cases it's helpful to have an escape hatch, but also, I would argue that most programmers don't need performance, even when they think they do, something else is the bottleneck.

Because this in HN: Yes, some people are writing operating systems, video games, database engines. Most people are not.

Re: The Future of Clojure

#176

> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?

Go, according to its creator Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understan…

As a person that uses Go and is quite fond of the language, I think it's kind of a misnomer to suggest that Go projects will be sane/built well due to the language. I think that Go invested a tremendous amount of time into making their syntax simple and formattable. I don't think that at, say, 10m LoC, a Go project is any more sane or performant than other languages, I just think the syntax and style of every file is probably more consistent.

Basically I think that Go makes it easy to open and read almost any file, regardless of what you know about the rest of the project. I think that's great, but I also don't really think that it prevents you from building bad software.

Re: The Future of Clojure

#177
post #19

Earlier quoted context omitted.

This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is dev…

> I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?

God I hate them. With annotations Java pulls off the rather unique trick of being both verbose and magical at the same time.

Re: The Future of Clojure

#178

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture in…

Honest question: Why is clojure so much better than the rest?

Rich Hickey has a bunch of good talks about simplicity, functional programming, and immutability which sort of lays out the ethos behind Clojure, and how it differs from other (primarily object oriented languages), but for me, one of the main appeals is the interactive nature of developing with Clojure.

That, combined with the fact that everything is generally made up of simple data structures (lists, vectors, maps, and sets) just makes working with Clojure fun (for me at least).

Here’s a great example of what I’m talking about:

https://vimeo.com/230220635

Re: The Future of Clojure

#179

Earlier quoted context omitted.

It’s really hard to argue that Java projects fail at unusual rates, given how much stuff runs on Java.

But are the rates for Clojure failures more or less than Java?

It is unlikely you will find apples to apples comparison.

What if Clojure projects are more risky by selection bias?

Re: The Future of Clojure

#180

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture in…

Honest question: Why is clojure so much better than the rest?

Everything is a function, functions are first class.

REPL based development gives you instant feedback. lets you write a function in your editor and then run it, change it, run it again. If your idea of REPL is python or ruby, then you are not getting the entire picture. https://stackoverflow.com/questions/5671214/is-lisp-the-only...

Immutable by default. This helps with debugging and solves thread safety. Feel free to pass around references without worry.

Java interop - you can use all the jars

"isomorphic" - write clojurescript for the browser, Clojure for the server

Post reply on HN