RE: [GD-General] Eiffel

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

> Some people (that even I consider a little crazy) do 
> surprising things with emacs.  Like, did you know that emacs 
> (er, XEmacs anyway) is a graphical web browser?

M-x whatever-dude

=)

Seriously though, I've known people that were crippled by not having
their .el files, and basically wouldn't use a computer until A.) Emacs
was installed and B.) they had their custom ELisp files loaded.  To me
it's like a bassist saying "I can't play unless I have my Wal".  Tools
matter, but they shouldn't matter so much that you're non-functional
without your perfect choice of tool.

I have a way easier time understanding the vi freaks, but now we're
getting way off topic...

> I don't really see the difference... the filesystem *is* a 
> browsable database.

Hey, and "cat > main.c" is a text editor =P

> > 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.
> 
> Huh?  Code somehow becomes magically less complex?

No, but it becomes a bit more structured when the language itself
encourages/enforces at least a modicum of discipline.  Some call this
fascist, I consider it reasonable (and I'm sure when C compilers started
issuing more stringent warnings about type safety that people considered
that fascist also).

> In response to your general point, that good programming 
> environments enhance productivity -- I agree completely.  I 
> just disagree with all your examples :)

Fair enough, as long as you understand my point =)

A better way of putting what I'm thinking is that programming needs to
become a more integrated process.  Radical disconnects between design,
analysis, versioning, and authoring, even if they're patched together by
the wonder that is Emacs =P, don't help.  It should become a process
whereby the various tools can take advantage of domain-specific
knowledge relating to the underlying language in use.

Ugh, I'm still saying this poorly -- how about this: programming should
be moving outside the domain of a language/syntax and into the domain of
a complete development process.  And I'm not talking academic analysis
of the problem, but taking into account where the problems occur in the
real world.  Much of what I liked about Ian Joyner's paper was that he
emphasized "Here's a real problem, not a language lawyer issue".  For
example, small things like "modifier before identifier makes browsing a
pain in the ass":

a() int;
b() void *;
c() const char *;

Is easier for a human being to scan than:

int a();
void *b();
const char *c();

But I digress (again).  I'd like to see Extreme Programming as applied
to development environments/work flow, not just philosophy and the act
of typing in code.  I don't want to deal with header files, precompiled
headers, and all the ugliness of separate files for interface and
implementation.  I want the dependency analysis done by a custom tool.
I want the language to concentrate on structure, not details.  Yadda
yadda yadda.

Eiffel seems to promise a lot of this (which sparked this thread), but
I'm still suspicious of it because I've yet to see someone actually use
it then bag on it.  Seems too good to be true, much like Obj-C (which,
as I've stated, just plain rules all...on OS X).

As JC Lawrence mentioned, much of this is the argument of atomic vs.
monolithic, but in this case I'm arguing that monolithic is better
because the fundamental data has context that all the tools need to
access.  Yeah, I know, convert to XML and pipe it through the command
line in a form all the tools understand.  Bah.

Brian