I was at Uni with Mike Cowlishaw who created Rexx- clever guy.
On Mon, 20 Mar 2017 at 04:22, Moose <olymoose@xxxxxxxxx> wrote:
> On 3/17/2017 10:07 AM, David Thatcher wrote:
> > Hi Jan,
> >
> > I trust all is well with you and yours.
> >
> > On Thu, Mar 16, 2017 at 10:14:34AM -0700, Jan Steinman wrote:
> >> I think you should cut interpreters some slack!
> >> In my (admittedly dated) experience, a good interpreter actually
> >> *reduces* the memory volume that a given amount of functionality
> >> consumes, trading it off for reduced run-time speed.
> >>
> >> You can think of the virtual code as a fixed set of subroutines. So in
> >> Smalltalk (for a lovely, but obsolete example), you had a library of 256
> >> subroutines that you could call ??? some, as complicated as BITBLT,
> >> which did all sorts of complicated image manipulation ??? all at the
> >> cost of ONE BYTE!
> > You did say GOOD interpreters. :)
>
> I've always thought the system in which I developed many apps, including
> one still being used by top management of a
> huge company - 17 years after my retirement, was close to ideal in overall
> design:
>
> Visual design of common app elements interpreted into a powerful, flexible
> language.
> The ability to do anything the visual design wouldn't by programming, such
> as complex calculations.
> Optimizing compiler to small native EXEs.
>
> The original implementation was really good. After a merger with a maker
> of optimizing compilers, it got better. Just
> about everything I did dealt with data, and I/O was always the speed limit.
>
> It was possible to include all needed subroutines from the libraries in
> the finished app. Or, in a situation where many
> programs might be running and want to share resources, compile to grab
> subs from a library when running.
>
> All run time efficiencies completely moot on today's fast machines with
> huge 'disks' and gobs of memory, but it was
> impressive on laptops of many years ago. A few other things might seem
> quick, until they ran OSCAR. :-)
>
> > Bloat in the interpreter subroutines
> > is bad, that one byte blows out to hundreds of lines of code in the
> > subroutine call and is just as much a pain for users as big inline code.
> > Having written BIOS primate functions in Z80 for homebrew CP/M-alike
> > system (and at one time I had a need to convert TVI912 escape codes to
> > VT52 on the fly in the charout call), it's easy to see how easy the
> > waste can grow. Sooner or later, no matter how many layers of
> > abstraction, the raw cpu-specific machine code *has* to be executed. If
> > the interpreter/virtual machine is just rubbish, we're in trouble! :)
> >
> > In the true general-purpose system, even the interpreter is loaded when
> > required and becomes part of the memory consumption only while resident-
> > which reminds me of high school: putting the orange 'PACKAGE'
> > (Hollerith/OMR) card on top of my card stack to be sent away to the
> > state Ed Dept computing centre's IBM370, so I could have a calendar with
> > an ASCII art Snoopy (actually Einstein) on it, printed on 132 column
> > paper. I also chose the year 2000, it seemed so far away... it's just
> > about as far behind us now! We were exposed to BASIC as well - also
> > using OMR cards with the blue BASIC card on top of the stack, but
> > there's nothing worse than getting your output a week later with
> > 'Syntax error in line 10' :)
> >
> >
> >> Modern RISC processors are notorious for consuming gobs of run-time
> >> memory. ???You want to add 1 + 1? That will cost you 96 bits, >
> > m???am!??? How refreshing to push two values on a stack and execute a >
> > single bytecode!
> >
> > Yes this is true, but they do make up for it in speed. RISC is a
> > completely different mindset. Because of the instruction cache and the
> > use of branch prediction, significant savings in execution time can be
> > made - on average!
> >
> >> Another old favourite that seems to have bit the dust was FORTH.
> > I had no experience with FORTH,
>
> I played with FORTH a little. Super powerful and flexible. Only useful, to
> my mind, for someone who did clean, careful
> coding with good, immediate documentation in the code. Really easy to
> write something totally obscure without a magic
> decoder ring.
>
> The interpreter I really liked, and used a lot, was REXX, originally for
> IBM mainframe, where it was truly invaluable,
> later for PCs, and still available for Windoze as part of my favorite
> programming editor, KEDIT.
>
> En Coded Moose
>
> --
> What if the Hokey Pokey *IS* what it's all about?
> --
> _________________________________________________________________
> Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
> Archives: http://lists.thomasclausen.net/mailman/private/olympus/
> Themed Olympus Photo Exhibition: http://www.tope.nl/
>
>
--
_________________________________________________________________
Options: http://lists.thomasclausen.net/mailman/listinfo/olympus
Archives: http://lists.thomasclausen.net/mailman/private/olympus/
Themed Olympus Photo Exhibition: http://www.tope.nl/
|