10 ms·

I'm half amused and half concerned for your mental health. There are too many places to start a counter argument. It could start with what MLMs actually are, i

I'm half amused and half concerned for your mental health. There are too many places to start a counter argument. It could start with what MLMs actually are, it could be that many businesses don't care about the talks and use scipy packages, it could be the cause and effect confusion of scipy packages existing and academic users using them--which relates to the Ruby part. But seriously, I hope I'm wrong, but your post comes off as a bit paranoid and crazy.

z9znz 4y ago
His MLM analogy does not fit, but I think the point is that Python got where it is because of luck. If the scientific computing and research community (and plenty of physicists) had known a better language, they would not be using Python now. Maybe it helps that Python was installed by default on many Linux systems, and Ruby was not. Much of the success of Python these days is related to non-CompSci users. And no offense, but many of them are focused entirely on results which have very little concern for code quality, maintainability, or other software engineering concerns. So now we have startups galore who want to be "AI" or "data science", and their PHBs gravitate to Python because Python is the machine learning language. Or so they've heard. Ironically, and perhaps one thing the parent poster was alluding to, most AI/ML/data science companies actually end up doing very little of those and instead just doing normal software development. Maybe they have a small sprinkle of data analysis.
- DigiDigiorno 4y ago
  I agree with everything you say (in fact another post I made on this page deals with "it should be NumPy to Python" because so many people learn the language through some popular library) I agree with your points, but the only counterpoint I will make is that Python was created as a simple scripting language that could utilize lower language code. Basically it's a convenient wrapper for faster c code. So the fact that Python is populated with scientific libraries that are optimized in c is not purely luck. That said, like a lot of things in life, it's the combination of viability and luck that lead to success.
  - mistrial9 4y ago
    to re-state the obvious, as a low-level C programmer by training, Python is exactly "a simple scripting language that could utilize lower language (C-linking) code." I wrote language glue for C libraries long ago, Python fit well and that is what I use it for to this day, decades later. maybe people without the C background do not see that at all?
    - DigiDigiorno 4y ago
      Maybe they do not. It's ironic that many people criticize the speed of python when it (or at least CPython) was originally made to run highly optimized C-linking code. But I also take the Cython route when it's just one to a few functions that need optimization/parallelization... (Did you know you can instantly compile Cython in Jupyter to use with Python?). So I avoid writing anything else unless it's really necessary. (avoided* I haven't done that in a while)
      - z9znz 4y ago
        The speed or lack thereof of Python is not the problem. The problem is language (mis)features. But interestingly, Go is a very simple, straightforward language. It's got many of the same goals that Python had, and it meets those goals quite well. And it is blazingly fast. And it compiles so fast that it might as well be interpreted. And it is statically typed, something that is all the rage again these days and which Python pretends to offer but is really just noise and decoration. I would go so far as to claim that anything built in Python can be built better in one of many other languages, even if you use Numpy or some other Python-specific language. And the way I would meet that challenge would be to isolate the use of the Python library and provide a minimal interface to that, and then call that Python program from another better language. Then I get the utility of the Python library from a language that scales better conceptually and performance-wise.
        rahen 4y ago
        Go is quite a bit cleaner than Python and its concurrency/parallelism primitives can be well suited to scientific workloads. You may want to have a look at Gonum (https://www.gonum.org https://www.gonum.org), and the Go HEP package developed by CERN (https://go-hep.org https://go-hep.org). I was also surprised to see DSP and pretty sophisticated packages, although I never used them: https://awesome-go.com/science-and-data-analysis https://awesome-go.com/science-and-data-analysis And of course Go has Jupyter integration, it's almost like running a script thanks to its fast compilation time.
- oivey 4y ago
  The “luck” Python ran into was that some people came together to write NumPy. The alternatives at the time were Matlab and R. Matlab is not a great general programming language and is expensive. R has esoteric syntax and also isn’t a great general purpose language. This shift didn’t happen so long ago that it can’t be remembered. It certainly didn’t happen because it was installed by default by some Linux distros. For better or worse (and honestly, probably often for better), people writing scientific Python care about solving a particular numerical problem. Code quality often matters less than just getting the right answer. Knowledge of a language or code quality is rarely the hard or important part. Scientists generally spend time learning math and software engineers spend time learning good design practices. It shouldn’t be a great surprise what each group becomes good at. Time is finite.
  - z9znz 4y ago
    > Knowledge of a language or code quality is rarely the hard or important part. That is true. The problem is, that code in Python of questionable quality (but real utility) is now turned into production code; and it is done so by building Python stuff around it. So now the insignificant implementation detail which was the language choice is now driving the entire project. Also, a PhD data scientist/mathematician can get hired for a big salary at a company (especially fintech), and their code will drive critical business decisions. A regular software engineer is mandated to build a structure around that code to make it production worthy. In my experience there is no traction to say, "Great, you've learned how to answer this tough question; now let's implement your solution in a real language."
    - analog31 4y ago
      To me, this seems like the wrong way of doing it. I'm a scientist, and I code in Python, but my code is never directly incorporated into the production code base. (Similar story for the portions of my work involving electronics, mechanics, etc). A decent generalization is that once I solve a problem, and demonstrate a result using Python, the actual amount of code that needs to be understood and translated into the production language is usually a few tens of lines at most. On the production side, the choice of language is just a tiny part of the entire process. They have frameworks, revision control systems, coding standards, review processes, the whole nine yards. Just using a "better" language isn't even an important step towards writing production code. If I wrote in the software department's favored language, they would still have to turn it into production code within their procedures. The fact that a few lines of Python represents hundreds of lines of production code makes it more productive for me to think my way through problems and express the principles underlying the solution to the coders. I see no reason why the tool that's used for discovering a solution has to be the same tool as the one used for putting the solution into production. Laboratory chemists don't use industrial manufacturing processes when trying to make a milligram of a new compound.
- WoahNoun 4y ago
  >If the scientific computing and research community (and plenty of physicists) had known a better language The scientific computing and research community heavily used C/C++ for years/decades after the decline of Fortran. Python came and solved their headaches by abstracting them away.
hlpage 4y ago

z9znz 4y ago

His MLM analogy does not fit, but I think the point is that Python got where it is because of luck. If the scientific computing and research community (and plenty of physicists) had known a better language, they would not be using Python now. Maybe it helps that Python was installed by default on many Linux systems, and Ruby was not. Much of the success of Python these days is related to non-CompSci users. And no offense, but many of them are focused entirely on results which have very little concern for code quality, maintainability, or other software engineering concerns. So now we have startups galore who want to be "AI" or "data science", and their PHBs gravitate to Python because Python is the machine learning language. Or so they've heard. Ironically, and perhaps one thing the parent poster was alluding to, most AI/ML/data science companies actually end up doing very little of those and instead just doing normal software development. Maybe they have a small sprinkle of data analysis.

DigiDigiorno 4y ago
I agree with everything you say (in fact another post I made on this page deals with "it should be NumPy to Python" because so many people learn the language through some popular library) I agree with your points, but the only counterpoint I will make is that Python was created as a simple scripting language that could utilize lower language code. Basically it's a convenient wrapper for faster c code. So the fact that Python is populated with scientific libraries that are optimized in c is not purely luck. That said, like a lot of things in life, it's the combination of viability and luck that lead to success.
- mistrial9 4y ago
  to re-state the obvious, as a low-level C programmer by training, Python is exactly "a simple scripting language that could utilize lower language (C-linking) code." I wrote language glue for C libraries long ago, Python fit well and that is what I use it for to this day, decades later. maybe people without the C background do not see that at all?
  - DigiDigiorno 4y ago
    Maybe they do not. It's ironic that many people criticize the speed of python when it (or at least CPython) was originally made to run highly optimized C-linking code. But I also take the Cython route when it's just one to a few functions that need optimization/parallelization... (Did you know you can instantly compile Cython in Jupyter to use with Python?). So I avoid writing anything else unless it's really necessary. (avoided* I haven't done that in a while)
    - z9znz 4y ago
      The speed or lack thereof of Python is not the problem. The problem is language (mis)features. But interestingly, Go is a very simple, straightforward language. It's got many of the same goals that Python had, and it meets those goals quite well. And it is blazingly fast. And it compiles so fast that it might as well be interpreted. And it is statically typed, something that is all the rage again these days and which Python pretends to offer but is really just noise and decoration. I would go so far as to claim that anything built in Python can be built better in one of many other languages, even if you use Numpy or some other Python-specific language. And the way I would meet that challenge would be to isolate the use of the Python library and provide a minimal interface to that, and then call that Python program from another better language. Then I get the utility of the Python library from a language that scales better conceptually and performance-wise.
      - rahen 4y ago
        Go is quite a bit cleaner than Python and its concurrency/parallelism primitives can be well suited to scientific workloads. You may want to have a look at Gonum (https://www.gonum.org https://www.gonum.org), and the Go HEP package developed by CERN (https://go-hep.org https://go-hep.org). I was also surprised to see DSP and pretty sophisticated packages, although I never used them: https://awesome-go.com/science-and-data-analysis https://awesome-go.com/science-and-data-analysis And of course Go has Jupyter integration, it's almost like running a script thanks to its fast compilation time.
oivey 4y ago
The “luck” Python ran into was that some people came together to write NumPy. The alternatives at the time were Matlab and R. Matlab is not a great general programming language and is expensive. R has esoteric syntax and also isn’t a great general purpose language. This shift didn’t happen so long ago that it can’t be remembered. It certainly didn’t happen because it was installed by default by some Linux distros. For better or worse (and honestly, probably often for better), people writing scientific Python care about solving a particular numerical problem. Code quality often matters less than just getting the right answer. Knowledge of a language or code quality is rarely the hard or important part. Scientists generally spend time learning math and software engineers spend time learning good design practices. It shouldn’t be a great surprise what each group becomes good at. Time is finite.
- z9znz 4y ago
  > Knowledge of a language or code quality is rarely the hard or important part. That is true. The problem is, that code in Python of questionable quality (but real utility) is now turned into production code; and it is done so by building Python stuff around it. So now the insignificant implementation detail which was the language choice is now driving the entire project. Also, a PhD data scientist/mathematician can get hired for a big salary at a company (especially fintech), and their code will drive critical business decisions. A regular software engineer is mandated to build a structure around that code to make it production worthy. In my experience there is no traction to say, "Great, you've learned how to answer this tough question; now let's implement your solution in a real language."
  - analog31 4y ago
    To me, this seems like the wrong way of doing it. I'm a scientist, and I code in Python, but my code is never directly incorporated into the production code base. (Similar story for the portions of my work involving electronics, mechanics, etc). A decent generalization is that once I solve a problem, and demonstrate a result using Python, the actual amount of code that needs to be understood and translated into the production language is usually a few tens of lines at most. On the production side, the choice of language is just a tiny part of the entire process. They have frameworks, revision control systems, coding standards, review processes, the whole nine yards. Just using a "better" language isn't even an important step towards writing production code. If I wrote in the software department's favored language, they would still have to turn it into production code within their procedures. The fact that a few lines of Python represents hundreds of lines of production code makes it more productive for me to think my way through problems and express the principles underlying the solution to the coders. I see no reason why the tool that's used for discovering a solution has to be the same tool as the one used for putting the solution into production. Laboratory chemists don't use industrial manufacturing processes when trying to make a milligram of a new compound.
WoahNoun 4y ago
>If the scientific computing and research community (and plenty of physicists) had known a better language The scientific computing and research community heavily used C/C++ for years/decades after the decline of Fortran. Python came and solved their headaches by abstracting them away.

hlpage 4y ago