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

61–70 of 80 posts

Re: Someday we will all program in Python

#61

Post by itistoday »

jshen wrote: post #58
itistoday wrote: post #48

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

I'm not a Clojure expert, so I can't directly address that, but from the little that I know of Clojure though, I think you can do that by binding a function to a var, and then changing the binding of the var. (Can any Clojure experts exlaborate?)

Regardless, every Lisp that I am able to comment on (newLISP, elisp, Scheme, CL) can do that easily, so I doubt that Clojure would have difficulty with this.

Re: Someday we will all program in Python

#62

Post by timr »

timr wrote: post #26
stefano wrote: post #9

Earlier quoted context omitted.

That could be said for any language. It's just that the first language someone usually learns borrows more from algol than from lisp. This leads to the idea that Python/Ruby/PHP/Javascript are easier to learn than Clojure/Common Lisp/Scheme.

Algol languages are taught first for good reason: Algol-derived languages resemble English; Lisp isn't natural or intuitive to anyone who doesn't already know Lisp.

Oh, come on, folks. It's a perfectly reasonable comment -- Lisp is powerful and expressive, but it is not an intuitive language for beginners.

Re: Someday we will all program in Python

#63

Post by natrius »

b-man wrote: post #53

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

The last part didn't seem entirely literal to me.

Re: Someday we will all program in Python

#64

Post by scott_s »

jshen wrote: post #56
scott_s wrote: post #43

Earlier quoted context omitted.

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?

Sure, that sounds reasonable. But you've still chosen C to talk to the hardware.

Re: Someday we will all program in Python

#65

Post by callahad »

gizmo wrote: post #10
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. Do you really believe that?

I think it's a reasonable statement, if the following premises are accepted:

1. It is easier and quicker to develop a correct solution in a higher level language than a lower level one.

2. Expressiveness / abstraction come at the cost of time and space efficiency.

Thus, if time and space efficiency are not a concern, then the higher level language should be preferred.

Re: Someday we will all program in Python

#66

Post by jcl »

timr wrote: post #62
timr wrote: post #26

Earlier quoted context omitted.

Algol languages are taught first for good reason: Algol-derived languages resemble English; Lisp isn't natural or intuitive to anyone who doesn't already know Lisp.

Oh, come on, folks. It's a perfectly reasonable comment -- Lisp is powerful and expressive, but it is not an intuitive language for beginners.

Perhaps it seems that way to you because you are more familiar with Algol syntax than Lisp syntax, or because you have gone on to learn the more advanced Lisp features. But Scheme syntax and semantics, for example, are arguably at least as simple as that of an Algol language. Scheme has been used successfully as a first programming language in high school computer science courses: http://www.teach-scheme.org/

Re: Someday we will all program in Python

#67

Post by Confusion »

anc2020 wrote: post #54
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'…

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

I will not argue the first point, but as for the second one: how does that one author determine what is 'the Pythonic way'? I think

  [sum(week) for week in partition(7, 7, daily)]
is 'the Pythonic way' and I find that quite a bit easier to comprehend than

  map(sum, partition(7, 7, daily))
The reason for that is as simple as it runs counter to what people usually preach: it is less concise. In the former, it is immediately clear that you are partitioning a list of days into partitions of weeks and summing over those weeks, resulting in a list of weekly sums. The extra word 'week', repeated twice, makes all the difference: all ingredients for comprehension are readily provided. The latter case, on the contrary, requires you to do a few mental operations to expand the expression into something meaningful, mentally adding the concept of a 'week' to understand what the code is doing. You need to do that everytime you read the code, which makes it less easy to understand.

Re: Someday we will all program in Python

#68

Post by gaius »

stcredzero wrote: post #55
gaius wrote: post #51

Earlier quoted context omitted.

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…

But that's tangential. If you are doing exploratory programming, what does unit testing get you? How can you write the tests before the code if you don't have a spec to work from in the first place?

A lot of the pain of strong typing goes away with type inference - and strong typing means you get much better tool support, e.g. you can see a problem right there highlighted in your editor, you don't need to wait for the unit tests to run on your nightly build!

Re: Someday we will all program in Python

#69

Post by stcredzero »

gaius wrote: post #68
stcredzero wrote: post #55

Earlier quoted context omitted.

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…

But that's tangential. If you are doing exploratory programming, what does unit testing get you? How can you write the tests before the code if you don't have a spec to work from in the first place? A lot of the pain of strong typing goes away with type inference - and strong typing means you get much better tool support, e.g. you can see a problem right there highlighted in your editor, you don't need to wait for th…

But that's tangential.

Maintenance is tangential? Most of the work across all of the fields of programming is probably maintenance.

If you are doing exploratory programming, what does unit testing get you?

It gets you the ability to change your mind and do deep reworkings of very complicated systems with a higher degree of confidence. It's most valuable for maintenance, while duck typing, however.

How can you write the tests before the code if you don't have a spec to work from in the first place?

You end up doing better interface design at a finer granularity than you would have to otherwise. It slows you down, but requires greater discipline in terms of good architecture, so you end up saving time that way. Test first is really just design-up front, but with 3 or 4 orders of magnitude more iterations.

This is best for duck typing languages. Would I unit test in Eiffel, which supports Design By Contract? Doubt it.

you don't need to wait for the unit tests to run on your nightly build!

In the original Extreme Programming, one ran unit tests before checking in any code!

Re: Someday we will all program in Python

#70

Post by jshen »

itistoday wrote: post #61
jshen wrote: post #58

Earlier quoted context omitted.

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.

I'm not a Clojure expert, so I can't directly address that, but from the little that I know of Clojure though, I think you can do that by binding a function to a var, and then changing the binding of the var. (Can any Clojure experts exlaborate?) Regardless, every Lisp that I am able to comment on (newLISP, elisp, Scheme, CL) can do that easily, so I doubt that Clojure would have difficulty with this.

It does have difficulty with this, check the mailing list. Just because something using s-expressions doesn't mean you can override functions in a namespace.

http://groups.google.com/group/clojure/browse_thread/thread/...;

Post reply on HN