Standard Forth versus Python: a case study
werty at swissinfo.org
Thu Oct 12 07:03:58 CEST 2006
Apples/oranges ? programmers are making very little $$ today .
Thats software ! No one is makin money on obsolete Forth ,
so why a comparisom ?
Ultimately the best OpSys will be free and millions of lines of code
obsoleted . Because no one can protect intellectual property , its
simply too costly for a Government to do this .
Notice the crypto fiasco , the USA govt forbad export of SSL and
in short order Australia gave the world a free SSLeasy !
This is software . No one will , for long , own software .
Microsoft and Linux will die in 24 months . No hardware will
produce money/profits using them .
Because we have a new hardware competitor , that obsoletes the BIOS
chip , North bridge/South bridge USB helpers , NICs .
No mo PNP (Plug_and_Pray) .
In 2 chips ( CPU /SoC and LCD controller) it will be faster than
a PC . 100's have allready written HDD drivers and haven't yet
free'd them . But when others give free , what good do it to
hold yours ! You look stupid selling what others improve and
free . Trying to sell what others find easy to create !
Intel made hardware too hard to program , ARM is easy .
Python wont last on ARM , for WCE and Linux will be tossed .
A simpler structured method will be used to customise
Browsers . There will be 2 columns , one on left will be main/orig
but on the Right will have hyperlink result . This way ya dont have
to go back to compare ! side by side .
Text editors will also work this way . You will read orig in left
and 'edit'/annotate your stuff to the Right columns .
Sun microsystems et all ( the ones we seldom think about ) will
all be obsoleted , bankrupted , their hardware surplused .
No more h/w servers .
There will be no high speed 64 bit boxes in the future .
The Pocket PC will do work you could not imagine !
All will have 100 GB HDD , VGA LCD , USBH/USBD , WIFI N
and no WERTY keyboard ! full GUI ...
ethernet and firewire and rs232 will die
Why not "see" the future ?
No Linux ,no WXP , no C+ , no PC .....
John Doty wrote:
> I realized that I have a little job on the table that is a fine test of
> the Python versus Standard Forth code availability and reusability issue.
> Note that I have little experience with either Python or Standard Forth
> (but I have much experience with a very nonstandard Forth). I've noodled
> around a bit with both gforth and Python, but I've never done a serious
> application in either. In my heart, I'm more of a Forth fan: Python is a
> bit too much of a black box for my taste. But in the end, I have work to
> get done.
> The problem:
> I have a bunch of image files in FITS format. For each raster row in
> each file, I need to determine the median pixel value and subtract it
> from all of the pixels in that row, and then write out the results as
> new FITS files.
> This is a real problem I need to solve, not a made-up toy problem. I was
> originally thinking of solving it in C (I know where to get the pieces
> in that language), but it seemed like a good test problem for the Python
> versus Forth issue.
> I looked to import FITS reading/writing, array manipulation, and median
> determination. From there, the solution should be pretty easy.
> So, first look for a median function in Python. A little googling finds:
> Wow! This is good stuff! An embarrassment of riches here! There are even
> several FITS modules, and I wasn't even looking for those yet. And just
> for further gratification, the page's author is an old student of mine
> (but I'll try not to let this influence my attitude). So, I followed the
> link to:
> From there, I downloaded stats.py, and the two other modules the page
> says it requires, and installed them in my site-packages directory. Then
> "from stats import median" got me a function to approximately determine
> the median of a list. It just worked. The approximation is good enough
> for my purposes here.
> Pyfits required a little more resourcefulness, in part because STSCI's
> ftp server was down yesterday, but I got it installed too. It helps that
> when something is missing, the error message gives you a module name. It
> needs the numarray module, so I got array manipulation as a side effect.
> I haven't finished the program, but I've tried out the pieces and all
> looks well here.
> OK, now for Forth. Googling for "forth dup swap median" easily found:
> At first blush, this looked really good for Forth. The search zeroed in
> on just what I wanted, no extras. The algorithm is better than the one
> in the Python stats module: it gives exact results, so there's no need
> to check that an approximation is good enough. But then, the
> disappointment came.
> What do you do with this file? It documents the words it depends on, but
> not where to get them. I'm looking at a significant effort to assemble
> the pieces here, an effort I didn't suffer through with Python. So, my
> first question was: "Is it worth it?".
> The answer came from searching for FITS support in Forth. If it exists
> in public, it must be really well hidden. That's a "show stopper", so
> there was no point in pursuing the Forth approach further.
> In the end, it was like comparing a muzzle-loading sharpshooter's rifle
> with a machine gun: Forth got off one really good shot, but Python just
> mowed the problems down.
> The advocates of the idea that Standard Forth has been a boon to code
> reusability seem mostly to be people with large private libraries of
> Forth legacy code. No doubt to them it really has been a boon. But I
> think this little experiment shows that for the rest of us, Python has a
> published base of reusable code that puts Forth to shame.
> John Doty, Noqsi Aerospace, Ltd.
> Specialization is for robots.
More information about the Python-list