RE: [GD-General] Eiffel

[Brian H. <bri...@py...>]

>I'm full of opinions and theories, like everyone else I'm sure.  My
semi-educated impression is that 
>OCaml is the paragon of advanced features, Dylan is the modern heir to
the Common Lisp heritage,
>Haskell is hardcore functional, Eiffel is hardcore OO, and Java/C# is
the half-measure we're all going 
>to be using instead.

I'm shying away from experimental languages that don't have
comprehensive IDEs.  I'm firmly of the belief that a solid development
environment is PART of the language, not an add on, because the language
is strictly a syntax, which is only part of the equation.

This is one reason I haven't really looked too hard at, say, Sather and
OCaml, although they may be far more advanced than the last time I
looked at them (18 months ago?).

Eiffel popped up on my radar when I read Ian Joyner's "Critique of C++"
(and I'm now reading his book, "Objects Unecapsulated").  I became more
interested in the overall subject of tools/languages as an impediment to
programmer productivity after I started using Obj-C (and Cocoa).

My productivity when writing tools with Obj-C/Cocoa is roughly 5-10x
that of using MFC/C++.  I can put together a reasonably competent OpenGL
in an hour, and that's with the completely crappy docs that Apple forces
us to sift through.  After using Obj-C (which is, to paraphrase a friend
of mine, "C with Smalltalk shoved up its ass"), I was thinking "Holy
crap, there IS a better way, and this is it!".  I guess Carmack was way,
WAY ahead of his time, given his use of Obj-C and NextStep some 9 years
ago.  Eiffel feels to me like a slightly better, more advanced version
of Obj-C (er, or Smalltalk) that eschews Obj-C's desire to maintain C
syntax compatibility and instead tries to implement ideas like
design-by-contract to promote better software engineering.

The fundamental problem with using something like Obj-C, SmallTalk or
Eiffel is that they're so detached from the hardware that getting high
performance is fairly difficult.  Not only that, but things like memory
management can't be ignored, especially issues like memory
fragmentation.  I've heard of MUD servers that can run for two days then
grind to a halt; not because of a leak, but because their address space
has become so fragmented from numerous small allocations and deletions.

So C is still important because it lets you manage things very
precisely.  C++ as a "better C" probably serves a purpose.  But for tool
development, e.g. landscape editors and things like that, the higher
level languages (and environments -- this is absolutely key) see to
provide a much faster way to develop real, robust applications that are
also easy to maintain.  I just don't think C++'s compromising straddle
of the no-man's land between "close to the metal" and "high level
abstractions" makes much sense, not for large scale projects that
typically don't NEED to get close to the metal.

And I just find the whole notion of text files that store lines of code
horribly quaint.  It's the new millenium and we're still worrying about
things like forward declarations and circular dependencies.  I find that
amazing.

Brian