Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[kevin.cline@gmail.com (Kevin Cline)]

Adam Ruth <adam.ruth@mac.com> wrote in message news:<adam.ruth-CEAF21.08210127092004@localhost>...
> In article <b47de02.0409261812.659a923b@posting.google.com>,
>  duggar@mit.edu (Keith H Duggar) wrote:
> 
> > > I've come to this thread late, so I'm not completely sure about the 
> > > exact specs of the code, but here's my take on a Python version.  It 
> > > comes in at a svelt 10 lines, and I think it's quite readable.  I'm sure 
> > > I'm missing something though.
> > > 
> > > import sys
> > > 
> > > words = {}
> > > for line in sys.stdin.readlines():
> > >     for word in line.split():
> > >         words[word] = words.get(word, 0) + 1
> > > 
> > > words = [[x[1], x[0]] for x in words.items()]
> > > words.sort()
> > > words.reverse()
> > > 
> > > for word in words[:10]:
> > >    print word[0], word[1]
> > 
> > Sweet. Python get's my vote for most readable in this case.
> > The "for ... in ..." construct is very nice. It saves a lot
> > of time and a lot of error prone indexing code. Thanks for
> > posting it.
> 
> 
> Python and Ada tie for my favorite languages (with Lisp coming in a 
> close second).  Which I use, depends on the task at hand.  Ada and 
> Python seem to have similar philosophies, though on opposite sides of 
> the spectrum.  Python's designer had as an explicit goal:
> 
> "There should only be one obvious way to do anything".
> 
> Some think that that stifles creativity, but I disagree.  It frees the 
> programmer in my mind.  While I'm not sure about the Ada designer, it 
> seems that a similar philosophy was in play.  That's a very 
> "engineering" type of thought, as opposed to a "hacker" type of thought.
> 
> That's actually my biggest problem with Perl.  Its designer had as a 
> goal that there should be as may ways to accomplish things as there are 
> programmers.  

That was not so much a goal as property that emerged as the language
grew. Features were added to make it convenient to do some things, or
to improve code readability, /without worrying about feature overlap. 
So you can say either
   if (!condition) { statement; }
or
   unless (condition) { statement; }
or
   statement unless (condition);

Or you can say either
   foreach $element (list)
   {
     do something;
   }
or
   map { something } (list);

Having more than one way to do things makes it easier to write
readable code.  And also easier to write unreadable code.

> Great if you're just a hacker having fun, terrible if 
> you're someone maintaining Perl code.  

Really not so terrible.  

> I think that has more to do with Perl's unreadability than the syntax.  I've 
> never met a "great" Perl 
> programmer (read, Perl hacker), who wasn't completely confused by their 
> own two month old code.  

Then you've never met a great Perl programmer.  The great programmers
I've known can write crystal-clear code in almost any language, with
very little need for explanatory comments beyond class and function
descriptions.

I've read a lot of CPAN modules and found most of them pretty clear. 
But there are some very high-level PERL modules that allow one to do a
lot with a little code, and it takes a little effort to learn what
those modules do.