I want to briefly discuss managed or interpreted languages. It's said that they're worth developing in, because the CPU time is worth less than the programmer time required to develop in a faster language. I'm curious if the same thing could be said for the compiler. If I had some mythical compiler that took four times as long to compile as, say, C#, but took half the time to program with, would that be an advantage or a disadvantage? Is programmer time worth more than compiler time?

  • What is your ratio of compile to program time? – JeffO Jul 16 '11 at 22:48
  • It's a hypothetical question - I don't have any ratios at all, they would likely be impossible to obtain even if I had the compiler in question. – DeadMG Jul 16 '11 at 22:52
  • Well... if you don't have this ratio, then the question can not be answered, because only knowing this ratio we can rationally (heh) answer it. – Mchl Jul 17 '11 at 9:33
  • 2
    Oh... and obligatory xkcd comic: xkcd.com/303 – Mchl Jul 17 '11 at 9:34

10 Answers 10


First off, compile time IS developer time--developers building and testing a system have o wait for the code to compile between each change in the code and their ability to unit test it.

That said, if the language makes it so that the developers can code things correctly with a time savings that offsets the time they sit waiting for it to compile, they probably won't mind all that much.

Also, the Moore's Law factor will decrease compile times over the long run, anyway.

| improve this answer | |
  • You can budget around lengthy compile times to take care of the other odious duties of a programmer. – JeffO Jul 16 '11 at 22:54
  • +1 for Moore's Law. Compile time is not anywhere near what it used to be and will only get shorter. – MaQleod Jul 17 '11 at 2:37
  • @Jeff: exactly. I worked on a system once where the compilation time for the whole of the source code to build the final executable was about 7 hours. Needless to say we got to be masters of incremental builds. But there was always odious crap to do when "the big one" had to be done. – quickly_now Jul 17 '11 at 6:03
  • 3
    Compiler time is not necessarily developer time. When the compiler takes a long time to run, the developer can find other things to do. We've got used to this idea because compile-times have got pretty short - too short to switch tasks. But then again, you need breaks during your working day anyway, even if it's just a few seconds to relax a few neurons, stare into space and relax your eyes etc. Usually, when you've just started a compile, you're about ready for one of those little breaks anyway. If it's too short, you'll just need more breaks later - or else you'll get less productive. – Steve314 Jul 17 '11 at 7:25
  • 1
    On average I probably compile every 30 to 60 seconds - that's how often I run my unit tests. If the compile takes more then a second or two it will destroy my flow completely. Second, remember that context switching is extremely costly. If you stop thinking about the problem and check your inbox, it will take you on average 20 minutes to get to where you were. – Torbjørn Jul 17 '11 at 11:53

I want to briefly discuss managed or interpreted languages.

You realize (I hope) that "managed" and "interpreted" are orthogonal concepts.

  • A managed language is one where the runtime system takes care of dynamic space management.

  • An interpreted language is one where the program is executed by an interpreter rather than by compiling to native code.

Also, interpreted versus non-interpreted is generally a language implementation issue.

Is programmer time worth more than compiler time?

In fact, compiler time IS programmer time. It is time that the programmer has to wait between making a change and testing the change. Indeed, this is one of the advantages of interpreted languages - the change / test cycle time is reduced compared with compiled languages.

The real trade-off is between programmer time and speed of the end product; e.g. the time that the end-user has to wait while the program executes. And that depends on both the chosen language (or more accurately, language implementation) AND on the application.

| improve this answer | |

XKCD Compiling

I'm a Java developer. The Eclipse IDE continuously compiles my code as I write it, so compiling does not take any noticeable time at all while I'm developing it.

| improve this answer | |
  • :) As soon as I saw the question I knew this comic had to turn up. – Bart Jul 17 '11 at 8:31
  • I was surprised nobody had posted it yet... ;-) – Jesper Jul 17 '11 at 9:52

I spend virtually zero time compiling compared to thinking or programming.

I use mainly Clojure, so when I am developing I usually have a running REPL that compiles individual expressions as I type them. Compile time is effectively instantaneous (at least, I've never noticed it.... you get the response pretty much instantaneously after you press enter)

So four times as much compile time in exchange for doubled development productivity would clearly be a win in my case. However, I'm not convinced such a programming language proposition exists. So it's a somewhat hypothetical argument....

| improve this answer | |

Cutting development effort in half across the board? What you propose is nothing less than the mythical silver bullet! So, yes, it would be a spectacularly worthwhile trade-off. Build time can always be gotten under control with faster machines, parallelisation, Moore's law etc. At the moment, developer effort per feature and quality is pretty much irreducible - even the best software methodologies have a hard time proving that they reduce it even by a small amount - and developer salaries are the bottleneck in software production.

| improve this answer | |
  • I'm not sure about developer salaries being the bottleneck. More people means more overheads - more time discussing/explaining etc, and not necessarily more productivity. The natural number of developers for a project probably depends more on the number of natural subdivisions of that project than on your salary budget. – Steve314 Jul 17 '11 at 8:50

If you had such a mythical compiler, I would put foward a business case to my boss to buy each developer a computer that was 4 times faster than we currently have. He would jump at the prospect of doubling the output of 30 developers by spending around $100K.

I am guessing you compiler really is mythical.....

| improve this answer | |

Well, developping in C++ I guess that I qualify for long compile-time :)

The truth is, although compile-time can indeed get important, there is much to be done to parallelize it (I work off a 24-core server, and we use distcc to pool them), therefore compiling the whole application is about 5/6 minutes despite its quite impressive size. Incremental builds are about 20/30 seconds (there is some load time for automated dependency checks).

On the other hand, the program takes about 1m/1m30 to load because of a whole lot of configuration happening during (and right after) DLL load.

As such, while I do feel crippled by a slow turn around (annoying when you want to test a quick fix), compile time is not even half the story.

If I used an interpreted language (say Python), I would probably lose more time because it would need to compile anyway (even though implicitly) and the load time would be much slower... (Well, and of course Python is not really multi-threaded so it would not be a good fit :/)

| improve this answer | |

Poor implementation aside, there are three things that make compilers slow:

  1. optimization - many good compilers take a lot of time to actually optimize the crap out of what looks like obvious imperative code. The advantage of this is, that you don't have to spend a lot of time performing trivial micro-optimization based on assumptions that might just as well be wrong, when the compiler often has far better heuristics and knowledge of the targeted platform than you do. Thus you can concentrate on writing clear code. That saves a lot of time while writing and even more while debugging.
  2. language features - there are many expensive language features. Overloading for example is one. Before you can call an overloaded method you need to perform a static type analysis at the call site. A problem a C compiler will not encounter for example. Static type systems in general are not without cost, but provide obvious benefits. Also generic programming can be quite expensive (especially something as expressive as C++ templates), as well as other kinds of meta-programming. So while it might take the compiler some time to understand what you mean to express and translate it to an executable form, you have the advantage of being able to express things a lot closer to your thoughts. You can write programs, that are significantly shorter and therefore easier to maintain.
  3. safety - many compilers (or build tools) perform static analysis beyond what is necessary to compile a program. Through all kinds of flow analysis and other techniques, they are able to pinpoint code sections that probably are mistakes and warn you accordingly. This allows to greatly diminish the potential of bugs and saves you long debugging time, that mostly consists on trying to reproduce some bug that happens quite rarely.

I think all of these are of great benefit. Personally, I dislike the idea of doing something, that a machine cannot only do for me, but probably do it even faster and better. I see no value in performing dull and repetitive tasks myself. This consumes a lot of time, introduces new sources of error and puts an unnecessary strain on me, keeping me from concentrating on more important aspects of programming.

| improve this answer | |
  • I dislike the idea that a compiler should spend huge amounts of time trying to figure out what a program is expected to do, every time it's compiled. Compilers should be expected to know more than programmers about which way of implementing something will be fastest when run under known conditions, but programmers will often know more about compilers about what conditions are most likely to occur; allowing a programmer to specify things that should be invariants, and have a compiler verify them, would seem a better approach than having an optimizer identify things it hopes are invariants. – supercat Jun 23 '15 at 21:15
  • @supercat I'm not saying programmers should not specify invariants. Of course they should. Simply because it makes it easier to reason about. The fact that it also makes it easier to compile is a nice side effect. – back2dos Jun 23 '15 at 21:38
  • I tend to believe that in a good language, small changes to a function's implementation should tend to cause similar changes in the generated code. If the fact that some particular parameter is never passed a value greater than 4 would allow some optimization, the question of whether the compiler performs that optimization should be determined by whether the code specifies that invariant. An analysis tool which can indicate "If the parameter will never need to exceed 4, adding XXX directive here would allow code to be faster" could be helpful, but having code depend too much on... – supercat Jun 23 '15 at 22:06
  • ...what inferences the compiler is able to make "unassisted" may easily result in a situation where a seemingly-trivial change to a program causes seemingly-unrelated parts to become five times as slower than they used to be for no apparent reason. – supercat Jun 23 '15 at 22:08
  • @supercat Your beliefs are yours to choose, but without explanation, they add very little value. I'm not even sure what you mean by "generated code". With your major interest in C# I suppose you are referring to something as CIL. But the fact is that with any decent JIT, the final machine code that actually gets executed can depend heavily on as little as different user input and doesn't even require implementation changes. That would make C# a bad language by your standards. In the end "programs must be written for people to read, and only incidentally for machines to execute". – back2dos Jun 23 '15 at 22:35

Performance doesn't matter in computing -- until it does, that is. And when performance does matter it can be the driving factor.

Performance is not a factor if this hypothetical language changes a 2 or 3 second compile time into ten seconds. As a programmer, you haven't lost mental context in that ten seconds. Performance is a huge factor if this hypothetical language changes an already unacceptable two hour build into a day-long build. This kind of "improvement" will drastically change how the team designs, programs, and tests. A from-scratch nightly build and test may no longer run over night. Programmers will lose mental context and suffer a productivity loss rather than a productivity gain.

Example: This might well happen when a product switches from a custom input file language to a scheme that uses python. SWIG is nice but it can add a huge build burden, easily making that hypothetical factor of four a reality.

| improve this answer | |

No right answer here.

Faster compilation tends to build a tendancy, in some programmers not all, of "lets just try this". Because trying is "cheap", ie fast, and so tinkering happens instead of thinking.

Slower compilation . turn around tends to lead to being very careful before compiling so that you don't waste time down the track. But it also tends to be frustrating because of the slow turn around, the lack of quick gratification, and the percetion that time is a-wasting.

In both cases there are perceptions (wasted time vs quick feedback) and different thought processes.

In both cases, the really good programmers don't really care - they plan their work, think before compiling anyhow, and generally know what they are doing and so avoid tinkering.

The less than really grand programmers can have their inadequacies masked by the faster compile / run cycle... they get caught out in the end by a lack on understanding anyhow - but it can take longer to uncover their weaknesses.

The whole thing about "cpu cycles are cheap" first materialised back when I was at Uni in the late 1980's - spouted off by some lecturer. EVERY SINGLE JOB I've had since then put that to the test and found it to be a lie.

CPU cycles almost always count for something somewhere: on embedded systems, poor or slow code means that the rocket won't fly straight or the washing machine over-fills. Web systems run out of steam and need more expensive hardware when there are too many connections. Business systems run for too long to to queries. And on and on it goes. As demands go up, software size and complexity goes up, processing performance goes up, demands go up... and on and on the cycle repeats.

In all these things there is a trade off, and it's usually not very obvious where it lies until you dig deep to look at things.

| improve this answer | |
  • 1
    First, whether it's you that rejects an idea or the compiler, it's still your idea that you thought of. Second, just because you said "let's just try this" doesn't automatically imply any less thought either before, during or after the build. Yes, there are some people who try to let their compiler do their thinking for them - but there are also smart people who don't waste their mental resources doing what the machine can do better. I may even reject ideas after the compiler says "looks OK to me" - having written the code, the build is the first chance you get to reflect on the result. – Steve314 Jul 17 '11 at 7:38
  • You might have missed the point - I'm having a go at the lazy programmer who does not want to stop and think - for these people, their laziness gets fed by quick compiles - they get an even quicker feedback by trying stuff, instead of by understanding stuff. Understanding is always better in the long run. – quickly_now Jul 17 '11 at 7:52
  • 1
    I could ponder for hours and be certain that what I do next is correct, or ponder for a couple of minutes, make a change and test to ensure that it does what I expected it to. Call me lazy and a bad programmer if you like, but unlike many of the contemprories, my products get out the door on time and on budget. – mattnz Jul 17 '11 at 9:10
  • My goodness, provocative comments here to try and show that THINKING IS GOOD clearly rub a lot of egos up the wrong way. Which perhaps actually proves my point! – quickly_now Jul 10 '14 at 2:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.