Comparison of languages f
Ted Warring
-> > not generally support recursion or dynamic allocation would be used
-> > in a course where those topics are critical, time and time again,
-> in > the subject matter.
->
-> I'd like to discuss that point just a little. In the particular
-> context of systems designed for reliability, can you demonstrate that
-> arbitrary use of recursion and/or dynamic memory is safe within the
-> context of a finite system (i.e. limited stack and heap space)?
->
-> Mark Morgan Lloyd
-> mark...@cix.compulink.co.uk
Hi Mark!
I must say that I agree with your point here. This is an issue that was
originally brought to my attention by one of my VERY good CS profs a
number of years back. I must say from the perspective of a commercial
software developer (and supporting MANY lines of code) that I have
learned to be less than fond of recursive methods. Although the code
certainly tends to be more elegant when writing AVL tres and such, my
experience is that in REAL applications there are ALWAYS concerns
regarding stack space, and somewhat less, but nonetheless a factor, heap
space. Finding a bug in recursive code can be a trial, to say the
least. In most large business apps you tend to push the limits of
available RAM constantly... You ALWAYS want to state minimal required
hardware specs...
Unfortunately, most CS people tend to forget that real world
applications are built around functionality in adversity, rather than
elegance.
Regards,
Ted Warring
Larry Wall
Ted Warring <Ted.W...@f268.n114.z1.fidonet.org> wrote:
: Unfortunately, most CS people tend to forget that real world applications
: are built around functionality in adversity, rather than elegance.
Bingo.
Larry Wall
lw...@netlabs.com
Rick Sutcliffe
Wall) wrote:
The question is, should they be built around functionality in adversity or
around the principle good engineering supported by appropriate tools
prevents those adverse situations from ever arising.
Rick
--
Rick Sutcliffe Assoc. Prof. Computing/Math Trinity Western University
comp.lang.modula-2 FAQ maintainer & WG13(Can) chair. Not speaking for TWU/WG13
Marco van de Voort
Saturday May 27 1995 00:25, Ted Warring wrote to "mark Morgan Lloyd ":
TW> I must say that I agree with your point here. This is an issue that was
TW> originally brought to my attention by one of my VERY good CS profs a
TW> number of years back. I must say from the perspective of a commercial
TW> software developer (and supporting MANY lines of code) that I have
TW> learned to be less than fond of recursive methods. Although the code
TW> certainly tends to be more elegant when writing AVL tres and such, my
TW> experience is that in REAL applications there are ALWAYS concerns
TW> regarding stack space, and somewhat less, but nonetheless a factor, heap
TW> space. Finding a bug in recursive code can be a trial, to say the
TW> least. In most large business apps you tend to push the limits of
TW> available RAM constantly... You ALWAYS want to state minimal required
TW> hardware specs...
I find it sometimes hard to make a decision about the minimal amount of free
RAM required to run my programs.
Since several of my programs are BBS/Modem utilities, another problem is DesqView. People tend to configure a DV Window with a (free) size of 500k.
What do you think what's reasonable, before swapping to disk/EMS.
Marco (M.W.T.J....@stud.tue.nl or Mar...@stack.urc.tue.nl)
Larry Wall
Rick Sutcliffe <rs...@twu.ca> wrote:
: In article <1995May30....@netlabs.com>, lw...@netlabs.com (Larry
: Wall) wrote:
:
: > In article <80167897...@puddle.fidonet.org>,
: > Ted Warring <Ted.W...@f268.n114.z1.fidonet.org> wrote:
: > : Unfortunately, most CS people tend to forget that real world applications
: > : are built around functionality in adversity, rather than elegance.
: >
: > Bingo.
:
: The question is, should they be built around functionality in adversity or
: around the principle good engineering supported by appropriate tools
: prevents those adverse situations from ever arising.
Leaving aside the fact that you just redefined elegance, good engineering
*requires* the existence of tools that function well in adversity. There's
much of life that can't be controlled by engineering, and much of that is
adverse.
Just to take one example, many of the decisions in a business are made
for, um, business reasons. The most successful products are compromises
between engineering and marketeering. Companies with too much marketeering
put out crap. Companies with too much engineering never put out anything.
The most successful products are about 90% crap.
As an engineer, I agree that we should avoid generating our own internal
adversity. But this cuts both ways. Keeping "modern" compilers happy
can be construed as another form of adversity. Companies have gone out
of business because of it. Fortunately it's a little harder to put
schools out of business, or we'd have lost a bunch of 'em by now.
My apologies for being so adversarial...
Larry
Martin Tom Brown
rs...@twu.ca "Rick Sutcliffe" writes:
> In article <1995May30....@netlabs.com>, lw...@netlabs.com (Larry
> Wall) wrote:
>
> > In article <80167897...@puddle.fidonet.org>,
> > Ted Warring <Ted.W...@f268.n114.z1.fidonet.org> wrote:
> > : Unfortunately, most CS people tend to forget that real world applications
> > : are built around functionality in adversity, rather than elegance.
> >
> > Bingo.
>
> The question is, should they be built around functionality in adversity or
> around the principle good engineering supported by appropriate tools
> prevents those adverse situations from ever arising.
One of the things I always wonder about when I'm sat in an Airbus or
other fly-by-wire passenger aircraft is just how good is the test
coverage, dual redundancy and how complete the manual override.
And in the case of the Airbus why they fly with an extra 2 tonne of
fuel because of a known bug in the system which sometimes deducts
about 2 tonnes from the fuel gauge indicator during final approach.
(This was reported in the UK press a month ago, a fix is in progress)
Nature and chance have a nasty habit of contriving to create adverse
situations that cannot be adequately forseen in any reasonably complex
control system. AFAIK there is quite a small limit on the size of
software that can be constructed with a formal proof of correct
functionality, and even that is vulnerable to specification errors.
I would certainly like to see the tools get better!
Best regards,
--
Martin Brown <mar...@nezumi.demon.co.uk> __ CIS: 71651,470
Scientific Software Consultancy /^,,)__/
Ted Warring
-> > Ted Warring <Ted.W...@f268.n114.z1.fidonet.org> wrote:
-> > : Unfortunately, most CS people tend to forget that real world
-> applications > : are built around functionality in adversity, rather
-> than elegance. >
-> > Bingo.
->
-> The question is, should they be built around functionality in
-> adversity or around the principle good engineering supported by
-> appropriate tools prevents those adverse situations from ever
-> arising.
->
-> Rick
Hi Rick!
I think you may misunderstand what I am trying to communicate. I am
trying to make clear that good engineering includes design criteria
based upon the complete project specifications, functionality, and
circumstances. Unfortunately, there seems to be a belief that
commercial software developers by definition do not believe in solid
design principles. This is just plain not true.
As an example, I (like most programmers) have a few "favorite ways" of
implementing data structures for a given class of problem. Some of
these have a high cost in memory usage, and/or slower performance than
other methods. Nonetheless, I consider them to be the most conceptually
clear, or "elegant" solution to a problem. If I am writing a program
for a grade, then undoubtably I would use the approach I considered the
most estheticly pleasing. On the other manipulative extremity, were I
implementing such a module for inclusion in a large 100,000 line
application that had little to no dynamic memory free at run-time, I
would use a less pleasing, but more memory efficient approach.
In summary then, I was chiming in because I see much to much of the:
"for this problem, this is THE solution" type thinking. I have
developed my own design criterion weighting system based upon:
performance, resource usage, supportability, and development time. In
business situations these basis may shift in priority, and I make my
design decisions situationally.
Best regards,
Ted Warring, BS CSE
Rick Sutcliffe
Ted.W...@f268.n114.z1.fidonet.org (Ted Warring) wrote:
> I think you may misunderstand what I am trying to communicate. I am
> trying to make clear that good engineering includes design criteria
> based upon the complete project specifications, functionality, and
> circumstances. Unfortunately, there seems to be a belief that
> commercial software developers by definition do not believe in solid
> design principles. This is just plain not true.
That depends on the organization. I know of several (upgrades of)
commercial software that were months or even years late because of bad
engineering and poor development tools.
>
> As an example, I (like most programmers) have a few "favorite ways" of
> implementing data structures for a given class of problem. Some of
> these have a high cost in memory usage, and/or slower performance than
> other methods. Nonetheless, I consider them to be the most conceptually
> clear, or "elegant" solution to a problem. If I am writing a program
> for a grade, then undoubtably I would use the approach I considered the
> most estheticly pleasing. On the other manipulative extremity, were I
> implementing such a module for inclusion in a large 100,000 line
> application that had little to no dynamic memory free at run-time, I
> would use a less pleasing, but more memory efficient approach.
Of course. We all have such preferences.
>
> In summary then, I was chiming in because I see much to much of the:
> "for this problem, this is THE solution" type thinking. I have
> developed my own design criterion weighting system based upon:
> performance, resource usage, supportability, and development time. In
> business situations these basis may shift in priority, and I make my
> design decisions situationally.
>
Oh I agree with you. My point of view is not so much that of a Modula-2
specialist, which I am as a BTW, but as a CS linguist, teacher, old
programmer, hacker, reviewer, and general industry knockabout. If I have
a "native" language is is probably 6502 assembler. From those points of
view, I see much of the attitude of "let's hack it together and get it out
the door"- an attitude promoted more by some shops, some languages, some
tools, and some managers than by others. Too many have what little design
philosophy they possess driven solely by the marketing group.
Dale Pontius
In article <rsutc-07069...@nsc189t100.twu.ca>, rs...@twu.ca (Rick Sutcliffe) writes:
>
> That depends on the organization. I know of several (upgrades of)
> commercial software that were months or even years late because of bad
> engineering and poor development tools.
>
begin with. I don't think anyone expects a software project to come
in on time, on budget, today.
Can you point to a counter-example? Good tools, good engineering,
therefore on time, on budget?
Dale Pontius
(NOT speaking for IBM)
Mark Morgan Lloyd
> elegance.
Also, many "real world" projects have to be debugged, both in the lab and
in the field. The average CS graduate knows how to handle umpteen
different kinds of data structure and how to write a compiler... but
stands less chance than a whelk in a supernova of driving a logic
analyser. The better type of EE graduate can drive an analyser in
extremis, and knows that when he needs a fancy data structure or a
special-purpose compiler he either heads for the nearest specialist
library or hires somebody.
There was an excellent course at a UK university some years ago (IIRC
"Electronics and Computer Systems") that had its accreditation withdrawn
because it did not cover electrical machines (i.e. motors & generators)
in enough detail. In this country, computers go with maths. In the USA,
computers go with electronics. Is it surprising which of the two is
dominant in the industry?
Mark Morgan Lloyd
mark...@cix.compulink.co.uk
*** Please note my USENET feed may be unreliable- email address as above
***
[Opinions above are the author's, not those of his employers or
colleagues]
Ted Warring
-> the: > "for this problem, this is THE solution" type thinking. I
-> have > developed my own design criterion weighting system based upon:
-> > performance, resource usage, supportability, and development time.
-> In > business situations these basis may shift in priority, and I
-> make my > design decisions situationally.
-> >
-> Oh I agree with you. My point of view is not so much that of a
-> Modula-2 specialist, which I am as a BTW, but as a CS linguist,
-> teacher, old programmer, hacker, reviewer, and general industry
-> knockabout. If I have a "native" language is is probably 6502
-> assembler. From those points of view, I see much of the attitude of
-> "let's hack it together and get it out the door"- an attitude
-> promoted more by some shops, some languages, some tools, and some
-> managers than by others. Too many have what little design philosophy
-> they possess driven solely by the marketing group.
->
-> Rick
Agreed with bells on. I have seen more than one product go out the door
because the "bug ratio" was low enough.
I find it frustrating because every software team I have led (though I
usually didn't get to pick the members) has been comprised of those that
didn't bother to test their code before deciding it was done, and those
that never quite finish "designing" their software.
Well...I can't help but to be outspoken on this one... I feel that the
industry is still "guru" driven. I have had no problem finding
programmers that I could flog into writing code (as long as they are
closely supervised), but it is rare to find someone that I can give a
concept to and receive an acceptable application as a result.
I have tired of the old "art" analogy.... I adamantly wish someone would
provide a better one.
Ted
Presbyte
"I have seen more than one product go out the door because the 'bug ratio'
was low enough."
Well, speaking pragmatically, I feel that it is not dishonorable to ship a
product that contains bugs, provided that 1) an honest effort has been
made to repair or obviate old bugs; 2) Any bugs that remain do not
compromise a customer's systems or data; 3) Bugs that remain are
documented; and 4) You can honestly say that you feel the new release is
an improvement over the old release.
Sometimes, you just have to keep that revenue stream going, in order to
stay in business. But putting "tail fins" on last year's model is not
acceptable. Any update or upgrade should improve the customer's lot by an
amount commensurate with any charge you decide to make for the upgrade.
Some people value features more; others value reliability and robustness
more. I happen to be among the latter, but I also know that it is hard to
sell "bug-fix" or "performance optimization" releases. For one thing, I
don't feel it is right to charge money for bug fixes. But a business has
to make money, somehow. So, performance enhancements and new features are
generally the order of the day, yet any new work one does entails the risk
of introducing (or uncovering) new bugs. We can improve our methods and
procedures over time. And the goal should always be "zero defects." But
making that an absolute requirement -- especially at this stage in our
industrial development -- would mean that a lot of worthwhile software
would never ship. The only honest thing to do, it seems to me, is to be
honest about software's limitations, in both functionality and
reliability. Customers should only "bear with us," after providing their
own informed consent.
Ted also wrote: "I have tired of the old 'art' analogy.... I adamantly
wish someone would provide a better one."
I agree with that. Art is "expression" that is thrust into the public
eye, almost as an act of defiance. Art says, "deal with it." No
warranties, no regrets. That may be a good model for a games programmer,
but not for anyone who is building applications, utilities, or systems
software.
In my group, we are trying to move toward a Civil Engineering discipline
-- we are building bridges, houses, and roads along the infobahn. I have
acquainted my staff with the ancient Code of Hammurabi ("If a Builder
Build a House and it fall down and kill the Owner, the Builder shall be
put to death; if the House fall down and kill the Owner's Son, the
Builder's Son shall be put to death." Did you know that they had one-year
warranties on ships in the old Babylonian days?) I ask my engineers to
pretend that Hammurabi is still running the show, knowing full well that
if he really were still around, we would all be twisting away in the
public square.
I tell you truthfully, if Hammurabi were calling the shots, I would not
dare to work in anything but Modula-2. There might be better vehicles for
rock-solid reliability, but I am not aware of them; the simplicity of M2
makes it more tenable for someone to place their reputation and career in
the hands of a compiler.
Just my two-cents. Your mileage may vary.
-Jim Merritt
Capitola CA