Re: Indentations and future evolution of languages
2009/3/8 Tim Roberts : > Tim Rowe wrote: >> >>I don't think the article is right that "it's silly to have some >>expression/statement groupings indentation based and some grouped by >>enclosing tokens" -- provided it's done right. The OCAML-based >>language F# accepts OCAML enclosing tokens, but if you mark the groups >>with indentation they're not necessary (but still legal). That seems >>to me to work pretty cleanly. > > Boy, I really want to like F# -- a lot of smart people have worked on it -- > but every program I write is completely incomprehensible to me a week > later. > > The more I look around, the more I like Python. Indentation works just fine in Python, too, just in case anybody hadn't noticed ;-) My point was that Python isn't alone on that whitespace-significant plateau. F# is up here too. And so is FORTRAN, of course. We try to ignore FORTRAN, but the distance we are able to edge away from it goes to show how big the plateau is. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
On Tue, Mar 10, 2009 at 12:39 PM, wrote: > > > John> The only complaint I have there is that mixing tabs and spaces for > John> indentation should be detected and treated as a syntax error. > > Guido's time machine strikes again (fixed in Python 3.x): > > % python3.0 ~/tmp/mixed.py > File "/home/titan/skipm/tmp/mixed.py", line 3 > print(a) > ^ > TabError: inconsistent use of tabs and spaces in indentation Or just use the '-tt' command line switch to force indentation consistency: ksm...@work:~/tmp [366]$ python2.5 -tt mixed.py File "mixed.py", line 6 print a ^ TabError: inconsistent use of tabs and spaces in indentation Kurt -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
John> The only complaint I have there is that mixing tabs and spaces for John> indentation should be detected and treated as a syntax error. Guido's time machine strikes again (fixed in Python 3.x): % python3.0 ~/tmp/mixed.py File "/home/titan/skipm/tmp/mixed.py", line 3 print(a) ^ TabError: inconsistent use of tabs and spaces in indentation Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
Kay Schluehr wrote: On 6 Mrz., 02:53, bearophileh...@lycos.com wrote: This is an interesting post, it shows me that fitness plateau where design of Python syntax lives is really small, you can't design something just similar: http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort... Living on a small fitness plateau isn't good, even if it's very high, because it's evolutionary unstable :-( Indentation-wise Haskell syntax seems one of the very few local maxima that is close enough to the little fitness plateau where Python is. Bye, bearophile Here is a somewhat longer comment: http://fiber-space.de/wordpress/?p=121 Take it with a grain of salt and have much fun. Python already has nested functions. So anything for which you really need a lambda function can already be done. You just have to name the function. This isn't a popular feature, because in a language with no declarations to determine scope, having too many nested scopes is confusing. But it's there. As for Python indentation, that seems to work reasonably well. The only complaint I have there is that mixing tabs and spaces for indentation should be detected and treated as a syntax error. (Whether to use tabs or spaces is a religious argument, but mixing them is clearly wrong, and results in non-visible bugs. CPython should enforce that.) John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
Tim Rowe wrote: > >I don't think the article is right that "it's silly to have some >expression/statement groupings indentation based and some grouped by >enclosing tokens" -- provided it's done right. The OCAML-based >language F# accepts OCAML enclosing tokens, but if you mark the groups >with indentation they're not necessary (but still legal). That seems >to me to work pretty cleanly. Boy, I really want to like F# -- a lot of smart people have worked on it -- but every program I write is completely incomprehensible to me a week later. The more I look around, the more I like Python. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
On 6 Mrz., 02:53, bearophileh...@lycos.com wrote: > This is an interesting post, it shows me that fitness plateau where > design of Python syntax lives is really small, you can't design > something just similar: > > http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort... > > Living on a small fitness plateau isn't good, even if it's very high, > because it's evolutionary unstable :-( > Indentation-wise Haskell syntax seems one of the very few local maxima > that is close enough to the little fitness plateau where Python is. > > Bye, > bearophile Here is a somewhat longer comment: http://fiber-space.de/wordpress/?p=121 Take it with a grain of salt and have much fun. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
2009/3/6 : > This is an interesting post, it shows me that fitness plateau where > design of Python syntax lives is really small, you can't design > something just similar: > > http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html I don't think the article is right that "it's silly to have some expression/statement groupings indentation based and some grouped by enclosing tokens" -- provided it's done right. The OCAML-based language F# accepts OCAML enclosing tokens, but if you mark the groups with indentation they're not necessary (but still legal). That seems to me to work pretty cleanly. -- Tim Rowe -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
Steven D'Aprano wrote: You can have one, or the other, but not both, unless you're willing to have a "practicality beats purity" trade-off and create a second way of grouping blocks, I propose /* and */ as block delimiters. There, you have auto-documenting code, ahah! -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
On 6 Mrz., 02:53, bearophileh...@lycos.com wrote: > This is an interesting post, it shows me that fitness plateau where > design of Python syntax lives is really small, you can't design > something just similar: > > http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mort... > > Living on a small fitness plateau isn't good, even if it's very high, > because it's evolutionary unstable :-( > Indentation-wise Haskell syntax seems one of the very few local maxima > that is close enough to the little fitness plateau where Python is. > > Bye, > bearophile This is all derived from a blog post about a language no one cares about? -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
bearophileh...@lycos.com writes: > Indentation-wise Haskell syntax seems one of the very few local maxima > that is close enough to the little fitness plateau where Python is. It is odd, the article claims indentation-aware syntax only works in languages that separate statement and expressions, but also mentions Haskell, which doesn't have such separation. Even things like do-blocks are just syntax sugar for function application. -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
bearophileh...@lycos.com wrote: Living on a small fitness plateau isn't good, even if it's very high, because it's evolutionary unstable :-( Actually I think, in biological sense speaking [citation needed], if one path has an advantage over the other path, even if the other path is in majority, it will grow over time in percentage and offshoot more sub-paths the other path. -- mph -- http://mail.python.org/mailman/listinfo/python-list
Re: Indentations and future evolution of languages
bearophileh...@lycos.com wrote: > This is an interesting post, it shows me that fitness plateau where > design of Python syntax lives is really small, you can't design > something just similar: > > http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html > > Living on a small fitness plateau isn't good, even if it's very high, > because it's evolutionary unstable :-( You're assuming that (1) evolutionary changes occur at random, and (2) there's value in there being many similar species/languages sharing a fitness plateau. Neither of those necessarily follow. Few languages (if any) undergo random mutation -- a better model for programming language evolution is directed mutation and artificial selection rather than evolution by natural selection with random mutation. It's very rare (non-existent) for two species to share a niche, and therefore co-exist in a fitness plateau. Due to network effects, much the same happens for languages: a few popular languages (e.g. C, Java, Perl) overwhelmingly capture a market. Given the popularity of Python, "Python-like" languages will be doomed to tiny niches -- unless the language discovers some sort of distinguishing feature that shifts them into a different, but similar, fitness plateau, where they can capture a market large enough to get their own network effort, or if the original language becomes moribund. E.g. some hypothetical Python clone with optional braces might take off, thus proving that all the l^H users begging for braces were right. Or the shift to multi-core processors and Guido's reluctance/inability to remove the GIL might doom Python to only being useful on an ever-shrinking pool of single-core CPUs. > Indentation-wise Haskell syntax seems one of the very few local maxima > that is close enough to the little fitness plateau where Python is. If the article is right, there is a fundamental incompatibility between indentation-sensitive languages and languages with multi-line anonymous blocks. You can have one, or the other, but not both, unless you're willing to have a "practicality beats purity" trade-off and create a second way of grouping blocks, and who knows whether that will turn out to *actually* be practical? That doesn't say anything about the narrowness of the Python fitness plateau. There could be room for a dozen languages with the same approach to indentation as Python. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Indentations and future evolution of languages
This is an interesting post, it shows me that fitness plateau where design of Python syntax lives is really small, you can't design something just similar: http://unlimitednovelty.com/2009/03/indentation-sensitivity-post-mortem.html Living on a small fitness plateau isn't good, even if it's very high, because it's evolutionary unstable :-( Indentation-wise Haskell syntax seems one of the very few local maxima that is close enough to the little fitness plateau where Python is. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
