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

151–160 of 184 posts

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

#151

Post by StefanKarpinski »

jofer wrote: post #49
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…

> You can use NumPy until the cows come home and you will be no more qualified to contribute to its internals than you were when you started. Just for whatever it's worth, as an occasional contributor to numpy who is an absolutely terrible C programmer, there's a _lot_ you can contribute with pure python. Yes, the core of the functionality is in C, but most of the user-facing functionality isn't. That having been sai…

:-)

I completely agree that Julia and SciPy are complementary rather than competing. I've attended the SciPy conference for several years and it's great – I love the Python and SciPy communities. It's definitely crucial to both be able to easily call existing C and Fortran libraries and write code in the high-level language that's as fast as it would have been in C. You don't want to reimplement things like BLAS, LAPACK and FFTW – but you do want to be able to implement new libraries without coding in Fortran or C, and more importantly, be able to write them in a very generic, reusable fashion.

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

#152

Post by benhoyt »

Goladus wrote: post #146
drkevorkian wrote: post #105

Earlier quoted context omitted.

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

I like this one. Though I would do it like this to keep the lines under 80 characters: words=open('test.txt').read().lower().split() for word, count in Counter(words).most_common(): print word, count (edited per child comment)

Yeah, those are nice -- and may actually be more efficient on smaller files, as you're only doing the lower() once on a big string. However, for big files you don't necessarily want to read the whole thing in at once.

One nitpick: it's Pythonic (I think) to just name the list of words "words" rather than "word_list".

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

#153

Post by chocolate_ »

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…

How does this type of question go during a phone screen? Does the candidate send the code to you afterward?

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

#154

Post by Goladus »

area51org wrote: post #30
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.

It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic.

It's ironic that you say that, given that if you don't get the whitespace correct, you'll have a syntax error. That's one of the big reason Python rubs me the wrong way: white space is semantic.

Not to pile on but this is exactly backwards. The whitespace saves keystrokes and errors because it's giving a semantic meaning to something that programmers put in their code anyway.

Now that I've actually written some code in ruby, I can't comprehend how rubyists aren't driven insane by the 'end' tokens. I'm sure this is a newbie mistake but on multiple occasions I've written something like this:

    def foo(x)
      if x > 5
        puts x
      else
        puts 5
    end

    foo(7)
    foo(3)
Any experienced ruby programmers should see the error pretty quickly. But it LOOKS pretty good. Here is the error you get:

    test.rb:9: syntax error, unexpected $end, expecting kEND
What's on line 9? That's just the end of the file. Nowhere near where the syntax error actually is. In this trivial example, tab-checking the indentation using my editor will reveal the error. But this is a trivial example. In more substantial code this technique is not nearly as effective. In erb templates its harder still.

That never happened to me in python, even as a newbie. If I forget a colon I almost always know instantly because the editor will try to indent my code dramatically wrong. And if I inadvertently delete the colon at a later time without updating the indentation (this happens a lot) I get an instant syntax error that points me right at the line where the colon is missing. It's an error you can fix in your sleep. You don't forget end tokens because there are no end tokens to forget. The block ends when the indentation level decreases.

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

#155

Post by tokipin »

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…

that first version is hilarious. i'd consider it hideous at any proficiency level in any language :D

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

#156

Post by Goladus »

simias wrote: post #70
hharrison wrote: post #56

Earlier quoted context omitted.

Any good editor should be able to figure out the indents when pasting. I'm not an emacs user, but I'd be surprised if there wasn't a plugin with smart python pasting.

My point is that it's not always possible for the editor to know what the indentation is supposed to be because it can't know what the code is supposed to do. Suppose you have code like this: [...] if a: b c [...] And then you paste some snippet you got from somewhere else between b and c: [...] if a: b pasted_snippet c [...] The editor cannot know how to indent that properly. It's not a problem in most other languag…

The editor cannot know how to indent that properly. It's not a problem in most other languages.

It will have a pretty good idea. If you paste the snippet, then hit 'tab', odds are high that a good editor (I use emacs python-mode) will Do The Right Thing on the first try, although sometimes you'll have to hit tab again or backspace a couple of times to get the right indent level.

Occasionally I need to use a keyboard macro to fix the indent after a paste, but this is very easy to do and doesn't happen to often, really. I'm sure by now with python's popularity there are more advanced indentation management tools but I still just use emacs keyboard macros.

It's a very small price to pay for the huge benefits of semantic whitespace.

Generally the worst case scenario for copy/paste is that I'm using emacs in a terminal window and I forget to switch to fundamental-mode before pasting. Because the terminal is handling the paste, not emacs, python-mode treats it all as if it had been entered one line at a time and auto-indents everything after a colon, then pasting in lines that already have indentation and the result is a complete mess. (but then I just undo it all and re-paste it the right way) GUI emacs doesn't have this problem.

The worst case scenario I can think of for semantic whitespace (outside of copy/paste) is accidentally changing indent level of a piece of code without realizing it and a syntax error doesn't result, meaning there's now a logic flaw in your program you don't know about. Python is more susceptible to that than sort of regression error than most languages. That said, usually that sort of mistake WILL cause a syntax error and be easily fixed.

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

#157

Post by Goladus »

simias wrote: post #66
pyre wrote: post #57

Earlier quoted context omitted.

> If refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions. That is just one of the many issues that can come up when refactoring large sections of code, and is one reason that people write tests. For people to point it out as the entire reason that they can't use Python seems to be making a mountain out of a mole hill. For example, I don't like that…

I'm not making a mountain out of a molehill but I don't understand why the python crowd refuse to acknowledge that having significant whitespace does cause some issues and the benefits are completely subjective. Sure unit tests will catch the error but in most other languages the error wouldn't have been introduced in the first place . I think in the end the problem is that I've been writing in C-style languages a lo…

I'm not making a mountain out of a molehill but I don't understand why the python crowd refuse to acknowledge that having significant whitespace does cause some issues and the benefits are completely subjective.

Here's what you wrote:

That's one of the big reason Python rubs me the wrong way: white space is semantic.

Defending python against a vague accusation like that is most certainly not "refusing to acknowledge that having significant whitespace does cause some issues"

that said, the benefits are not completely subjective. Whether you prefer the benefits or not is somewhat subjective, but the benefits can be clearly described. Specifically: you don't need braces or begin-end tags for code blocks. Correct code will always be indented based on the same concrete rules. Code can be moved from one block to another just by changing the indentation. Those are objective, not subjective traits.

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

#158

Post by Goladus »

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…

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.

To be fair, there are quite a few common cases where Python's syntax is rather inelegant. The need to break out if-then statements into multiple lines, the need for explicit 'return' statements which also have to go on their own line. These things are only indirectly related to whitespace but do sometimes put a lower bound on expressiveness.

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

#159

Post by Goladus »

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

the parser is usually really good at spotting those errors and once they've been pointed out are trivial to correct.

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

#160

Post by pyre »

Goladus wrote: post #158
pyre wrote: post #117

Earlier quoted context omitted.

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

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. To be fair, there are quite a few common cases where Python's syntax is rather inelegant. The need to break out if-then statements into multiple lines, the need for explicit 'return' statements which also have to go on their own line. These things are only indirectly related to whitespace but do some…

> To be fair, there are quite a few common cases where Python's syntax is rather inelegant

Now we're stepping out of the realm of "semantic white space" though. The people I've known to get (literally) red in the face over Python haven't actually used the language and can't do much more than regurgitate stuff like, "but white space!"

> The need to break out if-then statements into multiple lines, the need for explicit 'return' statements which also have to go on their own line.

Unless I'm missing something those are poor examples of the limits of semantic white space:

  % python
  >>> def function():
  ...   if True: return False
  ...
  >>> function()
  False
  >>> def function():
  ...   if False: return True
  ...   else: return False
  ...
  >>> function()
  False
Sure you can't do stuff like:

  >>> def function():
  ...   True
  ...
  >>> function()
  >>>
(That returned `None`)

But I don't see how requiring a return statement, or disallowing code like:

  if var1 = function():
    do_something()
is a crime against humanity.
Post reply on HN