Is this a dream or a nightmare? (Was Re: XML)

[David T. Grove]

On Sat, 07 Oct 2000 23:02:42 GMT, pete at petes-place.com (David T.
Grove) wrote:

>OOP over a procedural language has more lines, no matter how you look
>at it. C++ is especially guilty in this, because for "standard" C++,
>in certain areas like the STL, you end up programming classes with
>overloaded operators just to begin coding... not much of a time saver
>over basic ADT's from a programmer's pov. OOP can be a convenience
>when it comes to hiding code, but there's code in that black box, and
>it has to be anough to make it work. Plus in C++, though not in all
>object languages, you have syntactic overhead (a.k.a. fluff). Even
>Stroustroup complains about this in "The Design and Evolution of C++".
>But then, what do you expect from a language that trades no strings
>with bad strings. ;-)

I didn't say this right.

What I meant was, in OOP, you take what would be the procedural
language and fold in a lot of fluff in order to look at the data from
a different point of view. If you re-use your code, then your OOP may
pay off in the long run; but for that first time, your code is by far
longer than it would be with the procedural language in itself. In
C++, there's a lot of fluff to fold in. In order to make a _good_
black box, you have to go farther than you would normally go with
procedures in order to make it a complete thingy. Changes and
maintenance _hopefully_ (according to the goals of the language) take
place by making new black boxes based on the old ones, which is
easier, but that's C++, which has a different goal than Perl and
Python. Underneath all that fluff, you get the procedures and syntax
of the language. You don't get to putting your thoughts together to
accomplish design until you've gone through all of the fluff of making
complete black boxes in the hope of using them later, at least not if
you want a strong design.

(So, if you don't see that C++ as extremely verbose, then you are
either a careless programmer who makes incomplete black boxes, a
newbie who doesn't know how to make black boxes, or you have an
incredible set of already-defined superb and complete black boxes that
I want... gimme gimme gimme.)

Perl is not applied the same way as C++. Although it has OOP down to a
simple art, with every bit the umph of C++ (but none of the paranoia -
Python is also not nearly as paranoid as C++), Perl is normally used
in different ways, and isn't required to use the OOP mindset to
accomplish its goals. That is, unlike Java, where everything is an
object and in order to use the system you have to do OOP (waaaay
overdoing it), and unlike C++ where it's there if you need it but you
definitely need it, Perl treats OOP as a way of seeing things, there
if you need it, but you normally don't because unless you need it, it
just gets in the way of expressing your ideas in code. VB's OOP I
won't discuss, because it's not OOP. Fluff maybe, but not OOP.

Python tries to be geared a little more toward re-use than single-use.
In that alone it's more verbose. It almost has to be. (But then,
single-use grouped together used to be called a "system", and is every
bit as valid and useful as OOP. Perl crowns that way of thinking by
being the least verbose language of that mindset, at least that I know
of.) In terms of OOP, it encourages use of OOP by being OOP itself.
You can argue till the cows come home about Python being an
"application" language, but that one I'm not buying, at least not
"more so than Perl", and at least not in terms of capability. However,
I have noticed that people do use Python (in general) a bit
differently than they use Perl. It's still a scripting language, and
the verbosity and encouraged oopness sometimes get in the way of the
tasks that people use scripting languages for, which would be the case
if Perl were a little more "socially" geared toward groups of tasks in
an organized unit rather than a single task possibly grouped with
other single tasks to accomplish the same things in an organized
fashion.

Perl is "thought process" based, and OOP/Python is more algorithm
based. By this I mean that "one complete thought per line" is more of
a norm in Perl than "one complete thought per identifiable section of
code" as it would be in Python. As a result, Perl may be more
difficult to read to some people who aren't used to thoughts being
encompassed in fewer words. The difference can correspond
allegorically to the difference between hillbilly speech and the
speech of college professors: they say the same things, the professors
just use fewer words to get the thoughts across, because the thoughts
tend to get wrapped up into single words for which the hillbillies
have to use several words in combination to come up with the same
meaning in their speech, speech being the expression of thought, or in
CS the communication between man and machine.

There is an unfortunate social push in Perl right now, in the planning
of Perl 6.0, wanting to move more toward the type of programming tasks
that Python would be used for. The unfortunate thing is that the
proponents of this don't realize that this would accomplish little
more than making the language more verbose and less flexible. (From
the appearance of the Camel's third edition, what we should probably
be more concerned with is completing the 5.x series and eliminating
the causes of its problems - I won't mention them again since you know
where my finger points - before we move anywhere, since it seems that
every other feature of the language is now half-finished, because of
the untimely release of 5.6.)

So, as to whether Python takes more lines of code or is more verbose,
of course it is. If it weren't, it wouldn't be Python, it would be
Python-flavored Perl. If Perl were more verbose and geared toward the
same people and tasks that Python was, it wouldn't be Perl, it would
be Perl-flavored Python. I think the argument between "lines of code"
are, when given out of context, completely irrelevant. They only
become relevant when seen in the context of completing a task, or
expressing a "thought". The thoughts expressed depend upon the nature
of the conversation.

>Anyway, if you'll notice, I did some lumping there, not hard figures
>for each language. You take it any way other than lumping, you're
>misreading the text and skipping the meaning behind it.

Said that wrong too. Sorry... lack of sleep. I mean, I lumped several
languages together. VB and C with Python (which wasn't any kind of jab
at the Python language), and separated out C++ as an extreme. There
are actually studies done on this if you are really interested in line
counts. Look them up.

---

So, it appears then that my concern in moving to Python is less one of
off-by-one slices, and more of slowing down my train of thought to
come closer to the computer's way of thinking than my own. Of course,
it's only one step away from Perl, and doesn't slow me down to a crawl
as VB or C would, and doesn't use nearly as much fluff as C++. It will
just take a bit of getting used to, sort of like moving from upper
long island to the virginia coast (as opposed to moving to the
Tennessee hills).