Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Someday we will all program in Python

davidbau.com

Post reply on HN
Print view View original

51–60 of 80 posts

Re: Someday we will all program in Python

#51

Post by gaius »

stcredzero wrote: post #20
_pius wrote: post #16

Earlier quoted context omitted.

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 deman…

Strong inferred typing is (generally) superior to static in the sense that it gives you the best of both worlds, flexibility and safety. Strong typing plus a clear separation between pure and impure code gets you a lot. Test harnesses are vital still, but testing blindly (which is what most unit testing does) is scarcely better than old-fashioned manual QA.

Re: Someday we will all program in Python

#52

Post by tsuraan »

DannoHung wrote: post #50
fauigerzigerk wrote: post #32

Earlier quoted context omitted.

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 imag…

Can we at least all agree that no one should be writing anything in a shell scripting language any longer? I'd be happy with just winning that battle.

I like scripting my shell using a shell scripting langauge; if I have a few dozen (or hundred) console operations that need to be done often, then a shell script is more concise than ruby. If I need to add error handling, exceptions, networking, etc, then it's time to move up, but if all that's needed are external programs and some looping and conditionals, then I don't see any problem with scripting.

Re: Someday we will all program in Python

#53

Post by b-man »

I think it is funny that the guy went and said something correct like this:

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

Re: Someday we will all program in Python

#54

Post by anc2020 »

Confusion wrote: post #33
anc2020 wrote: post #8

Earlier quoted context omitted.

Is this better? map(partial(reduce, +), partition(7, 7, daily)) Personally I'd be much much more happy to be using this code than the snippet in the article. In fact, I don't program Python regularly and it did take quite a while to figure out what was going on in the code. weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)] Now if you look back at the top snippet, its just normal function calls, so you can…

Just because you already happen to have a certain function at your disposal doesn't mean your language is suddenly superior. def partition(n, step, coll): for i in range(0, len(coll), step): yield coll[i:i+n] allows weekly = [sum(week) for week in partition(7, 7, daily)] Using Python's map() function you can even do map(sum, partition(7, 7, daily)) making it exactly the same as your example. And no, I probably haven'…

Please consider my comment. Firstly, it was in response to this comment:

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

The real reason for commenting was to show that it is readable and yes, providing the "readable" Python equivalent.

There are two points - firstly, Clojure is (or is becoming?) a lazy language and the list type is different, so no they are definitely not exactly the same.

This brings us to a broader point in that even if you were to have laziness in Python it still wouldn't matter because I'm not the only coder in the world and there are a lot of Pythonists like the author of the article who do it the Pythonic way, which as already hinted, I think is just braindead.

Re: Someday we will all program in Python

#55

Post by stcredzero »

gaius wrote: post #51
stcredzero wrote: post #20

Earlier quoted context omitted.

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 deman…

Strong inferred typing is (generally) superior to static in the sense that it gives you the best of both worlds, flexibility and safety. Strong typing plus a clear separation between pure and impure code gets you a lot . Test harnesses are vital still, but testing blindly (which is what most unit testing does) is scarcely better than old-fashioned manual QA.

People forget that the whole point of abandoning strong typing in environments like Smalltalk was the extreme speed of exploratory programming that it supported. If you can have strong typing and have low overhead rapid exploratory programming, then why not? Duck Typing is not a goal, it's a means!

I disagree that testing blindly is scarcely better than manual QA. If it's automated, the cost of leveraging your tests is small. The cost of adding more tests is not multiplied by iterations. With automation, increased frequency of tests can be used to localize the cause of bugs to particular changes in time.

Re: Someday we will all program in Python

#56

Post by jshen »

scott_s wrote: post #43
charlesju wrote: post #38

Earlier quoted context omitted.

What are some other benefits of C or Java over something like Ruby and Python?

The level of abstraction matches most hardware. Not all code written in C is performance-critical. But sometimes it's still the best choice if your code is directly talking to hardware.

In that case wouldn't you write some components in C and glue it all together with something like ruby?

Re: Someday we will all program in Python

#57

Post by sp332 »

fauigerzigerk wrote: post #32
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…

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 imag…

You can already do image processing in lowly Javascript, example http://hacks.mozilla.org/2009/06/content-aware-image-resizin... , and machine learning can be done in pure Python, example http://montepython.sourceforge.net/ .

Re: Someday we will all program in Python

#58

Post by jshen »

itistoday wrote: post #48
Confusion wrote: post #33

Earlier quoted context omitted.

Just because you already happen to have a certain function at your disposal doesn't mean your language is suddenly superior. def partition(n, step, coll): for i in range(0, len(coll), step): yield coll[i:i+n] allows weekly = [sum(week) for week in partition(7, 7, daily)] Using Python's map() function you can even do map(sum, partition(7, 7, daily)) making it exactly the same as your example. And no, I probably haven'…

> Just because you already happen to have a certain function at your disposal doesn't mean your language is suddenly superior. You are certainly correct in that. That's not what makes Lisps superior to all other languages though, "it's the syntax stupid." Edit: Sorry, I know that comment appears trollish (and it is), what I meant to say is that unlike Python, Lisp(s) have virtually no syntax, and are more powerful be…

Isn't there more to power than that? For example, in clojure you can't change the binding of a function in a namespace after it has been compiled. In python or ruby you do have the power to do that.

Re: Someday we will all program in Python

#59

Post by juliend2 »

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.

Re: Someday we will all program in Python

#60

Post by fauigerzigerk »

sp332 wrote: post #57
fauigerzigerk wrote: post #32

Earlier quoted context omitted.

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 imag…

You can already do image processing in lowly Javascript, example http://hacks.mozilla.org/2009/06/content-aware-image-resizin... , and machine learning can be done in pure Python, example http://montepython.sourceforge.net/ .

They're all Turing complete after all ;-)
Post reply on HN