6 ms·
> True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accum
by gridlockd 7y ago
> True but run of the mill languages like this always tend to culminate in codebases that are hard to maintain and necessitates an eventual rewrite due to accumulation of complexity.
I'm reluctant to believe that Haskell magically protects you from that, but let's suppose it was true. What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation?
> Haskell is hard to learn and hard to find developers for, but the trade off is incredible safety and a type system that promotes good design and easy refactoring of inevitable design flaws.
Again, I'm reluctant to buy into that. Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design.
Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy.
- crimsonalucard 7y ago>I'm reluctant to believe that Haskell magically protects you from that i can only show you the door you have to walk through it. >What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? The 3rd rewrite of your nodejs app still has technical debt. It still has flaws and still is buggy. Every time you redo it, you repeat the same mistakes over and over and over again never knowing how to make things better. You are doomed to participate on an endless cycle of rewrites as people of every generation reinvent the wheel with a new framework and new mistakes never converging on a better solution. It's a myth that Haskell is slower. The speed I would say is the same because Haskell you would require significantly less testing and validation. >Even if that was true, unless you're writing Haskell in a vacuum, you're going to have to interface with various other horrible pieces of technology that will throw a wrench into your beautiful pure design. You do that anyway. At least keep one section of your stack safe and nice. Haskell. >Dealing with the ugly bits while maintaining composure is what makes the difference between a really good engineer and somebody who just wants to program. That quality is invaluable, but you're likely not going to develop it by programming in a language that you enjoy. Haskell is about safety and good design. If these two things are not critical to your program, then you shouldn't go the way of Haskell. If it is, Haskell is one of the best technologies to meet that requirement while not costing too much in performance / speed of development. If Haskell has a critical flaw it's the learning curve. But that's a one time deal. Once you get past the curve you're good. Also don't call us wizards. We're not... Haskell isn't that hard. Anyone can learn it, this isn't like quantum physics. Becoming an expert database SQL ninja admin on postgresql is probably just as hard as becoming one on haskell. haskell like sql is just a bit challenging because it's expression based as opposed to imperative like python.
- gridlockd 7y ago> The 3rd rewrite of your nodejs app still has technical debt. It still has flaws and still is buggy. Every time you redo it, you repeat the same mistakes over and over and over again never knowing how to make things better. Oh really? Well that's good news too, because now I can just save myself those rewrites, because they're pointless. That's a 3x improvement right there. > It's a myth that Haskell is slower. The speed I would say is the same because Haskell you would require significantly less testing and validation. If you have wizards, that is. > Haskell is about safety and good design. If these two things are not critical to your program, then you shouldn't go the way of Haskell. They certainly aren't critical to your run-of-the-mill NodeJS/Angular project which, I must remind, is the alternative that we are discussing here. > If Haskell has a critical flaw it's the learning curve. But that's a one time deal. No, it's a "one time per hire" deal. > Also don't call us wizards. We're not... Haskell isn't that hard. I'm certainly not calling all Haskell programmers wizards, I'm referring to that "team of experienced developers that had built large applications in other languages (and then arrived at Haskell as a better solution)" that the original commenter saw as a requirement for success. Of course it's not impossible to assemble such a team for a run-of-the-mill project. It's just impractical. > Becoming an expert database SQL ninja admin on postgresql is probably just as hard as becoming one on haskell. See, that's another kind of expert that I definitely don't want to need on the team. I want people who have a basic understanding of SQL, with a reluctance to learn the ins and outs of it. That'll dramatically lower the chances of them trying to be smart with SQL.
- crimsonalucard 7y ago>Oh really? Well that's good news too, because now I can just save myself those rewrites, because they're pointless. That's a 3x improvement right there. No dude don't even write it because likely it will be garbage. If you truly believe that nodejs apps don't need to be rewritten go to Uber. They never rewrote their entire nodejs code base in Golang. >If you have wizards, that is. Haskell isn't all wizards. It's just regular people who learned something different. >No, it's a "one time per hire" deal. Same with almost every other language that isn't popular yet. Rust and golang and kotlin and swift all went through this. The goal of any language is to become popular enough to get past this. >I'm certainly not calling all Haskell programmers wizards Then what is the big deal. If we aren't wizards then it's easy to learn. Programmers learn new languages all the time. Learning Haskell is just slightly more challenging and not a huge drain on productivity. Spend a couple more months training new developers in exchange for a 90% reduction in bugs and much better design. >See, that's another kind of expert that I definitely don't want to need on the team. I want people who have a basic understanding of SQL, with a reluctance to learn the ins and outs of it. That'll dramatically lower the chances of them trying to be smart with SQL. Eventually for certain queries you will have to get clever and write queries to optimize. Additionally to serve certain architectures you have to know a lot about the inner workings of the database and how to manipulate the api to get the performance needed at the lower level. An expert has no trouble with this and is an asset. This isn't about getting clever or doing tricky things with syntax just to be clever... this is about inevitability of the fact that a client will want to ask a question to a database that has grown so complex it is not straightforward to answer his question in a performant way. This is extremely common even for your run of the mill web app company. But that's besides the point. I'm comparing haskell to SQL because it's a similar learning curve. Both are expression based languages. In fact I would argue that Haskell is EASIER then SQL due to the type checking. Learn the language if you really want to understand our perspective. I use to be in that camp of why learn a freaking language when it's barely used, but that changed once I learned haskell.
- the_af 7y ago> What if my run-of-the-mill gang can rewrite the project three times over before your wizards have congregated to sing their first incantation? Is there any evidence Haskell projects take longer than projects done in "run of the mill" languages?