Hello /code/. Why don't we argue about Python's significant whitespace in this thread instead of derailing other threads over the matter?
Personally, I like it. I don't find it any more difficult or annoying using an extra tab rather than curly braces to delimit blocks, and the resulting code looks nicer and easier to follow for me. Mismatched spaces/tabs in Python and unclosed braces in other languages have bitten me in the ass equally often, and a good text editor with syntax highlighting will minimize both issues.
Does it really take expert programmers - which I'll freely admit I'm not - three times as long having to indent their blocks instead of surround them with braces?
Of course not. But you've noticed that you're worrying about what it looks like and "how easy it is to follow" and it's that which takes a lot of time. Python isn't a bad language for prototyping because of the indenting, but because it places such a large emphasis on code aesthetic which takes time and thought away from programming.
That's not always a bad thing: There are expert programmers that use python, but they often prototype and invent using something other than python. Reddit (for example) was prototyped and invented using Lisp but a proper implementation in python is easier to maintain. Yahoo Stores was prototyped and invented using Lisp, but I understand they used C++ for the implementation you look at today.
I think code aesthetic is arguably a good thing since we read code more often than we write it.
I can guess some of GvR's reasons for meaningful whitespace, and some have little to do with appearance. One problem I've been contemplating with '}' or 'end' is that it gives no indication which block it's a part of. If you do your indentation wrong you could well end up confusing the compiler, and you end up trying to find the mismatched delimiters. Bourne shell has one solution (if..fi, case..esac), but it's hard to read and adds clutter. Another solution I've seen in Ada (if..end if, case..end case), which is easier to read, but still adds clutter. If you make whitespace significant, you can remove end delimiters and both of these problems go away.
Of course, it's not without problems. I don't like Python's appearance; it has a similar "falling off the cliff" phenomenon that Lisp has, since Python has no end delimiters. PEP8 and the lack of end delimiters results in Python programs being densely written without much vertical whitespace, which hinders readability. Exacerbating the problem is that a lot of Python programmers appear to like using a lot of horizontal space as well, partly due to list comprehensions.
Python is also fairly noisy with symbols, __ and """ being pet peeves of mine. I was looking at the web.py homepage today, and the example on the front page is really bad, both in appearance and the way it was written.
That said, syntax is one of the lesser Python problems. It's a decent language (high praise coming from me), but it has its share of dubious semantics; I tend to think of Python as the Java of the dynamically-typed world.
>>3 It's most certainly arguable. I'm arguing that code aesthetic isn't a good thing when you're prototyping. When you're prototyping, you're writing much more than you're reading.
Once you're done prototyping, the choice of language matters far less. Even Java can be elegant with a good enough plan.
> I'm arguing that code aesthetic isn't a good thing when you're prototyping.
To argue that effectively we'll need to establish what "code aesthetic" means to each of us, and why you think aesthetic is mutually exclusive to prototyping.
For me it (might be) clarity of the code's intention. Ideally it'd fulfill the following:
I'm not sure what the above has to do with prototyping. While I suppose a case can be made for redundant syntax to make checking easier, I'd think that semantics would cause the bigger problems. An example is the dynamic<->static-typing continuum.
Another issue to consider is that prototypes usually aren't thrown away. They morph into a production systems.
> wrong things look wrong
This instantly rules out 99% of dynamically-typed languages.
> To argue that effectively we'll need to establish what "code aesthetic" means to each of us
Code aesthetic is a nominal statement of "how code looks". How pleseant you find it is irrelevant to anyone but you, so nothing meaningful can be said on the subject. Poll other people on how nice code looks, and you'll find some clear trends exist:
Poll them on why they find python aesthetic and you'll notice that many of them point out the whitespace. They feel it encourages whitespace-aware code. Blocks that are too long seem harder to read, and the lack of a trailing decorator (how you say "falling off a cliff") encourages shorter blocks.
When you look at a block of code, and you say "this block of code is ugly, I need to rewrite it", you're making a statement about its aesthetic. Sometimes this is motivated by being unable to read it, but sometimes this is motivated by being uncomfortable modifying it. The point at which code becomes ugly is very low in python- which is why it seems python programmers are constantly refactoring and adjusting their code.
> Another issue to consider is that prototypes usually aren't thrown away. They morph into a production systems.
I think that's a red herring. I'm arguing it's important to make prototyping easier, and that statement suggests that prototyping is meaningless because you only get to write it once anyway. While it's true that a lot of projects are that way in practice, that may merely be a practical side-effect of there being so few truly fantastic programmers, and infact there are very few projects where that prototype implementation was also how it would be engineered given what was learned during prototyping.
> Code aesthetic is a nominal statement of "how code looks". How pleseant you find it is irrelevant to anyone but you
Then why are you arguing against something so ambiguous?
Okay, I've reread your posts. Would you say this is an accurate summary of your argument:
Python is aesthetic and Python is poor at prototyping, therefore aesthetic is bad for prototyping.
I'd appreciate if you also clarified the following:
Regarding my comment about prototypes morphing into production, that's only a red herring if a languages that are good at prototyping are necessarily poor at production (I don't agree with that). It's also a valid concern since it is is a common progression with today's software; the whole agile/iterative/refactoring methodologies are a response to this.
>>9 I'll try and answer those questions:
> why do you think Python is bad at prototyping?
I don't know exactly. I think there's a psychological aspect of knowing the language is encouraging me (the programmer) to do something other than write code. GvR says that encouraging well thought-out code is important, so I'd say he's succeeding. I just think this is a bad idea for prototypes when I don't know all the variables before I start programming.
> which language do you think are good at prototyping, and why?
CL because of its interactive nature is by far the best prototyping language I've ever had a chance to use. The direct manipulation features and interactive development cuts down testing-time significantly. Perl is very good at some kinds of prototypes because of its very high affinity toward existing (modern) unix toolchains. I note that people say these languages are ugly, and I can't help but agree on some level.
> do you think these languages are bad at production, and why?
With perl, so much happens behind your back that if you don't know how the implementation works on the inside, it's difficult to get predictable behavior at run-time. With CL, it's hard to deploy to users who don't run a CL system. Even when they do, it's hard.
> do you not indent your code?
I don't indent my CL if that's what you mean. The editor does
that according to a very strict set of rules. And since a large majority of the python I write is in -e lines, no I guess I don't indent that either.
> what do you deem to be a prototype (days needed, kloc, or some other metric)?
When requirements aren't well known.
If you know all of your product requirements, because someone's done this before, or because it's obvious, then you don't need a prototyping system.
Sendmail is a prototype because its implementation was needed to answer a lot of questions. The address transformation code is completely unnecessary now because all internet messaging hosts must translate addresses the same way for interoperability. Nobody knew exactly what that way was when Sendmail was written, so it makes sense that they'd leave it tunable.
Qmail on the other hand uses a lot of that knowledge. The knowledge that 7bit hosts aren't on the Internet, the knowledge that addresses rarely equal mailboxes or users, and the knowledge that the MX hosts are usually up.
If the sendmail programmers knew everything the qmail programmer knew, then they probably wouldn't have implemented sendmail the way they did. Nevertheless, sendmail still supports this imaginary 7bit Internet that never existed and probably never will, and still treats |forward foo as an address (even though it's rewritten to be an error to prevent relaying and code execution). It still runs the queue from a single timer, even though on busy sites this is completely unacceptable.
That isn't to say the qmail programmer didn't learn anything from qmail. I'm sure he did, but I'm not as sure qmail would (or should!) be designed differently using that knowledge.
Another example: I have to write a data analysis package for statistical (but untested!) data. I don't know what kind of analysis will be interesting so I work with an analysist to explore the data. Together we write and use dozens of short simple programs designed to tabulate or cluster various results.
But it's important to note that we simply don't know what we're looking for when we start. Sometimes these are written as one-line scripts on the shell prompt, and I would definitely consider these prototype-quality.
If I wrote them in C or python, I might be tempted to reuse as many routines as possible, thus limiting what kinds of data I can look at. If I needed to do a new kind of clustering that wasn't originally thought of, I might have to rewrite my entire analysis stack.
Even if I had used SQL, 1NFing everything would make most of the queries that I know I have to do extremely complicated. awk is simply better and faster in this case.
(split into two parts because of Kareha's complaint)
> It's also a valid concern since it is is a common progression with today's software; the whole agile/iterative/refactoring methodologies are a response to this.
I don't see those methods being used in prototype-environments. ISC BIND (for example) is still basically the same system as it was when it started because while they've reimplemented almost the entire system at some point, they're still using the same design and frankly the design is stupid. They even say so in the documentation (not to run a site as both a cache and a content server) but nobody reads that thing. They just use the (stupid) defaults.
Well, being force fed like a child to indent would be a requirement for some of the C programmers I know, Honesty some people have no idea how to format their code correctly. I've had to run the unix INDENT program several times over there code just to show them how things should be done.
So why not just run indent on their code and stop whining?
>>12 seriously. indent -kr -i8 and be done with it.
A decent text editor will also fix indentation for you. In vim, select the code block you're working with, and press =
>>15
Vim launches indent as a subprocess for some filetypes.
This is a good thing, as the builtin indenting for lisp-like languages is somewhere between absolutely terrible and positively worthless.
Thanks for the replies. :)
> With perl, so much happens behind your back that if you don't know how the implementation works on the inside, it's difficult to get predictable behavior at run-time.
I agree with the problems that Do What I Mean present. I also don't like how syntactically heavy its OO system is (including Moose).
Ironically, despite the above, I think Perl is probably the best dynamically-typed language for production systems at the moment. It is mature, backed by a very large set of test suites, and is used in other production systems. Therefore I have higher confidence that the implementation works.
It also has strict mode with mandatory variable declaration, taint checking, a wealth of documentation and myriad commonly-used and mature libraries. Regrettably, most common dynamically-typed languages are missing some or all of that.
> With CL, it's hard to deploy to users who don't run a CL system. Even when they do, it's hard.
I suppose it depends on which business domain you operate in. If you're making closed client-side apps, CL has compilers. If it's server-side, nobody except your IT staff cares. The only time I think it's a problem is if you're making OSS software which will be used by geeks in the external world.
A bigger problem with Lisp is finding people who are skilled at it.
> Sendmail is a prototype because its implementation was needed to answer a lot of questions.
Our definitions of prototype appear to differ a bit. I think Sendmail stopped being a prototype long ago. It's in use in many systems even today.
Sendmail is an argument in favour of prototypes growing into production systems. It's not ideal, but it's what happens. There are alternatives, but Sendmail is still there, chugging along.
Many (most?) attempts I've seen at rewrites end up dead due to second-system effect, and that's ignoring the businesses who do not invest in rewriting software since they already have something that works. If your business sells that software, a rewrite gives competition plenty of time. If your business uses it in its infrastructure, the software is considered just an expense.
Parallel changeover works better, but that is arguably the software in question evolving. It's not a rewrite.
> I don't see those methods being used in prototype-environments.
Agile and iterative? If it's of any appreciable size I'd claim it does. Refactoring? Yeah, that's a problem. I'd argue a lack of refactoring is partly due to crappy code and inflexible languages.
If you write code well in a flexible language, there'd probably be less resistance to fixing large problems as they appear; one of the core ideas behind refactoring is reducing coupling, which goes hand-in-hand with a late-binding language.
I just wish that gradual typing was more common. I'm only aware of CL, Perl6 and Python 3000 (sorta) having anything like that.
> Our definitions of prototype appear to differ a bit. I think Sendmail stopped being a prototype long ago. It's in use in many systems even today.
A prototype is used to test a design concept by making actual observations and necessary adjustments. Linux's -mm tree can be considered a prototype as well, so I don't think deployment size can have anything to do with it.
> Many (most?) attempts I've seen at rewrites end up dead due to second-system effect.
I don't think the prototype needs to be complete, and usually isn't in practice. People write mockups in html or flash, or even on paper.
> Agile and iterative? If it's of any appreciable size I'd claim it does.
But most prototypes are small. It's only if they are fully functional (or almost so) that agile methodoligies are practical, so of course those are the ones that turn into production systems.
Those "betas" however, didn't really develop any useful information, or answer any unknowns so I'd hesitate to call them prototypes. Granted, sometimes, it does happen that a real prototype use agile, and becomes productive, but I think that's more a case of dumb luck, or psychic engineering than it is an indicator that agile is a good development practice for prototyping.
> A bigger problem with Lisp is finding people who are skilled at it.
You might say, a bigger problem with finding programmers, is finding good ones. :)
Or easier yet, slap checkstyle on the source control system so that they can't check it in unless THEY run it. Punish the person who's breaking the code style standards, not the guy who isn't.
Why on earth would you punish somebody for not doing by hand what can be done automatically on a computer? That is just insane.
That sounds like a fantastic way to get lots of whitespace-change patches.
>>21
Wrong, it's a way to AVOID lots of whitespace-change patches, because people won't be able to check in code with bogus indenting and stray whitespace.
>>22
That only works if you start with a pristine codebase. What if your codebase is slightly less (to your standard) ideal?
Then you fix it. Why is that a big deal?
It's not. People can get closed-minded sometimes. I think we all sometimes forget that this is an anonymous messageboard and there's no need to "win", or to be the chronic problem-pointer-outer who casts doubt on everything said. I agree with you.
>>24
On a large code base, it is a big deal. http://kerneltrap.org/mailarchive/linux-kernel/2007/9/19/263753 noted that patching the Linux kernel would take 15M to repair.
Meanwhile, just ignoring the problem and coding like normal eventually will fix it. Note that http://lwn.net/2001/1129/a/whitespace.php3 shows that an 8M reduction has already occurred over the course of 6 years.
And this is relevant because the average code base is the size of the linux kernel and is run by a diverse team of hundreds or thousands of programmers across the globe?
The problem doesn't occur with "average code bases" because you don't have projects with one-two programmers fighting over indent. If it happens in your "average code page" you should get yourself checked for a mental disorder.
>>23
Simple. Make one commit where you fix all the whitespace. Bam, solved in one commit, and all subsequent commits are clean. If you have multiple branches in action then you will be better off doing it to them at the same time though.
bump
>>30
bump what? they're dumb. case closed. fin.
python > lisp
python <====8 lisp
Since things are a bit quiet, perhaps a language war?
When Python:
...then perhaps -- as a language -- it will compare favourably to one of the Lisps.
In the meantime the only real competition for the awesome Crazy Language crown is Smalltalk, Forth and perhaps one of the Hindley-Milner languages (I think the Haskellers are batshit insane, but at least their insanity is interesting). Io may be another contender.
Unfortunately the direction Guido seems to want the language to go doesn't seem to be heading towards FP and Lispish constructs.
Guido seems very interested in making Basic. Basic is a fine language, it just isn't very powerful.
Someone's going to start a python clone; maybe a fork that extends the 2.6 semantics with more lispish features. I strongly suspect that the ast will simplify and we'll end up with an srfi49 implementation where define is spelled def...
Don't you hate code that's not properly indented? Making it part of the syntax guarantees that all code is properly indented! -- Guido van Rossum, Slashdot
Not that he's listening, but no, no I don't.
I use improperly indented code all the time as a visual cue to mark lines of code that are temporary - debugging lines that I'll remove soon, quick kludges, tests, that kind of thing. Making those stand out and look ugly really helps.
He also said:
"one of my reasons against adding Scheme-style continuations to the language is that it can't be implemented in a JVM. I find the existence of Jython very useful because it reminds me to think in terms of more abstract language semantics, not just implementation details."
You can't appeal to him as an authority because he's wrong twice as often as he's right.
> "one of my reasons against adding Scheme-style continuations to the language is that it can't be implemented in a JVM"
Someone best let the Scala developers know they're violating the laws of computation, then.
Or are Responders not Scheme-style?
Don't even need to go that far. SISC supports the entire R5RS and runs on Java.
> becomes homoiconic
In other words, "becomes Lisp"
> gets conditions
Conditions are just syntactic sugar for continuations.
> doesn't conflate variable definition with assignment
In Python, there is no such thing as variable definition.
> gets real lambdas
Explain how lambda is lacking compared to Lisp's? Python's lambda contains one expression, the same as Lisp. It's easy enough to write entire applications using lambda instead of def, if you prefer that style.
> develops better metaprogramming than that ugly class hackery
Compared to Lisp's macro madness, metaclasses are sane and beautiful. Though there are better metaprogramming features than metaclasses, such as type and function constructors.
> In other words, "becomes Lisp"
Lisp isn't the only homoiconic language.
> Conditions are just syntactic sugar for continuations.
Let me know when I can resume from an exception in Python. Let me know when CPython has continuations for that matter; right now the closest it comes is one-shot with generators (aka coroutines). Stackless has them, but nobody except CCP Games uses it.
> In Python, there is no such thing as variable definition.
They just appear out of thin air then? poof! No, the act of assigning to a variable creates it. That's a problem.
> Explain how lambda is lacking compared to Lisp's?
Well, for one, Lisp doesn't distinguish between statements and expressions. Python does. Python's lambdas cannot contain statements, so trivial things like assignment don't work (or if, or while, or...).
> It's easy enough to write entire applications using lambda instead of def, if you prefer that style.
Given the above limitations, I really like to see that.
> Conditions are just syntactic sugar for continuations.
CL has conditions, but no continuations. Python doesn't have callable continuations or conditions. Conditions work something like this:
handle Foo:
do stuff when Foo is signalled
restart Baz
do:
do stuff
r = signal Foo (Baz)
if r is Baz:
do stuff here
else:
never reachedbut it's admittedly ugly in this pseudo-python. I don't know if that can be improved; usually the problems with conditions are resolved by special-purpose macros for certain kinds of conditions (out of memory, file exists, etc), instead of using the primitive elements each time.
> In Python, there is no such thing as variable definition.
There is no such specific syntax. Variable definition is implicit in python, and it looks exactly the same as assignment. For example:
if x:
y = 1234
else:
y = 5678This is assignment. It defines it in the nearest def if necessary, but never any higher. That means something like this:
def foo(x):
y = 1234
def bar(z):
if x is z: y = 5678
return baris impossible. You need to use an extra reference (list) and that's ugly.
> Explain how lambda is lacking compared to Lisp's? Python's lambda contains one expression, the same as Lisp. It's easy enough to write entire applications using lambda instead of def, if you prefer that style.
It's not just lambda. It's Python's expressions that are lacking compare to lisp; it's a far less expressive language, and lambda is just one of the areas where it's really freakishly obvious to lispers.
> Stackless has them, but nobody except CCP Games uses it.
I use it every day. Maybe it's not big for hobbyists, but it's used often when a company needs heavy concurrency but can't use Erlang for whatever reason. PyPy also has support for continuations.
> They just appear out of thin air then? poof! No, the act of assigning to a variable creates it. That's a problem.
That's not a problem, that's a fundamental part of the language. All scopes are simple key:value mappings. If you had to declare variables, you'd also have to declare which values are allowed in a dictionary.
Variable allocation and declaration are separate issues.
> Well, for one, Lisp doesn't distinguish between statements and expressions. Python does. Python's lambdas cannot contain statements, so trivial things like assignment don't work (or if, or while, or...).
So don't use expressions. Since variable scopes are just dicts, anything you can do with assignments can be performed with dict methods. "if" statements work quite well, using either the modern <value> if <test> else <value>, old-style ((<test> and <value) or <value), or Smalltalk-style nested lambdas.
> Given the above limitations, I really like to see that.
Simple three-minute example: duplicate file scanner
> Maybe it's not big for hobbyists
Seriously now, it's not big for anyone outside of a few users. The vast majority of the Python-using population uses CPython. If I make my own fork of CPython that has pattern matching, can you rightfully say Python supports it?
> that's a fundamental part of the language.
Which is a problem. If you want to write to a variable in an outer scope you have to use something like the list hack. What if you assign to a mis-typed variable? Why does Python not have a block scope?
> All scopes are simple key:value mappings.
It is easy and inexpensive for the interpreter to check the existence of a hash key before assigning to it.
> Variable allocation and declaration are separate issues.
Indeed, and Python shouldn't conflate them.
> anything you can do with assignments can be performed with dict methods
I remember the last time I did that (I was mucking around with a proxy object). I'd really rather not; if assignment worked the code would be much clearer.
> using either the modern <value> if <test> else <value>
I didn't know about that. Thanks.
> old-style ((<test> and <value) or <value)
Let's leave the and-or trick dead and buried. ?: it ain't. D:
> Simple three-minute example: duplicate file scanner
Interesting. Thanks.
> Simple three-minute example: duplicate file scanner
>
> http://slickorslack.com/codes/73
That looks hideously unpythonic. You ought to be ashamed of yourself.
The "correct" answer to questions regarding Python's lack of power is that "There's one Right way to do it, and your way is hard to read"