24 ms·

On Marketing Haskell

156 points by azhenley 6y ago

dmix 6y ago
One of the best ways to get adoption is to have people take initial risks and build real world serious product with a serious team/company backing behind it. Erlang got a big boost when it came out WhatsApp scaled it up with a billion users, with tiny team and only a few servers. React/React Native got boosted by Instagram adopting it to build their production mobile app. Rails had 37signals/Basecamp and Github/Shopify/early Twitter/etc. Haskell needs some more famous commercial "killer-app" examples for real businesses and real teams. And yes I'm very familiar with the current selection of popular Haskell examples. Currently I only ever hear Haskell (and Ocaml for that matter) being used by engineers for backend engineery things (parsing programming languages, fighting spam, tooling) mostly for OSS tools. On a positive note, PureScript is trying to position itself as a practical Haskell and making a bit of success. One helpful reason is they have a nice app/company leading the way as a production app with Lumi [1], with their founder playing a key role on the language/ecosystem dev side as well: https://www.lumi.dev/blog/purescript-and-haskell-at-lumi https://www.lumi.dev/blog/purescript-and-haskell-at-lumi This is what Haskell needs more of - and critical a company promoting/blogging about their progress using Haskell as well as contributing back into the community. Another big one is simply a sort of 'starter kit' which guides you with best practices on how to architect a serious Haskell app (ie, using STM, free, etc). React has plenty of starter kits. For Rust CLI apps there is a great starter kit https://github.com/iqlusioninc/abscissa https://github.com/iqlusioninc/abscissa I'd love to see a similar starting point micro-framework for starting a new Haskell app that makes a bunch of importation decisions for you and guides the structure of the project.
- narrationbox 6y ago
  There is Hasura, they are probably the most famous commercial Haskell app right now (in terms of brand recognition). https://hasura.io https://hasura.io
  - dmix 6y ago
    That fits into the tooling category but it is a serious company. I found one blog post mentioning Haskell but without much technical details: https://hasura.io/blog/from-zero-to-hipster-haskell-in-production-97ea99d90c3b/ https://hasura.io/blog/from-zero-to-hipster-haskell-in-produ... I hope they write more..
- centimeter 6y ago
  I’m aware of 3-5 large companies (the number depending on what you define as “large”) that are using Haskell for big, serious projects, but all but one of them is in the defense or banking industries. Companies in these industries are usually not interested in sharing their experiences or engineering techniques, so it feels very quiet compared to when some hip startup starts (loudly) marketing some technology they’re using.
- chrischen 6y ago
  Ocaml (via ReasonML syntax) accounts for over 50% of Messenger.com. frontend code. https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... I’ve personally found starting adoption by converting pure domain code first to be the best approach, since it does not have to interact with legacy code.
- tayo42 6y ago
  a tagent, is erlang and maybe elixir worth spending time learning if Ive spent time writing haskell and scala?
  - dmix 6y ago
    Yes, I loved learning Erlang (and later Elixir was a breeze). It's a good experience in learning how to build apps using the Actor model (they predated it before it was called Actors) and building resilient, multi-process based systems where failure is part of the design and fully accounted for. It also has a really small and simple syntax and wonderful pattern matching heavy approach to code, which is something I've took with me to other languages (and a feature sorely missing in most major languages). OTP is a bit of a beast and feels overwhelming at first, for example when you download an HTTP server to run your app you actually "run" the supervisor which spawns a bunch of processes. And this is all within your own application which is a group of isolated processes. I'd personally use Erlang/Elixir for everything if it had strong typing. And I still might anyway for my next project.
- sigrlami 6y ago
  There are more than 200 companies using Haskell in a different levels, check out https://haskellcosm.com https://haskellcosm.com
centimeter 6y ago
With respect to availability of talent pool: my alma mater used to teach Haskell as the introductory programming language, and from what I’ve heard from people who were around then it was great for faculty and students. However, a very large corporate donor pressured the university to switch to Java in the early 2000s, because that’s what they used internally and they wanted a large local supply of pre-trained fungible labor. Now only a small fraction of the top students who study advanced topics in PL or compilers or what-have-you will come out of the university knowing how to use Haskell. I think this is deeply unfortunate - if society could quantum tunnel through to the point where Haskell was the safe, readily hireable corporate choice, the state of software (especially corporate software) would be a lot better off.
- gowld 6y ago
  I don’t get it. What does removing Haskell from the into course have to do with the use of Haskell in the PL or compilers class?
  - centimeter 6y ago
    Most CS students don’t take those classes. They’ll take data structures, algorithms, game design, databases, etc. which are mostly in Java or C++.
    - zabzonk 6y ago
      Most CS students certainly do take compiler classes, at least for any decent CS course.
  - mumblemumble 6y ago
    If it's anything like what happened at my alma mater, they may well have switched to Java for everything. It's really a disservice to students. Developing competence in a variety of programming paradigms is a career-expanding experience. It makes picking up a new language - and, by extension, a new technology stack - a quick and easy thing to do, because there will be very few ways of doing things that you haven't seen before. Which, in turn, makes it a lot more feasible to pivot your career or act quickly when an opportunity arrives. A bunch of students who know only Java, on the other hand, is exactly what big corporate employers want. For employers, it maximizes the interchangeability of employees. For employees, it minimizes the interchangeability of employers.
xixixao 6y ago
Javascript is not popular because it has Java in the name name...
- AnimalMuppet 6y ago
  But it was a big initial boost for it. "ECMAScript" didn't have the same marketability, and Java was being publicized and becoming popular, so they renamed it to JavaScript.
  - logicprog 6y ago
    I still maintain that ECMA sounds like an unpleasant skin disease. Not good marketing, that!
  - skybrian 6y ago
    That's wrong on the history. Netscape called the language "LiveScript" before changing it to "JavaScript". Then Microsoft called it "JScript." Then the "ECMAScript" name was chosen as a compromise. Using different names for the same language didn't change anything fundamental. It was built into the browser, so if you wanted to write code in the browser you didn't have a choice.
  - deleted 6y ago
    [deleted]
- zabzonk 6y ago
  Unless I have missed something, it is immensely popular.
  - tome 6y ago
    xixixao is making a statement about the reason for Javascript's popularity, not about its popularity itself.
- ipnon 6y ago
  It would be unreasonable to attribute none of JavaScript's popularity to its name. https://stackoverflow.com/questions/2018731/why-is-javascript-called-javascript-since-it-has-nothing-to-do-with-java https://stackoverflow.com/questions/2018731/why-is-javascrip... Even JavaScript's first name Mocha is a reference to chocolate coffee and the Java language.
kace91 6y ago
Although I think the post is very clear describing the reasons why Haskell isn't attractive in business, this part rubbed me the wrong way: > Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”). Thinking about readability or usability as emotions and social factors, rather than as first level concerns, is a non starter to me, and I find it extremely off putting that the author seems to pile up those qualities in the marketing "group", as if they were not real properties of a language. You can design a drill in a way that makes it the most scientifically correct at using the power it's supplied efficiently, but if the design hurts the users hands and requires months of training to operate, any worker will throw it in the trash, because they can drill things just fine with a regular tool. (I'm not necessarily saying that Haskell is that drill, just saying that usability should never be treated with condescension when you're designing tools).
- awinter-py 6y ago
  haskell isn't a drill it's a root canal
  - smitty1e 6y ago
    Well, if the dental work needs a conceptual makeover, then see a dentist. I'd contend that the immutability of containers and why Docker is such a win might be getting Haskell to its moment. For me, the hardest unlearning piece isn't the syntax. Rather, the impact of the purity on the execution model is the stumbling block. Monads seem arcane because laziness + purity = statelessness, which never really had tangible meaning until the idea that a Docker image is also stateless came along. Maybe some cruder, crayon-level examples can be devised to help us slow folk get there.
    - awinter-py 6y ago
      docker is a win on desktop because I can run two database instances at once on my laptop + understand what's happening + a win for cloud when combined with kube to understand exactly what's being exposed haskell isn't simple or understandable it's flexible but I have no idea what's happening where effects are getting folded in from all over the codebase all the type abstractions are for injecting code from somewhere else
weinzierl 6y ago
The author of the article has an interesting contact page: "To contact me via email run one of the following scripts to generate my contact information. I find this is an effective filter against the deluge of emails from recruiters." The "scripts" are offered in Haskell, x86-64 Assembly and Python. Solution is pretty obvious though, no need to run them actually.
- Tade0 6y ago
  Recruiters who do contact me will be named and shamed publicly. I would applaud any recruiter who went through all that trouble just to contact a person, regardless of my interest in their offer.
pron 6y ago
Ask any marketer — it's (almost) never the marketing. Or, rather, it's never the marketing of the "hype and subterfuge" kind. No product dominates the market for decades due to hype and subterfuge, let alone hype and subterfuge deployed decades earlier. It's always the product. It's just that what matters about the product to most people is often not what matters to some minority that insists that “technical excellence” is defined by their own preferences. In the famous VHS vs. Betamax war, the technically superior product won, it’s just that it was superior in matters that appealed to many and inferior in matters that appealed to few. The few famous cases where it was the marketing (diamond rings, maybe?) stick in our mind because they're the exception, not the rule. Blaming marketing problems is often an excuse to overlook product problems. Second, the problem with the message of "code written in Haskell is more correct than code written in other [more popular] languages," isn't that the industry doesn't care about correctness. Correctness translates to cost (to a degree), and the ability to write software as correct as it needs to be more cheaply is actually quite compelling. Rather, the problem with it is that it's simply not true (or, rather, hasn't been shown to be true), certainly not to any degree big enough to matter. That, in and of itself, does not make it a terrible message; after all it's just harmless hype, right? What makes it a terrible message is that it is very clearly not (shown to be) true and yet some Haskellers seem to actually believe it, drunk on their own kool-aid, which makes you think of them as out of touch with reality. At best, it's an emotion (it "feels" more correct), which you've mocked, rather than any sort of "critical thinking," that you present as the desirable standard. Third, the mistake in the perception of the economics of software is not the importance of correctness — that can have an easily measurable impact. It's in the importance of code. Programmers in general, but Haskellers in particular, are obsessed with code. As a result, they grossly overestimate its importance to software. Ask yourself how long it takes you to produce, say, 1000 lines of code of sufficient quality, and then look at a software produced at your company and divide the size of the codebase by the number you came up with. You'll find that the true cost is several times that. The "pure" cost of producing code is not where most of the cost of developing software is. Maybe it's in what you mockingly call "emotions", but it certainly isn't in programming-language semantics. Also, before presenting managers' priorities, it's better to actually speak to actual managers; they just might have some useful insight here, plus, it's what a culture of technical excellence demands, no? All of that means that unless your language has some clear and direct effect on the bottom line — which, these days, usually means it has good performance and/or observability, a good ecosystem, or a monopoly of sorts on some distribution platform -- there is no "message" that can make it popular, other than "it's easy and it's fun." While perhaps not a sufficient requirement for success, this can create a supply of qualified developers that at least won't put your language at a disadvantage. And here's another tip: if your retrospective introspection isn't painful, doesn't discuss any serious and conspicuous flaws with the product, and still paints you as being somehow right after all and everyone else as being somehow wrong — it's probably not true. Worse, it seems untrue. And not calling your own practice one of "engineering excellence" and others' as "throwing enough bodies" can't hurt, either. In other words, I don't know what a good marketing message for Haskell would be, but this post is a good example of a bad one.
wirrbel 6y ago
I am the person that would be the one most likely to adopt haskell in the company I work in. Now, I don't and I won't even though I used it for several pet projects and I would say have learned a lot of haskell and associated patterns. It's not that haskell doesn't have merits. However I feel like they are oversold. While you can build programs that lack certain error classes, they are not bug free and at the same time debugging often was a lot harder than in other languages. The laziness is especially problematic in that regard. Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. Another important problem is the docs. For some reasons they hardly contain examples. You don't get adoption that way. Even if the maintainers feel that the type signatures are documentation enough. And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process.
- lambdasquirrel 6y ago
  > Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.
  - a1369209993 6y ago
    I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.
  - 6y ago
moreaccountspls 6y ago
Anyone using Haskell to drive their business is making a huge mistake in my experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has centered around whatever the latest version of GHC is, with its millions of language extensions and breaking the world with changes like https://gitlab.haskell.org/ghc/ghc/issues/10365 https://gitlab.haskell.org/ghc/ghc/issues/10365 and https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of.... Which is fine if you're doing research or building tools for fun! But it makes an absolutely awful industrial experience when you want to ship features and not get stuck on a bit rotted version of GHC. edit: It's unfortunate that people are downvoting me for offering my experience, especially on a post that wants to make Haskell more attractive to being used in the industry.
- willtim 6y ago
  You have a very valid point. As someone who uses Haskell professionally in a large organisation, I can honestly say that past changes such as FTP and AMP have added very little but caused significant issues for both academic and industrial users. GHC is no longer a Haskell 2010 compiler and unfortunately there seems little interest in the community for creating a new Haskell standard.
- platz 6y ago
  these issues probably did not cause a lot of problems for production software
  - moreaccountspls 6y ago
    Huh? My whole comment is about the fact that they DID cause a lot of problems for production software. The company wrote their flagship product in Haskell, and there is a pretty large chance that that decision will doom them because of the choice to use Haskell. It's unfortunate because the product has a great market fit. If they had choose pretty much any other tech stack, they would be killing it.
    - deleted 6y ago
awinter-py 6y ago
tagged in on a client project written in haskell codebase organization was nonintuitive and I blame type-level programming compilation was so slow and bad that other programs on my laptop started to die the feature I was adding was something that would be library-provided in a normal web language none of the operators have names and are very hard to google; I had to search for things like 'haskell tilde asterisk arrow'. Impossible to know what's from libs vs core language. Lots of explanatory docs online were like 'oh we don't pronounce this one'. Core abstractions have no definition ('to explain that I would have to explain monads but you won't understand monads so GFY'). Monads are just sub rosa dependency injection . lang doesn't protect you from runtime crashes but does apparently protect you from knowing where the program crashed
- fphilipe 6y ago
  Haven’t written any serious Haskell, but doesn’t Hoogle work for searching infix operators? One thing I really like about Haskell is Hoogle. The ability to search by function signature is great. I often wish I could do that in other languages.
  - awinter-py 6y ago
    searched `->` got (->-) :: Bind m => (a -> m b) -> (b -> m c) -> a -> m c semigroupoids Data.Functor.Bind
    - mrkeen 6y ago
      Fair enough. `->` is core syntax, not a library function. It means `->` if you're a Java guy or `=>` if you're a Scala guy. Just search for it the same as you'd search for it in Java or Scala.
      - awinter-py 6y ago
        I'm open to the argument that my imperative / scripting background in some way primes me to learn rails but makes it hard for me to navigate a haskell codebase, and that this is human difference rather than one language being inherently more navigable than the other
solatic 6y ago
> The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Moreover, if you throw enough bodies writing Java at a project for a long-enough period of time, it will produce a result or fail with a fairly predictable set of cashflows, which is itself a low quantifiable risk that’s very easy for a business to plan for. This is a very MBA-like lens through which to examine software development. It's not wrong, but it's also a recipe for mediocrity, which is a great way to damage your culture and sit around wondering why you can never get ahead of your competition. The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? The pessimists will point to Equifax et. al. and tell you that the market simply doesn't care, that businesses can go through downtime after leak after catastrophic failure and their stock will never take a hit. And there's some truth to that. The end consumer actually doesn't really care about the bad news. There's not much that any company in the business can do about that. But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. The value of correctness isn't in the two months after you begin, it's in the two months after your latest release five years from now. It requires vision, patience, already-available human capital, and leadership to realize the benefits. > If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter. If you give your talent the opportunity to work on a Haskell project and they're walking out the door when it's difficult to find Haskell work to begin with, then you, the manager, failed in deciding which talent to hire. If you're looking for a support contract to hedge against the loss of in-house talent, then you've already failed. If you think that legal solutions will protect you against market failure, then you've already failed. Haskell isn't trying to market to these people in the first place, why should it start?
- dehora 6y ago
  To the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being aware of, and even as a rhetorical device, overstating helps bring them into focus. > The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? Because quality is on a spectrum and context specific: commercial domains need quality levels—you have to set magnitude or quantify in some way. The software profession such as it is, tends to come at this a binary matter (cite pretty much any debate about speed vs quality). That gets, I think, amplified in technical communities where correctness is deemed more important or simply more attainable in terms of claims. > But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. I agree with the sentiment; I actually do think we're in a phase where engineering leverage is underestimated, but would qualify it and say this is different to correctness. What great engineering can do is offer a short term technical advantage (eg "secret sauce") and/or a sustainable one (eg "organisational speed"). It's not clear correctness provides that kind of benefit, unless we want to frame as increasing precision/accuracy/reproducibility of results.
tinco 6y ago
I made the decision to stop using Haskell for things I consider "professional" use a couple years ago. No matter how much I love the idea of the language, there's a couple superficial things it gets wrong and one fundamental thing, or at least I believe it's fundamental, perhaps some academics have proof one way or the other. The superficial things are things that are not really part of the language, but more of its standard library, part of the 'prelude', or things the community has agreed upon: - the I/O monad (and others) can throw errors - prelude is full of bad practice like use of strings and linked lists - there's something wrong with how function names can't be namespaced There's more than this, and they're not just things I came up with, they've been fought over in the community at length. Other preludes exist, I/O libraries that don't throw errors, even whole different systems for doing I/O exist. It's not that solutions are hard or impossible, they're there, it's just that the way the language is managed it's not likely that they'd ever be applied in a way the entire community, and especially those drawn to it by any marketing would experience them. Maybe I'm making a fool of myself and things changed in the past couple of years, things were really developing at a rapid pace when I left, but it seemed all the improvements happened around haskell, not to the language itself. When Stack and LTS-Haskell emerged it was the most amazing thing that I saw happening to Haskell in like 10 years, but given the lackluster response Snoyman received from the core team it seemed like they didn't even realize it even though the entire community had like an upheaval. In my opinion, Haskell's marketing is fine. It's being marketed to every college student anywhere that goes to a good enough university that it teaches functional programming. In addition to that there's raving fans (myself included) that extoll its virtues to anyone who would hear. What it needs is a better retention rate. It needs that people who learn it, immediately realise it's fit for production use, that it's not just a fun experiment and a educative way of looking at things. For that we need something like a Haskell 2.0, designed by the community to incorporate everything we learned about Haskell's flaws and make it an absolute powerhouse of productivity. Maybe Haskell should be split into two flavors, one the teaching language with the linked lists, strings and funny pattern matching, and one that's got a prelude that will set you up with the perfect base to build the next compiler, database, service or web application. If all those smart people who learn Haskell and tinker with for a bit, actually stayed around and used it to build awesome stuff, Haskell would truly have an enormous foot print on the world. (not really relevant but the fundamental thing is that Haskell's performance is really hard to predict, this is true for many garbage collected languages, but for Haskell it seems to be extra bad because of the way its paradigm just doesn't map 1:1 to how computers are built)
cs702 6y ago
The idea of "marketing Haskell" to me is akin to marketing math and mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it is succinct. Yes, the benefits of its algebraic type system are many and very real -- if your code compiles, it is correct in many important ways. No one can argue with any of that. But... most people who look into Haskell lose steam as soon as they realize they actually must understand and be able to reason about functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. It's a shame.
- JadeNB 6y ago
  > But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it? Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.
  - marcosdumay 6y ago
    Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.
    - JadeNB 6y ago
      > Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine. Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.
mhh__ 6y ago
This is a slightly loaded question, but is a Haskell codebase harder to work on than one in a reasonable non-functional language? Maybe it's because the bugs are generally less common and easier to fix, but when I look at Haskell codebases it seems like it's quite difficult to achieve the same level of "separation" one would in (say) Java - i.e. an average Haskell file seems to purely consist of many loose free functions (often with very short names!). I might be missing the point but the aforementioned always pushed me away from Haskell - great language, but seems to have legibility as an afterthought (as opposed to python, which is an awful language, does manage to enforce some sort of legible coding style)
- chrischen 6y ago
  I’d suspect the difficulty comes from the paradigm shift. I’ve personally switch code to functional style and it has simplified and reduced code for me. Granted if you don’t know how monads work it could be very confusing.
  - mhh__ 6y ago
    I'm a bit rusty but I do understand the type and category theory behind Haskell. I don't find it confusing, just sort of suboptimal a la C++ template syntax
    - mrkeen 6y ago
      How could it be tweaked to make it better?
      - mhh__ 6y ago
        What D does. Angle brackets make instantiations harder to parse. Also the template keyword is pointless
    - chrischen 6y ago
      Ah yes if you have a language that isn’t conducive to it... luckily Typescript is multi-paradigm enough.
6gvONxR4sf7o 6y ago
I love haskell. What I love about it is the type system and pureness. In python, I loathe refactoring because of how fragile it often is. I hate finding out that I misunderstood what to even pass a function. I want the what haskell brings to those issues. I hate how hard haskell is to debug and how incredibly hard performance is to reason about. I want what python (or another imperative language) brings to those issues. I wonder if haskell had been strict by default rather than lazy by default, if its adoption would be different today. There are certainly pieces of haskell that would make all our lives easier, and I can't wait for them to make their way into mainstream industry work one way or another.
- crazypython 6y ago
  -XStrict?
  - 6gvONxR4sf7o 6y ago
    It's easy to write strict code in haskell, but the default behavior affects community norms, and what's considered standard and idiomatic. That's where I think the evolution could have been different.
    - massysett 6y ago
      Haskell would never have been strict by default, because the entire point of Haskell was to be a common basis for research into non-strict languages. Non-strictness is simply the core of what Haskell is.
rockmeamedee 6y ago
This is a very lucid piece on PL adoption in general. When I think about programming languages, I do think rather emotionally (which is fine, emotions are early warning systems). I liked the linked author's points about the pre-requisites for marketing a solution: It is memorable It includes a key benefit It differentiates It imparts positivity When I think about the most popular languages, they do have all of these: Rust: Memorable: very. It's basically everywhere you look Has a key benefit: going C++ fast without the C++ footguns, memory-safe, WASM integration Differentiates: Using Rust is definitely choosing a particular set of technical tradeoffs Imparts positivity: the community is known to be welcoming, feels cool, cute crab. People re-write existing software in Rust just because it feels good! Yet Haskell has almost none of these: Memorable: I mean, yeah, but it's not being shown to people, and I can't point to a bunch of software. Tools I know of include PostgREST, Hasura, Nix, hledger, which is better than nothing. Key benefit: Hand waving about "being more correct", unlike Rust which has reams of "Microsoft claims 60% of its bugs are memory-errors" articles, and in any case TFA's point is that this needs to be a different message because correctness isn't gonna sell it. Differentiates: This is definitely true, almost too much Imparts positivity: Not really feeling this one with Haskell. People feel good when they figure out a monad is a container & a lens is a path through a data structure, but attempts to explain to others these things feel condescending. Does Haskell even have an animal mascot? (serious question.) Also "stumps" a lot of people and people feel bad about it. There's no "import antigravity" equivalent feeling with Haskell. This sounds pretty sombre for Haskell, though it's been an academic language a long time, and could probably stay alive that way. One positioning possibility is maybe with the Frontend dev world becoming more and more functional and pure-oriented, positioning itself like reasonML, as a way to write and reason about declarative pure UIs. But I don't think the existing Haskell community cares too much about that world. Idk, I'm going to just keep writing Rust and JS, the already most loved and popular languages.
spekcular 6y ago
We dance around this issue in the comments to every Haskell story, but the reason Haskell is hard to market is that it's bad. It's a research language being shoehorned into production by a few people who really love it. Some details of this have been given in this thread; let me suggest the following threads for more: 1) https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/cugohyn/ https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... 2) https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_ocaml/fa4bnsw/ https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_oc... Yes, the Haskell community hates that guy and considers him a troll. But he does functional programming professionally as part of a private consultancy and wrote a book on OCaml. If anyone's equipped to understand what's wrong with Haskell, it's him. Haskell has had 30 years to get its act together. Any benefits it has are drowned out by a sea of buggy tooling and accidental complexity (monads, etc.). Ask yourself this: if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Time to move on.
- todd8 6y ago
  > if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc. However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws. We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.
phreack 6y ago
What about tooling? Haskell being such a powerful language would take off a lot more if there was a very hand-holding, Jetbrains-like IDE that gave you everything you needed and pointed out the problems in your code in real time. Or at least that's what I think, having never worked with haskell in a professional capacity. What are some day to day devtool stacks like in real companies?
- colehasson 6y ago
  ghcide, took a couple days to setup but the effects are phenom https://www.youtube.com/watch?v=cijsaeWNf2E https://www.youtube.com/watch?v=cijsaeWNf2E
- ghostwriter 6y ago
  http://rikvdkleij.github.io/intellij-haskell/ http://rikvdkleij.github.io/intellij-haskell/ it's been around for a while already
jeffdavis 6y ago
"The hard economic truth for engineers is that technical excellence is overwhelmingly irrelevant" No. Technical excellence matters a lot when used appropriately, but competing with javascript and python is not where haskell is going to win. There IS a language with HUGE success that is: declarative, strongly typed with type inference, lazy, and no side effects. It's called SQL[1]. That's where Haskell could shine -- compared with SQL. Imagine Maybe rather than NULLs, a sane language, multiple returns, a much better type system, etc. Python and Java can't touch SQL, but haskell could. [1] http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-cousin-of-haskell/ http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-...
- dllthomas 6y ago
  SQL does not have type inference. It's dynamically typed, and will break at runtime if you feed the wrong type into something. It probably is strongly typed, depending where you draw that line. It also sometimes has side effects, although that's more dialect specific than present in the standard I think (when it comes to DML).
  - jeffdavis 6y ago
    I'm sure there are some counterexamples, but for the most part most SQL implementations will fail to compile a query if you try to add a string to an integer or take the average of a date column. So I'm not quite sure what you mean. And type inference also plays a role with CASE statements, UNION, etc. Again may depend on SQL implementation.
    - dllthomas 6y ago
      Hmm, I'm not sure of the details, but I very much remember encountering type errors based on what data path was taken. Playing around now I think the typical case is more as you described. I might revisit when I'm better rested.
- justinmeiners 6y ago
  SQL works really well though. Lot's of people know it and can learn it. There are many implementations. There is a standard.
ashtonkem 6y ago
Marketing Haskell as an industry language is starting to feel a bit like a forlorn hope. After 30 years of getting passed by a variety of new languages that are supposedly inferior, hoping that Haskell will make industrial in-roads seems a bit silly to me. I mean, try if you want to. It's no skin off my back. But it doesn't seem like it'll work.
sjakobi 6y ago
Discussion on r/haskell: https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketing_haskell/ https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketin...

156 points by azhenley 6y ago

dmix 6y ago

One of the best ways to get adoption is to have people take initial risks and build real world serious product with a serious team/company backing behind it. Erlang got a big boost when it came out WhatsApp scaled it up with a billion users, with tiny team and only a few servers. React/React Native got boosted by Instagram adopting it to build their production mobile app. Rails had 37signals/Basecamp and Github/Shopify/early Twitter/etc. Haskell needs some more famous commercial "killer-app" examples for real businesses and real teams. And yes I'm very familiar with the current selection of popular Haskell examples. Currently I only ever hear Haskell (and Ocaml for that matter) being used by engineers for backend engineery things (parsing programming languages, fighting spam, tooling) mostly for OSS tools. On a positive note, PureScript is trying to position itself as a practical Haskell and making a bit of success. One helpful reason is they have a nice app/company leading the way as a production app with Lumi [1], with their founder playing a key role on the language/ecosystem dev side as well: https://www.lumi.dev/blog/purescript-and-haskell-at-lumi https://www.lumi.dev/blog/purescript-and-haskell-at-lumi This is what Haskell needs more of - and critical a company promoting/blogging about their progress using Haskell as well as contributing back into the community. Another big one is simply a sort of 'starter kit' which guides you with best practices on how to architect a serious Haskell app (ie, using STM, free, etc). React has plenty of starter kits. For Rust CLI apps there is a great starter kit https://github.com/iqlusioninc/abscissa https://github.com/iqlusioninc/abscissa I'd love to see a similar starting point micro-framework for starting a new Haskell app that makes a bunch of importation decisions for you and guides the structure of the project.

narrationbox 6y ago
There is Hasura, they are probably the most famous commercial Haskell app right now (in terms of brand recognition). https://hasura.io https://hasura.io
- dmix 6y ago
  That fits into the tooling category but it is a serious company. I found one blog post mentioning Haskell but without much technical details: https://hasura.io/blog/from-zero-to-hipster-haskell-in-production-97ea99d90c3b/ https://hasura.io/blog/from-zero-to-hipster-haskell-in-produ... I hope they write more..
centimeter 6y ago
I’m aware of 3-5 large companies (the number depending on what you define as “large”) that are using Haskell for big, serious projects, but all but one of them is in the defense or banking industries. Companies in these industries are usually not interested in sharing their experiences or engineering techniques, so it feels very quiet compared to when some hip startup starts (loudly) marketing some technology they’re using.
chrischen 6y ago
Ocaml (via ReasonML syntax) accounts for over 50% of Messenger.com. frontend code. https://reasonml.github.io/blog/2017/09/08/messenger-50-reason.html https://reasonml.github.io/blog/2017/09/08/messenger-50-reas... I’ve personally found starting adoption by converting pure domain code first to be the best approach, since it does not have to interact with legacy code.
tayo42 6y ago
a tagent, is erlang and maybe elixir worth spending time learning if Ive spent time writing haskell and scala?
- dmix 6y ago
  Yes, I loved learning Erlang (and later Elixir was a breeze). It's a good experience in learning how to build apps using the Actor model (they predated it before it was called Actors) and building resilient, multi-process based systems where failure is part of the design and fully accounted for. It also has a really small and simple syntax and wonderful pattern matching heavy approach to code, which is something I've took with me to other languages (and a feature sorely missing in most major languages). OTP is a bit of a beast and feels overwhelming at first, for example when you download an HTTP server to run your app you actually "run" the supervisor which spawns a bunch of processes. And this is all within your own application which is a group of isolated processes. I'd personally use Erlang/Elixir for everything if it had strong typing. And I still might anyway for my next project.
sigrlami 6y ago
There are more than 200 companies using Haskell in a different levels, check out https://haskellcosm.com https://haskellcosm.com

centimeter 6y ago

With respect to availability of talent pool: my alma mater used to teach Haskell as the introductory programming language, and from what I’ve heard from people who were around then it was great for faculty and students. However, a very large corporate donor pressured the university to switch to Java in the early 2000s, because that’s what they used internally and they wanted a large local supply of pre-trained fungible labor. Now only a small fraction of the top students who study advanced topics in PL or compilers or what-have-you will come out of the university knowing how to use Haskell. I think this is deeply unfortunate - if society could quantum tunnel through to the point where Haskell was the safe, readily hireable corporate choice, the state of software (especially corporate software) would be a lot better off.

gowld 6y ago
I don’t get it. What does removing Haskell from the into course have to do with the use of Haskell in the PL or compilers class?
- centimeter 6y ago
  Most CS students don’t take those classes. They’ll take data structures, algorithms, game design, databases, etc. which are mostly in Java or C++.
  - zabzonk 6y ago
    Most CS students certainly do take compiler classes, at least for any decent CS course.
- mumblemumble 6y ago
  If it's anything like what happened at my alma mater, they may well have switched to Java for everything. It's really a disservice to students. Developing competence in a variety of programming paradigms is a career-expanding experience. It makes picking up a new language - and, by extension, a new technology stack - a quick and easy thing to do, because there will be very few ways of doing things that you haven't seen before. Which, in turn, makes it a lot more feasible to pivot your career or act quickly when an opportunity arrives. A bunch of students who know only Java, on the other hand, is exactly what big corporate employers want. For employers, it maximizes the interchangeability of employees. For employees, it minimizes the interchangeability of employers.

xixixao 6y ago

Javascript is not popular because it has Java in the name name...

AnimalMuppet 6y ago
But it was a big initial boost for it. "ECMAScript" didn't have the same marketability, and Java was being publicized and becoming popular, so they renamed it to JavaScript.
- logicprog 6y ago
  I still maintain that ECMA sounds like an unpleasant skin disease. Not good marketing, that!
- skybrian 6y ago
  That's wrong on the history. Netscape called the language "LiveScript" before changing it to "JavaScript". Then Microsoft called it "JScript." Then the "ECMAScript" name was chosen as a compromise. Using different names for the same language didn't change anything fundamental. It was built into the browser, so if you wanted to write code in the browser you didn't have a choice.
- deleted 6y ago
  [deleted]
zabzonk 6y ago
Unless I have missed something, it is immensely popular.
- tome 6y ago
  xixixao is making a statement about the reason for Javascript's popularity, not about its popularity itself.
ipnon 6y ago
It would be unreasonable to attribute none of JavaScript's popularity to its name. https://stackoverflow.com/questions/2018731/why-is-javascript-called-javascript-since-it-has-nothing-to-do-with-java https://stackoverflow.com/questions/2018731/why-is-javascrip... Even JavaScript's first name Mocha is a reference to chocolate coffee and the Java language.

kace91 6y ago

Although I think the post is very clear describing the reasons why Haskell isn't attractive in business, this part rubbed me the wrong way: > Thus, instead of our discourse being about semantics, engineering quality, and implementation, we instead discuss our tools in terms of social factors and emotions (i.e. it “feels readable”, “feels usable”, “feels fast”). Thinking about readability or usability as emotions and social factors, rather than as first level concerns, is a non starter to me, and I find it extremely off putting that the author seems to pile up those qualities in the marketing "group", as if they were not real properties of a language. You can design a drill in a way that makes it the most scientifically correct at using the power it's supplied efficiently, but if the design hurts the users hands and requires months of training to operate, any worker will throw it in the trash, because they can drill things just fine with a regular tool. (I'm not necessarily saying that Haskell is that drill, just saying that usability should never be treated with condescension when you're designing tools).

awinter-py 6y ago
haskell isn't a drill it's a root canal
- smitty1e 6y ago
  Well, if the dental work needs a conceptual makeover, then see a dentist. I'd contend that the immutability of containers and why Docker is such a win might be getting Haskell to its moment. For me, the hardest unlearning piece isn't the syntax. Rather, the impact of the purity on the execution model is the stumbling block. Monads seem arcane because laziness + purity = statelessness, which never really had tangible meaning until the idea that a Docker image is also stateless came along. Maybe some cruder, crayon-level examples can be devised to help us slow folk get there.
  - awinter-py 6y ago
    docker is a win on desktop because I can run two database instances at once on my laptop + understand what's happening + a win for cloud when combined with kube to understand exactly what's being exposed haskell isn't simple or understandable it's flexible but I have no idea what's happening where effects are getting folded in from all over the codebase all the type abstractions are for injecting code from somewhere else

weinzierl 6y ago

The author of the article has an interesting contact page: "To contact me via email run one of the following scripts to generate my contact information. I find this is an effective filter against the deluge of emails from recruiters." The "scripts" are offered in Haskell, x86-64 Assembly and Python. Solution is pretty obvious though, no need to run them actually.

Tade0 6y ago
Recruiters who do contact me will be named and shamed publicly. I would applaud any recruiter who went through all that trouble just to contact a person, regardless of my interest in their offer.

pron 6y ago

Ask any marketer — it's (almost) never the marketing. Or, rather, it's never the marketing of the "hype and subterfuge" kind. No product dominates the market for decades due to hype and subterfuge, let alone hype and subterfuge deployed decades earlier. It's always the product. It's just that what matters about the product to most people is often not what matters to some minority that insists that “technical excellence” is defined by their own preferences. In the famous VHS vs. Betamax war, the technically superior product won, it’s just that it was superior in matters that appealed to many and inferior in matters that appealed to few. The few famous cases where it was the marketing (diamond rings, maybe?) stick in our mind because they're the exception, not the rule. Blaming marketing problems is often an excuse to overlook product problems. Second, the problem with the message of "code written in Haskell is more correct than code written in other [more popular] languages," isn't that the industry doesn't care about correctness. Correctness translates to cost (to a degree), and the ability to write software as correct as it needs to be more cheaply is actually quite compelling. Rather, the problem with it is that it's simply not true (or, rather, hasn't been shown to be true), certainly not to any degree big enough to matter. That, in and of itself, does not make it a terrible message; after all it's just harmless hype, right? What makes it a terrible message is that it is very clearly not (shown to be) true and yet some Haskellers seem to actually believe it, drunk on their own kool-aid, which makes you think of them as out of touch with reality. At best, it's an emotion (it "feels" more correct), which you've mocked, rather than any sort of "critical thinking," that you present as the desirable standard. Third, the mistake in the perception of the economics of software is not the importance of correctness — that can have an easily measurable impact. It's in the importance of code. Programmers in general, but Haskellers in particular, are obsessed with code. As a result, they grossly overestimate its importance to software. Ask yourself how long it takes you to produce, say, 1000 lines of code of sufficient quality, and then look at a software produced at your company and divide the size of the codebase by the number you came up with. You'll find that the true cost is several times that. The "pure" cost of producing code is not where most of the cost of developing software is. Maybe it's in what you mockingly call "emotions", but it certainly isn't in programming-language semantics. Also, before presenting managers' priorities, it's better to actually speak to actual managers; they just might have some useful insight here, plus, it's what a culture of technical excellence demands, no? All of that means that unless your language has some clear and direct effect on the bottom line — which, these days, usually means it has good performance and/or observability, a good ecosystem, or a monopoly of sorts on some distribution platform -- there is no "message" that can make it popular, other than "it's easy and it's fun." While perhaps not a sufficient requirement for success, this can create a supply of qualified developers that at least won't put your language at a disadvantage. And here's another tip: if your retrospective introspection isn't painful, doesn't discuss any serious and conspicuous flaws with the product, and still paints you as being somehow right after all and everyone else as being somehow wrong — it's probably not true. Worse, it seems untrue. And not calling your own practice one of "engineering excellence" and others' as "throwing enough bodies" can't hurt, either. In other words, I don't know what a good marketing message for Haskell would be, but this post is a good example of a bad one.

wirrbel 6y ago

I am the person that would be the one most likely to adopt haskell in the company I work in. Now, I don't and I won't even though I used it for several pet projects and I would say have learned a lot of haskell and associated patterns. It's not that haskell doesn't have merits. However I feel like they are oversold. While you can build programs that lack certain error classes, they are not bug free and at the same time debugging often was a lot harder than in other languages. The laziness is especially problematic in that regard. Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. Another important problem is the docs. For some reasons they hardly contain examples. You don't get adoption that way. Even if the maintainers feel that the type signatures are documentation enough. And as a last remark, the combinatoric complexity of compiler flags is a problem and needs to be fixed. But the ecosystem is in a deadlock there that no compromise could be found on what should be in the language and what shouldn't be. And it kind of indicates a deeper problem in the haskell design process.

lambdasquirrel 6y ago
> Another problem is cultural. Haskell and Scala community have been the most hostile communities I have experienced. And the friendliness of communities is a sure predictor for growth. To elaborate further, some of the most upsetting conversations I’ve had with Haskellers revolved around simple things like exceptions and logging. Issues would consistently turn into a matter of personal intelligence, and proving oneself correct. It is insane. We are just trying to build things here. These are very boring implementation issues that just need to get done.
- a1369209993 6y ago
  I admittedly don't engage with the Haskell community much myself, but I'd speculate that part of the problem is the fact that C++/Java/Python/etc-style exceptions (as opposed to things like Either Excep t or SomeMonadFail t) are very boring implementation issues that specifically need to not get done. I'd also speculate that whoever you talked to did a poor job of articulating that.
- 6y ago

moreaccountspls 6y ago

Anyone using Haskell to drive their business is making a huge mistake in my experience. Haskell2010 is a fine language. Unfortunately, the ecosystem has centered around whatever the latest version of GHC is, with its millions of language extensions and breaking the world with changes like https://gitlab.haskell.org/ghc/ghc/issues/10365 https://gitlab.haskell.org/ghc/ghc/issues/10365 and https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of.... Which is fine if you're doing research or building tools for fun! But it makes an absolutely awful industrial experience when you want to ship features and not get stuck on a bit rotted version of GHC. edit: It's unfortunate that people are downvoting me for offering my experience, especially on a post that wants to make Haskell more attractive to being used in the industry.

willtim 6y ago
You have a very valid point. As someone who uses Haskell professionally in a large organisation, I can honestly say that past changes such as FTP and AMP have added very little but caused significant issues for both academic and industrial users. GHC is no longer a Haskell 2010 compiler and unfortunately there seems little interest in the community for creating a new Haskell standard.
platz 6y ago
these issues probably did not cause a lot of problems for production software
- moreaccountspls 6y ago
  Huh? My whole comment is about the fact that they DID cause a lot of problems for production software. The company wrote their flagship product in Haskell, and there is a pretty large chance that that decision will doom them because of the choice to use Haskell. It's unfortunate because the product has a great market fit. If they had choose pretty much any other tech stack, they would be killing it.
  - deleted 6y ago

awinter-py 6y ago

tagged in on a client project written in haskell codebase organization was nonintuitive and I blame type-level programming compilation was so slow and bad that other programs on my laptop started to die the feature I was adding was something that would be library-provided in a normal web language none of the operators have names and are very hard to google; I had to search for things like 'haskell tilde asterisk arrow'. Impossible to know what's from libs vs core language. Lots of explanatory docs online were like 'oh we don't pronounce this one'. Core abstractions have no definition ('to explain that I would have to explain monads but you won't understand monads so GFY'). Monads are just sub rosa dependency injection . lang doesn't protect you from runtime crashes but does apparently protect you from knowing where the program crashed

fphilipe 6y ago
Haven’t written any serious Haskell, but doesn’t Hoogle work for searching infix operators? One thing I really like about Haskell is Hoogle. The ability to search by function signature is great. I often wish I could do that in other languages.
- awinter-py 6y ago
  searched `->` got (->-) :: Bind m => (a -> m b) -> (b -> m c) -> a -> m c semigroupoids Data.Functor.Bind
  - mrkeen 6y ago
    Fair enough. `->` is core syntax, not a library function. It means `->` if you're a Java guy or `=>` if you're a Scala guy. Just search for it the same as you'd search for it in Java or Scala.
    - awinter-py 6y ago
      I'm open to the argument that my imperative / scripting background in some way primes me to learn rails but makes it hard for me to navigate a haskell codebase, and that this is human difference rather than one language being inherently more navigable than the other

solatic 6y ago

> The bottom line is that rather than using more correct tools and engineering practices, it is simply far easier and more economical to hedge software risk with non-technical approaches. Moreover, if you throw enough bodies writing Java at a project for a long-enough period of time, it will produce a result or fail with a fairly predictable set of cashflows, which is itself a low quantifiable risk that’s very easy for a business to plan for. This is a very MBA-like lens through which to examine software development. It's not wrong, but it's also a recipe for mediocrity, which is a great way to damage your culture and sit around wondering why you can never get ahead of your competition. The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? The pessimists will point to Equifax et. al. and tell you that the market simply doesn't care, that businesses can go through downtime after leak after catastrophic failure and their stock will never take a hit. And there's some truth to that. The end consumer actually doesn't really care about the bad news. There's not much that any company in the business can do about that. But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. The value of correctness isn't in the two months after you begin, it's in the two months after your latest release five years from now. It requires vision, patience, already-available human capital, and leadership to realize the benefits. > If the talent pool is illiquid or geographically locked, that’s a non-starter. If there isn’t a large corporate vendor to go to to sign up for a support contract, then that’s a non-starter. If there isn’t a party to sue as an insurance policy against failure, then that’s a non-starter. If you give your talent the opportunity to work on a Haskell project and they're walking out the door when it's difficult to find Haskell work to begin with, then you, the manager, failed in deciding which talent to hire. If you're looking for a support contract to hedge against the loss of in-house talent, then you've already failed. If you think that legal solutions will protect you against market failure, then you've already failed. Haskell isn't trying to market to these people in the first place, why should it start?

dehora 6y ago
To the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being aware of, and even as a rhetorical device, overstating helps bring them into focus. > The deeper question is why is software quality only loosely correlated, if at all, with business outcomes? Because quality is on a spectrum and context specific: commercial domains need quality levels—you have to set magnitude or quantify in some way. The software profession such as it is, tends to come at this a binary matter (cite pretty much any debate about speed vs quality). That gets, I think, amplified in technical communities where correctness is deemed more important or simply more attainable in terms of claims. > But the optimist understands that great engineering will leapfrog competitors and leave them in the dust. I agree with the sentiment; I actually do think we're in a phase where engineering leverage is underestimated, but would qualify it and say this is different to correctness. What great engineering can do is offer a short term technical advantage (eg "secret sauce") and/or a sustainable one (eg "organisational speed"). It's not clear correctness provides that kind of benefit, unless we want to frame as increasing precision/accuracy/reproducibility of results.

tinco 6y ago

I made the decision to stop using Haskell for things I consider "professional" use a couple years ago. No matter how much I love the idea of the language, there's a couple superficial things it gets wrong and one fundamental thing, or at least I believe it's fundamental, perhaps some academics have proof one way or the other. The superficial things are things that are not really part of the language, but more of its standard library, part of the 'prelude', or things the community has agreed upon: - the I/O monad (and others) can throw errors - prelude is full of bad practice like use of strings and linked lists - there's something wrong with how function names can't be namespaced There's more than this, and they're not just things I came up with, they've been fought over in the community at length. Other preludes exist, I/O libraries that don't throw errors, even whole different systems for doing I/O exist. It's not that solutions are hard or impossible, they're there, it's just that the way the language is managed it's not likely that they'd ever be applied in a way the entire community, and especially those drawn to it by any marketing would experience them. Maybe I'm making a fool of myself and things changed in the past couple of years, things were really developing at a rapid pace when I left, but it seemed all the improvements happened around haskell, not to the language itself. When Stack and LTS-Haskell emerged it was the most amazing thing that I saw happening to Haskell in like 10 years, but given the lackluster response Snoyman received from the core team it seemed like they didn't even realize it even though the entire community had like an upheaval. In my opinion, Haskell's marketing is fine. It's being marketed to every college student anywhere that goes to a good enough university that it teaches functional programming. In addition to that there's raving fans (myself included) that extoll its virtues to anyone who would hear. What it needs is a better retention rate. It needs that people who learn it, immediately realise it's fit for production use, that it's not just a fun experiment and a educative way of looking at things. For that we need something like a Haskell 2.0, designed by the community to incorporate everything we learned about Haskell's flaws and make it an absolute powerhouse of productivity. Maybe Haskell should be split into two flavors, one the teaching language with the linked lists, strings and funny pattern matching, and one that's got a prelude that will set you up with the perfect base to build the next compiler, database, service or web application. If all those smart people who learn Haskell and tinker with for a bit, actually stayed around and used it to build awesome stuff, Haskell would truly have an enormous foot print on the world. (not really relevant but the fundamental thing is that Haskell's performance is really hard to predict, this is true for many garbage collected languages, but for Haskell it seems to be extra bad because of the way its paradigm just doesn't map 1:1 to how computers are built)

cs702 6y ago

The idea of "marketing Haskell" to me is akin to marketing math and mathematical notation. Yes, Haskell is elegant. Yes, it is powerful. Yes, it is succinct. Yes, the benefits of its algebraic type system are many and very real -- if your code compiles, it is correct in many important ways. No one can argue with any of that. But... most people who look into Haskell lose steam as soon as they realize they actually must understand and be able to reason about functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. It's a shame.

JadeNB 6y ago
> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful. Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it? Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.
- marcosdumay 6y ago
  Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.
  - JadeNB 6y ago
    > Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine. Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.

mhh__ 6y ago

This is a slightly loaded question, but is a Haskell codebase harder to work on than one in a reasonable non-functional language? Maybe it's because the bugs are generally less common and easier to fix, but when I look at Haskell codebases it seems like it's quite difficult to achieve the same level of "separation" one would in (say) Java - i.e. an average Haskell file seems to purely consist of many loose free functions (often with very short names!). I might be missing the point but the aforementioned always pushed me away from Haskell - great language, but seems to have legibility as an afterthought (as opposed to python, which is an awful language, does manage to enforce some sort of legible coding style)

chrischen 6y ago
I’d suspect the difficulty comes from the paradigm shift. I’ve personally switch code to functional style and it has simplified and reduced code for me. Granted if you don’t know how monads work it could be very confusing.
- mhh__ 6y ago
  I'm a bit rusty but I do understand the type and category theory behind Haskell. I don't find it confusing, just sort of suboptimal a la C++ template syntax
  - mrkeen 6y ago
    How could it be tweaked to make it better?
    - mhh__ 6y ago
      What D does. Angle brackets make instantiations harder to parse. Also the template keyword is pointless
  - chrischen 6y ago
    Ah yes if you have a language that isn’t conducive to it... luckily Typescript is multi-paradigm enough.

6gvONxR4sf7o 6y ago

I love haskell. What I love about it is the type system and pureness. In python, I loathe refactoring because of how fragile it often is. I hate finding out that I misunderstood what to even pass a function. I want the what haskell brings to those issues. I hate how hard haskell is to debug and how incredibly hard performance is to reason about. I want what python (or another imperative language) brings to those issues. I wonder if haskell had been strict by default rather than lazy by default, if its adoption would be different today. There are certainly pieces of haskell that would make all our lives easier, and I can't wait for them to make their way into mainstream industry work one way or another.

crazypython 6y ago
-XStrict?
- 6gvONxR4sf7o 6y ago
  It's easy to write strict code in haskell, but the default behavior affects community norms, and what's considered standard and idiomatic. That's where I think the evolution could have been different.
  - massysett 6y ago
    Haskell would never have been strict by default, because the entire point of Haskell was to be a common basis for research into non-strict languages. Non-strictness is simply the core of what Haskell is.

rockmeamedee 6y ago

This is a very lucid piece on PL adoption in general. When I think about programming languages, I do think rather emotionally (which is fine, emotions are early warning systems). I liked the linked author's points about the pre-requisites for marketing a solution: It is memorable It includes a key benefit It differentiates It imparts positivity When I think about the most popular languages, they do have all of these: Rust: Memorable: very. It's basically everywhere you look Has a key benefit: going C++ fast without the C++ footguns, memory-safe, WASM integration Differentiates: Using Rust is definitely choosing a particular set of technical tradeoffs Imparts positivity: the community is known to be welcoming, feels cool, cute crab. People re-write existing software in Rust just because it feels good! Yet Haskell has almost none of these: Memorable: I mean, yeah, but it's not being shown to people, and I can't point to a bunch of software. Tools I know of include PostgREST, Hasura, Nix, hledger, which is better than nothing. Key benefit: Hand waving about "being more correct", unlike Rust which has reams of "Microsoft claims 60% of its bugs are memory-errors" articles, and in any case TFA's point is that this needs to be a different message because correctness isn't gonna sell it. Differentiates: This is definitely true, almost too much Imparts positivity: Not really feeling this one with Haskell. People feel good when they figure out a monad is a container & a lens is a path through a data structure, but attempts to explain to others these things feel condescending. Does Haskell even have an animal mascot? (serious question.) Also "stumps" a lot of people and people feel bad about it. There's no "import antigravity" equivalent feeling with Haskell. This sounds pretty sombre for Haskell, though it's been an academic language a long time, and could probably stay alive that way. One positioning possibility is maybe with the Frontend dev world becoming more and more functional and pure-oriented, positioning itself like reasonML, as a way to write and reason about declarative pure UIs. But I don't think the existing Haskell community cares too much about that world. Idk, I'm going to just keep writing Rust and JS, the already most loved and popular languages.

spekcular 6y ago

We dance around this issue in the comments to every Haskell story, but the reason Haskell is hard to market is that it's bad. It's a research language being shoehorned into production by a few people who really love it. Some details of this have been given in this thread; let me suggest the following threads for more: 1) https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocamlers_critiques_of_haskell/cugohyn/ https://www.reddit.com/r/ocaml/comments/3ifwe9/what_are_ocam... 2) https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_ocaml/fa4bnsw/ https://www.reddit.com/r/ocaml/comments/e7g4nb/haskell_vs_oc... Yes, the Haskell community hates that guy and considers him a troll. But he does functional programming professionally as part of a private consultancy and wrote a book on OCaml. If anyone's equipped to understand what's wrong with Haskell, it's him. Haskell has had 30 years to get its act together. Any benefits it has are drowned out by a sea of buggy tooling and accidental complexity (monads, etc.). Ask yourself this: if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Time to move on.

todd8 6y ago
> if there are literally billions of dollars in industry riding on writing efficient and correct software, and Haskell is such an obvious productivity win, why does it have a market share that rounds to zero? Well, one reason we might get stuck on a “suboptimal” language is network effects outside of the criteria we use to compare languages: what language does an organization already have experience with, does the (only) current compiler support the target hardware and system, it’s to late now to write the Linux kernel in Haskell, etc. However, I agree with you. Despite the time I’ve invested in learning Haskell, I’ve personally decided to spend my time developing in other languages. If Haskell is the magic wand right there in front of us that will give us programs without flaws, how come almost nobody has picked it up and shown us working programs that took less development effort and fewer flaws. We could compare John Wiegley’s ledger (C++) to the similar hledger (Haskell), but hledger isn’t the same program as ledger it has different features, I have no idea how long it took to write, how many flaws it has versus the original, how different the developer skills were, how much time and defects were saved by it being a redesign, etc. And these are small single developer efforts (now with numerous contributors). From everything I can gather, they are both excellent. So in this case there is no compelling advantage demonstrated for Haskell, and this supports your point.

phreack 6y ago

What about tooling? Haskell being such a powerful language would take off a lot more if there was a very hand-holding, Jetbrains-like IDE that gave you everything you needed and pointed out the problems in your code in real time. Or at least that's what I think, having never worked with haskell in a professional capacity. What are some day to day devtool stacks like in real companies?

colehasson 6y ago
ghcide, took a couple days to setup but the effects are phenom https://www.youtube.com/watch?v=cijsaeWNf2E https://www.youtube.com/watch?v=cijsaeWNf2E
ghostwriter 6y ago
http://rikvdkleij.github.io/intellij-haskell/ http://rikvdkleij.github.io/intellij-haskell/ it's been around for a while already

jeffdavis 6y ago

"The hard economic truth for engineers is that technical excellence is overwhelmingly irrelevant" No. Technical excellence matters a lot when used appropriately, but competing with javascript and python is not where haskell is going to win. There IS a language with HUGE success that is: declarative, strongly typed with type inference, lazy, and no side effects. It's called SQL[1]. That's where Haskell could shine -- compared with SQL. Imagine Maybe rather than NULLs, a sane language, multiple returns, a much better type system, etc. Python and Java can't touch SQL, but haskell could. [1] http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-cousin-of-haskell/ http://thoughts.davisjeff.com/2011/09/25/sql-the-successful-...

dllthomas 6y ago
SQL does not have type inference. It's dynamically typed, and will break at runtime if you feed the wrong type into something. It probably is strongly typed, depending where you draw that line. It also sometimes has side effects, although that's more dialect specific than present in the standard I think (when it comes to DML).
- jeffdavis 6y ago
  I'm sure there are some counterexamples, but for the most part most SQL implementations will fail to compile a query if you try to add a string to an integer or take the average of a date column. So I'm not quite sure what you mean. And type inference also plays a role with CASE statements, UNION, etc. Again may depend on SQL implementation.
  - dllthomas 6y ago
    Hmm, I'm not sure of the details, but I very much remember encountering type errors based on what data path was taken. Playing around now I think the typical case is more as you described. I might revisit when I'm better rested.
justinmeiners 6y ago
SQL works really well though. Lot's of people know it and can learn it. There are many implementations. There is a standard.

ashtonkem 6y ago

Marketing Haskell as an industry language is starting to feel a bit like a forlorn hope. After 30 years of getting passed by a variety of new languages that are supposedly inferior, hoping that Haskell will make industrial in-roads seems a bit silly to me. I mean, try if you want to. It's no skin off my back. But it doesn't seem like it'll work.

sjakobi 6y ago

Discussion on r/haskell: https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketing_haskell/ https://www.reddit.com/r/haskell/comments/gtm3w0/on_marketin...