15 ms·

This post highlights my biggest problem with the language: it's about the how, not about the why. For example, dependent types. They add significant complexity

by pron 7y ago

This post highlights my biggest problem with the language: it's about the how, not about the why. For example, dependent types. They add significant complexity to the language and are intended to help with correctness. But are they an effective way to achieve it compared to alternatives? The fact that even current formal verification research is mostly looking elsewhere seems to suggest that the answer is likely negative, so why focus on them now? Or algebraic effects, about which the article says, "These effect-system libraries may help to achieve a boilerplate-free nirvana of tracking algebraic effects at much more granular levels." But is that even a worthwhile goal? Why is it nirvana to more easily do something that might not be worth doing at all? Researchers who study some technique X ask themselves how best to use X to do Y, and publish a series of papers on the subject, but practitioners don't care about the answer to that question because they don't care about that question at all. They want to know how best to do Y, period. One could say that every language, once designed, is committed to some techniques that it tries to employ in full effect. But any product made for practical use should at least strive to begin with the why rather than the how, both in its original design and throughout its evolution. I work with designers of a popular programming language, and I see them spending literally years first trying to answer the why or the what before getting to the how. So either Haskell is a language intended as a research tool for those studying some particular techniques -- which is a very worthy goal but not one that helps me achieve mine -- or it's intended to provide entertainment for practitioners who are particularly drawn to its style. Either way, it's not a language that's designed to solve a problem for practitioners (and if it is, it doesn't seem that testing whether it actually does so successfully is a priority). I think it's important to have languages for language research, but if that's what they are, don't try to present them as something else. And BTW, at ~0.06% of US market share -- less than Clojure, Elixir, Rust and Fortran, about the same as Erlang and Delphi, and slightly more than Lisp, F# and Elm -- and little or no growth (https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/), I wouldn't call Haskell a "popular language," as this post does, just yet.

patrec 7y ago
Exactly. I find it revealing that having some moderately visible successful software does not feature on this list. Even ocaml does, IMO, better here (bits of mirageOs for non-linux docker; Xen; unison, coq, at least one successful ocaml only company) vs what, pandoc and shellCheck?
- agumonkey 7y ago
  Success story are borderline stupid. Some companies are using haskell for non trivial needs, they just dont talk much about it.
  - kbumsik 7y ago
    > Some companies are using haskell for non trivial needs, they just dont talk much about it. Sorry but doesn't this statement fit better to the definition of "borderline" something?
    - agumonkey 7y ago
      Apologies if my comment felt offending. I've just seen a few stories about companies using non mainstream tools for important matter without making a product out of it. Caring only about known programs made in <lang> is shallow IMO
      - pron 7y ago
        If a language is used at a company and its use is not spreading rapidly within that company (as has happened with Fortran and C and Java/Python) you do ask yourself, is the language actually serving a business purpose, or is the business serving a "language purpose" by giving some fans their entertainment? I can't think of a worse signal for a language's value, or perhaps the size of its useful domain, than it being used for years at a company without spreading.
        agumonkey 7y ago
        Mild point, there's no way a single language would suddenly progress through all layers no matter what its qualities. I understand your question though, it's highly possible that the devs picked haskell for their own interest. But so far it's been a few years and the haskell "module" is dealing with the core of their business.
        7y ago
rtpg 7y ago
Though I don’t use it professionally, I believe purescript has proven that algebraic effects systems are very useful for granular effect handling. Things like “this writes to the database”, “this makes an unbounded query”, “this requires a random number generator “, rather than a nebulous “oh this has I/O” is very powerful and useful for maintaining a system
- pron 7y ago
  > Things like “this writes to the database”, “this makes an unbounded query”, “this requires a random number generator “, rather than a nebulous “oh this has I/O” is very powerful and useful for maintaining a system 1. How do you know that? 2. Why? 3. Why is tracking the effects in the type system useful? Even if and where this is important, it could be easily achieved using something like Java's 20+-year-old security manager and with finer granularity (i.e. you can allow code to read or write certain files, connect to certain domains etc.) [1]. Just because you can do something in the type system, doesn't mean you should, as it may not be the best way. [1]: https://docs.oracle.com/en/java/javase/13/security/permissions-jdk1.html https://docs.oracle.com/en/java/javase/13/security/permissio...
  - hopia 7y ago
    As for 3. Haskell already does it now with the IO monad. I can see how having something more specific for effects than the most generic IO type is the next step on an evolutionary path for languages with an advanced type system. The concern whether or not it is worthwhile then extends to the whole type system.
  - IceDane 7y ago
    Because it is a way to force you think about how you structure your code. You necessarily pull out the pure parts and are explicit in handling all the impure parts. This also makes it very easy to test your code. Why is it done in the type system? Well, because the goal is to have guarantees at compile-time, and this happens to be something that can be expressed in a sufficiently powerful type system.
    - 7y ago
uhryks 7y ago
Haskell is and has always been primarily a research language. It just has some popularity outside the academia. This is something everybody investing into Haskell knows (or should know).
- pron 7y ago
  That's not what the author of the article seems to think, though. He admits that "Haskell is never really going to be a mainstream programming language," but even non-mainstream languages, like, say, Erlang or Clojure are very much concerned with the why, and aren't aimed at research. A research language and a non-mainstream language are two very different things.
mjul 7y ago
If you look in the Haskell 2010 report the Goals section states that Haskell was designed for teaching and research and applications (in that order) and that the design committee intended that Haskell would serve as a basis for future research in language design. Usable for applications here means that it should be stable (_e.g._ so you can write your research tools in it and as a common language for sharing code examples in the academic programming language research community). Market share in the greater software development area (outside academia) was not one of its goals.
mumblemumble 7y ago
This has been a growing concern of mine about the whole functional-as-defined-by-John-Backus (viz, not including lisp) lineage of programming languages. On my grumpy days, I'm inclined to say that the current culture can be best described as, "Got excited and ran off to do some coding before making it all the way to the end of The Evolution of a Haskell Programmer." (https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html) That doesn't particularly bother me in Haskell, which was born as, and continues to primarily serve as, a platform for language research. (Secondary purpose, at least for me: A platform for daydreaming about a non-post-C++ existence. I suspect that professional use remains a small minority.) It gets more worrisome to me in an ostensibly industry-oriented language like Scala. There I start to fear that my colleagues choose ways of solving problems for about the same reasons that I prefer mechanical watches over quartz ones: Not because they're more practical or more economical - no in both cases - but because they're cooler. I think it'll probably get better naturally, though, the same way that lisp programming culture eventually stopped being quite so enamored of macros, and Java programming culture eventually stopped being quite so enamored of elaborate XML configuration files.
willtim 7y ago
> They add significant complexity to the language and are intended to help with correctness. But are they an effective way to achieve it compared to alternatives? Python programmers say the same about all static type systems. What alternatives do you have in mind? Are they as generally applicable as dependant types? Dependant types are a simple and unifying way to solve a variety of shortcomings with conventional statically typed systems. For example, dependant types can express first-class modules as simple records, or allow sophisticated record operations like merge to be well-typed. > [tracking algebraic effects] But is that even a worthwhile goal? Why is it nirvana to more easily do something that might not be worth doing at all? Given the various hugely expensive bugs I have been involved in (e.g. Java toString on a date reading the system locale). I would say yes. In my industry, reproducable numbers are of vital importance, so much so that the quants use Haskell in preference to something more mainstream and supported.
- pron 7y ago
  > Python programmers say the same about all static type systems. So what? Even if you think having X is good, that doesn't mean having 100X is necessarily better. > Dependant types are a simple and unifying way to solve a variety of shortcomings with conventional statically typed systems. But solving problems with type systems is not a business goal. Increasing correctness is. > What alternatives do you have in mind? The same ones that formal methods research focuses on (for deep properties): model checking and concolic testing, which have shown much better scalability than deductive methods. Dependent types are a powerful, general and complex mechanism that only scales well for very simple problems. > Given the various hugely expensive bugs I have been involved in (e.g. Java toString on a date reading the system locale). I would say yes. There are easier ways, like Java's permission system, that I mentioned elsewhere.
  - willtim 7y ago
    > But solving problems with type systems is not a business goal. Increasing correctness is. I gave an example of increasing correctness in the context of record data types, something almost every business app does. > The same ones that formal methods research focuses on (for deep properties): model checking and concolic testing, which have shown much better scalability than deductive methods. And these are good alternatives for some classes of problem, but how would I use them to type check a SQL query? > There are easier ways, like Java's permission system, that I mentioned elsewhere. Hmmm I have my doubts that this is really fit for such a purpose, otherwise why are there various efforts to build a deterministic JVM?
pjmlp 7y ago
Which is why although I see these kind of languages quite relevant to advance the state of the art, the industry belongs to impure multi-paradigm languages. Like Brian Goetz puts it, it is not FP vs OOP, rather combining FP and OOP, using the best of each to solve different kinds of problems with the same tool.
- pron 7y ago
  Combining FP and OOP is not a practical goal in and of itself, either (although it is a research goal for other languages led by researchers, such as Scala). At best, it's a means to some end, and Brian Goetz treats it as such. He cares more about the why than the how.
  - pjmlp 7y ago
    Agreed. Some problems get better solved as a set of classes, others as functions operating across data alongside pattern matching, and yet others are happy to take lambdas as callbacks. Many of the anti-OOP crowd doesn't realize how much OOP is already available on Common Lisp, that Smalltalk-80 already allowed for a good LINQ like mix with its blocks and collection methods, or how SML modules can be combined to make what isn't much different from interface based polymorphism. It is a matter of having a nice toolbox instead of just a hammer. :)
- hopia 7y ago
  I'm not so sure a multi-paradigm language is truly the ideal alternative. Languages that brag being multi-paradigm, such as Python or Javascript, in the end offer very few facilities for actual functional programming. It just doesn't feel idiomatic with them. FP and OOP are both well tested design patterns. Mixing them up in an incoherent way just makes the whole software architecture somewhat unpredictable.
  - pjmlp 7y ago
    The problem lies more on the programmer than the language.
agentultra 7y ago
They add significant complexity to the language and are intended to help with correctness. Not exactly -- they're intended to help with reasoning about the structure of programs and hopefully reject the obviously wrong ones. Correctness would still require a more formal system of validation. Whether this is more easily achieved in a language like Haskell is still an open question. The LiquidHaskell team and Synquid project are both very interesting. In a Haskell program the compiler trivially rejects programs that fail to provide a branch for a missing case. I can reason about the scope of what a function can do (and what it cannot) based on it's type information. I can reason about an equation in familiar terms of substitution and composition. Types don't automatically ensure my program is correct, for some vague notion of correctness. Either way, it's not a language that's designed to solve a problem for practitioners If I am right to assume that practitioners are programmers then I have to disagree with the premise here. I am not a researcher. I write software for factories to help real people I've met face to face solve real problems. I have solved pragmatic, real-world problems by writing programs with Haskell and it was a productive, novel experience. The feature I recently shipped to production has migrated nearly a million schema-less JSON documents to a well-defined schema, continuously back-fills the new table from an AWS Lambda function when we receive data in the old format, and was largely only possible to do in such a short amount of time because of the features of Haskell's type system. I haven't had a single bug report or failure in 5 months to boot. To compare: every single Javascript service we've shipped to production in the last three years, despite all of the testing, validation, and effort we put in to getting it right has at least one production error within three months. Tolerance for these failures has to be built into everything we do. Haskell is not only suited for research. It is used in Facebook and Github. It has plenty of industrial uses and is definitely designed for and with the aid of practitioners. It's development is largely supported by volunteers: practitioners and researchers alike. It may not be popular but all it takes is one startup to choose it as their basis to change the conversation. The Viaweb team chose Lisp, arguably as obscure as Haskell at the time, and did great work. As for dependent types the why is simple: we can express richer specifications in the type system. It would enable Haskell to use a uniform language for terms and types. For programmers the simplest, minimal example are sized vectors as types. You can pass around a vector in Haskell that is sized so that out-of-bounds access is not possible. However the size of the vector is opaque at the type level. With a dependently-typed vector you could specify the bounds of the vector your algorithm supports which further reduces cases where a programmer mistakenly uses your function for unbounded inputs. This is only the minimal example but dependently typed languages scale up from there: there are research languages that have implemented full-on interactive theorem provers and libraries that can encode the whole of mathematical research and knowledge in them: Lean and mathlib. I firmly believe this is where programming is going to go. Dependently typed languages are the next step. I started writing a guide for interested hackers to get started writing real, working programs in a research-heavy dependently-typed programming language called Lean which you can find here: https://agentultra.github.io/lean-for-hackers/ https://agentultra.github.io/lean-for-hackers/ I suggest giving it a shot before condemning Haskell so easily. There's a lot of promise here. And in my experience, selling Haskell is a lot easier than selling formal verification, fwiw. Hardly anyone uses TLA+ compared to Haskell. And I spend a fair amount of time and energy trying to sell both.
whateveracct 7y ago
Another Haskell post, another pron comment about how its community is misguided and wasting their time. I've solved production problems with Haskell (including w/advanced type system features & dependent types). I will continue to do so. And I will probably write other commercial, money-making software for enterprises and for myself for years to come. I have plenty of experience programming in other languages. Clojure, Go, Java, Python. Haskell was the hardest to pick up. But now that I know it, writing other languages requires so much more energy in comparison. I barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%)
- hopia 7y ago
  Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software. Out of interest, what kind of software do you build with Haskell? I'm doing web stuff and haven't quite been able to decide whether to stick to Haskell or Elixir for my own projects.
  - whateveracct 7y ago
    Hm I'd describe it mostly as generic "backend engineering." Web services, databases, data processing, etc. I've used GHCJS as well but I mostly made small changes (I don't have frontend skills.) In my free time I'm making games in Haskell, but that's slow-going partially due to the ecosystem not being mature but mostly due to lack of free time :)
- pron 7y ago
  > I've solved production problems with Haskell What I said was that Haskell's design and evolution have been primarily guided by research questions rather than business needs, not that it's unsuitable for production use. I didn't say it's unsuitable for production use, nor do I think it. That doesn't change the pretty obvious fact that its features are mostly guided by research questions. > barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%) If that effect were scalable and largely universal, then there would be no need for this discussion, anyway. But if it works well for you and the other thousands of developers who make up ~0.06% of the market, then it's great that it's available. Research languages also serve a very valuable goal in figuring out what works and what doesn't. If no one used them, we wouldn't know.
solatic 7y ago
> but practitioners don't care about the answer to that question because they don't care about that question at all. They want to know how best to do Y, period. OK, I'll bite. If the entirety of your goal is to do Y, you will never write a single test. Why would you write a test? It doesn't "do Y", for whichever Y is producing profit or some other benefit for you. Real, True Scotsmen understand that how to do Y is important, because it makes sure that they'll be able to do Z tomorrow. Tests are not essential for functional systems, they are essential for maintainable systems. Types are just tests enforced by the compiler. Every type-level tool that Haskell gives you is just another tool that makes it easier to write tests that actually help prove that your code is still working. Half the problem with our industry is that no other industry would accept unmaintainable product. Too many practicioners are practically proud of all their rewrites and green-field projects.
leshow 7y ago
What would satisfy you? And don't you think you are holding Haskell to an unfair standard that you're not holding to other languages? Do you have research to show a GC is better than manual memory management? That object oriented programming is any better than procedural? Or any of the other thousands of questions you could ask about extant languages today. But for some reason you need rock-solid evidence dependent typing does X before it's worthwhile to be used in an language?
przemo_li 7y ago
Read up on logical fallacies. You claim Haskell is how language and then point out how stupid it is. But we only have your word that Haskell indeed is how language. Show your proof ;)

by pron 7y ago

patrec 7y ago

Exactly. I find it revealing that having some moderately visible successful software does not feature on this list. Even ocaml does, IMO, better here (bits of mirageOs for non-linux docker; Xen; unison, coq, at least one successful ocaml only company) vs what, pandoc and shellCheck?

agumonkey 7y ago
Success story are borderline stupid. Some companies are using haskell for non trivial needs, they just dont talk much about it.
- kbumsik 7y ago
  > Some companies are using haskell for non trivial needs, they just dont talk much about it. Sorry but doesn't this statement fit better to the definition of "borderline" something?
  - agumonkey 7y ago
    Apologies if my comment felt offending. I've just seen a few stories about companies using non mainstream tools for important matter without making a product out of it. Caring only about known programs made in <lang> is shallow IMO
    - pron 7y ago
      If a language is used at a company and its use is not spreading rapidly within that company (as has happened with Fortran and C and Java/Python) you do ask yourself, is the language actually serving a business purpose, or is the business serving a "language purpose" by giving some fans their entertainment? I can't think of a worse signal for a language's value, or perhaps the size of its useful domain, than it being used for years at a company without spreading.
      - agumonkey 7y ago
        Mild point, there's no way a single language would suddenly progress through all layers no matter what its qualities. I understand your question though, it's highly possible that the devs picked haskell for their own interest. But so far it's been a few years and the haskell "module" is dealing with the core of their business.
        7y ago

rtpg 7y ago

Though I don’t use it professionally, I believe purescript has proven that algebraic effects systems are very useful for granular effect handling. Things like “this writes to the database”, “this makes an unbounded query”, “this requires a random number generator “, rather than a nebulous “oh this has I/O” is very powerful and useful for maintaining a system

pron 7y ago
> Things like “this writes to the database”, “this makes an unbounded query”, “this requires a random number generator “, rather than a nebulous “oh this has I/O” is very powerful and useful for maintaining a system 1. How do you know that? 2. Why? 3. Why is tracking the effects in the type system useful? Even if and where this is important, it could be easily achieved using something like Java's 20+-year-old security manager and with finer granularity (i.e. you can allow code to read or write certain files, connect to certain domains etc.) [1]. Just because you can do something in the type system, doesn't mean you should, as it may not be the best way. [1]: https://docs.oracle.com/en/java/javase/13/security/permissions-jdk1.html https://docs.oracle.com/en/java/javase/13/security/permissio...
- hopia 7y ago
  As for 3. Haskell already does it now with the IO monad. I can see how having something more specific for effects than the most generic IO type is the next step on an evolutionary path for languages with an advanced type system. The concern whether or not it is worthwhile then extends to the whole type system.
- IceDane 7y ago
  Because it is a way to force you think about how you structure your code. You necessarily pull out the pure parts and are explicit in handling all the impure parts. This also makes it very easy to test your code. Why is it done in the type system? Well, because the goal is to have guarantees at compile-time, and this happens to be something that can be expressed in a sufficiently powerful type system.
  - 7y ago

uhryks 7y ago

Haskell is and has always been primarily a research language. It just has some popularity outside the academia. This is something everybody investing into Haskell knows (or should know).

pron 7y ago
That's not what the author of the article seems to think, though. He admits that "Haskell is never really going to be a mainstream programming language," but even non-mainstream languages, like, say, Erlang or Clojure are very much concerned with the why, and aren't aimed at research. A research language and a non-mainstream language are two very different things.

mjul 7y ago

If you look in the Haskell 2010 report the Goals section states that Haskell was designed for teaching and research and applications (in that order) and that the design committee intended that Haskell would serve as a basis for future research in language design. Usable for applications here means that it should be stable (_e.g._ so you can write your research tools in it and as a common language for sharing code examples in the academic programming language research community). Market share in the greater software development area (outside academia) was not one of its goals.

mumblemumble 7y ago

This has been a growing concern of mine about the whole functional-as-defined-by-John-Backus (viz, not including lisp) lineage of programming languages. On my grumpy days, I'm inclined to say that the current culture can be best described as, "Got excited and ran off to do some coding before making it all the way to the end of The Evolution of a Haskell Programmer." (https://www.willamette.edu/~fruehr/haskell/evolution.html https://www.willamette.edu/~fruehr/haskell/evolution.html) That doesn't particularly bother me in Haskell, which was born as, and continues to primarily serve as, a platform for language research. (Secondary purpose, at least for me: A platform for daydreaming about a non-post-C++ existence. I suspect that professional use remains a small minority.) It gets more worrisome to me in an ostensibly industry-oriented language like Scala. There I start to fear that my colleagues choose ways of solving problems for about the same reasons that I prefer mechanical watches over quartz ones: Not because they're more practical or more economical - no in both cases - but because they're cooler. I think it'll probably get better naturally, though, the same way that lisp programming culture eventually stopped being quite so enamored of macros, and Java programming culture eventually stopped being quite so enamored of elaborate XML configuration files.

willtim 7y ago

> They add significant complexity to the language and are intended to help with correctness. But are they an effective way to achieve it compared to alternatives? Python programmers say the same about all static type systems. What alternatives do you have in mind? Are they as generally applicable as dependant types? Dependant types are a simple and unifying way to solve a variety of shortcomings with conventional statically typed systems. For example, dependant types can express first-class modules as simple records, or allow sophisticated record operations like merge to be well-typed. > [tracking algebraic effects] But is that even a worthwhile goal? Why is it nirvana to more easily do something that might not be worth doing at all? Given the various hugely expensive bugs I have been involved in (e.g. Java toString on a date reading the system locale). I would say yes. In my industry, reproducable numbers are of vital importance, so much so that the quants use Haskell in preference to something more mainstream and supported.

pron 7y ago
> Python programmers say the same about all static type systems. So what? Even if you think having X is good, that doesn't mean having 100X is necessarily better. > Dependant types are a simple and unifying way to solve a variety of shortcomings with conventional statically typed systems. But solving problems with type systems is not a business goal. Increasing correctness is. > What alternatives do you have in mind? The same ones that formal methods research focuses on (for deep properties): model checking and concolic testing, which have shown much better scalability than deductive methods. Dependent types are a powerful, general and complex mechanism that only scales well for very simple problems. > Given the various hugely expensive bugs I have been involved in (e.g. Java toString on a date reading the system locale). I would say yes. There are easier ways, like Java's permission system, that I mentioned elsewhere.
- willtim 7y ago
  > But solving problems with type systems is not a business goal. Increasing correctness is. I gave an example of increasing correctness in the context of record data types, something almost every business app does. > The same ones that formal methods research focuses on (for deep properties): model checking and concolic testing, which have shown much better scalability than deductive methods. And these are good alternatives for some classes of problem, but how would I use them to type check a SQL query? > There are easier ways, like Java's permission system, that I mentioned elsewhere. Hmmm I have my doubts that this is really fit for such a purpose, otherwise why are there various efforts to build a deterministic JVM?

pjmlp 7y ago

Which is why although I see these kind of languages quite relevant to advance the state of the art, the industry belongs to impure multi-paradigm languages. Like Brian Goetz puts it, it is not FP vs OOP, rather combining FP and OOP, using the best of each to solve different kinds of problems with the same tool.

pron 7y ago
Combining FP and OOP is not a practical goal in and of itself, either (although it is a research goal for other languages led by researchers, such as Scala). At best, it's a means to some end, and Brian Goetz treats it as such. He cares more about the why than the how.
- pjmlp 7y ago
  Agreed. Some problems get better solved as a set of classes, others as functions operating across data alongside pattern matching, and yet others are happy to take lambdas as callbacks. Many of the anti-OOP crowd doesn't realize how much OOP is already available on Common Lisp, that Smalltalk-80 already allowed for a good LINQ like mix with its blocks and collection methods, or how SML modules can be combined to make what isn't much different from interface based polymorphism. It is a matter of having a nice toolbox instead of just a hammer. :)
hopia 7y ago
I'm not so sure a multi-paradigm language is truly the ideal alternative. Languages that brag being multi-paradigm, such as Python or Javascript, in the end offer very few facilities for actual functional programming. It just doesn't feel idiomatic with them. FP and OOP are both well tested design patterns. Mixing them up in an incoherent way just makes the whole software architecture somewhat unpredictable.
- pjmlp 7y ago
  The problem lies more on the programmer than the language.

agentultra 7y ago

They add significant complexity to the language and are intended to help with correctness. Not exactly -- they're intended to help with reasoning about the structure of programs and hopefully reject the obviously wrong ones. Correctness would still require a more formal system of validation. Whether this is more easily achieved in a language like Haskell is still an open question. The LiquidHaskell team and Synquid project are both very interesting. In a Haskell program the compiler trivially rejects programs that fail to provide a branch for a missing case. I can reason about the scope of what a function can do (and what it cannot) based on it's type information. I can reason about an equation in familiar terms of substitution and composition. Types don't automatically ensure my program is correct, for some vague notion of correctness. Either way, it's not a language that's designed to solve a problem for practitioners If I am right to assume that practitioners are programmers then I have to disagree with the premise here. I am not a researcher. I write software for factories to help real people I've met face to face solve real problems. I have solved pragmatic, real-world problems by writing programs with Haskell and it was a productive, novel experience. The feature I recently shipped to production has migrated nearly a million schema-less JSON documents to a well-defined schema, continuously back-fills the new table from an AWS Lambda function when we receive data in the old format, and was largely only possible to do in such a short amount of time because of the features of Haskell's type system. I haven't had a single bug report or failure in 5 months to boot. To compare: every single Javascript service we've shipped to production in the last three years, despite all of the testing, validation, and effort we put in to getting it right has at least one production error within three months. Tolerance for these failures has to be built into everything we do. Haskell is not only suited for research. It is used in Facebook and Github. It has plenty of industrial uses and is definitely designed for and with the aid of practitioners. It's development is largely supported by volunteers: practitioners and researchers alike. It may not be popular but all it takes is one startup to choose it as their basis to change the conversation. The Viaweb team chose Lisp, arguably as obscure as Haskell at the time, and did great work. As for dependent types the why is simple: we can express richer specifications in the type system. It would enable Haskell to use a uniform language for terms and types. For programmers the simplest, minimal example are sized vectors as types. You can pass around a vector in Haskell that is sized so that out-of-bounds access is not possible. However the size of the vector is opaque at the type level. With a dependently-typed vector you could specify the bounds of the vector your algorithm supports which further reduces cases where a programmer mistakenly uses your function for unbounded inputs. This is only the minimal example but dependently typed languages scale up from there: there are research languages that have implemented full-on interactive theorem provers and libraries that can encode the whole of mathematical research and knowledge in them: Lean and mathlib. I firmly believe this is where programming is going to go. Dependently typed languages are the next step. I started writing a guide for interested hackers to get started writing real, working programs in a research-heavy dependently-typed programming language called Lean which you can find here: https://agentultra.github.io/lean-for-hackers/ https://agentultra.github.io/lean-for-hackers/ I suggest giving it a shot before condemning Haskell so easily. There's a lot of promise here. And in my experience, selling Haskell is a lot easier than selling formal verification, fwiw. Hardly anyone uses TLA+ compared to Haskell. And I spend a fair amount of time and energy trying to sell both.

whateveracct 7y ago

Another Haskell post, another pron comment about how its community is misguided and wasting their time. I've solved production problems with Haskell (including w/advanced type system features & dependent types). I will continue to do so. And I will probably write other commercial, money-making software for enterprises and for myself for years to come. I have plenty of experience programming in other languages. Clojure, Go, Java, Python. Haskell was the hardest to pick up. But now that I know it, writing other languages requires so much more energy in comparison. I barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%)

hopia 7y ago
Yeah the the very first and by now a worn out dismissal you always see is it's an academic research language, not for writing REAL software. Out of interest, what kind of software do you build with Haskell? I'm doing web stuff and haven't quite been able to decide whether to stick to Haskell or Elixir for my own projects.
- whateveracct 7y ago
  Hm I'd describe it mostly as generic "backend engineering." Web services, databases, data processing, etc. I've used GHCJS as well but I mostly made small changes (I don't have frontend skills.) In my free time I'm making games in Haskell, but that's slow-going partially due to the ecosystem not being mature but mostly due to lack of free time :)
pron 7y ago
> I've solved production problems with Haskell What I said was that Haskell's design and evolution have been primarily guided by research questions rather than business needs, not that it's unsuitable for production use. I didn't say it's unsuitable for production use, nor do I think it. That doesn't change the pretty obvious fact that its features are mostly guided by research questions. > barely have to try to deliver equal results compared to solving the same problems with other tools (so it's not a result of me just increasing my skill - the tool itself is a force multiplier for myself 100%) If that effect were scalable and largely universal, then there would be no need for this discussion, anyway. But if it works well for you and the other thousands of developers who make up ~0.06% of the market, then it's great that it's available. Research languages also serve a very valuable goal in figuring out what works and what doesn't. If no one used them, we wouldn't know.

solatic 7y ago

> but practitioners don't care about the answer to that question because they don't care about that question at all. They want to know how best to do Y, period. OK, I'll bite. If the entirety of your goal is to do Y, you will never write a single test. Why would you write a test? It doesn't "do Y", for whichever Y is producing profit or some other benefit for you. Real, True Scotsmen understand that how to do Y is important, because it makes sure that they'll be able to do Z tomorrow. Tests are not essential for functional systems, they are essential for maintainable systems. Types are just tests enforced by the compiler. Every type-level tool that Haskell gives you is just another tool that makes it easier to write tests that actually help prove that your code is still working. Half the problem with our industry is that no other industry would accept unmaintainable product. Too many practicioners are practically proud of all their rewrites and green-field projects.

leshow 7y ago

What would satisfy you? And don't you think you are holding Haskell to an unfair standard that you're not holding to other languages? Do you have research to show a GC is better than manual memory management? That object oriented programming is any better than procedural? Or any of the other thousands of questions you could ask about extant languages today. But for some reason you need rock-solid evidence dependent typing does X before it's worthwhile to be used in an language?

przemo_li 7y ago

Read up on logical fallacies. You claim Haskell is how language and then point out how stupid it is. But we only have your word that Haskell indeed is how language. Show your proof ;)