Idea for a better IDE

Discussion in 'C++' started by Hugo Elias, Jan 26, 2005.

  1. Hugo Elias

    Hugo Elias Guest

    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
     
    Hugo Elias, Jan 26, 2005
    #1
    1. Advertising

  2. > 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, Jan 26, 2005
    #2
    1. Advertising

  3. 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
     
    Jonathan Turkanis, Jan 26, 2005
    #3
  4. Hugo Elias

    grey wolf Guest

    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
     
    grey wolf, Jan 26, 2005
    #4
  5. Hugo Elias

    Hugo Elias Guest

    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, Jan 27, 2005
    #5
  6. Hugo Elias

    grey wolf Guest

    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
     
    grey wolf, Feb 3, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    59
    Views:
    982
    Terry Reedy
    Aug 17, 2005
  2. Replies:
    10
    Views:
    1,268
    Big K
    Feb 2, 2005
  3. Tarun
    Replies:
    14
    Views:
    570
    Tarun
    Jan 18, 2007
  4. Dr Mephesto

    App idea, Any idea on implementation?

    Dr Mephesto, Feb 4, 2008, in forum: Python
    Replies:
    3
    Views:
    745
    Dennis Lee Bieber
    Feb 5, 2008
  5. Replies:
    0
    Views:
    653
Loading...

Share This Page