[ColorForth] Let's talk philosophy

[Jack Johnson <fragment@xxxxxxx>]

Let me preface this message by saying that if you detest long-winded 
ramblings, hit delete as quickly as possible.

In the late '80s, I got hooked on Niklaus Wirth's Oberon System.  I had found 
the Oberon language easy to learn and the system fun to play with, but I ran 
headlong into the problem of interoperability that seemed to be so prevalent 
during those years.  So, in an attempt to be self-sufficient I wrote a 
half-dozen little utilities to do the things I wanted and needed.  Along with 
the image file converters and other odds and ends I kludged Oberon's serial 
drivers together with the world's largest CASE statement to provide just 
enough VT100 emulation to satisfy Pine over my pathetic dialup connection.  
Of course, the next step had to be file transfers.  

Which brings me to the subject of the message.  Chuck has voiced some pretty 
accurate observations of the current state of software today, namely the 
marriage of library hell with code bloat.  He's also shared his unflattering 
opinions of certain other languages and systems that tend to pipe data from 
one program to the next, on and on until the desired result is reached.  If 
I'm interpreting his statements correctly, it seems that Chuck favors 
building "the right tool for the job" rather than the Unix philosophy of "do 
one thing, and do it well (and pipe it to the next thing until the output 
looks right)".

I feel like I'm starting to understand Chuck's philosophy, and I agree with 
it, but I also think a very valid flipside is the steaming pile of coding 
heritage we share with the myriad other languages out there.  Though Chuck 
may never need to parse the output from someone else's program, those of us 
who get Excel chaff in our inboxes sometimes need to massage it into 
something else.  In my historical example, I needed to get data from a VAX 
host to an Oberon system via modem.  I suppose I could have written a file 
transfer program on both ends, or I could have implemented an existing 
protocol in Oberon.  Of course, there's always a better solution, and often 
there are excellent solutions outside the set towards which we gravitate (in 
my case, SneakerNet), but the fact remains that we will always need to 
transfer data from one system to another, whether that means bringing 
information from a legacy system into colorForth or something as simple as 
sending a PNG screenshot from colorForth as an e-mail attachment (from a 
nonexistent, native e-mail client).  Often, these transfers won't be a 
single-shot "script" but something that will be repeated frequently.  Kind of 
like the process that brought us to library hell in the first place.

We could argue that adding a filesystem isn't much more than the slippery 
slope towards code bloat.  Though colorForth is still in its infancy, I 
continue to wonder in what direction it is headed.  The problem with the idea 
of the promised land is that everyone has a different idea of heaven, and 
once someone finally writes down what heaven looks like quite a few crackpots 
will decide not to go.  Who really wants to implement zmodem in Forth 
(again)?  Though zmodem's continued usefulness is questionable, the idea of a 
colorForth VNC or ssh client seems as useful as zmodem was a decade ago, but 
equally daunting to construct.  Even Chuck wants a Web browser, but in a 
decade will it look like just another XML interpreter?

Where I see real, tangible promise is (color)Forth as a bridge.  There are 
two projects that came into my radar recently, both building on pForth.  One 
hooks Linux kernel syscalls, the other the FLTK X window toolkit.  With good 
coding practices, I can see writing software that ports easily between 
colorForth and some kind of colorForth/Linux hybrid.  And just as I currently 
value the ability to use someone else's zmodem implementation, I also like 
the idea of using someone else's audio card driver with my own Forth 
application, especially if the development of said driver didn't distract 
Chuck from coming up with the Next Fantabulously Astounding Thing.  I 
sometimes feel like the choices Chuck has put before us with colorForth is 
also asking us to draw a line in the sand, prodding us to decide what kind of 
baggage we want to bring with us into his brave new world.  Will any C code 
ever compile on a 25x?  Do we really need a generic computer?  Can you really 
build a better (computing) world one application or device at a time?  What 
are we--what am I--willing to give up to get there?

So, to generate some traffic in this mostly quiet mailing list I thought you 
might be willing to share your ideas with the rest of us.  Why colorForth?  
What brought you here?  Not only "Where do you want to go today?" but where 
do you want to be tomorrow?  And how do you get there from here?

Give us some fodder for thought.  Or at least a Brodieistic cartoon.

-Jack
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com