Standard Forth versus Python: a case study

[werty]

 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
columns
 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:
>
> http://www.astro.cornell.edu/staff/loredo/statpy/
>
> 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:
>
> http://www.nmr.mgh.harvard.edu/Neural_Systems_Group/gary/python.html
>
>  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:
>
> http://www.taygeta.com/fsl/library/find.seq
>
> 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.