7 ms·

Agreed on every point, but I have to add a few things. - No real metaprogramming is a big problem for me. I want decorators to be able to manipulate the AST (

by daeken 17y ago

Agreed on every point, but I have to add a few things. - No real metaprogramming is a big problem for me. I want decorators to be able to manipulate the AST (I'm playing around with a way to do this: http://pastie.org/490836 http://pastie.org/490836 ) at the very least, and preferably real macros that can add new syntax. - Anonymous functions. I want real anonymous functions in Python, not lambda or anything like it. After a long time of hacking Nemerle code, I go back to Python and cry when I write lambdas. - Tail call recursion. Another functional programming thing that I'd absolutely love to see, just because it's so incredibly useful. Sadly, I know none of these will likely be implemented, as they're just not the Python way, but it doesn't change the fact that I love Python and would love to see these changes.

jnoller 17y ago
You see, if I were someone else, I might have pointed out all three points you list here, except I don't like all three of them :) I can see the argument for tail recursion - except that people who really love tail recursion seem to over use it (all good things in moderation). Still, I might like to see it in core; as for the other two, well - I don't even like lambdas, even as implemented in python (I think it might be a taste thing) and metaprogramming in the wrong hands is painful at best.
- gchpaco 17y ago
  Python as a language is so good that it becomes difficult to concisely describe why one wants metaprogramming. Generally speaking the reason one wants metaprogramming is to make the language of the domain you are thinking in and the language of the program as close as possible. So in banking we talk of accounts and transactions, not rows in a database. The need for this is so acute in Java it makes my teeth ache. Python is much more flexible; so much so that this becomes a difficult to explain urge, but it is still there. An example may be worthwhile. Consider SCons. Know anybody who uses it? There were a number of issues going on there (one of which was the general lameness of the Cons infrastructure--I'm sorry, I use the fact that make is a dependency computation engine, all the damned time, and ant and Cons and every other lame-ass "make replacement" that doesn't do this drives me up the wall) but IMHO the decision to make the syntax raw, executable Python code did not help. Now, granted, I consider myself a Lisp hacker, so maybe you'll just write this off entirely. But the key thing I have with Python, the key complaint I have, is that there are fundamental domain assumptions baked into the language that are sometimes appropriate (numpy is an enormous success, for example) and sometimes aren't (SCons, HTML template system du jour, configuration files, etc.), and I can't change them. Edit: an example came to me as I thought about this. So how's this as an explanation: in Java and Python, you can have as many nouns as you want. You can have as many verbs as you like. Adverbs are hard. Pronouns are almost impossible. And syntax? Forget it. It makes for an interesting contrast with mathematical notation, which takes time to learn and is inconsistent and only governed by social constraints but, at its best, is so good at communicating information that it fades into the background, just as = or 0 do.
  - jnoller 17y ago
    "Now, granted, I consider myself a Lisp hacker, so maybe you'll just write this off entirely." Now why would I write you off? :) I would like to see examples of what you're talking about however.
    - gchpaco 17y ago
      It's hard to quantify the benefits of system-qua-language without pointing you at Maxima or something (a computer algebra system well integrated with the underlying programming language). But here's a small example of the sort of thing I want to do with metaprogramming in Python. In C, C++, Java, and almost every commonly used language, parsing is usually done by writing a parser in a different language (yacc, ANTLR, whatever) which is then compiled to source code which is then compiled again. In a language with good metaprogramming facilities, the parser is written in the language; macros in Lisp-descendants, parser combinators in Haskell (itself probably about as flexible syntactically as you can get without actually having macros), whatever the hell Forth people call it, etc. This has, at least in theory (a lot of parser combinators in Haskell are impossibly naive, but that's an implementation detail or so I claim), no demerits over the C approach, but it integrates better with the language. This is not just a difference in taste, either. As a different example, Python had the problem wherein regexp strings were getting impossibly difficult to write. They added raw strings to the language to get around this. Schemers had the same problem, but one of them (Shivers) wrote a regexp language with escapes to the underlying Scheme implementation that compiled to regexps but made it possible to read them like they were any other kind of code, instead of weird terse utterances. You can still do the weird terse utterances if you like, but you can also write regexps like they were any other kind of Scheme code. When I was doing web programming in 2000, I hacked an SQL generation library in Python. It felt awkward to use and was verbose but I deemed it better than being paranoid about SQL injection attacks. If I had good metaprogramming facilities, I might have been able to implement the database comprehensions they have in C# now (the LINQ facilities). I probably wouldn't have decided to do so, because even in 2000 I had some taste, but I could have and experienced all the benefits the C# people claim to have. Another thing that came up during that same project was that I was trying to do what we now call continuation-based web frameworks in a language with no explicit continuation apparatus. This is similar to what PG described doing in Viaweb, but I didn't have a metaprogramming setup to help me out with it. I did the CPS conversion manually, and lemme tell you it was a royal pain in the arse and contributed significantly to the difficulty in implementing that setup. If I had good metaprogramming frameworks I could CPS convert the code automatically, as PG did. Would you like more? :)
jamongkad 17y ago
You're right what you've just outline are features that the community as a whole show so much aversion to. I guess they believe functional programming does not help with code readability. But I do hope that Python's metaprogramming features get more attention and multi-line lambdas would be nice but not necessary. I can live without TCO as well.
- jnoller 17y ago
  Yes, I suspect you would find that many within the community do find functional programming constructs do not assist in readability of the code. That group would also include me, while I might use some FP things every so often, I tend to shy away from them for that express reason.
  - ubernostrum 17y ago
    Meanwhile I simply shy away from the idea that the things I do in my code can be so neatly classified :)
- tmoertel 17y ago
  > I guess they believe functional programming does not help with code readability. What does that statement say more about, the Python community or the readability of functional programming?
  - jamongkad 17y ago
    I think it's a little bit of both. Functional style in languages such as Scheme, Lisp and the like tend to nest functions. Which makes readability a bit hard, which goes against the design goal of Python in the first place.
    - tmoertel 17y ago
      > Functional style in languages such as Scheme, Lisp and the like tend to nest functions. Which makes readability a bit hard, ... Hard for whom? People unskilled in functional programming? People skilled only in the English language find Greek "a bit hard", too. This truth is so well established that it forms the heart of a colloquial expression, one used to confess a speaker's inability to understand a subject in general: "It's all Greek to me!" And yet I trust that you haven't fallen into the trap of thinking that this expression, no matter how much it is repeated by English-language speakers, reflects poorly on the Greek language, itself. The ancient Greeks, after all, didn't seem to have any difficulty using their language to great effect, and with remarkable clarity.
silentbicycle 17y ago
Lua is very similar to Python (with more Javascript and Scheme, perhaps), but with real lambdas and tail calls. It's a different language with different trade-offs (it's standard library is tiny; embedding is its primary niche), but its dev team very much shares Guido's sentiment of "keep it simple and don't clutter the core language trying to make it everything to everyone". If you want to see the parallel evolution of language with very similar values but a slightly different set of features, it's a good one to check out.
- stcredzero 17y ago
  Lua is also impressively fast!
  - silentbicycle 17y ago
    I think Lua's biggest assets are how easily it can be used with C (which is where a lot of the speed comes from), and how incredibly portable it is. The language is freaking tiny, it will run on anything with a C compiler, and it usually builds in just a few seconds. While it doesn't have a huge standard library, there are tons of C libraries, and writing Lua wrappers for them is dead easy. Also, LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html) rules. Edit: That's what I meant, that you can move code over to C. That Lua itself is faster than the other major scripting languages is just a nice perk. :) (Also, there's LuaJIT, but only on i386.)
    - davidw 17y ago
      > easily it can be used with C (which is where a lot of the speed comes from) I don't think the two are necessarily related: Tcl has a great C API, but is middle of the pack in terms of its own speed. Of course a good C API is an essential 'out' for scripting languages, so that you can write stuff in C where needed. Indeed, the idea behind Tcl was to not care much about Tcl's speed, because performance critical stuff would be done in C anyway.
    - jnoller 17y ago
stcredzero 17y ago
I want decorators to be able to manipulate the AST I've thought of a way to do this in Smalltalk. http://news.ycombinator.com/item?id=622773 http://news.ycombinator.com/item?id=622773 Using #perform: style calls as decorators is ugly, though. Instead of that, one could utilize a MethodWrapper instead. http://www.refactory.com/Software/MethodWrappers/ http://www.refactory.com/Software/MethodWrappers/ But instead of executing code before & after the method, you'd be executing an alternative version of it instead.
ubernostrum 17y ago
I can't help thinking that certain languages impose their own variation of the Blub syndrome, namely in leading to the conclusion that one particular way of thinking about programming should be the One True Way to think about programming. Various Lisps, for example, produce the well-known "when all you have is an AST, everything looks like a macro" syndrome; Scheme inculcates a desire to use tail recursion even when counting on one's fingers; etc. This is, incidentally, precisely the same criticism proponents of functional programming typically level at proponents of, say, object-oriented programming. And I've no doubt that, if the popularities of those paradigms were reversed, comments like this one would be the usual snipe from OOP fans at their "unenlightened" functional brethren and sistren. At any rate, I'm very far from being convinced that this is a healthy thing for either the programmers affected, or for the state of the art in general.
- halo 17y ago
  On the other hand, you get complaints over the complexity of C++ because it doesn't really have 'One True Way' to do anything. Ultimately, it's a case of trade-offs, and accepting that can't win them all.
- j_baker 17y ago
  I agree 100%. While I would like to see macros, I think they're more in the "That would be so cool!" category than the "This is really necessary" category.
- rw 17y ago
  When you can modify the semantics of the entire language, you can use any paradigm you want.
  - sethg 17y ago
    ...which is great, until you want to use one paradigm and you also want to take advantage of a certain library, and you discover that the library uses a completely different paradigm. Either you put up with an impedence mismatch between your code and the library, or you discover that in this language all paradigms are equal but some are more equal than others.

by daeken 17y ago

jnoller 17y ago

You see, if I were someone else, I might have pointed out all three points you list here, except I don't like all three of them :) I can see the argument for tail recursion - except that people who really love tail recursion seem to over use it (all good things in moderation). Still, I might like to see it in core; as for the other two, well - I don't even like lambdas, even as implemented in python (I think it might be a taste thing) and metaprogramming in the wrong hands is painful at best.

gchpaco 17y ago
Python as a language is so good that it becomes difficult to concisely describe why one wants metaprogramming. Generally speaking the reason one wants metaprogramming is to make the language of the domain you are thinking in and the language of the program as close as possible. So in banking we talk of accounts and transactions, not rows in a database. The need for this is so acute in Java it makes my teeth ache. Python is much more flexible; so much so that this becomes a difficult to explain urge, but it is still there. An example may be worthwhile. Consider SCons. Know anybody who uses it? There were a number of issues going on there (one of which was the general lameness of the Cons infrastructure--I'm sorry, I use the fact that make is a dependency computation engine, all the damned time, and ant and Cons and every other lame-ass "make replacement" that doesn't do this drives me up the wall) but IMHO the decision to make the syntax raw, executable Python code did not help. Now, granted, I consider myself a Lisp hacker, so maybe you'll just write this off entirely. But the key thing I have with Python, the key complaint I have, is that there are fundamental domain assumptions baked into the language that are sometimes appropriate (numpy is an enormous success, for example) and sometimes aren't (SCons, HTML template system du jour, configuration files, etc.), and I can't change them. Edit: an example came to me as I thought about this. So how's this as an explanation: in Java and Python, you can have as many nouns as you want. You can have as many verbs as you like. Adverbs are hard. Pronouns are almost impossible. And syntax? Forget it. It makes for an interesting contrast with mathematical notation, which takes time to learn and is inconsistent and only governed by social constraints but, at its best, is so good at communicating information that it fades into the background, just as = or 0 do.
- jnoller 17y ago
  "Now, granted, I consider myself a Lisp hacker, so maybe you'll just write this off entirely." Now why would I write you off? :) I would like to see examples of what you're talking about however.
  - gchpaco 17y ago
    It's hard to quantify the benefits of system-qua-language without pointing you at Maxima or something (a computer algebra system well integrated with the underlying programming language). But here's a small example of the sort of thing I want to do with metaprogramming in Python. In C, C++, Java, and almost every commonly used language, parsing is usually done by writing a parser in a different language (yacc, ANTLR, whatever) which is then compiled to source code which is then compiled again. In a language with good metaprogramming facilities, the parser is written in the language; macros in Lisp-descendants, parser combinators in Haskell (itself probably about as flexible syntactically as you can get without actually having macros), whatever the hell Forth people call it, etc. This has, at least in theory (a lot of parser combinators in Haskell are impossibly naive, but that's an implementation detail or so I claim), no demerits over the C approach, but it integrates better with the language. This is not just a difference in taste, either. As a different example, Python had the problem wherein regexp strings were getting impossibly difficult to write. They added raw strings to the language to get around this. Schemers had the same problem, but one of them (Shivers) wrote a regexp language with escapes to the underlying Scheme implementation that compiled to regexps but made it possible to read them like they were any other kind of code, instead of weird terse utterances. You can still do the weird terse utterances if you like, but you can also write regexps like they were any other kind of Scheme code. When I was doing web programming in 2000, I hacked an SQL generation library in Python. It felt awkward to use and was verbose but I deemed it better than being paranoid about SQL injection attacks. If I had good metaprogramming facilities, I might have been able to implement the database comprehensions they have in C# now (the LINQ facilities). I probably wouldn't have decided to do so, because even in 2000 I had some taste, but I could have and experienced all the benefits the C# people claim to have. Another thing that came up during that same project was that I was trying to do what we now call continuation-based web frameworks in a language with no explicit continuation apparatus. This is similar to what PG described doing in Viaweb, but I didn't have a metaprogramming setup to help me out with it. I did the CPS conversion manually, and lemme tell you it was a royal pain in the arse and contributed significantly to the difficulty in implementing that setup. If I had good metaprogramming frameworks I could CPS convert the code automatically, as PG did. Would you like more? :)

jamongkad 17y ago

You're right what you've just outline are features that the community as a whole show so much aversion to. I guess they believe functional programming does not help with code readability. But I do hope that Python's metaprogramming features get more attention and multi-line lambdas would be nice but not necessary. I can live without TCO as well.

jnoller 17y ago
Yes, I suspect you would find that many within the community do find functional programming constructs do not assist in readability of the code. That group would also include me, while I might use some FP things every so often, I tend to shy away from them for that express reason.
- ubernostrum 17y ago
  Meanwhile I simply shy away from the idea that the things I do in my code can be so neatly classified :)
tmoertel 17y ago
> I guess they believe functional programming does not help with code readability. What does that statement say more about, the Python community or the readability of functional programming?
- jamongkad 17y ago
  I think it's a little bit of both. Functional style in languages such as Scheme, Lisp and the like tend to nest functions. Which makes readability a bit hard, which goes against the design goal of Python in the first place.
  - tmoertel 17y ago
    > Functional style in languages such as Scheme, Lisp and the like tend to nest functions. Which makes readability a bit hard, ... Hard for whom? People unskilled in functional programming? People skilled only in the English language find Greek "a bit hard", too. This truth is so well established that it forms the heart of a colloquial expression, one used to confess a speaker's inability to understand a subject in general: "It's all Greek to me!" And yet I trust that you haven't fallen into the trap of thinking that this expression, no matter how much it is repeated by English-language speakers, reflects poorly on the Greek language, itself. The ancient Greeks, after all, didn't seem to have any difficulty using their language to great effect, and with remarkable clarity.

silentbicycle 17y ago

Lua is very similar to Python (with more Javascript and Scheme, perhaps), but with real lambdas and tail calls. It's a different language with different trade-offs (it's standard library is tiny; embedding is its primary niche), but its dev team very much shares Guido's sentiment of "keep it simple and don't clutter the core language trying to make it everything to everyone". If you want to see the parallel evolution of language with very similar values but a slightly different set of features, it's a good one to check out.

stcredzero 17y ago
Lua is also impressively fast!
- silentbicycle 17y ago
  I think Lua's biggest assets are how easily it can be used with C (which is where a lot of the speed comes from), and how incredibly portable it is. The language is freaking tiny, it will run on anything with a C compiler, and it usually builds in just a few seconds. While it doesn't have a huge standard library, there are tons of C libraries, and writing Lua wrappers for them is dead easy. Also, LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html) rules. Edit: That's what I meant, that you can move code over to C. That Lua itself is faster than the other major scripting languages is just a nice perk. :) (Also, there's LuaJIT, but only on i386.)
  - davidw 17y ago
    > easily it can be used with C (which is where a lot of the speed comes from) I don't think the two are necessarily related: Tcl has a great C API, but is middle of the pack in terms of its own speed. Of course a good C API is an essential 'out' for scripting languages, so that you can write stuff in C where needed. Indeed, the idea behind Tcl was to not care much about Tcl's speed, because performance critical stuff would be done in C anyway.
  - jnoller 17y ago

stcredzero 17y ago

I want decorators to be able to manipulate the AST I've thought of a way to do this in Smalltalk. http://news.ycombinator.com/item?id=622773 http://news.ycombinator.com/item?id=622773 Using #perform: style calls as decorators is ugly, though. Instead of that, one could utilize a MethodWrapper instead. http://www.refactory.com/Software/MethodWrappers/ http://www.refactory.com/Software/MethodWrappers/ But instead of executing code before & after the method, you'd be executing an alternative version of it instead.

ubernostrum 17y ago

I can't help thinking that certain languages impose their own variation of the Blub syndrome, namely in leading to the conclusion that one particular way of thinking about programming should be the One True Way to think about programming. Various Lisps, for example, produce the well-known "when all you have is an AST, everything looks like a macro" syndrome; Scheme inculcates a desire to use tail recursion even when counting on one's fingers; etc. This is, incidentally, precisely the same criticism proponents of functional programming typically level at proponents of, say, object-oriented programming. And I've no doubt that, if the popularities of those paradigms were reversed, comments like this one would be the usual snipe from OOP fans at their "unenlightened" functional brethren and sistren. At any rate, I'm very far from being convinced that this is a healthy thing for either the programmers affected, or for the state of the art in general.

halo 17y ago
On the other hand, you get complaints over the complexity of C++ because it doesn't really have 'One True Way' to do anything. Ultimately, it's a case of trade-offs, and accepting that can't win them all.
j_baker 17y ago
I agree 100%. While I would like to see macros, I think they're more in the "That would be so cool!" category than the "This is really necessary" category.
rw 17y ago
When you can modify the semantics of the entire language, you can use any paradigm you want.
- sethg 17y ago
  ...which is great, until you want to use one paradigm and you also want to take advantage of a certain library, and you discover that the library uses a completely different paradigm. Either you put up with an impedence mismatch between your code and the library, or you discover that in this language all paradigms are equal but some are more equal than others.