Ok, I finally listened to the podcasts. Thanks for the pointer. That's the second good reference to that series I've gotten, I'm going to keep an eye on them.
> While I agree that continuations are insanely powerful, I likewise > prefer generators and iterators to continuations. Why? When all you need is a generator or iterator, it's simpler to deal with and easier to debug. Continuations or closures give you the power to implement a iterator generator or generator generator to have the syntactic sugar and debugable manifest state. Iterators and Generators do not provide the general expressivity of anonymous functions & closures for delegation in frameworks. > To me the ability to tackle difficult constructs is less important > than the ability to provide clear debugging information if things go > wrong. And their power and flexibility causes continuations to lose > on that metric. No disagreement that usabilty counts. And Perl's *perceived* lack of readibility is costing us in the popularity race. Readibilty is sometimes perceived as a tradeoff against expressivity (with Lisp, Cobol, Fortran, and APL as the usual comparison), but with modern design, it should be orthogonal (as in Haskell). Perl appears a trifle old-school in getting expressivity from golfably rich operators and regex extensions. But while one is measuring the expressive power of a language, the _ability_ do do _everything_ closures and anonymous subs and code-blocks as arguments is the measure of "same power as". Guido admits he didn't intentionally copy Lisp, since he doesn't know Lisp. For a language designer to say that feels like an accountant saying "I was never very good at math" - it may be acceptable in ignorant society, but not in his field (or any truly intellectual company). This may explain his erroneous belief that having generators and iterators is of equivalent strength to anonymous code blocks (and thus closures which he won't even name). He says continuations make his head explode, yet he can claim generators are an 80% solution for what you'd want continuations for. If they make his head explode, why does he believe the 20% he can imagine using them for is all, there isn't another 200%? He doesn't get the abstract/delegation uses of anonymous blocks and encapsulation and currying uses of closures, which will raise the level of discourse again after iter/gen/lazy-eval. The good news is he doesn't like them and doesn't understand why non-iter-gen closures add power to frameworks, so we'll have that point of difference. The bad news is the average Analyst or IT magazine reviewer doesn't grok closures or framework-fu any better than the average Perl programmer, who can benefit from their being buried in a Damian module without knowing Latty's forethought to allow closures made the Damian-fu possible. But beginners and dabblers never get beyond iterator/generators, and a sugary overly specific syntax for those will *seem* more powerful than an obscure emergent idiom of greater intrinsic expressivity. I've heard his point that Patterns is a sign of language weakness elsewhere. Perl & Python are quite similar in comparison to Java there. He commented that the indentation-as-syntax wasn't even his brainstorm, he carried that over from the ABC language. That is one solution to the 'my eye sees the indents, the compiler sees the brackets' problem. Using an editor with blink-brackets, jump-match, and/or perl-tidy or other re-formatter are other solutions. I don't take to one-size-fits all well. The idea that 1,000 line perl scripts are a proof of the language strength is strange. I suppose there might be less cowboy spaghetti code in Python, since the B&D culture may self select for structured conformists, but that doesn't mean a good code can't use it to build something big - just that you may not be able to maintain it with dime a dozen interchangeable disposable generic maintenance drones. So? One PM'er still costs less than 12 Java grinders or two python One True Way'ers. TIMTOWTDI is freedom. Freedom scares some people ... especially Management. Python doesn't need shop coding standards memo or a PBP book - it's Guido's way or the highway, enforced by the compiler. "Readibilty" is one of Guido's key issues. It's a real issue in several different areas: beginners' learning curve; part-time users (who either don't code or use other languages for other things but need some P-fu once in a while), and Legacy Maintenance. Readability is why Python is rapidly replacing both bash and Perl for Linux install and config scripting, e.g., per order of Ubuntu's Mark Shuttleworth. Guido may think Python is winning as a devlopment language, but where it really is gaining mind-share is as a entry-level scripting language -- it's replacing BASH. -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
