Plasmasturm

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…

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…

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 :)

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/

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/)