> "So we could ship a product." This was an alien concept to them.
This mentality seems to have carried over to (most) modern FP stacks
This mentality seems to have carried over to (most) modern FP stacks
Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS.
They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perhaps JS was the exception but only to the last part.
Sure it mostly works today, but a lot of people put a lot of the effort so we can keep shoving square pegs into round roles.
For a while Conda seemed to have cracked this, but there too I now get unresolvable conflicts. It is really boggling the mind how you could get this so incredibly wrong and still have the kind of adoption that python has.
With the exception of Gstreamer. I use some awful hacks to break out of virtual environments and use the system Gstreamer, because it's not on PyPi....
Where I see Python used is in places where you do not need it packaged as executables:
1. Linux - where the package manager solves the problem. I use multiple GUI apps written in python
2. On servers - e.g. Django web apps, where the the environment is set up per application
3. Code written for specific environments - even for specific hardware
4. One off installs - again, you have a specified target environment.
In none of the above cases do I find the environment to be fragile. On the other hand, if you are trying to distribute a Windows app to a large number of users I would expect it to be problematic.
Which is significantly more than was needed for different technologies to achieve similar results.
Quick start guide: works on my machine.
I'll grant that there are plenty of languages that seemed designed for research and playing around with cool concepts rather than for shipping code, but the FP languages that I see getting the most buzz are all ones that can ship working code to users, so the end users can just run a standard .exe without needing to know how to set up a runtime.
I feel that is the biggest barrier to their adoption nowadays (and also silly things like requiring ;; at the end of the line)
Pure functions are a good theoretical exercise but they can't exist in practice.
Well, they can. But not all the way up to the top level of your program. But the longer you can hold off from your functions having side effects the more predictable and stable your codebase will be, with as an added benefit fewer bugs and less chance of runtime issues.
Q: How many Prolog programmers does it take to change a lightbulb?
A: Yes.
Also have you managed to eliminate the side effect of your IP register changing when your program is running? ;)
I find that both Python and Javascript allow you to use functional code when appropriate, without forcing you to use it when it isn’t.
Pure functions often exist in practice and are useful for preventing many bugs. Sure, they may not be suitable for some situations but they can prevent a lot of foot guns.
Here's a Haskell example with all of the above:
import System.Random (randomRIO)
main :: IO ()
main = do
num <- randomRIO (1, 100)
print $ pureFunction num
pureFunction :: Int -> Int
pureFunction x = x * x + 2 * x + 1