From Python to NumPy (2017) • Hacker News Board

Re: From Python to NumPy (2017)

#21

Post by z9znz » Fri, Jun 10, 2022, 4:23 AM UTC

boredemployee wrote: post #13

z9znz wrote: post #8

Numpy is a great thing, and also a terrible thing (because it is built on Python). Python is a terrible language compared to many others, not the least of which is Ruby (and I would include Java, Clojure, Elixir, and even C++ and probably C# and almost certainly F# if I knew them well). To make matters worse, there's a common mentality amongst Pythonistas of being aggressively complacent. A typical response to a ques…

Sorry, that discussion is so overrated and elitist. I'll never understand people complaining about one technology/language/tool that made it possible to dozens of people to join to the - once restrict - small club which was computer science and which is now making it possible to a lot of people to get a job with an easy to learn and less verbose language. One can argue about speed/memory/better languages out there to…

Use any language you like to build a proof of concept.

But one you need to take that POC and build a real product which needs to be supported, extended, and maintained, then you must choose tools which fit that long term need.

Many of use first experienced school in kindergarten. Kindergarten was an important step in our education and socialization. But we didn't refuse to move on to the next level, no matter how much fun it was or how nice our teachers were. Maybe some people felt unsure about leaving their comfort zone, but there's no progress without risk and effort.

Is a university student elitist because they know something a kindergarten kid doesn't? Should they stop trying to promote continued growth through the educational levels?

If you were to use production Python on any decent sized project, and you had also used Ruby (just one example... some other languages can be even more succinct), then you would hate Python.

Re: From Python to NumPy (2017)

#22

Post by WoahNoun » Fri, Jun 10, 2022, 4:25 AM UTC

z9znz wrote: post #9

DigiDigiorno wrote: post #7

Earlier quoted context omitted.

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 pos…

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 off…

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

Re: From Python to NumPy (2017)

#23

Post by z9znz » Fri, Jun 10, 2022, 4:31 AM UTC

boberoni wrote: post #19

boredemployee wrote: post #13

Earlier quoted context omitted.

Sorry, that discussion is so overrated and elitist. I'll never understand people complaining about one technology/language/tool that made it possible to dozens of people to join to the - once restrict - small club which was computer science and which is now making it possible to a lot of people to get a job with an easy to learn and less verbose language. One can argue about speed/memory/better languages out there to…

> Python has a great/dope community Python's community is one of the greatest and worst parts of the language. Python might not be the best language for anything, but it's the second best language for everything. I've dabbled in many programming languages, a lot of which are backed by a single large company or consultancy: - Java (Oracle, at least initially) - TypeScript, C# (Microsoft) - Golang, Dart (Google) - Elix…

> Python's community is one of the greatest and worst parts of the language.

If you come from a Ruby background, and you are now doing Python, you may find yourself on Stackoverflow looking up how to do X idomatically in Python (something you did all the time in Ruby). Or you may ask colleagues who know Python but do not know Ruby.

A common answer from the Pythonista community is, "Why would you ever want to do that?" (or Why would you need that?)

Ternary operators? Who needs that. Ok sure, here, but let's make it awkward. Where did Python get the model to do "x = 1 if y else 2"? But ironically, unlike Ruby where you can say "x = 1 if y", in Python you cannot do that. Oh, but you cannot say "x = 1 if y else return". That's not allowed.

Python has finally, as of 3.10, added a switch statement. This is something that many other languages have had for ages. You should see the contortions people have gone to to approximate a switch statement in Python... https://stackoverflow.com/questions/60208/replacements-for-s...

The Python community may have some good, helpful, and friendly people; but most programming communities have that. That is not a plus for any language, because it should be a given.

Re: From Python to NumPy (2017)

#24

Post by DigiDigiorno » Fri, Jun 10, 2022, 4:37 AM UTC

mistrial9 wrote: post #16

DigiDigiorno wrote: post #11

Earlier quoted context omitted.

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 tha…

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?

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)

Re: From Python to NumPy (2017)

#25

Post by z9znz » Fri, Jun 10, 2022, 4:38 AM UTC

oivey wrote: post #18

z9znz wrote: post #9

Earlier quoted context omitted.

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 off…

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

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

Re: From Python to NumPy (2017)

#26

Post by z9znz » Fri, Jun 10, 2022, 4:45 AM UTC

mistrial9 wrote: post #16

DigiDigiorno wrote: post #11

Earlier quoted context omitted.

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 tha…

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?

My third language was C, after Pascal and Modula 2. And I've built a good bit of production C long ago. (And beside the point, it was not difficult...? Memory management and pointer math is not rocket science. But I digress.)

It seems like the people promoting Python for its ability to interact with C (to outsource time/memory constrained functions) are no familiar with the other uses of Python -- namely to build large systems in object oriented fashions.

A 10 or 100 or even 1000 line "script" in Python is just fine. Read it like a story, let it do the one job it needs to do, and go home.

But scale up to 10000 or 100000 lines, and you will certainly be forced to go OOP. After all, most Python modules use OO classes in cases where a module of functions would suffice... Now you are in the realm where Python is comparatively very poorly suited for the job.

It's a frog-in-the-pot boiling situation. It started out innocently enough with the frog choosing the nicest small body of water nearby, but now the frog is in pain and dying and unable to understand how they got into that situation.

Re: From Python to NumPy (2017)

#27

Post by z9znz » Fri, Jun 10, 2022, 4:50 AM UTC

DigiDigiorno wrote: post #24

mistrial9 wrote: post #16

Earlier quoted context omitted.

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?

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 necessa…

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.

Re: From Python to NumPy (2017)

#28

Post by z9znz » Fri, Jun 10, 2022, 4:53 AM UTC

dragonwriter wrote: post #15

z9znz wrote: post #10

Earlier quoted context omitted.

I'm guessing the parent poster really meant something like "hyped snake oil". There is absolutely nothing about Python which makes it especially suited to scientific programming or any other kind of programming. In fact, it is poorly designed for most software engineering goals, short of just simple one-file, few line scripts. But those could just as well have been written in many other languages. Python just happene…

> There is absolutely nothing about Python which makes it especially suited to scientific programming or any other kind of programming. The amount of anger people have that things that, in fact, determine suitability for various applications are not the things which ought to do so in their own mental models of the world is... interesting.

If I hand you a dull butter knife and some loose, rusty pliers and ask you to fix a car engine, you should be angry. Of course, if all you've ever known is sub-par tools, then you won't see a problem.

This is a pointless conversation. You cannot know what you don't know. https://en.wiktionary.org/wiki/Blub_paradox

Re: From Python to NumPy (2017)

#29

Post by analog31 » Fri, Jun 10, 2022, 5:01 AM UTC

z9znz wrote: post #25

oivey wrote: post #18

Earlier quoted context omitted.

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

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

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.

Re: From Python to NumPy (2017)

#30

Post by z9znz » Fri, Jun 10, 2022, 5:02 AM UTC

DigiDigiorno wrote: post #20

z9znz wrote: post #14

Earlier quoted context omitted.

I use Python all day every day. It's horrible compared to many other languages I have used. There are many versions of hype promoted for Python. Coal powered steam locomotives were great in their day, before there were better alternatives. But we don't irrationally hold the mentality that there is nothing better and why would you need anything else anyway? Tell me any library which can only be built for Python? Tell…

Anyone who is "infatuated" with ANY tool is likely ignorant of alternatives. That said, I think python is a very convenient wrapper for lower language utilizing scipy libraries. I also think it is great for quick prototyping. (It's been a couple years, but I even prototyped PySide Qt stuff in ipython notebooks, now Jupyter notebooks, back in the day). Now, simply the popularity (perhaps created by luck), led to a hug…

I guess that's the problem. Python is just fine for many narrow tasks. But the people who use it, or the people who manage teams who use it, don't know how important it is to consider proper tooling when it comes time to turn the small thing into a big thing.

There's nothing wrong with using Python and its great libraries for some purposes. But none of those cases mean that Python is a good language. And frankly, the better the library is, the less Python language features you would use directly. The powerful libraries hide the failures of the parent language.

But as soon as you need to build something around your solution, unless you have another library which does the new thing you need (and encapsulates your solution neatly), then you will end up using real Python, on a larger scale. Then you will start disliking it.