Compiler time versus programmer time

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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....

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.....

Answer 8

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 :/)

Answer 9

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.

Answer 10

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.