com-nospam at ccraig.org (Christopher A. Craig) writes: > Douglas Alan <nessus at mit.edu> writes: > > What happened to giving programmers enough rope to hang themselves? > > What happened to the desire for flexibility and expressive power? > You can still get this, just not in Python. If you want a long rope, > you still have Lisp, C, C++, and Perl. A common answer I see in this newsgroup is that Python gives you a long rope. For instance, when people complain that they get bugs due to accidentally assigning to the wrong variable because variables don't have to be declared, people respond by saying that Python gives you a long rope. These people apparently they don't want to suffer, even for significantly increased reliability, the very minor limitations that variables declarations would entail. But then if someone complains that Python doesn't give them a long enough rope in some other area, the answer is that the proposed feature would allow poor programmers to write unreadable programms. C'mon guys, be consistent! Personally, I want a language that gives me all the rope I need, but doesn't make it a chore to write good programs. Writing good programs in Perl is a chore; hence Perl sucks. If Python had procedural macros, writing good programs would be less of a chore, not more of a chore. I don't want my language trying to force bad programmers to write good code. If this is some sort of official design goal of Python, then it is a misguided and impossible one. Regarding Perl, it is the worst attrocity foisted on humanity since the black plague. Regarding C and C++, they are not dynamic languages. Regarding Lisp, I'd be happy to use it if it there was a free implementation that had been ported to every platform known to man, started up in a small fraction of a second, was particularly well-suited to scripting, and came with the massive library and user-base that Python does. But there isn't. Besides, I have plenty of nits to pick with Lisp too. > One of the principles that makes Python so popular is its > simplicity. "Everything should be as simple as possible, but no simpler." > Any reasonably skilled programmer can learn every important part of > the Python syntax in less than a day. A macro capability doesn't detract from this. > Sure C++ is a more flexible language than Python. Not really. It's flexibility is along different axes. > But, I have read the entire language reference for Python, it took a > couple hours; it would take me a couple hours to carry the C++ > language reference up to my 4th floor desk. I have never seen a > Python program that I couldn't sit down and read with little effort; > I rarely see a Perl program that I can. That's because Perl is the worst attrocity foisted on humanity since the black plague. > If you go adding macros to Python then you remove that simplicity. Any feature added a language makes the language less simple. Python is hardly a simple language anymore. It has a simple core, and that's very important. C++ and Perl have no simple cores (unless, for C++, you just stick to the C core). Every feature in these languages interacts with other features in strange ways, so you better understand the whole thing or you're asking for trouble. The motto of the language "Logo" was "no threshold, no bounds". This should be the motto of any langauge. A language should be easy to learn, but offer untold power. If Python had procedural macros, the language wouldn't be any harder to learn since this is not something a newbie would have to worry about for quite some time. I programmed quite happily in Lisp for more than a year without every worrying myself about how macros worked. But when I needed them, there they were. > You would make it so that any programmer can add arbitrary levels of > complexity to the syntax used in the program, and thus before reading > through code a programmer would have to read and understand the macros > used. A bad programmer has many tools available to him in Python, as it is, to make hard to understand code. I don't think it would go over well to remove useful features from the language to prevent this. > You can do this now by passing your program through m4 before Python > parsing it, M4 is a far cry from procedural macros. > but you wouldn't be programming in Python. And that > really is the point. Lisp didn't always have macros. But when they added them, it was still Lisp. |>oug
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