IMO, strong typing has nothing to do with compile speed. It has everything to do with catching errors at compile time that you normally wouldn't catch until runtime.

If you don't want to declare every variable in .Net, then just make everything var (although it isn't recommended) or turn it off in VB.

No need to scroll up either. Most .Net people just define the variable when it's first used.

>I've been through this same discussion on strongly typed vs untyped back when 200MHz was fast. Turbo Pascal compiler was blazingly fast, because it was a single-pass compiler. Before compiling code, it had to know everything about any possible variables that may pop up in it, so you had to strongly type them. And it would compile a nice chunk of code in a second on a 2MHz Z80. Back then interpreted code was deemed to be slow, just because some flavors of interpreted Basic were slow. However, difference between speed of P-code and full compile into machine code was negligible; P-code would call runtime routines which can be, and often are, optimized. Fox was actually the strongest argument in favor of P-code+runtime. Somehow, VB guys thought of themselves as "compiled", while distributing runtimes everywhere :). And, nowadays, CLR is runtime too.
>
>As much as strong typing was necessary in the early days, because it made compilers simpler (fewer errors!) and the runtime faster, this is 20 or 30 years later, machines are blazingly fast compared to then, and the help of strong typing is not doing much for speed. As I mentioned, there are maybe 40 or 50 other things that the computer is doing in any given minute, and just the cost of process switching is larger than the gain by strong typing in most cases (IMO). If I was writing a mission critical, physical process tracking software, I may want to have strong typing, to squeeze every cycle I can - but before that, I'd unload about 50 of the system processes, get the machine off the network etc etc - a hundred other things that take up far more.
>
>But for my day-to-day coding, I'd rather not have to declare every variable with a type (even with any neat Intellisense script which may ask me which type I'd want), specially not in a six line routine which may accept any numeric type or a date (because it does date calculation and returns a number of days after something, or a day... and the parameter is a date or a day number). If I ever pass it a string, my bad. But in cases when I'm going over a record of an unknown table (not as rare as you may think), there's no way I'd know the types in advance. And if schema is not uncoupled from software which uses the table, then we're back in the 80s.
>
>IOW, I don't think strong typing is so great as to be the default behavior; it has its limitations and is generally wasting more time by irritation (or by just having to scroll up and add a variable - which has a nice side effect of forcing programmers to write short chunks of code, so they don't have to scroll so much), than it's saving in processor time. If you're writing an OS or a browser, OK, make it as tight as possible, but investing hours of work into squeezing a few milliseconds a day off a few hundred processors doesn't look worthwhile to me.
>
>>In the beginning of your experience/learning curve, do not look to much a what you cannot do - or think you cannot do, but look at what you can do
>
>That's exactly how I learned to think of programming - the kinds of steps that are available, and which ones to take to get from A to B. So, starting with what I want/need to do, how do I do that using the tools at my disposal.
>
>But then you push it to do something that its creators didn't have in mind. People have done complete payrolls in Lotus 1-2-3. I've done a polyclinic in FP2.6, but also a solitaire. There are games written in Flash or JavaScript; there are engineering calculations done in GWBasic.
>
>Once you hit a limitation in a language, you start doing not what you want, but what you can. If you're good, you still do what you want, in any possible way. You work around - and maybe invent a few great things at that. Things that may turn out to be great for other uses. May be an accidental invention, which doesn't diminish its usability.
>
>We may be guilty of not willing to let go off a good hammer, even when everybody else is switching from nails to glue. Because it's still a good hammer. I'd actually rather like to have screws and a driver instead, glue doesn't hold that fast nor long.