May 2004 - Posts
According to German Site Heisse, Richard Kaplan (Marketing manager of Microsoft) told at a Winxp sp2 session that SP2 could be expected in September. Internal documentation talks about q3 2004.
That's really not what you think, apost on the joy of drinking :-)
This is really cool, one program in 621 languages and variations !
Of course VB.Net C# are there, but check also the more exotic ones.
And yes Applesoft too :-)
But for me Logo is really the one I used to love th most, because maybe of the syntax simplicity:
; by Augusto Chioccariello
for [i 99 1 -1] [
print se :i [bottle(s) of beer on the wall]
print se :i [bottle(s) of beer]
print [take one down, pass it around]
print se (:i - 1) [bottle(s) of beer on the wall]]
"The role of the Software Architect"
The Software Architect function is not well defined, and we have to admit that it is difficult to give a precise definition of the term. This short article tries to determine the identity of these strange characters by presenting the tasks they are assigned and the required qualities to fulfill them.
A short read about software architects in small teams.
By Fabrice Marguerie
Thanks to Barry Gervin for this list of pdf's for each topic from TechEd.
Not sure it's new, but I recommend this article by J. Ambrose Little on generics.
Ouch ! It hurts ! Read the article here
Last week, I posted something about Datetime format and SQL, something to help SQL understand any international date format.
Well Jerry Pisk is right, his method is shorter. Use Mydate.ToString("yyyyMMdd"). Short and efficient.
Now just a note to Jerry: no need to use a bossy tone to explain something ! We all learn every day :-)
And yes Jerry I use parameters and not query strings in my code.
Things said nicely are always easier to swallow !
Hitachi has put on a page the noises you can hear from a crashing hard drive.
Very stressful and some are not recommended as ringtones :-)
Paul Vick reply to the question “isn't C# the language that's most 'native' to the .NET environment?”
The problem with blanket pronouncements like “always use CLR functions instead of VB functions“ is that you can easily shoot yourself in the foot without knowing it. One suggestion I've seen in more than one place is to use the functions exposed by the Convert class (a CLR class) instead of the intrinsic conversion operators (CInt, CStr, CLng, etc.) exposed by the VB language. This is supposedly because the CLR functions are going to perform better than the VB “functions.” The problem with this is that the conversion operators are true operators that compile down to IL instructions while the Convert functions are still just functions. This means you'll get significantly worse performance by calling Convert.ToInt32 instead of using CInt. So it's always very important to know what you're doing when you start tackling issues like performance.
So, in the end, there is no “native” language on the CLR and performance is something you're going to have to think about no matter what language you choose. (In fact, I think I should add a rule #0 to my “Ten Rules of Performance:” When it comes to performance, beware rules.) There are certainly lots of other factors to think about when choosing between VB and C#, but I don't think these are two of them.
More Posts Next page »