
Microsoft's Top Devs Don't Seem To Like Own Tools 496
ericatcw writes "Through tools such as Visual Basic and Visual Studio, Microsoft may have done more than any other vendor to make drag and drop-style programming mainstream. But its superstar developers seem to prefer old-school modes of crafting code. During the panel at the Professional Developers Conference earlier this month, the devs also revealed why they think writing tight, bare-metal code will come back into fashion, and why parallel programming hasn't caught up with the processors yet." These guys are senior enough that they don't seem to need to watch what they say and how it aligns with Microsoft's product roadmap. They are also dead funny. Here's Jeffrey Snover on managed code (being pushed by Microsoft through its Common Language Runtime tech): "Managed code is like antilock brakes. You used to have to be a good driver on ice or you would die. Now you don't have to pump your brakes anymore." Snover also joked that programming is getting so abstract, developers will soon have to use Natal to "write programs through interpretative dance."
Wow! (Score:5, Informative)
News at 11!
Re:So what? (Score:4, Informative)
That's because you weren't reading the ads - direct or indirect - of these MS "dev tools" (in magazines etc)
And you haven't been affected by managers who were reading them.
Re:I agree (Score:3, Informative)
WTF?
VisualStudio supports plain old C++. In fact, the new MSVS it's THE BEST editor for plain old C++, with the best autocomplete and refactoring support for C++ which exists in this Universe. I routinely write kernel-mode code in it, for example.
Some features like online C++ error checking are simply unique.
Re:I agree (Score:5, Informative)
Many companies aren't big enough (or use Windows extensively enough) to get a volume license. And besides that, the significant cost is not the license, but replacing the hardware, and all the man-hours of work getting all the old apps up and working again.
Windows 9x will remain for many years to come, on business PCs with modest needs. And yes, there periodically need to be new programs written, as well as several old programs maintained.
Re:I agree (Score:5, Informative)
Huh? If you don't want .NET, don't use a Managed C++ project, use a native C++ project. You can control exactly what libraries are included, and no, it doesn't include .NET libraries by default. I'm not sure how you can claim to know anything about Visual Studio, if you don't know this.
Re:I don't care what the MS Developers use (Score:2, Informative)
Nice strawman argument, but this is simply a case of old dogs vs. new tricks.
Besides, the people they're quoting don't really do much "in the trenches" coding anymore. They're in architect positions (which at Microsoft usually means "code evangelist").
Re:Rather smug, I think. (Score:3, Informative)
Now, I'm not saying that you therefore have to use Dotnet; I'm not really a fan of having to install yet another disk space munching VM
That choice has already effectively been made for you - Windows comes with some version of .NET since Win2003.
Re:MinGW g++ produces bloated executables (Score:3, Informative)
Did you strip debug symbols from the executable produced by MinGW?
Yes, I gave g++ the flags -s to strip debugging symbols and -Os to optimize for size. The <cstdio> version stripped down to 5,632 bytes, but the <iostream> version stripped down to 266,240. I investigated further, without the -s flag, and it turned out that whenever GNU libstdc++ creates an ostream, it also creates locale objects to represent date, time, and money formats, even if the program never outputs a date, time, or money object. Similar executable sizes were seen with devkitARM, a distribution of cross-GCC designed to target a handheld device with an ARM CPU and 262,144 bytes of main RAM: the executable hello-iostream.gba ended up 253,652 bytes in size.
Re:I agree (Score:2, Informative)
I've installed SQL Server 2005 multiple times in the last few weeks (setting up different OS's in VMs), and each time I've installed it on machines with .Net 3.5 installed. There is no conflict, and the installer does not even try to install .Net 2.0, because it's already there. You're doing something wrong.
Re:Package Runners vs Programmers (Score:3, Informative)
In other words tools do not write "tight code", the programmer does. For example, MSVC is often accused of creating binary bloat. However the IDE does not force the programmer to link in the default libs, ignorance and/or sloth is responsible for that.
Re:Package Runners vs Programmers (Score:3, Informative)
Re:Unless I forced to, I would never touch those k (Score:4, Informative)
Re:Rather smug, I think. (Score:2, Informative)
I can't beleive....... I agree with MS programmers (Score:2, Informative)
Then worse of all, things written badly as web apps. I was in the doctors and they had been computerize. The register for your appointment system was really slow, but what blew me away was the slide show of information. It couldn't even scroll large text across the screen properly. I could see this was a web thing because some of it was broken and the page was a IE page not found page. Here we are in 2009 with crazy powerful computers from the future, and we have such bad choices of technology, so much abstraction in the way, and bad "professionals", that it's worse then I did as a kid in BASIC on a computer with 2MHz. It makes me soo angry. It feels like we are going backwards. The fact these crap systems always seam to be running on Windows doesn't help. I'm sure it would be as easy and faster+ cheaper on a stripped down Linux with just X, the required libs and python!
Comment removed (Score:4, Informative)
Re:Programmers I've worked with (Score:3, Informative)
you really should try and use 80 columns only
Hi. The Time travel tourist board called, they said your "work in the future" visa was about to expire and could you make your way back to 1978 please. :)
Re:C on an 8-bit microcontroller? (Score:3, Informative)
Does that work even if you're targeting generic i686, which only goes up to MMX? Does the speed gain outweigh the time overhead to check which instruction sets are available and the space overhead of multiple implementations, one for each instruction set?
When speed matters, runtime processor checking is a triviality. Think about it.
Anyways, runtime cpu checking is normally only done once, often during program initialization.
There is a reason that the fastest implementations of heavy-lifting algorithms (encryption, compression, etc..) are written in assembly, and its not because the compiler is only slightly sub-optimal. Its because the abstract machine model for the language simply doesnt contain the concepts necessary to describe the (presumed to be.. TANSTATFC) optimal process such as explicitly leveraging the x86 flags register and the instructions which manipulate it, which means that you cannot coerce the compiler to emit anything that even resembles the optimal process.
"You can't get there from here."
I'm sure there will be lots of posts about premature optimization. Those arguments apply to application development, but often not to library development.
Re:I can't beleive....... I agree with MS programm (Score:3, Informative)
I keep being told by .NET people it's really not that heavy and it much more productive etc etc.
I feel the same way about Python. CPython is a naive interpreter, one of the few used for serious programming. Even Javascript has JIT compilers now. Not only that, on a multicore CPU, each CPython process runs slower, due to badly designed fighting over the global interpreter lock.
If CPython didn't suck so bad at performance, Google wouldn't have had to write "Go". Sad.
Quote's out of context (Score:3, Informative)
I was at the talk, and yes Don Box said "I will fight you if you try to take away my text editor" but it was after having being asked a leading question by Eric Meijer. Something along the lines of "will we ever write software entirely without writting text?"
However, what was Don doing for the rest of the PDC? He was hawking Entity Framework and M, both of which allow users to model data access using rich graphical tools!
The talk is here: http://microsoftpdc.com/Sessions/FT52 [microsoftpdc.com].
Re:MinGW g++ produces bloated executables (Score:3, Informative)
Try it with the project set to static link the C++ runtime. Otherwise a lot of the code is going to be in the msvcrt??.dll instead of the executable, and it's not a valid test.
The test was for a statically linked binary (it's what you get by default when using cl.exe with no other options). Dynamically linked (/MD) one is 7Kb.