[Prev][Next][Index][Thread]

Re: Integrated Linux Environment



Jonathan Ben-Avraham writes:
 > > From: "Harvey J. Stein" <abel@netvision.net.il>
 > >
 > > There's also xwpe.
 > >
 > > But I think multiple xterms + emacs + gcc + make + gdb + grep + gawk +
 > > byson + yacc + ... is far superior to these "integrated development
 > > environments".
 > >
 > > The only reason these things came about to begin with was because DOS
 > > wasn't multitasking.  Under DOS, you'd have to go into the editor,
 > > make changes, exit, run the compiler, run the program, go back into
 > > the editor ...  To avoid these hassles, they built everything into 1
 > > program, and called it an integrated development environment.
 > >
 > 
 > Not so, Harvey. If you have a really big project in Eifel, Smalltalk
 > or C++ you really have to have a class browser, and it helps to have
 > an incremental Make tool and a code repository or database that allows
 > you to define arbitrary snippets of code as objects for configuration
 > control. Anyone who has used the really good tool that do this, like
 > ENVY, realizes that the classic  multiple xterms + emacs + gcc ...
 > approach has had its day.
 > 

Who was talking about object oriented languages?

But, in any case, if you want a class browser, you should go get one.
OOBR (and emacs package, of course, ftp://ftp.xemacs.org/pub/infodock)
comes to mind.  Here's some info:

  ** Contains support for Eiffel, C++, Objective-C, Common Lisp and its
     Object System (CLOS), Java, Python, and Smalltalk class browsing.  
     Additionally, support for browsing large amounts of material in Info 
     format by node name (a popular online documentation format with cross 
     references and hierarchical structure) is included.

  ** Method browsing is supported for C++, Objective-C, Eiffel, Java, 
     Python and CLOS.  CLOS supports browsing all elements defined with 
     (def* constructs.  In-source feature browsing is also supported for 
     all of these languages.  One simply selects a feature name to jump to 
     its corresponding source.  Method name overloading in C++ and inherited
     feature renaming in Eiffel are fully supported.

  ** C code browsing is supported for C++, Objective-C and C source code.

  ** Objective-C category and formal protocol browsing are supported.

  ** C++ parameterized template classes and methods are supported.

  ** Immediate switching among languages is allowed.  One can switch
     from Eiffel browsing to C++ browsing in an instant, if so desired.
     Or simply run two OO-Browsers side by side.

  ** Multiple inheritance support is built-in, where applicable.

  ** Statistics on classes and Environments may be displayed.

  ** Language-specific class information may be shown.  Presently this
     feature is supported only for Eiffel and Python.  For Eiffel, a 
     listing of class parents, attributes, routines and best guess 
     (highly accurate) list of routine calls may be displayed.  Outputs 
     from the Eiffel 'short' and 'flat' commands may also be shown.  
     For Python this feature is used to browse documentation strings in 
     classes and methods.

And, of course, with some work, you can configure it to support
languages not in the above list...

(btw, another integrated environment to look at would be infodock from
the same directory.)

If you're talking about Smalltalk, the class browser is virtually part
of the system itself, and usually supports :fileout and :filein, so
when worse comes to worse, you can always dump the code to a file,
modify it, and read it back in (as I've had to do on occasion when the
system wouldn't let me do what I needed to do).  Also, the
edit/compile/test cycle is radically different from that of compiled
languages.

My experience has always been that once you start working on large
complicated applications, or for that matter, the moment it'd be
convenient to do something even marginally out of the ordinary, you
immediately run into problems where the integrated environment is
doing something you don't want it to do, or is not doing something you
need it to do.

With integrated environments, once this happens, either you're dead in
the water, or you end up circumventing the environment itself in major
ways.  Often, because of proprietary file formats and internal
hard-wired behaviors, you're unable to adjust things as needed.  Even
if you did have access to the file formats, the system would probably
rebuild the files automatically, thus erasing your changes.

With a collection of unix tools, you never get stuck.  You can always
make the appropriate adjustments, since everything is basically a
simple text file.  You can always add some additional processing where
it's needed to make adjustments.

Of course, the last 2 integrated development environments I've used
were Borland's Turbo C++ for windows (4 years ago), Digitalk's
Smalltalk (also 4 years ago), and Visual Basic (3 years ago).  The
Turbo C++ environment sucked compared to the Smalltalk environment.
The visual basic environment sucked because all the code was cut up
into these tiny pieces hung off of each interface element, and I
didn't see any to easily make global changes.

Unless there have been some major advances over the last four years, I
can't imagine that I'd prefer an integrated environment.

But, since this is far from being a linux-il question, let's defer
further discussion to private email...

Harvey


References: