

Jonathan Blow criticises Linux dev tools - thegarside
http://www.develop-online.net/news/43175/Jonathan-Blow-criticizes-Linux-dev-tools

======
sbierwagen
Blogspam of an _HN comment._

OP is <https://news.ycombinator.com/item?id=5124476>

------
Negitivefrags
I work on game servers that run on both linux and windows. (We deploy to linux
but most of our developers work in windows as that is what the client runs
on).

If there is a crash or other bug the first question is always "Can we
reproduce this on windows servers?".

I spend about 50% of my time using GDB and 50% in Visual Studio for debugging.
GDB is just crap compared to Visual Studio has a debugging tool.

~~~
lostnet
I had always wondered what market the window debugging was tuned for..
Building by bug fixing in a debugger and then shipping it to someone without a
debugger does seem to be the norm both on windows and in the game industry.

I worked for a UNIX vendor and our gdb style commands were ideal for business
and government customers and products.

The time spent diagnosing bugs during production is not nearly as important as
the ability to diagnose bugs remotely with limited amounts of data collected
(and in many cases read and redacted) by a customer running a machine with
sensitive data.

For live debugging we really relied on truss and dtrace. There are
ports/copies of them in Linux, I don't know how complete..

------
Expez
Seems unnecessarily meta to submit stories about comments on HN. Original
thread can be found here: <http://news.ycombinator.com/item?id=5124476>

------
exDM69
Yes, GDB might not be that great for application developers. But GDB is a
mighty powerful tool that you can use to debug in various environments.

You can use GDB with a regular user space application or attach it to a dead
process with a core file. Or you can plug it to QEMU to debug a bootloader or
a kernel image in emulation. Or you can use remote debugging over the network
or over the serial port. It's possible to add GDB stubs and run your custom
kernel image running on bare metal, debugging via serial connection. You can
debug a program running on a microcontroller like Arduino. You can even use it
to debug Windows applications remotely from the comfort of your Linux desktop.
In my day job and my hacking hobbies I have used all of the ways of using GDB
I mentioned in this paragraph.

So yeah, GDB is not a pretty source level debugger like Visual Studio or
Eclipse, the versatility comes at a price.

LLVM Project's LLDB debugger may make application debugging less painful in
the future.

------
kelnos
I just seriously don't understand all the GDB hate. It might have a steep
learning curve, but I feel _much_ more comfortable and productive in GDB than
I ever did in Visual Studio's debugger.

Is it the most amazing debugger ever? Certainly not. But it gets the job done.
LLDB looks promising as an alternative, but it's not mature enough yet.

Also, what's with the fetish with IDEs? I only use an IDE when I write Java
(since navigating even a "simple" Java codebase is difficult without one), but
for anything else, I spend all my time in vim and a terminal, even for large
projects.

~~~
FooBarWidget
GDB is okay once you get the hang of it, but it's seriously less productive
than with proper IDE integration.

How do you make a breakpoint? 'break Filename.cpp:1234' or 'break
FullClassName::FullFunctionName'. I have to go to my editor, lookup the file
and line number, go to gdb and enter a command. Remove a breakpoint? I always
forget how to do that so I need to lookup the manual every time. Urgh. I just
want to be able to click on a button next to the line to insert or remove a
breakpoint.

The command line interface has its uses, but there should _also_ be excellent
editor integration. I don't care about IDEs; integration with Sublime Text is
fine. Unfortunately every project that I've come across that tries to
implement that is half-baked.

------
masklinn
Lots of mentions (and warranted criticisms of) GDB for its failings and
(especially) nightmarish IDE/GUI integration, no mention of LLDB[0] which aims
to fix exactly that (amongst many other things).

[0] <http://lldb.llvm.org/>

