Unfortunately it's somewhat out of date. While it does cover C# 2, it was published a year before C# 2.0 (and.NET 2.0) were released - which means it won't be accurate when it comes to things like boxing nullable types.
It also (for obvious reasons) doesn't cover C# 3 at all. But yes, it does look like an interesting book...
Re:Challenging?
on
Head First C#
·
· Score: 2, Insightful
C# 1 was quite a simple language. C# 2 added significant complexity (and power, don't get me wrong) and C# 3 has done the same again.
I wouldn't be without the benefits of C# 3, but it does take it away from the "pick it up easily in a week or so" category in my view.
Well, for a start that's clearly not true in this case - HFC# came out in November 2007. 8 months isn't a year.
However, if you want a review of a more recent book, Jim Holmes has submitted one for my own C# book (C# in Depth) which came out just a few months ago. It's in Firehose right now. Whether it makes it to the front page is a different matter, of course.
Parent is a somewhat confused post - it contains various facts, but also some misused terminology. I tend to be a bit pedantic when it comes to the terminology around runtime features vs language features vs libraries, as it's a source of frequent miscommunication.
There's two main versions of the.NET CLR (Runtime): 1.1, and 2.0..NET 1.1 runs on.NET CLR 1.1.NET 2.0 through to.NET 3.5 runs on.NET CLR 2.0
So far, so good.
Effectively,.NET 3.0 and 3.5 were language extensions on top of 2.0. They still execute ontop of the same CLR.
They weren't "language extensions"..NET 3.0 contains solely library extensions: WPF, WCF, Cardspace, Workflow Foundation, on top of.NET 2.0..NET 3.5 contains library extensions, primarily LINQ (in its various guises) and additions to the BCL (e.g. System.TimeZoneInfo). I believe there are ASP.NET and ADO.NET enhancements too, but I haven't looked into them..NET 3.5 also contains the compilers for C#3 and VB9. More on them in a minute.
It's also worth mentioning.NET 2.0SP1, which includes some changes and enhancements to the BCL, such as System.DateTimeOffset.
If memory serves, Mono has recently announced full feature compliance against.NET 1.1, and they're now targetting full feature compliance against.NET 2.0.
That doesn't mean.NET 3.5 apps won't run. It just means certain bits (such as LINQ, WPF, WCF, Anonymous Types, etc) are either not present or not completely implemented yet.
Anonymous types are a purely language feature. They don't need any support from the runtime or the libraries. In other words, you can compile a C# 3 app which uses anonymous types, and it will work on Mono (assuming there's nothing else missing, of course). Most C# 3 features fall into this category - they don't need library or runtime support.
WPF and WCF are libraries. No language changes are needed, although tooling to support XAML is useful, of course.
LINQ is a mixture of many elements. To use "out of process" queries you need an implementation of expression trees (and compiler support). To use LINQ to Objects you need an implementation of that, but it can be completely separate to the rest of the main platform libraries (see http://www.albahari.com/nutshell/linqbridge.html for example). You can use C# 3 query expressions with no runtime/library support, so long as you've got a C# 3 compiler and a type with suitable methods (or properties).
Last time I looked, mcs support for C# 3 features was somewhat lacking (which surprises me, as Mono had a released version of mcs with C# 2 feature support before.NET 2.0 was fully released, IIRC). However, you can build an app with the MS C# 3 compiler and run it against the Mono platform so long as you don't use any library functionality which isn't supported there. Asking VS2008 to target.NET 2.0 is a good starting point on that front. (It actually targets.NET 2.0SP1, so be careful...)
In either case, Silverlight/Moonlight are seperate from the.NET / Mono codebases. Yes, they have shared code, however since Silverlight 2.0 is a vastly cut down version of the.NET Framework.
This makes full feature compliance of Silverlight 2.0 by the Moonlight crowd that much easier, since the majority of the functionality that is used in Silverlight is already implemented in Mono
It's amazing what you can believe based on "general consensus". I've certainly heard "general consensus" that Java's dying, along with C, C++ and Ruby. Of course, every time I've heard a "general consensus" one way, there have been plenty of people claiming a "general consensus" the other way too, which kinda defeats the idea of consensus to start with.
I don't remember hearing that Python's dying, but maybe I've not been listening carefully enough.
It does make you wonder what people are going to be using in a couple of years' time, with all of these platforms and languages dying out...
A polished turd still reeks. Messy code is inefficient and prone to bugs..NET can be inconsistent with itself. For example, generic vs. non-generic data structures (e.g., lists, vectors, etc.) have different member functions. Why? Presumably because when they redesigned the collections for generics, they found some things they could improve on. Would you rather things didn't get improved?
.NET lacks the mandatory exception handling of Java. Rather than have the compiler complain that I'm not handling my errors, I have to sort through buckets of documentation. The reason for this? "We found too many Java developers were using empty catch statements." So the answer was to make shoddy exception handling easier and good error handling harder? I used to support checked exceptions. After significant time in both C# and Java, I now regard checked exceptions as a failed experiment. There are very few times when you should actually catch an exception without rethrowing it unless you're at some reasonable top level of the stack - and when you can genuinely handle it, you're likely to know that without the compiler telling you.
I hope these have been addressed but I doubt it. I hope C# never "gains" checked exceptions. Indeed, I hope Java might lose checked exceptions (which are only a compile-time feature, unenforced by the VM) at some point. It would simplify new features as well...
In general, C# and.NET are a breath of fresh air for those used to Win32. Compared to any of dozens of alternate languages and tools (e.g., Python, Ruby, Haskell, Java, etc.), it's stale fare. My guess is you haven't written too much C# 2 or 3. Compared with those, Java is the language which is going stale. The number of common patterns supported well by C# but not by Java has come as something of a blow to me recently, moving back to Java from C#.
I don't think there's anything "ulterior" about it. It's pretty obvious: if people are going to run open source software, MS would like them to be running it on Windows. It's therefore in their interests to help open source developers to get their stuff running on Windows - especially where it doesn't compete with any of their own products.
Sure, they may well not really want to help the Firefox or Open Office teams much, but if it's a choice between "PHP on Windows" or "PHP on Linux" I think it's obvious where Microsoft's interests lie.
There's nothing suspicious in that behaviour - it's perfectly plain in my view. Now, unless you count increasing Linux market share as an aim in and of itself, I find it hard to see how MS doing this is something to be dismal about.
Using a thread per client is a debatable technique. It's usually more efficient to have fewer threads, and use asynchronous IO, CSP etc to use those threads efficiently. There's less context switching, to start with, as well as lower memory usage. It's not a problem for relatively low usage servers, but if you've got 10,000 clients each making a web request which may take a while (in terms of wall-clock time, but not in terms of CPU) to process then you probably don't want 10,000 threads, each with a 1MB stack.
Asynchronous programming takes a while to get your head round, unfortunately.
Scala is one of the many languages I haven't got round to yet, but plan to at some point.
There's an interesting question of psychology though. I *suspect* that we're more likely to win people round to a functional way of thinking by gradually encouraging a functional style within a familiar imperative setting than by starting off with a "mainly functional" language which allows side-effects in some cases.
I say this as someone with a long history of imperative programming, who is now coming round to the functional way of thinking - so I'm naturally hugely biased:)
However it happens, there's definitely a resurgence of interest (outside the CS community) in functional languages - at least, I've certainly noticed them getting more attention recently.
I'm well aware of java.util.concurrent, and I agree that having a strong set of primitives is a good idea. I believe that Parallel Extensions will provide some of the same kinds of primitives as well as the higher level "parallel for" etc. Both are useful.
I haven't looked at Parallel Extensions as much as I'd like to, due to time pressures, but if there are important primitives that it's missing, those would certainly be worth telling the team - I'm sure they'd be very interested to hear other views.
And yes, it's obvious that the.NET memory model was partly inspired by Java's, which may be part of the reason for making the same mistake of giving every object a monitor. Don't assume that I'm attacking Java's record from a point of view of ignorance. (Note also that I explicitly acknowledged that Java's memory model was a lot more clearly documented than.NET's. You implied that I've been entirely positive about C# and entirely negative about Java, which simply isn't true.)
If Java 7 actually gets closures (I haven't kept track of what's currently in/out) that would certainly aid concurrent programming in Java too, btw.
It encourages people to synchronize on any old reference, such as "this" or "typeof(Foo)".
This in turn leads locks to be more public than they should be, and also decreases the readability - you don't instantly know whether an object is going to be used for locking or not.
I almost always lock on a readonly object variable which is privately created and never exposed.
Java doesn't do a good job. It does a "better than abysmal" job in that it has some idea of threading with synchronized/volatile, and it has a well-defined memory model. (That's not to say there aren't flaws, however. Allowing synchronization on any reference was a mistake, IMO.)
What it *doesn't* do is make it easy to write verifiably immutable types, and code in a functional way where appropriate. As another respondent has mentioned, functional languages have great advantages when it comes to concurrency. However, I think the languages of the future will be a hybrid - making imperative-style code easy where that's appropriate, and functional-style code easy where that's appropriate.
C# 3 goes some of the way towards this, but leaves something to be desired when it comes to assistance with immutability. It also doesn't help that that.NET 2.0 memory model is poorly documented (the most reliable resources are blog posts, bizarrely enough - note that the.NET 2.0 model is significantly stronger than the ECMA CLI model).
APIs are important too - the ParallelExtensions framework should help.NET programmers significantly when it arrives, assuming it actually gets used. Of course, for other platforms there are other APIs - I'd expect them to keep leapfrogging each other in terms of capability.
I don't think C# 3 (or even 4) is going to be the last word in bringing understandable and reliable concurrency, but I think it points to a potential way forward.
The trouble is that concurrency is hard, unless you live in a completely side-effect free world. We can make it simpler to some extent by providing better primitives. We can encourage side-effect free programming in frameworks, and provide language smarts to help too. I'd be surprised if we ever manage to make it genuinely easy though.
From my personal point of view, Silverlight 2.0 *will* have something that Flash certainly doesn't - the ability to develop for it in C# 3, including LINQ etc. Likewise it will give me the ability to use familiar WPF techniques for developing a UI. I'd rather not learn Flash unless I really have to - but being able to deploy reasonably rich client-side apps via the web (not just using ClickOnce) is attractive.
Of course, most of that appeal is irrelevant to someone who doesn't already know a.NET language - but there are quite a few people who do.
And is the same true of Google apps and Firefox then, in your view? After all, the previous posts were drawing attention to those, weren't they?
You gave examples of three posts (including this one) which are similar in flavour ("technology X hasn't taken off yet"), and tried to use that as evidence that the poster is pro-Microsoft. Your logic is blatantly inconsistent.
(Oh, and just because you may not care about Silverlight doesn't mean no-one else does. I'm watching it with interest, but without any commitment yet. We'll see what happens...)
I suspect many developers have been waiting for 2.0 as the "real" Silverlight. It feels to me like 1.0 was mostly a stake in the ground to make it clear that MS is trying for the same market as Flex etc - but it wasn't enough to build proper applications.
2.0 should (if it lives up to hype/expectations) be much more useful.
Given that beta 1 has only just been released, it's not at all surprising that there isn't a lot of demand for developers in the marketplace yet, nor books available.
Um, in what way is *this* post pro-Microsoft? You can't very well argue that "Microsoft technology hasn't yet taken off" and "Non-Microsoft technology hasn't yet taken off" are *both* anti-MS subject-matters.
One potential workaround, which would probably require support from Intel/AMD: store a short encryption key in L1 cache. It doesn't need to be big, or use "proper" encryption - just enough to make the DRAM key useless unless you've got the cache memory.
I would hope that the CPU could clear this cache as it powers down (even in a non-orderly manner).
Then again, I realise that people who aren't experts (and I'm definitely not an expert) very rarely make suggestions which actually fix significant security holes...
The program, which Microsoft says will put its software and Web development tools in the hands of 1 billion students [...] That sounds like an awfully high number to me. What proportion of the world's population (around 6 billion, right?) is students with access to a computer and a desire to do any development of any kind?
Even if we're talking over the course of 10 years, it's still somewhat higher than I'd expect.
It's far from uncommon for a company to stop selling licences for a particular version of software, but to keep supporting it. That certainly discourages green-field development and should encourage migration to an alternative solution over time, but it's not the same as the solution no longer being supported.
Yes, people own Macs. But not *everyone* is running on a Mac, are they?
There are plenty of places where the impact of VBA not running on a Mac will be zero. The fact that it's not supported on Macs doesn't make it dead at all.
Where exactly did you read that it was no longer supported? The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported".
The way I read it, the message is "If you're on Windows and depend on VBA, don't worry - you can still upgrade to the latest version of Office (for Windows). That said, we're strongly discouraging future VBA development."
I can't see why (in purely practical terms) it's worth coordinating a release with an anniversary.
Surely if the code is "ready" (thoroughly tested etc) before the anniversary, it could very easily be useful as a release to developers before the anniversary.
If it isn't ready, it shouldn't be released early just because there's an anniversary.
Let me just check this: you believe that branching in Subversion requires creating a physical copy of everything you're branching? In other words, that if you take a repository of, say, 10M within the trunk, and create a branch, that will take an extra 10M in the repository server?
If that's what you believe, you're simply wrong. Here's a test I've just done:
1) Check out piece of repository I'm branching - 11M (including the extra local copy made of every file, of course) 2) Create a branch 3) Look at the size of the revision created: 506 bytes
So, where's the duplication you were talking about? Where are the "whole copies"?
*Do* tag your projects as much as you want without having to worry about them cluttering up the repository, unless you count a few hundred bytes as significant clutter.
From the documentation:
This is why you'll often hear Subversion users talk about "cheap copies". It doesn't matter how large the directory is--it takes a very tiny, constant amount of time to make a copy of it. Enough evidence from me - do you have any evidence that Subversion behaves as you're claiming?
Slashdot Mirror
Unfortunately it's somewhat out of date. While it does cover C# 2, it was published a year before C# 2.0 (and .NET 2.0) were released - which means it won't be accurate when it comes to things like boxing nullable types.
It also (for obvious reasons) doesn't cover C# 3 at all. But yes, it does look like an interesting book...
C# 1 was quite a simple language. C# 2 added significant complexity (and power, don't get me wrong) and C# 3 has done the same again.
I wouldn't be without the benefits of C# 3, but it does take it away from the "pick it up easily in a week or so" category in my view.
Well, for a start that's clearly not true in this case - HFC# came out in November 2007. 8 months isn't a year.
However, if you want a review of a more recent book, Jim Holmes has submitted one for my own C# book (C# in Depth) which came out just a few months ago. It's in Firehose right now. Whether it makes it to the front page is a different matter, of course.
The bickering itself (from within either company) is less interesting to me than the speculation it results in.
There's two main versions of the .NET CLR (Runtime): 1.1, and 2.0. .NET 1.1 runs on .NET CLR 1.1 .NET 2.0 through to .NET 3.5 runs on .NET CLR 2.0
So far, so good.
Effectively, .NET 3.0 and 3.5 were language extensions on top of 2.0. They still execute ontop of the same CLR.
They weren't "language extensions". .NET 3.0 contains solely library extensions: WPF, WCF, Cardspace, Workflow Foundation, on top of .NET 2.0. .NET 3.5 contains library extensions, primarily LINQ (in its various guises) and additions to the BCL (e.g. System.TimeZoneInfo). I believe there are ASP.NET and ADO.NET enhancements too, but I haven't looked into them. .NET 3.5 also contains the compilers for C#3 and VB9. More on them in a minute.
.NET 2.0SP1, which includes some changes and enhancements to the BCL, such as System.DateTimeOffset.
It's also worth mentioning
If memory serves, Mono has recently announced full feature compliance against .NET 1.1, and they're now targetting full feature compliance against .NET 2.0.
.NET 3.5 apps won't run. It just means certain bits (such as LINQ, WPF, WCF, Anonymous Types, etc) are either not present or not completely implemented yet.
That doesn't mean
Anonymous types are a purely language feature. They don't need any support from the runtime or the libraries. In other words, you can compile a C# 3 app which uses anonymous types, and it will work on Mono (assuming there's nothing else missing, of course). Most C# 3 features fall into this category - they don't need library or runtime support.
.NET 2.0 was fully released, IIRC). However, you can build an app with the MS C# 3 compiler and run it against the Mono platform so long as you don't use any library functionality which isn't supported there. Asking VS2008 to target .NET 2.0 is a good starting point on that front. (It actually targets .NET 2.0SP1, so be careful...)
WPF and WCF are libraries. No language changes are needed, although tooling to support XAML is useful, of course.
LINQ is a mixture of many elements. To use "out of process" queries you need an implementation of expression trees (and compiler support). To use LINQ to Objects you need an implementation of that, but it can be completely separate to the rest of the main platform libraries (see http://www.albahari.com/nutshell/linqbridge.html for example). You can use C# 3 query expressions with no runtime/library support, so long as you've got a C# 3 compiler and a type with suitable methods (or properties).
Last time I looked, mcs support for C# 3 features was somewhat lacking (which surprises me, as Mono had a released version of mcs with C# 2 feature support before
See http://csharpindepth.com/Articles/Chapter1/Versions.aspx for more details on the MS versions available, although that doesn't cover Mono.
In either case, Silverlight/Moonlight are seperate from the .NET / Mono codebases. Yes, they have shared code, however since Silverlight 2.0 is a vastly cut down version of the .NET Framework.
This makes full feature compliance of Silverlight 2.0 by the Moonlight crowd that much easier, since the majority of the functionality that is used in Silverlight is already implemented in Mono
It's amazing what you can believe based on "general consensus". I've certainly heard "general consensus" that Java's dying, along with C, C++ and Ruby. Of course, every time I've heard a "general consensus" one way, there have been plenty of people claiming a "general consensus" the other way too, which kinda defeats the idea of consensus to start with.
I don't remember hearing that Python's dying, but maybe I've not been listening carefully enough.
It does make you wonder what people are going to be using in a couple of years' time, with all of these platforms and languages dying out...
Jon
I don't think there's anything "ulterior" about it. It's pretty obvious: if people are going to run open source software, MS would like them to be running it on Windows. It's therefore in their interests to help open source developers to get their stuff running on Windows - especially where it doesn't compete with any of their own products.
Sure, they may well not really want to help the Firefox or Open Office teams much, but if it's a choice between "PHP on Windows" or "PHP on Linux" I think it's obvious where Microsoft's interests lie.
There's nothing suspicious in that behaviour - it's perfectly plain in my view. Now, unless you count increasing Linux market share as an aim in and of itself, I find it hard to see how MS doing this is something to be dismal about.
Using a thread per client is a debatable technique. It's usually more efficient to have fewer threads, and use asynchronous IO, CSP etc to use those threads efficiently. There's less context switching, to start with, as well as lower memory usage. It's not a problem for relatively low usage servers, but if you've got 10,000 clients each making a web request which may take a while (in terms of wall-clock time, but not in terms of CPU) to process then you probably don't want 10,000 threads, each with a 1MB stack.
Asynchronous programming takes a while to get your head round, unfortunately.
Scala is one of the many languages I haven't got round to yet, but plan to at some point.
:)
There's an interesting question of psychology though. I *suspect* that we're more likely to win people round to a functional way of thinking by gradually encouraging a functional style within a familiar imperative setting than by starting off with a "mainly functional" language which allows side-effects in some cases.
I say this as someone with a long history of imperative programming, who is now coming round to the functional way of thinking - so I'm naturally hugely biased
However it happens, there's definitely a resurgence of interest (outside the CS community) in functional languages - at least, I've certainly noticed them getting more attention recently.
I'm well aware of java.util.concurrent, and I agree that having a strong set of primitives is a good idea. I believe that Parallel Extensions will provide some of the same kinds of primitives as well as the higher level "parallel for" etc. Both are useful.
.NET memory model was partly inspired by Java's, which may be part of the reason for making the same mistake of giving every object a monitor. Don't assume that I'm attacking Java's record from a point of view of ignorance. (Note also that I explicitly acknowledged that Java's memory model was a lot more clearly documented than .NET's. You implied that I've been entirely positive about C# and entirely negative about Java, which simply isn't true.)
I haven't looked at Parallel Extensions as much as I'd like to, due to time pressures, but if there are important primitives that it's missing, those would certainly be worth telling the team - I'm sure they'd be very interested to hear other views.
And yes, it's obvious that the
If Java 7 actually gets closures (I haven't kept track of what's currently in/out) that would certainly aid concurrent programming in Java too, btw.
It encourages people to synchronize on any old reference, such as "this" or "typeof(Foo)".
This in turn leads locks to be more public than they should be, and also decreases the readability - you don't instantly know whether an object is going to be used for locking or not.
I almost always lock on a readonly object variable which is privately created and never exposed.
Java doesn't do a good job. It does a "better than abysmal" job in that it has some idea of threading with synchronized/volatile, and it has a well-defined memory model. (That's not to say there aren't flaws, however. Allowing synchronization on any reference was a mistake, IMO.)
.NET 2.0 memory model is poorly documented (the most reliable resources are blog posts, bizarrely enough - note that the .NET 2.0 model is significantly stronger than the ECMA CLI model).
.NET programmers significantly when it arrives, assuming it actually gets used. Of course, for other platforms there are other APIs - I'd expect them to keep leapfrogging each other in terms of capability.
What it *doesn't* do is make it easy to write verifiably immutable types, and code in a functional way where appropriate. As another respondent has mentioned, functional languages have great advantages when it comes to concurrency. However, I think the languages of the future will be a hybrid - making imperative-style code easy where that's appropriate, and functional-style code easy where that's appropriate.
C# 3 goes some of the way towards this, but leaves something to be desired when it comes to assistance with immutability. It also doesn't help that that
APIs are important too - the ParallelExtensions framework should help
I don't think C# 3 (or even 4) is going to be the last word in bringing understandable and reliable concurrency, but I think it points to a potential way forward.
The trouble is that concurrency is hard, unless you live in a completely side-effect free world. We can make it simpler to some extent by providing better primitives. We can encourage side-effect free programming in frameworks, and provide language smarts to help too. I'd be surprised if we ever manage to make it genuinely easy though.
From my personal point of view, Silverlight 2.0 *will* have something that Flash certainly doesn't - the ability to develop for it in C# 3, including LINQ etc. Likewise it will give me the ability to use familiar WPF techniques for developing a UI. I'd rather not learn Flash unless I really have to - but being able to deploy reasonably rich client-side apps via the web (not just using ClickOnce) is attractive.
.NET language - but there are quite a few people who do.
Of course, most of that appeal is irrelevant to someone who doesn't already know a
And is the same true of Google apps and Firefox then, in your view? After all, the previous posts were drawing attention to those, weren't they?
You gave examples of three posts (including this one) which are similar in flavour ("technology X hasn't taken off yet"), and tried to use that as evidence that the poster is pro-Microsoft. Your logic is blatantly inconsistent.
(Oh, and just because you may not care about Silverlight doesn't mean no-one else does. I'm watching it with interest, but without any commitment yet. We'll see what happens...)
I suspect many developers have been waiting for 2.0 as the "real" Silverlight. It feels to me like 1.0 was mostly a stake in the ground to make it clear that MS is trying for the same market as Flex etc - but it wasn't enough to build proper applications.
2.0 should (if it lives up to hype/expectations) be much more useful.
Given that beta 1 has only just been released, it's not at all surprising that there isn't a lot of demand for developers in the marketplace yet, nor books available.
Um, in what way is *this* post pro-Microsoft? You can't very well argue that "Microsoft technology hasn't yet taken off" and "Non-Microsoft technology hasn't yet taken off" are *both* anti-MS subject-matters.
That would be where my comment of "I would hope that the CPU could clear this cache as it powers down (even in a non-orderly manner)" comes in :)
One potential workaround, which would probably require support from Intel/AMD: store a short encryption key in L1 cache. It doesn't need to be big, or use "proper" encryption - just enough to make the DRAM key useless unless you've got the cache memory.
I would hope that the CPU could clear this cache as it powers down (even in a non-orderly manner).
Then again, I realise that people who aren't experts (and I'm definitely not an expert) very rarely make suggestions which actually fix significant security holes...
Okay, the second factor: no new licences.
It's far from uncommon for a company to stop selling licences for a particular version of software, but to keep supporting it. That certainly discourages green-field development and should encourage migration to an alternative solution over time, but it's not the same as the solution no longer being supported.
Jon
Yes, people own Macs. But not *everyone* is running on a Mac, are they?
There are plenty of places where the impact of VBA not running on a Mac will be zero. The fact that it's not supported on Macs doesn't make it dead at all.
Where exactly did you read that it was no longer supported? The articles states that it's no longer supported *on the Mac*. That's not the same thing as "no longer supported".
The way I read it, the message is "If you're on Windows and depend on VBA, don't worry - you can still upgrade to the latest version of Office (for Windows). That said, we're strongly discouraging future VBA development."
I can't see why (in purely practical terms) it's worth coordinating a release with an anniversary.
Surely if the code is "ready" (thoroughly tested etc) before the anniversary, it could very easily be useful as a release to developers before the anniversary.
If it isn't ready, it shouldn't be released early just because there's an anniversary.
If that's what you believe, you're simply wrong. Here's a test I've just done:
1) Check out piece of repository I'm branching - 11M (including the extra local copy made of every file, of course)
2) Create a branch
3) Look at the size of the revision created: 506 bytes
So, where's the duplication you were talking about? Where are the "whole copies"?
*Do* tag your projects as much as you want without having to worry about them cluttering up the repository, unless you count a few hundred bytes as significant clutter.
From the documentation: This is why you'll often hear Subversion users talk about "cheap copies". It doesn't matter how large the directory is--it takes a very tiny, constant amount of time to make a copy of it. Enough evidence from me - do you have any evidence that Subversion behaves as you're claiming?
Jon