3 ms·

I disagree with that hot take because it ignores the momentum around pandas, scipy and other key libraries that were just easier to use in Python than (for inst

by rcarmo 4y ago

I disagree with that hot take because it ignores the momentum around pandas, scipy and other key libraries that were just easier to use in Python than (for instance) R, and the network effects. In the years I was doing active ML and data science/engineering work, I met exactly _one_ team that was using Julia, and only came across R when dealing with academia. Mainstream/corporate customers never even considered any other alternative (other than MatLab, which had an established base in manufacturing, oil, gas, etc.).

MonkeyMalarky 4y ago
Not just the directly ML adjacent libraries but all the other tertiary libraries too. Having a single language codebase/pipeline that goes from scraping the web to collect data (using scrapy!), to data cleaning, model training and then prediction serving with flask or fastapi is sort of magical.
vegabook 4y ago
Personally I think Pandas gets too much credit, credit which really belongs with Numpy, and which was probably the reason that Pandas was built on it, rather than say, Ruby, which in the late 2000s was a contender. This is especially true in the world of ML. Pandas is incredibly convenient (clone as it started out being, after all, of R's eponymous DataFrame, which is also incredibly convenient for feature engineering), but it's Numpy that does the heavy lifting.
freilanzer 4y ago
That's not the point here though: what if another language had Pythons momentum?
peatmoss 4y ago
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.
disgruntledphd2 4y ago
> pandas, scipy and other key libraries that were just easier to use in Python than (for instance) R Depends on what you're doing. dplyr/ggplot2 are so so much better than pandas but sklearn is pretty rocking (and better than caret). R the language is pretty annoying relative to python, but I'd actually argue that pandas is the worst of both R and Python, in terms of the API at least.

by rcarmo 4y ago

MonkeyMalarky 4y ago

Not just the directly ML adjacent libraries but all the other tertiary libraries too. Having a single language codebase/pipeline that goes from scraping the web to collect data (using scrapy!), to data cleaning, model training and then prediction serving with flask or fastapi is sort of magical.

vegabook 4y ago

Personally I think Pandas gets too much credit, credit which really belongs with Numpy, and which was probably the reason that Pandas was built on it, rather than say, Ruby, which in the late 2000s was a contender. This is especially true in the world of ML. Pandas is incredibly convenient (clone as it started out being, after all, of R's eponymous DataFrame, which is also incredibly convenient for feature engineering), but it's Numpy that does the heavy lifting.

freilanzer 4y ago

That's not the point here though: what if another language had Pythons momentum?

peatmoss 4y ago

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.

disgruntledphd2 4y ago

> pandas, scipy and other key libraries that were just easier to use in Python than (for instance) R Depends on what you're doing. dplyr/ggplot2 are so so much better than pandas but sklearn is pretty rocking (and better than caret). R the language is pretty annoying relative to python, but I'd actually argue that pandas is the worst of both R and Python, in terms of the API at least.