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

Post by pyre » Fri, Jan 10, 2014, 4:43 AM UTC

ufmace wrote: post #122

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…

It's easy enough if you have only one editor on one computer that you use with only one language. If you mix and match a half-dozen editors on multiple computers running different OSes coding in different languages, then it gets messier. Especially when all of the editors have different ways to set preferences for whether to use spaces or tabs, how much space per tab/indent, and whether those preferences are for this…

Post by eeshanC » Fri, Jan 10, 2014, 7:12 AM UTC

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…

Post by eeshanC » Fri, Jan 10, 2014, 7:40 AM UTC

bnolsen wrote: post #107

yohanatan wrote: post #97

Earlier quoted context omitted.

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.

Post by bjourne » Fri, Jan 10, 2014, 8:28 AM UTC

Aloisius wrote: post #101

bjourne wrote: post #91

Earlier quoted context omitted.

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.

    m = type('', (), {})()
    setattr(m, 'foo', 123)
    m.f

Post by __david__ » Fri, Jan 10, 2014, 11:22 AM UTC

pyre wrote: post #48

__david__ wrote: post #44

Earlier quoted context omitted.

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