Plasmasturm
plasmasturm.org · Personal blog · on HN since 2007
Plasmasturm is the blog of Aristotle Pagaltzis, who writes about programming, git, Unicode, debugging, and software craft.
What HN saysHN commenters quote its Six Stages of Debugging post often, and also cite its writing on code as expenditure rather than an asset.
29HN people shared it
12linked it in comments
19stories submitted
497story points
7 months agolast shared
2007people per year2026
Most-shared posts
- 1The Six Stages of Debugging (2012)7 people · 115 points · first shared 2012 · 22 comments on HN
- 2The urge to comment as a sign of danger2 people · 23 points · first shared 2007 · 2 comments on HN
- 3Rename2 people · first shared 2012
- 4Tree traversal without recursion: the tree as a state machine (2007)1 people · 209 points · first shared 2019 · 77 comments on HN
- 5In praise of git’s index1 people · 93 points · first shared 2010 · 34 comments on HN
- 6Paul Graham's kind of dirty (On Unicode support as an exercise for the programmer)1 people · 17 points · first shared 2008 · 14 comments on HN
- 7Good Mail Sorting1 people · 15 points · first shared 2015 · 4 comments on HN
- 8A graphic illustration of 0.999…=11 people · 7 points · first shared 2011 · 18 comments on HN
- 9Yet another reason not to bet on Apple1 people · 4 points · first shared 2011 · 1 comments on HN
- 10Three Gigahertz Forever1 people · 3 points · first shared 2015 · discussion on HN
- 11An orphan olive branch to Mercurial (named branches in git)1 people · 2 points · first shared 2012 · discussion on HN
- 12Duh: A shell one-liner courtesy of GNU1 people · 2 points · first shared 2012 · discussion on HN
- 13Write just enough1 people · 2 points · first shared 2013 · discussion on HN
- 14Three Evolutionary Stages of Version Control1 people · 2 points · first shared 2009 · discussion on HN
- 15Emulating Shell Worksheets in Vim1 people · 1 points · first shared 2023 · discussion on HN
What HN people wrote when they linked it
btschaegg · 2018-10-04
I've got so many :(
I haven't seen this one so far (but haven't yet read all comments):
Whenever possible, try to avoid bugs. But, even more importantly: When given a bug report, FIX the damn bug. Don't:
- Shrug, mutter incomprehensible things and wish the person with the bug report goes away (yes, I've seen that. It infuriates me.)
- Say "that's not possible" (cf [1]). It is. It happened, no user makes this stuff up for fun.
- Say "that doesn't happen on my machine." Well done! Now make sure it doesn't on all the other ones, too!
- Say, "well, if you had configured it right,...". That's also a bug: Your documentation sucks. Fix it. Also make sure impossible/nonsensical configurations are visible (best done during startup, for example).
- Avoid commenting on the report/contacting the author because there's not enough information. Tell them you need more, what they must gather and how. If you tell everyone the same things, write a HOWTO and link there.
- Ignore bug reports. Valid reasons you're not fixing a bug are 1) you're currently busy fixing another, more important one or 2) you already understand the bug completely and have discussed the tradeoffs involved with others (write a WONTFIX with sound reasoning, please).
To sum it up: Be helpful to your users/admins/etc. Don't be a "Code Monkey".
[1]: http://plasmasturm.org/log/6debug/
Edit: Formatting, reference to 6debug :)
lkrubner · 2011-01-23
Different programming environments enforce security to different degrees, with different defaults. I'll here post some of the many criticisms that have been aimed at PHP over the years:
Andrew van der Stock writes:
--------------
For some time, I’ve been worried about the direction of PHP. As many of you know, I helped write XMB Forum and now help write UltimaBB. XMB in particular is an old code base, and UltimaBB, a descendant from XMB. I’ve done a lot to protect that code base from attack, and luckily, we’ve been missed despite some doozy and silly security issues. After writing PHP forum software for three years now, I’ve come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.
PHP needs a proper security architecture, and support for newbie programmers. PHP’s raison d’etre is that it is simple to pick up and make it do something useful. There needs to be a major push by the PHP Development team to take this advantage, and make it safe for the likely level of programmers – newbies. Newbies have zero chance of writing secure software unless their language is safe.
Think about Logo for a minute. Logo can do some interesting things, but it is not a commercially useful language because it cannot do much. But it is an excellent teaching language. PHP is like Logo – it’s a simple and easy way to get into serious web development. It is possible to write large applications in PHP, so it is useful at…
gkop · 2021-12-16
> It’s guaranteed she was pressing the gas, 0% chance she was pressing the brake
Congratulations, you reached stage 1 of debugging!
http://plasmasturm.org/log/6debug/
jlebar · 2020-10-11
Six Stages of Debugging
1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?
http://plasmasturm.org/log/6debug/
pdonis · 2019-09-18
From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided."
The obvious Edsger Djikstra reference:
[I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
http://plasmasturm.org/log/linesspent/
akx · 2017-09-14
I use this `rename` (available from Homebrew as `rename`): http://plasmasturm.org/code/rename/
fiddlerwoaroof · 2017-07-10
Also, something like this should work for network sound :) http://plasmasturm.org/log/soundserverhack/
jballanc · 2016-03-31
Reminds me of the "Six Stages of Debugging": http://plasmasturm.org/log/6debug/
forrestthewoods · 2015-11-22
1. That can't happen
2. That doesn't happen on my machine.
3. That shouldn't happen.
4. What does that happen?
5. Oh, I see.
6. How did that ever work?
Stage six is the worst. Especially when I wrote the original code.
(http://plasmasturm.org/log/6debug/)
mattsouth · 2013-10-01
I had forgotten about this site and am pleased to get a reminder. Its the place I first saw the immortal quote:
A friend of mine in a compiler writing class produced a compiler with one error message “you lied to me when you told me this was a program”.
—Pete Fenelon
http://plasmasturm.org/code/
dfc · 2013-07-10
Try this rename script if you really want to profit:
http://plasmasturm.org/code/rename/
The -z flag is phenomenal. The only thing I wish it had was a -R for recursive.
kragen · 2009-08-25
Gian,
If you want to argue that functional programming is better than object-oriented programming, you should take an object-oriented program, show how you would rewrite it as a functional program, show us why the result is better, and then show how the defects in the OO program are unavoidable within OO.
Some aspects of "goodness" for programs are:
* Brevity.
* Whether the program does something useful or at least entertaining.
* Local modifiability: that some modification of the program requires only local knowledge and local changes, rather than global knowledge and global changes. The more local, the better. This is conditional, though: requiring a ten-line change to a ten-line program is still better than requiring a twenty-line change to an eighty-line program. Demonstrating this requires that you show what is needed to make some particular change to both versions.
* Speed.
* Memory usage.
* Readability.
If you can show that your rewrite is better at least one of these axes and no worse on any of them, and that the difference is a result of OO vs. functional, then you will have shown that OO is worse than functional style for that program. This shouldn't be hard; I think symbolic differentiation is the usual example program for this. If it's better on some but worse on others, then you've shown that for that program, the choice is a situationally-dependent tradeoff.
If you can show that this is true for a wide range of programs, then you will have shown that…