Slashdot Mirror

I generally agree with the sentiment that many programmers often tend to neglect efficiency if there's not immediate value to be gained from it, i.e. we don't necessarily always develop in "ideal/optimized thinking mode" because there doesn't appear to be a necessity to do so, so we just settle for the quick & easy "solution".

I do however disagree with the conclusion that we as developers should be forced to work on corresponding low-end systems consequently, I tend to agree more with "merreborn" who is suggesting that development should take place on high performance systems while testing, benchmarks and profiling should probably be best done on lower end systems.

On the other hand, I do share the assumption that the quality of today's mainstream software would be higher if were more restricted in the use of available computing/hardware resources, and I think in fact that this is backed up by those periods in the history of computers when hardware resources were truly limited - but when software developers for example still managed to write exemplary software that had to run on 8 bit processors with just some kilobytes of memory (more on the below).

I know that I personally would become very frustrated if I had to work on a low end development platform, in fact I know that for a fact out of personal experience. Indeed, I can tell you -also from experience- that it is a tremendous pleasure to be able to develop on multi-core/multi-gb systems.

It really is such more "fun" and -ironically- also "effective", but not necessarily so due to the performance that I get to see when running my own compiled code, but moreso due to the *workflow* that such a environment facilitates:

I mean let's face it, while most of us do enjoy the process of developing software to a greater or lesser extent, we usually cannot really appreciate the "lateral", "chore" work associated with doing it, no matter if that means *waiting* for your SCM/RCS to complete a checkout/commit/merge, or *waiting* for your build to finally complete.

In other words, I don't mind spending really significant amounts of time (think hours) troubleshooting a problem or developing a piece of code - but if external factors, that are beyond my control, render me unproductive this is really starting to make me feel, bored or even *aggressive*.

As a programmer, I am interested in making the machine do something that I need to get done, so I am results-oriented when developing software.

The faster I get to see the results (that motivated me to write the software in the first place), the more I appreciate the whole experience of developing software.

If developing software inevitably implied that I have to wait several minutes to get to see my results, it's starting to get frustrating: software development is a dynamic process that benefits from a certain workflow, it certainly does for me!

In my case, if this workflow is interrupted, I am no longer as productive as before any more - and I know for a fact that this also applies to many other software developers who I know: It's all about your mental state during the process of developing software.

This is probably similar to air traffic controllers, who refer to this as "getting the flick" when they have total overview and know their airspace and current traffic situation in and out, distractions during this work - no matter how related or not, are not good for the worfklow and the overall process.

Any unprovoked events during the development process are actually an unappreciated distraction, I am sure many of you agree.

However, settling for less-than-ideal designs and implementations isn't generally unheard of in many settings, regardless of your level of professionalism or the type of setup you are using.

In fact, just a couple of minutes ago I stumbled on a blog entry from 2006, appropriately titled "Efficiency Will Always Matter" http://www.spinellis.gr/cgi-bin/comme

• Thinking in C++ by Bruce Eckel http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
• Computer Networks by Andrew Tanenbaum http://www.prenhall.com/tanenbaum/details2.html
• Structured Computer Organization by Andrew Tanenbaum http://www.pearsonhighered.com/educator/academic/product/0,,0131485210,00%2Ben-USS_01DBC.html
• Producing Open Source Software by Karl Fogel http://producingoss.com/
• Design and Implementation of the FreeBSD Operating System by Marshall Kirk McKusick and George V. Neville-Neil http://www.mckusick.com/books.html
• Code Quality by Diomidis Spinellis http://www.spinellis.gr/codequality/

Forget what you *think* you're measuring (code quality). Instead, consider whether you're measuring anything at all. That is, is there any information in the data you've measured?

For another indication, consider this figure, showing a trend that matches our expectations: how the maintainability of the FreeBSD system is, in general, falling over time. Again, this is derived from some of the metrics I used to compare the four kernels. These metrics do not yield noise.

I've put the data and the SQL queries on the web. It is therefore easy for you to do what you suggest, because the filenames are stored in the database. Just perform a cascade delete for the files you think that don't belong to each system's core and rerun the queries. I'd be interested to know the results.

With a liberal reading of "if it works" you're right. You can say that if the code is functional, reliable, usable, efficient, maintainable, and portable, then it is of high quality. But this is a circular definition, because this is how software quality is defined. As somebody else posted earlier, the quest for quality can lead you to an endless motorcycle trip on America's back-roads.

Ten years ago I wrote an article criticizing the Windows API. Most of what I wrote then, continues to be true today. Based on that external view of Windows, and the BSODs I regularly see, I was expecting to find in the kernel many worse things. The header file you mention is a clear manifest of an inappropriate design, and I suspect that at higher levels of system functionality (say OLE or the GDI) there will be more parts of similarly bad quality.

> the paper is well-written

Yup, and the author of the paper is Diomidis Spinellis, who wrote the excellent book Code Reading. This is a great study of code analysis and familiarization techniques. He also wrote a fine article on C preprocessors... in Dr. Dobb's Journal, I think.

If you want to speed up transfers and you're working on a LAN you trust (i.e. you don't worry about the integrity and confidentiality of the data passing through it), you can dramatically increase throughput using socketpipe. Although the initial socketpipe communication setup is performed through client-server intermediaries such as ssh(1), the communication channel that socketpipe establishes is a direct socket connection between the local and the remote commands. This eliminates not only the encryption/description overhead, but also the copying between your processes and ssh or rsh.

First, in most cases there's no need to spend time comprehending a large code base. You have to be selective, and the tools you'll use will depend on the problem you're facing.

• If you're only trying to solve a specific bug, then, as other posters already commented, the debugger is your tool of choice.
• If you're facing performance problems, then use the various performance measurement tools.
• If you must evaluate the code, then invest on metric collection tools, like CCCC.
• If you want to reuse the code in another project, then you need to investigate packaging tools and techniques.
• If the code's identifiers or its structure require refactoring, then try using a refactoring browser, like CScout.
• If the code's formatting and style brings you a headache, look at formatter, like indent

Second, never underestimate the power of grep. Grep will often find things that other tools can't. It can search in documentation, comments, binary files, unparsable source code, and change logs. It can work on any language, and (with the help of find(1) and xargs(1) tools) traverse deep directory hierarchies. Unlike most other tools, grep doesn't need any setup, tuning, or configuration. Grep will often locate what you're looking for, in less time than what you need to download a more sophisticated tool.

First, in most cases there's no need to spend time comprehending a large code base. You have to be selective, and the tools you'll use will depend on the problem you're facing.

• If you're only trying to solve a specific bug, then, as other posters already commented, the debugger is your tool of choice.
• If you're facing performance problems, then use the various performance measurement tools.
• If you must evaluate the code, then invest on metric collection tools, like CCCC.
• If you want to reuse the code in another project, then you need to investigate packaging tools and techniques.
• If the code's identifiers or its structure require refactoring, then try using a refactoring browser, like CScout.
• If the code's formatting and style brings you a headache, look at formatter, like indent

Second, never underestimate the power of grep. Grep will often find things that other tools can't. It can search in documentation, comments, binary files, unparsable source code, and change logs. It can work on any language, and (with the help of find(1) and xargs(1) tools) traverse deep directory hierarchies. Unlike most other tools, grep doesn't need any setup, tuning, or configuration. Grep will often locate what you're looking for, in less time than what you need to download a more sophisticated tool.

ETrace : Run-time tracing http://freshmeat.net/projects/etrace/

This book is worth a read http://www.spinellis.gr/codereading/

Draw some static graphs of functions of interest using CodeViz http://freshmeat.net/projects/codeviz/

Write lots of notes, preferably on paper with a pen rather than electronically.

Such a good reputation, in fact, that an entire book has been devoted to reading its source code. It has a reputation for correctness and portability (duh) and seems an interesting starting point.

Since I am only getting started in C programming, though, I can't recommend this book. Or the NetBSD source, either.

The two real problems are:

• Digital preservation. Will my files survive 50 years of moving between storage media? Will I be able to view JPEG files in 50 years time?
• People who print their photos on inkjet printers and then delete (or loose) the digital version of the image. This is happening more often as digital cameras are increasingly bought by less IT-savvy people.

Amazon has already deployed such a system under the name of Mechanical Turk. The idea is that humans assist computers, providing what is cutely named artificial artifical intelligence. You can read more about the concept in an article that ACM Queue run on May 2006.
--
Code Quality: The Open Source Perspective

SWILL is great for adding an interface to legacy code, because its impact on the application can be minimal. I wouldn't recommend its use if your GUI requirements are above what can be implemented in a dozen web pages.

I just finished comparing the sizes of the DLLs the two programs use. The total size of the DLLs that the Internet Explorer loads is 44MB; the size of the DLLs for SeaMonkey is 11MB less: 33MB.

A while ago I compared the number of dependencies to other components between Mozilla and the Internet Explorer. I thought that the free availability of many open source components would result in a much large number of dependencies (and therefore complexity) in Mozilla than in the IE. It turned out that the opposite was true. One explanation could be that, because Microsoft isn't obliged to publish the interfaces of internal Windows components and maintain backward compatibility, Microsoft developers have an easier time in creating internally reusable Windows components. Of course, in the long term, this strategy will backfire, as demonstrated by the travails of the Windows Vista release.

Code Quality: The Open Source Perspective

The fact that they had to shut down the site for updates is an indication that they haven't solved the (difficult) problem of performing live software and hardware updates. This looks to me like a fundamental design constraint of their solution, rather than a bug that can be addressed in a beta-testing cycle. Other internet-based service providers, like Google, Akamai, and (to a limited extend) Wikipedia, addressed this problem from day one. (Wikipedia reverts to a static browsing mode during some update operations.)

As I said, the reliable operation of a service is a difficult problem. At the Second Workshop on Real, Large Distributed Systems (WORLDS '05) Mike Afergan and his colleagues presented a very interesting paper detailing the design methodology used to achieve commercial-quality reliability in the Akamai content delivery network. As they write in the abstract, the Akamai network consists of 15,000+ servers in 1,100+ networks and spans 65+ countries. The paper makes very interesting reading.

--
Code Quality: The Open Source Perspective(Addison-Wesley 2006)

is the wording on a banner currently appearing on the thinkfree web site. Am I the only one feeling nervous about having my documents residing on an application service provider where their accessibility is beyond my control?

--
Code Quality: The Open Source Perspective (Addison-Wesley 2006)

Here is my bookshelf: with cover images, without cover images, and with cover images ordered by color.

Here is my bookshelf: with cover images, without cover images, and with cover images ordered by color.

Here is my bookshelf: with cover images, without cover images, and with cover images ordered by color.

I applaud your professor or thesis advisor or whoever for this real-world task. Here's a few resources which I wouldn't do without:
Code Reading: The Open Source Perspective
Object-Oriented Reengineering Patterns
Reading Computer Programs: Instructor's Guide and Exercise
Tips for Reading Code

Google seems to have found a way to use network effects to gather the visiting habits of all the world's web surfers. The value of this data is priceless. Google's army of Computer Science PhDs is definitely not sitting idle.

You are right, version control should be part of "programming" education, and should probably be taught in a software engineering course.

Diomidis

You are right, version control should be part of "programming" education, and should probably be taught in a software engineering course.

Diomidis

<!--
To update the FAQs table of contents yank the following vim commands into a register ("ry4j) and execute it (@r).
/^<h2>Contents
jjma/ul>
kmb/^$
"qyy:g/^< a name/s,<a name="\([^>]*\)><h2>\(.*\)</h2></a>,<li& g t; <a href="\#\1>\2</a>,|y Q|u
'ad'b"qP
-->

<a name="antialias"><h2>How can I improve the quality of the bitmap images I generate?</h2></a>

#include "/dev/tty"

1. determining whether a program is a virus or not is an undecidable problem (there exists no algorithm that can solve it), and
2. determining whether a program is a variation of a known bounded-length virus is NP-complete (algorithms that solve the problem would take impracticably long time).

An earlier poster mentioned how such a skill can help you find compiler bugs. This can be the case, but it is rare; I have located two such bugs in 20 years of programming. A more common use is to locate bugs in your code. When your brain refuses to see the missing braces around the wrongly indented code, or an spurious semicolon at the end of an if or while statement, reading the generated assembly code can save some extra hours of frustration. You will be able to see that the code the compiler generates differs from the code you think you wrote, and this will point you to the bug's location.

As I argue in Code Reading, other cases where reading assembly code can be of use are:

• to understand how an implementation-defined operation (e.g. a type cast) is actually performed,
• to see how compiler optimizations affect the resulting code,
• to verify that hardware-specific code written in C/C++ actually performs the operations you expect, and
• to learn how a particular construct can be written in symbolic code.

To read compiler-generated assembly code you need:

• An understanding of the processor's architecture: registers, instruction format, addressing modes. See for example Intel's Pentium Architecture Manual.
• A handbook of the processor's instruction set. Again, see for example Intel's Pentium Instruction Set Reference Manual A-M and Intel's Pentium Instruction Set Reference Manual N-Z.
• An appreciation of how compilers generate code for modern structured languages. The key ideas here are the stack as a way to handle nested function and method calls, the frame pointer as a way to access function arguments and local variables, and the virtual function table often used for implementing dynamic dispatch in OO languages. The Red Dragon Book is the venerable classic here.
• A way to obtain an assembly code listing of your high-level language code. The Unix compiler's -S switch, and the Java SDK "javap -c" command are two methods I often use. In gdb you can use the disassemble, nexti, and stepi commands to examine your program at the level of discrete processor instructions.

Obligatory "hello, world" program written in i386 assembly:

hello: .string "hello, world\n"
.globl main
main:
pushl $13
pushl $hello
pushl $1
call write
addl $12, %esp
xorl %eax, %eax
ret

Diomidis Spinellis - #include "/dev/tty"

F7 displays a popup history. PageUp recalls first command. PageDown recalls last command. F9 allows you to call a command by number (look at the popup history for the numbers). Type a letter, then hit F8 to recall a command starting with that letter. F5 or Up to go backwards. Down to go forwards. If you have the resource kit, a nice clipboard tool, clip.exe can be used to do some nifty things. winclip.exe is a suitable replacement. For example, search commands by regex and then execute the results in a subshell:

doskey /h | findstr ".*\.exe" | winclip -c && for /f "tokens=*" %H in ('winclip -p') do @cmd /c "%H"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

When I want to solve a program I choose the language I will use, taking into account the abstractions and facilities it offers.

• I chose Java when I wanted to leverage the javadoc applets (doclets) to convert a Java-like syntax into UML with my UMLgraph tool.
• I chose C++ to implement the CScout refactoring browser for C programs. In this case I wanted rich and efficient data structures, with minimal speed and space overhead. CScout datasets can require more than 1GB of RAM, and runtimes can span more than a day; any overhead of object boxing, garbage collection, or bytecode interpretation would in this case be unacceptable.
• I chose Perl to
  • Convert digital photographs and GPS track logs into annotated photo albums and trip maps
  • Examine the availability of 4500 URLs cited in computer science research papers.
  • To create the diagrams and the index for my book Code Reading: The Open Source Perspective.
  In all the above cases, I needed a typeless language with a rich set of operators, functions, and libraries to minimize the time I would spend to convert my ideas into code. Ruby and Python would have served me equally well.
• Finally, I chose C to write
  • the *BSD sed implementation.
  • The socketpipe zero-overhead network pipe tool.
  • The Outwit Windows-Unix shell integration tool suite.
  • The fileprune backup file prune utility.
  • A device driver for interfacing with my home's alarm system.
  In these cases, I did not require any fancy data structures or framework APIs, but I did want tight integration with the underlying system, absolute efficiency, and minimum-fuss portability. For code that will be executed billions of times on tens of thousands of systems, spending some additional effort to provide the absolute efficiency and reasonable portability that are possible in C, is a proposition one should take into account.

#include "/dev/tty"

As an example, you can change all registry entries pointing to a user's home directory by running

winreg HKEY_CURRENT_USER |
sed -n 's/C:\\home/D:\\home/gp' |
winreg

#include "/dev/tty"

As an example, you can change all registry entries pointing to a user's home directory by running

winreg HKEY_CURRENT_USER |
sed -n 's/C:\\home/D:\\home/gp' |
winreg

#include "/dev/tty"

Brian states in the introduction:

This is a community cookbook, from an invisible worldwide electronic community. Like all community cookbooks, it has the favorite recipes of the members of the community, suitably edited and organized. The USENET Cookbook is a collection of the favorite recipes of USENET readers worldwide.

In 1993 I converted the Cookbook into a Windows Help file. The conversion was done from the original unformated recipe troff texts, in order to properly translate all character codes, create a list of search keys, and hieararchical content tables. I downloaded the file from its web page, and it still works.

Diomidis Spinellis - #include "/dev/tty"

Code Reading by Diomidis Spinellis contains a bunch of ideas on ways to comprehend large codebases more easily.

He talks about browsing code, package structures, adding features or fixing bugs in a large codebase, and so on. It's a good read - well worth the money.

An article that appeared earlied this year in IEEE Pervasive Computing describes the principles of operation.

Diomidis Spinellis - #include "/dev/tty"

An article that appeared earlied this year in IEEE Pervasive Computing describes the principles of operation.

Diomidis Spinellis - #include "/dev/tty"

An article that appeared earlied this year in IEEE Pervasive Computing describes the principles of operation.

Diomidis Spinellis - #include "/dev/tty"

As an example, you can change all registry entries pointing to a user's home directory by running

winreg HKEY_CURRENT_USER |
sed -n 's/C:\\home/D:\\home/gp' |
winreg

#include "/dev/tty"

As an example, you can change all registry entries pointing to a user's home directory by running

winreg HKEY_CURRENT_USER |
sed -n 's/C:\\home/D:\\home/gp' |
winreg

#include "/dev/tty"