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

61–70 of 184 posts

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

#61

Post by frik »

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

Me too.

Lua the language and LuaJIT the third party vm are great. But there is no general purpose standard library. Like in C one has very limited libraries that are shipped with Lua - that's fine. Though I really miss a good website with a list of additional up-to-date libraries and a community around it.

Lua needs a better project website, like PHP where you can post code examples as comments. At the momemt the Lua website is stuck in 1999. The wiki software is bad, the only way to stay in touch is the mailing list, etc. The LuaForge website is outdated. Finding various libraries is pain. Many libraries are hosted on servers that don't exist anymore or are for Lua 4 or 5.1 but not 5.2.

A lot of users use Lua in closed source software as embedded language (video games, Adobe programs, etc.)

Imagine if all those libraries that you find for Python would be available for Lua, it would be great.

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

#62

Post by EvanMiller »

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…

I'd just like to add that what I love about Julia is that it actually lets you go deeper than C code. For high-performance computing it's easy to hit a wall with C (i.e. with SIMD vector instructions), and it's fairly difficult to jump the barrier to programming assembly. Julia makes it easy to muck around with the generated LLVM IR code as well as native assembly code. You can go as deep as you want without leaving the Julia REPL.

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

#63

Post by collyw »

CmonDev wrote: post #58
theorique wrote: post #35

Earlier quoted context omitted.

+1 I'm a user of both, fan of both, but the lightness of Lua is a big plus. The main downside, IMO, is that the Lua user base is smaller so there's more need to roll your own solutions for things that Python already has several libraries for.

"roll your own solutions" - that's part of fun!

its also time consuming, and often buggier than pre-rolled tested solutions.

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

#64

Post by collyw »

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 disliked the whitespace thing at first, but after using it for a while I got used to it. Then when I had to go back to change some Perl code I realised the real beauty of it - you never get the problem of having unmatched braces when moving blocks of code around.

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

#65

Post by Xcelerate »

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 than kludged together. I've been trying to gradually use it more and more for my research, but the only problem I've found so far is the large mental context-switch I make going from my usual languages to Julia. It's hard to tell what Julia code will be the most performant because there's many ways of doing the same task. I saw someone in the comments on this page mention that you can hand-tune the LLVM generated output within the REPL itself. I imagine this would be very useful if I can get around to learning it (anyone know a good tutorial?)

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

#66

Post by simias »

pyre wrote: post #57
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…

> 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 long enough time that I don't even "see" the brackets and semicolon anymore. As such I don't find any advantage to the python way. To me it's sacrificing convenience for aesthetics.

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

#67

Post by klibertp »

simias wrote: post #50
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 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…

I think all the modes for python in Emacs implement dedent and indent functions which behave nicely. I hacked one of them to leave selection active after the operation and now - it's still more than one command - I do C-y for paste, C-x C-x to select what was pasted and C-M-> or C-M-On the other hand it's almost impossible to make a mistake with indentation with python-mode (and similar, I'm using all-in-one-plus-your-cat elpy package) when writing code - the enter key indents automatically (instead of having to press tab additionally) and it indents one level more after statements which need it. And backspace removes one level of indentation. I can't remember if I ever had a problem with indentation in Python in Emacs; although I know I had some with CoffeeScript.

So in short - it's all an editor support issue and some relatively trivial rules give you an experience as streamlined as in langs without significant whitespace.

Also, I'm a lisper so - paredit. Knowing about it and using it makes you realize how broken every other syntax is and how hard it is to edit ;)

(Replying just because of Emacs, the rest is uninteresting anyway - in my experience once you cross the border of 5-8 known langs you can easily accommodate to any syntax)

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

#68

Post by mahyarm »

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 problem is larger multi-people projects. You need very strict editor/whitespace discipline, and you don't want to commit some sort of re-indent which touches every line of a file. That and the refactor issue is the main issue people have with the whitespace thing.

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

#69

Post by klibertp »

frenchy wrote: post #39
drdeadringer wrote: post #37

Earlier quoted context omitted.

"white space is semantic" Is this not true for webpages and journalism?

Semicolons are semantic in journalism too.

As they are in Python:

    import os; import antigravity; # etc...

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

#70

Post by simias »

hharrison wrote: post #56
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…

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 languages.

Again, I'm not trying to say it's a deal breaker and Python is useless as a result, I just think it's a small mistake in the design of the language. It's like non-breaking switch/case in C, it doesn't make the language unusable but it is an annoyance.

Post reply on HN