15 ms·

Algebra Driven Design

137 points by agentultra 6y ago

Xophmeister 6y ago
This looks interesting and the "freebie" is quite extensive at 80 pages. It would be nice to have a full table of contents to see what more you can expect, rather than the "executive summary" of what you could hope to learn.
peterlk 6y ago
> 10x is often cited as the magic number beyond which technology is good enough to overcome network effects. I'm personally convinced that functional programming is 10x better than any other paradigm I've tried Better for who? Bad code that ships is better than good code that doesn't. From a business perspective, I don't care if it's written in COBOL as long as it ships. The critical missing piece in the functional argument is an example (or probably several) where a company using functional programming consistently outperformed one that wasn't. By default, the business will be opposed to using anything that isn't one of the big programming languages because haskell/scala programmers are expensive. Why would I pay a bunch of expensive haskell programmers to build a chat app? I could build something that got me 80% of the way there for 30% of the cost. I think Haskell can flourish in places where correctness matters - fintech, factory control systems, and weapons come to mind. But in the vast majority of places that employ programmers, correctness doesn't actually matter. One argument for this is that requirements change so often that "correct" is impossible to define, so the overhead of being correct is actually a bug, not a feature. With all that said, I do wish that we had better software, and that correctness mattered more. I like functional programming, and I think learning it can make any programmer better.
- leephillips 6y ago
  “Bad code that ships is better than good code that doesn't” Maybe better for your bottom line (no criticism, we all have to eat), but not better for the world. Look around at our software universe: bad code that shipped, everywhere. Bad code that ships gets us Windows.
  - AnimalMuppet 6y ago
    But good code that doesn't ship gets us nothing. Awful as it is (and especially as it was), Windows was good enough and cheap enough for a whole lot of people to be able to afford computers that they could use.
    - thinkharderdev 6y ago
      This assumes that bad code is, at worst, worth nothing which isn't the case. Bad code that crashes a mission critical system is absolutely worse than nothing. Or to take your Windows example, I could argue that the problem with Windows was the opportunity cost. If Windows didn't take over the world maybe we would have more choices when it comes to desktop OSs
      - AnimalMuppet 6y ago
        No. Bad code that crashes a mission critical system may in fact be worse less than nothing, but my argument doesn't assume that. It assumes that Windows, though bad code, was still worth more than nothing. What's more, it takes the massive success of Windows as market-based evidence that Windows was worth quite a bit more than nothing - or at least, computers running Windows were worth something. Opportunity cost isn't usually considered in terms of a market, it's considered for an organization. If Microsoft hadn't done Windows, could they have done something more successful with the resources? That's pretty hard to imagine. Certainly you can say that Windows was bad for (the rest of) the desktop OS market. But the fact is, no mind control rays were involved. Microsoft created an OS that unlocked enough functionality for the average user, for little enough cost, that Microsoft took over the world. (Yeah, I know, lock-in and monopoly shenanigans. It's true. But none of it would have mattered if the OS were not good enough to mostly work for most people.) I can't believe I'm being an apologist for Windows. Gack.
        thinkharderdev 6y ago
        Yeah, fair enough. I guess at least from MSFTs perspective bad code was better than nothing.
- aszen 6y ago
  I think for a chat app Haskell may not be useful(but note that whatsapp was built on top of Erlang, a somewhat functional language) I think Haskell and other functional languages can really improve software in domains with complex business logic and rules which is most of the software that deals with the real world and is useful to the world. Correctness does actually matter a lot in software, nobody would trust a calculator that doesn't give the right results. Ofcourse people can tolerate edge cases but it's far better to remove them upfront.
  - codygman 6y ago
    As a professional Haskell programmer for a bit now, I see no problem with a chat app in Haskell. In fact, something close is wire[0] whose server source code is here[1]. They are a secure alternative to slack and mattermost for the curious. 0: https://wire.com/en/explore/competitive-advantage/ https://wire.com/en/explore/competitive-advantage/ (this gave the best explanation in the comparison section of what it actually is imo) 1: https://github.com/wireapp/wire-server https://github.com/wireapp/wire-server
- Xophmeister 6y ago
  There's more to coding than churning out business logic. Even if not used in production, learning a different paradigm can have an enlightening perspective on ones ability to solve a problem.
- jasim 6y ago
  This notion that functional programming is about correctness kept me away from static types and FP for the better part of my career. I mean - who cares about correctness when I'm trying to ship yet another cookie-cutter web application that I don't even know is going to see more than a thousand users in its life. What I cared about was speed. A few bugs in production is a better trade-off than all the mathematical mumbo-jumbo and slow, meticulous programming that Typed FP seemed to demand. But to my surprise, after getting started with ReScript/Reason/OCaml, I recognized that correctness is just a side-effect (!) of this mode of programming. (Note that unlike Haskell, OCaml is an imperative programming language with as much or as little mutation as we need. We can almost line-by-line translate a regular mutation-heavy piece of Python or JavaScript code to OCaml, if we wanted to.) Typed FP, contrary to what I'd came to expect, is all about speed. Quoting from something I wrote a while ago: "Refactoring a typed FP program is safe, but menial. When we say safe - it means no anxiety. There is going to be tons of mechanical work for every major type refactor - going thru all the compiler errors and fixing them one by one. That can't be avoided. We've been in multi-day refactoring sessions where we had to dredge thru page after page of compiler errors before we could even run the application. But - it is safe - we know that once it compiles, there won't be any mistakes. That gives us the freedom to build fast and loose - and take stock periodically before we have to abstract things out and tidy up the place. We should compulsively rely on that safety. Typed FP forces us to go slow in places where a dynamic environment would've allowed us to blaze through. For all that trouble, we get unmitigated refactoring dexterity and we must exploit it to benefit from the paradigm." There are many places where a dynamic, imperative approach is faster than a typed FP approach. But there are as many or more places where it is the other way round. I'm now fastest with this way of programming than anything else, and I wish that more literature around Typed FP communicated this rather than go about the indirect route of correctness, and expect people to pick up that correctness-by-construction results in increased velocity. That's a difficult jump to make unless one has written non-trivial amount of code in that style. This book by Sandy - I've read the introduction and skimmed thru the Tile construction equations - is to me poetry. I'm having trouble fitting in the idealistic notion of the Escher tile to my imperfect real-world domain, but otherwise, what a book!
  - Twisol 6y ago
- thinkharderdev 6y ago
  I think you misunderstand what "correctness" is really about. To me at least it's about creating a small set of powerful abstractions that can be applied generally to any problem. In order for those abstractions not to "leak" they need be really rigorously defined. The alternative I think is to have a lot of ad-hoc abstractions for each application that break as soon as requirements change. I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network.
  - jheriko 6y ago
    > I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network. Your argument fails to be an argument at all. Can you justify that first sentence? I do not see any convincing reason why you disagree... or even any reasons here tbh.
    - thinkharderdev 6y ago
      I assume by first sentence you mean the statement that "That is how we get software that is riddled with security issues" The argument is that you assume that the minimum value of code is zero, so that any code that ships has to be better than code that doesn't ship because at worst it is worthless, which is the same value as code that doesn't ship. My point is that bad code can be worth less than zero if it actively causes harm. So for example, code that has a critical security vulnerability which leaks personal information is worse than nothing. You would be better off not shipping anything at all than shipping something that causes actual harm.
- kickopotomus 6y ago
  > Bad code that ships is better than good code that doesn't But for how long? At some point, the technical debt that comes along with rushing out bad code will come back to bite you. You might be able to get a workable prototype for cheap but if it's a project that you want to sell and support long term, you may just be setting yourself up for failure down the road.
- marcosdumay 6y ago
  You are completely jumping to the conclusion that when the author says "10x better" he means some dimension that you do not care about. Programmers care about productivity too. And when somebody puts a number as in "10x better", that is usually the metric they are talking about. (Although this one seems so fuzzy that the statement is meaningless.)
  - xmprt 6y ago
    I don't know many programmers who are jumping to use Haskell for their personal projects. What you use at work is usually determined by the surrounding infrastructure but at home you can use whatever you want for productivity and yet most people continue to use their favorite non-functional language. If it's really 10x better and can overcome network effects then shouldn't we see a lot of Haskell personal projects?
    - skrebbel 6y ago
      Did you read the article? This exact argument is made and an entire book was written to address it.
    - codygman 6y ago
      > I don't know many programmers who are jumping to use Haskell for their personal projects. If you don't use Haskell or are suspicious of it, would you expect to know other programmers who use it? We have data that can more strongly make the opposite claim that people do use haskell for personal projects: > The functional language Haskell is the tag most visited outside of the workday; https://stackoverflow.blog/2017/04/19/programming-languages-used-late-night/ https://stackoverflow.blog/2017/04/19/programming-languages-...
- PaulStatezny 6y ago
  > Bad code that ships is better than good code that doesn't. Logical fallacy: false dichotomy. What about good code that ships? Best of both worlds.
  - swagonomixxx 6y ago
    Note: Before I possibly get railed for not knowing functional programming or anything like that, I actually really like functional programming, for a limited set of applications (mostly compilers, and other algorithm heavy stuff). > What about good code that ships? Best of both worlds. Right, but what is good code? The author of this page claims that code out of the "Algebra-Driven Design" paradigm is good code. But where's the proof? It's not enough to pull out the math textbook and give us fancy words like monoids, lattices, whatever (this is coming from someone who loved algebra classes far more than analysis classes in my math degree). I'd really like to see real world code that uses this. And by real world code, I mean code that isn't some contrived example, code that actually runs somewhere, and provides real-world value, e.g, a semi-popular website, e.g HN, Lobsters, Reddit, or something that runs on a robot, or something. I don't know. The common theme of all of these Haskell/Idris/SomeOtherMathyLanguage posts is that almost none of them bring any real world software to the table, that has been tried and tested by the real world, e.g, consumers, customers, whatever, except for a perhaps GHC, a handful of well maintained Haskell libraries, the Idris compilers, that Haskell spam filter at Facebook. We keep saying that functional programming is much better than any other paradigm. But the share of functional programming languages is tiny in comparison with the imperative/OO family languages, and there's a reason for that. Most functional languages are hard to use, have very little library support, and functional abstractions don't _really_ matter in the long run when it comes to bugs. Sure, C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think. I just find it absurd that on these functional programming posts, everyone just keeps saying that the only good code is functional code. It's simply not the case.
    - scns 6y ago
      Facebook rewrote the Messenger in ReasonML. Before they got hundreds of bugreports a year. Afterwards? Less then ten.
- codygman 6y ago
  > Bad code that ships is better than good code that doesn't. Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made. That works fine until a wall is hit and things have to be rewritten or worse hacks have to be added. That ends up taking more time than the original solution, but guess what... no one is going to bring that up. That means the correct solution never has a chance to get the points it earned to be weighted more highly next time a decision of correctness vs speed is made. There are pre-built frameworks for handling the common "ship the bad code, never say it's so bad it's a net loss, and just iterate on the crap on top of crap you have" so that all levels of the organization feel more comfortable. > With all that said, I do wish that we had better software, and that correctness mattered more. It can't matter until technical debt is analyzed on a meaningful time scale and actual observations happen, rather than what amounts to making things seem like they're going smoothly.
- amw-zero 6y ago
  Can you help me understand this logic - what business can make money off of software that doesn’t work?
  - jdgiese 6y ago
    Well, eventually it has to work. But if we write a buggy Python program in most industries, and it breaks, the customers complain a bit and you fix it. I suspect what the parent means is there are some industries where you can't afford for it to break at all. I.e., you don't need to guarantee correctness.
  - Jtsummers 6y ago
    Bad code still works. It may not work well in some regard: - Hard to maintain - Slow - Hard to extend (slightly different than maintain, but related) - Crash-prone (but infrequent enough) - Corrupts data (but infrequent enough) - Just wrong enough to be annoying but not wrong enough to be useless I had colleagues on a project (I really wanted to help them fix it, but was never brought on board) that was truly bad code. There was copy/pasta everywhere. The same function written a half dozen or more times with slight differences (or none, no idea why it was copied in the first place), so bug fixes would partially address an issue but not when all copies weren't fixed. It was massive (hundreds of thousands of lines by this point, maybe over a million now) with mostly new team (original coders were contractors, and original team for us all moved on). The size and quality made it hard to extend in a sane way because there were so many unknowns. It had random concurrency issues which would only crop up reliably when fielded. The fundamental design was flawed. They had to connect N different protocols (each different but communicating the same kind of information) to each other. Instead of coming up with an intermediate format they did 1-to-1 connections, which meant an explosion in complexity. Instead of N translation units to an internal format and N translation units out, it was N * (N - 1) translation units, every protocol needed a way to translate to every other. The sane way would mean adding a new protocol required 2 new translation units, the insane way required 2 * N (the new protocol to all existing protocols, all existing protocols to the new one). It shipped, it made millions (in revenue) every year, but it was not good code.
    - 6y ago
revskill 6y ago
I prefer a book on api design with haskell rather than this theoretic book.
- codygman 6y ago
  This "theoretic book" can help you design a very good api. If you mean REST api's by chance, remember those were theoretic once too!
commandlinefan 6y ago
This is something I spend a lot of time thinking about myself - it seems like functional program ought to be > object-oriented program which ought to be > procedural programming. However, I've almost never seen a functionally-designed application "in the wild" and honestly, it's pretty rare to even see an object-oriented one. It seems like every program I ever dig into is mostly written procedurally, even if it's written in a language that supports higher-level abstractions. And, for the most part, software works. As much as I love the concept of pure functional programming, how do we really know that "functional programming is better" and that's not just wishful thinking on our part? Looking forward to digging into this - hopefully the author can make a better case than others have.
- leephillips 6y ago
  Neither paradigm solves the expression problem. This forces people to break the paradigm as the code grows. Look at the code in some Julia packages, and you will see good use of abstractions around a language design where the expression problem does not exist. This is practical stuff, being used in applied scientific research on a large scale.
  - trumpeta 6y ago
    Here's how you can solve expression problem using object algebras: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf
    - Twisol 6y ago
      I'll make a stronger statement than "can": I have and do productively use object algebras in my day-to-day in Java. It's a really fantastic tool when you need an "interface" that governs multiple types or across more than one receiver. Even when you're not trying to solve the expression problem. When you're defining an interface on a type that doesn't need to appear in its own method parameters or return types, and where the actual type doesn't matter (as in classic OOP), Java interfaces are fine. But not all problems are best framed this way.
harry8 6y ago
I'd be more convinced if the author linked a bunch of software they'd written before writing yet another haskell tutorial. 10x? We're way above 10x in the ratio of haskell/functional/monad tutorials to running applications. If touting that yours is "the one" and we should skip over the tens of thousands of others out there, some supporting evidence might be useful. Applications written in haskell you can run on your computer for doing something other than programming is still a list that you can count on your fingers. Please let me be wrong about that and list them if I am. I'll be delighted and wildly enthused.
- leephillips 6y ago
  The one I know about is Pandoc, which I use every day.
  - harry8 6y ago
    One? Ok we'll do the full list again: xmonad. Some websites usable as applications using yesod maybe. (Shellcheck - great but doesn't count, you use it for programming a computer). What else are we missing. The list is not to bash Haskell, it's is instructive to be aware of a pretty significant data point and understand /why/ edit: Please note that libraries are /not/ applications but the two are conflated here (accidentally?) obscuring the point: https://wiki.haskell.org/Applications_and_libraries https://wiki.haskell.org/Applications_and_libraries
    - burkaman 6y ago
      BazQux is unfortunately not entirely open source, but it is my favorite RSS reader, is a profitable user-facing application, and is written partly in Haskell: https://bazqux.com/faq https://bazqux.com/faq https://github.com/bazqux/bazqux-urweb/tree/master/crawler https://github.com/bazqux/bazqux-urweb/tree/master/crawler Off the top of my head I also know of Freckle (https://www.freckle.com/ https://www.freckle.com/) and Co-Star (https://www.costarastrology.com/ https://www.costarastrology.com/). More importantly, this is not a Haskell book! I'm sure the author would be happy to see these ideas applied using Javascript or Scala or Java 14 or anything else. > Haskell is considered a difficult language to learn, which is certainly true if you come from traditional procedural languages. But rest assured, this is not a Haskell book. You won’t need more than a passing understanding of the language’s syntax and a few high-level idioms. Everything you’ll need to know will be shown later in this section. The ideas present in these pages are adaptable to any piece of technology you’d like, though they might require strictly more discipline to maintain than is necessary in Haskell. - Chapter 1.3.1, page 6 I'm not going to try to list all the user-facing applications written in any functional language, but I'm sure we can agree it is a much longer list.
jinwoo68 6y ago
I love Haskell and appreciate its abstraction power. But recently I started to think that one of the reasons that prevent it from becoming more popular is that the community focuses too much on "mathematical" abstractions. Almost every abstraction becomes a mathematical one. "Oh, this thing turns out to be a Monoid! Let me abstract it." "Oh, I can simplify this using Traversal", etc. They usually make perfect sense and useful abstractions, but at the same time they scare many programmers away. Especially non-math-savvy programmers will be easily turned away when they see code that is heavily abstracted in a mathematical manner. I also come from Lisp and Lisp focuses on building a language using the terms/concepts from the given problem domain. And when you do it right, it makes the code very natural in that specific problem domain and any domain experts can understand the code easily. Haskell communities do it very differently by making everything a mathematical problem, and it's only math experts who feel comfortable with the code.
- thinkharderdev 6y ago
  I'm not sure the Haskell community really wants the language to become more popular as a primary goal. Sure, it would be great if more people appreciated its power and adopted it, but not if it requires compromising on its core strength: rigorous correctness. And that's fine! Not every language needs to focus world domination. It's probably better that we have a lot of niche languages that are uncompromising and highly optimized for specific types of problems (or rather highly optimized for certain types of programmers). Also, you don't need to be mathematician or really be grounded in math at all to understand the abstractions favored in Haskell. I think https://www.scalawithcats.com/dist/scala-with-cats.html https://www.scalawithcats.com/dist/scala-with-cats.html is a really good example of explaining abstractions that are grounded in Category Theory without ever even trying to connect them to their mathematical origins. The abstractions can be explained and applied on their own terms.
- ghj 6y ago
  Mathematical abstractions are often at the wrong level of abstraction. Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too. For example, sure, you can think of a list as a "monoid" where the add operator is concatenation of two list. But adding two lists is not a fast operation even using specialized functional data structures. So making concatenation a primitive for equational reasoning just results in really slow code.
g_delgado14 6y ago
The top comment on yesterday's post on the Keli language (https://news.ycombinator.com/item?id=24331635 https://news.ycombinator.com/item?id=24331635) sums up FP's failure to become mainstream pretty clearly IMO: > The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means. That's why I think languages like Elm are a good example of "the sweet spot" of FP languages. Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list".
- random3 6y ago
  I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for each abstraction, so modeling without fully understanding what you try to model or something that changes wrt the abstraction model will yield incomplete abstractions, be hard to read, etc. Many things are being remodeled over an over (incomplete, with bugs, etc.) when in fact they don't change much. These are good candidates for good abstractions. I don't think you'd want to do 3d graphics without a system that understand the algebraic aspects (e.g. orthogonality) behind rotations, translations, etc. Categories generalize this all the way so optimizations would be possible at a whole different level (makes me think about what Tensorflow enables). I also think you only need one category (just like you only need one group / semigroup concept) for a model and it could be language agnostic.
  - codygman 6y ago
g_delgado14 6y ago
Someone wrote a comment in this thread saying that Haskell's strength is "rigorous correctness". Ok sure, I agree that generally your program is going to be more correct with Haskell than with, say, TypeScript. But that doesn't preclude a TypeScript program from ever being as correct as a Haskell one. One limitation might be the additional boilerplate due to the inability to abstract as much as Haskell. But if more boilerplate translates to greater readability (i.e. less abstraction & much closer relation to the problem domain) then I would argue that the added boilerplate is justified. Hence I don't really see, "rigorous correctness" as a good selling point for using Haskell since company culture tends to affect correctness just as much as the language a team uses.
- gmfawcett 6y ago
  That's a pretty big "if", though. Boilerplate is generally noisy, and it can be challenging to encapsulate it well enough (e.g. behind function boundaries) that the remaining code is high level and business-logic oriented. Company culture can only go so far (unless you're willing to pay the full tax, and maintain your code in the costly, slow way that e.g. NASA and other life-critical systems developers would). You can get halfway to Nirvana just by using a language that self-manages memory and has some kind of exception system (error handling at a distance); something like RAII (automatic lifecycle management, or automatic destructors in a pinch) can be a big help, too. Now, at least, all the systems-level boilerplate can be omitted from your mainline code. But high level, business logic pitfalls are hard to encapsulate, and especially so in a dynamically typed program. Documentation becomes critically important (don't ever do X before you do Y), as rigorous unit tests for chains of actions can sometimes be difficult to write. A good, type-level model of your program can be a helpful set of safety rails when refactoring a a large and complex code base, and a rich type system gives you more tools to build those rails to fit the the solution you're building. As a (weak) example, if your type model never lets you read from a file that's already been closed, that's one less thing you have to cover in testing or documentation -- or more importantly, it's one less thing you have to remember to test. At scale, having multiple ways to introduce structure into an otherwise chaotic (or arbitrarily structured) code base is a win. Building a good type-level model is one smart way to achieve that.
- 6y ago
Chris_Newton 6y ago
As both a mathematician and a programmer who often works on projects where high reliability is essential, I want to like the concept behind this book. However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance, which are the usual practical problems with trying to employ formal methods and very “mathematical” abstractions. Sadly, the early repetition of the usual faux quicksort example and the casual dismissal of arguments by “purists” about the difference is going crush the author’s credibility among a large group of programmers by the end of page 7, which is not a good omen.
- bmitc 6y ago
  Do you mind sharing what industry you work in and how you got there? I am mainly caught by "as both a mathematician and a programmer who often works on projects where high reliability is essential". I was a mathematician (or more strictly am a failed mathematician) who also does software, and so I am always curious what other domains people with this background work in. In general, I am turned off as well from the abstractionauts in the software world, particularly those found in the Haskell realm, and highly prefer more pragmatic functional languages like F#, Racket, and Elixir/Erlang.
  - codygman 6y ago
    > I am turned off as well from the abstractionauts in the software world Is there any way you can give examples of this in Haskell? If I'm just blind to them by now I'd like to know, but most "abstractionaut" criticisms I've heard seem to ignore the pragmatic ideals driving the reasons for the abstraction and ignoring inherent complexity.
  - Chris_Newton 6y ago
    Do you mind sharing what industry you work in and how you got there? I’ve worked on software in a few different industries, but the ones that needed particularly good reliability were mostly related to hardware deployed in challenging environments. For example, it’s never good to discover a bug in production when your firmware update process involves helicopters. :-) I’ve also worked on software that used quite intricate data processing algorithms, where any bugs could manifest as subtly incorrect behaviour that might not be noticed until it was too late and some serious failure had been caused. I didn’t specifically pursue these kinds of projects, they just happen to be common themes in the roles I’ve taken over the years. In time, I developed an interest in tools and processes for producing software that is significantly more reliable than much of what our profession produces, yet not necessarily on the level of say threat-to-life or running-a-satellite code where extreme measures might be justified almost regardless of cost. I firmly believe that even with the inevitable pressures driving commercial software development, the standards in our business could be much higher than they often are today, and that much of the problem is due to people — developers, managers, users — not realising what else is achievable or what it would really cost.
li4ick 6y ago
I'm starting to think that every thread about FP is pretty much identical on HN, especially when Haskell is involved. If you still need a ton of push to try it out, you'll never get it. If decades upon decades of provably superior concepts haven't convinced you, just give up. Just go and get hyped when the next minor FP feature gets integrated into your favourite language, something that's been used in Haskell/Erlang/etc. for 20+ years.
- whateveracct 6y ago
  Yeah I've focused on building things with Haskell (using way less energy and time in the process due to exactly what this book claims) There's really no point arguing with people. Sometimes I can't help myself, but I barely ever get anything useful out of trying.
- mrkeen 6y ago
  > I'm starting to think that every thread about FP is pretty much identical on HN Spot on. Where is Haskell actually used? No I meant apart from Facebook and Uber and Klarna. > Just go and get hyped when the next minor FP feature gets integrated into your favourite language We already have immutability in Java - why, the designers themselves made Strings immutable [1] We said goodbye to nulls in Java [2] but in case you really don't like nulls you can also say goodbye to them by switching from Java to Kotlin, which doesn't have them [3] but also does [4]. If you want to cut down on some boilerplate (without moving to Kotlin), you can try type inference in Java [5]: > For example, consider the following variable declaration: Map<String, List<String>> myMap = new HashMap<String, List<String>>(); > You can substitute the parameterized type of the constructor with an empty set of type parameters (<>): Map<String, List<String>> myMap = new HashMap<>(); Go got rid of Generics which made programming so much simpler. I can't wait for its new Generics feature though. But if you really need that functional stuff - the best thing writing Java code is that it runs on the JVM, so you can code in Scala instead. And if that argument doesn't make you want to code in Java I don't know what will. [1] https://javarevisited.blogspot.com/2010/10/why-string-is-immutable-or-final-in-java.html https://javarevisited.blogspot.com/2010/10/why-string-is-imm... [2] https://programmer.help/blogs/finally-i-m-happy-to-say-goodbye-to-null-say.html https://programmer.help/blogs/finally-i-m-happy-to-say-goodb... [3] https://medium.com/kayvan-kaseb/say-bye-to-nullpointerexception-in-kotlin-c8f0bae2c773 https://medium.com/kayvan-kaseb/say-bye-to-nullpointerexcept... [4] https://stackoverflow.com/questions/50427490/nullable-type-still-throw-nullpointer-exception-at-kotlin https://stackoverflow.com/questions/50427490/nullable-type-s... [5] https://docs.oracle.com/javase/tutorial/java/generics/genTypeInference.html https://docs.oracle.com/javase/tutorial/java/generics/genTyp...
codygman 6y ago
You might have been bitten by this before: 1. Make it work 2. Make it right 3. Make it fast (uh-oh your nice design prevents performance optimizations, time to scrap it) The reaction to that is usually to think more about performance ahead of time so you don't get trapped by your theoretically perfect design when the real world comes crashing down. With your hard-won experience you do away with those childish notions of being able to make a perfect elegant design where you don't have to worry about performance until the end. The most valuable thing you'll find in Sandy's book is that you can actually ignore performance until the end and nearly always (always maybe?) be able to make it fast. You can regain your optimism from your younger years before the bad experiences and resume this path: 1. Make it work 2. Make it right 3. Make it fast I think it goes without saying that I highly recommend Sandy's book and think it could be the way forward for quickly writing correct, elegant (composable/re-usable!), and FAST programs.
- Ericson2314 6y ago
  IMO 1. Make it correct and not insane asymptotically. 2. Tune constant factors, if you need to. In school I was confused why they kept on talking about asymptotics and ignoring the different costs of the building blocks. Now I see that, while it is true that asymptotic analysis doesn't well explain performance when "things are good": 1. There are a lot of stupid things people do write that it does catch. 2. Since it is scale free, it makes sense as a way to evaluate programs throughout their entire development. 3. Constant factor optimizations will always tempt one to ruin abstraction boundaries, but asymptotic analysis shouldn't----or if it does, sorry your abstraction sucks and needs to go. (Hi ORMs.) The latter points are really powerful. Never make me work without efficient tree map/set union and intersection ever again.
- leafboi 6y ago
  >theoretically perfect design We have no metric to use to quantitatively score one design as something unequivocally better than another design. This is the first thing you will need before you can prove one "design" is "better" than the other. Until than we are doomed to go in circles and have endless debates. I believe even if we do find some quantitative measure on program "designs" it won't be rating something as "better" or "worse" it will likely be metrics on many dimensions measuring tradeoffs.
jheriko 6y ago
> I'm personally convinced that functional programming is 10x better than any other paradigm I've tried. The failing is having a simple model that assumes that any one paradigm is ever best. A multi-paradigm language will always have the capacity to be better, or equal, by any metric. I also strongly disagree with this sentiment based on experience. There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug.... a problem made worse by the, very honestly, absolutely appalling quality of almost all example code - normalising one letter variable names, squeezing things onto one line and all kind of other terrible practises. these are deeply serious problems that fp fanboys and academia seem to glaze over, presumably from a lack of real world experience, or appreciation of how valuable these qualities are ...
- codygman 6y ago
  > There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug What niches are these where FP is "classically difficult to read, write or debug"?
  - non-entity 6y ago
    I think they're saying the opposite, that FP languages are difficult in general and only useful in a few niches.

137 points by agentultra 6y ago

This looks interesting and the "freebie" is quite extensive at 80 pages. It would be nice to have a full table of contents to see what more you can expect, rather than the "executive summary" of what you could hope to learn.

peterlk 6y ago

> 10x is often cited as the magic number beyond which technology is good enough to overcome network effects. I'm personally convinced that functional programming is 10x better than any other paradigm I've tried Better for who? Bad code that ships is better than good code that doesn't. From a business perspective, I don't care if it's written in COBOL as long as it ships. The critical missing piece in the functional argument is an example (or probably several) where a company using functional programming consistently outperformed one that wasn't. By default, the business will be opposed to using anything that isn't one of the big programming languages because haskell/scala programmers are expensive. Why would I pay a bunch of expensive haskell programmers to build a chat app? I could build something that got me 80% of the way there for 30% of the cost. I think Haskell can flourish in places where correctness matters - fintech, factory control systems, and weapons come to mind. But in the vast majority of places that employ programmers, correctness doesn't actually matter. One argument for this is that requirements change so often that "correct" is impossible to define, so the overhead of being correct is actually a bug, not a feature. With all that said, I do wish that we had better software, and that correctness mattered more. I like functional programming, and I think learning it can make any programmer better.

leephillips 6y ago
“Bad code that ships is better than good code that doesn't” Maybe better for your bottom line (no criticism, we all have to eat), but not better for the world. Look around at our software universe: bad code that shipped, everywhere. Bad code that ships gets us Windows.
- AnimalMuppet 6y ago
  But good code that doesn't ship gets us nothing. Awful as it is (and especially as it was), Windows was good enough and cheap enough for a whole lot of people to be able to afford computers that they could use.
  - thinkharderdev 6y ago
    This assumes that bad code is, at worst, worth nothing which isn't the case. Bad code that crashes a mission critical system is absolutely worse than nothing. Or to take your Windows example, I could argue that the problem with Windows was the opportunity cost. If Windows didn't take over the world maybe we would have more choices when it comes to desktop OSs
    - AnimalMuppet 6y ago
      No. Bad code that crashes a mission critical system may in fact be worse less than nothing, but my argument doesn't assume that. It assumes that Windows, though bad code, was still worth more than nothing. What's more, it takes the massive success of Windows as market-based evidence that Windows was worth quite a bit more than nothing - or at least, computers running Windows were worth something. Opportunity cost isn't usually considered in terms of a market, it's considered for an organization. If Microsoft hadn't done Windows, could they have done something more successful with the resources? That's pretty hard to imagine. Certainly you can say that Windows was bad for (the rest of) the desktop OS market. But the fact is, no mind control rays were involved. Microsoft created an OS that unlocked enough functionality for the average user, for little enough cost, that Microsoft took over the world. (Yeah, I know, lock-in and monopoly shenanigans. It's true. But none of it would have mattered if the OS were not good enough to mostly work for most people.) I can't believe I'm being an apologist for Windows. Gack.
      - thinkharderdev 6y ago
        Yeah, fair enough. I guess at least from MSFTs perspective bad code was better than nothing.
aszen 6y ago
I think for a chat app Haskell may not be useful(but note that whatsapp was built on top of Erlang, a somewhat functional language) I think Haskell and other functional languages can really improve software in domains with complex business logic and rules which is most of the software that deals with the real world and is useful to the world. Correctness does actually matter a lot in software, nobody would trust a calculator that doesn't give the right results. Ofcourse people can tolerate edge cases but it's far better to remove them upfront.
- codygman 6y ago
  As a professional Haskell programmer for a bit now, I see no problem with a chat app in Haskell. In fact, something close is wire[0] whose server source code is here[1]. They are a secure alternative to slack and mattermost for the curious. 0: https://wire.com/en/explore/competitive-advantage/ https://wire.com/en/explore/competitive-advantage/ (this gave the best explanation in the comparison section of what it actually is imo) 1: https://github.com/wireapp/wire-server https://github.com/wireapp/wire-server
Xophmeister 6y ago
There's more to coding than churning out business logic. Even if not used in production, learning a different paradigm can have an enlightening perspective on ones ability to solve a problem.
jasim 6y ago
This notion that functional programming is about correctness kept me away from static types and FP for the better part of my career. I mean - who cares about correctness when I'm trying to ship yet another cookie-cutter web application that I don't even know is going to see more than a thousand users in its life. What I cared about was speed. A few bugs in production is a better trade-off than all the mathematical mumbo-jumbo and slow, meticulous programming that Typed FP seemed to demand. But to my surprise, after getting started with ReScript/Reason/OCaml, I recognized that correctness is just a side-effect (!) of this mode of programming. (Note that unlike Haskell, OCaml is an imperative programming language with as much or as little mutation as we need. We can almost line-by-line translate a regular mutation-heavy piece of Python or JavaScript code to OCaml, if we wanted to.) Typed FP, contrary to what I'd came to expect, is all about speed. Quoting from something I wrote a while ago: "Refactoring a typed FP program is safe, but menial. When we say safe - it means no anxiety. There is going to be tons of mechanical work for every major type refactor - going thru all the compiler errors and fixing them one by one. That can't be avoided. We've been in multi-day refactoring sessions where we had to dredge thru page after page of compiler errors before we could even run the application. But - it is safe - we know that once it compiles, there won't be any mistakes. That gives us the freedom to build fast and loose - and take stock periodically before we have to abstract things out and tidy up the place. We should compulsively rely on that safety. Typed FP forces us to go slow in places where a dynamic environment would've allowed us to blaze through. For all that trouble, we get unmitigated refactoring dexterity and we must exploit it to benefit from the paradigm." There are many places where a dynamic, imperative approach is faster than a typed FP approach. But there are as many or more places where it is the other way round. I'm now fastest with this way of programming than anything else, and I wish that more literature around Typed FP communicated this rather than go about the indirect route of correctness, and expect people to pick up that correctness-by-construction results in increased velocity. That's a difficult jump to make unless one has written non-trivial amount of code in that style. This book by Sandy - I've read the introduction and skimmed thru the Tile construction equations - is to me poetry. I'm having trouble fitting in the idealistic notion of the Escher tile to my imperfect real-world domain, but otherwise, what a book!
- Twisol 6y ago
thinkharderdev 6y ago
I think you misunderstand what "correctness" is really about. To me at least it's about creating a small set of powerful abstractions that can be applied generally to any problem. In order for those abstractions not to "leak" they need be really rigorously defined. The alternative I think is to have a lot of ad-hoc abstractions for each application that break as soon as requirements change. I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network.
- jheriko 6y ago
  > I really, really disagree with the idea that bad code that ships is always better than code that doesn't. That is how we get software that is riddled with security issues. Even if the specific application isn't that important, it very well might be a major catastrophe if it has a severe security vulnerabilities that allows an attacker to get a root shell on a server in your internal network. Your argument fails to be an argument at all. Can you justify that first sentence? I do not see any convincing reason why you disagree... or even any reasons here tbh.
  - thinkharderdev 6y ago
    I assume by first sentence you mean the statement that "That is how we get software that is riddled with security issues" The argument is that you assume that the minimum value of code is zero, so that any code that ships has to be better than code that doesn't ship because at worst it is worthless, which is the same value as code that doesn't ship. My point is that bad code can be worth less than zero if it actively causes harm. So for example, code that has a critical security vulnerability which leaks personal information is worse than nothing. You would be better off not shipping anything at all than shipping something that causes actual harm.
kickopotomus 6y ago
> Bad code that ships is better than good code that doesn't But for how long? At some point, the technical debt that comes along with rushing out bad code will come back to bite you. You might be able to get a workable prototype for cheap but if it's a project that you want to sell and support long term, you may just be setting yourself up for failure down the road.
marcosdumay 6y ago
You are completely jumping to the conclusion that when the author says "10x better" he means some dimension that you do not care about. Programmers care about productivity too. And when somebody puts a number as in "10x better", that is usually the metric they are talking about. (Although this one seems so fuzzy that the statement is meaningless.)
- xmprt 6y ago
  I don't know many programmers who are jumping to use Haskell for their personal projects. What you use at work is usually determined by the surrounding infrastructure but at home you can use whatever you want for productivity and yet most people continue to use their favorite non-functional language. If it's really 10x better and can overcome network effects then shouldn't we see a lot of Haskell personal projects?
  - skrebbel 6y ago
    Did you read the article? This exact argument is made and an entire book was written to address it.
  - codygman 6y ago
    > I don't know many programmers who are jumping to use Haskell for their personal projects. If you don't use Haskell or are suspicious of it, would you expect to know other programmers who use it? We have data that can more strongly make the opposite claim that people do use haskell for personal projects: > The functional language Haskell is the tag most visited outside of the workday; https://stackoverflow.blog/2017/04/19/programming-languages-used-late-night/ https://stackoverflow.blog/2017/04/19/programming-languages-...
PaulStatezny 6y ago
> Bad code that ships is better than good code that doesn't. Logical fallacy: false dichotomy. What about good code that ships? Best of both worlds.
- swagonomixxx 6y ago
  Note: Before I possibly get railed for not knowing functional programming or anything like that, I actually really like functional programming, for a limited set of applications (mostly compilers, and other algorithm heavy stuff). > What about good code that ships? Best of both worlds. Right, but what is good code? The author of this page claims that code out of the "Algebra-Driven Design" paradigm is good code. But where's the proof? It's not enough to pull out the math textbook and give us fancy words like monoids, lattices, whatever (this is coming from someone who loved algebra classes far more than analysis classes in my math degree). I'd really like to see real world code that uses this. And by real world code, I mean code that isn't some contrived example, code that actually runs somewhere, and provides real-world value, e.g, a semi-popular website, e.g HN, Lobsters, Reddit, or something that runs on a robot, or something. I don't know. The common theme of all of these Haskell/Idris/SomeOtherMathyLanguage posts is that almost none of them bring any real world software to the table, that has been tried and tested by the real world, e.g, consumers, customers, whatever, except for a perhaps GHC, a handful of well maintained Haskell libraries, the Idris compilers, that Haskell spam filter at Facebook. We keep saying that functional programming is much better than any other paradigm. But the share of functional programming languages is tiny in comparison with the imperative/OO family languages, and there's a reason for that. Most functional languages are hard to use, have very little library support, and functional abstractions don't _really_ matter in the long run when it comes to bugs. Sure, C/C++/Java code is never bug free, but it's not tremendously difficult to write real-world applications using these languages, simply because of how well their memory models/object models/features map to the way most programmers think. I just find it absurd that on these functional programming posts, everyone just keeps saying that the only good code is functional code. It's simply not the case.
  - scns 6y ago
    Facebook rewrote the Messenger in ReasonML. Before they got hundreds of bugreports a year. Afterwards? Less then ten.
codygman 6y ago
> Bad code that ships is better than good code that doesn't. Sometimes, but not always. The bad code that ships however always feels better and gives the feeling that progress is being made. That works fine until a wall is hit and things have to be rewritten or worse hacks have to be added. That ends up taking more time than the original solution, but guess what... no one is going to bring that up. That means the correct solution never has a chance to get the points it earned to be weighted more highly next time a decision of correctness vs speed is made. There are pre-built frameworks for handling the common "ship the bad code, never say it's so bad it's a net loss, and just iterate on the crap on top of crap you have" so that all levels of the organization feel more comfortable. > With all that said, I do wish that we had better software, and that correctness mattered more. It can't matter until technical debt is analyzed on a meaningful time scale and actual observations happen, rather than what amounts to making things seem like they're going smoothly.
amw-zero 6y ago
Can you help me understand this logic - what business can make money off of software that doesn’t work?
- jdgiese 6y ago
  Well, eventually it has to work. But if we write a buggy Python program in most industries, and it breaks, the customers complain a bit and you fix it. I suspect what the parent means is there are some industries where you can't afford for it to break at all. I.e., you don't need to guarantee correctness.
- Jtsummers 6y ago
  Bad code still works. It may not work well in some regard: - Hard to maintain - Slow - Hard to extend (slightly different than maintain, but related) - Crash-prone (but infrequent enough) - Corrupts data (but infrequent enough) - Just wrong enough to be annoying but not wrong enough to be useless I had colleagues on a project (I really wanted to help them fix it, but was never brought on board) that was truly bad code. There was copy/pasta everywhere. The same function written a half dozen or more times with slight differences (or none, no idea why it was copied in the first place), so bug fixes would partially address an issue but not when all copies weren't fixed. It was massive (hundreds of thousands of lines by this point, maybe over a million now) with mostly new team (original coders were contractors, and original team for us all moved on). The size and quality made it hard to extend in a sane way because there were so many unknowns. It had random concurrency issues which would only crop up reliably when fielded. The fundamental design was flawed. They had to connect N different protocols (each different but communicating the same kind of information) to each other. Instead of coming up with an intermediate format they did 1-to-1 connections, which meant an explosion in complexity. Instead of N translation units to an internal format and N translation units out, it was N * (N - 1) translation units, every protocol needed a way to translate to every other. The sane way would mean adding a new protocol required 2 new translation units, the insane way required 2 * N (the new protocol to all existing protocols, all existing protocols to the new one). It shipped, it made millions (in revenue) every year, but it was not good code.
  - 6y ago

revskill 6y ago

I prefer a book on api design with haskell rather than this theoretic book.

codygman 6y ago
This "theoretic book" can help you design a very good api. If you mean REST api's by chance, remember those were theoretic once too!

commandlinefan 6y ago

This is something I spend a lot of time thinking about myself - it seems like functional program ought to be > object-oriented program which ought to be > procedural programming. However, I've almost never seen a functionally-designed application "in the wild" and honestly, it's pretty rare to even see an object-oriented one. It seems like every program I ever dig into is mostly written procedurally, even if it's written in a language that supports higher-level abstractions. And, for the most part, software works. As much as I love the concept of pure functional programming, how do we really know that "functional programming is better" and that's not just wishful thinking on our part? Looking forward to digging into this - hopefully the author can make a better case than others have.

leephillips 6y ago
Neither paradigm solves the expression problem. This forces people to break the paradigm as the code grows. Look at the code in some Julia packages, and you will see good use of abstractions around a language design where the expression problem does not exist. This is practical stuff, being used in applied scientific research on a large scale.
- trumpeta 6y ago
  Here's how you can solve expression problem using object algebras: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf
  - Twisol 6y ago
    I'll make a stronger statement than "can": I have and do productively use object algebras in my day-to-day in Java. It's a really fantastic tool when you need an "interface" that governs multiple types or across more than one receiver. Even when you're not trying to solve the expression problem. When you're defining an interface on a type that doesn't need to appear in its own method parameters or return types, and where the actual type doesn't matter (as in classic OOP), Java interfaces are fine. But not all problems are best framed this way.

harry8 6y ago

I'd be more convinced if the author linked a bunch of software they'd written before writing yet another haskell tutorial. 10x? We're way above 10x in the ratio of haskell/functional/monad tutorials to running applications. If touting that yours is "the one" and we should skip over the tens of thousands of others out there, some supporting evidence might be useful. Applications written in haskell you can run on your computer for doing something other than programming is still a list that you can count on your fingers. Please let me be wrong about that and list them if I am. I'll be delighted and wildly enthused.

leephillips 6y ago
The one I know about is Pandoc, which I use every day.
- harry8 6y ago
  One? Ok we'll do the full list again: xmonad. Some websites usable as applications using yesod maybe. (Shellcheck - great but doesn't count, you use it for programming a computer). What else are we missing. The list is not to bash Haskell, it's is instructive to be aware of a pretty significant data point and understand /why/ edit: Please note that libraries are /not/ applications but the two are conflated here (accidentally?) obscuring the point: https://wiki.haskell.org/Applications_and_libraries https://wiki.haskell.org/Applications_and_libraries
  - burkaman 6y ago
    BazQux is unfortunately not entirely open source, but it is my favorite RSS reader, is a profitable user-facing application, and is written partly in Haskell: https://bazqux.com/faq https://bazqux.com/faq https://github.com/bazqux/bazqux-urweb/tree/master/crawler https://github.com/bazqux/bazqux-urweb/tree/master/crawler Off the top of my head I also know of Freckle (https://www.freckle.com/ https://www.freckle.com/) and Co-Star (https://www.costarastrology.com/ https://www.costarastrology.com/). More importantly, this is not a Haskell book! I'm sure the author would be happy to see these ideas applied using Javascript or Scala or Java 14 or anything else. > Haskell is considered a difficult language to learn, which is certainly true if you come from traditional procedural languages. But rest assured, this is not a Haskell book. You won’t need more than a passing understanding of the language’s syntax and a few high-level idioms. Everything you’ll need to know will be shown later in this section. The ideas present in these pages are adaptable to any piece of technology you’d like, though they might require strictly more discipline to maintain than is necessary in Haskell. - Chapter 1.3.1, page 6 I'm not going to try to list all the user-facing applications written in any functional language, but I'm sure we can agree it is a much longer list.

jinwoo68 6y ago

I love Haskell and appreciate its abstraction power. But recently I started to think that one of the reasons that prevent it from becoming more popular is that the community focuses too much on "mathematical" abstractions. Almost every abstraction becomes a mathematical one. "Oh, this thing turns out to be a Monoid! Let me abstract it." "Oh, I can simplify this using Traversal", etc. They usually make perfect sense and useful abstractions, but at the same time they scare many programmers away. Especially non-math-savvy programmers will be easily turned away when they see code that is heavily abstracted in a mathematical manner. I also come from Lisp and Lisp focuses on building a language using the terms/concepts from the given problem domain. And when you do it right, it makes the code very natural in that specific problem domain and any domain experts can understand the code easily. Haskell communities do it very differently by making everything a mathematical problem, and it's only math experts who feel comfortable with the code.

thinkharderdev 6y ago
I'm not sure the Haskell community really wants the language to become more popular as a primary goal. Sure, it would be great if more people appreciated its power and adopted it, but not if it requires compromising on its core strength: rigorous correctness. And that's fine! Not every language needs to focus world domination. It's probably better that we have a lot of niche languages that are uncompromising and highly optimized for specific types of problems (or rather highly optimized for certain types of programmers). Also, you don't need to be mathematician or really be grounded in math at all to understand the abstractions favored in Haskell. I think https://www.scalawithcats.com/dist/scala-with-cats.html https://www.scalawithcats.com/dist/scala-with-cats.html is a really good example of explaining abstractions that are grounded in Category Theory without ever even trying to connect them to their mathematical origins. The abstractions can be explained and applied on their own terms.
ghj 6y ago
Mathematical abstractions are often at the wrong level of abstraction. Mathematicians mostly care about value semantics but programmers need to care about how it's realized in hardware too. For example, sure, you can think of a list as a "monoid" where the add operator is concatenation of two list. But adding two lists is not a fast operation even using specialized functional data structures. So making concatenation a primitive for equational reasoning just results in really slow code.

g_delgado14 6y ago

The top comment on yesterday's post on the Keli language (https://news.ycombinator.com/item?id=24331635 https://news.ycombinator.com/item?id=24331635) sums up FP's failure to become mainstream pretty clearly IMO: > The other reason is that many FP users are too enthusiastic about creating abstractions. This is of course something that FP is exceptionally well suited for. An api that was written to simply process a list of Orders into a Report might be abstracted into a fold on some monad, which at first seems a great idea. But if you're not careful, readability suffers a lot. It's much easier to get to know an application when its code deals with business objects that you already understand well, than to read hundreds of lines of code that deal only with abstractions. Industry programmers didn't sign up to learn about category theory. They do what they do because they like building things. There is a subset of those Industry Programmers that does indeed like learning about category theory and all of these other concepts necessary to grok languages such as Haskell - but it isn't a critical mass by any means. That's why I think languages like Elm are a good example of "the sweet spot" of FP languages. Yes, Elm lacks the horsepower that other pure FP languages have, but at least it doesn't lead a developer to think "hey, I didn't sign up to learn about Arrows and Monads. I just want to write a TODO list".

random3 6y ago
I think this is a long term investment that goes beyond engineer / language /etc. preferences. It's a matter of abstraction 'stability'. There's a cost for each abstraction, so modeling without fully understanding what you try to model or something that changes wrt the abstraction model will yield incomplete abstractions, be hard to read, etc. Many things are being remodeled over an over (incomplete, with bugs, etc.) when in fact they don't change much. These are good candidates for good abstractions. I don't think you'd want to do 3d graphics without a system that understand the algebraic aspects (e.g. orthogonality) behind rotations, translations, etc. Categories generalize this all the way so optimizations would be possible at a whole different level (makes me think about what Tensorflow enables). I also think you only need one category (just like you only need one group / semigroup concept) for a model and it could be language agnostic.
- codygman 6y ago

g_delgado14 6y ago

Someone wrote a comment in this thread saying that Haskell's strength is "rigorous correctness". Ok sure, I agree that generally your program is going to be more correct with Haskell than with, say, TypeScript. But that doesn't preclude a TypeScript program from ever being as correct as a Haskell one. One limitation might be the additional boilerplate due to the inability to abstract as much as Haskell. But if more boilerplate translates to greater readability (i.e. less abstraction & much closer relation to the problem domain) then I would argue that the added boilerplate is justified. Hence I don't really see, "rigorous correctness" as a good selling point for using Haskell since company culture tends to affect correctness just as much as the language a team uses.

gmfawcett 6y ago
That's a pretty big "if", though. Boilerplate is generally noisy, and it can be challenging to encapsulate it well enough (e.g. behind function boundaries) that the remaining code is high level and business-logic oriented. Company culture can only go so far (unless you're willing to pay the full tax, and maintain your code in the costly, slow way that e.g. NASA and other life-critical systems developers would). You can get halfway to Nirvana just by using a language that self-manages memory and has some kind of exception system (error handling at a distance); something like RAII (automatic lifecycle management, or automatic destructors in a pinch) can be a big help, too. Now, at least, all the systems-level boilerplate can be omitted from your mainline code. But high level, business logic pitfalls are hard to encapsulate, and especially so in a dynamically typed program. Documentation becomes critically important (don't ever do X before you do Y), as rigorous unit tests for chains of actions can sometimes be difficult to write. A good, type-level model of your program can be a helpful set of safety rails when refactoring a a large and complex code base, and a rich type system gives you more tools to build those rails to fit the the solution you're building. As a (weak) example, if your type model never lets you read from a file that's already been closed, that's one less thing you have to cover in testing or documentation -- or more importantly, it's one less thing you have to remember to test. At scale, having multiple ways to introduce structure into an otherwise chaotic (or arbitrarily structured) code base is a win. Building a good type-level model is one smart way to achieve that.
6y ago

Chris_Newton 6y ago

As both a mathematician and a programmer who often works on projects where high reliability is essential, I want to like the concept behind this book. However, based on the website and sample chapters, it’s not clear that there will be strong arguments made here about either scalability or performance, which are the usual practical problems with trying to employ formal methods and very “mathematical” abstractions. Sadly, the early repetition of the usual faux quicksort example and the casual dismissal of arguments by “purists” about the difference is going crush the author’s credibility among a large group of programmers by the end of page 7, which is not a good omen.

bmitc 6y ago
Do you mind sharing what industry you work in and how you got there? I am mainly caught by "as both a mathematician and a programmer who often works on projects where high reliability is essential". I was a mathematician (or more strictly am a failed mathematician) who also does software, and so I am always curious what other domains people with this background work in. In general, I am turned off as well from the abstractionauts in the software world, particularly those found in the Haskell realm, and highly prefer more pragmatic functional languages like F#, Racket, and Elixir/Erlang.
- codygman 6y ago
  > I am turned off as well from the abstractionauts in the software world Is there any way you can give examples of this in Haskell? If I'm just blind to them by now I'd like to know, but most "abstractionaut" criticisms I've heard seem to ignore the pragmatic ideals driving the reasons for the abstraction and ignoring inherent complexity.
- Chris_Newton 6y ago
  Do you mind sharing what industry you work in and how you got there? I’ve worked on software in a few different industries, but the ones that needed particularly good reliability were mostly related to hardware deployed in challenging environments. For example, it’s never good to discover a bug in production when your firmware update process involves helicopters. :-) I’ve also worked on software that used quite intricate data processing algorithms, where any bugs could manifest as subtly incorrect behaviour that might not be noticed until it was too late and some serious failure had been caused. I didn’t specifically pursue these kinds of projects, they just happen to be common themes in the roles I’ve taken over the years. In time, I developed an interest in tools and processes for producing software that is significantly more reliable than much of what our profession produces, yet not necessarily on the level of say threat-to-life or running-a-satellite code where extreme measures might be justified almost regardless of cost. I firmly believe that even with the inevitable pressures driving commercial software development, the standards in our business could be much higher than they often are today, and that much of the problem is due to people — developers, managers, users — not realising what else is achievable or what it would really cost.

li4ick 6y ago

I'm starting to think that every thread about FP is pretty much identical on HN, especially when Haskell is involved. If you still need a ton of push to try it out, you'll never get it. If decades upon decades of provably superior concepts haven't convinced you, just give up. Just go and get hyped when the next minor FP feature gets integrated into your favourite language, something that's been used in Haskell/Erlang/etc. for 20+ years.

whateveracct 6y ago
Yeah I've focused on building things with Haskell (using way less energy and time in the process due to exactly what this book claims) There's really no point arguing with people. Sometimes I can't help myself, but I barely ever get anything useful out of trying.
mrkeen 6y ago
> I'm starting to think that every thread about FP is pretty much identical on HN Spot on. Where is Haskell actually used? No I meant apart from Facebook and Uber and Klarna. > Just go and get hyped when the next minor FP feature gets integrated into your favourite language We already have immutability in Java - why, the designers themselves made Strings immutable [1] We said goodbye to nulls in Java [2] but in case you really don't like nulls you can also say goodbye to them by switching from Java to Kotlin, which doesn't have them [3] but also does [4]. If you want to cut down on some boilerplate (without moving to Kotlin), you can try type inference in Java [5]: > For example, consider the following variable declaration: Map<String, List<String>> myMap = new HashMap<String, List<String>>(); > You can substitute the parameterized type of the constructor with an empty set of type parameters (<>): Map<String, List<String>> myMap = new HashMap<>(); Go got rid of Generics which made programming so much simpler. I can't wait for its new Generics feature though. But if you really need that functional stuff - the best thing writing Java code is that it runs on the JVM, so you can code in Scala instead. And if that argument doesn't make you want to code in Java I don't know what will. [1] https://javarevisited.blogspot.com/2010/10/why-string-is-immutable-or-final-in-java.html https://javarevisited.blogspot.com/2010/10/why-string-is-imm... [2] https://programmer.help/blogs/finally-i-m-happy-to-say-goodbye-to-null-say.html https://programmer.help/blogs/finally-i-m-happy-to-say-goodb... [3] https://medium.com/kayvan-kaseb/say-bye-to-nullpointerexception-in-kotlin-c8f0bae2c773 https://medium.com/kayvan-kaseb/say-bye-to-nullpointerexcept... [4] https://stackoverflow.com/questions/50427490/nullable-type-still-throw-nullpointer-exception-at-kotlin https://stackoverflow.com/questions/50427490/nullable-type-s... [5] https://docs.oracle.com/javase/tutorial/java/generics/genTypeInference.html https://docs.oracle.com/javase/tutorial/java/generics/genTyp...

codygman 6y ago

You might have been bitten by this before: 1. Make it work 2. Make it right 3. Make it fast (uh-oh your nice design prevents performance optimizations, time to scrap it) The reaction to that is usually to think more about performance ahead of time so you don't get trapped by your theoretically perfect design when the real world comes crashing down. With your hard-won experience you do away with those childish notions of being able to make a perfect elegant design where you don't have to worry about performance until the end. The most valuable thing you'll find in Sandy's book is that you can actually ignore performance until the end and nearly always (always maybe?) be able to make it fast. You can regain your optimism from your younger years before the bad experiences and resume this path: 1. Make it work 2. Make it right 3. Make it fast I think it goes without saying that I highly recommend Sandy's book and think it could be the way forward for quickly writing correct, elegant (composable/re-usable!), and FAST programs.

Ericson2314 6y ago
IMO 1. Make it correct and not insane asymptotically. 2. Tune constant factors, if you need to. In school I was confused why they kept on talking about asymptotics and ignoring the different costs of the building blocks. Now I see that, while it is true that asymptotic analysis doesn't well explain performance when "things are good": 1. There are a lot of stupid things people do write that it does catch. 2. Since it is scale free, it makes sense as a way to evaluate programs throughout their entire development. 3. Constant factor optimizations will always tempt one to ruin abstraction boundaries, but asymptotic analysis shouldn't----or if it does, sorry your abstraction sucks and needs to go. (Hi ORMs.) The latter points are really powerful. Never make me work without efficient tree map/set union and intersection ever again.
leafboi 6y ago
>theoretically perfect design We have no metric to use to quantitatively score one design as something unequivocally better than another design. This is the first thing you will need before you can prove one "design" is "better" than the other. Until than we are doomed to go in circles and have endless debates. I believe even if we do find some quantitative measure on program "designs" it won't be rating something as "better" or "worse" it will likely be metrics on many dimensions measuring tradeoffs.

jheriko 6y ago

> I'm personally convinced that functional programming is 10x better than any other paradigm I've tried. The failing is having a simple model that assumes that any one paradigm is ever best. A multi-paradigm language will always have the capacity to be better, or equal, by any metric. I also strongly disagree with this sentiment based on experience. There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug.... a problem made worse by the, very honestly, absolutely appalling quality of almost all example code - normalising one letter variable names, squeezing things onto one line and all kind of other terrible practises. these are deeply serious problems that fp fanboys and academia seem to glaze over, presumably from a lack of real world experience, or appreciation of how valuable these qualities are ...

codygman 6y ago
> There are some tiny niches where functional programming is particularly useful, but outside of them the code is classically difficult to read, write or debug What niches are these where FP is "classically difficult to read, write or debug"?
- non-entity 6y ago
  I think they're saying the opposite, that FP languages are difficult in general and only useful in a few niches.