| As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed with the LISP machine.
The performance wasn't all that great. Initially garbage collection took 45 minutes, as it tried to garbage-collect paged-out code. Eventually that was fixed. The hardware was not very good. Too much wire wrap and slow, arrogant maintenance. I once had a discussion with the developers of Franz LISP. The way it worked was that it compiled LISP source files and produced .obj files. But instead of linking them into an executable, you had to load them into a run-time environment. So I asked, "could you put the run time environment in another .obj file, so you just link the entire program and get a standalone executable"? "Why would you want to do that?" "So we could ship a product." This was an alien concept to them. So was managing LISP files with source control, like everything else. LISP gurus were supposed to hack. And, in the end, 1980s "AI" technology didn't do enough to justify that hardware. |
| |
| ▲ | 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 26 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. | |
| ▲ | 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. |
| |
| ▲ | dbtc 4 hours ago | parent | prev [-] | | Wouldn't the whole system be the product then?
There's tradeoffs, but that's just integration. |
|
