From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-30 06:44:29 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!headwall.stanford.edu!feeder.via.net!cyclone-sf.pbi.net!206.13.28.183!nnrp5-w.sbc.net.POSTED!not-for-mail Message-ID: <3B6565D7.9C7407B9@sneakemail.com> From: Russ Paielli <18k11tm001@sneakemail.com> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3-20mdk i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: How to make Ada a dominant language References: <9k36ae$138k$1@pa.aaanet.ru> <3B6557D2.DC2F9F2F@sneakemail.com> <9k3mhe$1nuk$1@pa.aaanet.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Jul 2001 06:49:12 -0700 NNTP-Posting-Host: 63.194.87.148 X-Complaints-To: abuse@pacbell.net X-Trace: nnrp5-w.sbc.net 996500668 63.194.87.148 (Mon, 30 Jul 2001 06:44:28 PDT) NNTP-Posting-Date: Mon, 30 Jul 2001 06:44:28 PDT Organization: SBC Internet Services Xref: archiver1.google.com comp.lang.ada:10744 Date: 2001-07-30T06:49:12-07:00 List-Id: Gary Lisyansky wrote: > > "Russ Paielli" <18k11tm001@sneakemail.com> wrote in message > news:3B6557D2.DC2F9F2F@sneakemail.com... > > Gary Lisyansky wrote: > > > Ada is known to favour code reader over the code writer, while Python > tends > > > to be a typical "write only" language. > > > > Sorry, but that's just baloney. You must be confusing Python with Perl. > > It's not a baloney at all. To list but some elegant features, absence of > parameter type information makes the source code very difficult to read. > Mandatory placement of statements in lines and indentation rule make the > thing even worse to read (a li'l hint: some procedures and nested compound > statements may not fit into the height of the scrollable viewport of your > editor:-)). Given variables are typeless, even the world's most advanced > IDE won't give you a chance to understand what "someObject.doSomething" > really means and find the definition of doSomething(), for instance. I am obviously NOT suggesting for a second that Ada adopt Python's untyped variables. Are you deliberately trying to distort what I am proposing, or are you just completely failing to grasp it? > > > > > > > > Here are the syntax changes I propose: > > > > > > > > 1. Eliminate the "end" keyword and make the indentation structure an > > > > inherent part of the syntax, as in Python. > > > > > > This makes whitespace the part of the language syntax. In practice, it's > not > > > convenient, and adds *extremely nasty* tab/space problems. In common, > it's a > > > bug generator. > > > > Whitespace is already part of the language syntax. Don't believe me? > > Take all the whitespace out of your programs and see if they still work. > > Whitespace in well- designed languages is used as separator only. In Python > and other indentation- based languages it is effectively a keyword, and a > one without well- defined meaning. "Four whitespaces" may, depending on the > situation mean just the next statement in a block, or the end of a compound > statement, or may be used to distinguish between a method of a class and a > non- component function. What's that, programming using innuendoes? > Add here bugs like mis- indented statement that may keep the code still > formally valid but screwed up logically. Would you call ";" a "keyword"? As I wrote elsewhere, Python's use of indentation as logical structure FORCES the programmer to use proper indentation structure, which is completely in the Ada spirit of enforcing good practices (rather than simply "allowing" them). More importantly, Python assures the reader of the code that the logical structure is consistent with the indentation structure. > The infamous if (a = b) is so widespread an error in C++ that many compilers > issue a warning when encounter this perfectly legal construct. It's because > even years of C++ programming can't erase natural human habit to use "=" as > equality operator, and not "==". Another red herring. What I am proposing has absolutely nothing to do with this pitfall of C++. Russ