Live data from Hacker News

Is Clojure dying, and what has Ruby got to do with it?

lambdaisland.com

71–80 of 261 posts

Re: Is Clojure dying, and what has Ruby got to do with it?

#71

Clojure's not dying, but it's also not thriving[1]. I think it will continue on as a solid niche language for the foreseeable future, but it's highly unlikely that the language will grow by leaps and bounds barring some must-have innovation in the Clojure language and/or ecosystem that gets the tech world to take it more seriously. There are so many options these days that it's tough to stand out from the crowd. Cloj…

I don't really have anything to say about your other points, but the only comparable compile-to-JS tech in your list to ClojureScript is Scala.js. The other options assume you don't see significant value in using the same programming idioms across client and server.

As someone who chose ClojureScript over many of the other compile-to-JS languages without using Clojure on the server, I disagree.

Especially if ClojureScript could become more attractive than (or at least have a real solid standing amongst) Elm/PureScript/etc., I could see that being a big boon to Clojure development as well.

Re: Is Clojure dying, and what has Ruby got to do with it?

#72

I'm still left with the question of "why all the parenthesis?" While it might sound silly and reductionist, it is ostensibly the single hurdle I could never overcome when it came to lisp languages. The majority resides with the fact that it could work without them, so I see it as an ancient artifact.

Contrast, for a moment: var x = fib(a, b); with (let x (fib a b)) And count the delimiting symbols. I count 5 in the first example. In the second, I see 4. Let's try something a bit harder. function(a, b) { return a * b; }(6, 4); vs. ((fn (a b) (* a b) ) 6 4) 10 first, 8 second. Yes, "why all the [symbols]" indeed.

[deleted]

Re: Is Clojure dying, and what has Ruby got to do with it?

#74
post #68
post #63

Earlier quoted context omitted.

Sure, but that's the point: if Datomic is "the best thing Clojure's got" as far as killer-apps go—and it's not really that important to the community—then Clojure doesn't really have a killer app. A killer app is something that looks like Rails does in Ruby, or Phoenix does in Elixir: a thing where 50%-or-more of the people learning the language are only learning it in the context of using that one framework, and so…

Clojure, and lisp in general, tends to avoid the "framework" way of thinking prevalent among object-oriented languages. It's therefore no surprise that something like Rails hasn't taken off. There are, however, libraries and patterns which are very common, ring for example.

I'm not sure that Clojure avoids it, per se; a framework isn't something you set out to build by saying "this shall be a framework." A framework is just a library, exposed directly as functions and data in a given runtime, that has enough internal structural complexity and "active" logic that the framework offers high-level abstractions that pre-compose its components into functional arrangements, rather than expecting you to DSL-glue them together yourself.

Consider: OpenGL/DirectX are essentially "frameworks." They rely on you to specify the high-level (scenes) by calling the library APIs; the library does the medium-scale logic of managing the GPU; and then the library calls back to your code (shaders) to get the low-level details of textures and vertices specified to it. That's a framework! And there's really no way that it could be anything other than a framework.

If Clojure doesn't have any "frameworks", that's not because Clojure does something to avoid making libraries into frameworks; it's more because nobody has built a library that inherently is a framework, specifically for Clojure.

Re: Is Clojure dying, and what has Ruby got to do with it?

#75

I'm still left with the question of "why all the parenthesis?" While it might sound silly and reductionist, it is ostensibly the single hurdle I could never overcome when it came to lisp languages. The majority resides with the fact that it could work without them, so I see it as an ancient artifact.

Contrast, for a moment: var x = fib(a, b); with (let x (fib a b)) And count the delimiting symbols. I count 5 in the first example. In the second, I see 4. Let's try something a bit harder. function(a, b) { return a * b; }(6, 4); vs. ((fn (a b) (* a b) ) 6 4) 10 first, 8 second. Yes, "why all the [symbols]" indeed.

For your second example, your JavaScript is wrong. Let's compare the ES2015 JavaScript:

  ((a, b) => a * b)(6, 4);
...against the Clojure:

  ((fn [a b] (* a b)) 6 4)
Not a lot in it, really, is there?

Re: Is Clojure dying, and what has Ruby got to do with it?

#76
post #49

Clojure's "killer feature" for me is the by-default persistent data structures. Are there any other functional languages out there with similar features? Lisp or otherwise.

Elixir has that, and you can't even drop into Java/JVM mode to violate it! ;)

Haskell as well, I believe.

Re: Is Clojure dying, and what has Ruby got to do with it?

#77

I think Clojurescript might be the thing. With advances in the Google Closure compiler, it's getting better and better. And the front end developer tools and libraries in Clojurescript are _the best_ out there. The holy grail for javascript exists in Clojurescript. Until then I'll keep making my Javascript env look like Clojurescript. With janky react devcards, Immutable.js, and react-redux.

Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on top of JS, there would seem to be a path for the CLJS(not clj) tooling to become more JS ecosystem friendly. For the JS developers out there, is this something that's of interest? Or is the existing tooling(lein) good enough? What would be your ideal tooling s…

As a JS developer using CLJS in my spare time, I've found that once I got my project setup with figwheel and everything, I can pretty much ignore the JVM. The moment that "classpath" is mentioned I usually try to find another way, though.

Re: Is Clojure dying, and what has Ruby got to do with it?

#78
post #12

clojure's killer app, datomic, is closed source in my opinion, this is a key reason, why clojure is not thriving i can't think of any (problem) domain, where clojure have a framework or library, than is significantly better than most other frameworks or libraries if you are not number 1 at anything, it is hard to thrive

I use Datomic everyday. While it's certainly a stunning piece of technology and you could pry it from my cold dead hands, I don't think it has that much bearing on the growth of the Clojure community.

I have spoken to many developers from other programming communities and many of them admire Datomic at least in principle. Hell, as an Elixir guy, the first time I had to talk to the DB was jarring because it was "oh shit, it's a deep mutable data puddle again"

Datomic should be open-source. They could always consult around it to continue making money on it.

Re: Is Clojure dying, and what has Ruby got to do with it?

#79
post #29

> Elm, Elixir, JavaScript, seem to be better at prioritizing the humanistic aspect. Both in the affordances of the software (Elm’s famous error messages), and in person-to-person interactions. Can't stress that enough. I have observed Elixir community and I have to say Jose and others did an excellent job fostering a healthy, friendly and warm community. That is such an essential component. That combined with standin…

I tried Clojure and literally within the first hour got a super ugly Java stack trace from trying to add two numbers, and that was after already being a bit miffed by JVM startup time (i'm very big on instant unit test feedback). Meh.

Re: Is Clojure dying, and what has Ruby got to do with it?

#80

This is odd. I find myself moving to Assembly nowadays.

There will always be room in the market for trendy, abstracted languages like Assembly that provide simple syntax and garbage collection to sort memory management. Sometimes I think it's too user friendly though:

    assembly new project
When you scaffold an app like this in assembly you hardly know what it's doing under the hood.
Post reply on HN