Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Python to NumPy (2017)

labri.fr

Post reply on HN
Print view View original

41–50 of 78 posts

Re: From Python to NumPy (2017)

#41

Post by cycomanic »

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…

It's quite funny how you and some others here are saying python got into it's place by pure luck and being installed by default on linux systems.

Then you turn around and mention Ruby. I recall that there was a lot of hype around it for quite a while, largely due to Ruby on Rails (certainly outhyping Python), and it's popularity in terms of usage was very similar to Python. However, that did not last, so why is that? Are you saying Python "hyping" and default installation only happened after ~2011 (where Ruby really started to decline compared to Python)?

I would argue the success of Python is largely due to people building some packages like numpy and scipy in Python, because they sort it was the best tool for the job. Then came the ML wave and Python due to that ecosystem was ideally placed as a language that was easy to use for ML researchers. That you mention C++ even in that comparison shows that you do not understand why people use Python. I can tell you if I had to get my graduate students to use C++ for their analysis and lab automation tasks, we'd still be graphing by hand.

Re: From Python to NumPy (2017)

#42

Post by pbourke »

z9znz wrote: post #33
nemothekid wrote: post #31

Earlier quoted context omitted.

I'm not a Pythonista by any means, but these complaints are banal. Ternary operators? Plenty of new popular languages don't have a ternery operator (Go, Rust, Elixir, Kotlin, Nim). My list of python gripes are long, but language constructs are not on the list.

The point is about inconsistency. You can say "x = 1 if expr else 2", but you cannot say "x = 1 if expr". You do a two line if expr: x = 1 You cannot say "x = 1 if expr else return". [1] is a list with one item, 1. {1} is a set with one item, 1. (1) is a number, 1, with pointless parenthesis. Perhaps you mean (1,), a tuple containing only one value. Or how about mutable default values in function paramters? That make…

These are pointless nitpicks. Every language has things like this. In 4 years of using Python in anger I’ve never written a line of code that could be improved by the features you list.

Re: From Python to NumPy (2017)

#43

Post by pbourke »

z9znz wrote: post #21
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…

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

It truly does depend on what you’re building, in which organization and with whom you’re doing it.

If you’re building a production system with a small, stable team, and Python is a good fit for the work, then there is no reason not to use it.

If you’re doing programming in the large with a large and constantly changing team, then you’d be wise to pick a statically typed language that many people know (basically C# or Java)

Your education example is off base. Python is not a more basic form of programming that one passes through on the way to enlightenment. It’s hand screwdrivers vs hammer drills or diesel pickups vs electric sedans. Different tools for different contexts.

Re: From Python to NumPy (2017)

#44

Post by kaba0 »

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…

Paul Graham's essay is pretty bad, I really don't see any reason to cite it as he himself is pretty much at the "wrong" end of the blubness spectrum, as LISPs are not "God's language", modern PL research has plenty of areas not applicable to them in the general case (and no, just because you have macros and in theory can implement everything doesn't make it still the same language). It's almost like languages have different tradeoffs, and there is no one axis to place them on.

Re: From Python to NumPy (2017)

#45

Post by kaba0 »

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…

Java is one of the few languages that actually has a specification and multiple, very different implementations. So I don't believe it is fair to call out it as being backed by a single company (even though in practise Oracle is indeed the one doing the most work on the platform, and they are doing a spectacular work at that). Even if Oracle would disappear tomorrow, Java has enough usage by many huge companies that the platform wouldn't even skip a beat.

Re: From Python to NumPy (2017)

#46

Post by dalke »

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…

Yes, it was some luck ... and a lot of hard work. But it wasn't only NumPy that helped.

I was around in the 1990s when Python started making waves in the scientific computing and research community. Python wasn't installed by default (we mostly used IRIX back then).

Python was excellent for "steering" low-level computations, to use the buzzword at the time.

That is, if you had a large body of existing C, Fortran, whatever code, you could turn them into Python extensions, let Python glue the components together, and use a Python program/script to organize the high-level data- and control-flow.

Swig was a popular tool to help automate that process. Swig 1.0 had support for Tcl, Perl, Guile and Python, back in 1996.

I used Swig to interface to an existing cheminformatics toolkit, and published my experience at https://www.drdobbs.com/cpp/making-c-extensions-more-pythoni... . Python made it very easy to convert the implicit object model of the underlying C toolkit into an explicit OO model in Python. Python's reference-counted garbage collection was also a good fit to the C library.

Together these helped simplify scientific research work quite a bit.

And that's without NumPy.

Even now I do a lot of non-numerical scientific software development, and rarely have need for NumPy. While I often use Python to steer components written in C or C++.

Re: From Python to NumPy (2017)

#47

Post by qsort »

cycomanic wrote: post #41
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…

It's quite funny how you and some others here are saying python got into it's place by pure luck and being installed by default on linux systems. Then you turn around and mention Ruby. I recall that there was a lot of hype around it for quite a while, largely due to Ruby on Rails (certainly outhyping Python), and it's popularity in terms of usage was very similar to Python. However, that did not last, so why is that?…

Luck no, path-dependency yes.

Numpy is fantastic and so is scipy, but there's no inherent reason why they couldn't have been "numruby" or "numlua".

With that said, I agree with you that your parent's thesis isn't really operative, Python and Ruby are almost exactly the same technology, therefore the decision on which one to use depends on the available ecosystem. Everything else is effectively rounding error.

Re: From Python to NumPy (2017)

#48

Post by hlpage »

DigiDigiorno wrote: post #7
dhgaiK wrote: post #5

Quoted post unavailable.

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…

No post body was provided.

Re: From Python to NumPy (2017)

#49

Post by _dain_ »

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…

>excepting the practical capabilities afforded by libraries like Numpy which could just as well have been build for other languages

So it's bad, except for all of the practical things you can do with it. And other languages could have had something like Numpy ... but didn't, for some reason. Not really seeing why this makes Python bad.

Re: From Python to NumPy (2017)

#50

Post by kwertzzz »

I think the readability issue of vectorized numpy if often ignored (while readability is one of the main strength of python in my opinion). I could not resists to write the example of section 2.2 in Julia:

     using Random, BenchmarkTools
     seq = rand(0:2,10_000); sub = rand(0:2,4);
     # translation of the "readable" but slow python code 
     function_1(seq, sub) = [i for i in 1:(length(seq)-length(sub)) if view(seq,i:i+length(sub)-1) == sub];
     @btime function_1(seq, sub);
     #  93.858 μs (5 allocations: 1.98 KiB)
Which is more than twice as fast as the vectorized (and quite unreadable) python

     %timeit function_2(seq, sub) 
     215 µs ± 1.94 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)
Having a JIT (like julia, numba...) has really a bit potential to improve code readability and reduce the need of vectorized numpy operations. In some cases, it can even be faster due to be better memory utilization and by computing more directly what you need.
Post reply on HN