Six years of professional Clojure development • Hacker News Board

Re: Six years of professional Clojure development

#81

Post by draklor40 » Thu, May 06, 2021, 2:09 PM UTC

yogthos wrote: post #70

draklor40 wrote: post #39

Earlier quoted context omitted.

I wrote Clojure for 4 years. I understand your pain points. Dynamic types are an impediment beyond a certain code size.

My team structures projects by breaking things up into small isolated components that can be reasoned about independently. We'll often do it at the level of namespaces, where a namespace will describe a particular workflow or data transformation, and namespaces tend to be 500 lines or less. It's a similar idea to microservice architecture without the overhead of having to actually split the application up into separa…

``` breaking things up into small isolated components that can be reasoned about independently ``` - This is insufficient for the same reasons unit tests are not enough and you also need integration tests. The moment you cross namespace boundaries, you will end up not setting keys /entries in maps , missing logic etc and end up needing something like Spec/Schema....

Re: Six years of professional Clojure development

#82

Post by cies » Thu, May 06, 2021, 2:11 PM UTC

jeofken wrote: post #56

cies wrote: post #33

Earlier quoted context omitted.

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

In real life projects, you end up doing type checking at runtime, meaning you also need a test for the code path

Exactly! More developer discipline required.

What ever can be checked by the compiler, as part of the language, is automatic free productivity to me.

Re: Six years of professional Clojure development

#83

Post by comma_at » Thu, May 06, 2021, 2:11 PM UTC

jeofken wrote: post #54

Kototama wrote: post #35

Earlier quoted context omitted.

What is mutable by default in Clojure? Nothing. You need to explicitly declare mutable variables with a special notation. Are you talking about the underlying VM? Yes, the Java API are mutable, not surprise here, it's not Haskell. Imperative? What is imperative by default in Clojure? Nothing. It's one of the least imperative Lisp, favoring functional constructs all over the place unlike Common Lisp or even Scheme. Bl…

> What is mutable by default in Clojure? Nothing. All data in Clojure inherits from java.lang.Object. I get what you’re saying, but in real life commercial projects, especially when you use libraries and Java classes, the code ends up with a lot of mutable things. You can never know if any function you call does mutate something without keeping all definitions in your head, and with 20+ people on the project, this is…

> I for sure prefer to write a backend where no teammates ever introduce blocking calls.

Please note that forcing an execution model in the language will inadvertently cause headaches for some kinds of domains. Since clojure makes no wild choices the language can be ported to other runtimes (.net, js) and benefit from future runtime improvements without breaking the language (JVM virtual threads, value types).

Since the core is small and lisps are extensible, we can have a multitude of choices in libraries. So if you really like typy things you can check out core.typed, spec, schema, malli etc. If you want async you can check out manifold, promesa, core.async etc. If you want non-blocking effects handling you can check out missionary or darkleaf/effect.

Re: Six years of professional Clojure development

#84

Post by cies » Thu, May 06, 2021, 2:13 PM UTC

joppy wrote: post #37

cies wrote: post #33

Earlier quoted context omitted.

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

If you constantly work on the same code base day-in, day-out, breakage through the language or libraries is much less of an issue. You can keep up with current developments in the language and/or libraries, and update as necessary. Incremental changes are not a big deal, since you’re always around when they happen. If you tend to write code once, and come back to it months or years later, breakage is a huge issue - w…

Dont break things merely exaggerated as a requirement in dynamic typed langs.

Re: Six years of professional Clojure development

#85

Post by YuukiRey » Thu, May 06, 2021, 2:14 PM UTC

truth_seeker wrote: post #68

Why is everyone making a big deal out of dynamic nature of Clojure as the main factor to not consider it in enterprise project ? As if no dynamic language has ever succeeded in creating enterprise application which runs 24X7 !!! If you don't like maps use clojure records If you don't want free floating initiation or ambiguous variables and arguments to function in code, use type hints. Type hints may not be exact alt…

I assume you're referring to my comment, since I mentioned both Haskell and Rust.

_I_ am not capable of writing a robust, large scale application in a dynamic language. I do not have the discipline to second guess everything I do. I will at some point forget to write certain tests. Or test only the happy path. Or make a silly typo. Maybe I'll rename a keyword and in one place not notice that I'm renaming a keyword that will come from a completely different map. Or I'll forgot to namespace keywords and wonder where they come from.

I have no doubt that there are people who can write rock solid stuff in C, or Bash or Dash.

I can't. Therefore, yes, its dynamic nature is what leads me to rule out Clojure. I want to be lazy and focus on the logic, the algorithms and data structures. I do not want to be my own compiler because I'm not good at that.

Re: Six years of professional Clojure development

#86

Post by slifin » Thu, May 06, 2021, 2:14 PM UTC

lukashrb wrote: post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

PHP and JavaScript and Python are also dynamically typed the solution isn't yet another incompatible type system, there are so many type systems that don't work together, spec is also turing complete

Turing completeness in a type system allows you to use the type system as a meta coding language which is a fantastic amount of string to hoist yourself with, putting meta languages inside languages is a miserable place to be

I'd argue that most people just want the language to check for mistakes, clj-kondo is great and effective at doing this https://github.com/clj-kondo/clj-kondo/blob/master/doc/edito...

If you want types at your system boundaries like on your API then specs or malli is great for that

A great thing that Rich Hickey always advocated is separating out problems and then solving them individually I think modern type systems try and take on too many problems at once, static analysis tools are great because they're uncoupled by time and are laser focused on detecting mistakes only

Re: Six years of professional Clojure development

#87

Post by cies » Thu, May 06, 2021, 2:15 PM UTC

comma_at wrote: post #62

cies wrote: post #33

Earlier quoted context omitted.

I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day. From the article I see a lot f reasons why: > "Don't break things!" is part of the culture. If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and th…

> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things). Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kern…

Cabal hell is fixed with tooling. Part of that tooling is running tests, but a large part of it is "it compiled together so it should work together" (which is a safety dynamic typed langs dont offer).

Re: Six years of professional Clojure development

#88

Post by comma_at » Thu, May 06, 2021, 2:17 PM UTC

mapgrep wrote: post #80

jeofken wrote: post #54

Earlier quoted context omitted.

> What is mutable by default in Clojure? Nothing. All data in Clojure inherits from java.lang.Object. I get what you’re saying, but in real life commercial projects, especially when you use libraries and Java classes, the code ends up with a lot of mutable things. You can never know if any function you call does mutate something without keeping all definitions in your head, and with 20+ people on the project, this is…

Thank you for these comments they are super interesting to me as a relatively new Clojure programmer. Can I ask two related questions - 1. Reading between the lines it sounds like the mutability issue arises from interop, both in the core code and any dependencies that wrap Java? 2. If yes, curious why did the folks involved did not write native Clojure libraries to eliminate the (worst?) blocking dependencies (or pa…

The whole point of running inside another ecosystem is to reuse existing solutions. Many wrappers hide mutability and provide an immutable API. And more java libraries are being written with immutable classes.

I also failed to understand the "everything is a java.lang.Object" sentence. It doesn't make a clojure map mutable. In the end it's all just ones and zeroes, but that misses the point.

Re: Six years of professional Clojure development

#89

Post by pjmlp » Thu, May 06, 2021, 2:18 PM UTC

thomastjeffery wrote: post #71

pjmlp wrote: post #10

Earlier quoted context omitted.

JVM and .NET are the top runtimes with best in game GC implementatios, JIT compilers, JIT code cache, and monitoring tools for production code. In fact plenty of them, given that there are multiple implementation to choose from. Meanwhile other languages keep playing catchup and having to rewrite extensions in C.

The runtimes themselves may be great, but the tooling is bloated and uncomfortable. Every time I use Clojure, I am reminded how much I hate using Java. The error messages alone are enough to turn me away. So is having to set up a whole Leiningen project just to get started. A Clojure without Java would be very attractive to me.

There is nothing else that gets close to the world promised to us by Xerox PARC.

Don't blame Java for the issues that are Clojure's fault.

The only Lisps that can match such tooling are Allegro and LispWorks.

Re: Six years of professional Clojure development

#90

Post by mark_l_watson » Thu, May 06, 2021, 2:19 PM UTC

nonbirithm wrote: post #16

lukashrb wrote: post #6

Nice article. Sadly a lot of people won't even try clojure since it is dynamic typed. I see their point but nevertheless clojure does something really well here. As the author obserserves designing around some core data structures results in high code reuse. A library like spec is also way better in encoding business requirements than all the mainstream language typesystems e.g. a number in business context has mostl…

Can we have a REPL-driven language that's statically typed? My hope is yes, in that it's just that the work hasn't been put in yet to create to create the equivalent of Typescript for Clojure or Lua that compiles down to the actual, extensible language. I always wish that it would become unnecessary to have to choose between stability and extensibility when selecting a programming language. Having a Clojure with stat…

As I said elsewhere in this thread, Haskell has a good REPL dev experience. Personally, I am a much better Lisp programmer (used Lisp languages since around 1978) than Haskell. My journey learning Haskell is almost a decade long, and still I am no where near as productive as using Common Lisp. I find that Clojure is usually a high productivity language, but I get stuck sometimes on platform details and that gets me out of a flow programming experience.

If you want to try Haskell, work though a few tutorials and if it looks good, you can grab a free copy of my Haskell book https://markwatson.com/opencontent/haskell-cookbook.pdf There are much better Haskell books than mine though, my book just reflects my own learning process.