12 ms·

Friend of mine is always trying to convert me. Asked me to read this yesterday evening. This is my take on the article: Most of my daily job goes into gluing s

Friend of mine is always trying to convert me. Asked me to read this yesterday evening. This is my take on the article: Most of my daily job goes into gluing services (API endpoints to databases or other services, some business logic in the middle). I don't need to see yet another exposition of how to do algorithmic tasks. Haven't seen one of those since doing my BSc. Show me the tools available to write a daemon, an http server, API endpoints, ORM-type things and you will have provided me with tools to tackle what I do. I'll never write a binary tree or search or a linked list at work. If you want to convince me, show me what I need to know to do what I do.

eterps 7y ago
This a 100%. If Haskell proponents focused more on stuff that is described in https://pragprog.com/book/swdddf/domain-modeling-made-functional https://pragprog.com/book/swdddf/domain-modeling-made-functi... instead of algorithms a lot more devs could use it in their day-to-day job.
- yakshaving_jgt 7y ago
  It's all there to be used, it's just unfortunately Haskell proponents seem not to talk about it as much. Most of the discussion is around "interesting" stuff. My company does everything in Haskell, but it's almost all just boring plumbing code. APIs, JSON, databases, HTTP stuff, HTML templating, etc. It works great.
  - Beltiras 7y ago
    Can you share any of your toolchain and stack?
    - yakshaving_jgt 7y ago
      Sure. Here you go. https://news.ycombinator.com/item?id=21024494 https://news.ycombinator.com/item?id=21024494 As for libraries we use heavily (in no particular order): Yesod, Persistent, Esqueleto, Lens, Lens-Aeson, Hedis, STM, Wreq, Shakespeare, Hspec.
  - bojo 7y ago
    Exactly this. I've been meaning to write a blog post about what my team does with Haskell for the last 3 years, and while I think there are some gems of information we could provide to the world, at the end of the day it's incredibly boring stuff that works well for us and isn't really worth mentioning because it's not that different from what everyone else is doing with their own favorite language and tooling.
atroche 7y ago
Came here to say exactly this. And also to point to this excellent article: https://pchiusano.github.io/2017-01-20/why-not-haskell.html https://pchiusano.github.io/2017-01-20/why-not-haskell.html
- cousin_it 7y ago
  Joel Spolsky called it two decades ago: https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on-programming/ https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on... Until you’ve done Windows programming for a while, you may think that Win32 is just a library, like any other library, you’ll read the book and learn it and call it when you need to. You might think that basic programming, say, your expert C++ skills, are the 90% and all the APIs are the 10% fluff you can catch up on in a few weeks. To these people I humbly suggest: times have changed. The ratio has reversed. Read the whole article, it's pretty amazing. Parts of it are just as relevant to mobile development today as to desktop development back then.
tiew9Vii 7y ago
They do exist. I use http://hackage.haskell.org/package/optparse-applicative http://hackage.haskell.org/package/optparse-applicative for small cli apps http://hackage.haskell.org/package/envparse http://hackage.haskell.org/package/envparse For any Docker microservice http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-Aeson.html http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A... For all JSON work. Sometimes I’ll use it with lenses which is massively powerful but a rabbit hole I’ll use http://hackage.haskell.org/package/stm http://hackage.haskell.org/package/stm when dealing with parallel execution https://github.com/brendanhay/amazonka https://github.com/brendanhay/amazonka For anything dealing with AWS https://github.com/haskell-works?tab=repositories https://github.com/haskell-works?tab=repositories Projects for Kafka and avro http://hackage.haskell.org/package/warp http://hackage.haskell.org/package/warp For trivial micro services or Scotty if more than a few endpoints http://hackage.haskell.org/package/persistent http://hackage.haskell.org/package/persistent For dealing with Postgres http://hackage.haskell.org/package/parsec http://hackage.haskell.org/package/parsec For dealing with any text parsing. The tools are available, they can make things like cli apps and micro services trivial. However if you have never used a ML language before you will have a steep learning curve as very different to C style/based languages. I was once of the opinion Haskell is academic, what can you use it for in the real world. Then I studied with it, played with it admittedly on and off over 1-2 years, hit hurdles where I had to think as so different to what I’ve learnt before. Eventually it clicked, it’s very hard and frustrating now in my day job using typical enterprise or popular languages. It’s not about convincing, it’s about having a open mind and wanting to learn something different
- Beltiras 7y ago
  Those look really promising. My boss is big on TDD and open to developing cutting edge technologies. I'm going to have a look and see if I can propose a project using these tools.
  - polymatter 7y ago
    In case you're serious https://tech.fpcomplete.com/haskell/promote https://tech.fpcomplete.com/haskell/promote may help.
bjz_ 7y ago
You might be interested in checking out https://typeclasses.com/ https://typeclasses.com/. You have to subscribe, but they have some free content, including this nice section: https://typeclasses.com/phrasebook https://typeclasses.com/phrasebook, which gets right into printing to the console, and working with state, multi-threading and mutation.
amelius 7y ago
It's the other way around. Haskell is good at plumbing, while real algorithms are better done in a fast low-level language.
- gowld 7y ago
  Haskell is good at plumbing in research programs, not in production systems that require monad transformers or extensible effects.
  - johnday 7y ago
    No system requires monad transformers or extensible effects. In some cases they become useful, particularly when dealing with unusual computational contexts; but most of the time you can use IO, and sacrifice the sharpest edge of type-safety for an easier job of plumbing.
    - UK-Al05 7y ago
      In the real world, you end up with logging, ways of progating errors, etc All of which tend to introduce monads. When you have multiple moands on the go you need some combining them.
      - johnday 7y ago
        Yes, but as I was saying logging, errors and so on can all be handled directly inside of IO. Given that you can't do any of these things in a pure function anyway, the only loss of dropping into the wider context of IO is type safety.
phonebucket 7y ago
I'm relatively new to Haskell, but Yesod has a good reputation for web application logic, and moreover comes with a free book introducing both itself and Haskell: https://www.yesodweb.com/ https://www.yesodweb.com/
mumblemumble 7y ago
So, I love me some ML-style languages, including Haskell, but I've also come to think that Rich Hickey is right about the real problems of business programming not being well solved by digging in on things like static typing. For example, pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler. One makes the code a bit more concise and readable, but not necessarily a whole lot more maintainable. The other takes one of the more annoying and error-prone portions of my (say) Java code and renders it far more manageable. There's a recent LispCast that talks about this a bit: https://lispcast.com/what-is-data-orientation/ https://lispcast.com/what-is-data-orientation/
- chrisseaton 7y ago
  What's the difference between 'business programming' and other types of programming? I don't really know what distinction people are trying to make here.
  - deleted 7y ago
    [deleted]
  - fulafel 7y ago
    Dealing with the messy real world with exceptions to rules and evolving shape of data vs writing compilers and other internally consistent closed systems.
    - platz 7y ago
      If you have messy/dirty data then you just use an associative data structure like a Map in Haskell, just like any other language.
      - fulafel 7y ago
        Sure, but idea is that the idiomatic way of working in the language accomodates passing around data that is not necessarily closed in shape. Ie intermediate functions will by default pass along also attributes that they don't have knowledge of, for example. And checking data shape conformance is customizable (by the "spec" system).
ken 7y ago
When I first studied compilers, I was amazed that writing a compiler used every other subfield of computer science I'd studied. It's the acid test of language design. A language that can easily be used to write compilers can do almost anything well. And every non-trivial program I've worked on is 90% of a compiler. (You could describe compilers as just "some business logic in the middle", too, if you were in Architecture Astronaut mode.) You don't think HTTP servers use "pattern matching"? You don't think API endpoints would benefit from "ridiculously easy" testing? This is your bread and butter. This article is showing how to implement if-statements and null-checks in Haskell, and reduce your code size by half. I bet you have some of those in your software. I'm not sure how this could be much more relevant, without reducing its usefulness by being overly specific.
- gowld 7y ago
  You are conflating computer science (complete writing) with software application development. In the real world, software has a CS "core", plus 95% boring data copying and gluing APIs together, where availability of libs and tools is far more important than theoretical correctness properties and the most general abstraction possible. This is why Haskell looks so nice in blog posts but terrible in a production system. In Haskell, updating fields in a records is still an active area research.
  - johnday 7y ago
    > In Haskell, updating fields in a records is still an active area research. In Haskell, everything is still an active area of research. Mutable data already exists in Haskell and has sensible semantics. But the goal of Haskell (so far as I can see, at least) is good, reliable, maintainable code which produces good, reliable, maintainable programs. If this is not what you look for in a programming language then it might not be for you.
  - agentultra 7y ago
    I wrote a library for that. Hooray you can version your types and seamlessly upgrade them and the compiler will never let you cross streams by accident. https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...
leshow 7y ago
Sum types infinitely useful in regular, non-algorithmic code you find every day. Look at something like redux and redux actions, those are essentially sum types and would benefit greatly from a pattern matching syntax. The benefits for this stuff is literally anywhere.
BoiledCabbage 7y ago
My best advice is do not try to learn functional programming via Haskell. It has done more to turn people off of functional programming that just about anything. If you want to learn statically typed functional programming learn Elm (which takes only a few days), then one of F# or OCaml. If you want to learn dynamically typed Functional Programming, learn Clojure or Racket/Scheme. They amount of investment it takes to see return on learning Haskell makes it terrible for an introductory language. And every proponent of it glosses over this part. It has some advanced concepts but its not an introductory language. There is so much benefit you can get to your coding from learning FP that you should pick a language that allows you to see and judge that value prop on your own quickly, not have to invest so much time to be haskell proficient to try to get the return on your learning.
- claudiawerner 7y ago
  I found Elm's type system to be extremely cumbersome in comparison to Haskell's.
  - sullyj3 7y ago
    That's because you already knew haskell and knew what you were missing out on. Elm having a less expressive type system makes it a much better introduction to concepts like ADTs and pattern matching, higher order functions, and enforced immutability, because there's less to trip you up.
- jcora 7y ago
  Or go all in and actually expose yourself to an entirely different programming paradigm, there is so much more to "FP" that you can only find in Haskell and beyond.
- taneq 7y ago
  > It has done more to turn people off of functional programming that just about anything. The only thing worse in my book is FP evangelists. FP has some cool ideas and is an interestingly different way to do things compared with imperative programming, but enough exposure to the “FP is obviously the best paradigm and anybody who isn’t a fanatic is clearly just unenlightened” crowd will sour anybody on it.
kerkeslager 7y ago
What I'm about to say is a criticism of you, but please don't take it personally. It's also a criticism of me, because my day job is essentially the same as yours. In general terms, almost everything you and I do is either a CRUD app, or something overcomplicated which would be better-implemented as a CRUD app. There's not technological advancement happening here. And usually you're not even doing a new CRUD app, you're just reimplementing an earlier CRUD app with better CSS and JS and a different marketing team to tout it. IF there's an innovation in your company it's not the CRUD app developer who's innovating. We're just reimplementing the wheel over and over, because the other wheel implementations are closed source and owned by a competitor. If you want to innovate, you have to take on harder problems that aren't CRUD apps. That's where languages like Haskell shine. Haskell doesn't shine because it's better, it shines because it's different, and suited for different tasks. The tasks for which Haskell is suited haven't been saturated yet, so there's still room for innovating on the technical side of things. So yeah, I can't show you how to do what you do with Haskell--the reason you'd want to use Haskell in the first place is to do something different from what you (and most other developers, myself included) are doing. The reason you'd want to write Haskell is to solve technical problems which haven't already been solved. You're right to bring up binary search trees and linked lists as criticisms of the Haskell community, because those are also pretty solved areas: touting binary search and linked lists as the powers of Haskell completely undersells Haskell. Haskell learning materials fall into two basic categories: complete beginner stuff, and Ph.D. theses written in an alien language. This is, unfortunately, part of why there's any innovation to be had here: having very little mid-level learning material creates a barrier for entry that keeps people from reaching a level where they could innovate. The same is true for the communities of many less-widely-used languages. This has been a rather cynical post, I realize. I'm not sure there's any recommendations here: I'm certainly not going all-in on learning Haskell and using it to innovate, myself. CRUD apps pay the bills and innovation is risky. I find interest and novelty in other areas of my life.
oisdk 7y ago
I wasn't really trying to convince anyone to use Haskell at their day job: I am just a college student, after all, so I would have no idea what I was talking about! I wrote the article a while ago after being frustrated using a bunch of Go and Python at an internship. Often I really wanted simple algebraic data types and pattern-matching, but when I looked up why Go didn't have them I saw a lot of justifications that amounted to "functional features are too complex and we're making a simple language. Haskell is notoriously complex". In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. So I wanted to write an article demonstrating that, while Haskell has a lot of out-there stuff in it, there's a bunch of simple ideas which really shouldn't be missing from any modern general-purpose language. As to why I used a binary tree as the example, I thought it was pretty self-contained, and I find skew heaps quite interesting.
- reificator 7y ago
  > > functional features are too complex and we're making a simple language. Haskell is notoriously complex This is a true statement. (Opinion yada objective yada experience yada) > In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. This is also a true statement. (yada yada) The insight I think you're missing is this piece right here: `we're making a simple language`. Their goal is not necessarily to make simple application code. That's your job, and you start that process by selecting your tools. For certain tasks, pattern matching is a godsend. I'm usually very happy to have it available to me when it is. And I do often curse not having it available in other languages to be honest. But Go users typically have different criteria for what makes simple/reliable/maintainable/debugable/"good" code than Haskell users have. Which is why the two languages are selected by different groups of people handling different tasks. You're making a tradeoff between features and limitations of various languages. And the language designers have an even different criteria for those things. In this case, adding pattern matching would absolutely make the language itself more complex, and they apparently don't believe that language complexity is worth the benefits of pattern matching. I think that's a perfectly reasonable stance to take.
  - 7y ago
zelly 7y ago
I learned Haskell and it's a giant waste of time. I'm not the only one who regrets functional programming either. Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter. It's the string theory of computer science. If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).
- rifung 7y ago
  > Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter Hm interestingly I actually felt like learning Haskell had a huge benefit to my day job, probably much more than I imagine learning x86 assembly would. (Though admittedly I have learned some assembly in the past and that was also helpful). I feel like Haskell forced me to write better code by forcing me to think about side effects. I don't know that I would actually use it in a production project because unfortunately real projects often rely a lot on state, even if constrained to a subsystem, and I still find it difficult to reason about the performance of a Haskell program. Not trying to invalidate your point; perhaps you were already very good at what I learned via Haskell =] I admit I also find Haskell much more enjoyable to program in for the most part.
  - behnamoh 7y ago
    > I feel like Haskell forced me to write better code by forcing me to think about side effects. I see, but wouldn't that be possible by "forcing" yourself to think about side effects in the language you were already using? I mean, at the end of the day, it's learning the functional programming concepts that is supposedly going to make you a better programmer. Why not just start learning those in Java, Python, JS, etc.? One thing I hear a lot from people who've learnt Haskell is they admit they're probably never going to use it in a real-world project (for so many reasons). Then, isn't it inefficient and a waste of time to learn parts of Haskell that are only found in Haskell?! If I were to learn FP (which I will soon), I'd choose to learn it in the language I'm using now. It's not only more efficient, but also I'd enjoy being able to put what I've learnt in practical use.
patientplatypus 7y ago
THANK YOU
_bxg1 7y ago
I've been curious: what does it take to find a job in software that isn't just gluing things together? Where do you have to go to write interesting algorithms at work? In our golden age of open-source, does that stuff only ever happen at FAANG and research labs?
- deleted 7y ago
  [deleted]
- ci5er 7y ago
  Everywhere! 3rd gen factory robotics, and manipulator control. Movie cg renderers and asset transformation pipelines (heck, get busy and finish inkscape!) Ehr systems. ERP systems. Risk management systems. Decision support systems. Trading systems. Field service support systems. Scheduling, packing, routing systems. Now everything has an ui, and data innies and outies, but gosh! That's just connectors to the diamond!
- oppositelock 7y ago
  Those jobs exist, but are few and far between, since cool ideas tend to be packaged up into reusable libraries, and don't need to be redeveloped, while everyone else uses these reusable libraries differently, so you have a constant need for "sanitation engineers". Tensorflow or OpenCV or UnrealEngine get written once, then everyone uses them to build whatever they're building. You write some cool glue around these, that's the interesting code, then spend most of your time wiring everything together into a larger package that actually does something useful. Once you've wired everything together, now you need to track version, build artifacts, manage release processes, test them and qualify them, etc, so you do a lot of QA and DevOps work. QA, DevOps and sanitation engineering is so product specific that it can't be packaged up, it's a craftsmanship position, and that's why all of us spend most of our time doing this kind of work.
  - _bxg1 7y ago
    Yeah, that's what I figured. It's a bit depressing when you think about it. I guess for most of us that itch just has to be scratched by pleasure-programming.
mbo 7y ago
So, I've been a Scala programmer for the last 3 years, and have been effectively writing Haskell in Scala reasonably effectively. The pure FP Scala community understands your complaints more than the Haskell community. https://typelevel.org/ https://typelevel.org/ is chock full of a) useful utilities for actually writing applications b) decent documentation. Not just pages of type signatures, but demonstrations of the libs usage. Everything you need is here: JSON, config, units of measure, streams, testing, validation, a really nice JDBC wrapper (https://tpolecat.github.io/doobie/ https://tpolecat.github.io/doobie/) Throw in https://http4s.org/ https://http4s.org/ and you've got yourself a rock-solid, purely functional stack with sensible, documented APIs, a more readable syntax and better tooling support. I urge anyone who learnt some Haskell, thought "man this shit sucks, I'm never going to write something useful in this" to at least give FP Scala a chance. Here's a useful service template to start hacking with: https://github.com/http4s/http4s.g8 https://github.com/http4s/http4s.g8.
- AdieuToLogic 7y ago
  Another great resource for doing FP in Scala is "Functional Programming in Scala"[0]. It's a very well written book and goes far in introducing key FP concepts IMHO. 0 - https://www.manning.com/books/functional-programming-in-scala https://www.manning.com/books/functional-programming-in-scal...
- dwohnitmok 7y ago
  I feel conflicted about this having programmed in both OO-heavy and pure FP Scala. On the one hand, sure if you want to write pure FP in Scala, some of the tooling is better than Haskell. Most notably the IDE situation with IntelliJ's Scala plugin has made leaps and bounds in progress the last few years and mostly handles pure FP Scala code just fine. And having access to the JVM ecosystem is an absolute god-send and huge boost to productivity. This is true even outside of library dependencies when coding. If you try deploying to production with Haskell, there's often a large gap in production tooling (monitoring, diagnostics, GC tuning, etc.) when compared to the JVM. On the other hand Scala has its own share of infelicities when it comes to pure FP. I've mentioned this elsewhere, but the core language of Scala, that is the language that is left after you desugar everything, is OO and the FP part is really just a lot of syntax sugar mixed in with standard library data structure choices. That means if you're coming from a pure FP background a lot of things will seem like hacks (methods vs functions/automatic-eta-expansion, comparatively weak type inference, the final yield of a for-comprehension, subtyping to influence prioritization of implicits for typeclasses, monomorphic-only values vs. polymorphic classes, etc.). Treating Scala as an OO language side steps a lot of these warts. And then there's the social factors; the Scala community is split on how much it embraces pure FP and pure FP is a (significant) minority within the community. This carries over to the library ecosystem where things are basically split into Typelevel/Typelevel-using and non-Typelevel libraries. Many workplaces have a fear (well-placed and not so well-placed) of the Typelevel ecosystem. Years ago Scalaz was something akin to the bogeyman in some places. Cats has a bit of a softer image, but still comes off as an "advanced" library in the Scala ecosystem. Most of the social weight I feel is behind the non-pure-FP parts of Scala. Sure some of the libraries in pure FP Scala have good documentation (but I don't actually think the situation here is far better than Haskell's once you leave the core Typelevel libraries). The ones with excellent documentation though live outside the land of pure FP (Akka, Play, Spark, Slick, etc.).
thrower123 7y ago
Yeah, this more or less completely misses the point of what a working programmer would need to be doing. I honestly can't remember the last time I had to implement a data structure for real, and not just for the hell of it because I was bored. The closest I come is generally some sort of domain-specific shell that composites some data together. I feel like the F# community tends to be more grounded in reality. Or at least I'm more exposed to the side of it that is trying to popularize it in Microsoft, as a useful tool for Domain Driven Design and the like.

eterps 7y ago

This a 100%. If Haskell proponents focused more on stuff that is described in https://pragprog.com/book/swdddf/domain-modeling-made-functional https://pragprog.com/book/swdddf/domain-modeling-made-functi... instead of algorithms a lot more devs could use it in their day-to-day job.

yakshaving_jgt 7y ago
It's all there to be used, it's just unfortunately Haskell proponents seem not to talk about it as much. Most of the discussion is around "interesting" stuff. My company does everything in Haskell, but it's almost all just boring plumbing code. APIs, JSON, databases, HTTP stuff, HTML templating, etc. It works great.
- Beltiras 7y ago
  Can you share any of your toolchain and stack?
  - yakshaving_jgt 7y ago
    Sure. Here you go. https://news.ycombinator.com/item?id=21024494 https://news.ycombinator.com/item?id=21024494 As for libraries we use heavily (in no particular order): Yesod, Persistent, Esqueleto, Lens, Lens-Aeson, Hedis, STM, Wreq, Shakespeare, Hspec.
- bojo 7y ago
  Exactly this. I've been meaning to write a blog post about what my team does with Haskell for the last 3 years, and while I think there are some gems of information we could provide to the world, at the end of the day it's incredibly boring stuff that works well for us and isn't really worth mentioning because it's not that different from what everyone else is doing with their own favorite language and tooling.

atroche 7y ago

Came here to say exactly this. And also to point to this excellent article: https://pchiusano.github.io/2017-01-20/why-not-haskell.html https://pchiusano.github.io/2017-01-20/why-not-haskell.html

cousin_it 7y ago
Joel Spolsky called it two decades ago: https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on-programming/ https://www.joelonsoftware.com/2002/12/11/lord-palmerston-on... Until you’ve done Windows programming for a while, you may think that Win32 is just a library, like any other library, you’ll read the book and learn it and call it when you need to. You might think that basic programming, say, your expert C++ skills, are the 90% and all the APIs are the 10% fluff you can catch up on in a few weeks. To these people I humbly suggest: times have changed. The ratio has reversed. Read the whole article, it's pretty amazing. Parts of it are just as relevant to mobile development today as to desktop development back then.

tiew9Vii 7y ago

They do exist. I use http://hackage.haskell.org/package/optparse-applicative http://hackage.haskell.org/package/optparse-applicative for small cli apps http://hackage.haskell.org/package/envparse http://hackage.haskell.org/package/envparse For any Docker microservice http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-Aeson.html http://hackage.haskell.org/package/aeson-1.4.5.0/docs/Data-A... For all JSON work. Sometimes I’ll use it with lenses which is massively powerful but a rabbit hole I’ll use http://hackage.haskell.org/package/stm http://hackage.haskell.org/package/stm when dealing with parallel execution https://github.com/brendanhay/amazonka https://github.com/brendanhay/amazonka For anything dealing with AWS https://github.com/haskell-works?tab=repositories https://github.com/haskell-works?tab=repositories Projects for Kafka and avro http://hackage.haskell.org/package/warp http://hackage.haskell.org/package/warp For trivial micro services or Scotty if more than a few endpoints http://hackage.haskell.org/package/persistent http://hackage.haskell.org/package/persistent For dealing with Postgres http://hackage.haskell.org/package/parsec http://hackage.haskell.org/package/parsec For dealing with any text parsing. The tools are available, they can make things like cli apps and micro services trivial. However if you have never used a ML language before you will have a steep learning curve as very different to C style/based languages. I was once of the opinion Haskell is academic, what can you use it for in the real world. Then I studied with it, played with it admittedly on and off over 1-2 years, hit hurdles where I had to think as so different to what I’ve learnt before. Eventually it clicked, it’s very hard and frustrating now in my day job using typical enterprise or popular languages. It’s not about convincing, it’s about having a open mind and wanting to learn something different

Beltiras 7y ago
Those look really promising. My boss is big on TDD and open to developing cutting edge technologies. I'm going to have a look and see if I can propose a project using these tools.
- polymatter 7y ago
  In case you're serious https://tech.fpcomplete.com/haskell/promote https://tech.fpcomplete.com/haskell/promote may help.

bjz_ 7y ago

You might be interested in checking out https://typeclasses.com/ https://typeclasses.com/. You have to subscribe, but they have some free content, including this nice section: https://typeclasses.com/phrasebook https://typeclasses.com/phrasebook, which gets right into printing to the console, and working with state, multi-threading and mutation.

amelius 7y ago

It's the other way around. Haskell is good at plumbing, while real algorithms are better done in a fast low-level language.

gowld 7y ago
Haskell is good at plumbing in research programs, not in production systems that require monad transformers or extensible effects.
- johnday 7y ago
  No system requires monad transformers or extensible effects. In some cases they become useful, particularly when dealing with unusual computational contexts; but most of the time you can use IO, and sacrifice the sharpest edge of type-safety for an easier job of plumbing.
  - UK-Al05 7y ago
    In the real world, you end up with logging, ways of progating errors, etc All of which tend to introduce monads. When you have multiple moands on the go you need some combining them.
    - johnday 7y ago
      Yes, but as I was saying logging, errors and so on can all be handled directly inside of IO. Given that you can't do any of these things in a pure function anyway, the only loss of dropping into the wider context of IO is type safety.

phonebucket 7y ago

I'm relatively new to Haskell, but Yesod has a good reputation for web application logic, and moreover comes with a free book introducing both itself and Haskell: https://www.yesodweb.com/ https://www.yesodweb.com/

mumblemumble 7y ago

So, I love me some ML-style languages, including Haskell, but I've also come to think that Rich Hickey is right about the real problems of business programming not being well solved by digging in on things like static typing. For example, pattern matching against static types is cool, but, compared to pattern matching directly against data, Clojure-style, is even cooler. One makes the code a bit more concise and readable, but not necessarily a whole lot more maintainable. The other takes one of the more annoying and error-prone portions of my (say) Java code and renders it far more manageable. There's a recent LispCast that talks about this a bit: https://lispcast.com/what-is-data-orientation/ https://lispcast.com/what-is-data-orientation/

chrisseaton 7y ago
What's the difference between 'business programming' and other types of programming? I don't really know what distinction people are trying to make here.
- deleted 7y ago
  [deleted]
- fulafel 7y ago
  Dealing with the messy real world with exceptions to rules and evolving shape of data vs writing compilers and other internally consistent closed systems.
  - platz 7y ago
    If you have messy/dirty data then you just use an associative data structure like a Map in Haskell, just like any other language.
    - fulafel 7y ago
      Sure, but idea is that the idiomatic way of working in the language accomodates passing around data that is not necessarily closed in shape. Ie intermediate functions will by default pass along also attributes that they don't have knowledge of, for example. And checking data shape conformance is customizable (by the "spec" system).

ken 7y ago

When I first studied compilers, I was amazed that writing a compiler used every other subfield of computer science I'd studied. It's the acid test of language design. A language that can easily be used to write compilers can do almost anything well. And every non-trivial program I've worked on is 90% of a compiler. (You could describe compilers as just "some business logic in the middle", too, if you were in Architecture Astronaut mode.) You don't think HTTP servers use "pattern matching"? You don't think API endpoints would benefit from "ridiculously easy" testing? This is your bread and butter. This article is showing how to implement if-statements and null-checks in Haskell, and reduce your code size by half. I bet you have some of those in your software. I'm not sure how this could be much more relevant, without reducing its usefulness by being overly specific.

gowld 7y ago
You are conflating computer science (complete writing) with software application development. In the real world, software has a CS "core", plus 95% boring data copying and gluing APIs together, where availability of libs and tools is far more important than theoretical correctness properties and the most general abstraction possible. This is why Haskell looks so nice in blog posts but terrible in a production system. In Haskell, updating fields in a records is still an active area research.
- johnday 7y ago
  > In Haskell, updating fields in a records is still an active area research. In Haskell, everything is still an active area of research. Mutable data already exists in Haskell and has sensible semantics. But the goal of Haskell (so far as I can see, at least) is good, reliable, maintainable code which produces good, reliable, maintainable programs. If this is not what you look for in a programming language then it might not be for you.
- agentultra 7y ago
  I wrote a library for that. Hooray you can version your types and seamlessly upgrade them and the compiler will never let you cross streams by accident. https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs/Data-Migration.html https://hackage.haskell.org/package/DataVersion-0.1.0.0/docs...

leshow 7y ago

Sum types infinitely useful in regular, non-algorithmic code you find every day. Look at something like redux and redux actions, those are essentially sum types and would benefit greatly from a pattern matching syntax. The benefits for this stuff is literally anywhere.

BoiledCabbage 7y ago

My best advice is do not try to learn functional programming via Haskell. It has done more to turn people off of functional programming that just about anything. If you want to learn statically typed functional programming learn Elm (which takes only a few days), then one of F# or OCaml. If you want to learn dynamically typed Functional Programming, learn Clojure or Racket/Scheme. They amount of investment it takes to see return on learning Haskell makes it terrible for an introductory language. And every proponent of it glosses over this part. It has some advanced concepts but its not an introductory language. There is so much benefit you can get to your coding from learning FP that you should pick a language that allows you to see and judge that value prop on your own quickly, not have to invest so much time to be haskell proficient to try to get the return on your learning.

claudiawerner 7y ago
I found Elm's type system to be extremely cumbersome in comparison to Haskell's.
- sullyj3 7y ago
  That's because you already knew haskell and knew what you were missing out on. Elm having a less expressive type system makes it a much better introduction to concepts like ADTs and pattern matching, higher order functions, and enforced immutability, because there's less to trip you up.
jcora 7y ago
Or go all in and actually expose yourself to an entirely different programming paradigm, there is so much more to "FP" that you can only find in Haskell and beyond.
taneq 7y ago
> It has done more to turn people off of functional programming that just about anything. The only thing worse in my book is FP evangelists. FP has some cool ideas and is an interestingly different way to do things compared with imperative programming, but enough exposure to the “FP is obviously the best paradigm and anybody who isn’t a fanatic is clearly just unenlightened” crowd will sour anybody on it.

kerkeslager 7y ago

What I'm about to say is a criticism of you, but please don't take it personally. It's also a criticism of me, because my day job is essentially the same as yours. In general terms, almost everything you and I do is either a CRUD app, or something overcomplicated which would be better-implemented as a CRUD app. There's not technological advancement happening here. And usually you're not even doing a new CRUD app, you're just reimplementing an earlier CRUD app with better CSS and JS and a different marketing team to tout it. IF there's an innovation in your company it's not the CRUD app developer who's innovating. We're just reimplementing the wheel over and over, because the other wheel implementations are closed source and owned by a competitor. If you want to innovate, you have to take on harder problems that aren't CRUD apps. That's where languages like Haskell shine. Haskell doesn't shine because it's better, it shines because it's different, and suited for different tasks. The tasks for which Haskell is suited haven't been saturated yet, so there's still room for innovating on the technical side of things. So yeah, I can't show you how to do what you do with Haskell--the reason you'd want to use Haskell in the first place is to do something different from what you (and most other developers, myself included) are doing. The reason you'd want to write Haskell is to solve technical problems which haven't already been solved. You're right to bring up binary search trees and linked lists as criticisms of the Haskell community, because those are also pretty solved areas: touting binary search and linked lists as the powers of Haskell completely undersells Haskell. Haskell learning materials fall into two basic categories: complete beginner stuff, and Ph.D. theses written in an alien language. This is, unfortunately, part of why there's any innovation to be had here: having very little mid-level learning material creates a barrier for entry that keeps people from reaching a level where they could innovate. The same is true for the communities of many less-widely-used languages. This has been a rather cynical post, I realize. I'm not sure there's any recommendations here: I'm certainly not going all-in on learning Haskell and using it to innovate, myself. CRUD apps pay the bills and innovation is risky. I find interest and novelty in other areas of my life.

oisdk 7y ago

I wasn't really trying to convince anyone to use Haskell at their day job: I am just a college student, after all, so I would have no idea what I was talking about! I wrote the article a while ago after being frustrated using a bunch of Go and Python at an internship. Often I really wanted simple algebraic data types and pattern-matching, but when I looked up why Go didn't have them I saw a lot of justifications that amounted to "functional features are too complex and we're making a simple language. Haskell is notoriously complex". In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. So I wanted to write an article demonstrating that, while Haskell has a lot of out-there stuff in it, there's a bunch of simple ideas which really shouldn't be missing from any modern general-purpose language. As to why I used a binary tree as the example, I thought it was pretty self-contained, and I find skew heaps quite interesting.

reificator 7y ago
> > functional features are too complex and we're making a simple language. Haskell is notoriously complex This is a true statement. (Opinion yada objective yada experience yada) > In my opinion, the `res, err := fun(); if err != nil` (for example) pattern was much more complex than the alternative with pattern-matching. This is also a true statement. (yada yada) The insight I think you're missing is this piece right here: `we're making a simple language`. Their goal is not necessarily to make simple application code. That's your job, and you start that process by selecting your tools. For certain tasks, pattern matching is a godsend. I'm usually very happy to have it available to me when it is. And I do often curse not having it available in other languages to be honest. But Go users typically have different criteria for what makes simple/reliable/maintainable/debugable/"good" code than Haskell users have. Which is why the two languages are selected by different groups of people handling different tasks. You're making a tradeoff between features and limitations of various languages. And the language designers have an even different criteria for those things. In this case, adding pattern matching would absolutely make the language itself more complex, and they apparently don't believe that language complexity is worth the benefits of pattern matching. I think that's a perfectly reasonable stance to take.
- 7y ago

zelly 7y ago

I learned Haskell and it's a giant waste of time. I'm not the only one who regrets functional programming either. Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter. It's the string theory of computer science. If you like math/category theory, go deep on the math itself. Your knowledge will be transferable to more than just some man-made story (like a programming language).

rifung 7y ago
> Since then I vowed never to take things seriously that have zero connection to real world results. It's not possible to regret mastering x86 assembly for example, because even if that skill is relatively useless, it makes you better at many tangential things which can be decidedly useful; C and OS programming for example. Functional programming doesn't have this potential because it (proudly) exists as an abstract model with no connection to the machine or any physical processes for that matter Hm interestingly I actually felt like learning Haskell had a huge benefit to my day job, probably much more than I imagine learning x86 assembly would. (Though admittedly I have learned some assembly in the past and that was also helpful). I feel like Haskell forced me to write better code by forcing me to think about side effects. I don't know that I would actually use it in a production project because unfortunately real projects often rely a lot on state, even if constrained to a subsystem, and I still find it difficult to reason about the performance of a Haskell program. Not trying to invalidate your point; perhaps you were already very good at what I learned via Haskell =] I admit I also find Haskell much more enjoyable to program in for the most part.
- behnamoh 7y ago
  > I feel like Haskell forced me to write better code by forcing me to think about side effects. I see, but wouldn't that be possible by "forcing" yourself to think about side effects in the language you were already using? I mean, at the end of the day, it's learning the functional programming concepts that is supposedly going to make you a better programmer. Why not just start learning those in Java, Python, JS, etc.? One thing I hear a lot from people who've learnt Haskell is they admit they're probably never going to use it in a real-world project (for so many reasons). Then, isn't it inefficient and a waste of time to learn parts of Haskell that are only found in Haskell?! If I were to learn FP (which I will soon), I'd choose to learn it in the language I'm using now. It's not only more efficient, but also I'd enjoy being able to put what I've learnt in practical use.

patientplatypus 7y ago

THANK YOU

_bxg1 7y ago

I've been curious: what does it take to find a job in software that isn't just gluing things together? Where do you have to go to write interesting algorithms at work? In our golden age of open-source, does that stuff only ever happen at FAANG and research labs?

deleted 7y ago
[deleted]
ci5er 7y ago
Everywhere! 3rd gen factory robotics, and manipulator control. Movie cg renderers and asset transformation pipelines (heck, get busy and finish inkscape!) Ehr systems. ERP systems. Risk management systems. Decision support systems. Trading systems. Field service support systems. Scheduling, packing, routing systems. Now everything has an ui, and data innies and outies, but gosh! That's just connectors to the diamond!
oppositelock 7y ago
Those jobs exist, but are few and far between, since cool ideas tend to be packaged up into reusable libraries, and don't need to be redeveloped, while everyone else uses these reusable libraries differently, so you have a constant need for "sanitation engineers". Tensorflow or OpenCV or UnrealEngine get written once, then everyone uses them to build whatever they're building. You write some cool glue around these, that's the interesting code, then spend most of your time wiring everything together into a larger package that actually does something useful. Once you've wired everything together, now you need to track version, build artifacts, manage release processes, test them and qualify them, etc, so you do a lot of QA and DevOps work. QA, DevOps and sanitation engineering is so product specific that it can't be packaged up, it's a craftsmanship position, and that's why all of us spend most of our time doing this kind of work.
- _bxg1 7y ago
  Yeah, that's what I figured. It's a bit depressing when you think about it. I guess for most of us that itch just has to be scratched by pleasure-programming.

mbo 7y ago

So, I've been a Scala programmer for the last 3 years, and have been effectively writing Haskell in Scala reasonably effectively. The pure FP Scala community understands your complaints more than the Haskell community. https://typelevel.org/ https://typelevel.org/ is chock full of a) useful utilities for actually writing applications b) decent documentation. Not just pages of type signatures, but demonstrations of the libs usage. Everything you need is here: JSON, config, units of measure, streams, testing, validation, a really nice JDBC wrapper (https://tpolecat.github.io/doobie/ https://tpolecat.github.io/doobie/) Throw in https://http4s.org/ https://http4s.org/ and you've got yourself a rock-solid, purely functional stack with sensible, documented APIs, a more readable syntax and better tooling support. I urge anyone who learnt some Haskell, thought "man this shit sucks, I'm never going to write something useful in this" to at least give FP Scala a chance. Here's a useful service template to start hacking with: https://github.com/http4s/http4s.g8 https://github.com/http4s/http4s.g8.

AdieuToLogic 7y ago
Another great resource for doing FP in Scala is "Functional Programming in Scala"[0]. It's a very well written book and goes far in introducing key FP concepts IMHO. 0 - https://www.manning.com/books/functional-programming-in-scala https://www.manning.com/books/functional-programming-in-scal...
dwohnitmok 7y ago
I feel conflicted about this having programmed in both OO-heavy and pure FP Scala. On the one hand, sure if you want to write pure FP in Scala, some of the tooling is better than Haskell. Most notably the IDE situation with IntelliJ's Scala plugin has made leaps and bounds in progress the last few years and mostly handles pure FP Scala code just fine. And having access to the JVM ecosystem is an absolute god-send and huge boost to productivity. This is true even outside of library dependencies when coding. If you try deploying to production with Haskell, there's often a large gap in production tooling (monitoring, diagnostics, GC tuning, etc.) when compared to the JVM. On the other hand Scala has its own share of infelicities when it comes to pure FP. I've mentioned this elsewhere, but the core language of Scala, that is the language that is left after you desugar everything, is OO and the FP part is really just a lot of syntax sugar mixed in with standard library data structure choices. That means if you're coming from a pure FP background a lot of things will seem like hacks (methods vs functions/automatic-eta-expansion, comparatively weak type inference, the final yield of a for-comprehension, subtyping to influence prioritization of implicits for typeclasses, monomorphic-only values vs. polymorphic classes, etc.). Treating Scala as an OO language side steps a lot of these warts. And then there's the social factors; the Scala community is split on how much it embraces pure FP and pure FP is a (significant) minority within the community. This carries over to the library ecosystem where things are basically split into Typelevel/Typelevel-using and non-Typelevel libraries. Many workplaces have a fear (well-placed and not so well-placed) of the Typelevel ecosystem. Years ago Scalaz was something akin to the bogeyman in some places. Cats has a bit of a softer image, but still comes off as an "advanced" library in the Scala ecosystem. Most of the social weight I feel is behind the non-pure-FP parts of Scala. Sure some of the libraries in pure FP Scala have good documentation (but I don't actually think the situation here is far better than Haskell's once you leave the core Typelevel libraries). The ones with excellent documentation though live outside the land of pure FP (Akka, Play, Spark, Slick, etc.).

thrower123 7y ago

Yeah, this more or less completely misses the point of what a working programmer would need to be doing. I honestly can't remember the last time I had to implement a data structure for real, and not just for the hell of it because I was bored. The closest I come is generally some sort of domain-specific shell that composites some data together. I feel like the F# community tends to be more grounded in reality. Or at least I'm more exposed to the side of it that is trying to popularize it in Microsoft, as a useful tool for Domain Driven Design and the like.