Why Clojure? • Hacker News Board

Re: Why Clojure?

#181

Post by pbiggar » Sun, Aug 25, 2019, 6:11 PM UTC

Keyframe wrote: post #179

pbiggar wrote: post #53

Earlier quoted context omitted.

My previous startup (CircleCI) was written in Clojure, my current one (Darklang) is written in OCaml. I decided not to use Clojure again because it's not statically typed, and my number one frustration when I coded in the CircleCI codebase was that it was very very hard to know what shape a value had, and whether it could be null. OCaml certainly has a lot of flaws, and is not nearly as "nice" a language as clojure,…

I have no idea what darklang is (your site has zero information), but what made you opt into OCaml out of all of the options out there? Any previous experience with it prior to this?

Ah, sorry about that. The blog is better at the moment (https://medium.com/darklang) but we're updating the site in the very near future.

OCaml was because I had experience with Haskell and didn't like it, and with Elm, which I did like. We tried it for a while as an experiment and it worked really well.

Re: Why Clojure?

#182

Post by pbiggar » Sun, Aug 25, 2019, 6:13 PM UTC

fsloth wrote: post #177

pbiggar wrote: post #53

Earlier quoted context omitted.

My previous startup (CircleCI) was written in Clojure, my current one (Darklang) is written in OCaml. I decided not to use Clojure again because it's not statically typed, and my number one frustration when I coded in the CircleCI codebase was that it was very very hard to know what shape a value had, and whether it could be null. OCaml certainly has a lot of flaws, and is not nearly as "nice" a language as clojure,…

Thanks so much! This was exactly the sort of industrial benchmark I was after. Am I correct in summarizing your experience as: The possible encumbrance caused by types at prototyping phase is paid back several times when refactoring a production codebase?

Hmm, I think it's more that types make it possible to refactor without fear, both at the prototyping phase (when you refactor so much, I had 800 lines of python before that that I was afraid to touch) and later.

Re: Why Clojure?

#183

Post by yogthos » Sun, Aug 25, 2019, 6:43 PM UTC

mabbo wrote: post #128

yogthos wrote: post #106

Earlier quoted context omitted.

This is true literally for every language out there. My team maintains a Java application from over a decade ago. It's an utterly incomprehensible mess that nobody understands, and it's incredibly difficult to make any changes to the project. It's not the job of the language, but rather that of the developer to write clear and readable code. This problem is addressed by using good design practices, code reviews, test…

Oh, we also own plenty of those in Java. That's the job- carefully lay the legacy to rest as you replace it with something better. But at least the Java is overly verbose. It takes a while to read all that code. With the clojure stuff, I'm staring at the same line for just as long and getting no where.

I find that I have the opposite problem myself. With Clojure, the code tends to be more declarative and it tells me what it's doing. Meanwhile, Java leaks a lot of implementation details into the code, and I find it much harder to decipher the intent.

For example if I see something like (filter even? numbers) I immediately know what is being done and why. There aren't any surprises there.

Meanwhile, when I see something like:

    List acc = new ArrayList();
    for (int number : numbers) {
      if (number % 2 == 0) acc.add(number);
    }

then I have to walk through that code in my head to figure out what the intent is, and whether it's actually doing what it's meant to. On top of it I have to worry about mutability. Should a new variable like acc be used, or should the numbers list be updated in place, if it is updated in place where are all the other places that it's used, and are they being affected when I make a change, and so on.

So, there's a lot more to think about even in a completely trivial case such as the example here. In real world code that complexity quickly becomes overwhelming in my experience.

Re: Why Clojure?

#184

Post by iLemming » Sun, Aug 25, 2019, 6:49 PM UTC

yakshaving_jgt wrote: post #164

iLemming wrote: post #161

Earlier quoted context omitted.

> and programmer time is expensive That's why you need to spend 3 years learning Haskell? I feel that's the right amount of years for an average Joe programmer to reach meaningful productivity with the language. Well, maybe I'm exaggerating, maybe it's just two years. Plus/minus another year to learn and understand compiler pragmas.

Hey, I won’t deny that it takes a relatively long time to learn Haskell to a standard where you’re comfortably writing web applications with it. I’m not sure how that’s a rebuttal to my point though. I run a startup. I’ve already put the time in to learn the technology. I’ve learned other technologies too. This one happens to be the one I find the cheapest (now) to write. Did it take my employees a long time to learn…

Alright, jokes aside, let's not get into "measuring dicks" and argue which one is better. I know Clojure, and I know some Haskell. I love both. They both have their strengths and weaknesses. To be honest - I always find things in one that I wish existed in another and vice versa.

But your simple dismissal of Clojure (even though seem to be an educated one) has no merits. Don't feel bitter because Clojure is growing in popularity (in relative terms) and Haskell seems stagnated. Haskell is an older language and has had its ups and downs, and I think it will be fine. Clojure as well - no matter how aggressively haskellers would evangelize against it, it will continue to grow steadily. Think of it as a gateway drug into Haskell. I know people who jumped that way, and I know people who went the other way - from Haskell to Clojure.

To me, it is like using headphones - some prefer wired ones, some people enjoy wireless, even though audio quality suffers, wireless gives them a lot of freedom and might be viewed as a "more practical choice." To that though, proponents of wired might say: "what if the battery dies?". It is an endless and quite pointless debate. So let's concur: Haskell is great, and Clojure is fantastic too.

Re: Why Clojure?

#185

Post by iLemming » Sun, Aug 25, 2019, 6:55 PM UTC

elnygren wrote: post #169

iLemming wrote: post #161

Earlier quoted context omitted.

> and programmer time is expensive That's why you need to spend 3 years learning Haskell? I feel that's the right amount of years for an average Joe programmer to reach meaningful productivity with the language. Well, maybe I'm exaggerating, maybe it's just two years. Plus/minus another year to learn and understand compiler pragmas.

I wonder which is more closer: 3years or "a week or two" to learn enough haskell to start writing things with it. At least for OCaml/ReasonML it was "less than a week" for me and Haskell is probably not that much harder than another ML.

No, you cannot realistically learn Haskell in two weeks and jump into industrial Haskell codebase. I mean, it is not impossible - I just never heard such stories. If that was as easy as you think it is - Haskell would be much, much more popular. It is an amazing language. And probably the only point of criticism you can think of is exactly that: it takes quite some dedication and time to grok it.

Re: Why Clojure?

#186

Post by didibus » Sun, Aug 25, 2019, 9:22 PM UTC

kllrnohj wrote: post #178

didibus wrote: post #123

Earlier quoted context omitted.

> How well does the IDE warn I've made a type error before I've gone through a long compile & test iteration loop? How well do linters or other things work, or is there some aspect of LISP that means this is just not an issue like it is in other languages? Yes, Lisp makes this a non issue for the most part, because the compile and test iteration loop is instantaneous and integrated fully within your IDE/Editor Still,…

> Edit: Let me address the performance part of your comment as well. I think using a game with 20fps as an example was to show that it could even achieve such performance. Languages like Java, C#, Clojure, Python, Ruby are normally bad choices for games as they are not performant enough. So most games are implemented in C++ with an embedded scripting language on top. So the fact a pure Clojure game can hit 20fps with…

I admit it's a weird way to convince us that something is fast. To tell us you are getting 20fps without context.

Uncle Bob didn't mention any spec about his computer, he didn't say if it's 2D rendered or 3D rendered, if he's using GPU acceleration or not. So I had a look at the code for his game, and it is using a software 2D renderer. That means no GPU acceleration, it is fully rendered on the CPU. It basically uses the default processing.org 2D renderer.

Now, I don't know what spec his computer has, but software only 2D renderers are generally pretty slow. So 20fps isn't bad.

Anyways, I agree it's a weird way to show a language's performance. Like I said, Clojure will run around 10% slower than pure Java in most cases. Which is pretty fast, since Java is arguably the most performant GC language around.

Re: Why Clojure?

#187

Post by didibus » Sun, Aug 25, 2019, 11:49 PM UTC

dkersten wrote: post #175

didibus wrote: post #153

Earlier quoted context omitted.

Very interesting, and thanks for answering. Could I ask what kind of project it is? I wonder if I'm just lucky that Clojure fits perfectly my use case, which is mostly a set of distributed systems of all kinds. So while as a whole there's tens of thousands of LOC. The components have very strong boundaries being as it's a set of services assembled together through RPC, PubSubs and DBs. Maybe that alleviate the lack o…

I’ve written a lot of different Clojure projects over the years. Some large, some small. Back in 2013–2015 I ran a startup entirely on Clojure(script). My current project is an automation service for cryptocurrency trading bots (that is, all the infrastructure, automation, configuration, dashboard etc for running a bot, but the bot strategy and signals are up to the user — hence automation tool, not bot). It’s a larg…

It's not as simple as that. There are no typed Lisps, even though Lisps have been around since the 60s. That's not just coincidental in my opinion. The closest to a typed Lisp are gradual typed Lisp, like Typed Racket, and that is very similar to how Core.typed does it. There is Shen as well. Carp is the first strongly typed Lisp I'm seeing, and it is experimental and might never take off.

The issue is how would type definitions be introduced, and what kind of types would be most appropriate? As you said yourself, the way core.typed did it felt too "heavy". Yet it isn't clear how to make a more lightweight variant for a Lisp language such as Clojure without rendering the types worthless.

The first, and one of the biggest issue in my mind, is that what everyone loves about Clojure is the data-oriented style. In that style, you represents entities and their relationships using heterogeneous collections. That's where in Clojure you model your domain with Maps, Lists, Vectors, Sets, etc. It is awesome, but no one has figured out a non "heavy" way to statically type it. All methods I know of have bad programmer ergonomics. In effect, adding types back to it almost kills the data-oriented style, and it ends up feeling a lot like modeling with Classes instead. See Haskell's wiki section on this problem: https://wiki.haskell.org/Heterogenous_collections they haven't solved it, and have multiple ways to possibly handle the scenario, and non are ideal.

> I want a language that makes the exact same decisions and tradeoffs as Clojure, except on dynamic vs static types

I would too, but with the caveat that the development experience would be the same, and the programming ergonomics and styles would be retained. And this, I'm afraid, is an open problem that no one has solved yet. It's not just a case of personal preference. Having a language which has the pros of Clojure and the pros of static types, without the cons of static types is hard. That's why for now, you need to choose one or the other.

Re: Why Clojure?

#188

Post by yakshaving_jgt » Mon, Aug 26, 2019, 7:31 AM UTC

iLemming wrote: post #184

yakshaving_jgt wrote: post #164

Earlier quoted context omitted.

Hey, I won’t deny that it takes a relatively long time to learn Haskell to a standard where you’re comfortably writing web applications with it. I’m not sure how that’s a rebuttal to my point though. I run a startup. I’ve already put the time in to learn the technology. I’ve learned other technologies too. This one happens to be the one I find the cheapest (now) to write. Did it take my employees a long time to learn…

Alright, jokes aside, let's not get into "measuring dicks" and argue which one is better. I know Clojure, and I know some Haskell. I love both. They both have their strengths and weaknesses. To be honest - I always find things in one that I wish existed in another and vice versa. But your simple dismissal of Clojure (even though seem to be an educated one) has no merits. Don't feel bitter because Clojure is growing i…

> But your simple dismissal of Clojure has no merits.

I believe it has an impact on my business' bottom-line. Saving money in business is a merit.

> Don't feel bitter because Clojure is growing in popularity and Haskell seems stagnated.

That… was an odd take. I'm not sure what gave you the impression that I would be bitter about Clojure growing in popularity (not that I think it is, anyway). I have nothing invested in Clojure not being a popular language, and the idea that Haskell has stagnated is a little hilarious.

> Haskell is great, and Clojure is fantastic too.

Again, I have never denied Clojure's merits. My position is pretty simple — I have found it cheaper to build Internet software businesses with Haskell than with Clojure.

Re: Why Clojure?

#189

Post by kickopotomus » Mon, Aug 26, 2019, 4:10 PM UTC

slifin wrote: post #173

kickopotomus wrote: post #79

Earlier quoted context omitted.

This has been my experience as well. I have a couple of Clojure(Script) applications that are approximately 3-5K lines each and those have been a pleasure too work on. However, my latest project is now pushing past 20K lines and the mental load has jumped exponentially. There is a much greater need for spec, asserts, type hints, and comments just to keep everything straight.

That's interesting do you have any idea why the mental load jumped? would a static analysis tool working with your type hints help? Or is there many things to consider at once in the system instead of many individual things?

The biggest issue I keep running into is just the concept of data "shape". I love that clojure gives you so much freedom but it can be quite the footgun in a large system because you see that a function expects a map with keys :foo, :bar, and :baz but what are the values for those keys? Spec helps a little bit here for primitive values but for complex nested structures (e.g. {:a [{:b [1 2]} {:c "bar"}]}), it doesn't do much. So, as data moves through the system, and as the system grows it has become increasingly difficult to track the mutations to the underlying structures.

I do think that a static analysis tool would be of some help. Some sort of tooling to better handle tree structures would be very handy. I often find myself being off-by-one level with get-in calls on tree data (E.g. (get-in m [:a :b :d]) where m is {:a {:b {:c {:d 1}}}}), which is annoying because the NPE gets thrown 3 function calls up the stack.

Re: Why Clojure?

#190

Post by beders » Mon, Aug 26, 2019, 8:36 PM UTC

pbiggar wrote: post #53

fsloth wrote: post #12

Can anyone give a pro/cons analysis of a ML variant versus of a Lisp variant. Let's say F# versus Clojure? One of the general arguments in Lisp vs the world is that lisp is more concise. F# is really concise. It has datastructures as intrinsic part of the language syntax (just like Clojure, i.e in F# [|,,,|] is an array and in Clojure [...] is a vector, so more or less the same thing). Furthermore, the type inference…

My previous startup (CircleCI) was written in Clojure, my current one (Darklang) is written in OCaml. I decided not to use Clojure again because it's not statically typed, and my number one frustration when I coded in the CircleCI codebase was that it was very very hard to know what shape a value had, and whether it could be null. OCaml certainly has a lot of flaws, and is not nearly as "nice" a language as clojure,…

Ghostwheel to the rescue

(>defn my-fun [a b] [int? -> int?])