🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.prolog
Article #967

Re: Prolog's Pitfalls?

#967
From: RCAPENER
Date: Wed, 11 Jul 1990 16:47
92 lines
5720 bytes
In article <2952@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes:
> In article <3305@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au
> (Richard A. O'Keefe) writes:
>> -- obscurity as a property of a programming language has much to do
>>    with the person making the claim and the instructional material
>>    that person has been exposed to.
> 
	[much stuff deleted, but Jeff replies]
>
> This sort of observation is all very well, but it's far from the whole
> story.  If something's hard to understand, maybe it really *is* hard
> to understand.  If instructional material tends to be confusing, maybe
> that says something about the language.  You happen to be very good
> at explaining Prolog, but maybe it says something about the language
> that many other people meet with less success.
> 
	[more stuff deleted, Richard asserts another point]
>>
>>  This really is not a big deal in practice if you will only try to write
>>  *Prolog* code instead of trying to write Pascal code in Prolog.  If you
>>  want to know how to do that, my services as a teacher of advanced Prolog
>>  courses _are_ for hire...
> 
> Maybe it's not a big deal for *you*, but quite a few people, some of
> whom haven't learned any language other than Prolog (and so haven't
> been influenced by Pascal directly), and others who are very
> experienced Prolog programmers (and so should have learned better
> if it's as easy as you say), write procedures with unreasonable
> numbers of parameters.
> 

But Jeff, Richard is making a *VERY* valid critique here!  More
than once I have observed people with Pascal backgrounds drag
that accursed language over into *EVERY* other language out there.
Right now, I am not too happy at all about their Pascalization of
C in the latest ANSI version.  Why the h**l couldn't they have added
type complex and type BCD rather than worrying incessently about
adding prototypes?  And now they are dragging in their MixedCASEVars
AreWonderfulConcept SinceWeALWAYSReadEnglishThisWayAnyway!  Yes, sad
but true, the effects of a previous language DO have an effect on
learning a new language.  And they have also created new styles of
indentation that depart from the standard, bloating the size of
the files (tabs show as 8 spaces but only cost 1 char) and actually
making the code *LESS* readable!  By the way, do you really know people
that have PROLOG as their first computer language?

Prolog (shouldn't it be in all caps?) as a declarative logic language
has its uses, and it should be used differently than Pascal is.  People
that gripe about the awkwardness of PROLOG, are really going to have fun
when they try using Smalltalk or some other object-oriented language for
the first time!  The gist of this is, when you learn a new computer
language you really MUST try to think in the style that is natural for
that language.  It seems to me that this holds for natural human languages
as well.

Does PROLOG have its uses?  It certainly does, and although it may not
do everything (I haven't noticed anyone I know claiming it does), it
does what it does well.  Sure, we can do it faster in C, but we also
pay the price of having to write more code.  And it takes most of us
the same amount of time (assuming we can write with equal effectiveness
in multiple languages) to write X lines of code regardless of the
language we code it in.  This means we can finish the job faster in
languages that are more expressive (ie, SQL code vs. doing it all by
hand in C).  Do we pay a price for this convenience?  Yes, usually
slower execution times.  But this is nothing new, and we observe this
trade-off all of the time in Computer Science.  It just depends on
which is most valuable at the time we write the code, execution time
vs. development time.

Rather than focusing on this, we should be spending far more time
on integrating the various languages together so that we can write
mixed language applications easily and effectively.  And if some
poor soul is incapable of working in 3 or more languages effectively,
I choose to believe they are a dolt who shouldn't be in CS!  We have
all too many in that class now.  For myself, that means C++, Prolog
(wouldn't you have guessed that by now 8-)), LISP, and Sybase (or
take your own pick of relational or object oriented data base).  On
occasion, use of an Expert System shell might be nice too.  It all
depends on what you are doing.  If you find that PROLOG doesn't
have the capabilities to do whatever you want to get done, then don't
use it!  Use hammers for pounding in the nails, not wrenches.

Seriously, if someone finds PROLOG all that difficult to learn, I
question whether they have what it takes to be an effective Computer
Scientist.  I am NOT saying they are dumb!  There are people who are
brilliant in other fields that seem to die on the vine when it comes
to doing even the simplest programming tasks.  I know some of these
people personally.  Conversely, there are people who can write code
at the drop of the hat in many computer languages that have very
serious problems with Math or Physics.  The gist of it is, if you
can't do it, get out of the field.  It is overloaded with incompetents
as it is.  Note, I do NOT consider you to be one of these people!
Technical Details
Message-ID: <76740@cc.utah.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cc.utah.edu!rcapener
References: <1990Jun18.221058.11331@chaos.cs.brandeis.edu> <3305@goanna.cs.rmit.oz.au> <2952@skye.ed.ac.uk>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!cc.utah.edu!rcapener
From: RCAPENER@cc.utah.edu
Newsgroups: comp.lang.prolog
Subject: Re: Prolog's Pitfalls?
Message-ID: <76740@cc.utah.edu>
Date: 11 Jul 90 16:47:24 GMT
References: <1990Jun18.221058.11331@chaos.cs.brandeis.edu> <3305@goanna.cs.rmit.oz.au> <2952@skye.ed.ac.uk>
Lines: 92