Nov
8th
Sun
8th
Nov
5th
Thu
5th
It's OK Not to Write Unit Tests
Testowanie wciąż w modzie: 288 komentarzy na reddicie.
Mi się spodobały te dwa odnośniki:
Nov
1st
Sun
1st
"The Humble Programmer" by Edsger W. Dijkstra
Napisane w 1972 ciekawe spojrzenie na początki fachu programisty. Dość subiektywne, ale tym bardziej interesujące.
(…) in 1957, I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession. And, believe it or not, but under the heading “profession” my marriage act shows the ridiculous entry “theoretical physicist”!
Dijkstra ciekawie też pisze o roli programisty przed boomem komputerów trzeciej generacji:
(…) the programmer himself had a very modest view of his own work: his work derived all its significance from the existence of that wonderful machine. Because that was a unique machine, he knew only too well that his programs had only local significance and also, because it was patently obvious that this machine would have a limited lifetime, he knew that very little of his work would have a lasting value.
O następującym fragmencie opisującym PL/1 można by powiedzieć, że został napisany o Perlu. ;-)
Finally, although the subject is not a pleasant one, I must mention PL/1, a programming language for which the defining documentation is of a frightening size and complexity. Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control. And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1 he managed to ask for the addition of about fifty new “features”, little supposing that the main source of his problems could very well be that it contained already far too many “features”.
W tym cytacie zaś Dijkstra zdaje się pokładać (niespełnione z resztą) nadzieje w metodach formalnych, sam opis procesu przypomina jednak bardzo TDD.
Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first make the program and then prove its correctness, because then the requirement of providing the proof would only increase the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand. (…) If one first asks oneself what the structure of a convincing proof would be and, having found this, then constructs a program satisfying this proof’s requirements, then these correctness concerns turn out to be a very effective heuristic guidance.
Oct
30th
Fri
30th
Changing GNOME Panel autohide options with gconf-editor. Interesting options: auto_hide, auto_hide_size, hide_delay, and unhide_delay.
pSX on Ubuntu AMD64
I believe this will solve the problems for most people unable to launch pSX in Ubuntu Hardy/Intrepid.
#!/bin/bash
# A script to disable pulseaudio, run pSX, then renable pulseaudio
gksu /etc/init.d/pulseaudio stop
sleep 1
gksu killall pulseaudio # Forcefully ends pulseaudio if still running
sleep 1
exec /usr/local/games/psx/pSX
sleep 1
gksu /etc/init.d/pulseaudio start
just for the heck of it: I have tuned a very CPU-heavy function I wrote in Common Lisp over a year ago so it went from the unsatisfactory 623 µs per call to the very pleasant 4.7 µs per call.
the strictly equivalent C function that people are entirely satisfied with, performance-wise, takes 92 µs per call. very frequently, I find that Common Lisp allows me to experiment with algorithms so much faster than I can in C and the like, so I can change methodology and approach as fast as they can do another optimization attempt. this means that a good Common Lisp programmer can find the optimal algorithm and the optimal implementation in less time than the C programmer can find the optimal implementation.
the C mind-set is that C is fast. this is even less true than their idea that CL is slow. writing really fast C code is incredibly hard, and you might as well write it in assembly after you have seen what the compiler is doing to the overall code. I have squeezed the last drop of blood out of many a CPU in my time, but never has it been easier to do it than with Allegro CL with its instruction-level profiler, hackable LAP code (thanks, Duane!), and code transformation with compiler macros (a standard CL facility). this stuff just isn’t available to C programmers.
if you can’t outperform C in CL, you’re too good at C.
Oct
25th
Sun
25th
ditaa: DIagrams Through Ascii Art
via reddit
Neat project, and works with emacs’ org-mode too.
