5 ms·

I think you do have to factor in ecosystem inertia, however I also feel that numpy, scipy, and scikit-learn are pretty new, all things considered. We could have

I think you do have to factor in ecosystem inertia, however I also feel that numpy, scipy, and scikit-learn are pretty new, all things considered. We could have (and indeed did) take different paths in the past, just none of the others (xlispstat) really took. To me the chain of events that got us here go way further back. C was much, much better suited to squeezing performance out of the hardware of the late 1970s and 1980s (C fast; lisp slow). From there, the foundation of basically every operating system and system library we know and love today were built... in C. Python never tried to break free of being a veneer over C, with vaguely C sensibilities. Python displaced Perl as the prevailing veneer language because it had objects, and objects were all the rage right as people were learning about Python on Usenet and later Slashdot. The initial set of assumptions haven't held. Just about any serious language in the lisp family runs circles around Python. Lisp is no longer slow. But now we've been thinking in "C-ish" for so long that lisp is weird. We broke our collective brains on the gross abstractions of C and C-veneer, that we can't even see how gross it is. Will Julia ultimately gain traction? I don't know. They're trying to be a lisp that doesn't trigger our weird reflex. Bindings to a lower level language seem more like a liability in 2023 than 1993. And just in case, Julia has gone to some pains to allow reuse of C code, way down at the LLVM level, which is something Python can't say. But while Julia was getting built, Python built an ecosystem.

pjmlp 4y ago
I love this story, except that it wasn't quite so regarding early C compilers. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
- peatmoss 4y ago
  As I understand it (and this is before my time), garbage collection in lisp languages was really a downer on 70s and even 80s era hardware. I think a case could be made that C wasn't the only language at the time that could have birthed UNIX, but I'm not sure a lisp family language is in that list. (Edit: noting that C very much happened together with unix) Java was the first garbage collected language that really hit it bigtime in the mainstream. And even then, I remember the zeitgeist of the early days of Java being that Java was perhaps fatally slow. A lot has changed since then, and I'm firmly in camp "why can't we have nice things like lisp?" but I'm not sure I'd have picked a lisp (or C) back when the foundations of our current *nix paradigm were laid.
  - pjmlp 4y ago
    BASIC was the very first hitting big time outside big iron, many versions used reference counting as GC algorithm for strings and arrays. There were others as well, Lisp wasn't the only game in town with automatic memory management. As for systems languages predating C, there were several of them starting with JOVIAL in 1958.
  - kazinator 4y ago
    BASIC interpreters for 8 bit microcomputers, having 48 Kb of RAM or less, and running at 1 MHz, used garbage collection for strings just fine. That software was tailor-made to the machines from scratch. I would say it was the size and complexity of Lisp systems, developed in ivory towers on big iron hardware, which had trouble fitting in to emerging low-cost microchip-based hardware. When microcomputers emerged, they had the capabilities of mainframes from 15 (or more) years before. Current software from mainframes just wouldn't fit. That's how a lot of the languages and operating systems became swiftly relegated to the past. (Why do we still have Unix and Unix-like systems today? Unix started relatively late, on small minicomputers that were not so far off from subsequent microcomputers. Unix made the jump from PDP-7, 11 to DEC Vax, and 680x0 Sun boxes and such.) A Lisp system measuring its heaps and image sizes in hundreds of kilobytes or megabytes simply wouldn't fit into a system measured in tens of kilobytes. People working with Lisp machines in the 80's couldn't get customers (or not mass market customers), because mass market customers didn't want to buy expensive hardware. Only some big companies or governments. Today your GNU Bash may hit a 20 megabyte VM footprint, and you don't even notice, let alone pause to think about how "wrong" that is.

pjmlp 4y ago

I love this story, except that it wasn't quite so regarding early C compilers. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming

peatmoss 4y ago
As I understand it (and this is before my time), garbage collection in lisp languages was really a downer on 70s and even 80s era hardware. I think a case could be made that C wasn't the only language at the time that could have birthed UNIX, but I'm not sure a lisp family language is in that list. (Edit: noting that C very much happened together with unix) Java was the first garbage collected language that really hit it bigtime in the mainstream. And even then, I remember the zeitgeist of the early days of Java being that Java was perhaps fatally slow. A lot has changed since then, and I'm firmly in camp "why can't we have nice things like lisp?" but I'm not sure I'd have picked a lisp (or C) back when the foundations of our current *nix paradigm were laid.
- pjmlp 4y ago
  BASIC was the very first hitting big time outside big iron, many versions used reference counting as GC algorithm for strings and arrays. There were others as well, Lisp wasn't the only game in town with automatic memory management. As for systems languages predating C, there were several of them starting with JOVIAL in 1958.
- kazinator 4y ago
  BASIC interpreters for 8 bit microcomputers, having 48 Kb of RAM or less, and running at 1 MHz, used garbage collection for strings just fine. That software was tailor-made to the machines from scratch. I would say it was the size and complexity of Lisp systems, developed in ivory towers on big iron hardware, which had trouble fitting in to emerging low-cost microchip-based hardware. When microcomputers emerged, they had the capabilities of mainframes from 15 (or more) years before. Current software from mainframes just wouldn't fit. That's how a lot of the languages and operating systems became swiftly relegated to the past. (Why do we still have Unix and Unix-like systems today? Unix started relatively late, on small minicomputers that were not so far off from subsequent microcomputers. Unix made the jump from PDP-7, 11 to DEC Vax, and 680x0 Sun boxes and such.) A Lisp system measuring its heaps and image sizes in hundreds of kilobytes or megabytes simply wouldn't fit into a system measured in tens of kilobytes. People working with Lisp machines in the 80's couldn't get customers (or not mass market customers), because mass market customers didn't want to buy expensive hardware. Only some big companies or governments. Today your GNU Bash may hit a 20 megabyte VM footprint, and you don't even notice, let alone pause to think about how "wrong" that is.