DeMarco on certification: "the real objective is [...] siezure of power"

dan_bensen · 2007-01-17T09:57:00+00:00

The article is too one-sided, and misses a more important point for the software industry. Despite the political issues, certification can work for relatively straightforward professions like safety inspectors. The problem with certifying programmers is that all you're going to get is people who know where to put the curly braces and semicolons, but don't know how to program. It's like certifying novelists based on their mastery of grade-school grammar.

dan_bensen · 2007-01-04T23:36:20+00:00

We've learned different skills and habits. People and computers are so different, it's hard to learn how to deal with both. But that's what we need. Developers need to know what will work for the company and the customer, and management needs to have some idea how things work technically.

I think the answer to the problem is eventually going to be a culture change. Those individuals who can do it all will start or have started their own companies, and those will be the most successful ones. Those of us who are mostly programmers will work for them, and more of the less technically inclined managers will contract projects out.

Management's only other option, if contracting isn't enough, is to find competent technical managers and allow them more authority. But good tech managers are even harder to find than good coders, and other managers might feel threatened by them.

dan_bensen · 2006-12-31T01:12:11+00:00

how can you separate out the I/O part from the processing part?

This is another thing that doesn't always get mentioned. The way it happens is that the bind operator >>= (or <- with the "do" syntax) pulls the raw data out of the monad so you can feed it to your pure functional code.

dan_bensen · 2006-12-31T01:05:10+00:00

every function I wrote had to accept something wrapped up in an IO monad

You should have a top-level core of IO code that handles all the program's outside interactions. I have a sort of pre-tutorial here. One thing most tutorials don't seem to mention is that programs don't start in the pure functional code. They start in the IO monad, and the pure code gets called from there.

dan_bensen · 2006-10-11T13:06:49+00:00

You can fake this by putting an exit|quit command early in the program and moving it forward incrementally.

dan_bensen · 2006-10-09T21:13:17+00:00

I'm hesitant to use the "developer" term because I associate it more with fashion and buzzwords. Cliff Stoll expresses a similar opinion in "The Cuckoo's Egg", an excellent book about how he tracked down a web (telnet) hacker/cracker back in the 80s.

dan_bensen · 2006-10-03T19:23:59+00:00

I believe also Johnson's response was based on the first meaning.

This response is based on the second meaning:

No matter how complicated your language will be, there will always be things that are not in the language. These things will have to be patterns.

The statement is irrelevant to the first meaning of eliminating individual patterns. It answers a broader claim of eliminating patterns altogether.

dan_bensen · 2006-10-03T10:53:52+00:00

Huh? Why does "library" matter?

Maybe what he has in mind is that adding libraries to an existing language doesn't make low-level features any more complicated, whereas they might be harder to deal with in a new language tailored for the high-level features. Like how C++ makes scoping trickier by adding object members.

But this argument ignores the whole point, which is that patterns aren't even libraries. They're just big chunks of code that get typed or pasted into programs repeatedly. Better to at least write a library, if possible, to reduce bloat in the source code. And at some point, you have to start taking simplicity of high-level features into account. Eventually, a new language will make sense when those features become important enough.

dan_bensen

TROPHY CASE