4 ms·

> If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far. I always see people say this and on t

> If you had a rigid system and slow turnaround from the start, you might not have gotten off the ground to get that far. I always see people say this and on the surface it seems to make sense, but I also always wonder what "rigid system" they're talking about. It's much, much faster to make big changes in every phase of a project in Haskell for me than it is in Elixir, so this is the perspective I'm seeing this from. This hypothetical/straw man "rigid system" is hard to fathom.

void_mint 5y ago
It's funny - I see that sentiment all the time ("Static typing is slower to get going with") and I kinda chuckle. In both static and dynamic languages, in the beginning, you're not doing anything silly. In both scenarios, you likely aren't writing your methods that accept strings and then immediately trying to pass them ints. For two developers of the same proficiency, competing to generate value in a static vs. dynamic language, I suspect the first 10 hours or so of building a project would progress pretty similarly. Compilers don't really fight with you until there's lots of hidden complexity.* *Haskell and Rust get a lot of flack because of their compilers being difficult for beginners to work with. I don't necessarily think this is actually an issue - for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight".
- tome 5y ago
  > for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight". That's certainly true of my experience. I prefer to have the compiler there guiding me (My reference points are poorly-typed languages like C, Java and C++, and the dynamically-typed language Python. I've never used Clojure.).
fulafel 5y ago
I don't have Elixir experience, but the natural way to get started in modeling data and state in Clojure quite obviously involves less ceremony and scaffolding than what you do in Haskell, and is less work to change around. Also, it's not just the amount of work, it's the complexity of the language. Clojure is really simple, so you don't h ave to spend much of your cognitive capacity juggling things related to the language or operating a mental simulation of the type system.
- YuukiRey 5y ago
  I totally understand what you mean! At least I think I do. I have spent a significant amount of time going down the "type flex" rabbit hole. You can always make thinks a little safer, a little more concise, and so on. In that sense I really do get off the ground much, much faster in Clojure. In fact, it's my favorite language for prototyping and the whole interactive execution model of the REPL makes we want to learn Emacs and do everything in some kind of lisp, rather than awk, sed, bash, dash, whatever. I think the key ingredient for me with Haskell is to know when to stop. You can be very productive even as an intermediate Haskell user if you restrict yourself to the features with the highest return on investment. Everything else can be done later. But I also know that it's very tempting to stress out over these details. As a very late conclusion to my various comments in this thread: if I got better at taming type related errors in Clojure I could very well see it being my go-to language for everything.

void_mint 5y ago

It's funny - I see that sentiment all the time ("Static typing is slower to get going with") and I kinda chuckle. In both static and dynamic languages, in the beginning, you're not doing anything silly. In both scenarios, you likely aren't writing your methods that accept strings and then immediately trying to pass them ints. For two developers of the same proficiency, competing to generate value in a static vs. dynamic language, I suspect the first 10 hours or so of building a project would progress pretty similarly. Compilers don't really fight with you until there's lots of hidden complexity.* *Haskell and Rust get a lot of flack because of their compilers being difficult for beginners to work with. I don't necessarily think this is actually an issue - for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight".

tome 5y ago
> for a sufficiently skilled Rust or Haskell dev, I doubt most compiler errors feel like a "fight". That's certainly true of my experience. I prefer to have the compiler there guiding me (My reference points are poorly-typed languages like C, Java and C++, and the dynamically-typed language Python. I've never used Clojure.).

fulafel 5y ago

I don't have Elixir experience, but the natural way to get started in modeling data and state in Clojure quite obviously involves less ceremony and scaffolding than what you do in Haskell, and is less work to change around. Also, it's not just the amount of work, it's the complexity of the language. Clojure is really simple, so you don't h ave to spend much of your cognitive capacity juggling things related to the language or operating a mental simulation of the type system.

YuukiRey 5y ago
I totally understand what you mean! At least I think I do. I have spent a significant amount of time going down the "type flex" rabbit hole. You can always make thinks a little safer, a little more concise, and so on. In that sense I really do get off the ground much, much faster in Clojure. In fact, it's my favorite language for prototyping and the whole interactive execution model of the REPL makes we want to learn Emacs and do everything in some kind of lisp, rather than awk, sed, bash, dash, whatever. I think the key ingredient for me with Haskell is to know when to stop. You can be very productive even as an intermediate Haskell user if you restrict yourself to the features with the highest return on investment. Everything else can be done later. But I also know that it's very tempting to stress out over these details. As a very late conclusion to my various comments in this thread: if I got better at taming type related errors in Clojure I could very well see it being my go-to language for everything.