Microsoft's Top Devs Don't Seem To Like Own Tools

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!

[Anonymous Coward]

Advanced developers who learned how to code on what would be considered bare bones IDEs don't feel the need to use tools that are meant to let low level developers produce functional GUI applications without having to dedicate tons of hours.

News at 11!

Re:So what?

[ceeam]

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

[Cyberax]

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

[evilviper]

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

[jpmorgan]

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

[Anonymous Coward]

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.

[shutdown -p now]

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

[tepples]

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

[Volguus Zildrohar]

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

[TapeCutter]

I've been making a good living from MSVC since v1.5 arrived on win3.1. My current place of employment uses it to write a single code base that is later compiled in 32/64 bit versions for Win, Linux, Solaris, HPUX and Aix. IMHO MSVC's edit, search and (win) debug features are second to none. Not only that but as the GP implies, creating a large project that builds multiple sub-projects is a snap when compared to writing make files. Some of our build scripts create dozens of binaries, the MSVC command to kick it all off is a single line in a batch file.

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

[TapeCutter]

I haven't used Qt creator but I've heard good things. I used to be a big fan of Borland's Turbo IDE's back in the late 80's early 90's and I think that is where much of the initial inspiration for MSVC came from. It's the only example I can think of where MS beat a strong competitor the old fashioned way (ie: with a better product).

Re:Unless I forced to, I would never touch those k

[khellendros1984]

I've used SDL, which provides for audio, 2d graphics, controller input, network communication (I think), among other things. Basically, it's a multi-platform toolkit similar in use to DirectX....of course, I'm not claiming that it's a full feature-matched equivalent, but it's pretty useful.

Re:Rather smug, I think.

[hde226868]

Sorry, while I agree with your programming statement, please be aware that with antilock brakes in most situations the stopping distance is decreased, not increased as you claim (see, e.g., http://www.abs-education.org/faqs/faqindex.htm [abs-education.org]). The reason is that usually you have better traction when your wheels are rolling, not when they're blocked. It is only in very rare situations that you'd be better off without ABS. So you want ABS even for good drivers since as a human you just aren't fast enough to modify the braking force on the wheels to keep them from blocking.

I can't beleive....... I agree with MS programmers

[jabjoe]

I can't stand the .NET invasion. I keep being told by .NET people it's really not that heavy and it much more productive etc etc. Most admit it would be a problem if every app was written in .NET, but it ok for their app. BUT the very same people blame .NET when their applications are fat and slow! It gets worse when you have multiple of these apps running, each written basically on the assumption it's the only thing to run. Apps should be written to be a good citizen, i.e. take as little as they can, and give as much as they can. Don't get me wrong, it's not just .NET, this seamed to happen before with JAVA, which didn't take over either. Now I don't know if it's an environment thing, or programmer skill level thing, but JAVA applications don't seam to be as bad as .NET.

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!

Re:So what?

[Shinobi]

"Even $3 embedded devices will have 100s of meg ram to play with."

As a rule, no they won't. SOME embedded appliances, marketed for homes and sheltered geeks will have that, because they have the luxury of being connected to the powergrid all the time. Embedded stuff that don't have that luxury will not, for power saving reasons. That's why there are still embedded devices that use 1980's bare-bone processors and less than 100KiB RAM.

Re:Programmers I've worked with

[gbjbaanb]

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?

[Rockoon]

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

[Animats]

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

[A Guy From Ottawa]

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

[shutdown -p now]

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.