Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Six years of professional Clojure development

falkoriemenschneider.de

Post reply on HN
Print view View original

141–150 of 209 posts

Re: Six years of professional Clojure development

#141

Post by Scarbutt »

fnord123 wrote: post #61
joelbluminator wrote: post #11

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

You're both wrong. If it was dynamicism then why are JS, Python, and Ruby so popular? If it's about being functional then why has Scala got more users? Languages are driven by the platform. There is no Clojure platform that people want to use, so no one uses Clojure. If a language isn't bound to it's own platform, it can share a platform and displace other tools like python, go, and rust do with C and C++ (docker is…

Your hello world actually took one second to start, add libraries for a web application and you will be hitting 2-3 minutes of startup time.

Re: Six years of professional Clojure development

#142

Post by SatvikBeri »

Siira wrote: post #102
YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

Check out Julia; It has built-in optional static typing, a fast JIT, it can be run interactively in the same style as Clojure, and it supports lisp-like macros.

I use & love Julia, but it doesn't have really static typing – it has runtime validation based on type annotations. For static typing to be useful, IMO, you need static typechecking, usually done at compile-time.

Re: Six years of professional Clojure development

#143

Post by kaliszad »

capableweb wrote: post #14
joelbluminator wrote: post #11

Earlier quoted context omitted.

I don't think it's about it's dynamicism but more about it being functional. Plenty of super popular dynamic languages out there. I think that's also what keeps elixir from becoming something more mainstream, most people come from OOP and are used to thinking about programming that way.

Both of you miss the most obvious difference between Clojure and all mainstream languages: it's a lisp. I've had so many programmers look at code I write and proclaim: "wow that looks impossible because of the parenthesis" and that would never touch anything like it because it seems so different. Some people do take the time to learn how it works, but many just have a knee-jerk reaction to it and then forget about th…

Well yes. Clojure in general tends to have less special syntax and in general is designed very consistently. What I find very useful is the threading macro ->> and -> which basically is a pipeline:

(-> something (manipulation-of-something) (nextmanipulation) (anothermanipulation))

instead of:

(anothermanipulation (nextmanipulation (manipulation-of-something something)))

Often, you can remove some parenthesis in the first case as well.

I really love this. It is also very easy to just wrap it in a let or a function. This alone should open the eyes of anybody, who has written at least some Shell script somewhere or does some data analysis. If it doesn't, maybe the person isn't actually that great of a thinker or a practitioner and you would be better off around other people professionally. Frankly, who are the people, who cannot grok moving the opening parenthesis before the method/ function? I don't think I have ever met anybody like that - I only read/ hear about such people in comments or at conferences and I haven't heard a name yet.

Re: Six years of professional Clojure development

#144

Post by mark_l_watson »

pjmlp wrote: post #130
mark_l_watson wrote: post #96

Earlier quoted context omitted.

Well, I owned a Xerox Lisp Machine from 1982 to about 1987. True, a great programming environment, but the situation is so much better today. For example, I own a LispWorks Professional license, and the support and quality of the product is fantastic. My friends at Franz have similar quality products like Allegro and AllegroGraph. Even Clojure+Cider or Haskell+Intero or Haskell+VSCode (easiest to set up) is arguably…

Yeah, let me take the opporunity to thank you for the books.

you are welcome!

Re: Six years of professional Clojure development

#145

Post by mapgrep »

comma_at wrote: post #88
mapgrep wrote: post #80

Earlier quoted context omitted.

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.

>The whole point of running inside another ecosystem is to reuse existing solutions

Ya totally, but I think OP was hinting at a fundamental tension between this benefit of interop and the desire to be functional where Java is (generally) not. Clojure lets you reuse the wonderfully huge library of Java solutions -- but those solutions are (generally) not written with immutability in mind, which I could see becoming an issue when you're trying to write a concurrent app. I suspect that's what the java.lang.Object reference was about, although obviously I'm not sure.

>Many wrappers hide mutability and provide an immutable API. And more java libraries are being written with immutable classes.

All that sounds encouraging....

Re: Six years of professional Clojure development

#146

Post by _6pvr »

slifin wrote: post #77
YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

- Clojure without clj-kondo - PHP without phpstan/psalm/phan All bad ideas, modern tooling can detect errors in your code before you finish your code expression, but you do need to go out of your way to setup it up Most people do not and then complain about types instead of talking about static analysis If you are ever coding Clojure you should be following this: https://github.com/clj-kondo/clj-kondo/blob/master/doc…

It seems like if a tool is so essential to successful development in a language, it should probably not be a 3rd party library but instead baked into the language tooling itself, no? (I have never used Clojure and am not trying to be inflammatory)

Re: Six years of professional Clojure development

#147

Post by _6pvr »

YuukiRey wrote: post #15

Clojure is the most enjoyable language I've ever used and I love the interactive development. I haven't written code in any other language that even comes close. Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or…

> Unfortunately I am too lazy and careless to use Clojure in any serious capacity though. I really need a Haskell or Rust compiler to remind me of all my silly mistakes. I can't be trusted to get to the same level of confidence through unit tests or linting or spec or malli.

I think most developers cannot be trusted to make these mistakes, I wouldn't call it "careless or lazy". Languages exist with tools baked into them to prevent slip ups. Why wouldn't you want to take advantage of that tooling?

Also, as a result of this comment section, this is the second time in the past week that I've seen the suggestion to use 3rd party typechecking/static analysis tooling in a dynamic language, which (to me) brings up the question: Do you really want a dynamic language, or do you just want the ability to be careless intermittently? There is no shame in saying "I just want to get happy-path code working quickly". There is joy in getting happy path working quickly. I just think, as a codebase in a dynamic language grows, codebases seem to build lots of tooling to make that dynamic language less dynamic.

Re: Six years of professional Clojure development

#148

Post by comma_at »

jeofken wrote: post #132
comma_at wrote: post #83

Earlier quoted context omitted.

> 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…

Language design is about what features not to include. If you include blocking IO, or allow unsound programs, disallow GC-less allocations, you are forcing a model of programming onto the user, which is a good thing. Node.js became a hit because it lacked the feature of blocking IO. Having many choices available, and teams of maybe 50-100 good mates coming and going, and a period of 5-7 years, has a high likelihood o…

I agree, constraints often bring benefits. The question for a language is which ones to bring in and which ones to leave open. From that perspective I value clojure's choices (and don't value js every-io-is-a-callback design).

Any project of the size you mention needs technical leadership and constrained choices (for IO we use this, we do http this way..). This will be true regardless of what language you're using.

Re: Six years of professional Clojure development

#149

Post by eigenspace »

SatvikBeri wrote: post #142
Siira wrote: post #102

Earlier quoted context omitted.

Check out Julia; It has built-in optional static typing, a fast JIT, it can be run interactively in the same style as Clojure, and it supports lisp-like macros.

I use & love Julia, but it doesn't have really static typing – it has runtime validation based on type annotations. For static typing to be useful, IMO, you need static typechecking, usually done at compile-time.

This is a common point of confusion for people. Julia has a useful and expressive type system, so people just assume it must be static but it's not, julia is dynamically typed.

It's intermediate representation is statically typed, but the language itself has dynamic semantics.

That said, we have almost every trick and tool up our sleeves that static languages have (in various stages of development). Check out https://github.com/aviatesk/JET.jl if you want static typechecking of julia code.

Re: Six years of professional Clojure development

#150

Post by draklor40 »

mumblemumble wrote: post #113
draklor40 wrote: post #106

Earlier quoted context omitted.

> This is what I run into. But that's not exactly a dynamic language problem. It's more of a data-oriented programming (in the Clojure sense) problem. Yes, all dynamic languages have this problem. I have transitioned to statically typed languages and it has been very peaceful so far :)

To go at it from another angle: I'm working in a relatively large Java codebase that also likes to pass around generic ad-hoc data-structures such as maps. And I'm having exactly the same problem problems there. Static typing does nothing to help the situation. I realize that data-oriented programming is more likely to happen in dynamic languages. But correlation is not causation.

IMHO Static typing => structure, not necessarily Map (which is also a type). Shaping data is quite important and having an associative array doesn't necessarily means that the data is shaped.
Post reply on HN