61–70 of 120 posts
This is not going to change.
I love Haskell, and I appreciate the effort many are making to evangelize the language, but I am experienced (ie. cynical) enough to believe that it's never going to become truly mainstream.
https://m.reddit.com/r/rust/comments/5dtfp2/haskell_more_pro...
(Tried to ask on HN first, which once again proves the value of subreddits, as small focused communities: https://news.ycombinator.com/item?id=12989041)
The article assumes an existing team which is a bit problematic when talking about time to market. If you start the analysis earlier (two people discussing some ideas in a coffee shop) then I'd argue that a language like Haskell can be problematic if your metric is time to market. You might very well make that up later by having a more robust code base or reaping any of the other asserted benefits but the existing ga…
Well, the best language for an early-stage business is the one the founder knows, but that's always going to be true. There's no reason that language can't be Haskell.
If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?
[1]: https://www.coursera.org/specializations/scalaEarlier quoted context omitted.
> If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management. Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why any…
> That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have any actual anecdotal information at all. The precise difference between management and developers is that management sees the bigger picture. In most cases management isn't qualified to make technical decisions. Managers rarely see the bigger picture. I've worke…
Earlier quoted context omitted.
>> Haskell was and still is motivated by enabling software development gains > The same can be said about nearly every language. This clearly isn't true. For example many languages optimise for ease of use, shallow learning curve, programming in the small etc. Some optimise for efficiency and runtime determinism. Features like type-systems are great for software development (programming in the large), but do negative…
Nobody knows if Haskell's design is great for software development, and if it is, by how much and whether it justifies the costs. That's precisely why we need data. > Haskell just happens to have come from academia and is still heavily used in academia. Haskell isn't heavily used in academia at all. My guess is that most CS professors -- like most developers -- have hardly even heard of it, let alone used it. It is h…
We can certainly say that uncontrolled side-effects, manual memory-management and dynamic types is bad for software development in the large.
I'll stop here because I don't which to argue the semantics of what does are does not constitute significant use or significant research.
If you were a developer with 10 yoe looking for something new to get into, what would you choose at this moment and thinking about the near future: Haskell, Scala or F#?
Short answer: whichever you can get a job in. That's more important than the design differences between them, which are relatively small.
Long answer: I wouldn't use F# because nice as it is you're eventually going to want HKT. Between Scala and Haskell I'd pick based on your learning style - Scala lets you write familiar comfortable code and incrementally adopt functional features, Haskell forces you to dive straight in and do things the Right Way from the start.
Earlier quoted context omitted.
> That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have any actual anecdotal information at all. The precise difference between management and developers is that management sees the bigger picture. In most cases management isn't qualified to make technical decisions. Managers rarely see the bigger picture. I've worke…
First, given the large effort involved and how much you wanted Haskell to succeed, I assume you carefully collected lots of metrics. By publishing them you could actually do Haskell and the software community at large some actual good other than just complain about incompetent management (and I've whined about management, too). You may have missed the chance in that company, but your well-researched report is sure to…
All I could do is collect metrics like lines of code and intentionally vague experience reports from former colleagues who are still there, but I guess that's hardly gonna convince anybody.
IME Haskell development has a sort of bell-curve to it. Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way: you have to declare up-front which functions do I/O, etc. But once the core abstractions are settled, you start to reap its power. The type system catches tons of potential errors. Combinators allow for enormous expres…
> Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way The opposite is true: here Haskell helps to find the right data structures/abstractions incredibly fast. The ability to quickly construct and reconstruct a high-level skeleton of your program without actually having to implement anything makes prototyping much easier and f…
> Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug.
The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".
Earlier quoted context omitted.
> Initially, you're spending a lot of time prototyping, fumbling around trying to find the right abstractions. Here Haskell mostly gets in the way The opposite is true: here Haskell helps to find the right data structures/abstractions incredibly fast. The ability to quickly construct and reconstruct a high-level skeleton of your program without actually having to implement anything makes prototyping much easier and f…
Why, in your opinion, is it faster to construct a "high-level skeleton" than in dynamic languages? > Laziness can sometimes surprise you in bad ways, but it's not like it's impossible to debug. The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated. The answer I got was "yeah, in GHC 8 there will be some support for stack traces".
This is much faster than writing a large chunk of code, playing around in the REPL thinking everything is ok, only to realize one week later that you didn't think through some core aspect of your design and then having to refactor a sizeable piece of your codebase.
> The last message I get was something like "Array.Array: Index out of bounds". Program crashed. No idea where the error originated.
It is an unfortunate historical artefact that there are still partial functions (i.e. functions that may crash) in the Haskell base libraries. It is generally advised to avoid such functions, but this is not very clearly communicated to newcomers to Haskell.
For example, Elm, a language largely inspired by Haskell, doesn't have partial functions. This is why it prides itself in "not having any runtime errors in production" (excluding things like compiler bugs or unsafe JavaScript libraries, of course).