3 ms·

> carefully researched information first doesn't qualify as FUD How carefully researched was your very public assessment of what happened at CS? > Do we all n

by willtim 10y ago

> carefully researched information first doesn't qualify as FUD How carefully researched was your very public assessment of what happened at CS? > Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go? Of course not. Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill. > If Haskell had had a huge advantage, it wouldn't have been abandoned No one is claiming Haskell is some sort of magic bullet for all use cases. If you require ease-of-use, are writing disposable software, or high performance software, then it may not be the best choice. Nobody is arguing against further studies, but I suspect that most of our industry isn't really interested. As I have said elsewhere, Haskell does not optimise for ease-of-use or aesthetics. It has a growing niche and will continue to be successful in that niche, with or without further productivity studies.

pron 10y ago
> How carefully researched was your very public assessment of what happened at CS? It wasn't. I simply stated that it's a negative signal; that's not FUD. It is a negative signal whether or not I mention it. Mentioning it gives Haskell advocates a chance to address it. You don't have to, but whatever you do, the signal is there. But it's just one signal. I don't think anyone should make a decision based on just one signal. > Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill. What should those interested in increasing productivity learn? This entire discussion isn't about learning a new programming style, but about achieving a goal of reducing development costs. > No one is claiming Haskell is some sort of magic bullet for all use cases. So what is the claim, and is there actual evidence (even anecdotal) to support it? > I suspect that most of our industry isn't really interested. The industry is extremely interested in anything that can significantly reduce the cost of developing software. We don't care if it's called Haskell or an omniscient debugger, or a static analysis tool. > and will continue to be successful in that niche, with or without further productivity studies. That's terrific, but don't blame the industry for being short-sighted and investing heavily in something that has little evidence of a great promise. You can only blame the industry for ignoring evidence, not for ignoring hype.
- willtim 10y ago
  > What should those interested in increasing productivity learn? Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are oversimplifying. > So what is the claim, and is there actual evidence (even anecdotal) to support it? It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you. > The industry is extremely interested in anything that can significantly reduce the cost of developing software. Industry as a whole, does not have a good track record of adopting even good ideas in a timely manner. c.f. Garbage collection. So again, I think you are oversimplifying.
  - pron 10y ago
    > Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are over simplifying. I'm only simplifying as much as the claims in the article. It's just pretty hard to understand what the claims about Haskell are given all of the vague hype. The article we're discussing says, "Haskell decreases development time by narrowing the scope of development to your domain." Obviously, I understand there are caveats, and it's unclear how big the savings are. I just want reports with some meat. > It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you. The question of being "completely satisfied" is irrelevant. I'm not a researcher and my goal isn't to dream up better approaches, nor do I have the resources to invest in experimenting with every new tool. I am, however, very interested if someone says they have a tool that can provide significant savings. If there were only some more actionable information, convincing me would be quite easy. I want to be convinced, but throwing general promises around serves to confuse more than enlighten.

by willtim 10y ago

pron 10y ago

> How carefully researched was your very public assessment of what happened at CS? It wasn't. I simply stated that it's a negative signal; that's not FUD. It is a negative signal whether or not I mention it. Mentioning it gives Haskell advocates a chance to address it. You don't have to, but whatever you do, the signal is there. But it's just one signal. I don't think anyone should make a decision based on just one signal. > Those interested in learning more about pure functional programming should try Haskell, the others have different niches they are trying to fill. What should those interested in increasing productivity learn? This entire discussion isn't about learning a new programming style, but about achieving a goal of reducing development costs. > No one is claiming Haskell is some sort of magic bullet for all use cases. So what is the claim, and is there actual evidence (even anecdotal) to support it? > I suspect that most of our industry isn't really interested. The industry is extremely interested in anything that can significantly reduce the cost of developing software. We don't care if it's called Haskell or an omniscient debugger, or a static analysis tool. > and will continue to be successful in that niche, with or without further productivity studies. That's terrific, but don't blame the industry for being short-sighted and investing heavily in something that has little evidence of a great promise. You can only blame the industry for ignoring evidence, not for ignoring hype.

willtim 10y ago
> What should those interested in increasing productivity learn? Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are oversimplifying. > So what is the claim, and is there actual evidence (even anecdotal) to support it? It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you. > The industry is extremely interested in anything that can significantly reduce the cost of developing software. Industry as a whole, does not have a good track record of adopting even good ideas in a timely manner. c.f. Garbage collection. So again, I think you are oversimplifying.
- pron 10y ago
  > Productivity for whom? And over what timescales? As I have been trying to say, it is not that simple, you are over simplifying. I'm only simplifying as much as the claims in the article. It's just pretty hard to understand what the claims about Haskell are given all of the vague hype. The article we're discussing says, "Haskell decreases development time by narrowing the scope of development to your domain." Obviously, I understand there are caveats, and it's unclear how big the savings are. I just want reports with some meat. > It sounds like you are completely satisfied with existing approaches, in which case there is little point in me trying to convince you. The question of being "completely satisfied" is irrelevant. I'm not a researcher and my goal isn't to dream up better approaches, nor do I have the resources to invest in experimenting with every new tool. I am, however, very interested if someone says they have a tool that can provide significant savings. If there were only some more actionable information, convincing me would be quite easy. I want to be convinced, but throwing general promises around serves to confuse more than enlighten.