11–20 of 86 posts
[link redacted]
I find personally that there are some areas where FP shines -- anything that is or could be a CLI that takes some input and returns some other output is well suited. A GUI program is the manipulation of state, and it is poorly suited, though many sub parts might not be.
I consider taste a benefit, regardless of what your taste may be. There’s other things to weight, too, of course! But if the end result is that you enjoyed your time more than you would have if you were slinging Java, that’s not without merit.
You can write a confusing unreadable Haskell script, just like you can write a confusing unreadable Python script. There’s nothing magic about functional paradigm programming. It does, IMO, give you less foot guns related to state though. While I still actually like other paradigms, functional programming really limits how clever you can be with state. You can only pass things around immutability via parameters (At l…
I totally agree (and have seen both scenarios throughout my career).
That said, all else being equal[0], refactoring the purely functional code is, usually, easier, more reliable and less scary.
[0] - among other things, this assumes the person doing the refactoring knows, in this example, both Python and Haskell equally well.
Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects. Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the ch…
>Anything you could unit test without mock objects You can unit test without mock objects because you're following functional patterns.
Systems that have clear inputs and outputs. Parsers, compilers, stuff like that. SAT Solvers. Anything you could unit test without mock objects. Mixed initiative systems (say UI code where you call into the framework and the framework calls into you) can go either way. Sometimes you can formulate the part of your code in a pure functional way which tames the chaos, if you can’t or that formulation is unnatural the ch…
>Anything you could unit test without mock objects You can unit test without mock objects because you're following functional patterns.
Suppose you are writing a "CRUD" app that writes to a relational database, how do you apply functional programming to that? The whole point of an application like that is that it makes side effects.
In some cases you can break those problems down into functional pieces. Consider Python drivers for a product like
One major problem is that you want drivers that work synchronously and asynchronously, the structure of the average api call is something like
def query(parameters):
encoded_parameters = encode_parameter(parameters)
url = generate_rest_url(configuration, parameters)
response = do_post(url, encoded_parameters)
return decode_response(response)
- You can safely make more assumptions about how your program works - You can rely on your type checker like a to-do list when extending your program
These two benefits require more discipline, but they make extension and support brain-dead easy.
For the record, you don't need Haskell to enjoy these benefits, you can get them in Python or TypeScript too, as long as you're disciplined in how you design your system.
Referential transparency means that when we bind an expression to a name (e.g. `y = f x`), the two are interchangeable, and whenever we use `y` we could just as well use `f x` and vice versa, and the meaning of the code will stay the same.
Enforcing referential transparency in a programming language means that:
- We need to have more control over effects (purity)
- We can use substitution and equational reasoning
The value of referential transparency for me is that I can trust code to not surprise me with unexpected effects, I can use substitution to understand what a piece of code is doing, and I can always refactor by converting a piece of code to a new value or function because referential transparency guarantees that they are equivalent.
Because of that I feel like I can always understand how something works because I have a simple process to figure things out that doesn't require me keeping a lot of context in my head. I never feel like something is "magic" that I cannot understand. And I can easily change code to understand it better without changing its meaning.
Referential transparency is freeing, and makes me worry less when working with code!
---
The other part that is very notable about Haskell is one of its approaches to concurrency - Software Transactional Memory. Which is enabled by limiting the kind of effects we can perform in a transaction block:
https://www.oreilly.com/library/view/parallel-and-concurrent...
Earlier quoted context omitted.
>Anything you could unit test without mock objects You can unit test without mock objects because you're following functional patterns.
Not necessarily. For an easy counter example, build a Sierpiński triangle. Easy to unit test. Easier to build using imperative code than functional. (This goes for a ton of fractals, honestly.)
How easy it is to draw fractals depends on your tools. If you have turtle graphics with affine transformations (rotation and scaling) it is so easy to write simple recursive programs to draw space filling curves and such.
Are you _literally_ writing a simple script to do a single task which you won't save into version control? Pick whatever style will be fastest to write + run. But if you'll need to re-read it in 6 months to figure out how to re-use a portion in a different context, or the next engineer will need to migrate something out from under it in a year, or whatever else, then picking a style based on readability, testability, and analyzability can be worth it -- provided the rest of your team is on the same page.