141–150 of 273 posts
Earlier quoted context omitted.
> Haskell is an example of academic carefully crafted language, while C++ is rather a practically driven continuous patchwork (and they are extremities to both ends). Haskell is also a continuous patchwork, just look at the number of deprecated GHC extensions.
... which is the opposite of its pure vision, which is why I can't help think it is a negative.
We have a code base of roughly 200,000 lines of Haskell code, dealing with high performance SQL query parsing, compilation and optimizations. I only remember one situation over the past 5 years that we had a performance issue with Haskell, that was solved by using the profiling capabilities of GHC. I disagree that performance is hard to figure out. It could be better, yes - but it's not that different than what you'd…
but it's not that different than what you'd get with other programming languages. Until you have to solve a (maddeningly common) space leak issue. That's a problem unique to lazily evaluated languages (basically Haskell) and is godawful to debug. It reminds me of solving git problems... you suddenly find yourself having to tear back the abstraction layer that is the language and compiler and start thinking about thun…
Earlier quoted context omitted.
Haskell has a preference for looking academic, and is one of the favorites on academic circles. But that does not mean it's not used within industry. I'd say that people mostly do not know what is running in industry. It could be any share of anything. We get a hint looking at job offers; Haskell is small there, but not unheard of. On the sweet spot, Haskell is great for modeling complex domains; it's great for long-…
>> I'd say that people mostly do not know what is running in industry well if anyone does know what's out there then HN crowd would be a pretty good suspect in that regard. I personally have done my fair share of consulting and prof services engagements - dozens of them across all kinds of industries - I've never seen a Haskell shop. Java, Python, JS, Golang, Scala, Clojure, .Net, C, PHP - definitely out there in the…
Earlier quoted context omitted.
... which is the opposite of its pure vision, which is why I can't help think it is a negative.
>>> Haskell is an example of academic carefully crafted language >> Haskell is also a continuous patchwork > which is the opposite of its pure vision, which is why I can't help think it is a negative I'm very confused. One second, you're literally saying Haskell was "carefully crafted", and the next, you're saying it's "the opposite of its pure vision" It's almost as if you're just trying as hard as you can to argue,…
> It's almost as if you're just trying as hard as you can to argue, not caring what stance you're arguing, just so long as you can act like the author is wrong
Let me write the complete sentence:
([luispedrocoelho commented that] Haskell is also a continuous patchwork ) (which I simply accepted and followed -- even though I am doubtful) which is the opposite of its pure vision, which is why I can't help think it is a negative (regarding OP's point).
I commented originally that OP's this C++ comparison is also negative, right? So it is consistent.
When I say something is carefully crafted, I am refering to its intention. When I accept that someone find it like C++ or is also a patchwork, I accept that as a reality. When the reality runs against its design goal/vision/purpose, it is a negative, IMHO. -- Hope this clarifies.
EDIT: to make it even clearer, I didn't comment that whether a pure design goal or a continuous patchwork reality on its own is positive or negative. That is subjective. However, having a design goal and reality conflict, that can't be positive.
Some reasons I remember for the various failures, in no particular order:
- steep learning curve = experienced (in other languages) programmers having a tough time not being productive for weeks/months in the new language, with no clear payoff for the kind of projects they're working on
- sometimes/often side-effects/states/global vars/hackyness is what I want, because I'm experimenting with something in the code; and if I'm not sure if this code will be around in 3 months, I want to leave the mess in and not refactor it
- in general, I think all-the-way pure no side effects is too much; I think J.Carmack said sth along the lines: Haskell has good ideas which should be imported into more generally useful languages like C++/etc, eg. the gamestate in an FPS game should be write-once, it makes the engine/architecture easier to understand (but in general the language should support side-effect)
- I found the type system to be cumbersome: I kept not being able to model things the way I wanted to and running into annoyances; I find classes/objects/templates etc from the C++/Java/Python/whatever world to be more useful for modeling applications
- when the spec of the system keeps changing (=the norm in lean/cont.delivery environments), it's cumbersome/not practical to keep updating the types and deal with the cascading effects
- weird "bugs" due to how the VM evaluates the program (usually around lazyness/lists) leading to memory leaks; when I was chasing these issues I always felt like I'm wasting my time trying to convince the ghc runtime to do X, which would be trivial in an imperative language where I just write the program to do X and I'm done
- cryptic ghc compile errors regarding types (granted, this is similar in C++ with templates and STL..)
- if it compiles it's good => fallacy we kept running into
- type system seemed not a good fit for certain common use-cases, like parsing dynamic/messy things like json
Working at Facebook for the last year and seeing the PHP/Hack codebase which powers this incredibly successful product/company has further eroded my interest in Haskell: Facebook's slow transition from PHP to Hack (=win) shows that some level of strictness/typing/etc is important, but it's pointless to overdo the purity. Just pick sth which is good enough, make sure it has outstanding all-around tooling, have good code-review, and then focus on the product you're building, not the language.
I'm not saying Haskell is shit, I just don't care about it anymore. I'm happy if people get good use out of it, clearly there are problem spaces that are compact, well-defined and correctness is super-important (like parsing).
Question to the Haskell experts here. Is Haskell more academic in nature or used heavily in Production environments? Is there an application sweet spot/domain (say Artificial Intelligence/Machine Learning, etc) where it shines over using other languages (I am not talking about software/language architectural issues like type systems or such)? I have no experience with Haskell but do use functional languages such as E…
> Is there an application sweet spot/domain State of the Haskell ecosystem: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md The topics are roughly sorted from greatest strengths to greatest weaknesses. Each programming area will also be summarized by a single rating of either: Best in class: the best experience in any language Mature: suitable for most programmers Immature: only acceptable for early-adopte…
I'm sorry to cherrypick, but how did this happen??? Unicode shouldn't be a library or extension. It should be in the language.
I will never, ever use Haskell in production because of its default evaluation strategy, the wrongness of which was tacitly conceded not long ago with the addition of the strictness pragma (which only works per-module) to GHC. I think it's especially telling that its community skews so heavily towards this blogger/monad tutorial writer dilettante demographic rather than the D. Richard Hipp/Walter Bright 'actually get…
Earlier quoted context omitted.
Haskell has a preference for looking academic, and is one of the favorites on academic circles. But that does not mean it's not used within industry. I'd say that people mostly do not know what is running in industry. It could be any share of anything. We get a hint looking at job offers; Haskell is small there, but not unheard of. On the sweet spot, Haskell is great for modeling complex domains; it's great for long-…
>> I'd say that people mostly do not know what is running in industry well if anyone does know what's out there then HN crowd would be a pretty good suspect in that regard. I personally have done my fair share of consulting and prof services engagements - dozens of them across all kinds of industries - I've never seen a Haskell shop. Java, Python, JS, Golang, Scala, Clojure, .Net, C, PHP - definitely out there in the…
HN is a comically bad barometer for anything other than what's trendy in norcal.
Earlier quoted context omitted.
> and where trivial problems are the subject of ongoing academic research Like what?
I am not holding that (joke's) view, but monad came to mind as an ongoing academic research (to original Haskell at least) in order to solve a rather trivial stateful programming (trivial in an imperative style). To generalize that example, there are solutions that are trivial to express in an imperative style but seems convoluted in pure functional programming. How to retain the trivialness are subject of ongoing ac…