191–200 of 307 posts
I'd like to learn a modern production-ready functional language (I have some academic experience with SML), since they seem like a good way to grow as a programmer. Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) - but the fact that Clojure is dynamically typed is a bit of a turn off for me. My experience with dynamic vs static typing is that as a system grows in size and…
This is a bit tangential to the post, but I've seen a couple comments in this thread that amount to "Clojure is hard to read", but I think that's a really unfair comparison, because people are unwittingly comparing apples and oranges. It seems to me the reason people think Clojure is hard to read is that the language is so powerful and expressive, that when you're reading Clojure code, you're typically trying to unde…
I think my issue with Clojure is that it's hard to learn how to write good Clojure. There is very clearly a way that it should be written (to keep the code clean, readable, and concise) but unless you are very familiar with working with Lisps then it's easy to create a giant mess You could say that for a lot of other languages too, but you usually have some familiar base to work off of. That's less true with Lisps as…
- https://github.com/gothinkster/clojurescript-reframe-realworld-example-app for a great webapp example
- All of https://github.com/ztellman work but specifically:
- https://github.com/ztellman/manifold for more advanced Clojure
- https://github.com/reagent-project/reagent for interop with JS and advanced Clojurescript usageI'd like to learn a modern production-ready functional language (I have some academic experience with SML), since they seem like a good way to grow as a programmer. Main contenders so far are Haskell, Scala and Clojure (Reason might go on the list soon too) - but the fact that Clojure is dynamically typed is a bit of a turn off for me. My experience with dynamic vs static typing is that as a system grows in size and…
This is a bit tangential to the post, but I've seen a couple comments in this thread that amount to "Clojure is hard to read", but I think that's a really unfair comparison, because people are unwittingly comparing apples and oranges. It seems to me the reason people think Clojure is hard to read is that the language is so powerful and expressive, that when you're reading Clojure code, you're typically trying to unde…
I don't think it's hard to read, I think it's extremely difficult to analyze and almost impossible to debug. Lazyness is one of those "cool" features, IMO, that have more cons than pros. Yes, certain algorithms look more "elegant", but it's also harder to reason about/debug. Most of the time, you can ignore the fact that this awesome language runs on the JVM, until you see a barely-comprehensible stack trace containi…
Eager evaluation is merely a performance optimization, one which assumes that the data being evaluated will actually be used. When the data is not used it ceases to be an optimization and can even result in incorrect behavior (unnecessary exceptions / non-termination). Either way, making eager evaluation the default is a form of premature optimization.
Earlier quoted context omitted.
A perennial problem in Clojure is libraries that reach a mostly "done" state tend to look inactive to outsiders, because the language is so stable there's almost no maintenance work. So inevitably, someone will ask "Is lib foo still being used? The last commit was over 8 months ago" and then people have to chime in, "yes, it's still in heavy use".
Several languages have this problem, e.g. Common Lisp. It would be nice if developers of libraries like this at least updated their copyright annually, as an indicator that they and the project are still alive.
It's also kind of pointless to "update the copyright year" for individual works tied to your name, since the copyright lasts x years after your death. If anonymous/pseudonymous, then it's like 95 years after initial publication date, and you can't just extend that arbitrarily by updating the base year and nothing else every year..
Earlier quoted context omitted.
well... yeah ? there are entire companies of thousand of electrical engineers working in LL. They just don't come and post about it to hackernews and make PLC projects in github, they do their 9-5 job and that's all. Compare https://www.indeed.com/jobs?q=PLC+engineer and https://www.indeed.com/jobs?q=bash+programmer
>They just don't come and post about it to hackernews and make PLC projects in github Same logic applies to clojure. I think that's the point he's making. Everyone and their 12 year old nephew rockstar developer has questions about java. I also find that clojure questions nowadays are mainly asked in the clojurians slack organization. Immediate feedback is more attractive than waiting around hoping for an answer in s…
With any chat interface, it feels like your question may be lost if it's not immediately answered and it's often hard to follow discussions with multiple people chatting. With SO I will spend time to try and formulate a clear question. In general with slack or any other chat I may feel out the room first as it will be a waste of my time writing a detailed question if no one is around to answer.
Perhaps some sort of SO integration into Slack would be the best of both worlds?
Earlier quoted context omitted.
I don't think it's hard to read, I think it's extremely difficult to analyze and almost impossible to debug. Lazyness is one of those "cool" features, IMO, that have more cons than pros. Yes, certain algorithms look more "elegant", but it's also harder to reason about/debug. Most of the time, you can ignore the fact that this awesome language runs on the JVM, until you see a barely-comprehensible stack trace containi…
I don't think laziness is really that much harder to reason about, unless you're trying to fit it into a mental model based on eager evaluation. Evaluation occurs when the result is needed; that's so hard about that? And it's not really about making algorithms look "elegant" but rather about composiblity and reuse: it's much easier to add eager evaluation to non-strict interfaces than it is to get non-strict evaluati…
I by no means claim to be a Clojure guru, and I'm sure people who have more experience can just look at it and know, but for me, the time lost to pinpoint that error is too much. And when I have something in production, I need to be able to pinpoint the error in minutes and deploy the fix quickly.
>Either way, making eager evaluation the default is a form of premature optimization.
I don't see how that's true - it's the default way CPU's operate on the silicon level. Millions upon millions of lines of non-lazy code have been written and put into production and they perform real, valuable work.
I'm not against lazy evaluation or against Clojure - all I'm saying is - it's hard for me to reason about it when things go wrong.
If they don't go wrong (almost never for me) - it truly is a thing of beauty.
Earlier quoted context omitted.
Having spent the last two years working professionally in Haskell after having spent the previous two years working professionally in Clojure, I'd disagree with this. Haskell is roughly infinitely better than Clojure for meaningful refactoring. Clojure gives you (great) tools for using your own brain to make sure the refactor goes well. Haskell replaces your brain almost entirely in the process and just gives you a p…
To be fair, I wasn't comparing the two. I've never used Haskell (for more than just learning/tutorials). I would suggest that if you have runtime bugs popping up in Clojure programs then that would suggest the inputs to functions (since they should be primarily pure) are not being validated which can easily be accomplished. I would imagine this needs to be done in Haskell as well since just verifying types does not i…
Would be interested to hear their experiences with Clojure at Netflix for the 5 years that have followed since then. Did they keep writing more Clojure? If so, how much of their code is now in Clojure compared to Java? How much more did they rewrite from Java to Clojure? Do they use Clojure rather than Java for new code? What other languages do they use? Python? Erlang? Rust? How much, in terms of functionality, is w…
Did they keep writing more Clojure? Since Netflix likes to constantly write about their tech (videos, blog), my guess would be no, but interested in an official answer too. They are now heavy users of nodejs though. I personally ran out of reasons to prefer another dynamically-typed language over Javascript on the server (not a hard rule of course).
Of course, as a language I find Clojure superior in almost every way compared to JS.
Earlier quoted context omitted.
Having spent the last two years working professionally in Haskell after having spent the previous two years working professionally in Clojure, I'd disagree with this. Haskell is roughly infinitely better than Clojure for meaningful refactoring. Clojure gives you (great) tools for using your own brain to make sure the refactor goes well. Haskell replaces your brain almost entirely in the process and just gives you a p…
Just as with the word "developer" [1], I'm beginning to think that the word "refactor" is a dirty word. Are we even talking about the same activity? How is it people are alternately claiming that Haskell and Clojure (virtual opposites on the language spectrum) are infinitely superior to each other at the same thing? Wikipedia defines it as "the process of restructuring existing computer code without changing its exte…