131–140 of 202 posts
I need to learn Web, as mucj as I don't want to, and love clojure and fp. Also figwheel looks awesome, but how hard is it to setup.
I also think maybe to really get the best out of clojure script you also need to learn react??
I'm not sure this is the case with elm.
Any other non js alternatives?
> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
Well, what is your level of proficiency in Clojure? If it was your main language, do you think you would still struggle reading what the code does? I've inherited code bases in different languages in the past, and generally, it's the unfamiliarity to the language that makes it harder. Especially Clojure, being so different, the unfamiliarity is even stronger. For example, if you read the Clojure source code ( https:/…
All the rest, my team has managed to decode the intent and flow.
Earlier quoted context omitted.
Clojure has nothing at all to do with Haskell. I can't think of two more opposed camps in programming.
You're right, one is a language with a data-structure-centric approach to problem solving and an emphasis on pure transformations of immutable nested trees and lazy sequences, and the other one forces you to learn the word Monad. Edit: Joking aside, I do think you're right in terms of the ideological foundations and organizational structures of the two languages (clojure's emphasis on practicality, curation and evolu…
The last Clojure team I worked with decided to add “rop” to our project. The documentation in this library seems to go to great lengths to avoid using the word “monad”, despite the fact that the entire idea being encouraged by this library is monadic composition, but specialised to the Either monad. I mean come on, this library even takes its bind operator from Haskell.
These Clojure programmers were not Haskellers. They were just as indoctrinated as any other Clojurists and probably would have made the same flippant comment that you did.
And yet, here we are.
> clojure and haskell end up being pretty close.
In terms of the cost of building a software business, this has not been my experience. In my experience, the cost of building software at a scale beyond trivial is higher with Clojure than it is with Haskell.
Clojure is by far the best programming language I've ever used. Rich Hickey's Sermons On The Mount changed the game of programming once and for all. With Clojure you could finally have your Lisp cake and eat it. Witness the sheer chutzpah of the guy when he basically told Ruby devs they were doing it wrong at Rails Conf in 2012 ( https://www.youtube.com/watch?v=rI8tNMsozo0 ).
Oh man this talk... so incredibly good. The principle of simplicity vs easy is what drew me to Elixir, and what I'm starting to dislike about Rust. In Erlang/Elixir, you have patterns, and interfaces which are fairly low level, but provide meaningful abstractions over common goals... I.e. we have OTP. OTP is fairly simple, and that doesn't mean it's easy, it's really not, but it can be simple once you're familiar wit…
At my last job the client reps were notorious for saying “yes” to every client request and other devs were notorious for implementing those requests without question. I really tried hard to push back and find out what the client was trying to achieve. So many times after a brief discussion I would be able to inform them that what they wanted was already possible or doable with way less effort and expense. Sure, we didn’t get to bill them as much, but I’d much rather solve their pain points without adding code (especially when the code has already been written) than needlessly charging them.
> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
This is why I like python and C, almost impossible to layer in multiple layers of opaqueness with them. You can almost always deconstruct what the original person was trying to do, whether they were successful or not.
With Python, I find it's easy to understand what individual lines are doing, but really hard to understand what the codebase is attempting to do as a whole.
Earlier quoted context omitted.
> Macro system Macros are actually my least favourite part of Clojure. Sure, its great to have them and there are some libraries that use them to excellent effect (instaparse, Hugsql, etc), but most of the time, I prefer tools that don't use macros. You can see by comparing libraries that were made in the earlier days of Clojure versus more recent ones: the earlier ones love to use macros while the newer ones prefer…
I do agree that you should prefer functions over macros. The rule of thumb I’ve heard is only use macros if they are absolutely necessary. But having that option is better than not having the option at all IMHO.
> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
This is why I like python and C, almost impossible to layer in multiple layers of opaqueness with them. You can almost always deconstruct what the original person was trying to do, whether they were successful or not.
Earlier quoted context omitted.
It's a lot of fun but as projects got larger and larger for me (thousands of lines, or even tens of thousands), I found the dynamic typing taking up more and more of my time. I've since moved on to statically typed systems where the compiler takes a big load off the cognitive requirements of maintaining and debugging software.
How long have you been programming professionally? Did you have prior experience with dynamic languages? If so, how much? Did you have prior experience with statically typed languages? If so, how much? I'm trying to see if Clojure requires more fundamental programming intuition and experience to sustain in large projects. I work with tens of thousands of Clojure LOC, I don't feel these issues and can't relate, and lo…
And yet... I agree with GP. I love clojure, but over time I’m becoming less and less sold as dynamic typing. Spec helps, a little. Property-based generative tests (especially when used with spec) helps a little too. Neither are a replacement for proper static types, though, especially an ML-esque type system with type inference. Bonus points if spec validation could pass type data to the compiler/type inference (eg the code path after validation can assume that the data is of the the types described in the spec).
I dream of a statically typed Clojure with type inference, spec-inferred types and optional dynamic typing for REPL experimentation and glue code.
> 1. Economy of expression Funny, this list is the same one I use as to why I'm so annoyed with Clojure right now. I inherited a mission-critical Clojure ML library my team uses for it's primary business goals. It was written 4 years ago by a research scientist- who quit 3 years ago. We know what it's supposed to do. We know that it seems to do the job well. We just can't understand the code well enough to be certain…
Well, what is your level of proficiency in Clojure? If it was your main language, do you think you would still struggle reading what the code does? I've inherited code bases in different languages in the past, and generally, it's the unfamiliarity to the language that makes it harder. Especially Clojure, being so different, the unfamiliarity is even stronger. For example, if you read the Clojure source code ( https:/…
The response to "but is it slow" is pretty disappointingly bad. > No. Clojure is not slow. Oh, look, it’s not C. It’s not assembler. If nanoseconds are your concern than you probably don’t want Clojure in your innermost loops. You also probably don’t want Java, or C#. But 99.9% of the software we write nowadays has no need of nanosecond performance. I’ve built a real time, GUI based, animated space war game using Clo…
The biggest thing keeping me from ever seriously learning Clojure is the JVM. Slow startup time means I'd never use Clojure for "scripts", and I certainly don't want to have to manage the JVM in production scenarios, so when would I use Clojure? If there was a native version that could produce static binaries like Go/Nim/Rust I'd be much more interested to learn it.
Of all the things I’m unfortunate enough to have to manage in production, the JVM has never caused me any problems.
I mean, yeah, I’d like static binaries too (graal is promising but not quite there yet), but managing the JVM has nothing to do with it (footprint and startup time are my primary reasons)