«

On Fri, 20 Jul 2012 04:58:00 +0000, glen herrmannsfeldt wrote:

> In comp.lang.java.programmer Nadegda <> wrote:
> (snip, someone wrote)
>>> Wow, even the name is pointlessly abbreviated to be missing one vowel.
>>> Does it date back to when machines had a few KB of core and even one
>>> byte of extra computer code could be a storage problem?
>
>> Of course not. Not that that would have been an excuse even so. The old
>> Commodore VIC-20 had a BASIC interpreter and that language had full,
>> readable keywords like PRINT rather than abbreviated garbage like, say,
>> PRN. Commodore employed a clever trick: BASIC programs were stored (on
>> disk and in memory) *compressed*, with all of the common keywords
>> replaced with graphics characters with the high bit set.
>
> The HP TSB2000 (Time Shared BASIC) systems did that, too.
>
> Not only that, it would refuse to allow you to enter a statement that
> didn't pass some syntax checks.

That's not uncommon in the better-designed systems (i.e., not C family
languages). The Emacs paredit mode for working with Lisps is probably the
example most likely to be familiar to someone who wasn't around for the
micro era. It won't let you enter syntactically broken Lisp, though it
can be semantically as bogus as you please (and verifying with certainty
that it wouldn't be would be equivalent to the halting problem anyway).
Of course, with Lisp that basically boils down to just "it won't let you
have unbalanced parentheses".

> Many of the microcomputer BASIC interpreters were based on the ones from
> Microsoft, but even if not, the tokenizing compression was well known by
> then.
>
> Not only does it save memory, but the interpreter runs a lot faster! The
> tokenizing is done only once, not each time the statement is executed.

Those microcomputers needed every erg of speed they could get, too. A
VIC-20 ran at what, one measly *mega*hertz? The box I'm using to post
news with is somewhere around five *thousand* times that speed, in raw
cycle throughput, and can probably do a lot more with each cycle to boot.
It could emulate a large network of hundreds of VIC-20s in real time if
it wanted to. And there are other boxes nearby that make *it* look like a
joke.

And even then, the interpreted languages of now tend to both compile to
bytecode (either manually, or when first run) and then to be potentially
JITted to architecture-native code by the VM. Bytecode is a step further
than the BASIC compression tricks discussed, and JITting is a giant
*leap* further still.

On 20/07/2012 12:44 AM, Nadegda wrote:
> On Thu, 19 Jul 2012 23:59:59 -0400, kensi wrote:
>> On 19/07/2012 9:26 PM, Nadegda wrote:
>>> Lots of condensing by you; it's a shame to lose that much detail of the
>>> context. Maybe trim a *bit* less?
>>
>> Don't have much choice. AIOE doesn't like posts with too high a ratio
>> of quoted lines to original.
>
> Ew. Why not find another server? Or three?

Pain in the ass to sign up for another one. If AIOE suddenly one day is
annoying enough, then I will. As for "or three", setting up some sort of
thingy to combine more than one news server into a single view of the
froups sounds like work, and reading everything in triplicate sounds
like work. I also have *no* idea if I could get something like that
working on my pad, as opposed to on a normal computer, particularly
without jailbreaking it, the mere thought of which gives me the
heebie-jeebies. I've heard horror stories about Apple updates crippling
jailbroken devices that receive them. And I can't very well disconnect
it from the 'net and still use it to post news...

--
"To explain the unknown by the known is a logical procedure; to explain
the known by the unknown is a form of theological lunacy." ~David Brooks

glen herrmannsfeldt wrote:
> In comp.lang.java.programmer Nadegda <> wrote:
> (snip, someone wrote)
>
>>>Wow, even the name is pointlessly abbreviated to be missing one vowel.
>>>Does it date back to when machines had a few KB of core and even one
>>>byte of extra computer code could be a storage problem?
>
>>Of course not. Not that that would have been an excuse even so. The old
>>Commodore VIC-20 had a BASIC interpreter and that language had full,
>>readable keywords like PRINT rather than abbreviated garbage like, say,
>>PRN. Commodore employed a clever trick: BASIC programs were stored (on
>>disk and in memory) *compressed*, with all of the common keywords
>>replaced with graphics characters with the high bit set.
>
> The HP TSB2000 (Time Shared BASIC) systems did that, too.
>
> Not only that, it would refuse to allow you to enter a statement
> that didn't pass some syntax checks.
>
> Many of the microcomputer BASIC interpreters were based on
> the ones from Microsoft, but even if not, the tokenizing compression
> was well known by then.
>
> Not only does it save memory, but the interpreter runs a lot faster!
> The tokenizing is done only once, not each time the statement
> is executed.
>

You can make BASIC programs run lots faster if you delete comments and
replace the GOSUBes with GOTOes

--
Grizzly H.