Re: best Dam*ed development environment revisited (was Re: [DotGNU]Working Groups plan v2)

[Stephen Compall]

Charles Shuller wrote:
> I completely agree, but I'm lost on a key issue.  Isn't the 
> interoperability thing what Sun tried to do with Java, and what POSIX 
> tried to do with C?  How do we ensure success where they failed?  I 
> think it is completely possible, but I don't know how to go about it, 
> and I haven't seen anything that addresses that particular issue yet.  I 
> also don't think Java had anything particularly wrong with it 
> technically, other than it was massivly slow.  To me it seems lack of 
> industry/developer support, and they got most of Academia onboard. Which 
> also seems to be a point (specifically that Java lacked a cool 
> DevPlatform) of Fitzix, if I'm not mis-reading this quote.

That's because Java tried to force everything through a single, totally 
code-dominant system. So did POSIX (the Single Unix Spec, not C). What I 
mean is that all the ways you can work with the system are controlled by 
these systems; or at least that is their intention.

By allowing multiple VMs, multiple auth systems, and such, while not 
imposing the DotGNU "environment" on them, DotGNU has the openness that 
it takes.

> I could easily be completely off here, but I LIKE using Emacs and Make 
> :)  Most IDE's completely irritate me, do we have enough developers 
> working with us, who like using IDE's, to design, develop, and test one? 

Do we need an IDE? Not really. Like I said, even the "friendliness" of 
an IDE can be replaced with components.

The trick is not to eliminate autoconf, automake, and whatever else you 
like in the chain. These components were designed to work in the chain, 
and as many do prefer to work in the old-style environment. There's also 
no reason to require a full transition to an IDE-like environment if you 
just want to use one aspect -- say, creating RPM specs.

The trick is to avoid adding new unnecessary file formats. Why create a 
new "pnetprj" file format when the csant .build files express the build 
perfectly well? Also necessary is allowing interoperability between 
different build systems in use. i.e. you might have a C system program 
and a C# webservice in the same tree. Why make it nasty for them to 
coexist? That's a feature of autoconf as well: it doesn't care what you 
do beyond it, it interoperates well.

Here is something I wrote a few weeks ago, to introduce the DotGNU 
Development Environment (basically, all these tools, at commandline and 
?UI):

DotGNU Development Environment: *Not an IDE*!
*********************************************

   As GNU users, we vastly prefer coherent systems of tools, each with
certain purposes, working together, instead of all lumped together into
one package. The latter method's single tool is the "integrated
development environment". By lumping everything together, creators of
IDEs lose the advantages of toolchains, namely that [toolchains are]
more dynamic in that the pieces can be interchanged for others, and
they reuse the best of what went before, rather than "reinventing the
wheel."

   For example, the GNU Emacs editor is the most powerful, featureful
text editor in the world. The IDE concept requires providing a wholly
new editor, losing all the advantages of Emacs.(1)

   With the "DotGNU Development Environment", it is my intention to
connect the developers of various parts of the toolchain into creating
a coherent system, which will surely provide a better "user
experience"(2) than these IDEs.

   ---------- Footnotes ----------

   (1) If you aren't aware of these advantages, try starting `emacs' and
playing around for a while, or have a look at *Note Emacs: (emacs)Intro.

   (2) That is, developer experience....

*************************************************

And how, you may ask, do you glue these components together asis? Well, 
what do you think I mean by the word "glue"? >:->

--
Stephen Compall
Also known as S11001001
DotGNU `Contributor' -- http://dotgnu.org

Sometimes I think that perhaps one of the best things I could do with
my life is: find a gigantic pile of proprietary software that was a
trade secret, and start handing out copies on a street corner so it
wouldn't be a trade secret any more, and perhaps that would be a much
more efficient way for me to give people new free software than
actually writing it myself; but everyone is too cowardly to even take
it.
        -- RMS, Lecture at KTH (Sweden), 30 October 1986