<- Back
Comments (102)
- mightybyteWas just talking with someone the other day who used to write Haskell professionally but is now using Python. He said that in his experience when there are bugs the "blast radius" is much larger in a dynamic language like Python than in a static language like Haskell. That has been my experience as well.Something I haven't seen talked about, though, is how powerful the type system is for constraining LLMs when using them to generate code. I was recently trying to get LLMs to generate code for a pretty vague and complex task in Haskell. I wasn't having much luck until I defined a very clear set of types and organized them into a very clear and constrained interface that I asked the LLM to code to. Then the results were much better!Sure, you can use these same techniques in less strongly typed languages like Rust, and you can probably also use a similar approach in dynamically typed languages, but Haskell's pure functions allow you to create much stronger guard rails constraining what kinds of code the LLM can write.
- charcircuit>In banking, telecom, and payments, reliability is not a nice to have. It is table stakes.This reliability isn't done by being perfect 100% of the time. Things like being able to handle states where transactions don't line up allowing for payments to eventually be settled. Or for telecom allowing for single parts of the system to not take down the whole thing or adding redundancy. Essentially these types of businesses require fault tolerance to be supported. The real world is messy, there is always going to be faults, so investing heavily into correctness may not be worth it compared to investing into fault tollerance.
- mlavrentThis article seems to conflate strong type systems with functional programming, except in point 8. It makes sense why- OCaml and Haskell are functional and were early proponents of these type systems. But, languages like Racket don’t have these type systems and the article doesn’t do anything to explain why they are _also_ better for reliability.
- whateveracct> In banking, telecom, and payments, reliability is not a nice to have. It is table stakes.Haha as someone who has worked in one of these domains using FP even - I wish the people in charge agreed with you!Reliability is a cost center and Product-oriented Builders treat it as such.
- northlondonerYes.
- pizlonatorIt's acceptable to state, without evidence, that functional programming and static typing make things more reliable.But this isn't a falsifiable claim. We cannot possibly know if this is true or not.- Not all of banking and telecom use functional programming or even static typing.- Functional programming often leads to write-only incomprehensible code; the exact opposite of what you need to have a reliable system.- There's no hard evidence that static typing improves reliability. Only vibes and feels.
- thundergolferAll the line items are decent things, worth doing, but the claim about how much following the line items would improve reliability is super exaggerated.> [Most production incidents] are due to the code entering a state that should never have been possible.I have never seen evidence that this is even remotely true, and I've been looking at software reliability research in the last few months.Instead, it is more true that most production incidents are due to the system entering into one of thousands of unsafe states which were possible and latent in production potentially for years. In a sufficiently complex system—all interesting and important software projects—functional programming is not strong enough a tool to prevent even a sliver of potential accidents.> Arguments that these degraded conditions should have been recognized before the overt accident are usually predicated on naïve notions of system performance. System operations are dynamic, with components (organizational, human, technical) failing and being replaced continuously. — https://how.complexsystems.fail/
- wewewedxfgdfI'm wary of absolute statements about programming.
- tasukiI'm impressed by the author having made so many sensible choices in their life, yet marrying their blog content to GitHub issues.
- websiteapiA few mention on tests, but I expected more. The main value of pure functions is that now their behavior is representative in tests. In fact, I'd argue that all you need for reliability is determinism and tests of all equivalent scenarios. functional programming (and immutability) are only helpful to the extent that it's easier to have representative tests, but not necessarily required.
- jschrfTup: Use interface for structural types in TypeScript, not type.
- jatinsThese arguments unfortunately fail flat in front of industrial use. AWS could be considered "critical" by most metrics and what is is it written in? Java
- d--bStrong types: yes, it’s definitely betterFunctional programming: no, functional programming as in: the final program consists in piping functions together and calling the pipe. In my opinion, that tends to get in the way of complex error handling.The problem being that raising Exceptions at a deep level and catching them at some higher level is not pure functional programming. So your code has to deal with all the cases. It is more reliable if you can do it, but large systems have way too many failure points to be able to handle them all in a way that is practical.
- xpeSee also the type-state pattern. It is commonly used in Rust along with the builder pattern [1]. Quoting:"""The typestate pattern is an API design pattern that encodes information about an object’s run-time state in its compile-time type. In particular, an API using the typestate pattern will have:- Operations on an object (such as methods or functions) that are only available when the object is in certain states,- A way of encoding these states at the type level, such that attempts to use the operations in the wrong state fail to compile,- State transition operations (methods or functions) that change the type-level state of objects in addition to, or instead of, changing run-time dynamic state, such that the operations in the previous state are no longer possible.This is useful because:- It moves certain types of errors from run-time to compile-time, giving programmers faster feedback.- It interacts nicely with IDEs, which can avoid suggesting operations that are illegal in a certain state.- It can eliminate run-time checks, making code faster/smaller."""Some other languages can do it as well: see [2] for a discussion.[1]: https://cliffle.com/blog/rust-typestate/[2]: https://www.reddit.com/r/rust/comments/17l8eez/is_there_any_...
- cubefoxI think there is a strong case that ADTs (algebraic data types) aren't so great after all. Specifically, the "tagged" unions of ADT languages like Haskell are arguably pretty clearly inferior to the "untagged" unions of TypeScript or Scala 3. Because the latter actually behave like a logical "or" rather than an artificial construct that needs to be wrapped and unwrapped.
- henningI like good type systems, too, but they won't save you from bugs that are better addressed by fuzz testing, fault injection testing and adversarial mindset shifts.
- FpUserYet another silver bullet.