programming and human factors
by Jeff Atwood
Charles Petzold is widely known as the guy who put the h in hWnd. He's the author of the seminal 1988 book Programming Windows, now in its fifth edition. And he can prove it, too. He has an honest-to-God Windows tattoo on his arm:
This is explained in his FAQ:
Q. Is that a real tattoo?A. I think of it more as a scar I got after doing Windows programming for ten years (beginning in 1985).
When Charles Petzold talks, with my apologies to E.F. Hutton, people listen. Charles recently spoke at the NYC .NET Developer's Group and asked, Does Visual Studio Rot the Mind?
It's a great essay. The central idea is that your skillset should not be dictated by the tools you use. I've covered similar ground in Programming for Luddites, so I don't necessarily disagree. But I also wonder if Petzold has fallen into the trap Dan Appleman outlines in RAD is not productivity:
The reason that so much bad VB6 code was written was not because VB6 was RAD, but because it was easy. In fact, VB6 made writing software so easy that anyone could be a programmer, and so everyone was. Doctors, Lawyers, Bankers, Hobbyists, Kids -- everyone was writing VB6 code with little or no training.Now, I don't know about you, but I still have copies of a few of the programs I wrote when I was just starting out, before I'd actually gone to school to learn a thing or two about software development. There was some BASIC, some Pascal, and looking at it now, it's all pretty ugly.
So let's get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code. RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.
Petzold's essay meanders a bit, but ultimately cuts a little deeper than "R.A.D. is B.A.D.":
Life without Visual Studio is unimaginable, and yet, no less than PowerPoint, Visual Studio causes us to do our jobs in various predefined ways, and I, for one, would be much happier if Visual Studio did much less than what it does. Certain features in Visual Studio are supposed to make us more productive, and yet for me, they seem to denigrate and degrade the programming experience.
Petzold argues that the cognitive model that Visual Studio forces on the developer is fundamentally flawed. This is essentially the same argument presented in Edward Tufte's 2003 essay, The Cognitive Style of PowerPoint.* Petzold goes on to illustrate with intellisense, which he has a love/hate relationship with:
But the implication here is staggering. To get IntelliSense to work right, not only must you code in a bottom-up structure, but within each method or property, you must also write you code linearly from beginning to end -- just as if you were using that old DOS line editor, EDLIN. You must define all variables before you use them. No more skipping around in your code. It's not that IntelliSense is teaching us to program like a machine; it's just that IntelliSense would be much happier if we did.
And then there's the issue of code generation:
Even if Visual Studio generated immaculate code, there would still be a problem. As Visual Studio is generating code, it is also erecting walls between that code and the programmer. Visual Studio is implying that this is the only way you can write a modern Windows or web program because there are certain aspects of modern programming that only it knows about. And Visual Studio adds to this impression by including boilerplate code that contains stuff that has never really been adequately discussed in the tutorials or documentation that Microsoft provides.It becomes imperative to me, as a teacher of Windows Forms programming and Avalon programming, to deliberately go in the opposite direction. I feel I need to demystify what Visual Studio is doing and demonstrate how you can develop these applications by writing your own code, and even, if you want, compiling this code on the command line totally outside of Visual Studio.
In my Windows Forms books, I tell the reader not to choose Windows Application when starting a new Windows Forms project, but to choose the Empty Project option instead. The Empty Project doesn't create anything except a project file. All references and all code has to be explicitly added.
Am I performing a service by showing programmers how to write code in a way that is diametrically opposed to the features built into the tool that they're using? I don't know. Maybe this is wrong, but I can't see any alternative.
In other words, a developer weaned on the Visual Studio .NET IDE is powerless outside that enviroment. Working in the Visual Studio IDE becomes synonymous with the very act of programming. And that's the thing Petzold is most afraid of:
[to solve a New Scientist math puzzle] I decided to use plain old ANSI C, and to edit the source code in Notepad -- which has no IntelliSense and no sense of any other kind -- and to compile on the command line using both the Microsoft C compiler and the Gnu C compiler.What's appealing about this project is that I don't have to look anything up. I've been coding in C for 20 years. It was my favorite language before C# came along. This stuff is just pure algorithmic coding with simple text output. It's all content. Even after this preliminary process, there's still coding to do, but there's no APIs, there's no classes, there's no properties, there's no forms, there's no controls, there's no event handlers, and there's definitely no Visual Studio.
It's just me and the code, and for awhile, I feel like a real programmer again.
Using Notepad to code may be an instructive exercise in minimalism for students, but no professional programmer can afford to build software this way. If anything, I think the future lies in even tighter coupling of the language and the IDE. I can even envision a day where it isn't possible to compile a program outside the IDE-- and that's probably heresy to Petzold.
But it's also the future.
* Tufte's essay is also available in parody powerpoint form.
Using Notepad to code may be an instructive exercise in minimalism for students, but no
professional programmer can afford to build software this way. If anything, I think the
future lies in even tighter coupling of the language and the IDE. I can even envision a
day where it isn't possible to compile a program outside the IDE-- and that's probably heresy
to Petzold.
There are a couple of professional programmers using e.g. vi for programming. There are thousands of programs that can be compiled using command-line-tools. Microsoft and Windows are not the whole world where software-development happens. E.g. on unixoide systems it's always the three-step-way
./configure
make
make install
to compile and install software.
Your vision is no vision anymore. If you want to develop software for console-systems it's quite often necessary to use the development-system provided by the manufacturer of the console. But as long as there are "free" systems in the world there will be a development being possible without being forced to the IDE of a specific company.
I was changing my IDE for software-development a couple of times, but I will never use an IDE that produces source-code that can't be compiled using another IDE.
Best regards, Lothar
without being forced to the IDE of a specific company
It's not about "being forced"; it's the 1000% increase in productivity you gain from an IDE that is tightly coupled to the language. It has a clear benefit to the user. That's a carrot, not a stick.
that can't be compiled using another IDE
It's hard to create source code that compiles cleanly on all the various FreeBSD/Linux flavors -- and that's purely at the command line!
But as long as there are "free" systems in the world there will be a development being possible without being forced to the IDE of a specific company.
Well, you can also build a house using only a hand saw, hammer, and other manual tools.. but all modern home construction companies use power tools.
I'm not saying you should be prohibited from building code in notepad-- but it's not exactly a practical or realistic example, either.
Jeff Atwood on October 25, 2005 5:49 AMThis strikes me as a similar argument to learning assembly nowadays. Is assembly/knowing how to build my application outside the IDE something I'm going to use every day? Probably not. I am more productive inside the IDE. But knowing knowing how to build my app from the CLI means that when something goes wrong, I have a better chance of finding the problem, and fixing it. I'm not stuck wondering what the generated code does, I know what it's doing. It also means that if I'm stuck on a machine that doesn't have the IDE, I can still get things done. (Although that's certainly a rare occurrence.) First? rule of code generation: If you can't do it by hand, you can't write the generator. (And you probably shouldn't be using one, either.)
Bryan Bates on October 25, 2005 6:07 AMIt's not about "being forced"; it's the 1000% increase in productivity you gain from an IDE that is tightly coupled to the language.
There is a difference between an IDE being coupled to a language and a language being coupled to an IDE as you described it in your vision.
With your vision there will be a lot more similar situations as you were describing yourself in
a href="http://www.codinghorror.com/blog/archives/000392.html"http://www.codinghorror.com/blog/archives/000392.html/a
"Well, after digging around (a lot) to find the DX 8.1 SDK that this sample is specific to, I came up with the C++ source for Moire. With the assistance of a coworker more versed in C++ than I, we managed to bundle Moire into a VS.NET 2003 C++ solution."
I don't find myself being confortable with knowing that my ability to compile my own work is dependent on the development-roadmap of another company conerning the IDE I'm currently using.
Since I started developing in Java, I was swtiching IDEs more or less every two years (vi - Visual Cafe - Netbeans - Eclipse). I can still compile all the code I was producing with every single IDE. The compiling/releasing here is completely script-based (with Ant) and is happening on a Linux-machine without any IDE being installed (doing the checkout from the repository, compile, jar together, do the unit-testing, ...) so being forced to a specific IDE when compiling would break things here.
It's hard to create source code that compiles cleanly on all the various FreeBSD/Linux flavors
No doubt on that, it can be even hard to compile it on different versions of Linux-distributions. But on no system I read in the INSTALL-readme to first buy a copy of SuperIDE by Linus Inc. to be able to compile a secific software.
Well, you can also build a house using only a hand saw, hammer, and other manual tools.. but all modern home construction companies use power tools.
Sure, but the people using these tools were learning everything with using hand-saws, hammer and other manual tools. And I don't think that people building houses would be happy if they are forced to buy BlackDecker-machines when trying to build a house in New York with a full stock of already bought Hiltis in their stock.
Best regards, Lothar
First? rule of code generation: If you can't do it by hand, you can't write the generator. (And you probably shouldn't be using one, either.)
Well, then I guess we should all be programming in assembly. ;)
Jeff Atwood on October 25, 2005 6:22 AMWhat bothers me is that these guys keep making the assumption that because the IDE does things for me that I don't understand what it does. Good "developers" will always understand what the IDE is doing for them under the covers. That's what makes them good. Sure, there are many people who couldn't open Visual Studio and create a Windows Forms project by first starting with an "Empty Project". But then again, that's because they haven't taken the time to understand the fundamentals. But that wouldn't change regardless of what the language required. Even if builds required you to create and maintain text based make files by hand (remember those days?) those "bad" programmers would find a way to cheat (can you say... "Google for sample makefiles"?).
There is blindly allowing the IDE to do your work and then there is understanding what the IDE is doing for you so that you can get your work done faster. It is simply a matter of reliance.
matt on October 25, 2005 6:29 AMMy biggest fear with the ide-language concept is new coders lacking the understanding of what is "really going on" if they always have the ide supporting them. Modern carpenters use power tools to build burb boxes and buildings and whatnot but what about when they need to do a little finishing work or they jump over to the custom cabinet business, when they have to work with things that don't come pre-cut and blue-printed? Trust me, from someone that just watched their townhouse get built they don't know much about the finer details and they aren't paid enough to know.
I think for your average zombie coder this approach is great, it helps keep things standard and you get something to market faster and more stable, a bit like when they throw down a whole suburban development. When you want to go out on the edge though I feel you better know how things work and that's really what working in Notepad gives people, the understanding of exactly what's going on. It's not an exercise in minimalism, it's in understanding. It's adding each line yourself instead of it being auto-generated so you understand *why* it gets auto-generated.
I don't really like doing everything in Textpad and I curse every time I need to work on some JavaScript but there have been many times I've needed to do things the IDE didn't know about and when I didn't get my Intellisense I didn't freak out. When I decided I didn't really want to init my controls at that point or that no, really, I don't want my class to descend from that one. A more responsive, understanding ide is great but only as long as I can ignore it and tell it to shup up when I need to.
Basically I still think the kids need to learn the Old Math before the New Math. Give them a super coolie whizbang ide that reads your mind but only after they can demonstrate that they *could* do it without it.
Shawn Oster on October 25, 2005 6:46 AMI don't understand this obsessive need to know everything that's going on under the covers. How much do you know about the databases you program against? How much do you know about the details of the graphics subsystem when doing UI coding?
Really, all a developer needs to know is enough to do his job well. If a developer successfully delivers software that was 100% created by a wizard, so the f what? He's delivering solutions, right?
If you need to dive on the problem, then by all means, dive. Learn all about the internals, learn about the code the IDE generates, if that's what it takes to get your job done, then do it. Who hasn't had to do this, to learn something completely new because the job needed it right then?
There is a universe of things to learn about software development. If you focus on learning stuff that's not directly helpful for your job (like building applications with the barest of tools), isn't that a form of premature optimization? In the universe of the things to learn, its usually best to focus on the things that are most relevant. Or to put it another way, all that code produced by the IDE is usually irrelevant to your job. If it ever becomes something you need to know, then that's the best time to learn it.
Damien on October 25, 2005 9:05 AMI agree! Look, I'll be honest and say I don't really understand assembly all that well. However, I seem to do just fine without knowing exactly how it works.
I've taken the time to learn enough about what goes on under the hood to be effective, but I don't really need to know every detail.
Likewise, if you're a good programmer, you'll take the time to learn what the IDE is doing for you, and you'll thank the IDE for doing it.
Haacked on October 25, 2005 10:20 AMI recently went through a very interesting excercise: I installed my own engine in my 1985 VW Vanagon (if you are interested: http://www.cloakofcarrot.com/gallery/1985Westfaliavanengineinstallation
)
I did some reasearch, tracked down three companies that built engines for these sorts of vans, chose one. Now the 1985 vanagon has a 1.9l engine, which is no longer made, and was quite unreliable. Fortunately, the engine builders are capable of manufacturing a 2.1l engine that is bolt-equivalent of the 1.9l.
This meant that all I had to do was take the old engine out, swap the parts onto the new engine and put it back in.
I am not a professional mechanic, but was able to work through the process, and the van has been running great ever since.
There are a couple of things to learn here:
1. Why didn't I build my own engine? Engines are a highly-domain expertise specific thing, and require special knowledge and tools to construct and test. Also - the market will not support a large number of engine builders.
2. By having clearly defined interfaces, I was able to not only change engines, but get a more powerful engine installed
3. It was reletively easy to do, as I simply had to have a good knowledge of the problems that were likely to occur, and the patterns required to solve them. I did not need a low-level understanding of how engines work, how to build engines or how to be a machineist....
This 'how low do you know' debate has been going on for years, and is really quite redundant. Different people are going to have different levels of understanding, and tolerance for complexity.
Those with skills and capability to handle the complexity should be involved in constructing lower level systems. But there is not a need for everyone to construct or understand things at a low level: the market will not support it.
The key is for those who engage in building these systems is to have clearly defined interfaces and patterns that will allow the rest to succesfully and effectively apply their creations to solve problems.
Why don't we all build our own computers and hardware from vacuume tubes and magnets? That way everyone would understand exactly how things work at the lowest level.
Each wave of development builds on the last, and the more recently you learn things, the farther away from the core you get. Certainly, you can spend the time to learn assembler etc, but those skills will not likley land you a job anywhere these days.
The only way to build bigger and more reliable systems is through the use of well engineered systems that can be built into a whole matching a design. The domain experts in building motors can build the motors, and a desginer who needs a motor to power a car or a plant, can select the correct motor for their design and be assured that if they build a system that gives it the right coolant, fuel and oxygen that it will power their system reliably for the specifications provided.
That is how things are done in the engineering world, and that is the way things will continue to move in thes software world.
Why don't we all build our own computers and hardware from vacuume tubes and magnets? That way everyone would understand exactly how things work at the lowest level.
Charles Petzold has an excellent book, "Code: The Hidden Language of Computer Hardware and Software" which does exactly that:
http://www.amazon.com/exec/obidos/tg/detail/-/0735611319
It's a fascinating and beautiful book, but it's also irrelevant to most modern programming.
Jeff Atwood on October 26, 2005 3:59 AMI can hand cook a fancy curry for dinner when I've got time, but during the week I'll cook a curry from a jar of sauce.
Doing it by hand takes longer, but lends itself to a better produced and more delicate flavour.
The jar curry always tastes the same.
But sometimes I add a few of my own ingredents to the jar curry, to freshen it up.
Once you know what you're doing, then you pick use the correct tool and resources for the job.
Peter Bridger on October 26, 2005 9:59 AMI can even envision a day where it isn't possible to compile a program outside the IDE
I am sure Microsoft cannot wait for that day.
Tod Birdsall on October 26, 2005 11:56 AMDamien, if you said "I don't understand this obsession about understanding whats going on behind the covers" during an interview, I would stop and send you home right there.
Not knowing what goes on behind the covers, or understanding them, is what leads people to write bad code. And people who have no interest in how or why things work often make the worst developers; they're people who are coding because they have to, not because they want to. As with all art, it is an innate interest, and innate fire for what we do that helps us do it well. Anyone who doesn't see programming as an art is just a shitty code who does it because he has to.
Lothar, Visual Studio generally does NOT produce code that cannot be compiled by another IDE, except for the situations where it is trying to augment C++ to allow it to talk to COM/.NET better. Even in those cases, the IDE and the actual compiler are seperate entities.
The "Wizards" that people depend on are nothing more than code generators, and in general that code is really just code; comments can be used to help the wizard update the generated code. Regular patterns are used to help tools understand what they (or you) wrote. In the case of .NET/Java, introspection can be used as well.
These tools just save you the trouble of writing repetative code yourself and developing a framework/pattern for how to do certain kinds of menial tasks. It's not magic, its just pre-canned grunt-work that has no connection to the IDE itself.
Just a little side note; that I have to write my 13 times to make it compile on each of the 90 flavors of Linux is the very reason I choose to do all my development on Windows.
One instruction set to rule them all,
one API to bind them, and the darkness.
One compiler to bring them all
and in the linker bind them.
Ugh I had a typo :(
One instruction set to rule them all,
one API to bind them,
One compiler to bring them all
and in the linker bind them.
Boy, some of the comments here don't align with my experience. IDEs are more than just wizardy things for laying out dialogs or generating code that you'd prefer not to write. A good IDE is an excellent tool for understanding and managing a large body of code: What are the arguments to this method? Who calls me? Show me the implementors of this method? Where is this class defined? The IDE isn't just a text editor, it has a deep understanding of the language. For refactoring, an IDE can make like much easier: I want to change a method name and all of its callers. I want to encapsulate this common chunk of code as a method. This can be powerful stuff. Just look at the refactoring support in Eclipse and IntelliJ and now appearing in VS 2005.
I'd be unwilling to give up the productivity gains from using a good IDE. It's not that I can't code without one -- I did for years and years before. But without the IDE it would probably take me longer to do. Why should I waste my time?
Bob on October 27, 2005 8:32 AMif you said "I don't understand this obsession about understanding whats going on behind the covers" during an interview, I would stop and send you home right there.
But I don't think that's what he said. What he said was..
If you need to dive on the problem, then by all means, dive. Learn all about the internals, learn about the code the IDE generates, if that's what it takes to get your job done, then do it. Who hasn't had to do this, to learn something completely new because the job needed it right then?
In other words, Just-In-Time learning. I agree. Why learn a bunch of crap you'll never need?
Of course by that same argument, I should never have gone to college. :P There's definitely a balance level you want to achieve between JIT learning and background learning.
Jeff Atwood on October 28, 2005 4:50 AM" Why learn a bunch of crap you'll never need?"
Because if you know that crap, you will use it when it is most suitable.
If you never learn it you will be limited to knowledge you already got.
Some may be comfortable with that, but I see it as limiting.
One the other hand - if you need and IDE to manage the language, maybe it is time to look for another language?
Rimantas on November 22, 2005 7:45 AMI see a common decomposition of developers. Developers that write code because they love to code, and those who write code for a living, or because they have to.
This reminds me of a McDonalds training video from 1985 that I found online. It basically taught that enthusiasm is contagious, if you act excited and happy about what you are doing, you will be, and so will the people around you.
In the same respect if you love to code you will learn everything you can so that you can do it better, you will become more knowledgable and people(especially from camp 2) will rely on that knowledge.
We recently needed a new developer for our team, we interviewed people for over 4 months trying to find someone to fit the position. I intervied numerous people, and one thing I asked often was whether they ever wrote code at home after work or on the weekends. Frankly I was suprised how many people said no! Eventually we found somebody that loves to code, and know what? When I need him to do something he has a very solid foundation, he knows how memory is laid out, he knows what the IDE and the framework are doing. If he doesn't know what it is doing he opens up ILDASM(we are a .NET shop after all) and reads through the function. I don't have to pay him to spend days learning another vertical system because of the low level pedistal that he already sits on.
I feel sorry for people that code because they have to. As for me a day barely goes by when I don't write code at home, and a day never goes by when I don't learn something to support my higher learning.
Josh Perry on December 3, 2005 4:36 AMThe kind of people that doesnt know how to code outside the IDE usually doesnt know (or care) why his program runs slow, if it only does
void strcat (char *dest, char *src ) {
while (*dest) dest++;
while (*dest++ = *src++);
}
and they even tested it:
char str[255]; str[0] = '\0';
strcat(str,"Hi ");
strcat(str," All the people");
My concern with IDEs is that at some point they stop being the tool and become the problem.
Jeff said:
"It's hard to create source code that compiles cleanly on all the various FreeBSD/Linux flavors -- and that's purely at the command line!"
Which is true - there's way too many variations to worry about.
So why add IDEs to the mix? It's a tool - the difference between a hand saw and an electric should be time, not quality. Ideally, the end user shouldn't be able to tell the difference. And the person who comes after you should be able to use the IDE of her choice (even if that's Notepad) without problems.
Allen on April 25, 2007 9:41 AMThe answer to making programs faster is not better IDE's, it's better libraries. If windows programming is so full of boilerplate the IDE needs to write it for your, the GUI library is at fault. You should always attack the cause, not the symptom.
Steve on April 25, 2007 10:45 AMWhy your "Enter the Word" captcha image always have only 1 word "orange". I mean this is not a real captcha image. Isn't this unsafe?
mahernoz on May 1, 2007 11:20 AM[quote]Why your "Enter the Word" captcha image always have only 1 word "orange"[/quote]
Cuz it's a windows style security captcha, it only misses the "are you sure?" message.
captcha spammer on June 2, 2007 10:17 AMIf anything, better tools provide faster programming. Assuming that the code that was developed faster has the same quality as the code that was developed slower, this is a good thing.
But the IDE can become the problem very easily and sometimes Visual Studio IS the problem. I remember developing MSVC applications with Visual Studio 6. I really liked the IDE, it was robust and reasonably fast (unlike its successors), but in certain situations it provided you with incredilby bad code and you had to spend quite some time to make that code better.
My favorite example are (or were) dialog classes. Each dialog gets its own class and when a dialog needs to be opened, you create the corresponding object and tell it to run. But most of the time, dialogs are shown to get some input from the user. And how did MS think we should get a hold of the data from the dialog? By accessing its member variables that were of course all public by default. Now if that isn't bad programming, I don't know what is. But the style was encouraged heavily.
Manni on August 22, 2007 1:47 PMwell... all said good! ill just add me two cent rant.
notepad.exe is the most hideous/absurd/useless piece of software that came from an operating systems giant!
notepad++ comes fairly close to being a good tool for a developer (yes, it is* about developers. other people can suffice with word!). but the real power lies in legendary text editors (veterans?) like Vim and Emacs. Vim, 30 years in service and still fresh is my new most favourite tool!
Visual studio is great. Its a great debugger utility, its a great file/projects/solutions organizer. Its helpful with c#/VB for intellisense. But for a hardcore c/c++/asm developer its pretty useless. Heck you have to dive deeep deep into visual studio to actually know what command line compilers are available and how to use them. And then again, you will find them when u know what ur trying to find. MS loves to create consumer products. I wish it werent so. PowerShell? yes... but i guess its pretty late.
zakimirza on August 29, 2007 10:27 AMAm I the only one who is reminded of SmallTalk? Tight coupling of language and IDE isn't the future, it's the past. An interesting past, for sure.
SmallTalk's structure is really great. I learned it after a history of almost 20 years of coding in all languages I could get my hands on, and at first I was alienated by the concept of no compiler, no source files, nothing resembling traditional development. But I gave it a chance, and it's amazing. With modern SmallTalk implementations like Squeak, you can write fully working GUI applications without a single line of code. No, not even the usual one-line button click handlers. The development environment is up to par with commercially successful IDEs, and yet I didn't find it annoying at all (which IDEs usually get me), because the IDE is not just tightly coupled, it /is/ the language. And if you say, hey, that's the future, I'd gladly agree. Of course, SmallTalk has other deficiencies (although most aren't really deficiencies, they just stem from the unusual language concept and would be called innovations today), so it didn't prevent C from being invented/becoming popular. Still, what you describe predates even C itself.
But please hand me over my text editor for all common programming languages, including C-alikes. If it gets stored in files, I'd rather choose the text editor that fits my style of working best. I hate being forced to do things a certain way with IDEs. A really good text editor with a separate UI designer and a decent language concept for integrating both beats any IDE for all commonly used languages, IMHO.
jwalt on December 29, 2007 12:44 PMThe problem with VS 2008 is the code it generate is in the wrong layers. I hate having data access code intermingled in the UI layer.
MSFT is promoting n-tier development and their tools are not even compliant.
Moreover simple things like native data binding is missing. How can any company be so behind the times not to natively allow a UI control to bind to a data business object property? FoxPro can even do that. Not to mention VS class designer is missing visual inheritance for UI controls. Foxpro is closer to a RAD tool then VS. Moreover VS falls well short of the claims being made by Microsoft.
"the guy who put the h in hWnd"
Oh dear.. is that in VB?
Q on June 6, 2008 11:43 AMthe guy who put the h in hWnd
All this time I was blaming Charles Simonyi - with his Hungarian Notation - for making Win32 code such an ugly, unattractive mess to read. Now we have another culprit... :-)
Thank god we are now in the era of .NET and there is no longer a need to wade through such eyesores to code for Windows.
Web Mechs on August 13, 2008 5:57 AMWith the rate rapid rate of change, it is very difficult to keep up with the latest tools and technologies.
Even more difficult is keeping up with what is really going on under the covers of these various tools.
At some level we all have to look a black box and say "that's magic" -- then move on.
Mel Gibson on February 6, 2010 9:45 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |