40 ms·
I meant the build button, of course you don't have to do a full rebuild every time, that would be insane. Did you honestly think Visual Studio or the cs compile
by henrikschroder 17y ago
I meant the build button, of course you don't have to do a full rebuild every time, that would be insane. Did you honestly think Visual Studio or the cs compiler is that retarded?
However, it doesn't change the fact that you still have to perform it. If you're changing a file that has a lot of dependencies, all of those have to be re-built, unlike if you're sitting in Eclipse coding Java, where you don't.
- prodigal_erik 17y agoThe only reason incremental compilation is possible in Java is that the language completely lacks abstractions like macros and overloading which can globally affect the meaning of existing code. I already spend more time reading and writing code than recompiling, so making recompiling faster by making the code more verbose, repetitive, and error-prone is not a tradeoff I'm happy about.
- eru 17y agoI don't see how macros should make everything depend on everything else. When you want to use a macro you (should) still need indicate somehow where it comes from.
- lincolnq 17y agoThey make compilation of the macro's clients depend on the implementation of the macro, and therefore those clients must be recompiled when the macro changes. In Java, there's no expectation that changing the implementation of a method in one java file would cause another java file to be recompiled.
- __david__ 17y agoBut if you add an parameter to a function then don't all the files that have calls to that function have to be recompiled (so that you can see the error)? I don't know Java so I'm assuming it's similar to other compilers. Please correct me if I'm wrong.
- eru 17y agoOr how about changing types? Javas weak type system should make it necessary to re-compile (and even change the sources).
- lincolnq 17y agoIf you change a parameter, then you are changing the interface, and it makes sense that that affects recompilation. Changing the type is an interesting one. If you change the backing class from one type to another, but you were using an interface to access it, then the Java compiler doesn't need to recompile that code -- the compiled InvokeInterface bytecode for that method invocation doesn't change. However -- I feel like I may have read this somewhere -- there are optimizations which might cause it to replace InvokeInterface with static invocations when it can determine at compile time what class is used. If that's the case, then it would have to recompile the client class too.
- eru 17y agoI was thinking about changing the type of a parameter and return type in parallel --- where the application only treats them as block boxes and just gives and takes those objects, but never looks at them.
- jrockway 17y agoI think this is wrong. Incremental rebuilds are supported just fine by languages other than Java. cabal does incremental rebuilds of Haskell (and Template Haskell) projects just fine. If you define every function in terms of a macro, and change that macro, though, of course you have to rebuild the whole project.
- bugmenot 17y agoActually, the default setup of MS Visual Studio build is quite retarded, because the build time grows with number of projects due to lots of temp file copying. But if you use a few large projects, the build time is big because an entire projects needs to be rebuilt (assembly level, not class level like in Java or object-level like in C)