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

Homogenization of scientific computing – Python is eating other languages’ lunch

r-bloggers.com

Post reply on HN
Print view View original

101–110 of 184 posts

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#101

Post by Aloisius »

bjourne wrote: post #91
simias wrote: post #50

Earlier quoted context omitted.

> Getting the indentation right should be the least of your worries if you have a good editor I never understood that. The whole problem for me is that the indentation being the only thing denoting blocks the editor can't know for sure how things should be indented, since it's not simply cosmetic. I haven't written a whole lot of Python but how do you even refactor python code? In C I can just copy paste a block of c…

Indeed that is a problem when you are copy-pasting huge blocks of code. In deeply nested code it can be difficult to determine whether the nesting should be say 28 or 32 spaces. In practice, most people shy away from writing such code because to many levels of nesting is hard to follow. People also prefer to write atomic 5-15 line functions in which keeping track of the nesting levels is trivial. Many C# and Java-hea…

Many C# and Java-heads complain that Python lacks support for auto-completion. Which is true

Isn't that an IDE issue and not a language issue? I have no problem with the auto-completion in ipython for instance, though even ipython notebook is only useful for writing simple amounts of code. PyDev though works well too for larger projects albeit a bit sluggishly.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#102

Post by dkersten »

julienchastang wrote: post #100

I mostly agree with this article, but we are not there yet. I work with scientists who love the IPython Notebook technology. Some claim the IP[y]: Notebook to be the best thing since the Mosaic web browser and the most important development in scientific computing in a decade. I tend to agree, it is a revolutionary technology and the idea of executable papers is tantalizing. But there are also big problems. In partic…

Re: setting up environment, I love Anaconda for that reason. Wget the installer, run it, all done - you have a fully featured Python environment ready to go, including Numpy, Scipy, Scikit-learn and much more. Running IPython and the IPython Notebook is then trivial.

If you need anything else, you can use their own Conda package manager, or you can just use pip as usual.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#103

Post by gaius »

fit2rule wrote: post #33

I find Lua more interesting than Python. It has all the simplicity, all of the power, none of the indentation, and is quite a nice portable tool. That said, I do wonder at times what it is about Lua that makes so many people not-interested in it, when .. from my naive point of view .. its an almost perfect language for rapid development. I don't have that feeling about Python, quite so much ..

For me, Tcl does what Lua does, but much better. In fact given Tcl, it's hard to see why Lua was created.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#104

Post by dkersten »

JonSkeptic wrote: post #23

I know that I use python because of how easy it is to code. I can focus wholly, totally on the logic of my code without ever worrying about if I misplaced a semi-colon or left out some weird punctuation. Python frees me to code and not worry about things that get in the way of coding. That's why it's eating other language's lunches, the freedom is almost intoxicating.

without ever worrying about if I misplaced a semi-colon or left out some weird punctuation

I've seen enough code like [(foo[-1:self._bar:2]%(a,b),) for foo in quux] to not really believe that.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#105

Post by drkevorkian »

benhoyt wrote: post #95
tokipin wrote: post #86

Earlier quoted context omitted.

python is a deliberately-straightforward language. i don't see how anyone couldn't become highly proficient in it after writing one or two scripts

Deliberately-straightforward -- agreed. But "highly proficient" after writing one or two scripts? That's quite a stretch. For instance, one of the questions I give in phone screens is for the candidate to write a program to count the number of occurrences of unique words in a text file. The "after writing one or two Python scripts" approach is something like this: counts = {} f = open('test.txt') lines = f.read().spl…

  for word, count in Counter(open('test.txt').read().lower().split()).most_common():
      print word, count

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#106

Post by dkersten »

gaius wrote: post #103
fit2rule wrote: post #33

I find Lua more interesting than Python. It has all the simplicity, all of the power, none of the indentation, and is quite a nice portable tool. That said, I do wonder at times what it is about Lua that makes so many people not-interested in it, when .. from my naive point of view .. its an almost perfect language for rapid development. I don't have that feeling about Python, quite so much ..

For me, Tcl does what Lua does, but much better. In fact given Tcl, it's hard to see why Lua was created.

given Tcl, it's hard to see why Lua was created

Because:

    From 1977 until 1992, Brazil had a policy of strong trade barriers (called a market reserve) for computer hardware and software. In that atmosphere, Tecgraf's clients could not afford, either politically or financially, to buy customized software from abroad. Those reasons led Tecgraf to implement the basic tools it needed from scratch.
https://en.wikipedia.org/wiki/Lua_(programming_language)#His...

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#107

Post by bnolsen »

yohanatan wrote: post #97
benhoyt wrote: post #95

Earlier quoted context omitted.

Deliberately-straightforward -- agreed. But "highly proficient" after writing one or two scripts? That's quite a stretch. For instance, one of the questions I give in phone screens is for the candidate to write a program to count the number of occurrences of unique words in a text file. The "after writing one or two Python scripts" approach is something like this: counts = {} f = open('test.txt') lines = f.read().spl…

Actually that's not 'highly proficient'. This is: def read_words(words_file): return [word for line in open(words_file, 'r') for word in line.split()] len(set(read_words('test.txt')))

smashing tons of crap together isn't necessarily "highly proficient". In some cases it makes things harder to read and/or harder to maintain and many times certainly harder to edit.

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#108

Post by agumonkey »

yohanatan wrote: post #97
benhoyt wrote: post #95

Earlier quoted context omitted.

Deliberately-straightforward -- agreed. But "highly proficient" after writing one or two scripts? That's quite a stretch. For instance, one of the questions I give in phone screens is for the candidate to write a program to count the number of occurrences of unique words in a text file. The "after writing one or two Python scripts" approach is something like this: counts = {} f = open('test.txt') lines = f.read().spl…

Actually that's not 'highly proficient'. This is: def read_words(words_file): return [word for line in open(words_file, 'r') for word in line.split()] len(set(read_words('test.txt')))

Don't know when set comprehensions and resource handlers were introduced so that might not run everywhere

    def read_words(words_file):
        with open(words_file, 'r') as f:
            return {word for line in f for word in line.split()}

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#109

Post by dded »

StefanKarpinski wrote: post #19
hharrison wrote: post #12

Earlier quoted context omitted.

Yeah, I'm a Python convert like the author, though coming mostly from Matlab rather than R, and everyone in my field reacts with surprise when I tell them I prefer Python. They're open-minded, and I'm hoping to convert a few myself, but I don't think the mass migration has happened yet. Regarding your second comment- you're correct of course, but what makes this a "blind spot"? After all, if the user is writing code…

I call it a "bizarre blind spot" because it seems like there's a silent consensus to never talk about this basic fact. It's a bit surreal attending SciPy and hearing all of these people talking about scientific computing in Python when almost every single person in the room spends the vast majority of their time and energy writing C code. I disagree that the separation between implementation and user-land that's enfo…

Thanks for this reply. I thought the "bizarre blind spot" comment was some sort of (absurd) thought that numpy users were unaware that C was being used under the hood.

> it eventually will catch up and surpass two-language systems for scientific computing.

Assuming that, like hardware engineers, scientists have a fair bit of general-purpose scripting to do, Julia will itself be part of a different kind of two-language solution unless it is up-to-snuff w.r.t. said general-purpose scripting. This implies libraries and good interaction with OS utilities. Any thoughts on whether or not this will be an issue with Julia?

Re: Homogenization of scientific computing – Python is eating other languages’ lunch

#110

Post by 0x001E84EE »

baldfat wrote: post #93
plg wrote: post #90

Python so slow!!

What does this have to do with Scientific Computing? I don't think there is anyone would say that in the realm of Scientific Computing there is a problem with slow in python.

I would argue that many Scientific Computing problems involve large amounts of data and/or computation.
Post reply on HN