3 ms·

Compiling... it is a terrible UX and interruption of flow. For years at work I stuck strictly to dynamic/interpretted languages as no compiled language was wort

Compiling... it is a terrible UX and interruption of flow. For years at work I stuck strictly to dynamic/interpretted languages as no compiled language was worth using as they all killed productivity with their terrible compile times. Waiting even seconds for something to compile kicks me out of the zone and I have lost context and must re-orient to make sense of the output. I truly don't understand why developers put up with the stupidly slow compile times other than having no choice. In a time with such an emphasis placed on user experience why do developers get such a shit set of UX choices?

arinlen 4y ago
> Compiling... it is a terrible UX and interruption of flow. Compiling a project is only a nuisance if you don't design it around incremental builds and modularity. Otherwise the only thing your build system has to do is to build the files you actually touch, and link the remaining downstream subprojects that depend on it. One of the first things I don when starting to work on new C++ projects is check build times, and if rebuild times are noticeable when rebuilding subprojects then I determine what can be done to let that cease to be an issue. More often than not, all it takes to get back decent incremental build times is minimizing interfaces, refactoring some includes with interface segregation, peel off submodules from largeish modules, and that's it.
ivan_gammel 4y ago
1. There exists incremental compilation which reduces waiting time to run a unit test to a bare minimum. 2. There exists a whole set of latencies in deployment beyond compilation that also apply to interpreted languages. 3. Developer productivity is not measured in lines of code, but in delivered business value and as such is influenced by many other factors beyond how much time you waste on context switching during compilation. That one is usually pretty minor one: you are the first person in my 25 years of career in IT, who mentions this. Maybe you have some specifics in your field of work where it becomes important, but majority of the industry doesn’t think of it too much (and there is incremental compilation).
DayDollar 4y ago
It makes you wish you could perform basically a threaded taks, compile this, execute it, with these parameters or mouseclicks, then produce the results and offer to jump to the last place in code you changed for this. Parallel builds with makros as afterthought and conclusions to get you back up to speed once they are done
ivanche 4y ago
> I truly don't understand why developers put up with the stupidly slow compile times other than having no choice My money is on the fact that execution speed of a program written in compiled language will run circles around equivalent program in an interpreted language.
- _ph_ 4y ago
  Which is true, but doesn't automatically mean that most of the code has to be developed in that compiled language. There is a reason why Python is a popular language for machine learning: the computation is done in optimized native libraries, but the logic can be developed in a more interactive language without a relevant performance penalty. This also applies to a large amount of other problems, splitting the computation between a slower "high level language" which is suitable for rapid development and low level libraries in a fast compiled language is a good solution. And of course, you could have fast compiling languages which allow interactive development - just naming Common Lisp as one. You can recompile individual functions witout rebuilding the executable. This could be achived with many languages, but unfortunately it seems that no one bothered to build such systems.

arinlen 4y ago

> Compiling... it is a terrible UX and interruption of flow. Compiling a project is only a nuisance if you don't design it around incremental builds and modularity. Otherwise the only thing your build system has to do is to build the files you actually touch, and link the remaining downstream subprojects that depend on it. One of the first things I don when starting to work on new C++ projects is check build times, and if rebuild times are noticeable when rebuilding subprojects then I determine what can be done to let that cease to be an issue. More often than not, all it takes to get back decent incremental build times is minimizing interfaces, refactoring some includes with interface segregation, peel off submodules from largeish modules, and that's it.

ivan_gammel 4y ago

1. There exists incremental compilation which reduces waiting time to run a unit test to a bare minimum. 2. There exists a whole set of latencies in deployment beyond compilation that also apply to interpreted languages. 3. Developer productivity is not measured in lines of code, but in delivered business value and as such is influenced by many other factors beyond how much time you waste on context switching during compilation. That one is usually pretty minor one: you are the first person in my 25 years of career in IT, who mentions this. Maybe you have some specifics in your field of work where it becomes important, but majority of the industry doesn’t think of it too much (and there is incremental compilation).

DayDollar 4y ago

It makes you wish you could perform basically a threaded taks, compile this, execute it, with these parameters or mouseclicks, then produce the results and offer to jump to the last place in code you changed for this. Parallel builds with makros as afterthought and conclusions to get you back up to speed once they are done

ivanche 4y ago

> I truly don't understand why developers put up with the stupidly slow compile times other than having no choice My money is on the fact that execution speed of a program written in compiled language will run circles around equivalent program in an interpreted language.

_ph_ 4y ago
Which is true, but doesn't automatically mean that most of the code has to be developed in that compiled language. There is a reason why Python is a popular language for machine learning: the computation is done in optimized native libraries, but the logic can be developed in a more interactive language without a relevant performance penalty. This also applies to a large amount of other problems, splitting the computation between a slower "high level language" which is suitable for rapid development and low level libraries in a fast compiled language is a good solution. And of course, you could have fast compiling languages which allow interactive development - just naming Common Lisp as one. You can recompile individual functions witout rebuilding the executable. This could be achived with many languages, but unfortunately it seems that no one bothered to build such systems.