Paul DiLascia Interview – October 27, 2003

Translation by Aleksey V. Dolya, reprinted courtesy of Russian MSDN (January 2004 issue).

Paul, could you tell us about yourself (childhood, education, hobbies and etc.)?

I'm not sure my baby life will be very interesting to readers, though I did supposedly once write on the wall with my own poop. Whether it was in C++ or Perl, I don't know. I grew up in Manhattan and went to a special High School for smart kids. I went to Columbia and MIT, where I got my bachelor's degree in Mathematics. I studied at Harvard for a year working on my PhD, also in Mathematics. Betrand Russell said, "Mathematics may be defined as the subject in which we never know what we are talking about, nor whether what we are saying is true." As far as I can tell, this is true.

How did it happen that your life is connected with computers and programming?

Does anyone ever really know how they end up where they are? When I was a teenager, a college student I knew had an Altair 8800 kit computer, the first commercially successful personal computer, which appeared in Popular Electronics Magazine in 1975. (See By an amazing coincidence, this was also the first computer to run Microsoft software! You had to load the boot program in binary using toggle switches, then load the Basic interpreter from paper tape. I think it had 16K of memory, which nowadays isn't enough to hold even one file on some versions of Windows! I wrote a 3D Star Trek game in Microsoft Basic. But this was merely an amusing hobby. I always figured I'd become a serious Mathematician.

When I got to Harvard, I soon realized I'd have to learn 2000 years of mathematics before I could contribute something useful, whereas in software I could contribute right away. Plus, I'd make more money and have prettier girlfriends. So I quit math and got a job as a programmer. In those days, programming was so new anyone smart could get a job. It's like there were 10,000 programming jobs and six people with computer science degrees. Now it's the other way around: even your grandmother from Ufa can write "hello, world" in Visual Basic, and there are PhDs on the unemployment line.

One of my first jobs was at Infocom, a company that produced a line of adventure games including the famous Zork series. This was around 1982. I wrote the Zork interpreter for the Commodore 64, one of the early and most successful home computers. The C64 sold 20 million units worldwide (see Every time I tried to run my program, the disk broke. The same thing happened every time: I would type Run and the disk would make a loud CRACK! and never work again. I went through about five disk drives before we finally called the top hardware expert from Commodore. He got angry, as if it was my problem. Why was I writing such bad code? I said, "Hey, buddy—the hardware is supposed to be independent from the software! No matter what I do, it should not be possible to break the disk!" So what was going on? It turned out I was writing to the outermost track on the disk, which no one had ever tried before. So the head would fly to the outer part of the disk—but there was a mechanical stop that was too close. So the head would slam against the stop and break.

Imagine writing software that breaks the disk—those were the days!

Where do you work now and what are you doing?

My only official job is writing for MSDN Magazine, but I also do various consulting projects of diverse natures, if I find them sufficiently interesting or challenging. On my website I do my best to make it seem like I don't want to work, but for some reason people keep hiring me! Oh well. I've developed a couple of commercial web sites like I think web programming is more fun than Windows and Perl is more fun than C++. But my true passion is in the arts—writing and digital collage, which I'm just beginning to develop seriously.

Where are you an expert?

I hate the term "expert" because one thing I've learned from writing in MSJ/MSDN for over ten years is that no matter how expert you think you are, there's always somebody who knows more. Being an expert means I learned something ten minutes before you. With over 100,000 readers, there's always someone who knows more about something than I do. It's very humbling and scary. It keeps me on my toes and always ready with anti-anxiety pills!

The most important skills for my job are 1) the ability to very quickly absorb new technologies and information; and 2) the ability to communicate in a way that's clear, concise and entertaining. The trick is not to know every answer, but where to find it quickly. Then, you have to communicate. If I'm expert in anything, it's this.

You are a C++ columnist in MSDN Magazine. You answer the questions about native C++ (mostly MFC) code. Do you choose the questions by yourself? Or you answer all the questions?

Мой бог! There's no way I could answer all the questions! I get five or ten a day. Some of them are completely wacko. Like, How do I program in C++? or, How can I get a job at Microsoft? Someone once asked—I'm not joking—"How can I be more like you?"

At the other extreme, I get questions so esoteric that all I can say is, "Sorry, dude, I can't help. You obviously know more about it than I do!" The worst is when someone sends me two pages of C++ code and then asks me to find the bug. Those I don't even bother responding. I try to always reply, even if the answer is "I don't know." But probably around half the questions never get answered. Some day I'd like to write a column of funniest questions—but I don't think the folks in Redmond have a sense of humor.

What I do is try to select questions I think will have broad interest to many readers, the kinds of everyday things most programmers need to do. Like how do you put a bitmap in your menu? How do you get the machine's main IP address? How do you customize the File Open dialog? How can you call Win32 from C#? I have no particular desire to show off. I'd rather answer a simple question if I think it will help many readers, than a sophisticated one that makes me look smart but only five people can understand. Of course, if people want to think I'm smart, it's OK. Occasionally I come across something I think is important for readers to know, so I make up the question myself in order to explain it. Perhaps I made up some of the questions in this interview. How would you know?

Where did you get your C++ experience and knowledge?

From writing a book. The best way to become an expert on anything is to write a book about it. People will think you're an expert, whether you are or not.

When C++ first came out, I thought it was the best thing since microwave popcorn (do you have microwave popcorn in Russia?). I just had the feeling it would be big. The first C++ compiler for PC was Zortech. It came out around the same time Windows 3.1 was starting to grow, around 1991-1992. I'd been programming in C on Vax/Unix, and I wanted to move to C++ and PC/Windows. Nobody knew how to program Windows with C++. (This was before OWL or MFC.) So I built my own framework and wrote a book describing it, Windows++. Writing a book is like teaching. In order to explain something to others, you must understand it ten times better than they do. Of course, I've also spent years writing software for companies. But building the framework and writing Windows++ taught me the most about Windows programming in C++. My framework looked remarkably like MFC, even though I wrote mine first. People still read Windows++ today, even though it's out of date.

One day I got a letter from a man in England who said he'd met a German man while he was in Berlin. The German man gave the British man a letter addressed to me, which he had received from a young Russian man while he (the German) was in hospital in Berlin. The Russian man wanted to know if it was OK to translate my book Windows++ into Russian. He said there were many such bootleg books in Russia, distributed by hand via floppy disk, but since he liked my book so much he wanted to ask permission. So he wrote me a letter in Russian, which the German translated into German and the Brit into English, before finally sending to me. It was all very mysterious, like spies in the night. So I wrote back, "If you want to translate my book into Russian, God bless you!"

Why did you choose C++ as an area of your expertise?

I never consciously chose it. I was just doing what I thought was fun.

Do you use .NET-code in your work?

Only when I write about it.

How do you find .NET in general?

First, I should say that I will answer speaking for myself, not Microsoft.

The best thing about .NET is the interoperability and language-neutrality. .NET is the first system for writing reusable components that isn't agonizing to use (COM is agonizing). In .NET, everything is easy. You can write in any language and everything works. The interop services are amazing. Any time you want, you can call directly into the Windows API. The interop services know how to convert/marshal everything. If not, there's a way you can tell it. This is how programming should be!

The worst thing about .NET is Windows.Forms. I honestly don't see how anyone can write a serious GUI app with .NET, and I would never use it for a standalone Windows program. It's too slow and you can't access all the operating system features you need. On top of that, too many classes are sealed, so you can't override them. For example, you can't customize the File Open dialog, which is one of the most common things programmers do. If you use Windows.Forms, you'll end up writing half your code interop anyway, if not Managed C++, so what is the reason for using .NET?

It amazes me how much confusion there is about this whole issue of .NET versus C++. The real issue is not which is better? The real issue is: for what purpose? If you're writing a web application that accesses a database and talks to remote components, or want to build a prototype quickly, you're probably better with .NET. If you're writing a standalone Windows program to edit music files or a shell extension, you're better with C/C++. So it's not which is better, it's what are you trying to do? You wouldn't use a hammer to drive a screw, and you wouldn't use a screwdriver to drive a nail. To be a good programmer, you have to know which tool is best for which job.

So many programmers, including even professionals, fail to understand this. Just today I was reading an article called "How to port your C++ code to .NET." Nowhere in the article did the author even address the question: Why? Why would you port you C++ code to .NET? Because Bill Gates told you to? Too many programmers fail to think. They adopt the latest new thing just because it's new, without asking why. You shouldn't use .NET—or C++, or any other system—because someone told you it's cool or you want to impress your friends. You should use it only if it solves some real problem you're having. If you don't know why you're using something, don't use it! And if you really need it, you won't have to ask why, because it'll be obvious. This is common sense.

What's your opinion about using C++ for writing .NET-code? Do you have any ideas about new C++/CLI?

If you like C++, go for it! The Managed Extensions are really cool, they make C++ a full .NET citizen. But again, I would ask: Why? C++ is good for GUI apps that need to be fast and close to the operating system. If that's what you're writing, what are you using .NET for? C#/.NET is better for web apps. If you're doing that, why are you using C++? Programming languages are not ends in themselves, they're a means to an end.

As for new ideas about C++/CLI... Please, I have enough to think about already!

How often do you write code?

A rarely as possible. Unless it's in Perl.

What developing tools and compilers do you prefer?

I use the Microsoft compiler of course, but I don't use the Visual IDE. I can't stand IDEs. They make me feel like a pianist with no fingers. I use a text editor called Epsilon, which is based on Emacs, the most powerful text editor in the known universe. It's purely a matter of speed. I mean, who can program with a mouse? I can write code ten times faster with the keyboard. Young programmers who've never seen a real text editor are amazed when they watch me edit. I press two keys and nine things happen—the code seems to move by magic. If you blink you'll miss it. In Visual Studio, if you want to change the text of a control on your form, you have to type it into a box that's so tiny you can't see both ends of the sentence you're typing!

But please don't use Epsilon because I do! You should use whichever editor you like best. If you're a mouse person, who am I to argue?

The only other tool I use is the debugger. But I only use the debugger as the last resort. I can usually find any bug by inserting TRACE or printf statements that show what my program is doing, and one of my favorite tools is my TraceWin program, which displays the TRACE output in a window (you can download TraceWin from The way I like to work is to start with something very, very simple—then gradually add features one at a time. I write a few lines of code, then compile/run/test. If everything is OK, I write a few more lines, then test again. If you only write ten lines of code each time, it's easy to find the bugs! Where I always get into trouble is when I write 250 lines of code before testing. Then I have to spend an hour debugging—Yuk!

What do you think about the future of C++?

Many people think C++ is dead because there's all this new stuff coming out and Microsoft has stopped improving MFC. To me, that's the best thing that could happen to MFC! I mean, do you really want to be trying to write your program with a system that changes every three months? Do you want to be Microsoft's beta-site for the rest of your life?

The real shift is not from C++ to .NET, the real shift is from standalone apps (.EXEs) to web apps. So the real issue is not C++ versus .NET, the real issue is: will people still be writing standalone apps in ten years? To the extent people write more web apps and fewer GUI apps, C++ will decline as a slice of the total programming pie. But there will always be a need for standalone apps, fundamentally because the web is slow and because there will always be some things you want to do on the local computer without going out to the web. For standalone apps, C/C++ remains the most effective programming language. And what about all the servers? No one is going to write a web server in .NET!

Don't forget, Windows itself (as well as Unix/Linux) is written in C and exposed thought a C API. As long as that's the case, C/C++ will remain the most direct way to interact with the operating system. Even with MFC there are many parts of Windows not encapsulated, so you have to either write your own little class or call the C API directly. This is so natural most MFC programmers don't even think about it. Perhaps some day Windows will be rewritten in a high-level language with a runtime system similar to the CLR. Then C++ might finally fade. But I wouldn't hold my breath. That kind of shift will take decades, not years. There's too much code already written that has to be supported.

So in short, I think C++ will remain vital for a long time. Probably at least until you die. After that, why would you care?

And MFC?

Same answer. The fact that Microsoft doesn't plan to improve MFC means to me that it's stable, and therefore even more desirable as a programming system.

What's your philosophy of programming?

We have an acronym in English: KISS. It stands for Keep It Simple, Stupid. Programming is all about managing complexity. Therefore, anything you can do to make your program simpler translates into faster development, fewer bugs, greater reliability, more security. Unless you're writing games, users don't care about colored buttons or animated menus. What they care about is whether your program works, whether it destroys their data or not, whether it's quick and easy to use, whether it helps them get their job done.

Too many programmers spend all their energy implementing some cutesy UI feature like docking windows or pink scrollbars because they saw it somewhere else. If you're writing a sophisticated image editor that has fourteen toolbar palettes, then you may really need docking windows. If you're writing a program for six-year-old girls, you may need pink scrollbars. But for most programs, these features are a waste of your valuable time. You'll make more money if you implement boring but useful features like printing and batch mode. Microsoft has 5000 programmers to create animated paper-clips. You don't. Don't fall into the code envy trap!

The most important parts of a program are invisible: reliability and speed. Even the user interface, if it's really good, is invisible. When you get in a car, you don't think, "OK, I want to go forward, so now I must press my foot against the accelerator." You just do it, and the car moves. The car becomes an extension of your mind and body. That's how your GUI should be. If the user has to think, you've failed.

Another big mistake programmers make is they fail to spend enough time on design. I'm not talking about stupid design—like using flow-charts or abstract modeling systems—I'm talking about a written specification that says what your program does. What features will it have? What commands and toolbars? The most important thing to know is: What problem are you trying to solve? As a rule of thumb, you should spend about half the time on design. If you can't articulate what it is you're building, how can you possibly succeed? Too many programmers start compiling before they have any clue what they're trying to do. Because I write so many little programs for my columns, I've learned this the hard way. When I race to the keyboard to answer a question, I always make more mistakes and have to throw more code away, than if I first sit down, think about what I'm going to do, and jot down a plan of attack. How could anyone build a skyscraper without a blueprint? And yet programmers try to do exactly this.

So my message is: Make your program work. Make it reliable. Make it fast. Make it easy. Don't get side-tracked implementing the latest GUI feature you saw in Word or Excel. This above all else: Know who your users are and what they're trying to do. Then design a program that lets them do it, with as little fuss as possible. Don't get in their way and don't waste their time. Treat your users with great respect, as if they were guests in your home. This should be easy, since Russians are known for their hospitality. If you contemplate adding some new feature, ask yourself, "How does this feature help my users?" This applies to all programming, whether it's a GUI or web app, whether you write in C#, C++, Perl, VB or Java.

Have you ever been to Russia?

No, but I hope to visit some day. A few years ago, I studied Russian one summer, hoping to visit St Petersburg for the White Nights. I'm afraid I got bogged down with other projects and never made it. Russian is the hardest language I ever studied. I forgot most of what I learned, because I never have reason to practice. When I was learning Russian, I wrote a little program I called YazMan (Язык-Man) to memorize words. The program displays a word like book in English, and I have to type the Russian книга. If I get the right answer, it sounds a bing and shows a smiley-face. If the answer is wrong, it goes buzz and displays a frown. You can ask for a hint and it shows the first letter of the word. I used MFC and KOI-8. My teacher (a lovely Armenian woman who fed me delicious sweets and Turkish coffee before each lesson) loved it so much she wanted to buy it and start a business! I felt guilty taking money for a program that only took one day to write, so I gave it to her free.

I've always been fascinated with Russia and Russian history. You have such beautiful music, art, literature... Such beautiful, sensitive, intelligent people... But such bad leaders and political systems! This seems to be the Russian curse. I was always fascinated by the period of 1917 and how the Bolsheviks were able with so few people to seize power. But I think maybe you are on a happier course now—at least I hope so!

Do you know Russian language or maybe any words?

Повторите, пожалуйста. Я не понимаю. Где Москва? Где метро? Я не знаю. Я не русский, я программист. У мена компутер. Я не говорю по-русски. Вы говорите по-C++? Добрый ден. Очень спасибо! Пока!

Would you like to tell our readers anything at last?

Life is precious. Don't forget to have fun!