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 works, 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.
Instead of jamming in thing after thing after thing blindly hoping it's going to work, try reading the error messages and making sense of why it's doing what it's doing.
This is such Gen Z behaviour - it doesn't work first time so throw a strop and fling stuff.
Thank you for making my day.
I've heard of "68 and I'll owe you one", so is 67 about owing you two?
Incidentally, when will you (multiple) come and visit?
It's been too long.
Yup, I guess I am not. Been coding for over 20 years, went through over a dozen different PLs and only Python - the best fucking friend who doesn't sugar coat it, tells you without stuttering - "you suck at this, buddy"
# PEP 9001: Constructive Computing Feedback
## Abstract
This PEP proposes a standardized error message for situations where Python interpreters shall inform the user of insufficient computational competence.
## Specification
When a user attempts to execute Python code that supposedly should work but it doesn't, the interpreter shall emit:
You're suck at computersWow, nearly as long ago as my first kernel module.
Then you ought to be able to figure out how to install one thing then, eh?
Just out of interest, what was it that was causing such a hassle? I expect it's not really relevant now, but it would be interesting to see how hard it would be to fix.
...especially when it's about problems that are universally accepted as not being trivial, and often require entire teams and ecosystems (Docker, Poetry, uv) to solve in scale.
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
This mentality seems to have carried over to (most) modern FP stacks