11–20 of 98 posts
Common ground: first class functions, a lot of flexibility, closures
Lisp: macros, performance?
Python: easy to learn by example, readability, batteries included
I use Python day-to-day as I don't really need a macro system that much. I also disagree that Lisp is more elegant - beauty is in the eye of the observer.
Edit: formatting.
Every serious development group is going to need a few patterns and coding standards, because newsflash: no language is perfect. All languages need to be used properly.
If you have good standards for naming, then a simple search should tell you exactly how to read "(f x)" in less than a second. The same goes for Smalltalk method names. If an extremely important method in your application code gets named "add:" well, guess what, there are already base class methods named "add:"! This means your senders searches and implementor searches -- which are fundamental to the way lots of expert Smalltalkers code -- are going to be polluted.
Also, the same thing can apply to function names in Python!
In dynamic languages, good programmers know names are very important. Before a good, experienced dynamic language programmer names something "foo", they first search for foo! They search for things that might be confused with foo! Programmers of dynamic languages who don't do this are either ignorant or inconsiderate. This post doesn't strike me as written by someone experienced or knowledgeable with development in dynamic languages. (And if he's experienced, he's had the bad luck of having been mentored in short-sighted groups.)
There's a lot of repetition and many times it's downright verbose. But where Lisp is nice to write and hard to read, Python makes the opposite tradeoff. It's easy to read. You can determine how to interpret something—a string, a list, a function call, a definition—just by looking at the code locally.
This post takes no account of Don't Repeat Yourself and is seemingly written with no foreknowledge of this idea. Curious, since Python is powerful enough to get close to the ideal of Don't Repeat Yourself.
Strategy for creating a blog post that looks analytical and sounds good -- but only to sophomore programmers:
1) Pick a certain aspect Y of language X which can be abused
2) Give a detailed analysis for why Y is bad
3) Completely leave out any mention of known best practices for addressing Y
4) Compare to a more popular language Z. Leave out any mention of Y applied to Z.
This way, you can get some attention from sophomore programmers and provide them a way to feel better by giving them a good sounding reason to avoid studying X.
Really, this kind of sophistry is so common, there should be a name for it! (Actually, there is a way that Lisp can be easy to write and hard to read, but that has to do with macro expansion. But the tendency is for those with substantive Lisp experience to know about things like that.)
EDIT: To avoid distracting "ad hominem" nonsense. Note the argument is completely the same.
EDIT: Got read/write mixed up.
Saying that LISP is for writing code and Python is for reading code is like saying that cars are for travelling uphill and bicycles are for travelling downhill.
because that was the OA's point: that if a developer wanted to optimize for going uphill, choose a car rather than a bicycle. downhill? bicycle will do that with less resources, waste, cost, pollution, volume passed through, etc. pick which is better given the context and optimization goals.
I don't mean to be the next snarky Lisp guy in the room, but I don't see the difference between reading
(if (= a 3) ...)
if a == 3:
...
(No, you can't name a function "if" in Common Lisp. Go ahead, try it.)
>Python on the other hand has no macros I challenge this. I won't pretend that Python has full macro equivalence, but decorators are damned close.
This is certainly something you can do with macros, but it's not even really close to the full semantics. Macros allow you to add new special forms to the language. If Python had macros, for example, the new `with` statements would have been a five line addition to the standard libraries.
I really don't see it as "damned close" at all.
>Python on the other hand has no macros I challenge this. I won't pretend that Python has full macro equivalence, but decorators are damned close.
Can you expand on this. What is something that macros can do that decorators can't? And likewise, what are some common uses of macros that decorators can do?
That said, the usual answers to the question of "Why do I need macros" are slowly but surely being chewed through by Python. The relatively-recent (albeit years old) addition of "with" took another previously-macro-only use case away. I'm not sure what massive win for macros is left. If your Python is "downright verbose" you're probably doing something wrong. It may not always be the Absolute Shortest (TM) but "downright verbose" shouldn't come up often.
The trouble is that you can't easily tell just by looking at (f x) how to interpret it. Every serious development group is going to need a few patterns and coding standards, because newsflash: no language is perfect . All languages need to be used properly . If you have good standards for naming, then a simple search should tell you exactly how to read "(f x)" in less than a second. The same goes for Smalltalk method…
You realize that this poster is Google employee #7, responsible for "Don't be evil" (along with Paul Buchheit), and wrote the first prototype for Google Instant back in 1999?
Something else to keep in mind, from the article:
"When I read debates online, I have a bias towards the people who view these things as tradeoffs and a bias against the people who say there's only one right answer and everyone else is stupid or clueless ... When you're in a debate, consider that the other person might not be stupid, and there might be good reasons for his or her choices."
Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong.
Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing.
Oh well, at least he didn't complain about lisp having too many parenthesis.
The trouble is that you can't easily tell just by looking at (f x) how to interpret it. Every serious development group is going to need a few patterns and coding standards, because newsflash: no language is perfect . All languages need to be used properly . If you have good standards for naming, then a simple search should tell you exactly how to read "(f x)" in less than a second. The same goes for Smalltalk method…
"What this actually reveals is that this poster is used to code bases not advanced to the point of Don't Repeat Yourself. He may not even be at an advanced enough level to know about this idea or fully appreciate it. Python is powerful enough to get close to the ideal of Don't Repeat Yourself. Evidently, this poster has no clue." You realize that this poster is Google employee #7, responsible for "Don't be evil" (alo…
Why, are you arguing from authority on his behalf? In that case, I say he should know better! (That's a stand worth burning some karma on!)
tl;dr - If you are going to criticize language X, first take the time to learn the best practices of language X. If you don't, you're just creating more clueless noise of a kind which already exists online by the ton. Also, it seems quite lazy. All you have to do is get on IRC and ask, "Hey, I've been playing around with X. What about when this happens?" You might even learn something this way.
EDIT: Google employee #7? Makes me wonder if dozens of Google programmers have said something like, "Arrrgh, why did he have to name it that!? Did Amit write that code?"
Earlier quoted context omitted.
"What this actually reveals is that this poster is used to code bases not advanced to the point of Don't Repeat Yourself. He may not even be at an advanced enough level to know about this idea or fully appreciate it. Python is powerful enough to get close to the ideal of Don't Repeat Yourself. Evidently, this poster has no clue." You realize that this poster is Google employee #7, responsible for "Don't be evil" (alo…
You realize that this poster is Google employee #7, responsible for "Don't be evil" (along with Paul Buchheit), and wrote the first prototype for Google Instant back in 1999? Why, are you arguing from authority on his behalf? In that case, I say he should know better! (That's a stand worth burning some karma on!) tl;dr - If you are going to criticize language X, first take the time to learn the best practices of lang…
The first half of your post was great. It addresses the arguments directly, and I completely agree. In the second half, you then go on to make assumptions about the programmer's experience and aptitude - assumptions that I've shown are quite false. If you want to debate the merits of an argument, debate the merits of an argument, don't assume that everyone who argues with you is stupid. There's a very good chance that they aren't, and then you look like a fool.
Edit: On a regular basis, I whine about Craig Silverstein or Jeff Dean or Marissa Mayer's code. "Why did s/he have to write it like that? It's cost us untold thousands of hours in coding around their nasty hacks and poor design decisions." However, I recognize the context they were operating in: they were a tiny startup of about 20 people, trying to organize the world's information. They were working basically round the clock, and they changed the world. Sometimes, building something that works for users and won't crash your datacenter is worth the price of maintainability. You have to survive before you have the luxury of hiring people that will call you stupid.
Tradeoffs. They come with every hard problem.