Advanced C++ Programmer can't tolerate JAVA.
Alexander Anderson
>>Computer scientists generally care about formal, clear language
>>definitions, support for modularity and abstraction, and runtime
>>safety. From that point of view, C++ is about the antithesis of how a
>>language should be designed.
COPIED FROM http://www.cm.cf.ac.uk/CLE//volume97/18338
-------------------------------------------------------
Subject: Avoiding the second historic mistake
Newsgroups: comp.object,comp.software-eng,comp.lang.java.tech,comp.lang.java.programmer,comp.lang.eiffel,comp.lang.c++
X-Article-Creation-Date: Sun May 04 03:01:23 1997 GMT
--
"Think Java. Write new applications in Java.
Rewrite legacy apps with Java.
Don't upgrade or downgrade. Sidegrade instead to
a Java desktop device. Don't get hit with the
PC's massively negative ROI.
I don't understand why anybody would be
programming in anything other than Java"
Scott McNealy, Open Finance (a Sun publication),
Spring 1997.
Ten years ago or so, when object technology first captured
the industry's attention, projects moved en masse to C++.
This was not the right decision. Not that everything was bad
with C++ (then it would not have attracted so many
people); it was simply not appropriate for serious software
engineering. C++ was a transition technology, useful to make C
developers and their managers object-aware, but not appropriate
for the development of durable, high-quality software systems.
Interestingly enough, this was clear to many people; virtually
every object-oriented expert would privately concede that C++
was an inadequate solution - but carefully refrain from saying
so in public, for fear of appearing to go against the tide.
This is happening again with Java. Once again we have an
approach that has some major contributions to make but is
hyped as the solution to everything - and is not.
The contributions are clear enough. Java is good as
a language to write applets, and (through its virtual
machine) as a portable vehicle for executing programs written
in various languages. Its dynamic aspects are also interesting
for many applications.
But Java is inadequate as a software engineeering language for
enterprise applications. The deafening and at times indecent
marketing campaign that has been running continuously for almost
two years now (the quote at the beginning of this article is
typical) conveniently overlooks the limitations of Java:
- Unproven on large projects. Applets are great, but then
what?
- No multiple inheritance. (The marketing spin here is
quite smart: trying to convince people that multiple
inheritance is "bad", a contention for which not a single
piece of concrete evidence has ever been published, whereas
anyone who has practiced O-O development knows how important
it is to be able to combine separate abstractions.)
- No generic classes (forcing the frequent use of type casts,
with disastrous effects on both performance and safety).
- No assertions (even the modest "assert" of C++ has been
removed). This means - let's be clear about it -
that it is impossible to write serious reusable components
in Java, because serious reuse requires that the components
be specified. (See
http://www.eiffel.com/doc/manuals/technology/contract/ariane)
for a $500-million example of what happens when one violates
this elementary rule.) It's great to devise fancy names,
such as JavaBeans, but once the hype subsides
who is going to trust a mission-critical development to
"reusable" components who do not even document, let
alone monitor, their own specification?
- A neutered form of overriding (redefinition): when you
redefine a routine, you cannot change its signature.
This severely limits the application of polymorphism
and other fundamental O-O techniques. (If A has e.g.
a routine `copy' that takes an argument of type A,
representing an object to be copied, its redefinition
in a descendant class B must take an argument of type
B - otherwise it makes no sense. The only solution in
a no-signature-change language again appears to be the
use of casts, removing the benefits of type controls.)
- Violations of information hiding, hampering
object-oriented principles (you can write
a.x = value directly, i.e. modify an object field
without going through the interface of the class!).
- The confusing name overloading mechanism of C++ (what does
a.f (x) mean if a and x are polymorphic and f is both
redefined and overloaded for the corresponding types?).
- The confusing syntax of C, replete with special characters
and counter-intuitive conventions.
- Inadequate tools and environments (as confirmed recently by
a survey in ComputerWorld).
- Major performance problems (a project we know gave
up on Java after experiencing a tenfold performance
degradation compared to C++). Of course the vendors promise
that all will be fixed, and again the buzzwords are impressive,
as with "Just in Time Compiling", but buzzwords don't make
an application run faster.
As one .sig found on the net (I believe from Roland Turner)
states: "Java: the elegant simplicity of C++ and the blazing
speed of Smalltalk".
It is interesting to compare this with Eiffel:
- Used in projects large and small for eleven years.
- At the basis of large, successfully deployed commercial
projects in banking, networking, telecommunications,
health care etc.
- Taught successfully for many years in universities around
the world, because it is simple, clear and convincing.
- Used by experienced programmers as well as managers,
bankers, traders, engineers and specialists from widely
different backgrounds.
- The only approach that covers the entire lifecycle,
from analysis to design, implementation and maintenance
(no need for complex diagramming mechanisms
such as UML). Avoids the split personality of many
projects, where the analysis says one thing and the
software does another, and no one understands both.
- Widely cited as the most serious O-O language around
(e.g. in the OMT book by Rumbaugh et al.: "Eiffel is the
best commercially available object-oriented language",
and scores of similar comments in the literature).
- Offers a powerful inheritance mechanism supporting single,
multiple and repeated inheritance in a clear and simple way.
- Comes with thousands of proven reusable components, such
as EiffelBase, EiffelVision (portable graphics), EiffelNet
(client-server object communication), EiffelMath (numerical
computing), WEL (Windows graphics), EiffelStore (relational
database support), Matisse and Versant interfaces...
- Makes true reuse possible through the application of
carefully thought out reuse principles ("Reusable Software",
Prentice Hall).
- The only approach that can make reuse succeed on a truly
large scale thanks to its built-in support for assertions
(testable component specification, included in the
components themselves and used to generate the documentation).
- Runs on all major industry platforms, from Windows NT and
95 to all significant Unixes and VMS, with full source
compatibility.
- Run-time performance similar to C or C++.
- Instant recompilation, independent of project size,
thanks (in ISE Eiffel) to the Melting Ice Technology.
- An amazingly powerful environment, whose browsing facilities
have no equivalent for any language.
- Built-in automatic memory management and garbage collection.
- Interface to popular GUI builders through the Eiffel
Resource Bench. (Why redo what already exists? Object
technology is about leveraging software value, not doing
everything differently.)
- Interfaces to CORBA (soon to be released) and many other
industry-standard products.
- Backed (see http://www.eiffel.com/doc) by at least two
dozen books in English, Italian, French, German, Russian,
including in-depth descriptions of practical Eiffel
projects ("Object-Oriented Applications", Prentice Hall).
Extensive, award-winning on-line documentation at
http://www.eiffel.com.
- Now with support for multi-threading and (in SCOOP,
to be released later this year) arbitrary concurrency.
- Cheap personal versions (Windows, Linux), generous
university packages
(http://www.eiffel.com/services/university),
affordable token-based licensing.
Does this mean that one should drop everything else? Of course not.
As Roy Phillips noted in a recent posting to comp.lang.eiffel,
there is room and need for more than one language.
Eiffel recognizes the presence and usefulness of both
C++ (including C) and Java. Through its C++ interface and C++
wrapper (the recently released "Legacy++", see
http://www.eiffel.com/doc/manuals/technology/cpp/index.html),
ISE Eiffel provides clean encapsulation of C++ classes, in the
same way that it provides encapsulation of C functions.
Through its Java generation mechanism, slated for release later
this year, it will allow Eiffel developers to take advantage of
the Java VM and to combine Eiffel and Java code.
But the forced march to Java in 1997 is no more justified than the
mass conversions to C++ in 198. This time we don't have the
excuse that we don't know; and no spacecraft hides, ready to
rescue us, behind the comet.
Can we as an industry learn from our mistakes? How many more
Taligent-like catastrophes are needed, with Java replacing C++,
to discover the obvious? Must we lose another ten years?
No. One does not have to sacrifice the success of projects
to the fashion of the day. That you can use a language to spin
a fancy picture on a Web page does not mean you should use it
to program your bank's market trading.
There is money to be made now by choosing the right technical
approach. Using Eiffel, you can bring your projects to
completion faster and better. You can develop professional
reusable components and sell them. You can underprice the
competition on bids because you have a better technology.
One mistake is good; we as an industry can learn from it.
Two is one too many.
--
Bertrand Meyer, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
Web page: http://www.eiffel.com
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Xref: loki.cf.ac.uk comp.lang.c++:223477 comp.lang.eiffel:18338 comp.lang.java.programmer:55526 comp.lang.java.tech:10219 comp.object:58087 comp.software-eng:50759
Path: loki.cf.ac.uk!yama.mcc.ac.uk!basilisk.pdc.nhs.gov.uk!peernews.ftech.net!telehouse1.frontier-networks.co.uk!azure.xara.net!xara.net!news-feed.inet.tele.dk!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!news-peer.sprintlink.net!news.sprintlink.net!Sprint!news.maxwell.syr.edu!newsfeed.internetmci.com!jump.net!grunt.dejanews.com!not-for-mail
Date: Sat, 03 May 1997 22:11:08 -0600
From: Bertran...@eiffel.com
Subject: Avoiding the second historic mistake
Newsgroups: comp.object,comp.software-eng,comp.lang.java.tech,comp.lang.java.programmer,comp.lang.eiffel,comp.lang.c++
Message-ID: <862714...@dejanews.com>
Reply-To: Bertran...@eiffel.com
Organization: Deja News Usenet Posting Service
X-Article-Creation-Date: Sun May 04 03:01:23 1997 GMT
X-Originating-IP-Addr: 198.68.147.2 (outback.eiffel.com)
X-Http-User-Agent: Mozilla/3.01Gold (X11; I; SunOS 4.1.3 sun4c)
X-Authenticated-Sender: Bertran...@eiffel.com
Lines: 232
T Jurik
claim that "durable, high-quality software systems" are inappropriately
developed using C++ and Java fly in the face of experience and very good
examples that prove otherwise.
Reliable systems and high-quality software have less to do with the specific
technologies that are used to implement them and more to do with the
organizations, culture and people that develop the systems.
Yes, it is nice to have languages that reduce possibilities of memory
errors, are fast, etc., but the bottom line is that non-trivial systems
require intelligent people, robust requirements, significant architecture
and design and some coding.
Tim
>This was not the right decision. Not that everything was bad
>with C++ (then it would not have attracted so many
>people); it was simply not appropriate for serious software
>engineering. C++ was a transition technology, useful to make C
>developers and their managers object-aware, but not appropriate
>for the development of durable, high-quality software systems.
>Interestingly enough, this was clear to many people; virtually
>every object-oriented expert would privately concede that C++
>was an inadequate solution - but carefully refrain from saying
>so in public, for fear of appearing to go against the tide.
>The contributions are clear enough. Java is good as
>a language to write applets, and (through its virtual
>machine) as a portable vehicle for executing programs written
>in various languages. Its dynamic aspects are also interesting
>for many applications.
>
>But Java is inadequate as a software engineeering language for
>enterprise applications. The deafening and at times indecent
>marketing campaign that has been running continuously for almost
>two years now (the quote at the beginning of this article is
>typical) conveniently overlooks the limitations of Java:
<Rantings snipped>
Matt Kennel
:Technology is rarely the problem in implementing reliable systems. Your
:claim that "durable, high-quality software systems" are inappropriately
:developed using C++ and Java fly in the face of experience and very good
:examples that prove otherwise.
:Reliable systems and high-quality software have less to do with the specific
:technologies that are used to implement them and more to do with the
:organizations, culture and people that develop the systems.
Is it really so? Could you as reliably and economically organize a culture
and people to implement equally complicated software as those examples which
were written in C++ in assembly language, instead?
:Yes, it is nice to have languages that reduce possibilities of memory
:errors, are fast, etc., but the bottom line is that non-trivial systems
:require intelligent people, robust requirements, significant architecture
:and design and some coding.
Of course. But is there any evidence that better technology helps
intelligent people less than the 'other kind'?
There is often the typical assumption that the "threshold of
diminishing improvement" is always right at the level of the "current
industry-standard technology", even when, in retrospect, we weren't
even close.
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* "do || !do; try: Command not found"
* /sbin/yoda --help
Jay O'Connor
wrote:
>What would be thought of a car or aeroplane where one out of every hundred
>sold crashed and killed its occupants because of a design flaw? There would
>be an outcry, the product would be forcibly removed from the market, and
>litigation against the manufacturers would undoubtedly be successful. Yet
>software manufacturers tout products of a similar or worse level of
>reliability as "durable, high-quality software systems".
I was once on a project that was being totally mismanaged and was
becoming a disaster.
At one point I turned to my cowrokers and said "Would you fly on an
airplane that was designed they way we're building this software?"
No answers but some wide-eyed looks of panic.
>
>T Jurik wrote in message <74l1en$aih$1...@news01.li.net>...
>>"durable, high-quality software systems"
>
>
Jay O'Connor
joco...@roadrunner.com
http://www.roadrunner.com/~joconnor
"God himself plays on the bass strings first, when he tunes the soul"
Mike Spille
>
> On Wed, 9 Dec 1998 00:26:16 -0500, T Jurik <t...@mindstreamsw.com> wrote:
> :Technology is rarely the problem in implementing reliable systems. Your
> :claim that "durable, high-quality software systems" are inappropriately
> :developed using C++ and Java fly in the face of experience and very good
> :examples that prove otherwise.
>
> :Reliable systems and high-quality software have less to do with the specific
> :technologies that are used to implement them and more to do with the
> :organizations, culture and people that develop the systems.
>
> Is it really so? Could you as reliably and economically organize a culture
> and people to implement equally complicated software as those examples which
> were written in C++ in assembly language, instead?
>
I agree completely, Matt. The key words in your above statement to me are
"reliably" and "economically". Given super human effort one people can
deliver almost anything - witness NASA's push to the moon.
It's phenomenally awarding to put forth such effort, but...eventually, expending
super human effort on every project gets tiresome :-)
This is not to say that programming in, say, C++ takes a super human effort.
What I mean is that it makes sense to develop tools that lessen the effort and
increase the chance for success. C was a step in that direction, as are
Smalltalk and, yes, Java - they make common programming tasks easier. C++, IMHO,
is a giant question mark on this issue. It added alot of capabilities which
give programmers more expressiveness, but it also burdened the programmer
with alot of complexity.
Yes, a great culture and implementation team can wield C++ to create great
software. But don't people think the same team could do even better things
with a better language?
> :Yes, it is nice to have languages that reduce possibilities of memory
> :errors, are fast, etc., but the bottom line is that non-trivial systems
> :require intelligent people, robust requirements, significant architecture
> :and design and some coding.
>
> Of course. But is there any evidence that better technology helps
> intelligent people less than the 'other kind'?
>
> There is often the typical assumption that the "threshold of
> diminishing improvement" is always right at the level of the "current
> industry-standard technology", even when, in retrospect, we weren't
> even close.
>
> --
> * Matthew B. Kennel/Institute for Nonlinear Science, UCSD
> *
> * "do || !do; try: Command not found"
> * /sbin/yoda --help
-Mike
Brian A Stefanish
Yet where is the outcry?? :~(
There should of been a class action suit against MS for faulty software.
Nick Payne wrote in message <366ee...@newshost.pcug.org.au>...
>What would be thought of a car or aeroplane where one out of every hundred
>sold crashed and killed its occupants because of a design flaw? There would
>be an outcry, the product would be forcibly removed from the market, and
>litigation against the manufacturers would undoubtedly be successful. Yet
>software manufacturers tout products of a similar or worse level of
>reliability as "durable, high-quality software systems".
>
Peter van der Linden
>
>As C.A.R Hoare said, Algol was a great improvement on most of its successors.
It was actually Dijkstra who coined that phrase.
Nick Payne
Ian Joyner
> errors, are fast, etc., but the bottom line is that non-trivial systems
> require intelligent people, robust requirements, significant architecture
> and design and some coding.
Having decent tools is not just a nicety. The whole progress of the human race
has been to have better tools. Could you put today's most intelligent human
beings in the caveman era, and expect them to recreate today's society just on
their intelligence? No, they need the tools.
On the subsequent point... the point of Meyer's work is a programming language
that just does not do coding alone, but includes elements of requirements
analysis, architecture and design: the expression of these is all done in
language, so wouldn't it be nice if these languages dovetailed into
implementation languages.
Given all that... I strongly agree that you can't put advanced tools in the
hands of idiots and expect good systems to be built; you need good people and
expertise. But this does not prove that better tools are just a nicety.
> "I don't understand why anybody would be
> programming in anything other than Java"
>
> Scott McNealy, Open Finance (a Sun publication),
> Spring 1997.
The more I look at Java, and use it and consider the things that it lacks:
genericity, covariant redefinition, code multiple inheritance, anchored types,
the more I wonder why so many people are using it: the lack of these things gets
in the way all the time for serious software development.
--
Ian Joyner
Microsoft Research Institute Macquarie University
i.jo...@acm.org
http://www.mri.mq.edu.au/people/ian.html
Ian Joyner
> This is not to say that programming in, say, C++ takes a super human effort.
> What I mean is that it makes sense to develop tools that lessen the effort and
> increase the chance for success. C was a step in that direction, as are
First there was ALGOL... this was a big step in the right direction, then CPL which
was supposed to be practical ALGOL, was a slight step backwards. BCPL which was Basic
CPL was another step backwards. Then came B, a big step backwards (it took the Basic
and dropped the CPL), and C was a small step forwards over this. I think in all this
C had by the time it came around lost the plot.
The plot that it really found, which was more by accident than intention was cross
platform development, but that would have been in ALGOL anyway.
C did not prove that OSs could be written in HLLs: that belonged already to ALGOL on
the B5000 (~1964), and this OS survives today as still much better, fully featured
and robust than Unix and any other OS for that matter.
As C.A.R Hoare said, Algol was a great improvement on most of its successors.
(comp.sys.unisys added for comments on B5000. Please remove comp.sys.unisys if
replies do not specifically follow this thought).
Ken Carpenter
>
> What would be thought of a car or aeroplane where one out of every hundred
> sold crashed and killed its occupants because of a design flaw? There would
> be an outcry, the product would be forcibly removed from the market, and
> litigation against the manufacturers would undoubtedly be successful. Yet
> software manufacturers tout products of a similar or worse level of
> reliability as "durable, high-quality software systems".
While I agree with you that a lot of today's commercial software is of
generally poor quality, I think your comparison is too harsh. Software
defects do not always manifest themselves as "crashes", nor do defects
in mechanical systems like airplanes and cars.
I owned a 1992 Chevrolet Corsica for 5 years. During that time, it
experienced the following (partial) list of "quality flaws":
- Dash instrument module replaced twice
- Front/rear brakes required replacement/machining every 3-6 months
- Alternator failed/replaced 3 times
- Transmission torn to shreds internally; completely replaced
internals
- Aluminum-to-aluminum hose fitting "rotted" (apparently due to some
sort of static electricity thing or some such automotive mumbo
jumbo)
- Engine lurch problem at idle; taken in for service many times, but
never fixed properly.
Now some of these items were repaired/replaced under warranty, many
others were not. As the crowning achievement, this car failed to start
when I was about to take it to the dealer for inspection as a trade-in.
Guess what? Another alternator, and more extensive electrical system
damage.
As to your original question of "What would be thought of" such a car?
I thought it was a steaming piece of crap, but I was fresh out of
university at my first job, and the cost of switching to another car
was too much for me for a while.
Similarly in the software field, people have a lot of time and money
invested in (let's just say) Windows, Word, Excel, etc. Humans are
so amazingly adaptive that we sometimes seem to enjoy figuring out
how to work around little bugs in both "real" products and software.
Like when Word screws up redrawing the screen (which it does quite
frequently), I almost unconsciously reach for the Page Up/Page Down
keys to fix things.
Ken Carpenter
Alexander Anderson
>Could you put today's most intelligent human
>beings in the caveman era, and expect them to recreate today's society just on
>their intelligence? No, they need the tools.
I must protest in the most icy terms that the above discussion is
completely off topic, and childish nonsense to boot. If you want to
talk about this, I suggest you use proper channels, like
yak.yak.blah.misc.zzzz...
...If today's most intelligent human beings walk around telling
great big lies, chewing gum, wearing dark glasses, leering absently with
their mobile phones, crossing and recrossing their legs with consumate
nonchalance at the mearest whiff of reality, then they wouldn't need any
tools "to recreate today's society":
They would merely have to leer up a "What's your problem?" to an
already pissed off wooly mammoth and they'd have recreated latterday
California in an instant.
Of course, if by society you mean the freedom to be mildly bored by
the Leonid meteor showers lighting up the skies beyond your bedroom
window panes because you're scrambling to record "Star Trek: The Next
Generation" over last week's football match, then I grant you, yes, you
would indeed need the tools.
True, false, or indifferent?
With the Kindest of Regards,
Sandy and Kelly
P.S. dot java
/* CORRECT MY ADDRESS in any reply, or it'll be treated as spam:
--
// Alexander Anderson <DELETE_T...@alma-servicesSPAMATTACK.co.uk>
// Home Fone +44 (0) 171-794-4543
// London, UK http://www.almide.demon.co.uk/
// PGP print C6 8C 55 F2 77 7B 99 9B 14 77 66 F5 B8 74 CF 12
*/
James Kanze
|> The more I look at Java, and use it and consider the things that it lacks:
|> genericity, covariant redefinition, code multiple inheritance, anchored types,
|> the more I wonder why so many people are using it: the lack of these things gets
|> in the way all the time for serious software development.
For many of us, the alternative is C++. That's a mighty powerful
argument in favor of Java. (On the other hand, when you need C++ to
look good, it's not a very good argument for your language.)
--
James Kanze GABI Software, Sàrl
Conseils en informatique orienté objet --
-- Beratung in industrieller Datenverarbeitung
mailto: ka...@gabi-soft.fr mailto: James...@dresdner-bank.com
Stefano Gaburri
ciao
S
Alexander Anderson wrote:
Thaddeus L. Olczyk
wrote:
>In article <366F4AC1...@mpce.mq.edu.au>,
>Ian Joyner <i.jo...@acm.org> wrote:
>[Interesting potted history of the wobbles of HLL development snipped]
>>C did not prove that OSs could be written in HLLs: that belonged already
>>to ALGOL on the B5000 (~1964), and this OS survives today as still much
>>better, fully featured and robust than Unix and any other OS for that matter.
>
>An OS in Algol? Well, hurrah! Where can I get a copy for my PC?
>[or do I have to have a real computer if I want a real OS?] ;-)
>
>All the best,
>
>John.
I don't think you can find much if any software written in Algol now
that is being actively maintained ( as opposed to it's
predecessors/contemporaries Fortran and COBOL ).
For all it's praise, it was not used that much. Perhaps, a lesson for
modern language designers?
Nat Pryce
> The more I look at Java, and use it and consider the things that it lacks:
> genericity, covariant redefinition, code multiple inheritance, anchored types,
> the more I wonder why so many people are using it: the lack of these things gets
> in the way all the time for serious software development.
Because of the large selection of reasonably well designed
APIs. At least, that's why I swapped from C++ on Win32.
Many of the Win32 APIs are hideously over complicated, poorly
specified, non-standard and bodged with backwards compatibility
features that don't work in practice. And then when you put
something like MFC on top of them...
Compared to that, Java was a breeze. I found a massive boost
in productivity by switching to Java. It's a shame that
better languages don't get the same level of hype.
Cheersm
Nat.
--
+------------------------------------------+---------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: n...@doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen's Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
+------------------------------------------+---------------------+
R. Kerr
ALGOL spawned SIMULA and SIMULA spawned OO, so what's the lesson?
Cheers....Ron
L. Darrell Ray
>
> On 10 Dec 1998 10:52:36 -0000, css...@brunel.ac.uk (John D Salt)
> wrote:
>
> >Ian Joyner <i.jo...@acm.org> wrote:
> >[Interesting potted history of the wobbles of HLL development snipped]
> >>C did not prove that OSs could be written in HLLs: that belonged already
> >>to ALGOL on the B5000 (~1964), and this OS survives today as still much
> >>better, fully featured and robust than Unix and any other OS for that matter.
> >
> >An OS in Algol? Well, hurrah! Where can I get a copy for my PC?
> >[or do I have to have a real computer if I want a real OS?] ;-)
> >
> >All the best,
> >
> >John.
>
> that is being actively maintained ( as opposed to it's
> predecessors/contemporaries Fortran and COBOL ).
> For all it's praise, it was not used that much. Perhaps, a lesson for
> modern language designers?
It is still very much in use in the UNISYS A-series (formerly Burroughs)
mainframe world. The OS is in an ALGOL dialect and a LOT of
applications, utilities, etc. are sill being written and maintained in
one of the ALGOL dialects.
As for not used much, well I guess it depends on your definition of use.
If you mean number of programmers writting code then you are right. If
you mean number of people affected by applications written in ALGOL
dialects or even number of people using programs written in ALGOL then
it is still very much in use.
--
L. Darrell Ray
ASQ Certified Software Quality Engineer
Dade Behring
.
John D Salt
[snippage]
>> For all it's praise, it was not used that much. Perhaps, a lesson for
>> modern language designers?
>
Ummmm... (guessing wildly) Operating Systems should be written in
Simula? Better yet than Algol, and also a great improvement on
most of its successors...<sigh>
>Cheers....Ron
Is the ASU still alive, Ron? Will it const me money to re-join?
All the best,
John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
Seth Jones
>Compared to that, Java was a breeze. I found a massive boost
>in productivity by switching to Java. It's a shame that
>better languages don't get the same level of hype.
Excuse me? Java has gotten far more "hype" than any other language
in the history of computing.
Seth Jones
Jay O'Connor
wrote:
I read that to mean that there are languages better than Java that
does get as much hype, and thus as much attention as they deserve.
Bertrand Meyer
> !!! As C.A.R Hoare said, Algol was a great improvement on most of its successors.
Peter van der Linden answered:
> It was actually Dijkstra who coined that phrase.
Why do you think that?
"The more I ponder the principles of language design, and the
techniques that put them into practice, the more is my amazement
at and admiration of ALGOL 60. Here is a language so far ahead of
its time that it was not only an improvement on its predecessors
but also on nearly all its successors".
C.A.R. Hoare, "Hints on Programming Language Design", 1973
(This was among other places in a Stanford AI Lab report which I have
at home, but I just checked it in the reprint of the article in
Hoare and Jones, [Hoare's] "Essays on Computing Science", Prentice
Hall, 1989, page 214.)
--
Bertrand Meyer, Interactive Software Engineering
ISE Building, 2nd floor, 270 Storke Road, Goleta CA 93117
805-685-1006, fax 805-685-6869, <Bertran...@eiffel.com>
http://eiffel.com
Charles Martin - Sun PS
> Thaddeus L. Olczyk (olc...@interaccess.com) wrote:
> > On 10 Dec 1998 10:52:36 -0000, css...@brunel.ac.uk (John D Salt)
> > wrote:
>
>
> > I don't think you can find much if any software written in Algol now
> > that is being actively maintained ( as opposed to it's
> > predecessors/contemporaries Fortran and COBOL ).
> > For all it's praise, it was not used that much. Perhaps, a lesson for
> > modern language designers?
>
> ALGOL spawned SIMULA and SIMULA spawned OO, so what's the lesson?
>
Part of the lesson is that it helps to actually know/remember the
history instead of trying to deduce it out of thin air....
Algol was *very* broadly used Back In The Old Days, not just as an
implementation language in Europe, but also as the lingua franca of
programming. We old gray heads remember, for example, when all
algorithms in CACM were written in Algol as a matter of course.
Then, of course, there was the previously mentioned Burrough 5500 in
which everything from the ground up was written in an Algol/60
dialect, helped tremendously by the 5500 having a typed "tagged"
architecture. The HP3000 "assembler" system programming language was
also advertised originally as being "Algol-like" or as an "algol
dialect". TONS of software was written for those.
Then they tried to come up the the Ultimate Language, which became
Algol/68. In reaction to that (in part) Wirth came up with Pascal,
which was Algol-like to a great degree. '68 turned out to be almost
impossible to implement, and that part of the market was picked up by
Pascal and Pascal variants. (Also remember that C was originally
spoken of as an Algol-like language.)
Alexander Anderson
>As C.A.R Hoare said, Algol was a great improvement on most of its successors.
>
>It was actually Dijkstra who coined that phrase.
Peter, I'm shocked. It couldn't possibly have been Dijkstra because
no one can pronounce his name properly without having to cut off their
ear first. And it wasn't Dick van Dyke.
No, quid pro quo, it was in fact Kurt Gödel.
"Gödel" is pronounced "girdle". Don't ask.
Hope this helps in advance,
Sandy
Peter van der Linden
>
>> !!! As C.A.R Hoare said, Algol was a great improvement on most of its successors.
>
Thanks for the correction. My failing memory misattributed it, and Ian
got it right in the first place.
Alexander Anderson
>Thanks for the correction. My failing memory misattributed it, and Ian
>got it right in the first place.
Have you tried changing the DIMMS?
Associatively,
Lueko Willms
schrieb ijo...@mpce.mq.edu.au (Ian Joyner)
auf /COMP/LANG/JAVA/PROGRAMMER
in 366F4AC1...@mpce.mq.edu.au
ueber Re: Advanced C++ Programmer can't tolerate JAVA.
IJ> C did not prove that OSs could be written in HLLs: that belonged already
IJ> to ALGOL on the B5000 (~1964), and this OS survives today as still
IJ> much better, fully featured
IJ> and robust than Unix and any other OS for that matter.
My first teacher of A-Series (BLS) software explained that a machine
can be programmed the most efficiently in the programming language that
machine was constructed for.
BLS _are_ constructed for ALGOL (or NEWP, for that matter).
Yours,
Lüko Willms
/------------ L.WI...@LINK-F.rhein-main.de -- Will...@compuserve.com
/------------ Lueko....@T-Online.de -- "Get PGP Key" im Betreff
"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
Graham Perkins
> COPIED FROM http://www.cm.cf.ac.uk/CLE//volume97/18338
> Subject: Avoiding the second historic mistake
> ...
> The contributions are clear enough. Java is good as
> a language to write applets, and (through its virtual
> machine) as a portable vehicle for executing programs written
> in various languages.
Oh yes, you mean the WORA feature?
(Write Often, Rewrite Again)
> Its dynamic aspects are also interesting
> for many applications.
any better than Smalltalk? Can you really get good dynamic
handling within context of static typing? Both end up
being compromised.
(they could be mixed, but the static typing would have
to involve a contract that could be verified at runtime,
rather than simply an interface declaration).
> - Violations of information hiding, hampering
this is unbelievable. how language designers have
let this thru time and again (object pascal, C++,
java, ...) is just incredible.
> As one .sig found on the net (I believe from Roland Turner)
> states: "Java: the elegant simplicity of C++ and the blazing
> speed of Smalltalk".
and even that is generous. see another thread on
"language speed". Direct comparison of Line-of-code speed
is often meaningless.
Perhaps Roland should have added
"... and the portability of ASM86"
> It is interesting to compare this with Eiffel:
or any other mature technology. In particular, the handling
of a global product release, through several versions, and
with mixture of proprietory and open components.
----------------------------------------------------------------
Graham Perkins, De Montfort University, Milton Keynes
http://www.mk.dmu.ac.uk/~gperkins/
Ian Joyner
> Peter, I'm shocked. It couldn't possibly have been Dijkstra because
> no one can pronounce his name properly without having to cut off their
> ear first. And it wasn't Dick van Dyke.
I've heard it pronounce several ways, but don't know which is right. Actually all
Unisys people should be able to pronounce it, as Dijkstra was a Burroughs fellow
for some time. I also like (or don't like more to the point) the story of how he
first saw the B5000 in the mid 60s, and was so impressed at the performance of the
ALGOL compiler (proving ALGOL was a practical language) that he ordered three for
his University in Europe. However, the then CEO, Ray McDonald, cancelled the sale
as he did not want to set up a support centre in Europe just for some University.
(From Richard Waychoff's Stories of the B5000).
Some other notable unpronouncables are of course Niklaus Wirth, who had an
interesting story on how to pronounce his name: worth, veert, etc.
How about Bjarne Stroustrup:
http://www.research.att.com/~bs/bs_faq.html#pronounce
The bit with the potato hurts!.
And even Bertrand Meyer (http://www.eiffel.com), where the Bertrand came under
question at a TOOLS conference in Australia, and some smart person said "well in
Australia, we'd just pronounce it Bruce, mate!"
Ian Joyner
Stefano Gaburri wrote:
Before I have misattributions, it was Alexander who wrote the above in
response to my posting. I don't understand his over the top (and perhaps
rather rude) reaction.
Ian Joyner <ijo...@mpce.mq.edu.au> wrote:
>Could you put today's most intelligent human
>beings in the caveman era, and expect them to recreate today's society
just on
>their intelligence? No, they need the tools.
Perhaps his rather strong reaction was: would you really want to recreate
today's society? Perhaps not, I really didn't want to get into that debate.
That does not undermine my point of the fact that we need tools, they
improve our powers, and programming languages are such tools. Language
itself is a tool, a tool of personal communication.
Newsgroups are also a good tool to share ideas and debate topics. However,
they quickly lose that usefulness if people become abusive.
Jocelyn Coulmance
Nat Pryce a écrit dans le message <36700901...@doc.ic.ac.uk>...
>[...]
>Because of the large selection of reasonably well designed
>APIs.
How can you have well designed API if the language does not permit to write
some ? (no genericity, no contracts, no multiple-inheritance...)
Regards
Jocelyn
Steven Perryman
>In article <74p2qq$o5$1...@ucsnew1.ncl.ac.uk>, R. Kerr <R.K...@ncl.ac.uk> wrote:
>[snippage]
>>> modern language designers?
>>ALGOL spawned SIMULA and SIMULA spawned OO, so what's the lesson?
Please please Sir, let me be the 3rd Brit to say amen to Simula. :-)
Certainly Algol's block structuring was a big plus. It enabled the Simula
team to have a consistent paradigm for on-paper different concepts like
inheritance and nested classes.
>Ummmm... (guessing wildly) Operating Systems should be written in
>Simula? Better yet than Algol, and also a great improvement on
>most of its successors...<sigh>
Well, all the Simula system IO was encapsulated in classes, so it had already
made the fundamental step in that direction.
Regards,
Steven Perryman
ste...@nortel.co.uk
Mats Olsson
"Well-designed" is in the eye of the beholder.
Many people used to the Windows/MFC abomination find the Java API's
well-designed.
And no, well-designed API doesn't need multiple-inheritance,genericity
and contracts - contracts and genericity just makes it easier to write
well-designed API's. Now, multiple-inheritance ...
/Mats
Gerry Quinn
=>
=>>This was not the right decision. Not that everything was bad
=>>with C++ (then it would not have attracted so many
=>>people); it was simply not appropriate for serious software
=>>engineering. C++ was a transition technology, useful to make C
=>>developers and their managers object-aware, but not appropriate
=>>for the development of durable, high-quality software systems.
=>>Interestingly enough, this was clear to many people; virtually
=>>every object-oriented expert would privately concede that C++
=>>was an inadequate solution - but carefully refrain from saying
=>>so in public, for fear of appearing to go against the tide.
=>
I don't know who posted ther above, but if desktop PC applications are
considered serious software engineering, I do not know of any viable
alternative to C/C++.
- Gerry
http://bindweed.com
----------------------------------------------------------
ger...@indigo.ie (Gerry Quinn)
----------------------------------------------------------
Tim Ottinger
>
> That kinds sounds like the MS Windows Operating systems - Design Flaws.
>
> Yet where is the outcry?? :~(
Far be it from me to defend microsoft, but...
A large part of microsoft's market is people playing
games, running Quicken or Word or Excel, and then very
occasionally trying to run a moderately unimportant
app of some sort, perhaps a reporting app that can be
rerun if it crashes. They have 32, 48, or 64MB machines
running over 200MHz. Their machines are incredibly bored.
So the analogy would be to consider that you had a toaster,
and every once in a while you had to push the button
down twice, but it never hurt anything or caught fire
or burned the toast. It just had a minor glitch. That's
pretty far away from the idea of airliners crashing with
all passengers and crew lost.
There is a reason why life-critical stuff seldom runs
on windows. Your airline flight control computers certainly
don't, though the programmers sometimes use windows
to create the apps.
If you consider microsoft to be the leading manufacturer
of software for *personal* (not professional or life-critical)
computers, you realize that the crashes are really annoyances
and time wasters.
You and I just happen to be in a situation where our
PCs are *professional* computers, and the waste of time
and the annoyance is far more expensive. If, as an
industry, we each were to lose $50/month to reboots
and annoyances, that would really add up to a lot of
lost time. But it's only $50/month to any one of us:
maybe not worth a lawsuit.
Even so, I don't have to reboot very often at all now.
I am not without Win problems and complaints, but I want
to make sure we aren't exaggerating the damage here.
--
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler
Tim Ottinger
>
> I agree completely, Matt. The key words in your above statement to me are
> "reliably" and "economically". Given super human effort one people can
> deliver almost anything - witness NASA's push to the moon.
Ouch. Those who are more into space history will argue that this is
the
one example disgustingly apropos. The US Air Force was working for
years on reusable launch vehicles that you would (eventually) fly into
space and fly back down under pilot control. They were doing some
really
good work with gliders, exospheric (is that the word?) steering, etc.
That's when it was decided to pull funding from the dynosoar program
(among others) and put all their efforts into a "quick and dirty"
method of reaching the moon: shooting people into space in a rocket.
The quick and dirty way took a lot of people and a lot of hours and
they did some amazing work considering. It worked, it made release
#1, and could be refined from there (cathedral and bazaar), but
a certain amount of elegance was abandoned and useful research was
cancelled or postponed.
Is that what you were wanting to show?
> What I mean is that it makes sense to develop tools that lessen the effort and
> increase the chance for success. C was a step in that direction, as are
> Smalltalk and, yes, Java - they make common programming tasks easier. C++, IMHO,
> is a giant question mark on this issue.
And smalltalk (as I understand it) and python (definitely)
are examples of making a tool easier to use than many
alternatives.
Ken Denny
>
> First there was ALGOL... this was a big step in the right direction, then CPL which
> was supposed to be practical ALGOL, was a slight step backwards. BCPL which was Basic
> CPL was another step backwards. Then came B, a big step backwards (it took the Basic
> and dropped the CPL), and C was a small step forwards over this. I think in all this
> C had by the time it came around lost the plot.
Although I've never used CPL, BCPL, or B, I agree with you concerning
ALGOL and C. I worked for Burroughs/Unisys from 1974 to 1994 and did a
lot with ALGOL. Now I no longer work with any Unisys equipment :'( and
work in C and C++. I have to say also that to me in many ways C++ is a
step backward from C.
> As C.A.R Hoare said, Algol was a great improvement on most of its successors.
I like that. So true.
Ken Denny
Half the people you know are below average.
Ignace Saenen
>
> Alexander Anderson wrote:
>
> > Peter, I'm shocked. It couldn't possibly have been Dijkstra because
> > no one can pronounce his name properly without having to cut off their
> > ear first. And it wasn't Dick van Dyke.
>
> I've heard it pronounce several ways, but don't know which is right. Actually all
It`s a dutch name and therefore only the dutch pronounciation is the
only right one. The i and j together form a consonant which sounds like
the e in 'egg' (only longer) and goes just slightly to a normal sounding
e (in english). The sound of a dutch i and an english e is just the
same, in dutch, the j provides some sort of ramp up the hz-ladder for
consonants, and you get a longer and rounder consonant. Of course we
also have another version of the very same consonant which is written
like 'ei' but I`m not going to try to explain that one :)
> Some other notable unpronouncables are of course Niklaus Wirth, who had an
> interesting story on how to pronounce his name: worth, veert, etc.
That one`s German, so you `d get something like 'Vert'. Niklaus is like
Nikkihouse, but you change the 'kih' into 'kl' :)
> How about Bjarne Stroustrup:
I think he was finnish or norwegian. His first name is like Bjorn, only
a bit more sounding like an 'ah' in the middle, and with a short
sounding eh at the back. Stroustrup is pronounced like Strowsep (I think
:)).
> http://www.research.att.com/~bs/bs_faq.html#pronounce
>
> The bit with the potato hurts!.
>
> And even Bertrand Meyer (http://www.eiffel.com), where the Bertrand came under
> question at a TOOLS conference in Australia, and some smart person said "well in
> Australia, we'd just pronounce it Bruce, mate!"
Bertrand is of a french origin, and you all know your french, now don`t
you :)
Try this one:
Ignace Saenen
Tim Ottinger
> Many of the Win32 APIs are hideously over complicated, poorly
> specified, non-standard and bodged with backwards compatibility
> features that don't work in practice. And then when you put
> something like MFC on top of them...
>
> in productivity by switching to Java. It's a shame that
> better languages don't get the same level of hype.
Ah, then it wasn't so much the language as the windowing
API. Let us never, never forget that the ANSI C++ committee
has absolutely nothing to do with MFC. MFC is not a part
of C++. If it was, I'd abandon C++ rather quickly. It's a
third-party library.
So you find SWING/AWT better than MFC (no surprize), and
I'll bet you like the GC in Java, too? GC is mighty handy.
But is it the libraries or the language you like better?
Quinn Tyler Jackson
Regarding C++, it's hugeness, and it's place in serious software engineering....
IMO, if one is to engage in serious software engineering, one had better do it with all
the appropriate notations and tools available to get the job done as close to correctly as
possible. When one encounters problems that require scaled down (and incomplete)
solutions because of the (designed or incidental) limitations of the notations and tools
one has at his disposal, then it is time to consider a better notation or tool.
In both my private and commercial work, C++ has consistently provided the best
*all-around* tool for such work. Java was simply not up to the task. Nor were the
various dialects of BASIC. C++ has so far been the only notation that could be used to
properly express solutions to the problems in all of the domains for which I've required
an appropriate notation.
--
Quinn Tyler Jackson
email: qjac...@wave.home.com
url: http://www.qtj.net/~quinn/
ftp: qtj.net
"... it is wrong to say that a good language is important to thought, merely;
for it is the essence of it." -- Charles Sanders Peirce
Ron Natalie
>
> > Some other notable unpronouncables are of course Niklaus Wirth, who had an
> > interesting story on how to pronounce his name: worth, veert, etc.
>
> That one`s German, so you `d get something like 'Vert'. Niklaus is like
> Nikkihouse, but you change the 'kih' into 'kl' :)
There's an old story (don't know if it's true, but it sounds
plausible) that Wirth would say that you could call him by
name (VEERT) or by value (WORTH).
Johan Compagner
Alexander Anderson wrote in message ...
>>
>
>
>
>no one can pronounce his name properly without having to cut off their
>ear first. And it wasn't Dick van Dyke.
It is a dutch name (like Peter van der Linden) and i am dutch
so i CAN pronounce it Perfectly
it is pronounced as Deikstraaa
>
>
> No, quid pro quo, it was in fact Kurt Gödel.
>
>
> "Gödel" is pronounced "girdle". Don't ask.
>
>
>Hope this helps in advance,
>
>
>
>
Brett g Porter
worth".
After doing some work in Pascal and Modula-2, I never found cause to
disagree with that assessment.
<g>
--
//
// reply to:
// BgPorter at acm dot org
//
Ron Natalie wrote in message <36715215...@sensor.com>...
Mike Spille
>
> Mike Spille wrote:
> >
> > I agree completely, Matt. The key words in your above statement to me are
> > "reliably" and "economically". Given super human effort one people can
> > deliver almost anything - witness NASA's push to the moon.
>
> Ouch. Those who are more into space history will argue that this is
> the
> one example disgustingly apropos. The US Air Force was working for
> years on reusable launch vehicles that you would (eventually) fly into
> space and fly back down under pilot control. They were doing some
> really
> good work with gliders, exospheric (is that the word?) steering, etc.
> That's when it was decided to pull funding from the dynosoar program
> (among others) and put all their efforts into a "quick and dirty"
> method of reaching the moon: shooting people into space in a rocket.
>
> The quick and dirty way took a lot of people and a lot of hours and
> they did some amazing work considering. It worked, it made release
> #1, and could be refined from there (cathedral and bazaar), but
> a certain amount of elegance was abandoned and useful research was
> cancelled or postponed.
>
> Is that what you were wanting to show?
>
Yes, exactly. A single-minded, high-pressure drive to a single goal
succeeded due to massive work and massive support systems. Sucking
resources away from other projects is a natural result of such an
undertaking.
> > What I mean is that it makes sense to develop tools that lessen the effort and
> > increase the chance for success. C was a step in that direction, as are
> > Smalltalk and, yes, Java - they make common programming tasks easier. C++, IMHO,
> > is a giant question mark on this issue.
>
> And smalltalk (as I understand it) and python (definitely)
> are examples of making a tool easier to use than many
> alternatives.
>
Yep - and I would include Java as well. It is missing many features that
some would find desirable, but it's pretty consistent in its approach and
offers alot to the average implementor over something like C++.
> --
> --------- There is no craftite conspiracy -------------
> Tim Ottinger Object Mentor OO Training and
> otti...@oma.com www.oma.com Mentoring
> -------------------------------------------------------
> We can interpret a bad temper as a sign of inferiority.
> -- Alfred Adler
He he - I hadn't noticed this was cross-posted to comp.object until I saw a
mention of craftites :-)
-Mike
Martin Harvey
>
>
> First there was ALGOL... this was a big step in the right direction, then CPL which
> was supposed to be practical ALGOL, was a slight step backwards. BCPL which was Basic
> CPL was another step backwards. Then came B, a big step backwards (it took the Basic
> and dropped the CPL), and C was a small step forwards over this. I think in all this
> C had by the time it came around lost the plot.
Since I was lucky enough to have my university "compiler construction"
course given by Martin Richards, the designer of BCPL, I can perhaps
clarify this a bit.
CPL was to be a better program than ALGOL, and BCPL was a simple
typeless language that was simply meant to be used to write the compiler
for it. Unfortunately, CPL never really got anywhere (too complex?) and
BCPL caught on because it was easy to write compilers for it.
> The plot that it really found, which was more by accident than intention was cross
> platform development, but that would have been in ALGOL anyway.
Yep. I've never understood C or C++ ... there have always been more
elegant solutions around...
> C did not prove that OSs could be written in HLLs: that belonged already to ALGOL on
> the B5000 (~1964), and this OS survives today as still much better, fully featured
> and robust than Unix and any other OS for that matter.
Yep.
> As C.A.R Hoare said, Algol was a great improvement on most of its successors.
> (comp.sys.unisys added for comments on B5000. Please remove comp.sys.unisys if
> replies do not specifically follow this thought).
> --
> Ian Joyner
> Microsoft Research Institute Macquarie University
> i.jo...@acm.org
> http://www.mri.mq.edu.au/people/ian.html
Huh... my old unversity is going to end up like that... First M$ spends
several million on the computing department, the next thing it'll be:
"Microsoft Cambridge Research Institute UK, formerly known as Cambridge
University".
MH.
--
Martin Harvey.
Totally rewritten web pages at:
http://www.harvey27.demon.co.uk/mch24/
--------------BEGIN GEEK CODE BLOCK--------------
Version: 3.12
GCS/CC d(+) s-:- a-- C+++$ UL@ P L@>++ E- W++
N+++ o-- K++ w+++$ O--- M-- V-- PS@ Y-- PGP-
t--- 5-- X-- R-- !tv b+ DI+ D+ G e++ h- r z++>---
---------------END GEEK CODE BLOCK---------------
Don Macpherson
speaking to an American audience).
Don Macpherson
Brett g Porter wrote in message ...
Frank Mitchell
>The more I look at Java, and use it and consider the things that it lacks:
>genericity, covariant redefinition, code multiple inheritance, anchored
types,
>the more I wonder why so many people are using it: the lack of these things
gets
>in the way all the time for serious software development.
[This may get me in trouble with my employers -- Sun -- but what the hell.]
1. As others have noted, Java includes features which come in extremely
handy, and which are new to many C/C++ programmers: GC, a huge volume of
"standard" libraries, etc.
2. Java's portable bytecode (modulo windowing and os quirks) makes it stand
out. Until dramatically useful languages compile well into Java bytecode,
or until another bytecode standard takes off like Java did, the Java
language and libraries will come along for the ride.
3. Also as others have noted, if you've never used genericity, multiple
implementation inheritance, and so forth -- or used off-putting
implementations of those ideas -- you won't miss them.
4. It's certainly not under-publicized, or under-supported. Sun backed it,
and until Microsoft tried to play spoiler and HP broke ranks it had at least
lip service from all the major players.
5. Tools matter, but they don't make or break most efforts. Java might be
inconvenient in many ways, but thoughtful design and execution -- and
business savvy, for commercial efforts -- can make up for an implementation
language's deficiencies.
In short, Java is a "good enough" technology for a lot of needs: a really
cool notion (portable bytecode) implemented reasonably well, and enough
other stuff (builtin GC, libraries, interfaces and inner classes to take the
sting out of single inheritance) to make it a reasonable, if not stellar,
choice.
Perhaps if ISE had a bigger budget, made its compiler and even the core
Melting Ice technology free, and threw more resources into flashy demos,
Eiffel might have taken off the way Java has. But the sad truth is that
salesmanship and "brand" wins over technical merit, as long as the better
sold commodity is "good enough".
Frank
(Java programmer and wannabe Eiffelist)
Alexander Anderson
>It`s a dutch name and therefore only the dutch pronounciation is the
>only right one. The i and j together form a consonant which sounds like
>the e in 'egg' (only longer) and goes just slightly to a normal sounding
>e (in english). The sound of a dutch i and an english e is just the
>same, in dutch, the j provides some sort of ramp up the hz-ladder for
>consonants, and you get a longer and rounder consonant. Of course we
>also have another version of the very same consonant which is written
>like 'ei' but I`m not going to try to explain that one :)
>
>> Some other notable unpronouncables are of course Niklaus Wirth, who had an
>> interesting story on how to pronounce his name: worth, veert, etc.
>
>That one`s German, so you `d get something like 'Vert'. Niklaus is like
>Nikkihouse, but you change the 'kih' into 'kl' :)
>
>> How about Bjarne Stroustrup:
>
>I think he was finnish or norwegian. His first name is like Bjorn, only
>a bit more sounding like an 'ah' in the middle, and with a short
>sounding eh at the back. Stroustrup is pronounced like Strowsep (I think
>:)).
>
>> http://www.research.att.com/~bs/bs_faq.html#pronounce
>>
>> The bit with the potato hurts!.
>>
>> And even Bertrand Meyer (http://www.eiffel.com), where the Bertrand came under
>> question at a TOOLS conference in Australia, and some smart person said "well
>in
>> Australia, we'd just pronounce it Bruce, mate!"
I'm cheating. I was told how to pronounce Dijkstra, Aad van
Wijngaarten and Ruud Gullit, by Rem Koolhaas' (the maverick Dutch
architect based in Hampstead, London, England) wife. Do not ask. Also,
I do not ever want to pronounce Bjarne Stroustrup's name correctly, and
freely admit to enjoying making him sound like the title of an Ingmar
Bergman film (like paint drying in other words).
Thanks very much for the tips on Niklaus Wirth.
Mercifully, Meyer can be pronounced many ways, being a vaguely East
European Jewish name. Golda Meyer, and MGM's Louis B. Mayer. And what
of the dutch painter Jan Vermeer (1632-1675)?
Of course, if you really want to blast the Maths and Computer
Science department of your college clean out of the water, then the next
time you hear the phrase "reverse Polish notation", reply
"Oh, you mean _Jan_Lukasiewicz_ notation? Yes, yes, go on..."
"Lukasiewicz" sounds like wook-a-shey-vitch.
Dot java,
Ben Z. Tels
>only right one. The i and j together form a consonant which sounds like
>the e in 'egg' (only longer) and goes just slightly to a normal sounding
>e (in english).
Doesn't sound like that at all.
My advice to native English speakers on this list: give it up. There's
nothing in English like the "ij".
>That one`s German, so you `d get something like 'Vert'. Niklaus is like
>Nikkihouse, but you change the 'kih' into 'kl' :)
Always thought he was (IS actually) Swiss.
>I think he was finnish or norwegian. His first name is like Bjorn, only
>a bit more sounding like an 'ah' in the middle, and with a short
>sounding eh at the back. Stroustrup is pronounced like Strowsep (I think
>:)).
Always thought it was more like "stroostruhp".
Bjarne Stroustrup is (like Wirth) an "is" and not a "was". He is Danish.
Ben Z. Tels
opti...@stack.nl
http://www.stack.nl/~optimusb/
UIN:2474460
"The Earth is the cradle of the mind, but one cannot stay in the cradle
forever."
--Tsiolkovsky
T Jurik
I didn't use the word "tool" - rather I used "language." Tools are a
different story. My point was that the language is rarely the issue when I
see project successes and failures. The problems tend to lie in the areas
of organizational problems, human interactions, project mis-management, lack
of knowledge/training, imprecise or incorrect requirements and bad designs
and architectures. (the list goes on and on)
In these cases the choice of implementation language would not significantly
help or hurt the development efforts. Certainly if all other things are
equal than we focus on the language, but that will only solve (in my
experience) a negligible amount of the problems that face software
development.
Correcting the problems that will result in the most improvement was my
point. When the language/technology becomes the largest issue, then of
course we solve it.
Tim
Ian Joyner wrote in message <366F47B8...@mpce.mq.edu.au>...
>> Yes, it is nice to have languages that reduce possibilities of memory
>> errors, are fast, etc., but the bottom line is that non-trivial systems
>> require intelligent people, robust requirements, significant architecture
>> and design and some coding.
>
>Having decent tools is not just a nicety. The whole progress of the human
race
>has been to have better tools. Could you put today's most intelligent human
>beings in the caveman era, and expect them to recreate today's society just
on
>their intelligence? No, they need the tools.
>
>On the subsequent point... the point of Meyer's work is a programming
language
>that just does not do coding alone, but includes elements of requirements
>analysis, architecture and design: the expression of these is all done in
>language, so wouldn't it be nice if these languages dovetailed into
>implementation languages.
>
>Given all that... I strongly agree that you can't put advanced tools in the
>hands of idiots and expect good systems to be built; you need good people
and
>expertise. But this does not prove that better tools are just a nicety.
>
>> "I don't understand why anybody would be
>> programming in anything other than Java"
>>
>> Scott McNealy, Open Finance (a Sun publication),
>> Spring 1997.
>
>The more I look at Java, and use it and consider the things that it lacks:
>genericity, covariant redefinition, code multiple inheritance, anchored
types,
>the more I wonder why so many people are using it: the lack of these things
gets
>in the way all the time for serious software development.
Jeff W Morris
Pascal or something similar? Even an 80% translate will help a lot.
(Apologies for changing the subject slightly)
Jeff Morris
Martin Harvey <mar...@aziraphale.demon.co.uk> wrote in article
<36706174...@aziraphale.demon.co.uk>...
> Ian Joyner wrote:
> >
> >
> > First there was ALGOL... snip snip.....
Robert Claeson
>> How about Bjarne Stroustrup:
>
>I think he was finnish or norwegian. His first name is like Bjorn, only
>a bit more sounding like an 'ah' in the middle, and with a short
>sounding eh at the back. Stroustrup is pronounced like Strowsep (I think
>:)).
He was Danish, actually. I'm not going to elaborate on the pronounciation,
though. ;-)
/Robert
Robert Claeson
> My first teacher of A-Series (BLS) software explained that a machine
>can be programmed the most efficiently in the programming language that
>machine was constructed for.
There's an old Ericsson computer that was constructed to run Cobol. The only
language that existed for it was Cobol. There was an assembler for it
as well, of course, but it was only available to a few people within Ericsson
and never reached any customers. And naturally, the assembly language very
much resembled Cobol. Many common Cobol constructs were implemented as single
assembly language instructions.
/Robert
Lueko Willms
schrieb opti...@stack.nl (Ben Z. Tels)
auf /COMP/LANG/JAVA/PROGRAMMER
in 74sh57$rpe$2...@news.IAEhv.nl
ueber Re: Advanced C++ Programmer can't tolerate JAVA.
On Nikolaus Wirth:
BZT> >That one`s German, so you `d get something like 'Vert'. Niklaus is like
BZT> >Nikkihouse, but you change the 'kih' into 'kl' :)
BZT>
BZT>
BZT> Always thought he was (IS actually) Swiss.
Swiss traditionally have one of four native languages: German, French,
Italian, Runantch. German is the majority. The Swiss German also speak
"Schweizerdeutsch" (Swiss German), a dialect of the German language on the
verge of becoming a language by itself.
MfG,
Lüko Willms
/------------ L.WI...@LINK-F.rhein-main.de -- Will...@compuserve.com
/------------ Lueko....@T-Online.de -- "Get PGP Key" im Betreff
"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
Ian Joyner
Ken Denny wrote:
>
> Ian Joyner wrote:
>
> > As C.A.R Hoare said, Algol was a great improvement on most of its successors.
>
> I like that. So true.
Unfortunately, the sad part about it is that Unisys management has never
appreciated the gems that it has in its technical heritage, that most
things on A Series are still way ahead of the times. Their attitude is
that "mainframes" like A Series (although the attribution of "mainframe"
to A Series is just wrong) are old hat and being overtaken by "modern"
technologies such as C, Unix and NT... ugh!
Worse still, the quality managers who think that technology will only
ever be good if it is constructed according to processes such as ISO
9000, SEI CMM, etc. On that point, as far as I've seen A Series
development has the best development processes I've seen anywhere, but
not according to the ignorant quality managers who see software
developers as a bunch of cowboys, and who again don't appreciate the gem
they've got but have to go about undoing it.
--
Ian Joyner
i.jo...@acm.org
http://homepages.tig.com.au/~ijoyner/
Ell
>Worse still, the quality managers who think that technology will only
>ever be good if it is constructed according to processes such as ISO
>9000, SEI CMM, etc.
In general they are right. The point is to creatively tailor and
apply methodology. Why would anyone have a problem with that? Many
developers have found that creative tailoring of 9000 and CMM
generally leads to greater success than not.
>On that point, as far as I've seen A Series
>development has the best development processes I've seen anywhere, but
>not according to the ignorant quality managers who see software
>developers as a bunch of cowboys, and who again don't appreciate the gem
>they've got but have to go about undoing it.
Again, the industry in general has found greater success creatively
tailoring methodology rather than not.
Next, many managers are software developers, and they definitely know
that not all developers are cowboys. However some are and their ideas
and influence should be opposed because it typically leads to greater
project failure. And that is why I oppose the anti-methodolgy
sentiments quoted above.
Elliott
--
The Craftite conspiracy is:
a) their holding life terms as c.o.m. moderators
b) their oligarchic selection of new c.o.m. moderators
c) their not banning "one ups-manship" as a c.o.m. practice
d) their use of moderator comments in c.o.m.
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
Study Phony Craftite OO vs. Genuine OO: http://www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied w/out
permission only in the alt.comp.*, comp.* usenet and bitnet groups.
Ralph M. Prescott
> Before I have misattributions, it was Alexander who wrote the above in
> response to my posting. I don't understand his over the top (and perhaps
> rather rude) reaction.
>
> Ian Joyner <ijo...@mpce.mq.edu.au> wrote:
>
> >Could you put today's most intelligent human
> >beings in the caveman era, and expect them to recreate today's society
> just on
> >their intelligence? No, they need the tools.
>
> Perhaps his rather strong reaction was: would you really want to recreate
> today's society? Perhaps not, I really didn't want to get into that debate.
> That does not undermine my point of the fact that we need tools, they
> improve our powers, and programming languages are such tools. Language
> itself is a tool, a tool of personal communication.
>
> Newsgroups are also a good tool to share ideas and debate topics. However,
> they quickly lose that usefulness if people become abusive.
>
> --
> Ian Joyner
> Microsoft Research Institute Macquarie University
> i.jo...@acm.org
> http://www.mri.mq.edu.au/people/ian.html
The use of a tool involves knowledge.
The correct application of a tool involves wisdom.
A timely modern fable is the latest StarTrek movie.
It contrasts a wise people who reject knowledge
against a knowledgeable people who reject wisdom.
With the Federation (as usual) straddling the fence.
<slip> ouch!
As a recent poster so wonderfully stated:
Which is correct?
<kosh> Yes... </kosh>
~rmp
P.S. are there any MORE groups we should cross post to?
I wondered what Bertrand Meyer was doing reading the earlier drivel
until I checked the headers. >:-/
--
Ralph M. Prescott Systems Consultant
r...@rochester.rr.com LPA Software Inc
r...@lpa.com Fairport NY, USA
Michael J. Tobler
> Ian Joyner wrote:
[snip]
> P.S. are there any MORE groups we should cross post to?
> I wondered what Bertrand Meyer was doing reading the earlier drivel
> until I checked the headers. >:-/
Well, Netiquette says not to post to more than eight NG's, so we are still
within our limit :) Is there an active "Actor" newsgroup >:)
>
> --
> Ralph M. Prescott Systems Consultant
> r...@rochester.rr.com LPA Software Inc
> r...@lpa.com Fairport NY, USA
>
>
--
<<<<<<<<<< Blue Skies >>>>>>>>>>>
< Michael J. Tobler >
< mto...@no-spam-ibm.net >
< remove "no-spam-" when replying >
<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>
Michael J. Tobler
says...
[snip]
> Next, many managers are software developers, and they definitely know
> that not all developers are cowboys. However some are and their ideas
> and influence should be opposed because it typically leads to greater
> project failure. And that is why I oppose the anti-methodolgy
> sentiments quoted above.
Two things to expand on here:
1) Some (many?) managers are not coders (never have been). This brings
some difficulty to bear for developers.
2) Some managers are ex-cowboy-coders. This brings some difficulty to bear
for developers who are NOT cowboy coders. I can hear those managers:
"What's with all the A&D? Let's dive into coding !!!!!"
Alexander Anderson
>Worse still, the quality managers who think that technology will only
>ever be good if it is constructed according to processes such as ISO
>9000, SEI CMM, etc. On that point, as far as I've seen A Series
>development has the best development processes I've seen anywhere, but
>not according to the ignorant quality managers who see software
>developers as a bunch of cowboys, and who again don't appreciate the gem
>they've got but have to go about undoing it.
Ian, yes, it is _absurd_ (I type this whilst nibbling on a thickly
spread Bath-Oliver cracker of room temperature Lanark Blue five-
dimensional cheese) that in the face of all these E numbers (a European
system of classifying horrible ingredients listed towards the end of the
contents list on edible products in the supermarkets) that I can arrive
at the unshakeable conclusion -- at the end of the 20th Century -- that
GNU's[*] Linux is simply _the_rock_solid_best_ implementation of UNIX
extant.
Better than say, Solaris 7.
It is surely _absurd_, is it not?
With Kind Regards,
Sandy
[*] G.N.U. is an acronym meaning "GNU's Not Unix". Don't ask!
P.S. My NT4 system that I forked out a total of £500 quid for to give
me enough system reliability to get me through my E-numbered
college, now, after installing the 50MB virus called Internet
Explorer 4.01, crashes at least once a day.
P.P.S. I write this from comp.lang.java.help
Donald Gregory
>
> Ian Joyner <ijo...@pop.tig.com.au> wrote:
>
> >Worse still, the quality managers who think that technology will only
> >ever be good if it is constructed according to processes such as ISO
> >9000, SEI CMM, etc. On that point, as far as I've seen A Series
> >development has the best development processes I've seen anywhere, but
> >not according to the ignorant quality managers who see software
> >developers as a bunch of cowboys, and who again don't appreciate the gem
> >they've got but have to go about undoing it.
>
>
> GNU's[*] Linux is simply _the_rock_solid_best_ implementation of UNIX
> extant.
>
> Better than say, Solaris 7.
>
> It is surely _absurd_, is it not?
Yet it demonstrates what we've known all along: that all of this
methodology crap exists simply for the purpose of trying to explain
to managers (who haven't a clue what we do) what we are doing!
By the time they understand (if ever), there's no time left in the
project plan to do any testing of the code.
Time to let the cowboys back in the saddle!
Don Gregory
--
--------------------------------------
Donald J. Gregory
Gregory Publishing Company
See our A-Series Documentation Library
at: www.gregpub.com
E-Mail: don...@gregpub.com
---------------------------------------
Jun Nolasco
from suing anyone that produced defective software, no matter how big or
small the problem?
Jun Nolasco
Brian A Stefanish wrote:
>
> That kinds sounds like the MS Windows Operating systems - Design Flaws.
>
> Yet where is the outcry?? :~(
>
> There should of been a class action suit against MS for faulty software.
>
> Nick Payne wrote in message <366ee...@newshost.pcug.org.au>...
> >What would be thought of a car or aeroplane where one out of every hundred
> >sold crashed and killed its occupants because of a design flaw? There would
> >be an outcry, the product would be forcibly removed from the market, and
> >litigation against the manufacturers would undoubtedly be successful. Yet
> >software manufacturers tout products of a similar or worse level of
> >reliability as "durable, high-quality software systems".
> >
> >T Jurik wrote in message <74l1en$aih$1...@news01.li.net>...
> >>"durable, high-quality software systems"
> >
> >
Ian Joyner
> Ian Joyner <ijo...@pop.tig.com.au> wrote:
>
> >Worse still, the quality managers who think that technology will only
> >ever be good if it is constructed according to processes such as ISO
> >9000, SEI CMM, etc.
>
> In general they are right. The point is to creatively tailor and
> apply methodology. Why would anyone have a problem with that? Many
> developers have found that creative tailoring of 9000 and CMM
> generally leads to greater success than not.
(Apologies, I knew I should have qualified the above a bit better, but did
not want to be too long winded.)
I agree; in the right hands they are useful, but in the wrong hands they are
lame ducks, but even worse can do much cultural damage in an organisation.
The interesting thing I have observed is that the worse people are those who
have the attitude that software people are "cowboys", only do things "by the
seat of their pants", etc, are usually the people that push such
methodologies to further their own career. After all "I established ISO
9000/SEI methodologies at x" should look good on the resume, right?
Unfortunately, this is exactly the attitude that will have the programmers up
in arms, and therefore will do a lot of damage.
> >On that point, as far as I've seen A Series
> >development has the best development processes I've seen anywhere, but
> >not according to the ignorant quality managers who see software
> >developers as a bunch of cowboys, and who again don't appreciate the gem
> >they've got but have to go about undoing it.
>
> Again, the industry in general has found greater success creatively
> tailoring methodology rather than not.
>
> Next, many managers are software developers, and they definitely know
> that not all developers are cowboys. However some are and their ideas
> and influence should be opposed because it typically leads to greater
> project failure. And that is why I oppose the anti-methodolgy
> sentiments quoted above.
The sentiments above were anti bogus quality managers, and others that have
the attitude that "coders are hackers", not anti-methodology as such. Note
that also the statement that ISO 9000 or SEI are not a necessary precondition
to create quality software is the truth, but also not necessarily anti those
methodologies either, just anti those who say "if you are not using <x> you
are not any good." The lesson for quality managers is to work with, not
against the software people.
It is also strange that some people say that programming languages are
unimportant to quality, but methodologies are important. Both programming
languages and methodologies are just tools, and they either will both
influence quality, or both not, but not one or the other. If a good
programming language is used as a tool, then it will be integrated with
whatever methodology, or will influence the overall methodology and design of
software.
Jan Jong
> Mercifully, Meyer can be pronounced many ways, being a vaguely
> East
> European Jewish name. Golda Meyer, and MGM's Louis B. Mayer. And
> what
> of the dutch painter Jan Vermeer (1632-1675)?
And, speaking of painters (dutch), what about van Gogh. That is
definitely NOT pronounced "ven gow" ;-). I won't even try to explain
the correct pronounciation of the letter 'g' in dutch. Not in writing
anyway...
Jan Jong
Alkmaar, Netherlands
Jocelyn Coulmance
Mats Olsson a écrit dans le message <74qv2d$api$1...@nyheter.chalmers.se>...
>In article <74qohv$5d5$1...@feed.teaser.fr>,
>Jocelyn Coulmance <j.cou...@itecor.com> wrote:
>>
>>Nat Pryce a écrit dans le message <36700901...@doc.ic.ac.uk>...
>>>[...]
>>>Because of the large selection of reasonably well designed
>>>APIs.
>>
>>How can you have well designed API if the language does not permit to
write
>>some ? (no genericity, no contracts, no multiple-inheritance...)
>
> "Well-designed" is in the eye of the beholder.
"Well-designed" can be estimated wrt the "state of the art".
>
> Many people used to the Windows/MFC abomination find the Java API's
>well-designed.
In French we have a proverb that approximately says "in the realm of the
blind, the one-eyed is the king".
>
> And no, well-designed API doesn't need multiple-inheritance,genericity
>and contracts - contracts and genericity just makes it easier to write
>well-designed API's.
One of my criteria for "well-designed" API is that it allows one to write
sound applications.
- Missing genericity, Java APIs force every application code to (ab-)use
downcasting, especially, when one uses container classes. In other words,
every time you have a 1-n relationship in your model, you introduce a hole
in the type system. This means that your design is made fragile because when
you change something, your tools cannot help you to determine if the change
is consistent with the existing design or not.
- The lack of contracts induces the risk that the semantics of the design
can be misunderstood. See for example
http://www.eiffel.com/eiffel/projects/hp/creel.html to understand how
critical this point is.
It is true that genericity and contracts are not the only ways to cope with
these well-known problems. But at least they bring a part of the answer.
More than "ease of writing", they are crucial tools that help deal with
complex software. IMO Java's lack of solution in this domain makes it
unsuitable for the writing of "well-designed" APIs.
> Now, multiple-inheritance ...
It is only single-inheritance used several times... And it sometimes helps
avoid contorsions (and thus unnecessary complexity), or worse,
copy-and-paste of code.
Regards
Jocelyn
Alexander Anderson
>And, speaking of painters (dutch), what about van Gogh. That is
>definitely NOT pronounced "ven gow" ;-). I won't even try to explain
>the correct pronounciation of the letter 'g' in dutch. Not in writing
>anyway...
van "Hkhk-O-gkh" ?
I think van Gogh (it's difficult not to spit now) is related to the
fractal nature of the ex-mayor of New York, Ed Koch (now a major trash-
TV host) who proved that the length of the perimeter of any dollar bill
is infinite.
Ed Koch was elected mayor of New York because he weren't afraid of
no ghost and was good at plumbing.
Ed Koch is the inventor of Sierpinski's Gasket.
Hope this helps,
Sandy
Stephan Eggermont
> Alexander Anderson wrote:
>> Mercifully, Meyer can be pronounced many ways, being a vaguely
>> East
>> European Jewish name. Golda Meyer, and MGM's Louis B. Mayer. And
>> what
>> of the dutch painter Jan Vermeer (1632-1675)?
> And, speaking of painters (dutch), what about van Gogh. That is
> definitely NOT pronounced "ven gow" ;-). I won't even try to explain
> the correct pronounciation of the letter 'g' in dutch. Not in writing
> anyway...
That wouldn't be helpful in pronouncing it correctly, too.
He was born in Brabant, and we don't pronounce the 'g' like the
people from above the rivers!
Stephan Eggermont
Gerhard Menzl
> The sentiments above were anti bogus quality managers, and others that have the
> attitude that "coders are hackers", not anti-methodology as such. Note that
> also the statement that ISO 9000 or SEI are not a necessary precondition to
> create quality software is the truth, but also not necessarily anti those
> methodologies either, just anti those who say "if you are not using <x> you are
> not any good." The lesson for quality managers is to work with, not against the
> software people.
Exactly. After I had left the worst hacker shop I have ever had the misfortune to
work for, I learned that they got ISO-9000 certified. They bailed out of it soon,
though, because of the quality pretending effort they would have had to undergo
once a year. To me, this means that an ISO-9000 stamp conveys no information
whatsoever, except that the company involved has filled out a lot of forms.
Quality is in people's minds, not in certificates.
Gerhard Menzl
Gerhard Menzl
I'm going to comment only on the misunderstandings with respect to my own native
language, so:
> That one`s German, so you `d get something like 'Vert'. Niklaus is like
> Nikkihouse, but you change the 'kih' into 'kl' :)
Wirth, as has been pointed out, is Swiss, but the name is definitely German.
It is pronounced (in pseudo-english spelling) Nick-louse Veart, with a short "ear"
sound as in, well, "ear". Veert is somehow misleading because it seems to suggest a
long vowel.
Gerhard Menzl
Jocelyn Coulmance
Thomas a écrit dans le message ...
>In article <74qohv$5d5$1...@feed.teaser.fr> "Jocelyn Coulmance"
<j.cou...@itecor.com> writes:
>
>> >Because of the large selection of reasonably well designed
>> >APIs.
>>
>> How can you have well designed API if the language does not permit to
write
>> some ? (no genericity, no contracts, no multiple-inheritance...)
>
>happy.
Sure. But above all I try to program robust systems, not just applets.
> But Java supports different constructs and programming
>paradigms, and they aren't necessarily worse. I find use of nested
>classes and anonymous nested classes actually leads to better designs
>than MI.
IMO, nested classes are a ad-hoc solution to a problem that was created by
lack of MI. With a well tought-out MI mechanism you can have exactly the
same things as with nested classes with extra benefits: only one, integrated
concept; i.e. inheritance. Compare this with Java: you have classes,
interfaces, inheritance between interfaces, inheritance between classes,
inheritance between interfaces and classes, nested classes with their
special visibility rules (are there special inheritance rules as well ?)
>
>Lack of genericity is a minor nuisance, not a major problem,
>and will likely be addressed.
It is a major nuisance when you want to guarantee the integrity of a system.
Lack of genericity introduces many holes in the type system. It only remains
two choices for you: build fragile designs or use defensive programming.
> Lack of contracts doesn't make
>the APIs worse, it simply limits the amount of enforcement the
>language can give you;
It is more than enforcement. It is a way of stating things, just like you
state the types of your routines and attributes. Contracts are the
specifications of your classes. Enforcement comes in addition, at test-time.
> furthermore, there are several add-on tools that can provide that
functionality if you want it.
Not a very satisfactory solution. You force the users of your APIs to use
your add-on tools. Why not have the contracts standardized in the language ?
Regards
Jocelyn
Rick Rutt
>Then they tried to come up the the Ultimate Language, which became
>Algol/68. In reaction to that (in part) Wirth came up with Pascal,
>which was Algol-like to a great degree. '68 turned out to be almost
>impossible to implement, and that part of the market was picked up by
>Pascal and Pascal variants. (Also remember that C was originally
>spoken of as an Algol-like language.)
Many of the new concepts introduced in Algol/68 found their way into Ada.
-- Rick
--
(Rick Rutt is a system architect living and working in metropolitan Detroit.)
Roedy Green
>Wirth, as has been pointed out, is Swiss, but the name is definitely
>German.
>It is pronounced (in pseudo-english spelling) Nick-louse Veart, with a
>short "ear"
>sound as in, well, "ear". Veert is somehow misleading because it seems to
>suggest a
>long vowel.
This is a joke someone fine tune about Professor Wirth's pronunciation --
call by name Nick-Louse Viert or call by value Nickle's Worth
Is there a picture of this man on the web anywhere?. I have mental images
I have built up over the years. One is a rotund fellow with a monk's bald
head and a fringe. The other is a sort of Peter O'toole British tweedy
thin chap.
For the JAVA GLOSSARY and the CMP Utilities: <http://mindprod.com>
--
Roedy Green, Canadian Mind Products
-30-
Matt Kennel
:It is also strange that some people say that programming languages are
:unimportant to quality, but methodologies are important. Both programming
:languages and methodologies are just tools, and they either will both
:influence quality, or both not, but not one or the other. If a good
:programming language is used as a tool, then it will be integrated with
:whatever methodology, or will influence the overall methodology and design of
:software.
I'll go further and make the claim that a central purpose of programming
langauges is to obsolete 'methodology' as much as possible.
How much 'methodology' do we need for documenting and enforcing rules for
register allocation any more?
:Ian Joyner
:Microsoft Research Institute Macquarie University
:i.jo...@acm.org
:http://www.mri.mq.edu.au/people/ian.html
--
* Matthew B. Kennel/Institute for Nonlinear Science, UCSD
*
* "do || !do; try: Command not found"
* /sbin/yoda --help
Marcel Weiher
>I'll go further and make the claim that a central purpose of programming
>langauges is to obsolete 'methodology' as much as possible.
>How much 'methodology' do we need for documenting and enforcing rules for
>register allocation any more?
Exactly!
Just like design patterns (at least the micro-architecture ones in
the GOF book): why do I have to document recurring designs? If they
really recur, I want to *factor* them out of my code!
Marcel
--
Java and C++ make you think that the new ideas are like the old ones.
Java is the most distressing thing to hit computing since MS-DOS.
- Alan Kay -
Donald McLean
mbkennel <replace this with '@'> yahoo.com wrote:
> On Mon, 14 Dec 1998 16:03:25 +1000, Ian Joyner <ijo...@mpce.mq.edu.au> wrote:
> :It is also strange that some people say that programming languages are
> :unimportant to quality, but methodologies are important. Both programming
> :languages and methodologies are just tools, and they either will both
> :influence quality, or both not, but not one or the other. If a good
> :programming language is used as a tool, then it will be integrated with
> :whatever methodology, or will influence the overall methodology and design of
> :software.
>
> I'll go further and make the claim that a central purpose of programming
> langauges is to obsolete 'methodology' as much as possible.
>
> How much 'methodology' do we need for documenting and enforcing rules for
> register allocation any more?
Matthew, I would argue that you are half correct.
Newer programming languages make writting small pieces of correct code
easier.
We still need methodolgy to help us decide which small pieces of code to
write and how to put them together to make bigger pieces of code.
--
Donald F. McLean
dmc...@stsci.edu
Space Telescope Science Institute, Baltimore, MD
Mike Spille
In other words, you advocate a (mostly) static type system. That's fine if this
fits your solution, but many of us in the "Java space" are building highly
dynamic systems, including downloading code on the fly and executing it. And
I'm not speaking about just applets, but distributed computing in general. In
such an environment high-runtime safety is more important than high static
safety.
That said, I can see how generics could add value to Java - there are times
when compile-time safety is best. Certainly it would be great to have
statically typesafe containers in Java. But there's alot more to good design
than compile time safety - ask any Java programmer who's implemented their own
class loader, or just about any Smalltalker :-)
Your fragile design is my flexible and dynamic application.
As a final note, anecdotally it's quite rare to see a Java implementation put
the wrong type into a container or try to pull the wrong type out. What some
have called fragile in theory works quite well in practice.
> > Lack of contracts doesn't make
> >the APIs worse, it simply limits the amount of enforcement the
> >language can give you;
>
> It is more than enforcement. It is a way of stating things, just like you
> state the types of your routines and attributes. Contracts are the
> specifications of your classes. Enforcement comes in addition, at test-time.
>
Contracts without enforcement are, IMHO, worthless - at that level they're
comments.
> > furthermore, there are several add-on tools that can provide that
> functionality if you want it.
>
> Not a very satisfactory solution. You force the users of your APIs to use
> your add-on tools. Why not have the contracts standardized in the language ?
>
> Regards
> Jocelyn
-Mike
Ralph M. Prescott
> (Matt Kennel) writes:
>
> >I'll go further and make the claim that a central purpose of programming
> langauges is to obsolete 'methodology' as much as possible.
>
> >How much 'methodology' do we need for documenting and enforcing rules for
> register allocation any more?
>
> Exactly!
>
> Just like design patterns (at least the micro-architecture ones in
> the GOF book): why do I have to document recurring designs? If they
> really recur, I want to *factor* them out of my code!
>
> Marcel
> --
>
Both of these posters have failed to realize the inherent nature
of the competitive process (or human nature) to continually attempt
to reach beyond our grasp. As tools become better, problems that
were previously economically unfeasable now become possible.
Not guaranteed, but possible.
Bottom line...it isn't EVER going to become simple.
Processes (when done RIGHT) allow the inherent chaotic nature of
this boundary layer to be kept under some semblance of control.
They should be used to optimize for the correct balance of:
time x cost x quality x features that you're shooting for.
As an earlier poster pointed out; they are often instituted for quite
different reasons :-(
> Java and C++ make you think that the new ideas are like the old ones.
> Java is the most distressing thing to hit computing since MS-DOS.
> - Alan Kay -
Why does this strike me so? For bad or for worse there are a heck of
a lot more DOS boxes than Dynabooks AND Altos combined.
I guess the best IS the enemy of the good.
~rmp
Michael J. Tobler
says...
[snip]
> Java's paradigms of programming and object model are very close to Eiffel, they just miss out on
> a lot: genericity, covariance, anchored types, assertions. I could almost say that Java is Eiffel
> in C like syntax, but missing these crucial elements.
I find it closer to Modula than anything else. (Think about it).
[snip]
Chris Kuan
>
> Gerhard Menzl asked, wrote, or quoted:
> >Wirth, as has been pointed out, is Swiss, but the name is definitely
> >German.
> >It is pronounced (in pseudo-english spelling) Nick-louse Veart, with a
> >short "ear"
> >sound as in, well, "ear". Veert is somehow misleading because it seems to
> >suggest a
> >long vowel.
Gerhard, to a native English speaker, "ear" IS the same sound as "eer"
:-)
"air" might be better?
> This is a joke someone fine tune about Professor Wirth's pronunciation --
> call by name Nick-Louse Viert or call by value Nickle's Worth
I believe that joke was made by Wirth himself.
--
Chris Kuan, BHP Information Technology
Concatenate for email: mr gazpacho @ hotmail . com
Phone : +61 2 4275 5555 Fax : +61 2 4275 5547
"A Design Pattern is something that got left out of the language"
- Richard O'Keefe
Zenin
>snip<
: IMO, nested classes are a ad-hoc solution to a problem that was created by
: lack of MI.
And a lack of structs, and a lack of closures/lamdas...
: With a well tought-out MI mechanism you can have exactly the same things
: as with nested classes with extra benefits: only one, integrated concept;
: i.e. inheritance.
While I agree leaving MI out was quite simply lame, neither OO or
"good design" either starts or ends with MI. It's just one more
tool. Closures are another role that nested classes try to fill in
for, but that MI couldn't address.
--
-Zenin (ze...@archive.rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
Ian Joyner
I was going to say... surely quality is in the product, but you made me think some
more!
Reminds me of the Yes Minister show where the public service had a fully running
hospital, with a complete administration, but no patients. Of course Sir Humphries
excuse was how even without patients, quality must be of the highest standards.
It also reminds me of Tom Peter's example of how you could gain ISO 9000
accreditation for producing concrete life jackets.
How about Scott Adams' advice on how to appear busy around the office without
actually doing anything?
Seems by quality measures, you can be very busy, and still not produce anything. You
can also be very financially successful and not produce anything really useful for
society. Financial success only proves you can make money.
However, you are probably right about quality being in people's minds. A lot of
people would prefer to buy a $60 jar of name brand skin cream rather than a $4
bottle, even though tests show the cheapy does the same.
How many thought IBM made better equipment than Burroughs (OK some of Burroughs
hardware was suspect, but the software quality still blows IBM out of the water).
How many kids today think Apple Mac's are yesterdays technology, even though they
still lead the way in quality desktop environments?
How many teenagers just have to have Reeboks, even though cheaper brands are better
or just as good, or how many just have to wear their caps backwards because they
think it looks cool, but looks stupid (ok, perhaps its the trying to look cool that
looks stupid!)
How many would prefer to drink some disgusting lolly water name brand cola, than a
healthy cup of brewed tea, or carefully fermented quality wine, just because its the
thing to do.
Closer to home, how many think Unix, Java or C++ is cool just because everyone else
is doing it, and that the likes of a high quality language like Eiffel are just the
domain of a few academic wierdos?
So I think there are enough precidents to show that quality is in the minds, even
though peoples perceptions are often wrong.
The point is that its not that we don't need measurements, it's that we need truthful
measurements, and not measurements used to prove what we are trying to prove.
--
Ian Joyner
i.jo...@acm.org
http://www.mri.mq.edu.au/people/ian.html
Ian Joyner
> In article <74qohv$5d5$1...@feed.teaser.fr> "Jocelyn Coulmance" <j.cou...@itecor.com> writes:
>
> > >Because of the large selection of reasonably well designed
> > >APIs.
> >
> > How can you have well designed API if the language does not permit to write
> > some ? (no genericity, no contracts, no multiple-inheritance...)
Thomas is just arguing black is white, or at best has a bad case of denial, at worst deliberate
misinformation.
> If you try to program in Java like you do in Eiffel, you won't be
> happy. But Java supports different constructs and programming
> paradigms, and they aren't necessarily worse.
Java's paradigms of programming and object model are very close to Eiffel, they just miss out on
a lot: genericity, covariance, anchored types, assertions. I could almost say that Java is Eiffel
in C like syntax, but missing these crucial elements.
> I find use of nested
> classes and anonymous nested classes actually leads to better designs
> than MI.
Nested classes are an extremely ugly way of getting code reuse.
> Lack of genericity is a minor nuisance, not a major problem,
You are disagreeing with the likes of Guy Steele who in the introduction to his OOPSLA 98 paper
on NextGen or genericity in Java noted that lack of genericity in Java was its most major
problem.
> and will likely be addressed.
But to be addressed properly means getting the JVM right, and this was the subject of Suad
Alagic's OOPSLA paper... an excellent read on genericity. I too thought genericity would be a
simple addition to Java, but I was wrong!
> Lack of contracts doesn't make
> the APIs worse, it simply limits the amount of enforcement the
> language can give you; furthermore, there are several add-on
> tools that can provide that functionality if you want it.
This really is just arguing black is white, and shows lack of understanding of what the contract
paradigm is about. It is to document an API so that you can write the calling code correctly. Yes
APIs without contracts are poorer... very much so. The fact that Eiffel can enforce the stated
contracts is a bonus.
--
Frank Mitchell
Ian Joyner wrote in message <3675E01A...@mpce.mq.edu.au>...
>Thomas wrote:
>> I find use of nested
>> classes and anonymous nested classes actually leads to better designs
>> than MI.
>
>Nested classes are an extremely ugly way of getting code reuse.
Nested classes have good and bad points compared to MI.
The good part is that, unlike MI, you can present different implementations
of the same interface to different clients, and unlike the classical Command
pattern you keep the Command code along with the thing being commanded.
The bad part is that, especially in the anonymous case, the code can be
really hard to read. Where I work, we have an unofficial rule that all
nested classes have only a few lines of code, and that the major work comes
from methods in the enclosing class. Also, you're forced to decide between
interfaces or classes (or interfaces with "default" implementations) early
on, sometimes before you know what the most common behavior will be.
So I agree some problems that cry out for mixins and other classic MI
solutions, which Java can only approximate with circumlocutions, common
design patterns, and syntactic sugar like inner classes. And another poster
pointed out that nested classes don't have the full power of FP closures,
either. But it is notable that one mechanism can get pretty close to two
other features.
>> Lack of genericity is a minor nuisance, not a major problem,
>
>You are disagreeing with the likes of Guy Steele who in the introduction to
his OOPSLA 98 paper
>on NextGen or genericity in Java noted that lack of genericity in Java was
its most major
>problem.
>
>> and will likely be addressed.
>
>But to be addressed properly means getting the JVM right, and this was the
subject of Suad
>Alagic's OOPSLA paper... an excellent read on genericity. I too thought
genericity would be a
>simple addition to Java, but I was wrong!
Pointers to this, please?
While not addressing genericity "properly", the Generic Java approach
(http://www.cs.bell-labs.com/~wadler/pizza/gj/ ) isn't fully type-safe, but
it seems a workable patch, and it has the advantage that it can be
retrofitted on existing code. Even Guy Steele thinks so.
>> Lack of contracts doesn't make
>> the APIs worse, it simply limits the amount of enforcement the
>> language can give you; furthermore, there are several add-on
>> tools that can provide that functionality if you want it.
>
>This really is just arguing black is white, and shows lack of understanding
of what the contract
>paradigm is about. It is to document an API so that you can write the
calling code correctly. Yes
>APIs without contracts are poorer... very much so. The fact that Eiffel can
enforce the stated
>contracts is a bonus.
If runtime enforcement isn't important, then the new JavaDoc can fit the
bill nicely, given a set of tags. However, I regard runtime enforcement as
a requirement of DbC ... otherwise, it's just more comments that drift out
of sync with the actual code.
Frank
Gerhard Menzl
> > Quality is in people's minds, not in certificates.
>
> I was going to say... surely quality is in the product, but you made me think some
> more!
[...]
> However, you are probably right about quality being in people's minds. A lot of people
> would prefer to buy a $60 jar of name brand skin cream rather than a $4 bottle, even
> though tests show the cheapy does the same.
You have a point here, but it's not the one I was trying to make. I should have said: you
won't get real quality in a product simply by acquiring a certificate; it requires a
desire for quality in the minds of the people taking part in its making.
This raises the question of what is real quality, of course. See "Zen and the Art of
Motor Cycle Maintenance" by Robert Pirsig for an elaborate treatise of the subject.
Gerhard Menzl
Gerhard Menzl
> Just like design patterns (at least the micro-architecture ones in
> the GOF book): why do I have to document recurring designs?
So that less experienced developers can learn about best practices.
> If they really recur, I want to *factor* them out of my code!
You are confusing design and code here. Design patterns are not about code
reuse. You cannot factor out a trick of the trade.
Gerhard Menzl
Gerhard Menzl
> Gerhard, to a native English speaker, "ear" IS the same sound as "eer" :-)
Sometimes. But does "bear" rhyme with "beer"? ;-)
To me, "ee" seems to suggest a long vowel, that's why I chose the alternative
representation. You can choose Veert or Veart or Viert, as long as you make it
short. The closest equivalent in English I can think of is the sound in "tier".
> "air" might be better?
"air" is a completely different sound.
I wonder when WAV attachments will become standard in newsgroups. <g>
Gerhard Menzl
Steven Perryman
>Thomas a écrit dans le message ...
>> But Java supports different constructs and programming
>>paradigms, and they aren't necessarily worse. I find use of nested
>>classes and anonymous nested classes actually leads to better designs
>>than MI.
>IMO, nested classes are a ad-hoc solution to a problem that was created by
>lack of MI.
IMHO you had better qualify that statement as 'lack of MI in Java' .
Nested classes are a useful mechanism indeed, allowing for some quite elegant
design solutions. And I'm glad the Simula creators had the vision to devise
it.
Regards,
Steven Perryman
ste...@nortel.co.uk
Jocelyn Coulmance
Steven Perryman a écrit dans le message
<75585j$k...@bmdhh222.europe.nortel.com>...
>IMHO you had better qualify that statement as 'lack of MI in Java' .
This was implicit :-)
Regards
Jocelyn
James Kanze
|> In article <3675E01A...@mpce.mq.edu.au>, ijo...@mpce.mq.edu.au
|> says...
|> [snip]
|> > Java's paradigms of programming and object model are very close to Eiffel, they
|> just miss out on
|> > a lot: genericity, covariance, anchored types, assertions. I could almost say
|> that Java is Eiffel
|> > in C like syntax, but missing these crucial elements.
|> I find it closer to Modula than anything else. (Think about it).
Modula without modules or separate compile?
--
James Kanze GABI Software, Sàrl
Conseils en informatique orienté objet --
-- Beratung in industrieller Datenverarbeitung
mailto: ka...@gabi-soft.fr mailto: James...@dresdner-bank.com
Juergen Zink
>
> On Mon, 14 Dec 1998 16:03:25 +1000, Ian Joyner <ijo...@mpce.mq.edu.au> wrote:
> :It is also strange that some people say that programming languages are
> :unimportant to quality, but methodologies are important. Both programming
> :languages and methodologies are just tools, and they either will both
> :influence quality, or both not, but not one or the other. If a good
> :programming language is used as a tool, then it will be integrated with
> :whatever methodology, or will influence the overall methodology and design of
> :software.
>
> langauges is to obsolete 'methodology' as much as possible.
>
Consider 'methodology' as a theory, not as a tool. You start a theory
and verify
the theory by falsification. By programming without theory you will
verify your
program by verification. It works for this and that.
Example: Division by zero; it will work nearly for all numbers. But
there still
exist one number (i.e. zero) that doesn't work. How do you find this
number?
Therefore everybody MUST have a 'methodology'/theory in mind to do
programming!
Cheers,
Jšrgen Zink
Olaf Appelt
Nope. Take the short i from grid and insert it betwenn W and rth. The th in
Wirth BTW is *not* a 'th' as in 'th'at. Forget the h.
Olaf
Colin Stock
Stephan Eggermont wrote:
It might be earier if we call everyone of importance or significance in
the computing industry "Gatesey". :)
--
========================================================================
Colin
Stock
colin...@gecm.com
Doh.
Jocelyn Coulmance
Mike Spille a écrit dans le message <36754113...@tisny.com>...
>In other words, you advocate a (mostly) static type system.
In fact, a general form of inheritance can include delegation. One of the
ways to do this is described on Joachim Durchholtz's page at
http://homepages.munich.netsurf.de/Joachim.Durchholz/eiffel-critique/replica
ted-inheritance.html
In section "Naming inheritance paths" is described a syntax for a "dynamic"
inheritance model.
Regards
Jocelyn
Jocelyn Coulmance
Zenin a écrit dans le message <91368527...@thrush.omix.com>...
>
> While I agree leaving MI out was quite simply lame, neither OO or
> "good design" either starts or ends with MI. It's just one more
> tool.
Would you say that an application full of goto's is well designed ? Loops
are tools that help design better. MI is another such tool.
> Closures are another role that nested classes try to fill in
> for, but that MI couldn't address.
Not quite exact with "named inheritance" (see my reply to Mike Spille).
Regards
Jocelyn
Marcel Weiher
[I wrote]
>> Just like design patterns (at least the micro-architecture ones in
>> really recur, I want to *factor* them out of my code!
[..]
>As tools become better, problems that
>were previously economically unfeasable now become possible.
>Not guaranteed, but possible.
That is a good analysis of why we will continue to struggle.
>Both of these posters have failed to realize the inherent nature
>of the competitive process (or human nature) to continually attempt
>to reach beyond our grasp.
Not at all, the point was that there is so much unecssary struggle
because of a silly focus on techniques that document our inability
to grasp instead of extending our ability to do so.
BTW, not a *single* Dynabook has been built yet, just like there
are a lot more smoke-belching diesel trucks than solar powered,
zero-emission, long-haul heavy-weight trucks.
Marcel
--
Marcel Weiher
>Marcel Weiher wrote:
>> Just like design patterns (at least the micro-architecture ones in
>> the GOF book): why do I have to document recurring designs?
>So that less experienced developers can learn about best practices.
>> If they really recur, I want to *factor* them out of my code!
>You are confusing design and code here. Design patterns are not about code
>reuse. You cannot factor out a trick of the trade.
One man's design is another man's code. Fact is, quite a few of the
design patterns in the GOF book *can* be turned into re-usable code.
Others currently cannot, but maybe that is a limitation of our current
languages and mindsets?
Welcome to the meta-level. :-)
Alex B.
> Thomas a écrit dans le message ...
> >In article <74qohv$5d5$1...@feed.teaser.fr> "Jocelyn Coulmance"
> <j.cou...@itecor.com> writes:
> >
> >> >Because of the large selection of reasonably well designed
> >> >APIs.
> >>
> >> How can you have well designed API if the language does not permit to
> write
> >> some ? (no genericity, no contracts, no multiple-inheritance...)
> >
> >If you try to program in Java like you do in Eiffel, you won't be
> >happy.
>
> Sure. But above all I try to program robust systems, not just applets.
>
> > But Java supports different constructs and programming
> >paradigms, and they aren't necessarily worse. I find use of nested
> >classes and anonymous nested classes actually leads to better designs
> >than MI.
>
>
> IMO, nested classes are a ad-hoc solution to a problem that was created by
> lack of MI. With a well tought-out MI mechanism you can have exactly the
> same things as with nested classes with extra benefits: only one, integrated
> concept; i.e. inheritance. Compare this with Java: you have classes,
> interfaces, inheritance between interfaces, inheritance between classes,
> inheritance between interfaces and classes, nested classes with their
> special visibility rules (are there special inheritance rules as well ?)
IMO, nested clases are a ad-hoc solution to a problem that was created
by lack of closures and artificial division between objects and
methods. Eiffel has no such solution.
> >
> >Lack of genericity is a minor nuisance, not a major problem,
> >and will likely be addressed.
>
> It is a major nuisance when you want to guarantee the integrity of a system.
> Lack of genericity introduces many holes in the type system. It only remains
> two choices for you: build fragile designs or use defensive programming.
This is Eiffel point of view. Smalltalk point of view: you don't need
static type system. Which one is right?
> > Lack of contracts doesn't make
> >the APIs worse, it simply limits the amount of enforcement the
> >language can give you;
>
> It is more than enforcement. It is a way of stating things, just like you
> state the types of your routines and attributes. Contracts are the
> specifications of your classes. Enforcement comes in addition, at test-time.
>
>
> > furthermore, there are several add-on tools that can provide that
> functionality if you want it.
>
> Not a very satisfactory solution. You force the users of your APIs to use
> your add-on tools. Why not have the contracts standardized in the language ?
Why not simply have the language which is powerful enough to express
contracts in meta-itself? Like Smalltalk or CLOS. It has been
demonstrated that you can implement Eiffel design-by-contract in some
400 lines of CLOS.
> Regards
> Jocelyn
>
>
--
E-mail transform : rot13, "y" -> "a"
Darin Johnson
> Nested classes are a useful mechanism indeed, allowing for some quite elegant
> design solutions. And I'm glad the Simula creators had the vision to devise
> it.
The whole argument about nested classes is silly. It's a simple
scoping change to a language that has advantages to many people. Why
argue against it? Just because there are other ways to do the same
thing is irrelevant, unless your goal is to make sure there is one and
only one way of doing anything.
--
Darin Johnson
Support your right to own gnus.
Robert C. Martin
Ell wrote in message <36737ee0...@news.erols.com>...
>Ian Joyner <ijo...@pop.tig.com.au> wrote:
>
>>Worse still, the quality managers who think that technology will only
>>ever be good if it is constructed according to processes such as ISO
>>9000, SEI CMM, etc.
>
>In general they are right. The point is to creatively tailor and
>apply methodology. Why would anyone have a problem with that? Many
>developers have found that creative tailoring of 9000 and CMM
>generally leads to greater success than not.
I agree that creative tailoring of a process is beneficial. Although I
think that the word "tailoring" should be taken to mean what it does in the
clothing industry -- "to cut" ;^).
The best process is the smallest process that you can afford.
As for CMM, I have yet to see any convincing research that correlates CMM
level with industrial success. This is not to say that the activities that
the SEI suggest are incorrect; that is certainly not true. However, the
measurement of 'levels' seems to me to be quite arbitrary. And the process
of certifying a company at a certain level seems to me to be less than
worthless. It creates artificial goals ("We must be level 3 by August!")
and there is little or no empirical data to show that the goal is actually
worthwhile.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
Robert C. Martin
Gerhard Menzl wrote in message <36750646...@sea.ericsson.se>...
>Exactly. After I had left the worst hacker shop I have ever had the
misfortune to
>work for, I learned that they got ISO-9000 certified. They bailed out of it
soon,
>though, because of the quality pretending effort they would have had to
undergo
>once a year. To me, this means that an ISO-9000 stamp conveys no
information
>whatsoever, except that the company involved has filled out a lot of forms.
>
>Quality is in people's minds, not in certificates.
Absolutely! As you'll read in my Engineering Notebook column, in the
February C++ Report, I know of a company that passed certification by
instructing the employees on how to answer all the questions of the
auditors, and by informing them as to which hallways and labs they could
take the auditors. It was a complete sham.