Greg-
Could you elucidate for me how .NET handles thread synchronisation?
I ran into a situation where someone wanted a .NET App coded up in 3 days
which worked ok except I ran into a problem where multiple threads were/are
accessing the same method..my work around was to install a hack which turned
on a Session variable and a pre-validator function would ensure that session
variable was indeed turned off before executing the method. Does .NET have
any support for synchronized method access?
Feel free to contact me offline...as this WAY WAY WAY O/T
Many Thanks,
Martin-
----- Original Message -----
From: "Gregory Seidman" <[EMAIL PROTECTED]>
To: <user@struts.apache.org>
Sent: Saturday, July 02, 2005 9:40 AM
Subject: Re: Struts vs .NET???
On Sat, Jul 02, 2005 at 04:41:38AM -0700, Nitish Kumar wrote:
} With all due respect to every one (including microsoft).. the advantage
of
} .NET is nothing but a IDE which is idiot proof.
} Any dumb can do a few clicks followed by intelligent editor to prompt
and
} spoon feed whats to be written, and then the IDE creates a code, which
makes
} any dumb with or without any intelligence, a programmer.
You clearly missed my post on the advantages C# has over Java, IDE
notwithstanding. The language itself is more convenient, in that common
idioms require fewer lines of code. Sure, you can tell me that Eclipse or
whatnot takes the drudgery out of getters and setters, but I can tell you
that the C# language itself avoids that drudgery. You can also tell me
that
there are Java tools to make the unpleasant task of developing a JSP tag
easier, but I can tell you that C# and ASP.NET make encapsulating
functionality in custom tags comfortable and easy. Furthermore, it is at
least three times easier (i.e. takes 1/3 the lines of code) to express
event handling in C# than in Java. C# has other advantages as well (I'm
particularly excited about the coming C# improvements, which include a
very
nice way of expressing iteration), but those three are sufficient basis
for
the points below.
If you are an idiot, you can produce crappy code that may actually work.
This is, indeed, more likely using Visual Studio (though I'd claim the
days
of it being truly easy were over when VB6 went away) than in Java.
Ultimately, however, if you want solid, dependable, maintainable, scalable
software then you need good software engineering, and no IDE or language
will change that. If you have good software engineers, it then becomes a
concern of how much do they have to do to accomplish the task, which boils
down to lines of code. (A better software engineer will accomplish the
same
task in fewer lines of code, but there is a lower limit on the lines of
code required to express any specific functionality.) With C# in
particular, and ASP.NET to some extent, the number of lines of code
required (whether or not you count lines generated by your IDE of choice)
to express any given functionality is generally less than that required to
do the same thing in Java. This is based on my experience, of course, but
also based on the specific advantages I listed above; they are common
idioms, which means that saving a few lines of code in the numerous places
in your program where you use those idioms adds up.
} Unfortunately in java, we still have a long way to go before we promote
} idiots to the coder level.. We are progressing in that direction, but I
} guess we still have some time before that..till then I hope to retire..
:)
I am not interested in having idiots coding. There are two problems with
coding by idiots:
1) They often become managers (or already were) and can't understand why
it
takes so long for those lazy software engineers to accomplish the tasks
before them. I mean, after all, when they slapped together that VB app
in a week it worked great!
2) Once the idiots have produced their crappy code, it becomes some
software engineer's problem to maintain it, make it scalable, etc. and
it's just unpleasant to deal with crappy code. Even worse is when
management ties the software engineers' hands and prevents them from
treating the crap code as a working prototype (i.e. which should now be
rewritten) and forces them to keep it alive as is.
Also note that there are huge distinctions between a coder, a programmer,
and a software engineer. The coder produces (working?) code. The
programmer
can produce working code that accomplishes a medium to large task with
some
eye toward efficiency. The software engineer can produce well thought out,
working, maintainable, scalable code that provides hooks for potential
future development. I hate working with coders. Programmers are useful,
but
require guidance.
} Thanks and Regards,
} Nitish Kumar
--Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
