Someday we will all program in Python • Hacker News Board

Re: Someday we will all program in Python

#11

Post by gaius » Mon, Jun 22, 2009, 12:01 PM UTC

Tichy wrote: post #7

andrewljohnson wrote: post #2

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…

Some people really want static types.

More people than you'd think, hence the current fashion for "unit tests".

Re: Someday we will all program in Python

#12

Post by _pius » Mon, Jun 22, 2009, 12:04 PM UTC

weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)]

While I appreciate the general sentiment that high-level languages will take over the world, there is very little that's new in this article and I am not impressed by the showpiece Python code from the article. For loops are the future?

Re: Someday we will all program in Python

#13

Post by _pius » Mon, Jun 22, 2009, 12:07 PM UTC

tybris wrote: post #5

cubix wrote: post #3

Or how about in Clojure? (map (partial reduce +) (partition 7 7 daily)) Edit: Possibly that should be partition-all from seq-utils to sum the remainder days if the length of daily isn't divisible by 7.

That's pretty unreadable for someone who doesn't know clojure.

That's pretty unreadable for someone who doesn't know clojure.

And that Python is pretty unreadable for someone who doesn't know Python.

Re: Someday we will all program in Python

#14

Post by adamc » Mon, Jun 22, 2009, 12:15 PM UTC

I thought the second comment was interesting:

>I believe the flaw in the argument is that the higher-level languages are actually more constrained, because they have made too many broad promises and are unable to tell when they can violate them without ill effect, even though it is obvious to the programmer. We might think that your example above would be a perfect case in which we could parallelize the loop... but what if sum() had side effects, such that it would produce the wrong result if not evaluated in order? What if sum() didn't have any directly detectable side effects, but called another function which called another function which did... sometimes, from code in a runtime eval? The compiler has no way of knowing this, so it has to assume the worst, and this is why it ends up being unable to make all the optimizations that one thinks it "should" be able to make. The human looks at it and says "duh, it's called 'sum'. If it has side effects, I'm going to smack somebody up the side of the head" and proceeds to optimize in the expected ways.<

Re: Someday we will all program in Python

#15

Post by tezza » Mon, Jun 22, 2009, 12:18 PM UTC

andrewljohnson wrote: post #2

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…

"there are a very limited number of applications that require that sort of speed"

Plenty of software is not web-based or a cron job for Linux.

Java, C# are chosen not just because of speed.

You can get vendor support from Sun for their JVM stack. You can (try to) get similar support from Microsoft for .Net stack.

Then also there are personal preferences ::

. Static Typing can be a key part of how people build complex systems in a way they feel comfortable with. When my team codes that way, may bugs are picked up at compile time versus deploy time.

. JVM has really nice remote debugging

. JVM is much closer to run-anywhere than Python

. JVM exits with hs_err files logged

Re: Someday we will all program in Python

#16

Post by _pius » Mon, Jun 22, 2009, 12:23 PM UTC

gaius wrote: post #11

Tichy wrote: post #7

Earlier quoted context omitted.

Some people really want static types.

More people than you'd think, hence the current fashion for "unit tests".

Static typing hardly replaces unit tests.

And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer.

If it were true, why would Java programmers use JUnit?

Re: Someday we will all program in Python

#17

Post by danbmil99 » Mon, Jun 22, 2009, 12:26 PM UTC

So true.

[edit:] if only... Amend to: some day, we will program as efficiently as possible, and software will do most of the annoying housekeeping.

Re: Someday we will all program in Python

#18

Post by crc » Mon, Jun 22, 2009, 12:29 PM UTC

cubix wrote: post #3

Or how about in Clojure? (map (partial reduce +) (partition 7 7 daily)) Edit: Possibly that should be partition-all from seq-utils to sum the remainder days if the length of daily isn't divisible by 7.

> Possibly that should be partition-all from seq-utils

As of June 20th, there is now an optional padding argument in clojure.core/partition.

Re: Someday we will all program in Python

#19

Post by stcredzero » Mon, Jun 22, 2009, 12:36 PM UTC

andrewljohnson wrote: post #2

The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…

Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory.

There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality JIT to machine code with no primitives.)

The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth.

You forget to mention a big factor: speed of cultural transmission. Considering what Lisp, Smalltalk, Self and other languages have been able to achieve for high level languages, why are we still dealing with poky high level languages like Ruby and Python? A part of it is cultural expectations. We still expect HLL to be an order of magnitude slower, even though that expectation is decades out of date, technologically. (HLL should only be 70-50% slower now.)

Re: Someday we will all program in Python

#20

Post by stcredzero » Mon, Jun 22, 2009, 12:44 PM UTC

_pius wrote: post #16

gaius wrote: post #11

Earlier quoted context omitted.

More people than you'd think, hence the current fashion for "unit tests".

Static typing hardly replaces unit tests. And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer. If it were true, why would Java programmers use JUnit?

As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all.

Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.