71–80 of 86 posts
For me, as a UI dev, there are a lot of repetitive tasks. FP allows me to know that the Lego pieces all work as they should.
I wouldn't say there is any threshold where purely functional programming shines less. Fewer regressions and the system being more likely to "just work" makes it more fun to develop. So for interactive programs, servers, CLI tools, parsers et.c. purely functional programming is amazing. An elm developer reported that the prototype they wrote in elm ended up with less bugs than the actual production system. I personal…
> I wouldn't say there is any threshold where purely functional programming shines less. But what is the set of problems you are usually solving? Any problem set that involves a lot of mutable set is not well-suited for functional programming, in my opinion. And maybe problems where efficiency is important, although I don't know enough to have an opinion on that. Some areas that come to mind are: - systems programmin…
Functions handle state perfectly with scopes and closures.
I work full-time as a Haskell programmer, I stream myself building various Haskell projects once a week at https://twitch.tv/agentultra , I maintain a couple of Haskell libraries, and I occasionally do other things too. I've been a professional programmer for a little more than twenty years and have been using Haskell to this degree for about the last 4 or so. A good chunk of my career was dedicated to Python and C.…
This sounds really interesting. Is there a toy example that comes to mind that you could share?
Earlier quoted context omitted.
Read what you’ve quoted. They say the ecosystem is lacking, not that the issue is inherent in FP.
They wrote about "places where the ecosystem is not quite as mature", and then referenced interacting with cloud services. I read that as alluding to the rapid development and instability of some cloud services. I've written plenty of non-FP code that interacts with less mature systems, and the problems I've always run into have been related to changing APIs and behaviors of the remote systems, not anything inherent…
Earlier quoted context omitted.
They wrote about "places where the ecosystem is not quite as mature", and then referenced interacting with cloud services. I read that as alluding to the rapid development and instability of some cloud services. I've written plenty of non-FP code that interacts with less mature systems, and the problems I've always run into have been related to changing APIs and behaviors of the remote systems, not anything inherent…
What I had in mind was that the library ecosystem just isn't mature yet, so the libraries are incomplete or undocumented.
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.
... or working in an environment or on a problem for which functional patterns apply. 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 https://www.arangodb…
However what you might want to do (and this is based on IIRC!) is have a typeclass for your database interaction. Then the real DB type and the mock one can both implement that typeclass and you have basically dependency injection.
There are other ways like free monads but I never got my head around that.
You could also create a monad transformer which is a bit more straight forward. They let you compose monads, so you can chain little bits of side effect. Like “here is something that can talk to a database and write logs and that is all it will do” … but actually it is pure! It thinks it is doing those things but they can be mocked.
I work full-time as a Haskell programmer, I stream myself building various Haskell projects once a week at https://twitch.tv/agentultra , I maintain a couple of Haskell libraries, and I occasionally do other things too. I've been a professional programmer for a little more than twenty years and have been using Haskell to this degree for about the last 4 or so. A good chunk of my career was dedicated to Python and C.…
> control flow is kind of... represented in data types This sounds really interesting. Is there a toy example that comes to mind that you could share?
`Either Int Char`
Example values of this type are: Left 3, Right 'a', Left -99, Right 'X'.
When we pattern match on a value of this `Either Int Char` type we have two branches to handle:
``` case myValue of
Left someInt -> "It's an integer: " ++ show someInt
Right someChar -> "It's a char: " ++ [someChar]
You can nest them if you need more branches: `Either Int (Either Char String)` and you can match out the different branches. Although people don't usually write code this way in Haskell: we usually think of better types that model what we're trying to do.
This is such a common way of doing things. There's a great function called, `compare` that returns a value of type `Ordering` which can be one of: LT, EQ, GT for each of the cases when comparing things with the usual comparison operators.
A lot of Haskell is variations on pattern matching: guards, if-expressions, etc.
Where this becomes even more useful is when you start to use types to enforce pre-conditions. I don't know how many times I've seen code in C++ or Python or Javascript where you have to validate the inputs to a function: make sure the list isn't empty otherwise throw an error! In Haskell we can prevent that possibility and eliminate the need for a useless check by writing a type for a non-empty list and use that in our function's signature (note: you can do this in C++ and Javascript too, it's a good idea).
Or you can write your type so that it fails in some way if the inputs are not right: use `Either SomeError Int`. Then your callers have to handle the error case and the happy case.
There are such things as "exceptions" in Haskell but they're limited (mostly) to things that happen in `IO` returning functions. There are ways to pick apart the seams of the GHC runtime and do nefarious things that would throw exceptions that would break the usual rules (eg: https://hackage.haskell.org/package/bytestring-0.10.8.1/docs...). However it's incredibly rare and sticks out like a sore thumb that it forces you to give such code extra scrutiny.
Exceptions aren't used for control flow in the same way that they are in Python, say. Handling them though is possible and a whole other topic. Let's just say it's a bit tricky to get used to... though Haskell has some good facilities for properly handling async/threads and exceptions so that resources are cleaned up and handled properly.
If you choose to write your core product in a functional programming language, you now have to hire an entire team of people who can program FP. If you decide to write your core product in Javascript, Node, or Typescript, you can now hire bootcamp grads and a handful of senior engineers to keep an eye on them