| GeDaMo | Turbo Pascal :P |
| rindolf | GeDaMo: where? |
| Aruseus | many modern language features are slow to compile. rust has that problem too |
| InPhase | Fast compilation, fast development, fast runtime. Choose 2. |
| rindolf | InPhase: heh |
| rindolf | InPhase: 2 or less |
| GeDaMo | rindolf: that was to beaky's "instant compile speeds" |
| rindolf | GeDaMo: ah |
| InPhase | There's a fundamental reason one ends up with that trade-off of choosing 2. Turning complicated ideas into fast instructions is complicated. And that complexity has to eventually be processed somewhere, either in the head of the programmer, by the compiler, or as a runtime cost. |
| rindolf | InPhase: interesting |
| _W_ | most slow compilers are slow, not because it is necessary, but simply because making it fast hasn't been a priority |
| InPhase | _W_: Well the major C++ compiler designers, and the C++ language committee, reportedly spent effort trying to significantly speed up compilation in recent years. But I think we can see there were not many meaningful results from those efforts. They've had trouble finding ways that don't majorly break the features that make the C++ runtime fast. |
| xeno | if I don't learn how to read a file line by line in Swift, this one will also be slow, memory consuming or unstable ;/ |
| xeno | :/ |
| _W_ | well C++ compilation is already relatively fast, so it makes sense that there wouldn't be a lot to gain |
| jeaye | There have been huge results in the reduction of TMP compilation speeds, thanks to pressure from the clang/llvm world. |
| jeaye | Templates, of course, being the biggest practical slowdown in C++ compilation, that's a big win. |
| rindolf | jeaye: what is TMP? |
| jeaye | rindolf: Template MetaProgramming |
| _W_ | I'd go so far as to say that there's more of a correlation between how young a language is and how slow its compilation is, than between complexity of language and how slow the compilation is |
| rindolf | jeaye: ah |
| SlashLife | jeaye: And to be fair, I don't think it was obvious 20-25 years ago how big TMP would become. |
| rindolf | _W_: some languages started off with fast compilers |
| _W_ | yes, it's not a hard rule by any means |
| rindolf | _W_: and gcc got slower - https://github.com/shlomif/fc-solve/blob/master/fc-solve/docs/gcc-2.95.txt |
| gehn | fast in terms of time to compile? or fast in terms of the performance of the resulting executable? |
| _W_ | gehn: time spent in compilation was what was being discussed |
| _W_ | (and contrasted up against speed of development and speed of execution) |
| gehn | ah |
| xeno | would guess most languages started off with fast compilers that got slower |
| _W_ | probably, at least up to some level of complexity and features |
| velco | speed of development is subjective, its place is not at all with the other too |
| velco | two* |
| gehn | compile time is certainly something that impacts dev time |
| gehn | at least in my experience |
| gehn | I like C++, but I don't love everything about it. it would be nice if we had significantly faster C++ compile times |
| velco | in my experience, it does impact time taken only when not writing code |
| gehn | well, testing the code written is a pretty important and continuous process of my development |
| gehn | I have unit tests, but those don't cover everything |
| gehn | and GUIs are often more difficult to test at all |
| gehn | especially difficult to test things like the result of a render operation on an OpenGL context |
| gehn | so, needing to wait a significant amount of time (upwards of a minute or several) just to test some fairly simple change can spiral time-to-dev costs |
| rindolf | gehn: yes |
| rindolf | gehn: using ccache has changed my life |
| velco | what percentage of this time is spent compiling? and what is spent analysing the issue, coming up with a solution, implementing the solution, writing a test, code review, running the test? |
| gehn | rindolf, is that different from how a Makefile or whatever (or a cmake generated project) should be able to detect which files need compile and which don't? |
| gehn | velco, like I said, it's not always feasible to write a test for everything |
| rindolf | gehn: sometimes it is |
| gehn | I don't have an answer as to exact percentage, but on many days I suspect I spend almost 50% of my total time waiting for compiles |
| rindolf | gehn: if you did “make clean” for example |
| velco | gehn: Sure. Why do you feel compelled to tell this to me? |
| gehn | that might be an overestimate, but it's not far away |
| Aruseus | gehn, if you have a file b that depends on a. if you change a, then you'll need to recompile b even if you didn't change it at all. so probably not everything will change |
| gehn | velco, were you not asking the percentage question as a response to what I had said? |
| rindolf | obxkcd: https://www.explainxkcd.com/wiki/index.php/303:_Compiling |
| gehn | unit tests help a lot |
| velco | gehn: yes, and if you don't write test, my list potentially incomplete list of things allows for a 0 percent |
| gehn | because they compile much faster as each unit is typically decoupled from the entire app |
| velco | gehn: sound like you need to rethink your workflow |
| gehn | velco, sorry I don't understand what you just said |
| gehn | velco, maybe, but I'm not sure what to change about said workflow |
| velco | gehn: I have not put a restriction of non-zero time on any particular item in my list, so I don't understand why do you need to tell me some of these may take zero time |
| gehn | so, it's great to write unit tests, and I write a lot of them, but when doing more GUI centric integration centric work - a workflow centered around unit tests isn't viable |
| gehn | velco, I seriously still don't understand what you're saying? |
| gehn | when did I say anything about zero time? |
| rindolf | gehn: there is also https://en.wikipedia.org/wiki/Distcc |
| gehn | velco, yes, what about that statement? |
| velco | I have found that a a simple change incurs less than 2 minutes of building of a large c++ project, most of it spent in linking |
| gehn | 2 minutes is still kind of a lot |
| gehn | I tend to not write tons of code before recompiling and testing |
| gehn | so I might spend anywhere from 30s to 5 minutes on a few lines, and then I usually want to test again before moving on |
| gehn | with unit tests where compilation and runtime is usually < 20-30s that's mostly not an issue |
| gehn | but when compile times start to rise above the minute-or-several mark, then this begins to become more of a problematic issue |
| velco | why run compilation and test so often? |
| gehn | I think the answer to that should be fairly clear to many if not most devs |
| velco | I run it when I have written a committable amount of code |
| exio4_noznc | velco: fail early |
| gehn | the more lines of code you write the more chance that you've made a mistake, and the further you go without checking your work, the more likely it is you'll end up in a very difficult to debug situation that consumes more time than it should |
| velco | exio4_noznc: it looks to me that some fail even before starting :P |
| gde33 | shouldn't make mistakes |
| gehn | linting helps with that a lot |
| gehn | but still doesn't prevent logic or runtime errors |
| velco | gehn: that does not come form my experience; it is very rare I have an error in each line I write |
| gehn | so I guess velco is a near god-like perfect programmer |
| velco | in fact, most are correct; hence, testing them in isolation proves pointless |
| gehn | for the rest of us mortals however... |
| gehn | I don't test lines in isolation |