> "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

▲ whstl 5 hours ago | parent | next [-]

Nah, it carried over to scripting languages.

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.

▲

graemep 30 minutes ago | parent | next [-]

TCL has good solutions for this, but its not made it a success.

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.

▲

jacquesm 4 hours ago | parent | prev | next [-]

Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infantilized programming but then required you to become an expert at resolving package manager conflicts.

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.

▲

ErroneousBosh 4 hours ago | parent [-]

Or, you know, it might just be that you're not very good at computers.

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.

▲

jacquesm 4 hours ago | parent | next [-]

This is such a hilarious comment.

Thank you for making my day.

▲

DonHopkins 4 hours ago | parent [-]

Hey Gen Z, as long as I have you on the line, could you please explain 67 to me?

I've heard of "68 and I'll owe you one", so is 67 about owing you two?

▲

jacquesm 4 hours ago | parent [-]

I'm having a hard time coping with my social media addiction while doing some fairly hardcore development on an STM32 based platform so sorry :)

Incidentally, when will you (multiple) come and visit?

It's been too long.

	▲	DonHopkins 4 hours ago \| parent [-]
		I owe you at least one or two! Maybe we can test your drones out on that Russian guy with the GoFundMe campaign, then I'll owe you three! ;)

▲

s0sa 2 hours ago | parent | prev [-]

Oh yeah? Well the jerk store called, and they’re running out of you!

▲

logicprog 4 hours ago | parent | prev | next [-]

Yeah, anytime I see a useful tool, and then find out it's written in Python, I want to kms — ofc, unless it happens to work with UV, but they don't always

▲

raverbashing 5 hours ago | parent | prev [-]

You are correct unfortunately

▲ rmunn 5 hours ago | parent | prev | next [-]

Not the ones I've used. Haskell compiles to executables, F# compiles to the same bytecode that C# does and can be shipped the same way (including compiling to executables if you need to deploy to environments where you don't expect the .NET runtime to be already set up), Clojure compiles to .jar files and deploys just like other Java code, and so on.

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.

▲ raverbashing 5 hours ago | parent [-]

True but some still wants me to understand what a monofunctor is or something that sounds like a disease to do things like print to screen or get a random number

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.

▲ jacquesm 4 hours ago | parent | next [-]

> 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.

▲

DonHopkins 3 hours ago | parent | next [-]

Yes, but they're "Hello world!" hostile, so traditional programming language pedagogy doesn't work well.

Q: How many Prolog programmers does it take to change a lightbulb?

A: Yes.

	▲	mchaver 2 hours ago \| parent [-]
		I imagine LLMs have already thrown traditional programming language pedagogy out the window.

▲

raverbashing 2 hours ago | parent | prev [-]

Yes I agree, pure functions are good building blocks (for the most part), but I don't think the current abstractions and ways of bridging the FP and Procedural world are good enough

Also have you managed to eliminate the side effect of your IP register changing when your program is running? ;)

▲ roryc89 4 hours ago | parent | prev [-]

In most FP languages it is simple to print to screen and get a random number.

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

▲ dbtc 4 hours ago | parent | prev [-]

Wouldn't the whole system be the product then? There's tradeoffs, but that's just integration.