Sunday, December 16, 2007

C++ Development on Linux

My new team at Google uses C++. After spending the last 6 months in Java and JavaScript, I welcomed the opportunity to work again in a language I know well and like a lot.

The team is tiny, and at first the fact that there isn't really a setup for debugging struck me as odd, but explainable. I was coming from the environment where everything started with instructions (or creating thereof) on how to build and run the project on the local machine. The road traffic team runs everything, including the dev builds, in the data center, but in a pipeline that is different from production.

But how do you debug? Well, that has not been figured out yet. Currently with printfs and logs.

Ok, weird... So I, too, used the printf in developing a new little feature that I wrote first, I, too, set up a special pipeline for myself to run, and used the logs. Then I went to a python class, and that was an impetus for me to look into running everything locally - I wanted to use the new skills.

The very first stage of the pipeline worked just fine, but the second did not work. There is no way I could debug thousands of existing code with printfs, so I set out investigating Linux debuggers.

What I discovered was truly horrible. The only debugger I could find was gdb - a command-oriented debugger with no UI whatsoever. If you come from Windows environment, think ntsd, but without extensions. On top of it there is ddd - a windbg-like shell, only an order of magnitude more primitive.

Used to the richness and power of Visual Studio? Tough luck, my friend, welcome to the best 1975 can offer! Back to the future...

To the developers who say that Linux is a better development environment - you are crazy. Patently insane! You just have no idea! You only use Linux because you've never been exposed to programming the way it is supposed to be done. And the people who do switch platforms never come back, so you do not hear from them.

Proof? There is Emacs emulation in Visual Studio, but there is no Visual Studio emulation in Emacs. You cannot claim that this is because Emacs keystrokes are more intuitive - it is probably because the people who leave the Unix environment to program Windows never come back...

It looks like Microsoft is really the only company that is spending big money on courting developers. It is unfortunate that with Vista release it appears to have just put a bullet through its head. I don't know if it will recover, but I hope to god it would, because otherwise there is not going a company that really cares about the developers. And the world will have no alternative to gdb.

12 comments:

Илья Казначеев said...

you are crazy. Patently insane! You just have no idea! You only use Linux because you've never been exposed to programming the way it is supposed to be done.
Maybe you didn't try to write code for wince (what a name!) with eMVS?

No debugger, no command line, no stdout, no nothing. Well, there is supposedly a debugger, but I don't think I can get it to work in realistic time frame given how 'fine' basic tools like activesync work.

There is Emacs emulation in Visual Studio, but there is no Visual Studio emulation in Emacs.
Given extensibelity of Emacs you probably could make one in a few hours. Given that, I guess there are a lot of emacs VS keybinding solutions lying around, just find one.
Emacs is plugin-oriented not monolyth-oriented. That means they aren't going to ship everything in base install. You may not like it (well, I don't like plugin-oriented apps), but it's their way.

As for the rest, sorry, but you look like padawan linuxoid which is amplified by the fact that you're forced to use linux.
You don't *get* the system and you don't want to understand it because, well, you're forced to use it but ain't going to marry it.

That's a sad setup for both you and your linux :)

Anonymous said...

In my experience (a Windows C++ developer switched to Linux) Eclipse + CDT (C/C++ Development Toolkit) worked quite well. Eclipse is comparable to Visual Studio as an IDE and its integration with GDB is quite good.

DzembuGaijin said...

In good old times when I managed insanely HUGE team of developers :-) ( not anymore !) making Linux Based Print Server ( that RULEZ! and #1) (Pingo http://www.canon-mj.co.jp/pixel/lineup/clc1180ga/pingo-cs.html) I touched Linux development myself for a little bit. It was not too bad so, there are debugger we used that looks nice enough : DDD
http://www.linuxjournal.com/article/2315
I think. Of course I did not feel as at home as with good old Windowz...but ... it was fine: you can always get help and information and ... I spent much more time on real stuff so ( debugging of Canon h/w protocol and Color Management for stupid Pixel copier) Of course my developers took major hit and they all beached and moaned about how bad Linux is. ;-) So I do understand how hard it can be to move to Linux from Windows. But if you look back on Windows Home Server : all this infrastructure is also very complex: you just know it much better. Eventually you will learn all, you are very smart and you will be very well at home: may be you will even write your own tools or find some that do it for you. My last word : nothing yet compare to simplicity and joy of my old 286 DOS based computer that I booted from 5'' Floppy and start TurboC with single stroke. It complied like MAGIC ( Wooooosshhh!) Project file was simple TEXT with list of files ! Program was just one file and it just fucking worked ! I wrote GUI based WAV file editor with mouse support and stuff - that included "mini windows" from scratch! under DOS with a very limited real word experience and it worked! .. just learning plumbing needed from Borland's samples. TurboC has debugger of course and worked VERY VERY FAST. You know... I miss this SO SO SO much ... My 286 did not even had HD ! ( till a got my first IT job and got it used for insanely big amount of cash) Today... well, there are probably nothing like it. I hate VS so much for being huge and so stupid and slow ( Everything is HUGE and SLOW today :-( - SUX!!!!) . There are million options, I have to configure all locations. Like ... well, it is fine, but not walk in the park one would expect after technology supposedly improved :-) Hey... it did not ! :-)

Sergey Solyanik said...

To Ilya:
Actually, I've spent 6 years writing code for Windows CE at Microsoft. The worst we had was windbg, which was light years ahead of gdb. But we pretty quickly ported a Visual Studio debugger, which made kernel debug experience on WinCE the best I've ever seen - unlike NT you could step in and out of kernel, cross process (PSL servers), etc. That was amazing! So when I went and worked in NT base I was taken aback by terrible tools (kd) that most people used. But even kd can be used with windbg!

WRT command line tool - I personally wrote CMD and console implementation for Windows CE, ported it to PPC and published it. For a while it was one of the most frequently downloaded PPC tool :-).

Emacs - believe me, I looked! There is one very half-baked attemt to do it. It looked so scary and preliminary that I was afraid to try it.

To behemoth:
Yep, I used Eclipse with Java on Linux and Windows. Excellent tool set, and free. Can't use it to debug our code though - there is no ability to attach to a running process, so I would have to build it all in Eclipse. And it's several millions lines of code.

Anonymous said...

Have You looked at Insight GDB GUI? I don't know how good it is compared to VS.
Sincerely

Anonymous said...

emacs's gdb integration is worth a shot. (M-x gdb).

Finding a good .emacsrc is also important, as emacs has pretty useless defaults. Search for an .emacsrc with pc-selection-mode in it.

http://www.emacswiki.org/cgi-bin/wiki/CopyAndPaste
http://flex-compiler.csail.mit.edu/Harpoon/HOWTO/getting-started/config/emacsrc

Илья Казначеев said...

It looks like you've comparing carefully grown environment with default setup of linux where you're a newcomer.

I tried to reverse this by pointing to windows ce. *You* had time to port a debugger there, write a command shell, etc, etc... But I didn't want to marry wince, so I've found it an atrociously bad programming environment. And windows in my experience wasn't much better, but that's because I'm a padawan windows developer.


I, for example, can say that strace wipes the floor in the field of debugging program flow.
Then again, you can tell you've installed a dozen of sysinternals programs which do ten times more. But I don't want to find and install a dozen of programs, I want to use simple program coming with a system on any windows box which I can use for in-place debugging.

Sergey Solyanik said...

To Ilya:

This is a very different case. On Windows CE you used the wrong tool set. Good (excellent!) tools do exist, and I have pointed it out.

On Linux, I am very willing to learn the tools that I need to debug. Point me to anything remotely similar to VS (or Eclipse, but capable of debugging something that was not built inside it), and I will be ecstatic.

Илья Казначеев said...

Well, strace, valgrind, gdb (+ kdevelop or eclipse or emacs?). They're exellent tools. And you generally do have sources for everything :)

Your lacking of VS debugger under linux is like my lacking of strace under windows ce, that's why I compare them.

Anonymous said...

Aah 286 TurboC (Turbo Pascal in my case) that was a blessing! I've programmed in MSX Basic; that was good. I've programmed in GW Basic; that was good. I did QBasic; that was good. Then I got to know Turbo Pascal/Borland Pascal; that was a blessing! I once read someone who said "I still need a blue screen to be a productive developer" and I would totally agree! I've developed in Delphi since and then I left the IDE environment to code in Java with assorted tools.. but whenever I boot up BP for a quick routine I feel I'm in heaven... I've never taken up coding in Linux apart from some quick 'n simple C program I need for something or the other, simply because the environment is so dirt poor. Emacs? I don't even want to get into that. Vi? I'll take MSDOS 6.22 edit.com *anytime*. I know I'm no big shot developer, but Linux is like a backwater desert compared to the rich and fruitful environment you get in Windows (and possibly Mac). You can tell even without doing any research yourself because of the never ending suggestions you get from linux lovers that say "have you tried this? have you tried that?" - pointing to the simple and obvious truth that there is no good solution in place! - for why else would everyone be pointing to those hacks and one-man utilities...

Really... cannot someone just do the hard work and make it easier for everyone else, instead of everyone having to figure everything out for themselves? What a waste of resources. Just a bloody waste of resources. Linux could have been 5 times as good if all those singleminded developers would have joined hands and operated out of a shared vision and organisation, instead of creating the next distribution that offers almost the same experience as all the others...

Anonymous said...

If you want a free debugger, use gdb or tools that others have mentioned that are based on it. TotalView (www.totalviewtech.com) is a top-of-the line commercial debugger that supports Linux. It's fairly expensive for an individual, but not out of reach for a small programming shop.

Unknown said...

I am an that works for a very big consulting firm. In the last four years i've been spending most of my time in the bank market writing software that facilitates data flow and communications between Unix and Windows systems. I have also worked heavily on module development for Openldap and Apache. Since this is mainly system software most of it is developed in C/C++ with a small fraction in Java and .NET. On windows i use Visual Studio and on Unix i am using vi+gdb. Anyone knows that the most expensive part of software development is debugging. Debugging software under Unix is more expensive. Period. It takes more time. And this is not because of some missing feature in gbd but it is because gdb is not an IDE. Setting a breakpoint writing a file name and a line numer takes considerably more time than pressing a mouse button. Printing a variable name several times takes more time than setting a watch in VS or pointing the mouse over it and having its value and structure visualized. Learning the command line tool also takes more time. It's all about time and it's all as simple as this. Debugging is a repetitive task and an IDE is best suited in supporting this than a command line tools. A debugging tool should strive for reducing the amount of repetitive work a programmer has to do and an IDE is far superior in this than a command line debugger. In a world where we have to deal with deadlines developing sotware using gdb simply is more expensive and takes more effort than using Visual Studio or a similar ide. People that don't realize this probably have never been under the pressure of a coming deadline. The question is as simple as this: do you prefer to spend most of your time founding and solving bugs or writing commands in the debugger? This is my humble point of view.