On Apr 22, 2:20=A0am, Gerry <ge...@[EMAIL PROTECTED]
> wrote:
> On 21 Apr, 18:42, Elizabeth D Rather <erat...@[EMAIL PROTECTED]
> wrote:
>
>
>
> > Jonah Thomas wrote:
>
> > ...
>
> > > People say it works for Chuck Moore. He writes lots of routines that
a=
re
> > > a line or two each. Simple, clear, powerful. It does 90% of what
you'd=
> > > want it to, and the other 10% isn't needed. If it's true that 10% of
t=
he
> > > specs generate 90% of the complexity and that 10% isn't really
> > > needed.... People say Chuck is the best at using Forth. I'd like to
be=
> > > better at it than I am. What does Chuck do that I don't do? What do
I =
do
> > > that I shouldn't?
> > >...
>
> > Understanding that your percentages here are entirely rhetorical, I
> > think you're on the right track. =A0The big difference between Chuck
and=
a
> > lot of folks here is that he only solves the particular problem at
hand
> > -- he is never groping for a general solution. =A0He would never say,
"I=
> > need a better string handling package." =A0Instead, confronted with a
> > particular string challenge, he'd find the most direct way of dealing
> > with it. =A0If he is working on an application full of strings, he'd
fin=
d
> > ways to deal with its specific issues, and factor some of the common
> > needs into reusable definitions, but he would never be searching for
> > either "general purpose" functions or attempting to replicate what
some
> > other language did.
>
> > Whether this is good or bad, I can't say... but if you ask "What does
> > Chuck do that I don't do?" that's the answer.
>
> Yes different approaches to getting the job done. Earlier in this
> thread I was effectively apologising for the BNF to Gray format
> converter being a bit complicated but on thinking about it I don't
> think it is really. To build this converter, which is an off-line
> tool, I used:
> - some library code to provide memory buffers
> - an off-line tool (LexGen) to generate transition tables for a
> lexical scanner
> - library code for the lexical scanner
> - another tool (Gray) for the parser generator
>
> and then wrote higher level code to tie it together and make it all
> work.
This has come to be known as "post-modern programming", and is
sup****ted by various glue and scripting environments like shells,
Perl, Python, etc. coupled with growing code libraries like Unix,
Boost, CPAN and various other standard libraries.
The premise is that as time goes on, the number of existing solutions
to programming problems increases, and the practical effort to plug
existing solutions together should become less than
the effort to craft one's own solutions. The post-modern skill set is
slightly different, synthetic instead of creative.
Note that you can still get the benefits of tight custom solutions
with post-modern programming, if you have access to source and not
just black-box libraries. In one application, I took an existing
device driver that was both too general and half-baked, stripped 75%
of the code out of it, leaving only a tight core that was tailored to
our application. This works well in shared source cultures like Forth.
> Contrast this with the typical Forther approach of doing the whole
> thing from scratch, e.g. Jonah developing code for text recognition -
> a problem that is already solved by a general purpose lexical scanner.
> This of course results in more concise source code, faster code etc.
> but probably takes longer to develop.
I suggest that the Forth way of writing from scratch was a product of
its time. In the 70s and 80s, you didn't have public repositories of
existing solutions. Also, each programmer became his own resource,
notably Chuck and Forth vendors, and their experience ****ting to wide
varieties of systems.
> Which is the best approach, I don't know, I suppose it depends on your
> point of view, but I know which I prefer.
>
> Gerry
I personally think post-modern programming is the way of the future. A
language which cannot sup****t it is doomed to the sidelines. Thus, I
think Forth should start borrowing from other languages, continuing to
standardize but focusing more on standard code libraries, im****t
mechanisms, foreign-function interfaces and otherwise working well
with others.
Ian
|
