Homogenization of scientific computing – Python is eating other languages’ lunch • Hacker News Board

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

#41

Post by maxerickson » Thu, Jan 09, 2014, 5:32 PM UTC

frou_dh wrote: post #40

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…

> 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). Nope. Tabs are for indentation and spaces are for alignment. It's precisely because of non-good (or maybe non-smart) editors that people can't be bothered acknowledging or practicing this distinction a…

Conveniently, any editor that can properly deal with tabs will have an easy time dealing with semantic leading spaces.

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

#42

Post by Ensorceled » Thu, Jan 09, 2014, 5:32 PM UTC

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.

I used to think that way. But then I realized it forced all my co-workers to get their freakin' indenting correct.

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

#43

Post by klrr » Thu, Jan 09, 2014, 5:33 PM UTC

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.

So you are enabled to focus wholly since you are used to its syntax?

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

#44

Post by __david__ » Thu, Jan 09, 2014, 5:33 PM UTC

pyre wrote: post #32

area51org wrote: post #30

Earlier quoted context omitted.

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.

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…

> The two '$_'s in the map block actually refer to two different variables

Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a.

That's not really a style thing, it's a Perl thing, for better or for worse.

> I'm sorry, but I can't get worked up about not being able to write code like that.

Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl.

It's even a single expression which means you could probably write a similar one liner in python (since their wimpy "lambda" only does expressions)

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

#45

Post by Eiwatah4 » Thu, Jan 09, 2014, 5:34 PM UTC

StefanKarpinski wrote: post #29

[deleted] wrote: post #20

[deleted]

Edit: in response to "why isn't there a movement around using JavaScript for scientific computing", which I thought was an excellent question (which has crossed my mind on occasion). Typed arrays and real support for integers are crucial features for scientific computing. Although JavaScript recently got some support for typed arrays, they are pretty awkward to use and there still isn't any support for 64-bit integer…

You don't have to simulate multidimensional arrays in C. It's just easier than wrapping your head around the weird syntax required to pass them around: http://pastebin.com/JTjQMfxr

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

#46

Post by Arnor » Thu, Jan 09, 2014, 5:35 PM UTC

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.

Yeah, I hate when my language forces me to write pristine code...

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

#47

Post by gvb » Thu, Jan 09, 2014, 5:40 PM UTC

pyre wrote: post #32

area51org wrote: post #30

Earlier quoted context omitted.

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.

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, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it." - http://www.gurteen.com/gurteen/gurteen.nsf/id/L001362/

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

#48

Post by pyre » Thu, Jan 09, 2014, 5:40 PM UTC

__david__ wrote: post #44

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…

> The two '$_'s in the map block actually refer to two different variables Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. That's not really a style thing, it's a Perl thing, for better or for worse. > I'm sorry, but I can't get worked up about not being able to write code like that. Why? It looks more or less reasonable to me. Most of the weirdness there…

> Yeah, but that's Perl 101. Grabbing an element of array @a is $a[0], which is wholly different than plain $a. > > That's not really a style thing, it's a Perl thing, for better or for worse.

That code confused me after working in nothing but Perl for 4 years. It was confusing because I wasn't used to people having an array (@_ in this case) and a scalar ($_) named the same thing, and used in close approximation. The issue could have been avoided by (e.g.) setting $_[2] to a variable first, and would have made the code more readable. It's not "Perl 101" to write code that is intentionally obtuse.

> Why? It looks more or less reasonable to me. Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters. @_ and $_[] are simply a fact of life when writing Perl.

That code could be written in a way that was easier to read and maintain. For example, what is 'shift' intended to be? The only information we have is that it's supposed to be the first argument to function1.

Edit:

> Most of the weirdness there is a factor of Perl's unfortunate lack of named function parameters

This was in a code base with a source filter to provide function parameters. That could have been written as:

  sub function1($arg1, $arg2, $arg3) {
  }

in that code base, but the developer in question chose not to.

Even without said source filter, you can still name the function parameters:

  sub function1 {
    my ($arg1, $arg2, $arg3) = @_;
  }

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

#49

Post by jofer » Thu, Jan 09, 2014, 5:42 PM UTC

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…

> 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 said, I completely agree on the benefits of Julia.

However, I'd argue that Julia has the potential to compete with (or replace) the scientific python ecosystem for a completely different reason: It's more seamless to call C/Fortran functions from Julia than from Python. (Though Cython and f2py makes it pretty easy in python.)

There's an awful lot of very useful, well-designed, very well-tested scientific libraries written in C and Fortran. It's far better (i.m.o.) to have a higher-level language be able to call them seamlessly than to have a high-level language where reimplementing them is a better option. (Julia does wonderfully in this regard. Python does pretty well, but not as well, i.m.o.)

Also, from what I've seen, I think the Julia and scientific python ecosystems are more complimentary than competing, at the moment. There seems to be a lot of cross-pollination of ideas and collaboration, which is a very good thing.

(...And I just realized who I'm replying to... Well, ignore most of what I said. You know all of that far, far better than I do! Julia is _really_ interesting and useful, by the way!)

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

#50

Post by simias » Thu, Jan 09, 2014, 5:44 PM UTC

pyre wrote: post #32

area51org wrote: post #30

Earlier quoted context omitted.

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.

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…

> 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 code from anywhere to anywhere (no matter the coding style in the source and destination file and the level of indentation) and then hit C-M-\ in emacs and have it reindent everything properly. In Python you have to make sure that everything is at the level of indentation it belongs to. If you refactor huge chunks of code it's easy to miss one fubar tab and have code subtly broken and introduce weird regressions.

Also, regarding the OP and "focusing only on your code", I think we all feel that way about the language we're the most familiar with. For me that's C and I can't say I've had a "missing semicolon" compilation error in months of heavy use. Once you're used to the syntax it becomes automatic.