Hacker News Reader

Comment by coldtea | Hacker News Reader

>I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous.

Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.

View on HN

He is not talking about a "programming language", he is talking about "programming language tooling". So yes, compile time is an valid and interesting aspect to judge a programming language tooling ever since the beginning.

> Since when was compile time an interesting aspect to judge a programming language?

Since compilers were dog slow.

When using irb or lisp or smalltalk, my productivity is off the charts compared with C++, in no small part to the compile time.

Where do you think the Turbo in Turbo Pascal comes from?

Have you ever worked on a large-scale C++ project?

No, but then again, as I wrote in a comment just above that one:

"I don't think most teams outside of Google and some C++ or Scala shops have had any issue with "long compile times" for that to have been a major factor."

Actually, the biggest problems with large-scale C++ projects for me have been "long compile times for fully optimized builds" and "long linking times", neither of which Go 6g/8g solves.

Put another way, much of the problem is "modern compiler optimization takes a long time". Go's solution was "remove the modern optimizer". That doesn't actually solve my problem.

Reply on news.ycombinator.com