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

151–160 of 306 posts

Re: Clojure: A Lisp that wants to spread

#151

Post by peferron »

modarts wrote: post #104
peferron wrote: post #100

Earlier quoted context omitted.

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…

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.

Re: Clojure: A Lisp that wants to spread

#152

Post by bambataa »

lgrapenthin wrote: post #143
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…

Instead of just measuring how many developers adopt Clojure and how difficult/easy that is, I'd also love a measure of how many developers Clojure "puts out of business". IME Clojure is quite aggressive on that front. In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired an…

Were they fired because they weren’t good enough at Clojure? Perhaps all Clojure did was filter out less capable performers. The small team of skilled developers might have been just as fast in Java if they weren’t encumbered by the mediocre ones.

Re: Clojure: A Lisp that wants to spread

#153

Post by keymone »

yarrel wrote: post #64

The dealbreakers with Clojure for me are: 1. Weirdly irregular syntax. 2. Java import statements and Java error backtraces anywhere you want to do real work. 3. Inexcusable renaming and name collisions on basic Lisp functions. It's much, much less of a Lisp than Scheme and neither "but it's properly functional" nor "we fixed the tooling now" make that any less true or the language any more interesting for the use cas…

1. Elaborate please

2. If you’re writing a wrapper to existing java lib maybe

3. Tough to be a particular lisp fanatic I guess.. Clojure helped me to get into lisp big time and all other lisps now feel clunky and inelegant.

Re: Clojure: A Lisp that wants to spread

#154

Post by lincpa »

Clojure is a FP (Lisp) language based on RMDB theory, which is very suitable for dataflow and data-driven programming, so it is suitable for large-scale industrialized pipeline software development using Warehouse/Workshop Model model.

https://github.com/linpengcheng/PurefunctionPipelineDataflow

Re: Clojure: A Lisp that wants to spread

#155

Post by peferron »

escherize wrote: post #105
peferron wrote: post #99

Earlier quoted context omitted.

Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.

Clojure has while loops, but I think I see where you're coming from: It is a significantly different approach to programming, and if an engineer is not willing to re-jigger their style Clojure is not going to be a good fit for them.

I meant that they won't even try.

Re: Clojure: A Lisp that wants to spread

#156

Post by devin »

stingraycharles wrote: post #136
billfruit wrote: post #131

Earlier quoted context omitted.

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur c…

> Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn. This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.

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 change the build tool. I have worked with them, and the attitude was always pragmatic > dogmatic.

Where I will agree with you is that some folks in the community took an alpha release of tools.deps and treated it like it was the new lein or boot. It isn’t. It’s different, and as a Clojure programmer of 10+ years I use it in exactly 0 production projects. That said, it improves greatly upon “lein checkouts” by allowing one to refer to git SHAs as versions and do cross-project interactive development.

Re: Clojure: A Lisp that wants to spread

#157

Post by Naomarik »

billfruit wrote: post #131
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…

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur c…

WSL2 is great. Recently moved off MacOS to do all my dev work work on Windows.

Re: Clojure: A Lisp that wants to spread

#158

Post by lincpa »

hota_mazi wrote: post #98
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…

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…

Programming is like an exam. Good students know where errors might occur after they write code. Bad students do not know whether they are right or wrong and where they are wrong. Therefore, a variety of complex and lengthy error checking systems, such as static type systems. But this is a costly effort with little effect.

Re: Clojure: A Lisp that wants to spread

#159

Post by simongray »

mikelevins wrote: post #92
simongray wrote: post #58

Earlier quoted context omitted.

The common talking points are * Clojure is based on seqs rather than cons cells. * Clojure renamed certain common functions, like car and cdr, so 30 year old Lisp example code no longer compiles. * Clojure doesn't have implicit tail call optimisation for recursion. * Clojure reveals its host platform when it has runtime errors.

This list doesn't strike me as the important things that Clojure is missing. They're all relatively minor matters. There are several other things that I would consider much more important. I've gone on at some length about those things before (for example, see my long comment in this thread: https://news.ycombinator.com/item?id=22318748 , ), so I won't repeat it here. I'll just say that Clojure is pretty nice as far…

> I daydream about a Clojure with the missing pieces filled in

Be the change you want to see in the world and start filling in the missing pieces! ;-)

Re: Clojure: A Lisp that wants to spread

#160

Post by stingraycharles »

devin wrote: post #156
stingraycharles wrote: post #136

Earlier quoted context omitted.

> Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn. This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.

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.

Post reply on HN