Compile as you type

Hi all,

I had a thought. What does anyone think?

It would be great to have an IDE which could compile your C program *as you type*.

Think about it, the compilation process for a single file typically takes a matter of seconds, yet I spend minutes or hours typing and thinking between compilations. This time could be used to compile the code.

Reasons why this would be a good thing:
* Compilation would already be done by the time you want to compile. Just linking to do.
* The IDE could give you much more information as you type. For example
- type checking information
- syntax checking
- 'Lint' type comments
- How many instruction cycles does each line take to perform.
- How effective is the optimisation?

All of these things would be so useful, especially the instruction cycle count. Sometimes it can be surprisingly very high. It would be better to know this at typing time, than having to go digging for it after compiling.

The screen could be split into several columns. You type code in the left one. The next one shows the first pass of the compiler, producing internal symbolic information. Then the optimisation pass, then the output instructions. (or something like that)

Is it possible? One of the reasons I have heard that this wouldn't work is that the code would be full of syntax errors as you type, so would not compile. However, I don't think this is a problem. The syntax colouring IDEs don't crash when they see a syntax error, they just do their best until it's fixed. The same could be true of the compiler. It would wait until the errors were gone, then compile that line / function / section.

What does anyone else think about this idea?

Hugo Elias

> - type checking information
> - syntax checking
Source Insight is especially good at this. Not only will it tell you whether you actually declared all symbols, but it also shows you diagrammatically class relationships, provides tool-tip type assisted auto completion and a whole bunch of other stuff.
Visual Assist for Visual Studio does the same thing more or less.
So do other IDEs no doubt.

> - How many instruction cycles does each line take to perform.
A totally meaningless metric IMO.
Yes, your bubble sort looks very efficient looking at the instruction count for any given line.
But boy, it sure runs like a crippled dog.
You should be focussing on things which matter, and which the compiler is oblivious of, like the Big-O complexity of the algorithms you choose.

> - How effective is the optimisation?
I prefer to let the compiler worry about micro optimisations over whether i++, ++i or i=i+1 is the most efficient. Mostly, it's not that interesting.
Also, there isn't a 1:1 correspondence between source code lines and executable code, especially when the optimiser has been at it. There can be considerable rearrangement of code, elimination of variables and other stuff which makes for a very non-linear association between the two.

> - 'Lint' type comments
You'd need some heuristic to spot when the user had stopped typing otherwise it would just nag you to death with every character you typed.
Personally, I use the pause caused by pressing ctrl-s to trigger this.

> Compilation would already be done by the time you want to compile. Just linking to do.
Save even more time, just type your code into the debugger!.
Oh wait, vc.net has editandcontinue debugging.

Not sure about it. Most of the time the code would be "incomplete", unclosed braces, unfinished statements... For example, if I write a function, I usually type the closing brace as the last thing. So, the code couldn't be compiled until I've finished. And this is where I would compile anyway.

And what would you do with all the optimisation information? The general strategy is to get it working first, and then see if something could be done better.

As for all kinds of information, code completion, class browsing... I prefer to turn most of this off: my wxDevCpp sometimes hangs up trying to help me :)

The main (no pun intended) problem would be if it tried to compile in the middle of me writing a function. I would stop to think, and then it would spit out a block of errors at me.

Quote:

---

The main (no pun intended) problem would be if it tried to compile in the middle of me writing a function. I would stop to think, and then it would spit out a block of errors at me.

---

Quote:

---

Not sure about it. Most of the time the code would be "incomplete", unclosed braces, unfinished statements...

---

Quote:

---

You'd need some heuristic to spot when the user had stopped typing otherwise it would just nag you to death with every character you typed.

---

As I explained in my original post, this shouldn't be a problem. The compiler should be unobtrusive and polite, like syntax colouring. The code could be coloured to point out syntax errors etc as you type. If you stop typing for a second, and there are no current syntax errors, then the compiler would start silently, constantly updating the various columns to show its progress.

You're still thinking of the compilation process being something which spits out streams of error messages. What I had in mind was a very dynamic/interactive process.

Code which is incomplete would be coloured to show that it contains syntax errors.
Code with warnings might be underlined, and the warning would be shown when you move the cursor to that line.
Code with errors would be another colour, and would go back to the correct colour when the error is fixed. - Why wait until I press 'compile' to tell me about these things.

My PC is 3GHz. !Three Gigahertz! We've become so complacent about computer speeds, we forget that a PC might trivially be able to spare a billion instructions every second. When I'm writing code, is it really too much to ask that my PC spare some time to help me out, instead of just wasting 200W of power waiting for me to press another key?

Quote:

---

> - How many instruction cycles does each line take to perform.
A totally meaningless metric IMO. You should be focussing on things which matter, and which the compiler is oblivious of, like the Big-O complexity of the algorithms you choose.

---

I guess I should explain that I had this idea while I was writing firmare for our robots (http://www.shadowrobot.com). As in much microcontroller code, time complexity is never an issue. There are no sorting, searching, or massive data structures to deal with, just lots of linear, real-time critical code. In which case it's very important to know that you're not accidently setting off the creations of large temporaries etc (this is especially true in C++).

Also, when writing firmware for portable devices, the number of instructions taken has a direct effect on battery life. And in a battery life competitive market, that is a *very meaningful* metric. When I wrote the firmware for a digital watch recently, moving from C to assembler increased the battery life of the watch from 6 months to 1.5 years!

Hugo

Perhaps, but my good old compiler works fine. All that color and underling would honestly get annoying after a while. Maybe you would be able to turn this off?

If you people want to see the described scenario in action, check out Eclipse's Java environment or Visual Studio's C#. They both do very, very well on this. (Eclipse even a little better last time I checked, because it's smarter about offering corrections for the errors.)
It does not get annoying; it's in fact very helpful. (Unless it's implemented in the way of VB6. Now that was annoying.)

The problem with C (and C++ even more so) is include files. It's an awful lot of code that might need to be checked and re-checked all the time.

Eclipse's compile as you type stuff is awesome, I found it pretty helpful, though at times it was annoying, more often than not it helped me.

Quote:

---

check out Eclipse's Java environment or Visual Studio's C#

---

Many thanks. I'm very excited to know I'm not the only one in the world who believes in this!
Gonna check it out

Hugo

Who believes in what?

This compile-as-you-type thing is funny and fancy, but I don't think it's very useful.

it would be a good feature if it could show the error while typing the code. but it annoyers me after a few try. cant type a code without error free at the first time. So every time there is a char missing a error or a colorful code pop up which spoils the intentions of writing the code.

ssharish2005

I reckon there's a bit of fuddyduddyness going on here. The fear of the new. Does anyone here find syntax colouring annoying? Or is it helpful?

Hugo

Aftter having worked with Eclipse quite a bit (my university is very java-oriented), I must say that the code completion/colouring/compiling as you type has never really annoyed me to the point to make me wish it were not there. It does make mistakes, every so often, but not enough to warrant taking it off. It's a good feature in my opinion.

If you are a competent programmer and know what you're doing, would you really want someone looking over your shoulder all the time saying "That's right. That's right. That's right. That's right. That's right..."? :rolleyes:

Yeah, but one could argue the same about doing math with calculators, or pretty much any process which is automated. If you're good at math, you shouldn't need a calculator. But who doesn't use a calculator ? I mean, computers were invented to do the tedious work for humans, like say...find syntax errors in C or Java code. I for one definitely appreciate that Eclipse does that for me.

And, of course, if you're a good coder, you'd figure that errors such as syntax errors would be avoided altogether.

But error is human...it doesn't exist for machines.

Hi
It's interesting that the one person here who has used a similar system says it's not annoying. And, yes, I would love to have the computer telling me all the time if I have got something wrong.

Quote:

---

If you are a competent programmer and know what you're doing

---

Humans make mistakes. You make it sound like a really good prgrammer never makes any. I have been programming for 20 years now, and I make mistakes all the time. Everything from simple spelling errors , and missing semicolons, to stupid things like if (a=b).

Why should the computer wait until I compile to tell me about things like that? Why not just be helpful and tell me now?

Hugo

I wouldn't be surprised as new heuristics are developed, processing power is increased and smarter people code compilers, that the future is in dynamic compilation.

One of the problems of modern major systems is exactly compilation times. Sometimes almost prohibitive to the point of coders trying to hack around the need to have to recompile, or deciding to delay maintenance tasks.

Somewhat similar techniques are used already like JIT compiling that puts a part of the compilation burden on the application user. Although the stress is in improving application performance, not minimizing compilation times, there is no denying compilation into bytecode is simpler than into machine-code. For one, some optimization techniques can be left out of the initial compilation process.

If you ask me, you bet I would like to have my files being compiled "as I type" (loosely speaking of course. Some in here seem to be taking this too literaly).

I think it's obvious to anyone who gives a little thought to this that it would be a wonderful weapon (and a job savior on the extreme cases).

Does anyone really believe the opposite? and Why?

> One of the problems of modern major systems is exactly compilation times
Compiling individual source files takes almost no time at all if you've made a decent enough job of modularising your code and setting up your project.
If you have a
#include <everything.h>
and it keeps changing, causing the whole system to be recompiled (like what can happen with poorly setup precompiled headers), then you have a problem with your development strategy which software isn't going to fix.

I'll just stick with pressing ctrl-f7 every so often to save and compile the current file, and deal with any issues which might be present.

Syntax highlighting - OK I suppose, it just about works reliably enough after about 10 years of development.
Auto completion - I can type faster than that even on a fast machine. It's about half way between annoying and useful. That's if it has enough sense to pick the right context. By the time I've finished with the alt-ctrl-shift magic to make it do the right thing, I could have typed it in.

When you're writing in Word, do you slavishly pay any attention at all to all the spelling and style nags whilst you're writing, or do you just forge ahead to get everything written "first draft", then go back and start fixing things up.

I can hardly wait for the "My IDE won't let me type in any more code" support calls :rolleyes:

> I reckon there's a bit of fuddyduddyness going on here. The fear of the new
Or more likely, just see the smoke and mirrors for what it is.
Looks pretty, but is it actually solving any real problems?

No ones stopping you from implementing it yourself. Isn't that why you're here, to validate your big idea?

You asked for opinions, you got 'em.

To me, it will be nothing more than another set of training wheels on a bicycle. Yes I suppose showing syntax errors to "hunt and peck" noobs might be worth something.
But for the pro's, it had better do something pretty darn useful otherwise it will just get turned off!.

I've used Java and Eclipse, and I love the compile-as-you-code feature. It really is a time-saver. For best results, use a good development machine.

Hi Salem,

Thanks for the opinions :)

Quote:

---

Syntax highlighting - OK I suppose, it just about works reliably enough after about 10 years of development.

---

Huh? I saw it working just fine many years ago on our old 086 in Turbo Pascal.

Quote:

---

Auto completion - I can type faster than that even on a fast machine. It's about half way between annoying and useful.

---

Agreed.

Quote:

---

When you're writing in Word, do you slavishly pay any attention at all to all the spelling and style nags whilst you're writing, or do you just forge ahead to get everything written "first draft", then go back and start fixing things up.

---

A: Yes. And
B: It's a completely different context. I can personally understand a misspelt word, but my compiler will not tolerate it in the slightest.

Quote:

---

I can hardly wait for the "My IDE won't let me type in any more code" support calls

---

I don't understand how you get from Compile As You Type to that. But it's really not what I had in mind. The idea is that the computer should help you in any way it can, and in a non-irritating way. So, I'm not talking about pop-up messages you you have to click on, and not talking about the irritating paperclip.

What I do mean is that, if the computer could feasibly see an error, which I have missed, why should it sit there smug as a bug, waiting until I compile? Why not tell me now? Especially if it's wasting billions of instructions by the second doing nothing.

At the moment, the computer is a little bit like one of those horrible jobs-worth people at an embassy, who watches you fill in a form, then sends you a letter two weeks later saying you've filled it in incorrectly and will have to come back to try again.

Quote:

---

No ones stopping you from implementing it yourself. Isn't that why you're here, to validate your big idea?

---

It's something I would like to try. But I'm in the middle of validating several of my other big ideas, and I shouldn't really be taking on any new ones. Especially ones outside of my expertise. What I was hoping was for someone else to exclaim "What a good idea, I'll implement it myself" - then I could reap the benefits of someone else's hard work.

Quote:

---

But for the pro's, it had better do something pretty darn useful otherwise it will just get turned off!.

---

Well, as someone who does this professionally, I do find myself wanting this every time I see this:

Syntax error: (373) missing semicolon
Build Failed, 1 errors, 0 warnings


(Seriously, you dumb computer. You couldn't have told me that ages ago??)

Hugo

Quote:

---

Originally Posted by Wraithan

Eclipse's compile as you type stuff is awesome, I found it pretty helpful, though at times it was annoying, more often than not it helped me.

---

yeah, rather than spitting out a block full of errors you get non-intrusive underlines where your code is incomplete. Works with the CDT as well.

> Huh? I saw it working just fine many years ago on our old 086 in Turbo Pascal.

Well, for one I would like for code completion to go one step further and start coloring based on scope. swap() and MyClass::swap() are two very different things.

> Compiling individual source files takes almost no time at all if you've made a decent enough job of modularising your code and setting up your project.

The easy argument. The "if you had done it right you wouldn't this" type of argument. Unfortunately, the real world out there is more full of "I did it wrong and now its either too late or too expensive to fix it" argument.

Quote:

---

Unfortunately, the real world out there is more full of "I did it wrong and now its either too late or too expensive to fix it" argument.

---

I agree. There's too much fantasy idealism in the computer science world. Too much talk about Big-O, when in the real world, it's frequently irrelevant. And too much about "doing it properly", when in the real world, you're dealing with a 15 year old system that you didn't start, and are now having to deal with.

The answer from some programmers to many problems seems to be: "well you should just be a better person".

Quote:

---

yeah, rather than spitting out a block full of errors you get non-intrusive underlines where your code is incomplete.

---

Great, this is exactly what I'm talking about. Now, who fancies implementing it?

Hugo

> Great, this is exactly what I'm talking about. Now, who fancies implementing it?

But that has little to do with a possible compile-as-you-type feature. I thought (and that has been my understanding from the start of this thread) that the general idea was to speed up the compilation process.

What is being discussed instead is a context-sensitive parser that can detect code errors as you type. Not that I don't see anything wrong with that. I just don't see how that fits on a compilation discussion.

It would also be highly tied to the editor interface. I'm not sure how it could be easily integrated into an existing IDE without the makers of the IDE implementing it themselves.

Quote:

---

But that has little to do with a possible compile-as-you-type feature. I thought (and that has been my understanding from the start of this thread) that the general idea was to speed up the compilation process.

---

Well, the original idea of Compile-As-You-Type (and also Lint-as-you-type) was twofold. One, to speed up the process, but also to try to provide the user with the information gained from this process as soon as possible, using things like syntax colouring, underlining, and un-obtrusive messages relating to the code under the cursor.

For example, the user might as well be told sooner, rather than later that they have missed a semicolon, written if(a=b), or done something else stupid.

As well as code errors, the user can also be told about other fruits of the compilation process. Admittedly, these may only apply to people writing very time-critical code, e.g. on microcontrollers. But I think they would provide other valuable insights to what's going on under the hood, especially in C++, where there a lot of gotchas. I'm often not 100% sure if my compiler is creating a tempoary or not, and I have to go digging in the asm output.

I think it would be very useful to see the results of the first pass. For example, exactly what sequence of events happens when I do:

a = b->f() + c;

What temporaries were created? Were any constructors called etc? And what about the optimisation? Did that line optimise nicely? what if I try this instead:

a = b->f();
a += c;

Does that look better?


I know, I know. If I were a super-geek, I'd just know all this stuff off the top of my head. Perhaps 5% of programmers are good enough to really know this stuff. Maybe 20% are pretty good, but have a lot to learn about the results of their code. There are probably loads of mediocre programmers around. As well as being useful, compile-as-you-type could help us programmers learn what's really going on when we program. I keep bothering my guru friends with questions that could easily have been answered by the compiler, if it just knew how to tell me.


Hugo

Quote:

---

It would also be highly tied to the editor interface. I'm not sure how it could be easily integrated into an existing IDE without the makers of the IDE implementing it themselves

---

A good point. I'd wondered about this, and I think it's a hard question. Here are two possibilities:

1: The compilers and IDEs could agree on a standard file format for communicating.
2: Compilers could be loaded into memory, and passed code through standardised API calls.

But, yes, there are hurdles to overcome.

Hugo

> What temporaries were created? Were any constructors called etc? And what about the optimisation? Did that line optimise nicely?

Hmm... the language specification answer all those questions except the last. And the problem of the last is that you can't expect to have trustworthy results. On the other hand, compilers these days are smart enough to not give you many options regarding optimization. I understood the point of your example. It was meant just as an illustration. But the problem is that, the compiler will not care with such small changes. It will optimize equally. Most optimization decisions are taken at a more complex level involving a larger array of code and the context in which it is being evaluated.

What I was expecting this conversation was all about, was dynamic compilation models for C++ (akin to those existing for other programming languages). I found interesting the concept of my file being compiled as I type (which I don't think any language supports) into perhaps bytecode, considerably speeding the building process once I hit the button.

Quote:

---

Hmm... the language specification answer all those questions except the last.

---

Aah, the old "RTFM". In this case, the manual is more than 400 pages long. I'd be pretty impressed with anyone who could answer any such question I had about the language.

It's best to ask an expert, and what better expert than the compiler itself? Compare:

"compiler what happens if I do this ... or this ... thanks"

with

"hmm, what do I have to look up, read and interpret to find out if this ... might be better than this ... ?"


I partly agree about the compiler being so good at optimising. The day I threw away my Pentium assembler datasheet and stopped writing Pentium optimised asm was the day my compiled totally shamed me in a speed contest. I spent the week perfecting my inner loop, re-ordering code, calculating cycle times, and measuring them to check. For a laugh, I decided to see how much faster it was than the original C code. Guess what, the C was faster :(.

I don't have an intimate knowledge of compilers, so I could easily be wrong about this, but I was under the impression that the compiler can't always do the optimisation you might expect. For example when working with pointers. Sometimes the compiler simply can't know you're not doing something daft with the pointers which would mess up its optimisation.


Hugo

Rocketmagnet, you might be interested in seeing these comments on a similar feature discussed at the community forum of SlickEdit, a nice text editor, that has support for this feature in Java but not C++: http://community.slickedit.com/index...sg2777#msg2777

Very interesting reading.

I went the extra mile and bought SlickEdit recently. I did experience the "refactoring on malformed code" issue.

However, while I see the point of the article there is one thing I can probably see implemented in the future, Code Insight perhaps being one of the pioneers; syntax errors being dynamically flagged.

While still complex I would assume it would be doable to have a parser built around the language grammar only.

Webmaster,

many thanks. That was a very interesting read. I am pleased to know that other people are already thinking about this problem, and actively tackling it. Really, that is all I wanted to know.

One day I will have live compilation. I am happy.

Hugo

Hi guys,
sorry to drag this topic up again, but I was reading this on another forum, and figured it was an example of what I was talking about:

http://direct.forum.microchip.com/tm.aspx?m=207198


Ignore all the C vs ASM arguments :) It shows that it can sometimes be quite surprising what code is generated by the compiler. In this case (and in others I'm sure) making some changes to the C produced *much* better ASM.

I suspect (but can't prove) that much of the "just write it and trust the compiler to do it perfectly" is too optimistic. We can help our compiler produce better code, we just need to close that feedback loop.

Hugo