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 Pythonic, but he's wrong to say we'll all write in Python some day. 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. The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth.
I must say though that I pray for more convergence. It annoys me to write code in JavaScript and Python, having to remember subtle differences between the two as small as capitalization of true and False, and tricky pitfalls like the scope of a variable declared in an if block.
It does seem an unnecessary burden for me as a web developer to have to know a handful of languages. You can hardly make a website today without knowing HTML, CSS, Javascript, Python/Ruby, and you better know your SQL too. Then, let's talk APIs.
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
You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software.
With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more.
You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.
"There's no question that Linux should be written in a low level language"
In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language.
I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly.
Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it.
In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.
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.)
"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.
You seem to completely ignore the fact that there are environments where speed does not matter, but memory is constrained.
In those environments even Java is prohibited and C/C++ or even assembly is a way to go, because in these languages you have direct control over memory allocation.
>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.<
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?
The less the programmer says, the more flexibility the compiler has to speed things up.
I seriously doubt it. The more the compiler knows, the more it can optimize things.
What it's "daily" in this example? It could be anything. The only thing the compiler knows at compile time is that it should generate some lookups searching and calling the functions "__iter__", "__slice__", etc... Put that line into a function which receives daily as a parameter and it could mean something different at every single invocation. Human beings, looking that code think know what it does, while in fact don't have a clue. The equivalent code in clojure someone has wrote only is really equivalent under some very specific assumptions.
I know, I know, at runtime you could gather all kinds of interesting data to optimize things. But, that's not easy nor cheap and, sometimes, iterating over an array, it's just iterating over an array.
Unfortunately, it will take a long time for all the web dev to switch (from PHP) to Python. Lazyness is stronger than any high-level language feature or development speed.
I've long given up trying to convince my clients to switch for a python-friendly host.
Imagine: i still have some clients running their website on PHP4.
[+] [-] andrewljohnson|17 years ago|reply
So, the author is right that we're getting more Pythonic, but he's wrong to say we'll all write in Python some day. 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. The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth.
I must say though that I pray for more convergence. It annoys me to write code in JavaScript and Python, having to remember subtle differences between the two as small as capitalization of true and False, and tricky pitfalls like the scope of a variable declared in an if block.
It does seem an unnecessary burden for me as a web developer to have to know a handful of languages. You can hardly make a website today without knowing HTML, CSS, Javascript, Python/Ruby, and you better know your SQL too. Then, let's talk APIs.
[+] [-] fauigerzigerk|17 years ago|reply
You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software.
With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more.
You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.
[+] [-] rbanffy|17 years ago|reply
In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language.
I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly.
Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it.
In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.
[+] [-] stcredzero|17 years ago|reply
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.)
[+] [-] vorador|17 years ago|reply
[+] [-] tezza|17 years ago|reply
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
[+] [-] Tichy|17 years ago|reply
[+] [-] gizmo|17 years ago|reply
Do you really believe that?
[+] [-] agazso|17 years ago|reply
[+] [-] unknown|17 years ago|reply
[deleted]
[+] [-] adamc|17 years ago|reply
>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.<
[+] [-] mjuyhjui|17 years ago|reply
[+] [-] b-man|17 years ago|reply
"In an ideal world, high-level languages like Python would replace all other programming languages."
That includes smalltalk, scheme, clisp, and every marvelous language not yet invented.
But then he goes on and says something very closed minded like
"Someday we will all program in python."
As if python got everything correct, and we have a perfect map of how humans think with it. The arrogance.
[+] [-] natrius|17 years ago|reply
[+] [-] cubix|17 years ago|reply
(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.
[+] [-] tybris|17 years ago|reply
[+] [-] crc|17 years ago|reply
As of June 20th, there is now an optional padding argument in clojure.core/partition.
[+] [-] tybris|17 years ago|reply
[+] [-] malkia|17 years ago|reply
[+] [-] _pius|17 years ago|reply
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?
[+] [-] fcr|17 years ago|reply
[+] [-] samuel|17 years ago|reply
I seriously doubt it. The more the compiler knows, the more it can optimize things.
What it's "daily" in this example? It could be anything. The only thing the compiler knows at compile time is that it should generate some lookups searching and calling the functions "__iter__", "__slice__", etc... Put that line into a function which receives daily as a parameter and it could mean something different at every single invocation. Human beings, looking that code think know what it does, while in fact don't have a clue. The equivalent code in clojure someone has wrote only is really equivalent under some very specific assumptions.
I know, I know, at runtime you could gather all kinds of interesting data to optimize things. But, that's not easy nor cheap and, sometimes, iterating over an array, it's just iterating over an array.
[+] [-] malkia|17 years ago|reply
[+] [-] juliend2|17 years ago|reply
[+] [-] danbmil99|17 years ago|reply
[edit:] if only... Amend to: some day, we will program as efficiently as possible, and software will do most of the annoying housekeeping.