201–210 of 228 posts
Earlier quoted context omitted.
Mozart/Oz??? I never heard of it. Now there is another rabbit cave to spelunk in my search for the perfect programming language.
It's an academic-only language, mostly used for teaching students about programming. Anyone sane would not use it in production, as the output would likely be "ill-typed".
You could also just: write the less general version and stop listening to folks who flip and scoff at every piece of code isn't maximally general. Crazy, I know, but especially when were doing labor in industry, even without maximal generality your code is probably going to outlive its patron corporation and then die in obscurity.
The only person who flips and scoff at every piece of code isn't maximally general is... the author the code. That's the problem.
This fosters an environment that might already lead people to second guess themselves, because it's so big and new.
Earlier quoted context omitted.
The type system forces you to solve this problem in a very specific way by structuring your entire app around pushing IO to the edges. There are plenty of other ways to address the problem that work perfectly fine in practice. For example, you can specify what should happen is IO fails in your logging configuration. This handles the exceptional case consistently and in a single place without forcing you to structure…
> For example, you can specify what should happen is IO fails in your logging configuration. This handles the exceptional case consistently and in a single place without forcing you to structure your whole app around it. In Haskell you can write a function that does "unsafe" logging and handles exceptions if that's the behaviour you want. You can even make that function change its behaviour based on a config file if…
If dynamic typing was problematic we would've switched back a long time ago.
Earlier quoted context omitted.
A big one is lazy I/O[1]. It is really easy to mess up the order that operations happen in when using IO operations from Haskell's standard library. The non-standard library alternatives like conduits or pipes are more complex, but much harder to mess up. [1] https://stackoverflow.com/questions/5892653/whats-so-bad-abo...
I agree lazy file I/O can be dangerous and needs to vanish, but I'm not sure this counts as an "algorithmic" complaint, which is what I was really curious about. I also don't think you need Conduit or Pipes or any other performance destroying free Monad libraries to deal with it. My hot take: Conduit is in fact awful and radically overused and multiple superior options exist.
Earlier quoted context omitted.
What makes you think the Haskell community is toxic? I usually hear the exact opposite.
I find that the Haskell community is very friendly as long as you buy into their approach to solving problems. However, my experience is that if you question the effectiveness of static typing, or ask for evidence in support of the claimed benefits you'll get a very hostile reaction. The comment above where pka snidely claims that using any alternative to types amounts to yolo is quite representative. He outright dis…
That's an interesting thing to say, seeing how representative figures of (specifically) the Clojure community get really defensive really quickly once somebody questions the effectiveness of dynamic typing - which I specifically didn't do.
> He outright dismisses that any valid alternatives are possible
I was merely dismissing your incorrect claim about logging in Haskell. And yes, not taking advantage of the type system when you are already programming in a language with a type system amounts to #yoloing it, in my opinion. Doing the same in other languages is fine, since you don't have another option really.
Earlier quoted context omitted.
Mozart/Oz??? I never heard of it. Now there is another rabbit cave to spelunk in my search for the perfect programming language.
It's an academic-only language, mostly used for teaching students about programming. Anyone sane would not use it in production, as the output would likely be "ill-typed".
Earlier quoted context omitted.
Mozart/Oz??? I never heard of it. Now there is another rabbit cave to spelunk in my search for the perfect programming language.
It's an academic-only language, mostly used for teaching students about programming. Anyone sane would not use it in production, as the output would likely be "ill-typed".
Earlier quoted context omitted.
When people wonder why my typical comments run on to multiple screenfuls, it's because I'm armoring them against this sort of dismissive snark. I was in between tasks today and lacked time to make it longer.
OK, long form: you whooshed on the point of the linked article entirely. Software exists to solve problems, not to achieve some sort of aesthetic ideal. Time spent in pursuit of abstractions (or skill in the expression of abstractions) is wasted, by definition. You seem to be conflating the two. To wit: spending hours giting gud at Haskell doesn't translate to hours saved solving real problems (like the one in the li…
As long as we're playing "make baseless assertions at each other", my experience says otherwise. That's going to be hard for you to talk me out of.
Programmers still seem to have this bizarre belief that programming, uniquely among all the skills in the world, is not possible to improve via deliberative practice, and an equally bizarre belief that improved skills can't possible translate into better programs or even worse, must inevitably translate into worse programs. I can't wrap my mind around it.
I don't deny that there certainly is a trap where you learn these skills in a sort of greenhouse environment, then fail to translate them out of that environment properly. But that's the fault of the practitioner, not the skills, and I prove by demonstration that the skills can come out of the greenhouse and improve real code. I mostly write my professional code in Go, so you can be quite assured my production code is anything but a mess of functional paradigms inappropriately applied, since that's basically impossible in Go. I find what I learned in Haskell to be incredibly useful in Go.
Earlier quoted context omitted.
OK, long form: you whooshed on the point of the linked article entirely. Software exists to solve problems, not to achieve some sort of aesthetic ideal. Time spent in pursuit of abstractions (or skill in the expression of abstractions) is wasted, by definition. You seem to be conflating the two. To wit: spending hours giting gud at Haskell doesn't translate to hours saved solving real problems (like the one in the li…
"spending hours giting gud at Haskell doesn't translate to hours saved solving real problems" As long as we're playing "make baseless assertions at each other", my experience says otherwise. That's going to be hard for you to talk me out of. Programmers still seem to have this bizarre belief that programming, uniquely among all the skills in the world, is not possible to improve via deliberative practice, and an equa…
> you can be quite assured my production code is anything but a mess of functional paradigms inappropriately applied
The point of the article was precisely that functional paradigms appropriately (which is to say, "appropriately") applied are themselves a design smell.
Earlier quoted context omitted.
> you can say that any `b` in the result list _must_ have come from applying the function to some `a` in the input list. Morally correct... but consider the function `\f xs -> [undefined]`, which can be typed as `(a -> b) -> [a] -> [b]`. (Obviously it could be given other types as well.)
When discussing Haskell and theorems about its types it's common to simply ignore non-termination; if we don't ignore non-termination there's basically nothing we can say about Haskell programs at all. Interested readers should check out Agda and Theorems for free!