This caught my eye on reddit:
http://epsilondelta.wordpress.com/2006/01/31/programming-like-a-mathematician-ii\
-learning-new-languages/
My antennae began to twitch at the point were Dziuba distinguishes the
programmer who _understands_ Java who will think thoughts like "Hmm,
network programming. This feels awful similar to file I/O. I bet they
use the same basic structure. I'll have a look at the docs" from the
one who, as he puts it, simply _knows_ Java who will "fire up IE, type
in www.google.com and search for java network programming". I'm pretty
sure that I'd do the second approach first and the first approach
second and I'm not sure I know why that would be bad. In fact, I just
did google for java network programming and the first hit is a
fantastically useful FAQ.
The programmer who understands a language, in Dziuba's model, grasps
the "fundamental tenet" of the language (by analogy with the various
Fundamental Theorems of this and that in maths) and has trained
themselves in how that tenet conditions solutions in that language and
is able to "understand the fundamentals to a point where [they] can
build upon them in the simplest way to get the most efficient answer
to the question at hand". Furthermore, the _effective_ programmer can
"for any given problem [...] mentally visualize and express in code,
the shortest path to solution". A voice in my head appends "in one
step" to the end of that, but I'm not 100% sure thats the intent.
Anyway, I suppose that people who can do this must exist but I don't
think I've met one in ten years of commerical programming. On the
other hand I have met a number of people who's productivity in that
setting is quite low because they insist on fathoming out the
uttermost details and nethermost implications of the implementation of
BufferedInputStream before making any use of it.
Learning a programming language the way a mathematician learns a new
branch of the subject (although I don't quite believe that they do
this the way Dziuba seems to suggest) doesn't seem like such a
fantastic notion to me. Which raises the question: how would you go
about learning a language like a post-modernist?
Keith
Using technology for the sake of it is a universal failing, but the
idea that there should be a Universal reuse library is certainly
modernist. And I guess the idea that it needs to be automated in a
"clean" mechanical way is modernist.
S.
On 30 Jan 2006, at 01:02, Michael Feathers wrote:
> Yeah... it's funny.. with these sorts of silliness, I don't know
> whether
> tying them to modermism is "right." It feels right in a way but it
> also
> feels off.
>
> Nat Pryce wrote:
>
>> At least they wanted make a tool to help share code. I've seen
>> projects with a "reuse" charter burn six figure sums writing
>> frameworks from scratch that don't meet anybody's needs -- because
>> the
>> reuse team never spoke to the end-users (development teams).
>>
>> --Nat.
>>
>> On 1/25/06, Michael Feathers <mfeathers@...> wrote:
>>
>>
>>> I haven't run across it, but it makes sense. I'll never forget
>>> the time
>>> I went to company wide meeting of geeks with my boss (I was a junior
>>> programmer at the time) and we sat through a hour of plans to make a
>>> reuse library for the company I was at. What was the first
>>> task? Make
>>> an application to manage the reuse library, of course. This was all
>>> pre-web but it was just silly. Walking back I told my boss that we
>>> should've just designated someone to be the librarian, written up
>>> some
>>> summaries, and let the librarian keep track of the summaries.
>>> But no,
>>> we were programmers, we had to code something... but we never
>>> did. I've
>>> seen the same sort of scenario repeat itself at many companies.
>>> We're
>>> programmers and we have a big hammer. We'll make something shiny
>>> and
>>> new. Why a program? Because we're programmers.
Yeah... it's funny.. with these sorts of silliness, I don't know whether
tying them to modermism is "right." It feels right in a way but it also
feels off.
Nat Pryce wrote:
>At least they wanted make a tool to help share code. I've seen
>projects with a "reuse" charter burn six figure sums writing
>frameworks from scratch that don't meet anybody's needs -- because the
>reuse team never spoke to the end-users (development teams).
>
>--Nat.
>
>On 1/25/06, Michael Feathers <mfeathers@...> wrote:
>
>
>>I haven't run across it, but it makes sense. I'll never forget the time
>>I went to company wide meeting of geeks with my boss (I was a junior
>>programmer at the time) and we sat through a hour of plans to make a
>>reuse library for the company I was at. What was the first task? Make
>>an application to manage the reuse library, of course. This was all
>>pre-web but it was just silly. Walking back I told my boss that we
>>should've just designated someone to be the librarian, written up some
>>summaries, and let the librarian keep track of the summaries. But no,
>>we were programmers, we had to code something... but we never did. I've
>>seen the same sort of scenario repeat itself at many companies. We're
>>programmers and we have a big hammer. We'll make something shiny and
>>new. Why a program? Because we're programmers.
>>
>>Michael Feathers
>>www.objectmentor.com
>>
>>
>>
>>
>>
>>
>>
>>Yahoo! Groups Links
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
Nat Pryce wrote:
>I won't be at SPA but I will be at ACCU.
>
>Your article really resonates with me. Even now I like to learn how
>to use a new tool, technology or technique by taking it as far as it
>will go, and then too far to see what bad things happen. I suggested
>it to Ade for inclusion in his apprenticeship patterns book but I
>don't think he was keen.
>
Thanks. Yeah, I look forward to seeing you there.
How many of you all are going to be at SPA? I know Steve Freeman's
going to be there. Ivan? Keith?
Michael
http://www.microformats.org/
From http://www.microformats.org/about/:
"Designed for humans first and machines second, microformats are a set
of simple, open data formats built upon existing and widely adopted
standards. Instead of throwing away what works today, microformats
intend to solve simpler problems first by adapting to current
behaviors and usage patterns (e.g. XHTML, blogging)."
Their design principles sound very Scrapheap Challenge friendly:
microformats are:
* a way of thinking about data
* design principles for formats
* adapted to current behaviors and usage patterns ("Pave the cow paths.")
* highly correlated with semantic XHTML
* a set of simple open data format standards that many are
actively developing and implementing for more/better structured
blogging and web microcontent publishing in general.
* "An evolutionary revolution"
* all the above.
microformats are not:
* a new language
* infinitely extensible and open-ended
* an attempt to get everyone to change their behavior and rewrite
their tools
* a whole new approach that throws away what already works today
* a panacea for all taxonomies, ontologies, and other such abstractions
* defining the whole world, or even just boiling the ocean
* any of the above
the microformats principles
* solve a specific problem
* start as simple as possible
* design for humans first, machines second
* reuse building blocks from widely adopted standards
* modularity / embeddability
* enable and encourage decentralized development, content, services
--- In postmodernprogramming@yahoogroups.com, "Keith Braithwaite"
<Keith.Braithwaite@w...> wrote:
>
> --- In postmodernprogramming@yahoogroups.com, "olibye"
> <oli.yahoo@x> wrote:
> >
> >
> > >
> > > Anyway, has anyone come across this notion of Koestler's
> > before/elsewhere?
> > >
> > > Keith
> > >
> >
> > Speaking of lead, I always like the joke about the NASA pen, developed
> > at great expence that can write in zero gravity. The Russians used a
> > pencil.
> Is this more or less funny once we know that the space pen was
> developed by a commerical company with no links to NASA (and lead
> (boom-boom) by a deeply eccentric fellow) to solve a largely
> non-existant problem. The Americans also used pencils.
>
> > With respect to "haha insight", Edward De Bono encourages humour for
> > generating lateral thinking solutions:
> Interesting. The usual "brainstorm" rules state quite clearly no
> laughing, smirking etc.
>
> Keith
>
Less funny
Andrew Eland wrote:
>On 1/27/06, Muness Alrubaie <muness@...> wrote:
>
>
>>By the way, if anyone is wondering why OptimalJ is so slow, I suggest
>>the reason is that it it is developed using, you guessed it, OptimalJ.
>>
>>
>
>I wonder how they developed the embryonic OptimalJ they used to
>generate the final OptimalJ? I'm sure there was a meta-meta-meta-model
>involved somewhere.
>
>
It's turtles all the way down... :-)
On 1/27/06, Muness Alrubaie <muness@...> wrote:
> By the way, if anyone is wondering why OptimalJ is so slow, I suggest
> the reason is that it it is developed using, you guessed it, OptimalJ.
I wonder how they developed the embryonic OptimalJ they used to
generate the final OptimalJ? I'm sure there was a meta-meta-meta-model
involved somewhere.
-- Andrew
Seems early for April fool's jokes, no?
Sad thing is, I've met people who have waxed poetic about MDA tools in
a manner no different than that used in the quote, below. They were
biased developers of one such tool (OptimalJ), so maybe they were just
saying what they had to to sell the product.
By the way, if anyone is wondering why OptimalJ is so slow, I suggest
the reason is that it it is developed using, you guessed it, OptimalJ.
Muness
On 1/27/06, Andrew Eland <postmodern@...> wrote:
> http://www.waterfall2006.com/
>
> Obviously from the XP community, but I think it's a pretty good parody
> of high-modernism too:
>
> """
> As I sat their daydreaming, I realized that this always happens. My
> beautiful and elegant designs never seem to survive the coders. The
> designs always rot into some parody of their former glory.
>
> And then it hit me. The designs weren't the problem, it was the code!
> Code ruins designs. The solution to this problem seemed so obvious
> that my jaw nearly hit the floor. All we have to do to preserve our
> designs is refuse to code them!
>
> So I bought an MDA tool and started drawing designs that the tool
> could execute. What a joy! There were no programmers to ruin my
> design. There were not crass coding issues to destroy the abstract
> beauty of my structures. I was sure this was the answer.
> """
>
> -- Andrew
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
http://www.waterfall2006.com/
Obviously from the XP community, but I think it's a pretty good parody
of high-modernism too:
"""
As I sat their daydreaming, I realized that this always happens. My
beautiful and elegant designs never seem to survive the coders. The
designs always rot into some parody of their former glory.
And then it hit me. The designs weren't the problem, it was the code!
Code ruins designs. The solution to this problem seemed so obvious
that my jaw nearly hit the floor. All we have to do to preserve our
designs is refuse to code them!
So I bought an MDA tool and started drawing designs that the tool
could execute. What a joy! There were no programmers to ruin my
design. There were not crass coding issues to destroy the abstract
beauty of my structures. I was sure this was the answer.
"""
-- Andrew
--- In postmodernprogramming@yahoogroups.com, "olibye"
<oli.yahoo@x...> wrote:
>
>
> >
> > Anyway, has anyone come across this notion of Koestler's
> before/elsewhere?
> >
> > Keith
> >
>
> Speaking of lead, I always like the joke about the NASA pen, developed
> at great expence that can write in zero gravity. The Russians used a
> pencil.
Is this more or less funny once we know that the space pen was
developed by a commerical company with no links to NASA (and lead
(boom-boom) by a deeply eccentric fellow) to solve a largely
non-existant problem. The Americans also used pencils.
> With respect to "haha insight", Edward De Bono encourages humour for
> generating lateral thinking solutions:
Interesting. The usual "brainstorm" rules state quite clearly no
laughing, smirking etc.
Keith
On 1/25/06, Stephen Freeman <steve@...> wrote:
> http://www.mashupcamp.com/
Maybe. I can certainly see a lot of potential for postmodern
development, but it's also possible that people will mashup
findaproperty.com with Google Maps via a written-from-scratch,
UML-designed-up-front, CORBA beating object RPC system.
Microsoft and Eclipse seem to have come presence, it'll be interesting
to see what comes out of those crowds.
-- Andrew
>
> Anyway, has anyone come across this notion of Koestler's
before/elsewhere?
>
> Keith
>
Speaking of lead, I always like the joke about the NASA pen, developed
at great expence that can write in zero gravity. The Russians used a
pencil.
With respect to "haha insight", Edward De Bono encourages humour for
generating lateral thinking solutions:
One exercise forces you to pick one or two nouns at random and include
them in your solution. I remember one OT session where we had to use
flippers and a news paper to help a police man direct traffic.
De Bono also suggests the "po" thing. Where you can just use the word
po in a sentence, and people must take it seriously however silly it
is. Suspend normal left brain analysis, giving the right hand side
some time.
IMHO http://www.drawright.com/ book has helped me give time to my
right brain.
If you want some left right brain fiction read Phil K Dick's "A
Scanner Darkly" (to be released as a film this year).
OB
At least they wanted make a tool to help share code. I've seen
projects with a "reuse" charter burn six figure sums writing
frameworks from scratch that don't meet anybody's needs -- because the
reuse team never spoke to the end-users (development teams).
--Nat.
On 1/25/06, Michael Feathers <mfeathers@...> wrote:
> I haven't run across it, but it makes sense. I'll never forget the time
> I went to company wide meeting of geeks with my boss (I was a junior
> programmer at the time) and we sat through a hour of plans to make a
> reuse library for the company I was at. What was the first task? Make
> an application to manage the reuse library, of course. This was all
> pre-web but it was just silly. Walking back I told my boss that we
> should've just designated someone to be the librarian, written up some
> summaries, and let the librarian keep track of the summaries. But no,
> we were programmers, we had to code something... but we never did. I've
> seen the same sort of scenario repeat itself at many companies. We're
> programmers and we have a big hammer. We'll make something shiny and
> new. Why a program? Because we're programmers.
>
> Michael Feathers
> www.objectmentor.com
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
I won't be at SPA but I will be at ACCU.
Your article really resonates with me. Even now I like to learn how
to use a new tool, technology or technique by taking it as far as it
will go, and then too far to see what bad things happen. I suggested
it to Ade for inclusion in his apprenticeship patterns book but I
don't think he was keen.
--Nat.
On 1/25/06, Michael Feathers <mfeathers@...> wrote:
> I'm tempted to attempt a Modernists Anonymous BOF so that I can share
> grief with others.
>
> My modernism resurges:
> http://blogs.objectmentor.com/ArticleS.MichaelFeathers.ProgrammingOnYourOwn
>
>
> Michael Feathers
> www.objectmentor.com
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Keith Braithwaite wrote:
>
>But that's not the punchline, either. Seems that Adams refers to a
>taxonomy of creative insight. There's ah! insights requiring
>originality, aha! insights requiring discovery and haha! insights,
>which Bently describes, maybe quoting Koestler (who's taxonomy it is)
>as "the low-tech answer to a high-tech question [which is] an act of
>comic inspiration".
>
>Looks rather as if haha! solutions are something that would fit nicely
>into a post-modern approach. It's possible to be a bit too low tech,
>mind you: we recently had to put someone on a plane to go collect a CD
>from a client bearing data which they claimed couldn't be sent by any
>electronic means whatsoever for reasons of "security"--and that's just
>silly.
>
>Anyway, has anyone come across this notion of Koestler's before/elsewhere?
>
>
I haven't run across it, but it makes sense. I'll never forget the time
I went to company wide meeting of geeks with my boss (I was a junior
programmer at the time) and we sat through a hour of plans to make a
reuse library for the company I was at. What was the first task? Make
an application to manage the reuse library, of course. This was all
pre-web but it was just silly. Walking back I told my boss that we
should've just designated someone to be the librarian, written up some
summaries, and let the librarian keep track of the summaries. But no,
we were programmers, we had to code something... but we never did. I've
seen the same sort of scenario repeat itself at many companies. We're
programmers and we have a big hammer. We'll make something shiny and
new. Why a program? Because we're programmers.
Michael Feathers
www.objectmentor.com
So, I was re-reading Programming Pearls (2nd ed.) One problem that
Bently addresses (in Column 12) is that of selcting n from m items at
random. There's some stuff about recalling that Knuth deals with this
and finding "Algorithm S" from section 3.4.2 of tAoCP and off he goes.
But then he tells of subsequently giving this problem to a West Point
class to solve. One of the students suggests putting the name of each
item on a slip of paper, then drawing n slips out of a hat.
But that's not the punchline. Bently describes the pointer's solution
as an example of "conceptual blockbusting" as referenced in Adams's
book of that title (which I have not read).
But that's not the punchline, either. Seems that Adams refers to a
taxonomy of creative insight. There's ah! insights requiring
originality, aha! insights requiring discovery and haha! insights,
which Bently describes, maybe quoting Koestler (who's taxonomy it is)
as "the low-tech answer to a high-tech question [which is] an act of
comic inspiration".
Looks rather as if haha! solutions are something that would fit nicely
into a post-modern approach. It's possible to be a bit too low tech,
mind you: we recently had to put someone on a plane to go collect a CD
from a client bearing data which they claimed couldn't be sent by any
electronic means whatsoever for reasons of "security"--and that's just
silly.
Anyway, has anyone come across this notion of Koestler's before/elsewhere?
Keith
On 12 Jan 2006, at 20:57, Nat Pryce wrote:
> On 1/12/06, Stephen Freeman <steve@...> wrote:
>> I inflicted it on my students in my new course. The only ones who
>> really achieved anything used wget and grep. Many attempted solutions
>> using MS Office, which involved lots of cutting and pasting of text.
>> Some of these later fell back to Java but by then they were too late.
>
> Could you write it up? Brief notes would be enough. I can publish
> them onto the website.
I'm intending to run the exercise again after they've seen some other
technology. Let's see what happens. (I'm being over-optimistic again,
aren't I...)
As for the MS world, I know of a certain systems integrator
consultancy that has many of the right people to try it out in...
S
--- In postmodernprogramming@yahoogroups.com, Michael Feathers
<mfeathers@m...> wrote:
> Unix was a reaction to a modernist system: Multics. Do you think that
> most roads in PomoP will lead back to Unix?
Maybe the Unix way turns out to have captured a lot of what we mean by
po-mo programming many epochs before the term in much the same way as
Tristram Shandy did for po-mo literature.
Hmm, does that make Larry Wall the David Foster Wallace of programming?
Keith
Thanks Andrew. I've added the paragraph about the C++ solutions to
your Google report on the postmodernprogramming.org website.
--Nat
--- In postmodernprogramming@yahoogroups.com, Andrew Eland
<postmodern@a...> wrote:
>
> On 1/12/06, nat_pryce <nat.pryce@g...> wrote:
> > ...I'd be interested in hearing about the results of the workshop
at Google
> > where C++ programmers did very well.
>
> The C++ programmers did very well, but typically the bulk of their
> solution was implemented as a UNIX shell pipeline. The C++ only
> covered tasks that would have been too tricky with awk. I think most
> people would opt for a scripting language in this situation, but if
> you're an STL guru, using C++ isn't such a handicap for small
> components.
>
> I think the workshops so far have shown that scrapheap programming
> requires three things:
> - The ability to easily connect small components together
> - The ability to easily transform data, enabling components with
> differing interfaces to be joined together
> It seems to me that UNIX style systems have the edge here, but we
> should apply the standard interview technique of probing for contrary
> evidence, and run a scrapheap challenge workshop at the next Microsoft
> PDC.
>
> -- Andrew
>
On 1/12/06, Stephen Freeman <steve@...> wrote:
> I inflicted it on my students in my new course. The only ones who
> really achieved anything used wget and grep. Many attempted solutions
> using MS Office, which involved lots of cutting and pasting of text.
> Some of these later fell back to Java but by then they were too late.
Could you write it up? Brief notes would be enough. I can publish
them onto the website.
> Didn't someone post the Google write up somewhere?
I posted Andrew's report on postmodernprogramming.org but I'd be
interested in more details about the C++ solutions.
--Nat
--- In postmodernprogramming@yahoogroups.com, Andrew Eland
<postmodern@a...> wrote:
> It seems to me that UNIX style systems have the edge here, but we
> should apply the standard interview technique of probing for contrary
> evidence, and run a scrapheap challenge workshop at the next Microsoft
> PDC.
That's a great idea.
--Nat
On 1/12/06, nat_pryce <nat.pryce@...> wrote:
> ...I'd be interested in hearing about the results of the workshop at Google
> where C++ programmers did very well.
The C++ programmers did very well, but typically the bulk of their
solution was implemented as a UNIX shell pipeline. The C++ only
covered tasks that would have been too tricky with awk. I think most
people would opt for a scripting language in this situation, but if
you're an STL guru, using C++ isn't such a handicap for small
components.
I think the workshops so far have shown that scrapheap programming
requires three things:
- The ability to easily connect small components together
- The ability to easily transform data, enabling components with
differing interfaces to be joined together
It seems to me that UNIX style systems have the edge here, but we
should apply the standard interview technique of probing for contrary
evidence, and run a scrapheap challenge workshop at the next Microsoft
PDC.
-- Andrew
Another piece that struck me as relevant is Foote and Yoder's The
Selfish Class [1]. Comparing the paper to Nat's write up [2] is
striking.
Maybe the reason postmodern programming and unix share so much
philosophically is that they're both movements that are pragmatic in
nature. When you're trying to build something that just works you end
up with pieces that are evolutionarily fit. (For a treatment of the
meaning of fitness, I suggest Richard Dawkins' The Extended
Phenotype[3], where he even dedicates a chapter to the way the term
has been used.)
So maybe postmodern programming is really about coming to terms with
the fact that nature is the real designer and not us. Instead of
trying to design systems that are perfect in the modern tradition, we
design systems that can evolve [4].
As for the suggestion that postmodern programming will lead back to
Unix, why? Wouldn't it make more sense for others simply to copy
aspects of Unix that make it adaptable?
Muness
[1] http://www.joeyoder.com/papers/patterns/Selfish/selfish.html
[2] http://nat.truemesh.com/archives/000555.html
[3] isbn://0192880519
[4] http://muness.blogspot.com/2005/06/change-management-vs-evolution-and.html
On 1/12/06, Michael Feathers <mfeathers@...> wrote:
>
> I've been flipping through Eric Raymond's 'Art of Unix Programming'
> again, and it is neat to see what is the same and what is different
> compared to notions of good design that have developed in OO communities.
>
> The parallels between the Scrapheap Challenge results and the Unix
> philosophy are striking.. open pieces and glue seem to win..
>
> Unix was a reaction to a modernist system: Multics. Do you think that
> most roads in PomoP will lead back to Unix?
>
> Michael
I inflicted it on my students in my new course. The only ones who
really achieved anything used wget and grep. Many attempted solutions
using MS Office, which involved lots of cutting and pasting of text.
Some of these later fell back to Java but by then they were too late.
On 12 Jan 2006, at 16:36, nat_pryce wrote:
> One reason was that most of the solutions used Unix shell scripts and
> existing filters with a few custom filters to fill in the gaps. We've
> only run the workshop with a few people. I'd like to run it with
> people with a wide range of expertise in different languages and
> environments.
The Smalltalk world is a collection of bits and pieces anyway, it
just happens to run in an image, so I don't think there need be much
difference there. Haven't tried it in Haskell. Didn't someone post
the Google write up somewhere?
> I'm sure that Smalltalk and Haskell programmers have a
> different view about how to plug stuff together and I'd be interested
> in hearing about the results of the workshop at Google where C++
> programmers did very well.
Isn't this just the usual tension? Postmodern systems are only
possible because of the work of the modernists. I was going to say
that processor chips are modernist, until I thought about x86
range :) Is this really the same pattern as Hard And Soft Layers?
Reminds me of a story I heard from someone about porting a Fortran
library from a VAX to an mainframe.
- "Um, what do I do to create a file?"
- "Easy, just fill out this form and send it to the Ops people"
>> Unix was a reaction to a modernist system: Multics. Do you think
>> that
>> most roads in PomoP will lead back to Unix?
>
> I think that's probably quite true. The Unix Way is one of those
> things, like Lisp, that people keep rediscovering. The Windows monad
> shell and REST web architectures come to mind.
S.
--- In postmodernprogramming@yahoogroups.com, Michael Feathers
<mfeathers@m...> wrote:
>
>
> I've been flipping through Eric Raymond's 'Art of Unix Programming'
> again, and it is neat to see what is the same and what is different
> compared to notions of good design that have developed in OO
communities.
>
> The parallels between the Scrapheap Challenge results and the Unix
> philosophy are striking.. open pieces and glue seem to win..
One reason was that most of the solutions used Unix shell scripts and
existing filters with a few custom filters to fill in the gaps. We've
only run the workshop with a few people. I'd like to run it with
people with a wide range of expertise in different languages and
environments. I'm sure that Smalltalk and Haskell programmers have a
different view about how to plug stuff together and I'd be interested
in hearing about the results of the workshop at Google where C++
programmers did very well.
Actually, I know that Haskell programmers have a different view after
reading the following blog post that somewhat misinterprets, or
misunderstands, the Scrapheap Challenge writeup:
http://www.scannedinavian.com/2005-11-06.html.
> Unix was a reaction to a modernist system: Multics. Do you think that
> most roads in PomoP will lead back to Unix?
I think that's probably quite true. The Unix Way is one of those
things, like Lisp, that people keep rediscovering. The Windows monad
shell and REST web architectures come to mind.
--Nat
I've been flipping through Eric Raymond's 'Art of Unix Programming'
again, and it is neat to see what is the same and what is different
compared to notions of good design that have developed in OO communities.
The parallels between the Scrapheap Challenge results and the Unix
philosophy are striking.. open pieces and glue seem to win..
Unix was a reaction to a modernist system: Multics. Do you think that
most roads in PomoP will lead back to Unix?
Michael
>
>
>
>
>
>
I've updated the postmodernprogramming.org site with a report by
Andrew Eland of the Scrapheap Challenge workshop he ran inside Google
at the end of last year.
--Nat.