RE: [GD-General] Eiffel

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

> Well, there's my favorite IDE, emacs.  Supports every 
> language you've ever heard of, and every feature (for better 
> or worse).  Not very fun to learn, though.

Oooh, ooh, we're treading on dangerous ground here, so, um, I'll try to
be polite =)

Emacs is great -- I used it exclusively from about 1991 to 1996.  In
fact, I used OS/2 2.x ONLY because it had a good Emacs.

But in the end, Emacs is a text editor, and I think that modern
programming is going to move us into custom tools, browsers, source code
analyzers, design analyzers, and all manner of stuff that isn't going to
be expressible as an Elisp function or an external command line tool.  I
know that Emacs has managed to do much of this so far through the
ingenuity of its design and its users, but I have this suspicion that
going forward that the "text only" model isn't going to work.

For example, you can't build a Smalltalk like environment in Emacs (at
least, I don't think you can, but hell, I'm sure someone will post a
link to something similar =) ).

> Cool... I take it Cocoa is what used to be NextStep...

Yep.

> Hm, well, that kind of thing sounds like a bug in the garbage 
> collector, or a crummy allocator.  A practical problem, nonetheless.

In the case of Obj-C, there is GC built into the language itself.  Cocoa
frameworks has a ref counting system (autorelease pools) that is better
than nothing, but not a true behind-the-back GC.  Eiffel implementations
have pluggable GC implementations, so you can choose which one makes
sense for you.  I think C++ and Obj-C are far more susceptible to memory
fragmentation problems (because they expose this information) than, say,
Java and Eiffel.

So I'm glad you pointed that out, because fragmentation shouldn't be a
problem on a closed system that doesn't expose the memory subsystem's
guts.

There's also the difference between "fast enough" and "as fast as
possible".  Games are always striving for the latter, but I think that a
large class of applications need "fast enough" for 95% of their code and
"as fast as possible" for the remainder.  People used to complain that
Obj-C's message passing (or even C++'s virtual functions or C's vararg
functions) were "too slow".  But computers are a bit faster than the
68040/25 machines that NextStep shipped on, so I'm not convinced that
some of the slowness of SmallTalk is still THAT slow =)

> I've heard this gripe a few times lately, and I really don't 
> see it. What's wrong with files, really?  Isn't it really 
> C++'s declare-before-use that's the problem?

The problem is more along the lines of a lack of global "see it all at
once" analysis.  The in order parsing of various files, some with
"declarations" and others with "definitions", is obsolete.  We have
computers to take away this kind of tedious bookkeeping, but instead I'm
the one that has to say "Oh, Foo is a class that I define elsewhere".

In an ideal world you have class definitions that are just in some
browsable database.  You then fill in the blanks on what they do, the
class invariants, preconditions, postconditions, etc. and then the tools
should be able to spit out a complete specification based on your code.
The idea of manual comments becomes an artifact of a by-gone age.
Documentation is necessary, but manual comments (comment == "some text I
put here to explain this bit of code") should be fairly rare.

The build environment can then parse your entire architecture and
generate back end code, comments, dependency analysis, etc. all within
the confines of one environment that UNDERSTANDS the language,
frameworks and tools instead of just PARSING the language and its tools.
Emacs can be made to work with a syntax, but it can't be made to
understand what a language is trying to do.

The common complaint against this is that people wedded to Emacs, make,
grep, perl, etc. will find themselves at the mercy of whatever
environment is provided.  I don't have a problem with this -- I'm
completely comfortable in MSDEV, ProjectBuilder, etc.  I can make them
do what I need them to do, warts and all.  But I do at least understand
their concerns, even if I do find them misguided =)

Brian