Re: Why doesn't C# allow incremental compilation like Java?

Andy <andyj@xxxxxxxxxxxxxxxxxx> wrote:
On Apr 24, 12:04 pm, "Jon Skeet [C# MVP]" <s...@xxxxxxxxx> wrote:
The point is that by keeping each class in its own file, you only need
to touch the files which have changed and any dependencies. You don't
need to rebuild the larger jar files - whereas you *do* have to build
the full assembly in .NET. (Yes, using modules would help this, but
it's a pain.)

Ok, but I haven't had .Net project compiles take a huge amount of
time.

It depends on what you mean by "a huge amount of time". To me, 10
seconds is enough to be a distraction.

I gather it slows things down significantly with larger projects
though - or at least did at one point. Either way, there's a
psychological difference between "I'll trust that the as-you-type
compiler has spotted all the errors" and "The code is actually built
and can be run, and I have no errors".

Are you talking about intellisense or the Vb.Net background compiler?
The former seems to eliminate 99% of compile errors to me. I haven't
used the latter, but I understand it DOES compile using vbc as you
type.

Right. Shame it's still VB.NET ;)

Everything *will* have been built though. That's the point - it's
incremental.
(Actually, Eclipse will let you run code even if you've still got
compilation errors - you'll get a runtime error when you enter the
method or type that failed to compile. It warns you on launch, of
course.)

I see. I'm not sure that running a program even with compile errors
is useful though.

Rarely, indeed.

I don't necessarily test every single line change, but I try to test
every functional change - and rerunning the unit tests very frequently
helps with that.

As do I. I typically have to wait longer for NUnit to reload the
assemblies than I do for the compiler though.

Well, that's effectively part of the cycle, possibly again due to the
way that .NET assemblies work (as well as due to the lack of tight
integration between VS and NUnit).

TDD is all about making small changes and making sure they work. If
you're not a TDD fan, fine - but please don't assume that just because
a relatively slow compile cycle doesn't hurt *your* productivity, it
doesn't hurt that of other people.

Actually I do like TDD; its just that VS lacking background /
incremental hasn't made an impact on how often I can test.

I really don't mean to be patronising (and I know perfectly well how
patronising this sounds) but it's easy to say that something doesn't
have an effect if you've never been without it. I didn't realise quite
how useful closures could be until I started working in a language
which supported them really well.

Actual background compilation, or just background error checking?
There's a big difference between the two. (Besides, I far prefer the
C# language to VB.NET.)

From what I understand, actual background compilation, as many
Vb.Netters complain that things like invalid casts aren't caught in C#
until they compile, but Vb.Net catches all these errors almost
immediately.

That doesn't mean it's actually being compiled - just error checked.
The important thing is whether or not it's constantly updating the
assemblies. What does it still need to do when you hit build?

I can't fault you for perfering C# over Vb though. :-)
FWIW, I have heard that the Orcas will support C# background
compilation ala Vb.Net.

I'll have a look at what beta 1 does on my virtual PC.

That's because it's not an incremental compiler, as I say. In Eclipse,
if I change one method, even in a *giant* class, IIRC only that method
will actually be recompiled (and the whole class file regenerated). If
I change the method signature, other things which depend on it will be
recompiled. It doesn't need to recompile whole projects - only
dependencies.

Understood, but again, I haven't seen many places where compiling
takes all that long at all. 1 - 2 seconds is typical, except for my
forms application, but that's also adding in resources and such.

As I say, it's about 10 seconds on the solutions I'm working on at the
moment, and that's a lot longer than with a much bigger project in
Eclipse.

My machine is reasonably nippy, but it still takes 10 seconds to
compile the solution I'm largely working with at the moment.

A forms application or straight class library? My forms application
takes a bit of time, mostly because of all the resources which get
embedded. Of course I'm planning on moving most of the forms to
library assemblies though, both to speed project compile time and
speed the loading of my application.

Class libraries and forms, or class libraries and web services,
depending on the solution.

The fact that you're thinking of changing the design of your
application even *partly* due to compilation time means that it *is*
significant to you though.

So it's a pain in the neck, particularly for TDD developers. Have you
used Eclipse for significant projects? It's sometimes hard to
appreciate what a difference such features can make without having
experienced them for yourself.

I haven't noticed a problem in the teams I've been in (solo now
though). I haven't used Eclipse, but I have used IDEs which do
incremental compiling. If the Orcas will have background compilation
for C# as I've heard, I guess I'll see then if it makes a difference.

Possibly - depending on what it really does.

I often talk about features like "Open Type" in Eclipse, and people
who haven't used Eclipse say they can easily live without it. I
haven't yet met anyone who *has* used Eclipse for significant periods
who doesn't agree that it would be a *huge* benefit to have in VS2005.
(Fortunately, ReSharper provides it. Shame it's not in VS itself
though.)

I haven't used resharper yet, although I understand how much of a
benefit that functionality will provide. I'm hoping to purchase
Resharper soon.

It's lovely from what I've experienced - although I think it does make
the editor slightly less responsive. The trade-off is worth it for me.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: dependency scanner
    ... Ivy gave us a leg up on analyzing dependencies. ... Historically, this is done with configure, though ant ... packages that won't compile need to be skipped. ...
    (comp.lang.java.programmer)
  • Re: How would you handle this error 430 automation error?
    ... Next, open each project separately, set compatibility to binary and compile them. ... Store the dlls in the one output folder and add a reference to those dlls as needed in the toher projects instead of project references or project groups. ... dependencies and notice that my Project references are not persisting. ...
    (microsoft.public.vb.general.discussion)
  • Re: Im getting frustrated and angry!
    ... were abandoned when they made Java. ... Java allows circular dependencies which can only be ... Only if the "object files" don't exist at compile time. ... But why the attack on Ant? ...
    (comp.lang.java.help)
  • Re: Delphi 2005 - Is it going to be thanks for having wasted my time?
    ... > since you were not able to compile and it runs on another machine, ... I do agre that there must be some missing/incompatible dependencies. ... Converting a D7 Project to it... ... sure that uninstalling D2005 will really solve the problem (I cannot rely on ...
    (borland.public.delphi.non-technical)
  • Re: Batch compiling Fujitsu COBOL
    ... need to provide a script or Windows Console that will let a series of ... In fact the project generates a makefile and then runs this. ... There won't be any dependencies between these modules, ... thought was to simply compile and link them, ...
    (comp.lang.cobol)