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

111–120 of 184 posts

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

#111

Post by pwang »

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')))

len(set(open("test.txt").read().split()))

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

#112

Post by [deleted] »

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')))

[deleted]

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

#113

Post by julienchastang »

dkersten wrote: post #102
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.

@dkersten What happens in the scenario where you have other Python distributions on your system? Does Anaconda keep things nicely compartmentalized like a virtualenv?

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

#114

Post by frik »

xfax wrote: post #78
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 ..

I have no exposure to Lua. How is the library support for scientific computing?

Scientific Computing with Lua: http://www.scilua.org/

Scientific libraries for Lua: http://stackoverflow.com/questions/388172/scientific-librari...

"A Primer of Scientific Computing in Lua" (book chapter in "Lua Gems" book), source code: http://code.google.com/p/luagems-numeric/downloads/list

LuaTex, an extended version of pdfTeX using Lua as an embedded scripting language: http://www.luatex.org/

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

#115

Post by jamesjporter »

dded wrote: post #109
StefanKarpinski wrote: post #19

Earlier quoted context omitted.

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

Julia is designed to be a good general purpose language. There are already a bunch of database drivers; a simple web framework, etc., etc. http://docs.julialang.org/en/release-0.2/packages/packagelis...

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

#116

Post by jamesjporter »

michaelochurch wrote: post #75
Xcelerate wrote: post #65

I do scientific computing, and Python is one language I never actually got around to learning for some reason. However, as a long-time hobby, I do have an interest in programming languages so I like exploring things like Haskell, Clojure, Lisp, etc. One language I'm really excited about for scientific computing though is Julia. From a language-design perspective, it's beautiful. It was actually thought out rather tha…

What are your thoughts on Clojure's suitability as a go-to language for scientific computing (except in lower-level, high-performance scenarios that might recommend Julia)? I think it has serious potential in this field. It's not there yet, but it's getting there, and the core.matrix standardization helps a lot.

I agree with collyw; Lisp is too much for most scientists, who just care about getting their research done and can't be bother to learn all this weird FP/paren stuff [1]. Supplying an obvious, familiar syntax that looks like math written on paper for, e.g., matrix operations, is critical. This is actually one of the core tensions in Julia development imho: balancing having a sane, well designed language (from a programmer's perspective) vs. having a tool that allows scientists to quickly and easily crank out results.

[1]: Note; I am not insinuating that Lisp is bad, I like it personally. Just relaying the response you will get from most practicing scientists who are not trained as programmers.

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

#117

Post by pyre »

gvb wrote: post #47
pyre wrote: post #32

Earlier quoted context omitted.

Getting the indentation right should be the least of your worries if you have a good editor (and don't do something like mix spaces and tabs, which I think everyone is in general agreement with across all languages). When was the last time that you manually typed out 4 (or 2, or 8, etc) spaces to indent a line of code vs. just hitting tab and letting the editor handle inserting those spaces (or the editor automatical…

You are being kind or your coworker isn't that bad - in your example the whitespace is consistent. My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. Sloppily formatted code is Edward Bear code. All the bumping makes it hard to think about how it works (or, more often, why it doesn't work). "Here is Edward Bear, coming downstairs now,…

> My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels.

This is usually due to:

1) Lack of a consistent style guide.

2) Lack of style guide enforcement.

3) A language where white space doesn't matter.

If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or would run but not work correctly) or it would make code maintenance a nightmare. Yet there are plenty of Python shops out there, and we don't hear horror stories of Python white space maintenance nightmares. Either the Python community is doing a good job of hiding these issues, or they really aren't issues in practice.

Of the people I've talked to in-person about Python semantic white-space, the common threads are either:

1) It's different than what I'm used to.

2) It's cramping my style. My code is art, and restricting how I can structure my code is an affront to my very being.

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

#118

Post by jessaustin »

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')))

GP asked for counts, not uniques.

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

#120

Post by jessaustin »

pyre wrote: post #117
gvb wrote: post #47

Earlier quoted context omitted.

You are being kind or your coworker isn't that bad - in your example the whitespace is consistent. My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. Sloppily formatted code is Edward Bear code. All the bumping makes it hard to think about how it works (or, more often, why it doesn't work). "Here is Edward Bear, coming downstairs now,…

> My experience is that the whitespace is totally arbitrary: totally inconsistently placed 0 - n spaces with random indentation levels. This is usually due to: 1) Lack of a consistent style guide. 2) Lack of style guide enforcement. 3) A language where white space doesn't matter. If you think about this critically though, these random indentation changes would either break all of the code (e.g. it wouldn't run, or wo…

I guess I'm in a third camp:

3) Python's semantic whitespace is so wonderful I'm baffled that most other programming languages don't have it. It's like they're coding with one eye shut: why not do this wonderful thing that makes everything easier?

Post reply on HN