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

[Oxide Scrubber <jharriman@hatlop.de>]

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.

> 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, when in 
fact it is very useful even for major production-code systems.

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.)

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

Typical C++ code has to spend time deallocating objects proportional to 
the number of objects that need deallocating. GCs tend to spend time 
deallocating objects proportional to the number of objects that 
*survive* since the last GC. This is often a much smaller number.

On a modern JVM, including Hotspot, the amount of time spent on memory 
management for objects that don't survive to be copied to a tenured 
generation tends to be two.

Two instruction cycles per object, that is, one to copy a pointer and 
one to bump a pointer.

Not even some fiddling around with a free-list on top of that.

The devil is in the details, but the time spent on objects that do 
survive tends not to be much worse over time, especially for very long 
lived objects, which get tenured once and then are very rarely dealt 
with by the garbage collector, which sweeps the tenured space far less 
frequently than it does the young-object space.

The new G1 collector is supposed to be even more efficient; TLABs become 
boxes of objects, which fill up. Eventually the system needs fresh TLABs 
and all the boxes are full, whereupon some of the oldest get garbage 
collected. By then almost everything in them tends to be garbage, and 
only a very few objects must be copied to empty most of those boxes 
while filling a few with live objects. Those become a kind of ad-hoc 
"tenured" generation. Or something like that. Sun's web site has 
technical information about it, somewhere. A site-scoped google search 
of it for "garbage first" should bear fruit.

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

Poppycock.

> 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?

> 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.

Java? Scripting platform? Oh, PUH-LEEZE. You can't script in Java. Too 
much static main this and class that boilerplate needed, plus you have 
to *compile* it and everything. You can't just write a few lines of code 
in a .java file, sic some interpreter on it, and away you go, unlike say 
Python.

As for GC being "rubber crutches": see above.

> What ever happened to competent coders?

They've all seen C++ for the unholy mess it is and migrated to languages 
like Java, Scala, and Clojure that let you get something done without 
worrying about micromanaging memory? 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. :)

> There is no idiot-proof system.

Hence your characterization of Java as one seems to be rather flawed.

> If you don't know how to manage storage, you shouldn't be allocating
> it.

Who says they don't know how to? Maybe they just don't *want* to, when 
the computer is perfectly capable of doing it for them, reliably and 
error-free.

Do you think they should also do all sorts of arithmetic manually 
instead of having the computer do it faster and more reliably, too?

Take that to its logical conclusion and all computers "should" be used 
for is playing Quake, while real work is done entirely by hands-on human 
labor.

How positively Luddite of you.

>> Also, I find the OO notation a little quirky.
> 
> That's a tough proposition from someone advocating C++. C++ notation is
> hideous, obfuscated, and error-prone. It's one of the least readable (maybe
> the worst in that regard) of any of the languages in common use.

Funnily enough, it's similar to Java notation. 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 on Objective C...

> 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? :)

> But that is certainly all
> lost on somebody who believes it's impossible to manage memory properly

I doubt any of us do so. Indeed, a counterexample seems to be Sun's 
Hotspot GC, which seems to manage memory properly. I've never known it 
to make a mistake, so it *must* be possible.

> and thinks garbage collection is a must-have for any language.

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

>> My own language choice now would be Java or C#. I am investigating Clojure
>> since I always have a fondness for Scheme/Lisps, and a modern Lisp on the
>> JVM solves a lot of problems.
> 
> Well yes, if you don't know how to code and if you don't understand
> fundamental aspects of software engineering like resource management, you

Horsefeathers.

> the "protect me from myself" platforms like Java

Codswallop.

> and C#.

Blatherskite.