New editor/Integrated Development Environment/compiler

Hi,


My name is Hiram and I would like to know if somebody is interested in
joining the development of a new kind of editor/Integrated Development
Environment/compiler.


I'm not happy with the current free (or open-source) alternatives that
I've found. I think that all those tools (Eclipse, NetBeans, QtCreator,
Emacs, Vim, ...) have in the bottom the same problem: they work with
directories, files and text.


Personally, I like Vim and I love that it has different modes (command,
insert, visual, ...). The best is that it is fast to open (compared to
the other heavy IDE:s) and that there are thousands of plugins to boost
the development. However, it also works with dirs, files and text.


But ... how else could an IDE/Editor/compiler work then? With STRUCTURE.


And note that I say << STRUCTURE >> and not << MODEL >>. I've worked
with free tools that manage models in order to generate source code but
these models are, most of the time, limited in the level of detail of
the instructions. Those tools do not keep a clean-and-tight relation
between the model and the source code. Sometimes they just make things
messier. I've also worked with UML and have noticed that, in large and
stressing projects, is difficult to keep in sync the UML diagrams with
the source code, most of the time people cares about getting things
done, not about getting designs well-documented.


So, what's the difference between STRUCTURE and MODEL?


I don't want to get into definition problems, everybody can have their
own definition for both words. I would like to refer specially to the
TREE-STRUCTURE of the source code, that I would like to call the <<
SOURCE-STRUCTURE >>.


The source code is composed (as I mentioned previously) by directories
containing more directories and files, and files containing text.
* Going a step further:
- The text of the files is composed by a root level that contains
include/import instructions, class and struct definitions, methods
definitions, etc.
- Structs contain other structs or basic typed elements.
- Classes may include other classes, enumerations, attributes, methods, etc.
- Attributes include type and name.
- Methods include arguments and instructions, ... etc.
* Going a step backwards:
- Directories are found in computers (hosts)
- Hosts are found in networks or in other sort of clustered infrastructures.


Therefore, I see all these elements as branches and leaves of a big
tree-structure (the SOURCE-STRUCTURE).


What I want to create is a tool that works with this source-structure
and that, with the help of different rulesets, transforms the
source-structure into source-code or documentation files or webpages or
three-dimensional worlds, etc. The source-code (directories, files and
text) can then be compiled or interpreted. Going a step further, I think
it might be possible to transform the source-structure directly into
executable code, skipping the compilation/interpretation step.


Having different rulesets for the transformation might help to create
deployment rulesets, debug rulesets, obfuscated rulesets, documentation
rulesets, windows rulesets, linux rulesets, i.e., the same
source-structure can be transformed into deployment source-code or debug
source-code or obfuscated source-code or documentation files, etc.


This is nothing but an extrapolation of using XML (source) and XSL
(rules) to create HTML (product). An even more obvious analogy is: usign
c++ code (source) use gcc (rules) to obtain an executable binary
(product). I'm talking about doing the same but in a higher level: using
the source-structure (source) use some rules (rules) to obtain whatever
you need (product).


Another problem that I found in the current IDE/editors is that revision
control is an optional feature. One might use CVS, SVN, git, etc. to
keep track of changes in the code and to allow collaboration between
developers.


In the application I want to develop, revision control and collaboration
are found at the core level. I think that the current IDE/editors were
developed with old functionality principles in mind. The fact is that
complex applications require the coordinated collaboration of tenths or
hundreds of developers. Thus, the new tool has to be a
collaborative/change-tracking tool with edition features on top, and not
the opposite.


I have tough about many more features that I would like to talk about
but I don't want to make this email longer than it is. Just want to
mention that the tool I want to develop use a Presentation-Logic-Data
architecture, has a three-dimensional interface, allows easy integration
of design-patterns and has an inherent multi-language capability.


Hope you find this interesting. Many thanks for your attention,


/Hiram
[There were structure based tools back in the 1970s. My recollection
is that they were completely unusable other than by the people who
wrote them. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.