Comments on: Rediscovering the obvious

By: Paul M Jones

Paul M Jones — Tue, 30 Nov 1999 00:00:00 +0000

Harry, you left out a quote right after the lead-in "What stuck me as perhaps the remark of the whole book was this;". Am interested to see the excerpt. :-)

-- pmj

By: arborint

arborint — Tue, 30 Nov 1999 00:00:00 +0000

A little too much to comment Harry. Wow.

I was interested in you comments on: "follow us, we know better, sacrifice your reason to the revolution" I think this is true (and maybe necessary) that these groups hype their method. It was true of structured programming, OOP, extreme programming, now AOP and Software Factories. The problem is there is no meta layer on top to match the methodologies to the programmers. Maybe someday someone will come up with a questionaire for programmers that then recommends which tool chains might work best for them.

I think it is pretty funny that Visual Studio 2005 Team System has now invented many of the paradigms that open source programming has been using for years. Good for Microsoft!

Final thought regarding code generation. I think PHP is a domain specific language in many ways. It certainly has a reduced problem space. I think code generation is possible when there are good foundation code. That is why things like your ScriptServer are so interesting and important. They become a target for code generation. This is especially useful for the nasty problems like keeping PHP and Javascript talking together where a code generator can make the programmer's life much easier.

By: culley

culley — Tue, 30 Nov 1999 00:00:00 +0000

I liked to book as well. I found his "emacs is clearly the best editor in the world" attitude blind to the fact that editor choice is a *preference*, but other than that it was mostly a good read.

culley

By: James

James — Tue, 30 Nov 1999 00:00:00 +0000

I find the phrase "tool chains" to be interesting - do they really bind the programmer?

Right now, software programming is a job of craftsmanship, not production. I don't know that it will ever have a Henry Ford to automate the production. How can you turn intent into code? You can explain (pseudo-code) the intent, then turn the pseudo-code into real code - but that's what interpretive languages are supposed to do anyway.

I think, that in the end, Software coding will be more along the lines of the medical profession (we learn a lot of basic rules, memorize a TON of facts, but in the end are free to excercise our good judgement) than a 'Software Factory'.

Project Management will help define the intent, but coders will always have to turn the pseudo-code (read: specs) into real code.

By: HarryF

HarryF — Tue, 30 Nov 1999 00:00:00 +0000

Not sure I'd underestimate Microsoft - I'm sure the TEAM version of Visual Studio will be excellent. Just would rather see them sell it on it's own merits, rather than trying to invent a new "theology".

Back to The Art of Unix Programming, another part which echoes in PHP is here;

The wrong way to get to a minilanguage design is to extend your way to it, one patch and crufty added feature at a time. On this path, your specification file keeps sprouting more implied control flow and more tangled special-purpose structures until it has become an ad-hoc language without your noticing it.

Wonder where we've seen that before in PHP? ;)