Dann Corbit (·······@solutionsiq.com) wrote:
: Travis C. Porco <·····@stat.Berkeley.EDU> wrote in article
[Snip]
: > But first, one must ask whether it is desirable to learn it in the first
: place.
: > C++ is by all accounts exceedingly difficult to master.
: By what accounts? I have no problem understanding it, and I'm not a
: genius. There are thousands of commercial programmers and analysts who
: have made the leap. Many times as many as Lisp and Smalltalk put together.
He said "master", not "understand". Understanding C++ is one thing,
but mastering it is another. There are so many nuances and
pathological horrors that await you in the bowels of this, the
most overrated of languages, that you will be befuddled time
and again, and turn your tear stained faced up towards the heavens
and cry "Why me Lord, why hath thou forsaken me?!?!?".
First, you have the miserable failings of C to contend with, and
then you have the extra horrors that C++ decided to throw in for
good measure. Object oriented extensions slapped on top of an
inadequate, archaic, low level language, a programming experience
do not make.
: > What is the return
: > on our time investment? Especially when there are even higher level
: > languages available than C++, in particular Common Lisp with its object
: system
: > CLOS.
: What a load of crap. If you are talking about 'return on investment' C++
: is absurdly higher than Common Lisp. Look at the amount of development
: that is going on in C++ and compare it with what is going on in Lisp.
That depends on what you define as "return on investment". If
by "return on investment" you mean better job opportunities, then
yes C++ sure does have a higher return on investment. But if
you mean the ability to produce reliable, maintainable code, then
C++ is a complete failure in this regard and gives you zero return
on investment.
: Only
: a fool will thing they will get a higher ROI from a study of Lisp, which is
: at least as difficult to master as C++.
Kindly leave some of your belligerence at home. This is a public
forum where many different opinions and facts are discussed, and
your attitude does little to promote intelligent discourse.
: Go to a bookstore, and see how
: much effort is being put forth to provide C++ instruction, compared to
: Lisp.
While you're at it, see how much effort is being put forth to provide
Visual Basic instruction. Popularity and Quality are very often
two mutually exclusive things. Do not confuse the two. C++ is
a miserable language, but one that is tremendously popular.
If you want to ride the wave of popularity, then be my guest.
However, some of us are leaving our surfboards at home and
prefer to swim upstream, to where the real gains are.
Lisp, while not my favorite language, is a language that is
leaps and bounds ahead of C and it's inbred cousin, C++.
The fact that in Lisp you can worry about coding the problem
at hand, rather than playing with copy constructors, assignment
overloading, pointers, and destructors speaks for itself.
: Will you be able to use your Lisp skills on every platform you might
: need to work on?
Yes. You see, Lisp is not only available as is, but is also the
extension language for Emacs, The World's Finest Editor (tm). With
Lisp under my belt I can customize Emacs to jump through hoops and
boost my productivity by leaps and bounds, even if my job entails
programming in another language (I've already used it to save some
*SERIOUS* time at work).
Furthermore, there's the Scheme Shell, which you can use for
UNIX shell programming, and who knows what else -- in addition
to your standard Lisp code.
Furthermore, others do code in Lisp. I've seen various extension
packages written in Lisp, even the videogame Abuse, had some
Lisp code in there.
: Look at the tools that are available for C++ compared to
: Lisp.
Given C++'s uselessness, you'll need them.
: Will you be able to pull a big pile of Lisp code into your design
: tool and automatically create object diagrams from it?
It depends on the tools and vendor now doesn't it?
: On dozens of
: platforms?
Ditto, but more likely for C++ due exclusively to it's popularity.
: Yes, I do realize that Smalltalk and Lisp are viable tools that
: do answer real-life business problems. Sometimes they are the best tool
: for the job. Just less often than C++.
Actually, it's the other way around. It's rare when C++ is needed
to do something that a superior language cannot do better. C++
is used for one reason and one reason only -- popularity. It is
the fad, and hence it is used. It is a woefully inadequate
programming language for even the most trivial of tasks.
: How many trained programming
: resources does a typical organization have for C++ verses those
: alternatives?
And how many roaches can one find in a house versus humans?
: Neither Smalltalk nor Lisp will ever have the following nor
: the utility that C++ does.
Nor will they have the bugs, crappy reputation, or laughable
"features".
:
: > The choice of language tools is not, as some would say, a matter of
: > "programming religion" purely. Some languages really do provide enhanced
: > productivity by abstraction. Who would deny that it is faster and safer
: > to write applications in C than in assembler?
: Please don't let Nudds hear you. And it is not always true. Just most of
: the time.
Nudds, dear lord people really have it in for that guy.
: As always, all this stuff is IMO - YMMV.
Ditto here.
: Please send hate mail to me, rather than pollute the newsgroups with a
: language war.
: ·······@SolutionsIQ.com
--
Cya,
Ahmed
You call it romance,
You're full of shit!
"Filler" by Minor Threat
From: Graham Hughes
Subject: Language wars (again, <sob>), was re: What is wrong with OO ?
Date:
Message-ID: <5d8t2j$nr9$1@A-abe.resnet.ucsb.edu>
-----BEGIN PGP SIGNED MESSAGE-----
[Followups trimmed; I'm not sure the Smalltalk people really want to
hear about this...]
Speaking of flame bait...
········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>He said "master", not "understand". Understanding C++ is one thing,
>but mastering it is another. There are so many nuances and
>pathological horrors that await you in the bowels of this, the
>most overrated of languages, that you will be befuddled time
>and again, and turn your tear stained faced up towards the heavens
>and cry "Why me Lord, why hath thou forsaken me?!?!?".
Have you used the language, or do you base your ranting on second hand
information?
I'm not sure I've mastered the language yet; I'm not sure anyone really
has, as the draft standard is still in flux. But I don't need to, any
more than I need to master Perl. No language lacks faults, and LISP and
Smalltalk are certainly no exceptions here. Neither is C++. I know
enough to get by (although for a library developer, that's a fair bit)
and that's good enough.
>First, you have the miserable failings of C to contend with, and
>then you have the extra horrors that C++ decided to throw in for
>good measure. Object oriented extensions slapped on top of an
>inadequate, archaic, low level language, a programming experience
>do not make.
`inadequate, archaic, low level language'; one would even think you have
an axe to grind. Are you trying to sell me something? Don't insult the
language; it is certainly very good compared to the utter crap being
passed around as systems programming languages. (Remember Pascal's
heyday, when every compiler compiled a different superset of Wirth's
original intention?)
C++ has its faults, and a great many of them are inherited from C. Once
you move past the lower level stuff like char * pointers (which the new
standard library helps immensely with), it's even pleasant to use. And
it's *efficient*; Borland and Microsoft to the contrary, C++ compilers
generate code on par with the C compilers they supplant, which (along
with their FORTRAN counterparts) generate code well enough to have
doomed assembler programming on all but 80x86 machines.
>That depends on what you define as "return on investment". If
>by "return on investment" you mean better job opportunities, then
>yes C++ sure does have a higher return on investment. But if
>you mean the ability to produce reliable, maintainable code, then
>C++ is a complete failure in this regard and gives you zero return
>on investment.
Again, have you used the language? When? Which compiler?
People generate reliable, maintainable code in C++ every day. Much more
than LISPers generate (although this is because of volume). My code in
particular has been ported from my box to a machine with a different OS
and CPU with no changes. I have to do this, because it's required to
run on this other machine. I can't actually *do* this with LISP,
because the other machine has no LISP interpreter/compiler.
>Kindly leave some of your belligerence at home. This is a public
>forum where many different opinions and facts are discussed, and
>your attitude does little to promote intelligent discourse.
How ironic that *you* should mention this, given your incendiary
remarks.
<snip>
>Lisp, while not my favorite language, is a language that is
>leaps and bounds ahead of C and it's inbred cousin, C++.
>The fact that in Lisp you can worry about coding the problem
>at hand, rather than playing with copy constructors, assignment
>overloading, pointers, and destructors speaks for itself.
Yeah, then you can worry about it running when you get it past the
compiler. My quibble with LISP derives from its dynamic typing (which I
beg people *not* to turn into a flame war *again*). Copy constructors,
assignment overloading, pointers and destructors all serve valuable
purposes, and that you cannot recognize this implies you have never
tried.
Step out of your shell; there *is* a world beyond LISP. If you decide
to go back to LISP after looking elsewhere, that's your business; I did
something analogous with C++. But at least taste what the alternatives
have to offer, eh?
I'll disregard the rest of your posting; it mostly contains pointless
remarks apparently designed to reaffirm your own ego.
Oh, and please listen to the man:
>: Please send hate mail to me, rather than pollute the newsgroups with a
>: language war.
>: ·······@SolutionsIQ.com
I make the same request. I will continue this debate with those
interested privately via email. I would like to avoid spamming the
language newsgroups *again*. I just hate seeing hubris go by
unanswered...
- --
Graham Hughes (·············@resnet.ucsb.edu)
http://A-abe.resnet.ucsb.edu/~graham/ -- MIME & PGP mail OK.
"Never attribute to malice that which can be adequately explained by
stupidity." -- Hanlon's Razor
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
iQCVAwUBMvf3WiqNPSINiVE5AQFpvwP9EdbGhORVhCy1l8mkgPkueEN2CsZz1Zuw
u6IhCqGCtkPyIJ+uVSCU/nJbiVJUnTcu3lBm8TIouEy39S0LknxcE3OaWngofw++
E8fs1nzOfdP6Fm8QUEjEa3dVoP+z/AHBRphLlQ4tCNtugMfkvcCU0Q/l/ztjSLQi
3IvHe1qCeiM=
=089x
-----END PGP SIGNATURE-----
Here, here. Bottom line...every language has it's place. That said, I
think C++'s place is few for my employer. Our company is a large IT
services company that creates business applications for our clients. In
this situation, it doesn't pay to write in C++, even though I can't
convince anyone around here of that. I've taught C++, I've taught VB, I've
taught Smalltalk...nothing is harder to learn than C++. Nothing is harder
to use that C++. Nothing provides a complete waste of time and resource
more than C++. (forget obscure languages and things like assembly...)
I'm working on a project now. We developed the beginnings of a system with
one use case, four system operations. The ops are complex because of our
need to create a "database services" layer complete with broker objects,
database objects (to separate vendor stuff), and transaction objects. On
top we built our domain. With the DB, totalled about 60-70 classes.
I "prototyped" the system's one use case in VisualWorks by myself, then
took printouts of the code and told the C++ people to code it in C++.
Langauge Number of people Time (including testing)
VisualWorks 1 4 hours
C++ w/memory DB 4 6 days (not done yet)
C++ w/ODBMS +1 6 days (not done yet)
I know what you're thinking "must be some stupid C++ people". Definitely
not so. All have complete grasp of memory management, pointer, heap vs.
stack, references, OO, design patterns, yada yada yada. There is just so
much more to consider: who deletes what, use pointers or instances, pass by
pointer vs. pass by reference, const.......... Integrating STL with ODBMS
is causing a LOT of problems.
Now I'll be the first to admit that if you *really* need speed, ie. high TP
environments, do yourself a favor and lock at C++. But the moment to slap
a UI on some business app, you're waiting on the user 99% of the time. And
noone would develop a device driver in ST...
--
Persistence is futile.
You will be aggregated...
From: Kelly Murray
Subject: Re: Language wars (again, <sob>), was re: What is wrong with OO ?
Date:
Message-ID: <5dblql$4qc@sparky.franz.com>
> Now I'll be the first to admit that if you *really* need speed, ie. high TP
> environments, do yourself a favor and lock at C++. But the moment to slap
> a UI on some business app, you're waiting on the user 99% of the time. And
> noone would develop a device driver in ST...
Yep, but might as well forget C++ and use just C, which most "C++ programmers"
are doing anyway. SteveH at Franz found a job posting asking for
"C++ programmers experienced in using C++ in an object-oriented way".
I don't think one can't even buy just a "C" compiler anymore,
-kelly murray ···@franz.com http://www.franz.com
Long long ago in a land far far away, Kelly Murray wrote:
} > Now I'll be the first to admit that if you *really* need speed, ie. high TP
} > environments, do yourself a favor and lock at C++. But the moment to slap
} > a UI on some business app, you're waiting on the user 99% of the time. And
} > noone would develop a device driver in ST...
}
} Yep, but might as well forget C++ and use just C, which most "C++ programmers"
} are doing anyway. SteveH at Franz found a job posting asking for
} "C++ programmers experienced in using C++ in an object-oriented way".
} I don't think one can't even buy just a "C" compiler anymore,
}
I know that I am going to get in trouble for this, but . . .
I cannot agree more with this direction. I, as do many others, consider C++ a
better C. Our company is presently working on a project the is 90% UI. We
started in C++, but switched to Smalltalk after about a year. Some of our
routines we maintain in C because we need the speed and control that this gives
us, but for the bulk of the work, St is much easier to work with, and
performance is more than adaquate.
John
_____________________________________________________
John Gale ····@peacesummit.com
ICAN Systems Inc. Voice: (604) 852-6941
On 6 Feb 1997 04:14:13 GMT, ···@math.ufl.edu (Kelly Murray) wrote:
>Yep, but might as well forget C++ and use just C, which most "C++ programmers"
>are doing anyway.
Sigh.
Do you have statistical proof that >50% of all C++ programmers
are not using OO methods at all? I don't think so.
But if you look at the subset of C++ programmers who only use
C++ because that's what Microsoft offers for Windows, then I
have found a number of them have little knowledge, and sometimes
very little interest, in things OO. Many of them have never
heard of Scott Meyers, James Coplien, Grady Booch, Bertrand
Meyers, or any of the others.
It's only empirical, and may not be at all representative, but
all the non-windows programmers I know are very much OO C++
programmers. Of the windows programmers I've known (not that many),
about 1/2 were aware of OO design and analysis. The others considered
themselves Windows programmers, not OO programmers.
I'm saying that there is more than one reason to get into C++. One
reason is to implement OO designs. Another is to use some other
set of tools also available.
I like OO. I use C++ to realize it. I have concernss when people
are using C++ but not OO, just like you'd have issues with people
using lisp and smalltalk in inelegant ways, such as using smalltalk
to realize Data Flow Diagrams.
But I don't think that "not OO" means that the software is bad.
OO is a preference, and I think it is a "better" way to build
software. Being honest, I can't say that it's *the* critical
requirement for a piece of software to be useful and valuable.
C++ is OO, but it's not OO-only (OOO?). There are many reasons
to use it. And, I'm sure, a fair number of reasons not to.
The problem is when people claim to be OO programemrs and are not.
The other problem is when people expect others to be OO programmers,
but they are not.
I've also had the other problem, where people thing that because
I use OO that I'm a GUI programmer. I think that comes from some
windowing environment vendors telling people that GUI is *the*
OO approach to software.
> SteveH at Franz found a job posting asking for
>"C++ programmers experienced in using C++ in an object-oriented way".
>I don't think one can't even buy just a "C" compiler anymore,
You can. In my previous company, we bought several. Of course, non-
standard (non-ANSI C) ones come free with Unix systems, and you can
get GNU for free for just about anywhere. But you can also pay for
the professional C (i.e. standard C) environments if you need them.
I don't know about the Windows environment. They may have all
converted to C++, but you can set an option in most to either do
C or C++. To use the windows frameworks, you have to use the C++
option. You can write windows code the old, C way if you want,
though. That's the whole backward-compatibility "advantage". :-)
So, when you posted your message, were you only thinking about
PC programming? Were you only thinking about MS and Borland
C++? If so, you are missing a huge chunk of the C++ community.
Maybe the largest chunk.
But that all has nothing to do with smalltalk, nor listp. Nor is it
all that interesting.
-------------------------------------------------------------
Tim Ottinger | Object Mentor Inc. | OOA/D, C++, more..
········@oma.com | http://www.oma.com | Training/Consulting
-------------------------------------------------------------
"... remember, there are ways of succeeding that we would not
personally have chosen. " - Bjarne Stroustrup
-------------------------------------------------------------
From: Travis C. Porco
Subject: Re: Language wars (again, <sob>), was re: What is wrong with OO ?
Date:
Message-ID: <5dbfrm$6dk@agate.berkeley.edu>
In article <············@A-abe.resnet.ucsb.edu>,
Graham Hughes <·············@resnet.ucsb.edu> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>[Followups trimmed; I'm not sure the Smalltalk people really want to
>hear about this...]
>Speaking of flame bait...
>········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>>He said "master", not "understand". Understanding C++ is one thing,
>>but mastering it is another. There are so many nuances and
>>pathological horrors that await you in the bowels of this, the
>>most overrated of languages, that you will be befuddled time
>>and again, and turn your tear stained faced up towards the heavens
>>and cry "Why me Lord, why hath thou forsaken me?!?!?".
>Have you used the language, or do you base your ranting on second hand
>information?
I have tried GNU C++ on a Sparc 1+ early on, I tried Borland C++ on
Windows 3.1, and finally GNU C++ on Linux. I have code to perform
Latin hypercube (Monte Carlo based) sensitivity analyses on the outputs
of simulation models. Now this is a relatively small (by industry
standards) program that I wrote and maintain myself.
When it came time to port it to my Linux machine, and
to modify it for a tuberculosis model, I tried writing parts in C++.
For instance, I tried to have
a class called Distribution, from which specific distributions could
be inherited, such as Uniform, Triangular, Beta, etc. I finally got
this part to work, but after much frustration and error, and the whole
thing was fragile; apparently small changes which looked reasonable
produced mystifying run-time behavior (constructors not initialized
properly, etc.). It was darn hard to just convert this small part to C++.
In desperation, I first looked into Ada, but then I found Ullman's book on
ML and decided to give this language
a try. It took me about 10 days to rewrite my entire program in ML.
_That_ was easier than just trying to write the probability distribution
segment in C++. So I became a believer in the real bottom-line benefits
of language abstraction. Without ML, I would never have
finished my part of one of the tuberculosis simulation projects our group
undertook. ML made the difference between success and failure.
OF course, YMMV, and all that.
I've moved more to Lisp lately, because of the statistics package Xlispstat
and the lisp-based editor Emacs, and because of the very interesting tool
Scheme-TK which I hope will make it possible to write some windowing
interfaces with 1% the trouble that direct use of low level X functions
would be.
I'm not interested in a "language war", but we do have to be able to
discuss rationally and with mutual respect our choice of tools. Half the
problem we have is that programming language DOES become a question of
'religion', immune to reason and argument. (Oddly, we're still urged
to follow bandwagons, even in THIS environment.)
--Travis Porco
From: Ian Joyner
Subject: Re: Language wars (again, <sob>), was re: What is wrong with OO ?
Date:
Message-ID: <32FA5E38.5689@acm.org>
I agree with the following sentiment of not being interested in language
wars. We need good technical assessment of languages, and how they
relate
to the whole software development task. Do they help with a only a small
part of development, that is coding (which I call coding, not
programming),
or do they help with many more aspects of the entire software
development
lifecycle? What are the holes in the language that lead to traps and
difficult to find and costly errors? Not only that but how much do they
automate, not necessarily by having auxilliary tools such as make and
lint, but because such tasks are implicitly handled by the good design
of the language?
My attempt to analyse features such as these in three widely available
languages can be found at:
http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html
But please stop the religious wars, and analyse things on their
technical
merits.
Travis C. Porco wrote:
>
> In article <············@A-abe.resnet.ucsb.edu>,
> Graham Hughes <·············@resnet.ucsb.edu> wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >
> >[Followups trimmed; I'm not sure the Smalltalk people really want to
> >hear about this...]
>
> >Speaking of flame bait...
>
> >········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>
> >>He said "master", not "understand". Understanding C++ is one thing,
> >>but mastering it is another. There are so many nuances and
> >>pathological horrors that await you in the bowels of this, the
> >>most overrated of languages, that you will be befuddled time
> >>and again, and turn your tear stained faced up towards the heavens
> >>and cry "Why me Lord, why hath thou forsaken me?!?!?".
>
> >Have you used the language, or do you base your ranting on second hand
> >information?
>
> I have tried GNU C++ on a Sparc 1+ early on, I tried Borland C++ on
> Windows 3.1, and finally GNU C++ on Linux. I have code to perform
> Latin hypercube (Monte Carlo based) sensitivity analyses on the outputs
> of simulation models. Now this is a relatively small (by industry
> standards) program that I wrote and maintain myself.
>
> When it came time to port it to my Linux machine, and
> to modify it for a tuberculosis model, I tried writing parts in C++.
> For instance, I tried to have
> a class called Distribution, from which specific distributions could
> be inherited, such as Uniform, Triangular, Beta, etc. I finally got
> this part to work, but after much frustration and error, and the whole
> thing was fragile; apparently small changes which looked reasonable
> produced mystifying run-time behavior (constructors not initialized
> properly, etc.). It was darn hard to just convert this small part to C++.
>
> In desperation, I first looked into Ada, but then I found Ullman's book on
> ML and decided to give this language
> a try. It took me about 10 days to rewrite my entire program in ML.
> _That_ was easier than just trying to write the probability distribution
> segment in C++. So I became a believer in the real bottom-line benefits
> of language abstraction. Without ML, I would never have
> finished my part of one of the tuberculosis simulation projects our group
> undertook. ML made the difference between success and failure.
>
> OF course, YMMV, and all that.
>
> I've moved more to Lisp lately, because of the statistics package Xlispstat
> and the lisp-based editor Emacs, and because of the very interesting tool
> Scheme-TK which I hope will make it possible to write some windowing
> interfaces with 1% the trouble that direct use of low level X functions
> would be.
>
> I'm not interested in a "language war", but we do have to be able to
> discuss rationally and with mutual respect our choice of tools. Half the
> problem we have is that programming language DOES become a question of
> 'religion', immune to reason and argument. (Oddly, we're still urged
> to follow bandwagons, even in THIS environment.)
>
> --Travis Porco
--
------------------------------------------------------------------------
Ian Joyner | "for when lenity and cruelty play | All opinions are
Internet email: | for a kingdom, the gentler | personal and are
········@acm.org | gamester is the soonest winner" | not Unisys
| William Shakespeare Henry V | official comment
------------------------------------------------------------------------
From: ········@craftedsmalltalk.com
Subject: Re: Language wars (again, <sob>), was re: What is wrong with OO ?
Date:
Message-ID: <c0.9w.2DyldG$09B@craftedsmalltalk.com>
In <·············@acm.org>, Ian Joyner <········@acm.org> writes:
>My attempt to analyse features such as these in three widely available
>languages can be found at:
>
>http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html
>
>But please stop the religious wars, and analyse things on their
>technical
>merits.
Oh, but they are technical merits.
And I am serious.
The problem is that, at least for smalltalk, the features
are synergistic and different than traditional languages
so it makes communication about the language difficult.
The only effective way to compare smalltalk to other languages
is to apply it against a set of problems. Of course that
introduces another set of problems. So, practically speaking
I think the only way someone who is really interested is
going to be able to satisfy themselves is to get a copy
and use it for a while. The reason you read all this
rhetoric from smalltalk programmers is because they have
been there and they have found what they consider to be a very
good solution.
===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk *Breakpoints* and *Watchpoints* for
19 Tilley Ave. VW and ENVY/Developer
Newport, RI 02840
(401) 846-6573 ········@craftedsmalltalk.com
http://www.craftedsmalltalk.com
===========================================================
The Parable of the Scissors, or, On Using the Right Tool
Long ago in a suburb far, far away...
A man who owned a house asked Big Mel to "cut the grass on the lawn".
Big Mel took a pair of scissors from the dresser and went out to cut the
grass. After all, he knwe how useful scissors were if you had to cut paper
or twine. Starting at one side of the lawn, he reached down and sheared
a blade of grass perfectly. Satisfied, he started to cut the lawn with
his pair of scissors.
Good grass cutting with the scissors was a challenge. He got to where he
could make the cut in exactly the right place on the blade, and was able to
dig up the occasional dandelion. He left a little more leaf where the grass
was thin. He developed muscles and attentiveness. He could walk out and
cut a square yard of grass in 10 minutes, and never was grass cut so well or
with such accuracy.
He taught the other gardeners at the mansion to use the scissors, and was soon
the Horticultural Scissormaster. They ordered dozens of pairs of scissors
and lots of spare parts. They hired extra gardeners, and one was assigned
to sharpen them, another to scrape off grass and rust. They became strong
and sharp-eyed, and knew just the right stroke when the grass was wet,
when the grass was dry, when the soil was thick and when the soil was thin.
By the end of the summer, they had almost managed to mow the north lawn.
The owner wrung his hands and asked if Mel could go any faster. Mel explained
that lawnmowing was intrinsically complex.
A fellow named Mac one day hooked up some curved blades onto some rollers.
He meant to use this to cut the grass faster. Mel said, "look, it's cute,
but _no one_ is using this curved bladed thing. You don't have all the
resources and support you'll have if you stay with the scissors. Can all
those scissor users be wrong?"
Mac mowed the side lawn on his own, but nobody believed him. He kept working
by himself on the side lawn, and the others are still toiling away to this
day with their scissors.
--Travis Porco
very good!
On 6 Feb 1997 03:04:51 GMT, ·····@stat.Berkeley.EDU (Travis C. Porco)
wrote:
*:>The Parable of the Scissors, or, On Using the Right Tool
*:>
*:>Long ago in a suburb far, far away...
*:>
*:>A man who owned a house asked Big Mel to "cut the grass on the lawn".
*:>
*:>Big Mel took a pair of scissors from the dresser and went out to cut the
*:>grass. After all, he knwe how useful scissors were if you had to cut paper
*:>or twine. Starting at one side of the lawn, he reached down and sheared
*:>a blade of grass perfectly. Satisfied, he started to cut the lawn with
*:>his pair of scissors.
*:>
*:>Good grass cutting with the scissors was a challenge. He got to where he
*:>could make the cut in exactly the right place on the blade, and was able to
*:>dig up the occasional dandelion. He left a little more leaf where the grass
*:>was thin. He developed muscles and attentiveness. He could walk out and
*:>cut a square yard of grass in 10 minutes, and never was grass cut so well or
*:>with such accuracy.
*:>
*:>He taught the other gardeners at the mansion to use the scissors, and was soon
*:>the Horticultural Scissormaster. They ordered dozens of pairs of scissors
*:>and lots of spare parts. They hired extra gardeners, and one was assigned
*:>to sharpen them, another to scrape off grass and rust. They became strong
*:>and sharp-eyed, and knew just the right stroke when the grass was wet,
*:>when the grass was dry, when the soil was thick and when the soil was thin.
*:>
*:>By the end of the summer, they had almost managed to mow the north lawn.
*:>The owner wrung his hands and asked if Mel could go any faster. Mel explained
*:>that lawnmowing was intrinsically complex.
*:>
*:>A fellow named Mac one day hooked up some curved blades onto some rollers.
*:>He meant to use this to cut the grass faster. Mel said, "look, it's cute,
*:>but _no one_ is using this curved bladed thing. You don't have all the
*:>resources and support you'll have if you stay with the scissors. Can all
*:>those scissor users be wrong?"
*:>
*:>Mac mowed the side lawn on his own, but nobody believed him. He kept working
*:>by himself on the side lawn, and the others are still toiling away to this
*:>day with their scissors.
*:>
*:>--Travis Porco
---------------------------------------------------------------------------
DEAD REPUBLICAN Kill yourself and all your ideals
Underground Milhouse Studios Dead Republican '96: 6 songs
PO Box 320411 Society Part One: 11 songs
Fairfield, CT 06432 Primary: 4 songs (3 remixes)
········@ct2.nai.net Member of Buttmunch Records
http://w3.nai.net/~perfecto/deadrep.html Support FREE Music!
http://w3.nai.net/~perfecto/umilhous.htm Support FREE Music!
In article <················@news.nai.net>,
perry fect, republican <········@nai.net> wrote:
>very good!
>On 6 Feb 1997 03:04:51 GMT, ·····@stat.Berkeley.EDU (Travis C. Porco)
>wrote:
>*:>The Parable of the Scissors, or, On Using the Right Tool
Thanks for the pat on the back. I remember well being told when I was
struggling with C++ that programming should (always and everywhere) be
left to professionals who had mastered the True Professional Language C++.
I already think Lisp languages are high-level and flexible enough to
be useful for the sort of things I'm interested in, and am currently
using GNU Common Lisp in my work.
But I'm curious what the Smalltalk excitement is all about, which is why
I came over to your group. I'm still unsuccessfully trying to get
a Smalltalk system running on my Linux box.
As a simulation modeler,
I think it is interesting that object oriented programming originated
from the simulation modeling language Simula. It is also interesting
that the Goldberg book _Smalltalk-80. The language_ concludes with
a chapter on event-driven simulation, which is very interesting to me
since I'm at present working on event-driven models in a biostatistical
application. Of course, there are are plenty of simulation packages,
but I wonder if Smalltalk (due to its Simula heritage) also has some
unique features that may be useful to a simulation modeler.
If anyone knows of an _affordable_ Smalltalk that runs on _Linux_, please
let me know. Many thanks,
--Travis Porco
·····@stat.Berkeley.EDU (Travis C. Porco) writes:
> I'm still unsuccessfully trying to get a Smalltalk system running on my
> Linux box.
Go to ftp://alix.inria.fr/pub/squeak/unix/Squeak-1.18 and download the
following:
README
image/Squeak1.18.changes
image/Squeak1.18.image
image/SqueakV1.sources
bin/SqueakVM-1.18-i586-linux1.2
Put everything in the same directory and then type
./SqueakVM* Squeak1.18.image
The README file from that directory should get you going, and there are
more hints in the README in the parent directory.
(The above site is mirrored at ftp.create.ucsb.edu -- if the timestamp on
the Linux binary there is Jan 27 13:50 then use the UCSB mirror instead.)
If you have any problems at all with the Linux version then mail me
direct and I'll do my best to help you out.
Lots more information on Squeak (including mailing list coordinates) is
at:
http://www.research.apple.com/research/proj/Learning_Concepts/squeak/
> If anyone knows of an _affordable_ Smalltalk that runs on _Linux_, please
> let me know.
Squeak will set you back $0.
> [...]I'm at present working on event-driven models in a biostatistical
> application. Of course, there are are plenty of simulation packages,
> but I wonder if Smalltalk (due to its Simula heritage) also has some
> unique features that may be useful to a simulation modeler.
Squeak is identical to the Smalltalk described in both the Blue and
Purple books (see the Smalltalk FAQ), which contain a lot of information
about how to do discrete event simulation in Smalltalk. Combine the
former with either of the latter and you're off to a very good start.
Regards,
Ian
------------------------------- projet SOR -------------------------------
Ian Piumarta, INRIA Rocquencourt, Internet: ············@inria.fr
BP105, 78153 Le Chesnay Cedex, FRANCE Voice: +33 1 39 63 52 87
----------------------- Systemes a Objets Repartis -----------------------
In article <············@A-abe.resnet.ucsb.edu> Graham Hughes <·············@resnet.ucsb.edu> writes:
>My code in particular has been ported from my box to a machine with
>a different OS and CPU with no changes. I have to do this, because
>it's required to run on this other machine. I can't actually *do*
>this with LISP, because the other machine has no LISP
>interpreter/compiler.
This pretty well summarises your ridiculous posting. C++ is better
than lisp because your particular box happens to have a C++ compiler
but not a lisp compiler. Yeah right.
For the most part nothing...
OO is ok with me. I naturally construct my object oriented
taxonomies with nouns & verbs and with some re-work every
thing fit's and works ok.
I give it a thumbs up.
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote in article
<··········@Masala.CC.UH.EDU>...
> Dann Corbit (·······@solutionsiq.com) wrote:
> : Travis C. Porco <·····@stat.Berkeley.EDU> wrote in article
>
> [Snip]
>
> : > But first, one must ask whether it is desirable to learn it in the
first
> : place.
> : > C++ is by all accounts exceedingly difficult to master.
> : By what accounts? I have no problem understanding it, and I'm not a
> : genius. There are thousands of commercial programmers and analysts who
> : have made the leap. Many times as many as Lisp and Smalltalk put
together.
>
> He said "master", not "understand". Understanding C++ is one thing,
> but mastering it is another. There are so many nuances and
> pathological horrors that await you in the bowels of this, the
> most overrated of languages, that you will be befuddled time
> and again, and turn your tear stained faced up towards the heavens
> and cry "Why me Lord, why hath thou forsaken me?!?!?".
>
> First, you have the miserable failings of C to contend with, and
> then you have the extra horrors that C++ decided to throw in for
> good measure. Object oriented extensions slapped on top of an
> inadequate, archaic, low level language, a programming experience
> do not make.
>
>
> : > What is the return
> : > on our time investment? Especially when there are even higher level
> : > languages available than C++, in particular Common Lisp with its
object
> : system
> : > CLOS.
> : What a load of crap. If you are talking about 'return on investment'
C++
> : is absurdly higher than Common Lisp. Look at the amount of development
> : that is going on in C++ and compare it with what is going on in Lisp.
>
> That depends on what you define as "return on investment". If
> by "return on investment" you mean better job opportunities, then
> yes C++ sure does have a higher return on investment. But if
> you mean the ability to produce reliable, maintainable code, then
> C++ is a complete failure in this regard and gives you zero return
> on investment.
>
>
> : Only
> : a fool will thing they will get a higher ROI from a study of Lisp,
which is
> : at least as difficult to master as C++.
>
> Kindly leave some of your belligerence at home. This is a public
> forum where many different opinions and facts are discussed, and
> your attitude does little to promote intelligent discourse.
>
>
> : Go to a bookstore, and see how
> : much effort is being put forth to provide C++ instruction, compared to
> : Lisp.
>
> While you're at it, see how much effort is being put forth to provide
> Visual Basic instruction. Popularity and Quality are very often
> two mutually exclusive things. Do not confuse the two. C++ is
> a miserable language, but one that is tremendously popular.
>
> If you want to ride the wave of popularity, then be my guest.
> However, some of us are leaving our surfboards at home and
> prefer to swim upstream, to where the real gains are.
>
> Lisp, while not my favorite language, is a language that is
> leaps and bounds ahead of C and it's inbred cousin, C++.
> The fact that in Lisp you can worry about coding the problem
> at hand, rather than playing with copy constructors, assignment
> overloading, pointers, and destructors speaks for itself.
>
>
> : Will you be able to use your Lisp skills on every platform you might
> : need to work on?
>
> Yes. You see, Lisp is not only available as is, but is also the
> extension language for Emacs, The World's Finest Editor (tm). With
> Lisp under my belt I can customize Emacs to jump through hoops and
> boost my productivity by leaps and bounds, even if my job entails
> programming in another language (I've already used it to save some
> *SERIOUS* time at work).
>
> Furthermore, there's the Scheme Shell, which you can use for
> UNIX shell programming, and who knows what else -- in addition
> to your standard Lisp code.
>
> Furthermore, others do code in Lisp. I've seen various extension
> packages written in Lisp, even the videogame Abuse, had some
> Lisp code in there.
>
>
> : Look at the tools that are available for C++ compared to
> : Lisp.
>
> Given C++'s uselessness, you'll need them.
>
>
> : Will you be able to pull a big pile of Lisp code into your design
> : tool and automatically create object diagrams from it?
>
> It depends on the tools and vendor now doesn't it?
>
>
> : On dozens of
> : platforms?
>
> Ditto, but more likely for C++ due exclusively to it's popularity.
>
> : Yes, I do realize that Smalltalk and Lisp are viable tools that
> : do answer real-life business problems. Sometimes they are the best
tool
> : for the job. Just less often than C++.
>
> Actually, it's the other way around. It's rare when C++ is needed
> to do something that a superior language cannot do better. C++
> is used for one reason and one reason only -- popularity. It is
> the fad, and hence it is used. It is a woefully inadequate
> programming language for even the most trivial of tasks.
>
>
> : How many trained programming
> : resources does a typical organization have for C++ verses those
> : alternatives?
>
> And how many roaches can one find in a house versus humans?
>
>
> : Neither Smalltalk nor Lisp will ever have the following nor
> : the utility that C++ does.
>
> Nor will they have the bugs, crappy reputation, or laughable
> "features".
>
>
> :
> : > The choice of language tools is not, as some would say, a matter of
> : > "programming religion" purely. Some languages really do provide
enhanced
> : > productivity by abstraction. Who would deny that it is faster and
safer
> : > to write applications in C than in assembler?
> : Please don't let Nudds hear you. And it is not always true. Just most
of
> : the time.
>
> Nudds, dear lord people really have it in for that guy.
>
>
> : As always, all this stuff is IMO - YMMV.
>
> Ditto here.
>
>
> : Please send hate mail to me, rather than pollute the newsgroups with a
> : language war.
> : ·······@SolutionsIQ.com
>
>
> --
> Cya,
> Ahmed
>
> You call it romance,
> You're full of shit!
> "Filler" by Minor Threat
>
In article <··········@Masala.CC.UH.EDU>,
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
...
>Actually, it's the other way around. It's rare when C++ is needed
>to do something that a superior language cannot do better. C++
>is used for one reason and one reason only -- popularity. It is
>the fad, and hence it is used. ...
Exactly. We see, already, the retreat to the popularity argument.
This is a bad sign. The popularity argument has some--but only some--
merit. When it starts to be the most convincing reason to use
a language or system, you know the language or system has become
obsolescent, and a parachute to progress.
Thus C++ enters the company of DOS, FORTRAN-77, COBOL, SAS. Ugly,
obsolete tools that no one likes, but that we have been stuck with.
Maddening frustration and exhausted resignation replace the
enthusiasm of the dedicated programmers, and missed deadlines and
unpredictable failures become the expected standard.
Fortunately, with Standard ML, CAML, Common LISP, Scheme, Scheme-TK,
Prolog, Mercury, SmallTalk, MUPAD--there are now more excellent tools that
are available than ever before. And there are the even better tools
that tomorrow's men and women of imagination will provide. All
it takes is the open-mindedness to be sincerely open to change
and improvement.
--Travis Porco
Travis C. Porco wrote:
>
> In article <··········@Masala.CC.UH.EDU>,
> ········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
I find this discussion quite interesting, as it is addressing
implicitly a topic that has worried me for some time: What good is
C++ for? More to the point, what features does it provide that makes
it superior to C?
These questions are motivated by the same frustration that
other posters have expressed, to wit, that originating from a having
to learn a pretty complicated beast, without actually perceiving what
advantages the whole thing could incur into as compared to plain C.
I would be very grateful if somebody can provide examples of
the convenience of using C++ instead of C: what kind of problems,
techniques, and programming approaches. The books I have consulted
fail to do so.
Jose Castejon wrote:
>
> Travis C. Porco wrote:
> >
> > In article <··········@Masala.CC.UH.EDU>,
> > ········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
>
> I find this discussion quite interesting, as it is addressing
> implicitly a topic that has worried me for some time: What good is
> C++ for? More to the point, what features does it provide that makes
> it superior to C?
>
> These questions are motivated by the same frustration that
> other posters have expressed, to wit, that originating from a having
> to learn a pretty complicated beast, without actually perceiving what
> advantages the whole thing could incur into as compared to plain C.
>
C++'s intended target audience is programmers who on large projects,
often in teams. To anyone who has worked in such an environment
the extra features of C++ over c offer huge advantages in areas of
modularity and code reuse.
In other words the one of primary design aim of C++ was to address
well known large-scale software engineering problems (The same problems
that OO is trying to address) while making use of peoples existing
C skills. It is really not possible to get a "feel" for these
issues unless you have been there so you will just have to take
it on faith that the advantages are real.
> I would be very grateful if somebody can provide examples of
> the convenience of using C++ instead of C: what kind of problems,
> techniques, and programming approaches. The books I have consulted
> fail to do so.
It is difficult to give convincing trivial or small demostrations
of these advantages because the advantages in these sorts of cases
are indeed often marginal. But it is precisly because the examples
are *small* that the advantages of using C++ do not appear to be
that great.
Paul C.
UK.
In article <·············@marben.com> Jose Castejon <·········@marben.com> writes:
> I would be very grateful if somebody can provide examples of
> the convenience of using C++ instead of C: what kind of problems,
> techniques, and programming approaches. The books I have consulted
> fail to do so.
You might have a look at the book I wrote with Barbara Moo,
``Ruminations on C++'' (for more information, see
http://www.aw.com/cp/koenig-moo.html)
The book starts out with a programming example that shows
some things that C++ can do and C can't. Much of the rest
of the book is examples of using C++ to solve problems.
--
--Andrew Koenig
···@research.att.com
http://www.research.att.com/info/ark