6 ms·

> 10x is often cited as the magic number beyond which technology is good enough to overcome network effects. I'm personally convinced that functional programmin

> 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.
- jcelerier 6y ago
  > Bad code that ships gets us Windows. as much as an enthusiast linux user I am, I'm pretty sure that the world would be a worse place without DOS & Windows
  - ragnese 6y ago
    How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM.
    - Jtsummers 6y ago
      MS Window's presence in the market made PCs true commodities and drove down the price for home and office computers in a way none of their contemporary competitors would have achieved. Most of their competitors were tied to hardware, and received a lot of their revenue and profit from the combination of hardware and software sales. MS only needed to sell the software, and let HP, Dell, Gateway, and others compete on hardware prices. This probably put more computers out there (within that time span) than would have been achieved without them.
    - p_l 6y ago
      It's less about the deal, and more about MS following a pretty strict philosophy that if your software, the software you bought runs on OS version X, the only reason it may not run on version X+1 is a dumb bug in the software. Also they kept at "computers accessible to everyone", and as much as they fought competition, I have to admit they did it.
    - webmaven 6y ago
      > How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM. I've occasionally seen speculation that in the absence of the de-facto DOS monoculture that deal created, CP/M may have been the most likely desktop platform winner, at least initially.
- leafboi 6y ago
  “Bad code that ships is better than good code that doesn't” When you work on code long enough two things will eventually happen: Shippable Bad code will eventually be unshippable. Unshippable Good code will eventually be shippable. Your quotation simplifies a concept by hiding the extra dimension of time. Bad or good, shippable code depends on a point in time.... It could be shippable now, or shippable in the future...
- pc86 6y ago
  Pretty terrible example. Bad code gets us the most used, most popular desktop (and maybe server, definitely server for certain industries) operating system in the world? Mac is great, I have one, but Apple made it's cash stores on the back of the iPhone, not MacOS.
  - jheriko 6y ago
    IMO MacOS is not an example of good code, or good engineering. The engineering decisions made are often terrible, including recycling the legacy of NeXT for what I assume were ego-based reasons... Nothing in the history of Windows compares to that scale of bad.
    - pc86 6y ago
      I wasn't clear, I didn't mean to imply that MacOS is technically better than Windows, just that Windows is by far the most popular OS and was trying to cut off any rebuttal boiling down to "but I use a Mac."
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

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.
jcelerier 6y ago
> Bad code that ships gets us Windows. as much as an enthusiast linux user I am, I'm pretty sure that the world would be a worse place without DOS & Windows
- ragnese 6y ago
  How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM.
  - Jtsummers 6y ago
    MS Window's presence in the market made PCs true commodities and drove down the price for home and office computers in a way none of their contemporary competitors would have achieved. Most of their competitors were tied to hardware, and received a lot of their revenue and profit from the combination of hardware and software sales. MS only needed to sell the software, and let HP, Dell, Gateway, and others compete on hardware prices. This probably put more computers out there (within that time span) than would have been achieved without them.
  - p_l 6y ago
    It's less about the deal, and more about MS following a pretty strict philosophy that if your software, the software you bought runs on OS version X, the only reason it may not run on version X+1 is a dumb bug in the software. Also they kept at "computers accessible to everyone", and as much as they fought competition, I have to admit they did it.
  - webmaven 6y ago
    > How so? I mean, obviously it's impossible to make a decent educated guess since basically the entirety of most peoples' interactions with computers stems from the near-monopoly Microsoft had on personal computing in the 90s. But I'm still curious to know what you predict would be different if MS didn't strike their deal with IBM. I've occasionally seen speculation that in the absence of the de-facto DOS monoculture that deal created, CP/M may have been the most likely desktop platform winner, at least initially.
leafboi 6y ago
“Bad code that ships is better than good code that doesn't” When you work on code long enough two things will eventually happen: Shippable Bad code will eventually be unshippable. Unshippable Good code will eventually be shippable. Your quotation simplifies a concept by hiding the extra dimension of time. Bad or good, shippable code depends on a point in time.... It could be shippable now, or shippable in the future...
pc86 6y ago
Pretty terrible example. Bad code gets us the most used, most popular desktop (and maybe server, definitely server for certain industries) operating system in the world? Mac is great, I have one, but Apple made it's cash stores on the back of the iPhone, not MacOS.
- jheriko 6y ago
  IMO MacOS is not an example of good code, or good engineering. The engineering decisions made are often terrible, including recycling the legacy of NeXT for what I assume were ego-based reasons... Nothing in the history of Windows compares to that scale of bad.
  - pc86 6y ago
    I wasn't clear, I didn't mean to imply that MacOS is technically better than Windows, just that Windows is by far the most popular OS and was trying to cut off any rebuttal boiling down to "but I use a Mac."

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