One is young or old depending on how one confronts change.
The old feels frustration. The young accepts change and takes profit of it.
Young is one who find home in the foreign. Those who grasp their old sweet routine for comfort, those who can’t accept disorientation are from another era.
| // (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, ... ); | |
| } |
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:
| @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 |
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.
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?
| #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" : ", "); | |
| } } | |
| } |
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