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

Clojure: A Lisp that wants to spread

simongray.github.io

Post reply on HN
Print view View original

181–190 of 306 posts

Re: Clojure: A Lisp that wants to spread

#181

Post by dragandj »

stingraycharles wrote: post #160
devin wrote: post #156

Earlier quoted context omitted.

That’s an exaggeration. You’re not entirely wrong, though. First, it is not called deps.edn, it is called tools.deps. Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not ch…

Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.

Does it matter when all these tools are compatible (on the level of artifacts and distribution repository)?

Re: Clojure: A Lisp that wants to spread

#182

Post by roenxi »

tensor wrote: post #26

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has man…

The other interesting problem is that the experts are using tools and concepts that are a long way away from a beginner and that can make it harder for beginners to learn. In Clojure when a beginner wants to accomplish a task their biggest problem is that they are solving the wrong problem or being pushed to deal with problems they don't understand.

Case in point the var/agent/ref system is fantastic and probably critical to how to think about Clojure projects - but the problems being solved by it are a long way away from the concerns of someone at the beginner-intermediate type level. They don't need to solve multithreading right now. They don't see their data model as an urgent priority.

Compare that to Python where most of the core language is (1) call function, solve problem or (2) feature does something you could already do but with a little less typing.

I prefer Clojure but it is easy to see that the lack of an opinionated onboarding process is going to hurt the language.

Re: Clojure: A Lisp that wants to spread

#183

Post by engineeringwoke »

lincpa wrote: post #161

You need a well-organized linear pipeline system, this is "The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model"

I hope you realize that this is complete nonsense to anyone that isn't part of your new "new" functional programming cult. It has almost no semantic meaning.

Re: Clojure: A Lisp that wants to spread

#184

Post by engineeringwoke »

peferron wrote: post #151
modarts wrote: post #104

Earlier quoted context omitted.

spec

Describing the Clojure dev team as "trying very hard to catch up to statically typed languages by retrofitting some type system" because they work on spec is pushing a narrative that I doubt they'd agree with, both regarding spec's goals and its rhythm of development.

I'm not thinking highly of any narrative that the Clojure dev team believes. It is the pièce de résistance of the new "new" functional programming cult, which is in fact very old school.

Even just parroting some of the memes from this thread like "static types only prevent 2% of bugs" and "you can replace 12 developers with 3 amazing (italics) Clojure developers" and "a Clojure developer can replace any kind of developer!" means you don't have to make up absurd viewpoints to argue the contrary. These trends are old as time and completely nonsensical.

Re: Clojure: A Lisp that wants to spread

#185

Post by _xt8z »

engineeringwoke wrote: post #183
lincpa wrote: post #161

You need a well-organized linear pipeline system, this is "The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model"

I hope you realize that this is complete nonsense to anyone that isn't part of your new "new" functional programming cult. It has almost no semantic meaning.

I definitely saw nothing but sarcasm in the comment you are replying to.

But now after looking at their other comments, I see it was not sarcasm.

What an understatement for how messy functional programming can actually be.

Re: Clojure: A Lisp that wants to spread

#186

Post by stingraycharles »

dragandj wrote: post #181
stingraycharles wrote: post #160

Earlier quoted context omitted.

Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.

Does it matter when all these tools are compatible (on the level of artifacts and distribution repository)?

For the experienced user, it doesn't matter. But for the newcomer, it's one more additional choice to make, and, as the grandparent said, is in sharp contrast to a "batteries included" approach you see in Python. Given that build tooling is one of the more frequent complaints, more fragmentation in this area is undesired.

Re: Clojure: A Lisp that wants to spread

#187

Post by [deleted] »

peferron wrote: post #100
hota_mazi wrote: post #98

Earlier quoted context omitted.

I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never…

Python and JS succeeded long before they had a static type system. Many people still use Python and JS today without type annotations. Elixir is not statically typed either and seems to be doing fine. I like static typing and agree that it will eventually "win", but I really don't see where you're coming from here. > I know it's trying very hard to catch up to statically typed languages now by retrofitting some type…

[deleted]

Re: Clojure: A Lisp that wants to spread

#188

Post by pgt »

The most interesting Clojure-like language around is, IMO, Carp[^1]. Carp is a Lisp written in Haskell that compiles down to C with Rust ownership semantics and looks like Clojure. So you get a GC-less Lisp with fast startup time that is suitable for game development with the safety guarantees of Rust.

[^1]: https://github.com/carp-lang/Carp

Re: Clojure: A Lisp that wants to spread

#189

Post by engineeringwoke »

_xt8z wrote: post #185
engineeringwoke wrote: post #183

Earlier quoted context omitted.

I hope you realize that this is complete nonsense to anyone that isn't part of your new "new" functional programming cult. It has almost no semantic meaning.

I definitely saw nothing but sarcasm in the comment you are replying to. But now after looking at their other comments, I see it was not sarcasm. What an understatement for how messy functional programming can actually be.

I thought he was joking at first too and googled it to find out that he was in fact serious.

Re: Clojure: A Lisp that wants to spread

#190

Post by armitron »

abrax3141 wrote: post #86

I don’t actually get the big deal about enforced immutability. Of course, you need to constrain yourself in certain circumstances to do things immutably, but it seems like something that should be contextual (immutably ...), rather than enforcing it. In fact, sometimes it is necessary in high performance multi—threaded/multi-processor environments to use side effects judiciously. Moreover, most serious lisp programme…

Most serious Lisp programmers write mutable code. Common Lisp is multi-paradigm but most code written has side-effects. And that’s for a good reason: Clojure-style immutable programming doesn’t fit most problems very well. Which is why Clojure will never be a language with the lasting power of Common Lisp. It prematurely optimizes and constrains your thinking into a single paradigm.
Post reply on HN