«

Hi all,

I have an idea for a better IDE. Though I don't have
the skills required to write such a thing, if anyone's
looking for a killer app, maybe this is it.

If I'm typing at a rate of 10 characters per second
(which is *very* fast for sustained code writing),
then my computer is executing around 200,000,000
instructions as it waits for the next keystroke to
come in. That's a lot of power going to waste.

Why not use that time to compile my code?

Sure, the bit code I'm typing right now is changing,
but huge chunks are sitting around, waiting. Why not
process them now? That way, when I finally come to
build the executable, 99% of the compiling has been
done already, and there's just the linking step to
do.

The algorithm might look something like this:

When my cursor leaves a line that I have edited,
its knock on effects are analysed.

- If this is the line of a small, non-inline function,
then this function can be compiled immediately.

- If this in an inline function then this function and
any that use it are queued for compilation. They needn't
finish before the next keystroke, just whenever.

- If this is a header file, then whole .cpp files will
need to be queued for compilation.

- If I edit some code it's compiling, then it cancels
that chunk and waits till I stop.

As compilation chunks are finished, the actual code, or
perhaps pre-asm pseudo instructions can appear in another
window, along with the code it came from (much like you
see in a debugger). This way, it's immediately obvious how
efficient your code is.

More importantly, the IDE would have a deep understanding
of the code you're typing, as you type it. It can take
Visual Assist to a whole new level. I would very much like
to have something like Lint for C++. I would like it even
better if it could point out potential problems in my
code as I type it.

The amount of processing that's actually done in the IDE
could be anything from just parsing and understanding the
structure of the code, to generating the intermediate
representation, to the final machine instructions. Depends
on whatever's the most convenient way to do this. Not being
a compiler expert myself (I can barely operate one) I don't
know the million reasons why this is a terrible idea. But if
anyone's got any thoughts, I'd be interested to hear.

Thank you for your time.

Hugo Elias

> If I'm typing at a rate of 10 characters per second
> (which is *very* fast for sustained code writing),
> then my computer is executing around 200,000,000
> instructions as it waits for the next keystroke to
> come in. That's a lot of power going to waste.

> Why not use that time to compile my code?

First of all, it may actually take several thousand instructions to
process each keystroke, or even more. The OS has to find what process
to send the keystroke to; that process may be a window-server, which
dispactches a message to another process. Once in the IDE process (if
not before), the keystroke is probably encapsulated as a generic event
class and dispatched to a virtual function, which may notify several
different objects and set a lot of state information. One effect is to
output a character on the video display. If you're using a TrueType
font on a bitmapped display, it may be necessary to compile that
character; in any case, the graphics engine will need to do a (WxH)
bitblt...

People have done stuff leading up to what you're describing. Many
editors for C++ and other C-like languages have syntax highlighting.
Microsoft Visual C++ 7 automatically looks up class members when you
type the name of an instance of that class, and does other basic
checks as you type. NetBeans (a Java IDE) actually does pretty much
what you describe, although it's easier with Java because the syntax
is a little more restricted.

Consider what your program would do as someone typed the following
short program:

#include <iostream>
#include <string>

int main()
{
std::string s = "Hello";

cout << "Copyright 2005 Some Programmer" << endl;
for (int i=0; i<11; i++) {
char c;
cin >> c;

.... etc.

At every point before the end of main(), a normal C++ compiler would
complain about a parse error (unmatched '{' ). At most places it would
complain about expecting a ';'. It gets even worse if someone jumps to
the middle of a header file and starts typing a class definition,
because every function in every file becomes invalid until the class
definition is closed with "};".

I'm not sure if these are insurmountable difficulties; for instance,
the editor could automatically add a phantom '}' to match each '{', a
phantom ';' before each '}', a phantom ')' to match each '(', a
phantom ':' for each '?', a phantom "return (default value for type)"
at the end of each non-void function that doesn't unconditionally
return a value, etc.

That last one is an interesting case: of course the default for any
simple type is easy:

char '\0'
int 0
float 0.0f
double 0.0
void* NULL (if a #include <cstdlib> is present)

What about a function decalred as

SomeClass& SomeClass::func() ?

Here the default value could be (this).

What about

OtherClass& SomeClass::func() ?

No idea.

I find that fancy doodads in editors are sometimes useful, but other
times they can be downright distracting, and I'm glad emacs allows me
to turn stuff like that off.

--
DLL

David Lee Lambert wrote:

> I'm not sure if these are insurmountable difficulties; for instance,
> the editor could automatically add a phantom '}' to match each '{', a
> phantom ';' before each '}', a phantom ')' to match each '(', a
> phantom ':' for each '?', a phantom "return (default value for type)"
> at the end of each non-void function that doesn't unconditionally
> return a value, etc.
>
> That last one is an interesting case: of course the default for any
> simple type is easy:
>
> char '\0'
> int 0
> float 0.0f
> double 0.0
> void* NULL (if a #include <cstdlib> is present)
>
> What about a function decalred as
>
> SomeClass& SomeClass::func() ?
>
> Here the default value could be (this).
>
> What about
>
> OtherClass& SomeClass::func() ?

return *(OtherClass*) 0;



Jonathan

Hugo Elias wrote:
> Hi all,
>
> I have an idea for a better IDE. Though I don't have
> the skills required to write such a thing, if anyone's
> looking for a killer app, maybe this is it.
>
i've found that when I say something like this, it's been done before
already and has a better featureset than i'd considered.

> If I'm typing at a rate of 10 characters per second
> (which is *very* fast for sustained code writing),
> then my computer is executing around 200,000,000
> instructions as it waits for the next keystroke to
> come in. That's a lot of power going to waste.
>
> Why not use that time to compile my code?
>
in the Eclipse platform with the C/C++ extensions, you can configure it
to do exactly that - each time you save your work, it can compile the
unit and give you immediate feedback in the messages panel as to
errors, warnings, etc. it can even go so far as to link the whole
project in the background so you can test the application shortly after
you save.

this is great for small projects, but when your source files grow to
hundreds upon hundreds of lines and the time required to compile one of
them starts reaching into the minutes, this quickly grows tiresome and
counterproductive.

> The algorithm might look something like this:
>
> When my cursor leaves a line that I have edited,
> its knock on effects are analysed.
>
> - If this is the line of a small, non-inline function,
> then this function can be compiled immediately.
>
> - If this in an inline function then this function and
> any that use it are queued for compilation. They needn't
> finish before the next keystroke, just whenever.
>
> - If this is a header file, then whole .cpp files will
> need to be queued for compilation.
>
> - If I edit some code it's compiling, then it cancels
> that chunk and waits till I stop.
>
what you're asking for here is well outside the scope of the IDE -
you're now talking about an interactive compiler suite that can
dynamically compile units at the function level rather than at the unit
(or object) level. such a compiler would be overly complex, prone to a
great deal of internal compiler bugs, and would most likely output very
poor-quality object files.

> As compilation chunks are finished, the actual code, or
> perhaps pre-asm pseudo instructions can appear in another
> window, along with the code it came from (much like you
> see in a debugger). This way, it's immediately obvious how
> efficient your code is.
>
so configure Eclipse to preserve intermediate files during compile
steps and write a plugin that displays the output assembler file,
seeking to areas relevant to where you're working in the main window.

admittedly, this sound snice, but in practice, i suspect it would be
far too much screen clutter, and you'd shut it off, keeping it around
only for debugging.

> More importantly, the IDE would have a deep understanding
> of the code you're typing, as you type it. It can take
> Visual Assist to a whole new level. I would very much like
> to have something like Lint for C++. I would like it even
> better if it could point out potential problems in my
> code as I type it.
>
Eclipse does just this by giving immediate feedback on a line of code -
in many ways like Microsoft Word's spellcheck and grammar check -
showing you problem areas to look at. it's not a full-blown syntax
checker like the one in a compiler, but it's close enough that it helps
a good deal.

> The amount of processing that's actually done in the IDE
> could be anything from just parsing and understanding the
> structure of the code, to generating the intermediate
> representation, to the final machine instructions. Depends
> on whatever's the most convenient way to do this. Not being
> a compiler expert myself (I can barely operate one) I don't
> know the million reasons why this is a terrible idea. But if
> anyone's got any thoughts, I'd be interested to hear.
>
your idea is an interesting one - but you seem to be confusing the jobs
of an IDE with that of a compiler. the compiler has only one purpose
in life - and that is to compile source into object code. likewise, an
IDE has only one purpose - and that is to integrate the functions of a
text editor with the execution of Makefiles and compilers to make the
developer's life easier. the IDE has no place taking over the _JOB_ of
a compiler any more than the compiler should have anything to do with a
text editor.

that said - it's been done. go check out the Eclipse platform.
> Thank you for your time.
>
> Hugo Elias

Hi all,

Many thanks for the replies. I am glad that
you have taken the time to consider my idea.

I hope I am not breaking netiquette here by
answering two posts at once. I have credited
each author.


David Lee Lambert wrote:
> First of all, it may actually take several thousand
> instructions to process each keystroke, or even more.

Yes, of course. Let's be conservative, and say it takes
one million instructions. That still leaves 199,000,000
instructions for thumb twiddling. And that's if I type
extremely fast. If I take a moment to think, or rest my
weary fingers, the compiler may have 3x10^10 instructions
to play with, or more.


David Lee Lambert wrote:
> At every point before the end of main(), a normal C++ compiler would
> complain about a parse error (unmatched '{' ).

That's ok. Nobody would expect the compiler to work miracles.
On encountering such a glaring error in the code, it would simply
stop parsing, and highlight the error. Why wait until I press F7 (or
whatever) to point out such a glaring mistake.

This is similar to the behaviour of an IDE with syntax colouring.
When I type a /* all of the code after is turned immediately into
the colour of a comment. This is not what I had in mind, but as
soon as I type the */ the colouring is fixed.



David Lee Lambert wrote:
> I'm not sure if these are insurmountable difficulties; for instance,
> the editor could automatically add a phantom '}' to match each '{', a

I don't think the compiler should type your code for you. That's
surely some kind of AI problem. It need only wait patently, colouring
the line as you type it, and restarting the compilation when the cursor
leaves the line.


David Lee Lambert wrote:
> I find that fancy doodads in editors are sometimes useful, but other
> times they can be downright distracting, and I'm glad emacs allows me
> to turn stuff like that off.

Of course, that should always be an option. You needn't
see any of this information in real-time. But would you choose
to disable essentially instant compiling, and deeply informative
syntax colouring?



grey wolf wrote:
> in the Eclipse platform with the C/C++ extensions, you can configure it
> to do exactly that - each time you save your work . . .
>
> this is great for small projects, but when your source files grow to
> hundreds upon hundreds of lines and the time required to compile one of
> them starts reaching into the minutes, this quickly grows tiresome and
> counterproductive.

This is almost what I had in mind, but not quite. The difference
is what you have highlighted: that the compile time can be very
slow for large projects. I imagine that, after every save, you
have to wait for the compile to complete before you can continue
typing? If that is the case, then I can imagine it totally ruins
the coding experience.

What I am suggesting is a tool which would never waste more of
your time than a conventional IDE+compiler, and may well save
a great deal of time.

It simply makes use of the available time, constantly and invisibly
restarting chunks of compilation as it needs to. To the user, it
would simply look like a super syntax colourer, plus very short
compile times.


grey wolf wrote:
> what you're asking for here is well outside the scope of the IDE -
> you're now talking about an interactive compiler suite that can
> dynamically compile units at the function level rather than at the unit
> (or object) level.

Now, this is where I show off my ignorance of the innards of a compiler.
I always assumed that, at some point, a compiler would have to consider
non-inline functions on their own, without considering other functions
at the same time. Can anyone clarify this?

There must be some amount of work that can be done to compile and
optmise a function in isolation.

At the very least, it could be compile whole units that you are not
currently editing. Often, I make changes to several units. The compiler
could begin compiling one of those as soon as you switch to a different
source window, and stop if you begin editing it again. Hmm, I wonder if
this can be done with eclipse?


grey wolf wrote:
> your idea is an interesting one - but you seem to be confusing the
> jobs of an IDE with that of a compiler ... [cut] ... the IDE has no
> place taking over the _JOB_ of a compiler any more than the compiler
> should have anything to do with a text editor.

Yes, I am talking about an *Integrated* Development Environment,
where the compiler has also been integrated too.
I am fully aware that currently the jobs of the editor, compiler,
linker and make are all separate. But this is not a law of physics,
and there is no confusion.

Once, for example, mechanical CAD software and Stress FEA tools
were separate applications, now you can get CAD with integrated
stress analysis, which makes the engineer more productive. PCB
layout tools, and FPGA firmware authoring tools were separate,
but intergrating them allowed the PCB autorouter to help optimise
the usage of the FPGA pins to make more efficient routing.
In this case, bringing the expertise of the compiler into the
coding might have great productivity gains.



> such a compiler would be overly complex, prone to a
> great deal of internal compiler bugs, and would most likely output very
> poor-quality object files.

I agree that the compiler would be more complex, but I don't
see why this particular feature should introduce relatively
more bugs than any other advanced feature. I can imagine people
saying that an optimising compiler had no place optimising your
code for you, and would be buggy, back when someone first suggested
it.
I also don't see that the compiler should produce code that is
in any way different to that which it would produce by compiling
all at once. But that view may come from my ignorance.


The payoff would be if such a tool could dramatically improve
the productivity of programmers, and perhaps even improve the
quality of their code. The best time to catch a bug is at compile
time. Let's have more compile time!


Sadly, this is as far as I go. As is often the case, my dreams far
outshine my talents. Rather than lamely suggesting it, I would
normally just go ahead and do it, as I am currently doing for a
similar idea I have for a tool for editing PCBs. Watch this space.

Many thanks for your patience if you have read this far.

Also, thanks grey wolf, I'll go and check out eclipse. I am
looking for a new IDE at the moment.

Hugo Elias

Hugo Elias wrote:
>
> grey wolf wrote:
> > in the Eclipse platform with the C/C++ extensions, you can
configure it
> > to do exactly that - each time you save your work . . .
> >
> > this is great for small projects, but when your source files grow
to
> > hundreds upon hundreds of lines and the time required to compile
one of
> > them starts reaching into the minutes, this quickly grows tiresome
and
> > counterproductive.
>
> This is almost what I had in mind, but not quite. The difference
> is what you have highlighted: that the compile time can be very
> slow for large projects. I imagine that, after every save, you
> have to wait for the compile to complete before you can continue
> typing? If that is the case, then I can imagine it totally ruins
> the coding experience.
>
that's not the case. stop imagining and try the Eclipse platform for
yourself.

> What I am suggesting is a tool which would never waste more of
> your time than a conventional IDE+compiler, and may well save
> a great deal of time.
>
> It simply makes use of the available time, constantly and invisibly
> restarting chunks of compilation as it needs to. To the user, it
> would simply look like a super syntax colourer, plus very short
> compile times.
>
IMO, it's a good idea when you limit it to the syntax checking. if you
go beyond that, it becomes vendor lock-in: i'm forced to use a
compiler that may not be the one my project requires.

>
> grey wolf wrote:
> > what you're asking for here is well outside the scope of the IDE -
> > you're now talking about an interactive compiler suite that can
> > dynamically compile units at the function level rather than at the
unit
> > (or object) level.
>
> Now, this is where I show off my ignorance of the innards of a
compiler.
> I always assumed that, at some point, a compiler would have to
consider
> non-inline functions on their own, without considering other
functions
> at the same time. Can anyone clarify this?
>
> There must be some amount of work that can be done to compile and
> optmise a function in isolation.
>
nearly all of it, yes. but there are, in some cases, unforseen
difficulties in applying optimization tricks that require the context
of additional code.

additionally, don't forget that this automatic compiling is necessarily
forced to one build type - if multiple build types are allowed, memory
requirements become double what they need to be to support parallel
builds with opposing compiler options - not to mention the additional
CPU time required to maintain this constant recompiling.

> At the very least, it could be compile whole units that you are not
> currently editing. Often, I make changes to several units. The
compiler
> could begin compiling one of those as soon as you switch to a
different
> source window, and stop if you begin editing it again. Hmm, I wonder
if
> this can be done with eclipse?
>
that is exactly the case when you save and switch to another file. you
can work as it saves and rebuilds the workspace, thugh it slows down
the editor's responsiveness.

>
> grey wolf wrote:
> > your idea is an interesting one - but you seem to be confusing the
> > jobs of an IDE with that of a compiler ... [cut] ... the IDE has
no
> > place taking over the _JOB_ of a compiler any more than the
compiler
> > should have anything to do with a text editor.
>
> Yes, I am talking about an *Integrated* Development Environment,
> where the compiler has also been integrated too.
> I am fully aware that currently the jobs of the editor, compiler,
> linker and make are all separate. But this is not a law of physics,
> and there is no confusion.
>
> Once, for example, mechanical CAD software and Stress FEA tools
> were separate applications, now you can get CAD with integrated
> stress analysis, which makes the engineer more productive. PCB
> layout tools, and FPGA firmware authoring tools were separate,
> but intergrating them allowed the PCB autorouter to help optimise
> the usage of the FPGA pins to make more efficient routing.
> In this case, bringing the expertise of the compiler into the
> coding might have great productivity gains.
>
the IDE's job is to manage the Makefile and build environment, and run
the compiler when requested. the compiler is a separate entity for the
purposes of pluggability: i can switch the default compiler for my
own.

fully integrating the compiler removes that freedom and adds unneeded
complexity to the compiler itself so that its work can be paused and
maintained in memory.
>
>
> > such a compiler would be overly complex, prone to a
> > great deal of internal compiler bugs, and would most likely output
very
> > poor-quality object files.
>
> I agree that the compiler would be more complex, but I don't
> see why this particular feature should introduce relatively
> more bugs than any other advanced feature. I can imagine people
> saying that an optimising compiler had no place optimising your
> code for you, and would be buggy, back when someone first suggested
> it.
> I also don't see that the compiler should produce code that is
> in any way different to that which it would produce by compiling
> all at once. But that view may come from my ignorance.
>
compiling all at once allows the compiler to make additional
considerations for the purposes of profiling, debugging, and
optimizing. compiling function-at-a-time is roughly equivalent to
separating every function in a unit into its own unit, leaving
optimization work to a linker, where fewer optimizations and
considerations can be made. in the compiler, the full context of the
unit is immediately available, making it possible to add these
additional considerations and produce overall higher-quality object
code.

>
> The payoff would be if such a tool could dramatically improve
> the productivity of programmers, and perhaps even improve the
> quality of their code. The best time to catch a bug is at compile
> time. Let's have more compile time!
>
so save more often and recompile each unit more often, paying close
attention to all warnings and errors.

>
> Sadly, this is as far as I go. As is often the case, my dreams far
> outshine my talents. Rather than lamely suggesting it, I would
> normally just go ahead and do it, as I am currently doing for a
> similar idea I have for a tool for editing PCBs. Watch this space.
>
> Many thanks for your patience if you have read this far.
>
> Also, thanks grey wolf, I'll go and check out eclipse. I am
> looking for a new IDE at the moment.
>
sure. you may also want to check into Emacs (which has an integrated
Lisp interpretor which makes it very flexible in any role) and Vim
(which is mor eminimalist and has additional features designed for
programming). both can be used as full-blown IDEs with some work to
set them up to your liking.

> Hugo Elias