uucidl

Goals

Looking at software from a different angle as done during profiling and data analysis has numerous benefits. It requires and increases our understanding of the problems being solved by the software. It exposes us to unexpected discoveries and insights. It allows us to suggest improvements.

Since there is a great element of skills involved, and it is rarely taught in Computer Science degrees, the role of practice is very important to gain the necessary skills.

Exercises

Ex1: sequential processing

uucidl

#include <cstddef>
#include <cstdint>
#include <cstdio>
#include <cstdlib>
#include <cstring>

size_t
megabytes_size(uint32_t x)
{
  return x * 1024 * 1024;

uucidl

The IOKit framework is Apple’s base framework to interact with devices. This is your go to when for instance working with USB devices.

There is a way in IOKit to register notifications to discover devices as they are plugged by our users. The API seems easy enough (see IOKitLib header)

However I was puzzled for quite long why my notifications were not processed. It turns out you have to process the iterator immediately after calling IOServiceAddMatchingNotification, otherwise notifications won’t be

uucidl

#include <stdio.h>

// Shows how to iterate backwards in C. (Counter version)
int main(int argc, char** argv)
{
  { int c = argc; while (c--) {
    printf("%s%s", argv[c], c == 0 ? "\n" : ", ");
  } }
}

uucidl

Sophistication in programming languages has diminishing returns.

I treat programming language features like I treat drugs. They come with side-effects, which I want to be aware off before even thinking of putting them into use. And if in doubt, I’d rather not use them.

For an alternative take, legions of programmers write online about the features they want to have in their language. Is it based on actual experience rather than wishful thinking? Is it based on their own introspection of what’s producing defects or harming progress?

uucidl

Engineering

Good results in software engineering depend on robust decisions over the trade-offs involved in solving problems with computing devices. This can only be done through a good understanding of the problem being presented, and the context/platform that will support its resolution. Technical choices should not be elevated above that.

Note that both the problem and the platform’s definition should not only consist of inanimate objects. Both always incorporate human elements that must be understood.

By nature, engineering therefore involves learning, knowledge formation, skill development and acquisition.

Learning and knowledge formation

uucidl

• A Discipline Of Programming by Edsger W. Dijkstra
• Elements Of Programming by Alexander Stepanov and Paul McJones

uucidl

@echo off
REM a normal compilation runs through
cl.exe main.cpp /Z7 /nologo /c -DWIN32 -W4 -WX -Wall -wd4514

REM however the pre-processor fails because of -WX and C4668
cl.exe main.cpp /Z7 /nologo /c -DWIN32 -W4 -WX -Wall -wd4514 -E

uucidl

https://youtu.be/CAlU_hs_rZ8?t=3069

It’s good to generalize when things get simpler in generality. I.e. general case vs case analysis

This seems to have similarities to the practice of Topology in Mathematics (of which I’m no expert of) in how they squash degerate cases.

Discipline Of Programming by Dijkstra:

• there are useful and useless generalizations

uucidl

// (Ghetto trace) (Trace in an hostile environment)
#include <stdlib.h>
#define UU_TRACE_BEGIN
#define UU_TRACE_END
#if defined (_WIN32)
extern "C" {
    __declspec(dllimport) unsigned long __stdcall GetCurrentProcessId(void);
    void __stdcall OutputDebugStringA(_In_opt_ char const *outputString);
    __declspec(dllimport) int _snprintf( char* buffer, size_t buf_size, const char* format, ... );
}