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

51–60 of 78 posts

Re: From Python to NumPy (2017)

#51

Post by workingon »

pbronez wrote: post #35
z9znz wrote: post #32

Earlier quoted context omitted.

If you run a company, then you might make better choices (or at least allow for proper discovery of what approach to take to building a large system). But there seems to be an accepted rule that "if you're doing data science, you are a Python shop". And if you are trying to pitch a data science company to investors, they know Python for data science. New companies start all the time using a technology because "that's…

For machine learning companies, Julia is probably the dark horse language that could give you a competitive advantage. Like always, the problem with using something more niche is the ecosystem strength. You need to train people more, build more tooling yourself. Still, there is performance to be had if you work for it.

No post body was provided.

Re: From Python to NumPy (2017)

#52

Post by rahen »

z9znz wrote: post #27
DigiDigiorno wrote: post #24

Earlier quoted context omitted.

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…

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), and the Go HEP package developed by CERN (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

And of course Go has Jupyter integration, it's almost like running a script thanks to its fast compilation time.

Re: From Python to NumPy (2017)

#53

Post by ChrisRackauckas »

workingon wrote: post #51
pbronez wrote: post #35

Earlier quoted context omitted.

For machine learning companies, Julia is probably the dark horse language that could give you a competitive advantage. Like always, the problem with using something more niche is the ecosystem strength. You need to train people more, build more tooling yourself. Still, there is performance to be had if you work for it.

Quoted post unavailable.

Please post a concrete example of one that you have ran into.

Re: From Python to NumPy (2017)

#54

Post by eesmith »

z9znz wrote: post #14
DigiDigiorno wrote: post #12

Earlier quoted context omitted.

Referring to Python hype as "snake oil" is hilarious; I recommend anyone arguing the underlying thought use it.

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…

> Tell me any library which can only be built for Python?

Are you really making the "every programming language is Turing-computable" argument?

All your talk of features is missing an important point - Python is one of the few languages designed with insight from how to develop a programming language for non-programmers. In Python's case, experience drawn from ABC.

These are people for whom "public class java { public static void" is a barrier to entry.

For whom diagnosing segfaults is arcane knowledge.

And for whom hygienic macros sounds like a bathroom product.

I like Python because it's a language that my colleagues - most of whom are not software developers but who do some programming for their research - can productively use. Even with all the complexity of modern Python.

So no, there are zero features in Python which don't exist in other programming languages.

And it doesn't matter.

What better options do you suggest to a grad student in chemistry, biology, or physics?

Re: From Python to NumPy (2017)

#55

Post by dragonwriter »

z9znz wrote: post #28
dragonwriter wrote: post #15

Earlier quoted context omitted.

> 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

> Of course, if all you've ever known is sub-par tools, then you won't see a problem.

Yeah, sure. What makes you think that I haven't used a wide variety of programming languages covering every paradigm from unstructured imperative to procedural to functional (pure and impure) to OOP to relational to logic to...?

When I am amused at the anger people have about their idealized mental model of what should matter not being what actual does matter most to practical utility, I’m not speaking from ignorance of the different features of programming languages and the theoretical and practical benefits they bring. I am speaking from four decades of programming and understanding all that, as well as the human and social side of the activity.

Re: From Python to NumPy (2017)

#57

Post by mjburgess »

kwertzzz wrote: post #50

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…

Blame python for being off in the weeds adding syntax for software engineering (eg., walrus operator), and not for data analysis.

Re: From Python to NumPy (2017)

#59

Post by SpectralTheory »

rahimnathwani wrote: post #17
dang wrote: post #4

Discussed at the time: From Python to Numpy - https://news.ycombinator.com/item?id=13355034 - Jan 2017 (48 comments)

Thanks. I clicked on 'past' immediately after posting, but all I saw were Algolia search results for the keywords in the title. If I'd seen it had been posted before, I probably would have deleted my post. ISTR 'past' used to show matches for the URL, and not the title. Perhaps I'm mistaken.

I wouldn't treat these as warnings about posting (you're allowed to repost after some time). These are more about sharing relevant older conversations for the interested.

Re: From Python to NumPy (2017)

#60

Post by paddy_m »

z9znz wrote: post #10
l33t2328 wrote: post #6

Earlier quoted context omitted.

How is prothletising a free tool an MLM scheme?

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.

Compared to Java and JS there is. The lack of operator overloading would make numpy matrix manipulations absolutely painful in those languages. It's just a chance that numpy wasn't built on top of ruby.

Post reply on HN