'. '

Debugger

From APIDesign

(Difference between revisions)
Jump to: navigation, search
(Building Modular systems)
Line 3: Line 3:
== Building [[Modular system]]s ==
== Building [[Modular system]]s ==
-
[[Chapter 1]] of [[TheAPIBook]] discusses the art of building modern software systems and concludes that these days we are building systems that we don't understand. As an example it mentions that in order to write a web page one needs to understand [[HTML]] and possibly a [[wikipedia:Java_Servlet|Servlet API]], but you don't need to have knowledge of anything that lays below: [[Glassfish]] server, [[Java]] [[VM]], [[Unix]] libraries, [[Linux]] kernel, the [[VirtualBox]] nor even the hardware. At the end you can deploy a massive solution and in fact understand roughly one percent of it!
+
[[Chapter 1]] of [[TheAPIBook]] discusses the art of building modern software systems and concludes that these days we are building systems that we don't understand. As an example it mentions that in order to write a dynamically generated web page one needs to understand [[HTML]] and possibly a [[wikipedia:Java_Servlet|Servlet API]], but you don't need to have knowledge of anything that lays below: [[Glassfish]] server, [[Java]] [[VM]], [[Unix]] libraries, [[Linux]] kernel, the [[VirtualBox]] nor even the hardware. At the end you can deploy a massive solution and in fact understand roughly one percent of it!
Some people may find it freightening that we use systems without real understanding, but [[The Art of Building Modern Software]] chapter concludes that such level of [[cluelessness]] is OK and in fact completely necessary. Brain has limited capacity, and the learning time is finite as well. As such we just can't understand everything. It is enough to know just the surface:
Some people may find it freightening that we use systems without real understanding, but [[The Art of Building Modern Software]] chapter concludes that such level of [[cluelessness]] is OK and in fact completely necessary. Brain has limited capacity, and the learning time is finite as well. As such we just can't understand everything. It is enough to know just the surface:

Revision as of 05:13, 14 August 2013

Debugger is a program that helps to find out what other programs are doing. Often people use debugger to understand why their own code does not do, what they would like it to do. However debugger is incredibly useful for other purposes as well. Here is its story.

Contents

Building Modular systems

Chapter 1 of TheAPIBook discusses the art of building modern software systems and concludes that these days we are building systems that we don't understand. As an example it mentions that in order to write a dynamically generated web page one needs to understand HTML and possibly a Servlet API, but you don't need to have knowledge of anything that lays below: Glassfish server, Java VM, Unix libraries, Linux kernel, the VirtualBox nor even the hardware. At the end you can deploy a massive solution and in fact understand roughly one percent of it!

Some people may find it freightening that we use systems without real understanding, but The Art of Building Modern Software chapter concludes that such level of cluelessness is OK and in fact completely necessary. Brain has limited capacity, and the learning time is finite as well. As such we just can't understand everything. It is enough to know just the surface:

Knowing these interfaces is enough. The details behind them are unimportant (if things go well).

Btw. this is also the reason why API design is important. Well designed application programming interfaces encourage cluelessness. The less knowledge people need to use a technology, the better the technology is. That is why read TheAPIBook and learn how to do it! But let's now get back to topic of debugging.

Cluelessness of an API User

I am using word cluelessness for the blessed state when one does not need to know the internals behind APIs. However in fact I mean selective cluelessness: when there is no need to know to make things work, the less we know the better.

However when things go wrong, then we should concentrate on what is wrong and get as deep knowledge of the affected area as possible. We should select that we want to know everything about a particular part of (for example) Glassfish and learn every detail about it (for example why it throws NullPointerException).

These days it should not be hard to increase our knowledge about our libraries. Most of them are Open source and thus getting access to their source code is easy. Putting a breakpoint on appropriate line, launching own application under debugger is usually easy as well. Moreover it is also easy to play with the code - modify a line, compile (using Maven or make) and use the modified version. There are no barriers to increase our knowledge about Glassfish, Java, Linux, etc.

In spite of the above easiness, I don't see people doing it. I don't see them looking at sources of libraries they use. Rather than that they treat them as blackbox. In spite of all the options we have, some of us decided to stay clueless (in the negative meaning, without the important selective part).

The Googling Robot

Rather than trying to investigate the problem, the first reaction is to query google search machine. I have to admit, I do it too and the results from Stackoverflow web site and really valuable. It is selectively clueless to check whether somebody else tried to solve the problem, so far this attitude is good. However the really problematic state occurs as soon as the query yields no results. I've seen many situations when desperate programmers frustrated by unsatisfying search give up!

Such googling only robots will however face inevitable destiny. These days google can recognize voice, drive a car, the day when it will be able to create artificial intelligence that will program using searches is not far away. At that moment programmers will be unemployed or will have to become selectively clueless again - and learn how to use debugger.

Knowing Every Detail

maven, NetBeans Platform (customer) and iOS, open source

When Things Don't Happen

Debuggers were designed to allow developers to step through their own code. Certainly, when such feature hit market, it was a huge step forward. Ability to understand the behavior of own program by stepping through one line and seeing the state of memory and variables is certainly useful. Much easier than running the whole program and then trying to find out on which line something went wrong.

However the proliferation of open source libraries and the fact that these days we rather assemble applications than write them.

originally for things went wrong, now often for things that don't happen.

Use the Debugger. Stupid!

TBD

Personal tools
buy