"Douglas Alan" <nessus at mit.edu> wrote in message news:lcu23dvqrq.fsf at gaffa.mit.edu... > "Alex Martelli" <aleaxit at yahoo.com> writes: > > > One genius clamored for a huge new mechanism that would at last, in > > the Plenitude of Glory, let him write "let x = y" versus "set x = y" > > so he'd get ``declarations'' -- and then, when somebody showed him > > how easily he could set things up so as to write "let.x = y" and > > "set.x = y", he claimed his coworkers would kill him if he > > programmed that way. Well isn't that obvious, that being able to > > have a SPACE there instead of a PERIOD is the be-all, end-all of > > programming?! Isn't it _absolutely_ obvious that placing a period > > there will lead to justified homicide...? > > Thank you, Mr. Martelli, for the deference that you show to others > whose opinions differ. You are a model for us all. You're welcome! And I very much look forward to the PEP and patches where you'll show us all the true beauty of the new mechanism you have envisaged in all of its glory -- please be sure to include the examples that you were using to motivate it, such as this let/set masterpiece, and, of course, "do/until" (which was, as surely you will recall, the subject heading of one of the threads in which you were regaling us with your masterful advocacy) as its true crown. > I'd like to point out, however, that you have reduced my position to > an absurdity. There are a number of other reasons to avoid the > proposed solution than only the difference between a "." and a space. Indeed, I agree on the latter -- the key reason being that having no declarations is one of Python's strengths, and issues such as typo-checking best addressed by other tools separate from the compiler (such as PyChecker, for example), without adding any complexity to the Python language itself. But then, _I_ wasn't the one clamoring for additions to Python in order to fix alleged problems with it, and ignoring such possibilities as operating at the tools-level and keeping the language simpler. So, I have to bashfully decline your kind attribution to me of the absurdity that does inhere in this position -- I cannot take credit for this delightful nonsense, any more than I can for "Alice in Wonderland" and other masterpieces of this genre; a mere journeyman in the pearly vaults of the Absurd, I always defer to acknowledged True Masters of the field. > panelists indicated that hygienic macros are an *essential* feature > for future languages in order to allow for them to grow and to > adequately support solving domain-specific problems. Domain-specific > languages are essential, they said, for reducing complexity in many > difficult problems, and hygienic macros are one of the best ways of Two interestingly embricated claims. I do see the interest in separate, Python-like languages such as PyHTML -- domain specific and all. But there seems to be an underlying hypothesis here that it's best to do EVERYTHING in ONE language, including implementing other ones on top of it. One of Python's specific design choices was to reject that: it was deliberately designed to cooperate well with other tools (and languages in particular) instead. Rather than stretching one language to the point where it covers EVERY important design goals (including this idea of domain-specificness, but also classic ones such as very high ability to be optimized), as most other major languages seem to have set out to do from different starting points, Python chose instead to stay *SIMPLE*, pragmatic, and highly able to interoperate with other tools to provide missing pieces of the software development puzzle. Why would a "future language" have to be all things to all people (like was the design goal of, say, 90% of existing ones), rather than flourish in the 'niche' of doing many things well and leaving it to other tools to cover the rest? PyHTML is one example of how that might work -- and no doubt, if that is the direction, Python specs may change _a little_ to make life simpler for the *other tools* (NOT Python itself) that it cooperates with. It seems to me no convincing case has ever been made that a single language MUST do everything well. Many widespread languages aim at that -- Common Lisp, Dylan, C++, Eiffel, Java, just to name a few. Python doesn't. I prefer Python. Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4