Slashdot Mirror
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."
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!
I hate Microsoft more than anyone, but... I really don't see an issue or any hypocrisy here.
"Most people, I think, don't even know what a rootkit is, so why should they care about it?"
Yes, in some respects, programming is becoming easier and more unqualified people are able to do it.
But I think that these guys are really missing the boat. The closer the programming environment can come to providing domain-relevant expression tools to the user, the better they will be able to create programs that fit their domain.
In addition, content these days is a form of programming. Whether it is HTML/CSS or word processing or spreadsheets, the distinct line between what is a program and what is pure data is blurred beyond recognition. So a programming language for interpretive dance would probably find the Natal very useful.
so MS has elitist morons in their ranks as well, how is this news?
If you mod me down, I will become more powerful than you can imagine....
It does not affect my decisions at all.
Businesses aren't in business to push programming ideology. They are in business to make money. If I need an application I'm going to get the application that does the job for the least amount of money (all the caveats about it not being poorly written and being moderately open to possible future expansion, etc.. apply). If I need bare-metal code then I'll get a guy to do that. If VB will do the job then I'm going to get a guy to do that and probably a bit cheaper. I don't care what the language is. I care that the problem is solved adequately for the least amount of overhead possible.
When I researched the Visual BASIC.Net 2002 development tools in beta I noticed those problems and my employer thought I was crazy. They moved on to Dotnet without me, having fired me for getting sick on the job and I eventually ended up so sick from the stress that I ended up disabled. I went on short-term disability for a while, tried a few more jobs, but ended up on disability.
Wow! I never thought I'd see a "crappy Microsoft software made me disabled!" post on Slashdot. Though I guess it shouldn't come as a surprise to me.
"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."
Might have been more appropriate to compare it in that people in the high performance arena (nascar) don't like antilock brakes because of their limits and the separation you get from your task at hand. (you lose your "feel for the road")
Tho I'm a little strangely biased, I miss the days of assembly, when 10k was a LOT of code to write to solve a problem, thing ran at blindingly fast speed with almost no disk or memory footprint. Nowadays, Hello World is a huge production in itself. 97% of today's coders don't have any idea what they've missed out on and just accept what they've got. Even someone that understands the nerf tools like VB at a lower level can get sooo much more out of them. I recall taking someone's crypto code in VB and producing a several thousand-fold speed boost because of my understanding of how VB was translating things. They didn't know what to say, they'd just accepted that what they were doing was going to be dog slow. (and unfortunately the users are also falling under the same hypnosis)
I work for the Department of Redundancy Department.
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
Well you are very close to the mark here.
The integrated IDEs arose to allow the hobbyist and corporate IT newbie turn out something, which has a good chance of being functional if not maintainable or efficient. These tools also allow specialists from other fields (accountants, meteorologists, scientists) actually turn out products.
Efficiency, maintainability and extensibility don't matter for that type of programmer. They just need to put up a few screens to count the widgets or produce the daily report. It doesn't have to be portable,or efficient, and chances are it will be tossed as soon as that programmer moves on to another job.
Those programmers do manage to turn out a reasonable amount of customized applications, some of which are actually marketable. The vast majority are for in-house use. But some actually work quite well for specialized industry applications like Medical Billing, where the knowledge of the subject matter is more important than the efficiency of the code.
OS level code has to be much more efficient, and there is no substitution for knowing the programming language, the processor capabilities, and the compiler peculiarities. You can not leave to some IDE the task of putting code behind a button that will drag in half a ton of MS Foundation Classes or use some particular C/C++ construct that is horribly inefficient. You are basically always dealing with some data stream or message and doing X Y and Z with it and handing it off to the next task.
As such these guys virtually never see a piece of data all the way thru the computer. Their customers are other pieces of software. Their wholesaler are yet more pieces of software. Its data-in, whack it, pound it, and pass it on sort of code, and a lot of it, and a lot of self plagiarism. The IDEs just get in the way.
Sig Battery depleted. Reverting to safe mode.
I could write a lengthy essay about how old programmers don't like to use new tools that offer them little because they already know all the tricks and gadgets for their old, "inferior" and more complicated tools, while new tools are perfect for new programmers because they don't have to learn so much to achive the same results because those tools are easier to use and the learning curve isn't so steep until you have a result, but I think I can sum it up in a single word:
Emacs.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
C'mon, this is unfair. By your logic we shouldn't have Perl or Python or any other scripting language because they "[don't] give nearly as much control because it tries to spoonfeed you."
There are lots of situations when you don't need to twiddle the bits or delete your own allocated memory. What's wrong with simplifying the language for simplified tasks?
It's not like Microsoft doesn't support low-level languages.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I just realized that I am now committed to the proposition that Perl "tries to spoonfeed you." I am not sure this is a good position to be in ;-)
When BASIC was bundled with almost every 8-Bit computer sold in the 1970's and 1980's? It was the default language on most of the systems sold and other languages like FORTRAN, C/C++, Pascal, COBOL, etc had to be bought separately. So the el cheapo way to program was via BASIC. Many computer magazines issued BASIC programs in them and cross platform modifications for Apple //, Commodore 64, IBM PC MS-DOS, Atari 800/400, TRS-80 and TRS-80 COCO, TI 99/4a, etc that had BASIC default.
Borland turned Turbo Pascal into Borland Delphi, but Microsoft turned GWBASIC and Quick BASIC into Visual BASIC. Then when Windows dominated the Visual BASIC took over C++ and Delphi, as it was easier to program in for managers to understand. I didn't program in Visual BASIC because I liked it, I programmed in it because the job required me to do so. My managers didn't understand Java, C/C++, Python, Perl, PHP, etc, only BASIC and Visual BASIC, so they didn't trust programmers to write with anything else. Most of the Microsoft Windows IT/IS departments are run almost the same way and most of them use Visual BASIC (or in some cases Visual C# as it is easier than C++) because it is easier for management to understand what their programmers are doing and review code.
You don't earn money programming with your choice of a programming language, you earn money with a programming language that your employers choose for the jobs that are available in your area. Unless you want to migrate to a Linux or Macintosh IT/IS department, but sometimes you have to settle for a Visual BASIC development job and have no choice in the matter.
Just that now Microsoft Programmers are catching on that Dotnet is rotten, and if corrupt any program written to use it won't work.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I'm a great programmer and I use emacs, you insensitive clod!
The
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.
do they use vim or emacs now?
Intellisense is pretty slick, but overall if I'm doing development on Windows I'd rather use an emacs as my text editor.
Of course, Visual C++ makes a fantastic debugger. It's almost good enough to forgive Windows for its lack of valgrind. Almost.
The biggest posers I worked with used Visual Studio. The best group of programmers I worked with used text editor. That group could code rings around VS. The best of the best of them used vi.
This is absurd. Visual Studio, Eclipse, Vim, these are fucking *tools*. People use tools, not because the people are better, but because they find the tools useful.
Me, if I'm writing code for Unix or my DS, yeah, I prefer a maximized xterm, GNU Screen, and Vim. But if I'm writing a .NET application, I'm gonna use Visual Studio, as it's a very powerful development environment (doubly so when coupled with ViEmu).
OTOH, people who judge others based on their choice of IDE? Those people *are* tools...
The original article and the summary both come of as rather smug to me. The truth of the matter is that you need both low-level nitty-gritty programming and high-level programming. It depends on what you're using it for.
Think of it this way. You have people who make pipes. You know, the kind used in plumbing. Fittings, too. And they're very good at it. If you take your average house builder and try to get him to make a pipe, he'll be hopelessly bad at it. But you know what those guys who build houses are good at? Putting the pipes together in meaningful ways to get what they need (i.e. building a house) done. Take a guy who's brilliant at making pipes and fittings and try to get him to build a house. Yeah, not such a superstar now.
It's the same with programmers. Tell someone who is very good at writing low-level code, "I need a killer efficient compiler." Give them enough time, and they can churn it out and make it wicked optimized. Tell them, "I need a new type of control that works in this specific way and with crucial efficiency," and they're your guys. Tell them, "I need an new application entirely from scratch that can process my specific business logic, it needs to look and feel like a standard Windows application, it needs to be easy for end users to figure out and work with, and we need a working version in a couple of weeks," and they'll probably laugh at you. Yet that's what those people they're looking down on, the people developing with higher-level abstracted languages, are doing every day.
In my experience, competence != usefulness. They're not opposites, mind you, but it takes both types. It takes the people who work with the low-level nitty-gritty stuff, and it takes the people who use what they churn out to actually accomplish real-world productive things. One isn't smarter, one isn't better, neither should be looked down upon. Both are necessary.
Yeah, because IDEs don't have lists of errors, and double clicking on the error doesn't take you right to the line where the error is. It's so much easier to hunt through random code than to look at the little red squiggle on the line the IDE pointed out to you.
I'd call you an idiot but that would be insulting to idiots.
Our programmers are getting a bad rep because of our coding-for-weenies tradition. Can you please run an article that makes Microsoft programmers look like total badasses?
XOXOXO
-Steve B.
I'd be frustrated too trying to write code with tools that generate memory leaks for days and sucks at returning free'd memory to the system. I remember one version of Word you could start it up and just let it sit, within and hour or so Windows would crash. Then the version of Excel that shipped with debug code because the stripped version would never pass QA. Aw fine tools.
When I have to write a Windows GUI app, C# rocks! I can design the UI whip off the code and be done with it. It's better than MFC and after writing countless message loops in win32 and OS/2 for that matter, I don't think writing more GUI boiler plate code, using the APIs to match resource IDs, and all that mindless coding will do any good - especially when I need the time to figure out an algorithm or other problems. And I can still do low level stuff (really low level) with P/Invokes, so the only thing I'm really missing out is busy work. And if there's a time when I DO need the control and abilities of unmanaged code, well there's the C++ stuff.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
There are times I am forced to, like if I'm doing gaming video, I have to do it using the Direct-X toolkit.
I mean, there is no other way around, since some users are using ATI cards and CUDA is useless on ATI GPUs.
But on other projects, I do bare metals, and when I have the chance, I go assembly.
Muchas Gracias, Señor Edward Snowden !
Don't know about interpretive dance, but I'm guessing that the MFC was written in abstract pottery.
Red to red, black to black. Switch it on, but stand well back.
The point you are missing is that "bare-metal code" is assembler, regardless of how much effort is involved.
I again have to point you to Linux or *BSD, these OSes have real time drivers in C. I don't recall seeing *any* peripheral driver in Linux that is not C. Practically all assembly code is under arch/ which means bootstrap, memory initialization and main timers. The rest is C.
Go ahead and write a real time driver in C, let me know how it works for you.
I'm doing this right now, and it is a very usual thing for me to do because I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz. I have tons of peripherals in the MCU, and they must be serviced on time. A typical MCU project is a real time design. Sometimes I profile the code by connecting an oscilloscope to some spare pins and check that I have enough time in critical parts of the code. And *all* the code is C, compiled by avr-gcc 4.3.2. I have maybe 0.1% of the code that is in assembler, and that is stock macros that come with avr-gcc.
To illustrate, here you can see the lowest level of avr32 support, and you can observe how many LOCs are in .S and how many are in .c files. If still not convinced, visit mm/ and see what language the do_page_fault() is implemented in; that is one of most performance-critical pieces of code. C today is the "bare-metal" language of choice, and it works well in that role.
The article didn't actually have much in it, it was Computer World after all, but it makes sense if you read it as visual programming tools instead of Visual Studio. The article seemed, as CW articles tend to, that it was a good article that was cut to 1/4 it's original size just because.
With today's libraries, a half-decent IDE can make a huge difference in productivity. But the comment about zooming in and out makes perfect sense if you think of the "I'll drag an IF block here, then wire it to the blah field..." kind of visual programming. The kind that people are always trying to make so that programming will be available to the "everyman". The kind that never works.
Hypercard is the closest I've ever seen this come to working well. It's so sad Apple never knew what to do with it. It was approachable, and for simple record keeping was rather easy. HyperScript worked very well and was extremely approachable, especially with it's ability to do things like "take word 5 of line 2 of textbox".
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
I don't really see the point in using assembly anymore. Yeah, its fast. But, its also a total pain to port and sometimes to maintain. With predictions saying that ARM will eventually catch up to x86 within the next 5 years, the fact that an ARM version of netbooks could be coming, etc. I don't know why anyone would still program in assembly for anything other than, say, emulators which need to be built for speed.
Taxation is legalized theft, no more, no less.
http://www.codeplex.com/singularity
Your words, I want to see you eat them.
I don't know why anyone would still program in assembly for anything other than, say, emulators which need to be built for speed.
How about programs designed to run in the same class of systems that such emulators emulate? There are dirt-cheap mass-produced computer-on-a-chip designs that connect an 8-bit CPU core clocked at under 5 MHz to a TMS9918-like video generator. You're dealing with something comparable to a Sega Master System or NES on a chip. C on a Z80 or 6502 isn't pretty.
Very insightful reply, and you're 100% correct. That was my other line of thought. This is the company (and probably some of these "superstar" programmers are the very people) who have given us a litany of buffer overruns, security holes, and other low-level programming "features" over the years.
I'm not saying that no one should ever program at a low level, but I am saying that people shouldn't be afraid to take advantage of features of managed code and other conveniences. Don't program at a low level if you don't have to. You're only making your life harder for no reason, and needlessly exposing yourself to risks of fundamental errors that are much worse. Take advantage of all of the hard work that others have already done.
The real reason why they don't use Visual Studio is far more prosaic -- the build environment of most of Microsoft products does not support the Visual Studio project files. Their products are built using a system called CoreXT -- basically a set of binary tools and scripts cobbled together by build engineers and developers over the past decade or so. CoreXT uses a lot of different crap, make, perl, compilers, etc, etc., and all tools and SDKs are checked in and versioned. The upside is that you can roll back your Source Depot (Microsoft's own flavor of Perforce) enlistment to an earlier date and be sure things will build exactly the same way, and once you enlist, you get repeatable, isolated build environment where you can guarantee the correctness of versions for all tools, compilers and libraries (Java developer's wet dream, even though they don't know it). The downside is that you have to maintain the makefiles by hand, and you can't use Visual Studio, because there are no project files checked in, and even if there are, most people don't use them and they are not updated, so you can count on them being broken.
I did a lot of my coding in either Notepad2, or in a separate project in Visual Studio against a test harness emulating the rest of the project (what Enterprise Java types call a "mock"). Some folks used Ultra Edit or vi, or EMACS. For some just a bare Notepad did the trick. Some stuck with Visual Studio, which in their case was just a glorified Notepad with autoindent since it doesn't support build or Intellisense if you don't have a project file.
Yes, it's an enormous waste of time, and yes, it was painful. But CoreXT is so integrated into the rest of the dev pipeline that replacing it with something else in a large product is a major, destabilizing endeavor that is bound to undo at least some of the work around gated check-in infrastructure, test infrastructure, automated deployment infrastructure and god knows what else, so few teams ever attempt it. Now naturally, DevDiv eats their own dogfood, so they were one of the first teams to switch completely to MSBuild. It took something like a year in their case, they did it gradually, from the leaves down the tree. I'm sure if they had a choice, they would be using CoreXT to this day though, and fighting with incremental build issues. :-)
Recently, a few more teams have adopted MSBuild. They can actually open their entire projects in Visual Studio and rebuild them. If they have test infrastructure deployed on the side, some of them can even test the product without waiting for it to deploy. So I predict that as more and more teams adopt MSBuild (this in itself could take another decade easily), these "senior" folks will come around to appreciate its benefits. It's awfully handy when you can set a conditional breakpoint on your local box and step through things.
Actually, you're both right. Or I should say, you are right and the OP may be right. You're right because it is obviously true that there exists at least some non-poser programmers who use Visual Studio and at least some "poser" programmers who use a text editor. But the OP may be right if it is statistically true (I don't know that it is) that there exists high correlations between "good" programmers preferring a text editor and/or "posers" preferring Visual Studio.
While it is obviously true that such correlation coefficients do not equal 1.0 (since supposedly at least some of us subjectively know of some good programmers who prefer Visual Studio or some poser programmers who prefer a text editor, it is my opinion that there probably does exist a pretty strong correlation on the basis (and assumptions) that programmers who are familiar with a text editor are older and therefore more experienced than those whose only real experience is with an IDE. If this is true, then the OP is generally correct (and it is obvious that he was generalizing).
This author takes full ownership and responsibility for the unpopular opinions outlined above.
"I work on firmware for slower microcontrollers that run at clock speeds from 1.8 to 16 MHz"
No wonder you can afford to use C! ;)
I can buy a $1.20 microcontroller that's more than an order of magnitude faster than the machine I learned to code on. Still, there are still times when a nice bit of assembly makes a big difference. Not much, just as much as you need.
As for the rest of the thread, assembly IS the bare metal. C is the next best thing to bare metal. Not to say that you should code everything in assembly, that would be silly. But being aware that it exists can't hurt.
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.
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.
When confronted with one problem, some think "I'll use recursion". Now they are confronted with one problem.
I think a lot of IDE's actually complicate the language though. When I do use the features, I end up having to go back in and rewrite 95% of the simple feature I just used at least 86% of the time. Another fear I have is that allowing to many non-schooled programmers into programming can really make it difficult when you have to try to figure out coding done by someone who doesn't have any conception of decent coding practices and naming conventions are. I do think that there are somethings which can be done more simply though, that being said; however, in the interest of some semblance of job security I'd prefer they not be too easy.
OpenGL doesn't encapsulate anything other than graphics. DirectX encapsulates input, 3D acceleration, sound, etc.
From a developer standpoint, DirectX is a no-brainer when it's available.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
But the OP may be right if it is statistically true (I don't know that it is) that there exists high correlations between "good" programmers preferring a text editor and/or "posers" preferring Visual Studio.
I'll buy the former, but absolutely *not* the latter.
Coding with a simple text editor, make/gcc/etc, and gdb implies a fundamental set of skills: familiarity and comfort on the command-line, ability to (presumably) write and invoke Makefiles, ability to use gdb (which, let's face it, ain't pretty for a newcomer), and so forth. So it stands to reason that there's a greater chance such an individual has the skills necessary to write decent code (also known as "trial by fire"), as a poorer developer would likely be scared away.
But I find it very difficult to believe that, given a population of VS users, there's a disproportionate number of crappy developers (ie, that the ratio of skilled to unskilled developers exceeds the ratio in the software developer population at large). A weak developer will obviously use any tools that make the job of writing code less daunting, and a good IDE definitely fits in that category. And a strong developer will use whatever tool makes their job easier, and guess what? VS is a *damn* good tool, particularly if you're targeting the .NET stack.
So I'd would say this: A developer that's happy using a simple text editor/compiler/debugger combo has a greater than average chance of being a good developer. But you can assume nothing about a developer who chooses an integrated IDE over the aforementioned environment if given the choice.
In fact, I would go so far as to say that any developer who actively *shuns* IDEs without good reason (and, BTW, simple familiarity is a good reason... mindless elitism, however, is not) deserves as much skepticism as one who isn't capable of using the editor/compiler/debugger environment, as they're expressing dogmatic tendencies that can be deeply counterproductive in the work environment.
Thank you, but that's not what I was asking,although the comparison is both interesting and informative. (to me, at least) What I wanted to know is why Linux devs don't feel the need for a Linux version of Direct-X. However, it occurs to me that you have answered my question, indirectly: OpenGL may not do everything Direct-X does, but it does enough so that Linux devs don't feel the need for a more comprehensive solution. Thank you again.
Good, inexpensive web hosting
I can't stand it when Microsoft developers talk about multi-threaded programming when the entire corporation has done that absolute bare minimum to make developer's lives easier. No wonder that they don't like using their own tools, because their tools are terrible.
Many years ago, a brilliant third-party multi-threaded library was released for Java, by a professor at Oswego university. I used it in several large production apps, and it absolutely rocked. You could build up safe, reliable, scalable multi-threaded applications by simply snapping together flexible pieces like Lego. It was so good that it became a part of the SUN Java standard library, and it's now called "util.concurrent". Compared to having to "hand craft" multi-threaded code in C++, it was wonderful. It's as if the lights had just turned on, and everything had become clear to me.
Now that I'm a C# dev, it's been a huge step backwards, doubly so because .NET was developed after the Oswego library was already popular, so Microsoft must have seen it and just flat out ignored it. For years afterwards, the whole entirety of multi-threading in both .NET and C++ were "threads" and "locks". The one nicety they included was an anemic thread pool in .NET which was just usable enough for the most basic tasks, but couldn't handle any real load. Even the locks were heavyweight inter-process kernel locks that are unusably slow for many tasks.
It's only now in .NET 4 (which won't be final until 2010) that they are adding a small set of very basic lock-free containers, light-weight locks, and actual interfaces that one can implement in order to customize behavior. It's all still very basic, and nowhere near as flexible, powerful, or comprehensive as the Java APIs that are years old now.
Microsoft's general attitude to API design is so bad that it can only be described as wilful ignorance. Reading articles evangelizing "modern multithreaded programming to better utilize new multi core processors" somehow feels like a religious zealot harping on about their appreciation of pure rational logic and science.
Linux video in general is a mess...
But open source developers have put a ton of effort into cloning DirectX in Wine, which is arguably a better solution given Linux's current marketshare.
Managed code takes some control away from the developer but is the developer having that control for the best?
For example, think of the type of errors leading to security bugs. A lot of them have to do with buffer overflows primarily in the area of string manipulation. These are easy mistakes to make in C or C++. Hell Microsoft and others have tried to modify the C runtime library to have "safer" versions of string manipulation functions because these errors continue to happen. Now consider a managed language like Java or C#. It's not possible to overflow buffers provided the buffer management code is sound. Instead of each mostly average programmer going through the process to manage buffers and reinventing the wheel, we have a few particularly talented people develop the code who specialize in that type of work.
Also think about memory leaks. Firefox is a prime example of a great open source program developed in an unmanaged language. Probably thousands of people have looked at the code and still some of the most common complaints are memory leaks. My feeling as for why that would be is that C++ makes it so easy to forget to deallocate memory that with a million line program, its just too difficult to find every possible leak. A managed language never has that problem. We have a group of particularly talented people develop a garbage collector and memory management system and the average developer will never have to worry about it.
Interesting. I have been writing Qt applications on Windows using MinGW for a while and just assumed my executables were huge because of Qt.
I just tested what you said, whipped up Hello World using libstdc++ and got an identical byte size as your own. It was 474990 bytes with debugging symbols in it!
I recompiled with -Os and stripped the executable and got it down to 265728. Jesus.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Judging by what GP said, it seems to be a library problem, not the compiler problem. I assume the way they wrote formatting code for iostream somehow references all locale facets, triggering their instantiation.
Still, iostreams are fat on any implementation Just checked on VC++2010 - with "optimize for size" it was 95Kb for a HelloWorld.
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.
It is pitch black. You are likely to be eaten by a grue.
Well, both of you are correct imo. Yes I prefer having to double click on the error in the IDE and have the cursor positioned on the correct line on the correct source code... except sometimes the indicated error has nothing to do with the actual problem. In practice, on non trivial projects involving many developers, libraries, inherited property sheets and complicated solution files, it is quite common that the error is due to something included before something else, or somebody changing an inherited parameter somewhere else in the code base. So yes in the end you have an error somewhere, but the cause of the error is not necessarily located there and may be very difficult to find.
Damn. I don't even use Java(I'm an embedded C guy), but if DL did it, then it's probably really good. As a C developer I feel the old pthreads style is a throwback to old multi-process hacks on SysV of 25 years ago.
What dragged you to the dark side anyways? (C#/.NET)
The Oswego library was the bomb. It's basically how APIs should be designed: Very simple looking abstract interfaces* with a bunch of reference implementations, some of which are incredibly advanced. You can then pick and choose what you want, reimplement anything at will, and combine like Lego. That guy saved me a LOT of time and bug hunting. Want a queue? Pick from four different flavors! Want priorities? Done! Want to keep the queue but change the execution style or locking mechanism? No problem!
As to switching, I've always generally been a Windows guy, and C# is currently the single fastest way to develop a GUI and not get "stuck" too much, because it can call C or COM style APIs directly. When it was first released, a good former Java/C++ developer could get started with it quickly, and develop GUIs 2-3x quicker than anything else, which then ran smoothly, and looked native.
I still get frustrated, especially with the lack of decent containers, algorithms, and threading frameworks, but C# is still overall the best. I do a lot of very Windows platform specific stuff like Active Directory manipulation, and it would be very hard to do that quickly (but correctly) with any other language.
Java is great for "server side" development. It has better database binding** libraries, threading, third-party support, containers and frameworks, and a much better community. However, its client-side is just terrible, especially the GUI frameworks. SUN apparently still hasn't learned the key to Microsoft's success story: own the client, and you will own the world.
It's only recently that Java IDEs got decent "drag & drop" forms development, while Microsoft is already a generation ahead with WPF which very cleanly separates code and layout, to the point that artists can do layout almost completely independently of the dev team. Think of what HTML and CSS tried but failed to do, but done properly.
*) Microsoft has an allergy to interfaces. It's like they're trying to tell you that they "own" the API, and you, the developer, should keep your dirty little mitts off it.
**) Microsoft's LINQ to SQL is practically a beta at this time. They don't even support multi-columns keys! Its big brother, the "Entity Framework" didn't support foreign keys until .NET 4, which is currently beta, and the GUI editor still fails on all but the simplest models. Something like 60% of the features, if used, disable the GUI editor completely. Microsoft isn't even planning to finish the EF framework GUI, ever. Every couple of years, they come up with a new data binding framework, drop the old ones, never finish it, and then they repeat, not having learned a single lesson. I've lost count.. there's been, what: DDE, ODBC, ADO, ADO.NET, LINQ, EF, and now they're up to some garbage called "M" or "Oslo" or whatever. I'm certain it'll be buggy, slow, incomplete, and replaced in short order. Just watch.
If only Microsoft's architecture and best practices groups actually worked to leverage the efficiency of the tools, rather than just drain it. The thing about Microsoft is that the tools are good, yes, but then they sell them with these practices and recommendations that just drain innovation and drags all developers down to a lowest common denominator.
It's really, Taylor all over again but applied to computer programming. The problem is, Taylor is what GM and Ford and Chrysler do, and the unions are locked in with. Just like we have pipefitters and machinist titles of varying kind on the shop floor at an old style manufacturing plant, we have guys that are being pushed into the database, u/i design, or middle tier roles, and really, 90% of all projects could be done with one guy putting together a half way decent screen in a craftsmen like fashion.
At this point, Microsoft is headed out just like GM - recruiting a lot of the best engineers, then just killing them in red tape, and delivering products that increasingly fail to captivate their market.
This is my sig.
But the GC does not solve two things:
1) Freeing up resources other than memory (this is only possible with a deterministic GC and RAII/destructors, or with refcounting instead of a GC)
2) Taking up tons of RAM because of unnecessary allocations (I've seen Java code that allocates MBs in tight loops...)
This sig does not contain any SCO code.
Please don't do that. I will hunt you down and deliver a round-house open-handed slap to your ear; rupturing your eardrum asunder. Consider that next year I might have to maintain your 512 column code. There is nothing more nauseating than opening someone's code in a standard xterm and seeing single lines fucking wrap around the fuck around the fucking terminal
Wouldn't it be easier to turn off line wrap in your editor?
This is my sig.
When I get an error, the compiler also points exactly to the line where the error is. So your insults are completely unwarranted.
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. :)
Not really. Compilers these days do a better job at optimizing most code than most assembly programmers (for well-supported CPUs anyway), mostly because instruction timing and dependency issues in modern complex CPUs are quite complicated, and compilers are able to take a lot more into account (just because the code 'looks' tighter doesn't mean it'll run faster). The only place where it really makes sense to use asm is for tight inner algorithm loops, especially when you can use SIMD instructions.
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.
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.
using System.Awesome;
Ask yourself why we have "builds", where everything gets rebuilt. Do I have to have my ICs re-fabbed when I change the PC board design? No. We're still not doing components right.
Historically, the big problem came from C include files. Everything but the kitchen sink is in there. There's no language-enforced separation between interface (the parts clients of the module see and may have to recompile if changed) and implementation (the part the implementations see). Also, you can include files inside include files, even conditionally. So developing the dependency graph of the program is hard.
C++ made things worse, not better. The private methods of a C++ class have to appear in the header file, which exposes more of the internals than is really necessary. Every time you add a new private method, the clients, who can never see or use that private method, have to be recompiled. This not only produces cascading builds, it discourages programmers from adding new private methods rather than bloating existing ones. That's bad for code readability and reliability.
Ada explicitly dealt with this. Ada has a hard separation between interface and implementation. This was considered a headache when Ada came out, but now that everyone has bigger monitors, it's less of an issue.
Java, despite having interfaces, seems to have build and packaging systems of grossly excessive complexity. I'm not really sure why.
The next problem is the "make" mindset, which is built on timestamps. "make" doesn't check what changed; it checks was was "touched". If "make" decided what had changed based on hashes, rather than timestamps, many unnecessary recompiles would be avoided. Something could run "autoconf", produce exactly the same result as last time, and not trigger vast numbers of recompiles.
There's also the tendency to treat "make" as a macro language rather than a dependency graph. This results in makefiles that always recompile, rather than only recompile what's needed.
It would be useful if compilers output, in the object file, a list of every file they read during the compile, with a crypto grade hash (MD5, etc.) of each. A hash of the compile options and the compiler version would also be included. Then you could tell, reliably, if you really needed to rebuild something.
People are reading a lot into this that isn't there. These people use Visual Studio, and I don't think they'd claim that using a GUI to design a...GUI is a bad thing. They're referring largely to the new modeling tools MS is pushing with VS2010, and they're saying sometimes it's quicker to just write the code than design the model. And indeed it is.
It's a tradeoff. For example, they already have some modeling tools (web service factory) for developing a web service. You layout interfaces, data contracts, message contracts, etc... and associate them visually. I think this sucks, personally, and I still just do it the old school (and much quicker, more powerful) method by creating an interface and data contracts. But for some scenarios designing the model might pay off in terms of self-documentation and allowing some standards to be followed by multiple developers working on a web service.
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.