Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[learn2code@yourdesk.com]

["Followup-To:" header set to comp.lang.ada.]
On 2009-07-29, Oxide Scrubber <jharriman@hatlop.de> wrote:
> learn2code@yourdesk.com wrote:
>> ["Followup-To:" header set to comp.lang.ada.]
>
> Sorry, no can do. You write complete nonsense in four newsgroups, you 
> get corrected in four newsgroups.

Same to you. Besides, I was just responding to the silly post, if he hadn't
splattered his goo all over usenet my response would have been in one group
as well.

>> On 2009-07-29, Ray Blaak <rAYblaaK@STRIPCAPStelus.net> wrote:
>>> fft1976 <fft1976@gmail.com> writes:
>> 
>>> My problem with it is the lack of a garbage collection. That is just not
>>> acceptable to me these days. If you manually allocate memory, then you
>>> pretty much have memory bugs, it's as simple as that.
>> 
>> That is simply not true. If you don't know how to do resource management
>> properly, you're not ready to write commercial code in any environment.
>
> What utter balderdash. You make GC sound like training wheels

Exactly what it is, excellent characterization!

> when in fact it is very useful even for major production-code systems.

No, it's not useful or even necessary at all unless you have a virtual
machine or other runtime. I work on large systems and we write all our code
in assembler. We don't have GC, we just know how to code. Simple is good for
performance, for readability, and for just about everything else. That's
another reason I like Ada, at least through the 95 version.

I would hate to see the "major production-code system" that relied on GC. I
can tell you this with certainty, no bank, insurance company, airline, or
any other online realtime operation uses such nonsense. Of course they have
some bits here and there written in C++ but the code that keeps them online
and serving customers is written in COBOL, assembler or Ada and doesn't need
or have GC. That's production.

If you're talking about academic (know-nothing) or hobbyist languages I can
understand how GC would be a virtue along with all the other mind-numbing
"improvements" made over the years.

> Consider memory management of an object that is shared and passed around 
> at need among many related parts of a program. Keeping track of when 
> it's no longer in use rapidly becomes nontrivial as the complexity of 
> the code using it goes up. Eventually, you'll be reference counting or 
> doing something else like that, and before long, you'll end up with an 
> ad-hoc, informally specified, slow, bug-ridden implementation of half of 
> a garbage collector. (This will probably in turn be a part of an ad-hoc, 
> informally specified, slow, bug-ridden implementation of half of Common 
> Lisp.)

This is how most uninformed people deal with fundamental lack of knowledge
and discipline in the design and coding of systems of any significant size
and scope. They just go from bad to worse by using spit and bailing wire
instead of understanding the issues and avoiding fundamentally incorrect and
inappropriate practices and language implementations. Know your tools and
you can avoid these problems entirely.

Reference counting and other such silly schemes are as much rubber crutches
as GC. All of the need for this sort of rubbish is based on the basic
inability to design and implement properly. If you would just have control
and understand your platform, all of these problems would go away.

> Why not save yourself the trouble and use a real GC, then? Especially 
> since a properly-used GC will actually improve execution speed.

Because we have never needed them. And nobody else does unless they want to
strap themselves into Java or other bloated run-time systems, as I
said. Traditional compiled languages have no need for GC.

>> Garbage collection is a throwback to interpreted languages and bloated
>> run-time systems.
>
> Poppycock.

And then you go on to give examples of interpreted languages with bloated
runtimes like Lisp, Smalltalk, Clojure, etc. We don't get fooled by VMs,
they're still interpreters. Compiled code runs on bare metal with no
runtime. That's the distinction.

>> Normal compiled languages get along very well without any such thing
>> at all.
>
> Many implementations of Common Lisp are compiled. All have GCs. Are none 
> of them "normal" compiled languages?

No, they're still based on run-time systems and have fundamental flaws that
create the need for GC. At any rate, they're not used in large systems and
not where performance is essential. I don't have any interest in those sorts
of applications. Academic computing is only interesting to academics. I work
on code that has to work and has to perform. None of the languages you
mention will do for any serious sort of work.

>> You need to understand your tools and not rely on the rubber crutches
>> overglorified scripting platforms like Java have taught people to put
>> blind faith in. What ever happened to competent coders?
>
> They've all seen C++ for the unholy mess it is

On this we agree!

> and migrated to languages like Java, Scala, and Clojure that let you get
>something done without worrying about micromanaging memory?

Memory and resource management generally are fundamental aspects of software
engineering discipline. Java is not a language, it's a scripting platform on
a dedicated VM. It's not progress to dumb-down programming to where you need
GQ and a VM and then say why should we worry about micromanaging? It's all
in the details. I think you ought to have total control over what you're
writing and how it works and some of the languages that offer that better
than others are of course assembler but include Ada.

> Now if only we could stop worrying about streams and window handles and
>other such nonsense too and have  the computer automation take care of
>those sorts of niggling details too, as is the computer's job. :)  

That's a fundamental point of disagreement. I don't want anything done for
me. I'll tell the machine what to do, and that's what I want. The father
you get from your hardware, the less efficient your executable, the less
control you have, and the more protection from yourself you need. I don't
want anybody to blame but myself.

If you don't agree, then why stop there? Just write application and code
generators and be done with it.

> Funnily enough, it's similar to Java notation.

That's not by accident, that's by ripoff.

> Of course, you might find CLOS notation worse -- all those
> parentheses. Smalltalk too -- no actual  monolithic class file, just
> individual methods browsable from a list,  and possibly mixed in with
> methods of other classes when dumped to a  file. C# is like Java, with
> some funky extras. Am I missing any? Oh,  yeah, Modula 3. And don't get
> me started started on Objective C... 

The pattern seems to be that OO implementations are necessarily inefficient
compared to their predecessors and as a result of a few years of relying on
their self-protection, coders have become less and less competent, further
away from the machine, and more dependent on nannying. I don't approve of
this. I don't want my car to drive itself to the store, I'll steer it, use
the gas and brakes, and make it do what I want, thanks very much.

I realize every so-called coder under the age of 30 has been brainwashed
into thinking OO is the silver bullet but that's simply not the case. This
misapplication and misimplementation of OO has done far more damage than
good and now we are seeing the results as people become more reliant on
self-protection and less and less capable of doing anything themselves
without 3rd party libraries, GC, and layer upon layer of middleware,
etc. Where does it stop?

>> Ada is readable. It's clean, it's orderly, it's so much better and safer
>> than C++ that there isn't any comparison at all.
>
> And it's at least as verbose as Java. Eeeuw. If you can cope with deeply 
> nested parentheses, Lisp FTW. Otherwise maybe stick with C? :)

Ada is not verbose at all. I don't understand how you can make that
statement. Java is a sloppy mess like its cousins. Ada makes reading the
code simple and that was a design goal of Ada.

> I'm more worried about the wackos that think manual memory management is 
> a must-have.

And why is that? Is personal responsibility somehow not relevant to coding?
Is understanding your hardware and making it do what you want no longer the
goal of programming?