Comments on: Extending HttpApplication with session counts and uptime in C# http://damieng.com/blog/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c A .NET developer in Redmond Tue, 18 Nov 2008 21:44:07 +0000 http://wordpress.org/?v=2.6.3 By: Steve http://damieng.com/blog/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c#comment-1503 Steve Thu, 08 Jun 2006 14:25:23 +0000 http://damieng.com/blog/archive/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c.aspx#comment-1503 Java's main problem is the lack of simple out of the box complete frameworks for things like web development - there are lots of really great libs and tools out there (Struts, JSF, XDoclet) but you have to know where to get them and assemble them yourself - it's strongly decoupled and flexible approach is its own worst enemy, there's no turnkey version. Trust me, once you get a platform going it's as productive as .Net but it takes time to build it - impractical on a course (I know, the Java I did in my degree is nothing like what I do for a living). They've gone some way to making this better in v5 with Annotations, but it's still the major reason developers prefer .Net on first sight IMO, .Net hands you more stuff on a plate so it's quicker to get going. Java's main problem is the lack of simple out of the box complete frameworks for things like web development - there are lots of really great libs and tools out there (Struts, JSF, XDoclet) but you have to know where to get them and assemble them yourself - it's strongly decoupled and flexible approach is its own worst enemy, there's no turnkey version. Trust me, once you get a platform going it's as productive as .Net but it takes time to build it - impractical on a course (I know, the Java I did in my degree is nothing like what I do for a living). They've gone some way to making this better in v5 with Annotations, but it's still the major reason developers prefer .Net on first sight IMO, .Net hands you more stuff on a plate so it's quicker to get going.

]]> By: Damien Guard http://damieng.com/blog/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c#comment-1502 Damien Guard Thu, 08 Jun 2006 00:07:49 +0000 http://damieng.com/blog/archive/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c.aspx#comment-1502 Having written a mini eBay for my degree in Java + JSP I can much say I prefer the .NET approach to web development.<br /><br />[)amien Having written a mini eBay for my degree in Java + JSP I can much say I prefer the .NET approach to web development.

[)amien

]]> By: Steve http://damieng.com/blog/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c#comment-1501 Steve Wed, 07 Jun 2006 12:02:37 +0000 http://damieng.com/blog/archive/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c.aspx#comment-1501 Oh, and I just mentioned this because seeing Interlocked.Increment reminded me. Sorry for the sidetrack. Oh, and I just mentioned this because seeing Interlocked.Increment reminded me. Sorry for the sidetrack.

]]> By: Steve http://damieng.com/blog/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c#comment-1500 Steve Wed, 07 Jun 2006 12:00:07 +0000 http://damieng.com/blog/archive/2006/06/06/extending_httpapplication_with_session_counts_and_uptime_in_c.aspx#comment-1500 Having read up a little on threading in .Net, I have to say I favour the Java approach, but more for what it doesn't let you do ;). At the higher level there's not much difference between them really, except for naming issues (instead of wait/notify/notifyAll available on all objects, you have a separate Monitor class with Wait/Pulse/PulseAll - a little odd choice of name but I'll ignore that). However, .Net clearly lets you get at the more fundamental building blocks of threading, namely at mutexes and semaphores (and the atomic inc/dec/exchange/check&exchange which are simple & ok). <br /><br />I can see why that might be useful in some cases, but in my experience threading is such a can of worms it's nice to have it locked down to the 'recommended' approaches for business applications. Mutexes and particularly semaphores (with their lack of thread identity checks) are really, really easy to screw up so if I were using C#, I'd set internal standards to avoid them entirely and stick to Monitor. I guess .Net is being helpful here, but IMO giving these tools to inexperienced coders is like giving a razor to a tartrazine-addled toddler. :) Having read up a little on threading in .Net, I have to say I favour the Java approach, but more for what it doesn't let you do ;). At the higher level there's not much difference between them really, except for naming issues (instead of wait/notify/notifyAll available on all objects, you have a separate Monitor class with Wait/Pulse/PulseAll - a little odd choice of name but I'll ignore that). However, .Net clearly lets you get at the more fundamental building blocks of threading, namely at mutexes and semaphores (and the atomic inc/dec/exchange/check&exchange which are simple & ok).

I can see why that might be useful in some cases, but in my experience threading is such a can of worms it's nice to have it locked down to the 'recommended' approaches for business applications. Mutexes and particularly semaphores (with their lack of thread identity checks) are really, really easy to screw up so if I were using C#, I'd set internal standards to avoid them entirely and stick to Monitor. I guess .Net is being helpful here, but IMO giving these tools to inexperienced coders is like giving a razor to a tartrazine-addled toddler. :)

]]>