[TUHS] Happy birthday, Niklaus Wirth!

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

Computer pioneer Niklaus Wirth was born on this day in 1934; he basically 
designed ALGOL, one of the most influential languages ever, with just 
about every programming language in use today tracing its roots to it.

His name is pronounced "vurt" but he would accept "worth", and he joked 
that you could call him by name or by value (you need to know ALGOL to 
understand).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Niklaus Wirth!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

On Wed, Feb 14, 2018 at 4:06 PM, Dave Horsfall <dave at horsfall.org> wrote:

>
> His name is pronounced "vurt" but he would accept "worth", and he joked
> that you could call him by name or by value (you need to know ALGOL to
> understand).

​The actual joke was Europeans called him by name(ni-klaus vurt) and
Americans by value [nickel-less worth].​
ᐧ
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180214/53abe962/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[George Michaelson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

the joke was extended on my Uni course to include "call by reference" but I
forget what it was. probably "hey! YOU"

-G

On Thu, Feb 15, 2018 at 7:12 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Wed, Feb 14, 2018 at 4:06 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
>>
>> His name is pronounced "vurt" but he would accept "worth", and he joked
>> that you could call him by name or by value (you need to know ALGOL to
>> understand).
>
> ​The actual joke was Europeans called him by name(ni-klaus vurt) and
> Americans by value [nickel-less worth].​
> ᐧ
> ᐧ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/0a67246c/attachment-0001.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

On Wed, 14 Feb 2018, Clem Cole wrote:

> The actual joke was Europeans called him by name(ni-klaus vurt) and 
> Americans by value [nickel-less worth].​

Thanks; noted in my list.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Niklaus Wirth!

[Toby Thain]

On 2018-02-14 4:06 PM, Dave Horsfall wrote:
> ALGOL, one of the most influential languages ever, with just about every
> programming language in use today tracing its roots to it.

Worth mentioning one significant exception: the Lisp family.

--T

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

On Wed, 14 Feb 2018, Toby Thain wrote:

>> ALGOL, one of the most influential languages ever, with just about 
>> every programming language in use today tracing its roots to it.
>
> Worth mentioning one significant exception: the Lisp family.

I know about LISP (and even used it); it's on my history list.

Actually, I can't think of any language that derived exclusively from LISP 
(other than Scheme etc)...  Oh, and EMACS :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Niklaus Wirth!

[Dan Cross]

On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 14 Feb 2018, Toby Thain wrote:
>
>> ALGOL, one of the most influential languages ever, with just about every
>>> programming language in use today tracing its roots to it.
>>>
>>
>> Worth mentioning one significant exception: the Lisp family.
>>
>
> I know about LISP (and even used it); it's on my history list.
>
> Actually, I can't think of any language that derived exclusively from LISP
> (other than Scheme etc)...  Oh, and EMACS :-)
>

There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and
Scheme might be the best known, with Clojure a modern entrant. Arc is sort
of a thing. Most folks know about emacs Lisp. All of these derive from the
original Lisp.

But there were a whole slew of historical dialects descended from Lisp 1.5:
MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant
implemented by Symbolics before they adopted Common Lisp, Portable Standard
Lisp...and any number of others that were implemented as extension
languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the
pseudo-Lisp from Gosling's Emacs, and plenty of others. And how about
implementations? VAX Lisp, LispWorks, Allegro, etc. I think the thing is
that "Lisp" isn't a single language, but rather a family of languages that
all share common features (code is data, macros, etc, etc, etc) with lots
of variation between them (I understand that there was serious argument
about whether integer literals should be written in octal in Common Lisp,
as they were in MacLisp. Somehow common sense prevailed).

So, how's this relevant to Unix? Well, I'd like to know more about the
historical interplay between the Unix and Lisp communities. What about the
Lisp done at Berkeley on the VAX (Franz Lisp).

One of the things that strikes me about Lisp and Unix is the conceptual
similarity between image based languages (like Lisp) with a REPL and the
Unix "process as virtual machine" model with a shell and set of utilities.
An image is a sort of virtual machine and a REPL is a sort of shell;
callable functions in the REPL are sort of like discrete programs in the
$PATH. To a first order approximation, at any rate.

So anyway...some of you who were there, was there cross-pollination? Was
Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
Lisp people who just happened to be using Unix because VAXen were expensive?

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/c5e5d828/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Clem cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3267 bytes --]

The whole reason VM was developed at UCB was because Ernie (the original) Vax was funded to develop the ability to port MacLisp and more importantly Macsyma from ITS.  
V32’s static address space was not going to work. 


Btw the program we used to debug the VM system on the original mc500 was macsyma’s competition, sms (which would later become wolfram).

In both cases the idea was to ensure the memory system was being exercised. 

Clem


Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Feb 15, 2018, at 7:51 PM, Dan Cross <crossd at gmail.com> wrote:
> 
>> On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall <dave at horsfall.org> wrote:
>> On Wed, 14 Feb 2018, Toby Thain wrote:
>>>> ALGOL, one of the most influential languages ever, with just about every programming language in use today tracing its roots to it.
>>> 
>>> Worth mentioning one significant exception: the Lisp family.
>> 
>> I know about LISP (and even used it); it's on my history list.
>> 
>> Actually, I can't think of any language that derived exclusively from LISP (other than Scheme etc)...  Oh, and EMACS :-)
> 
> There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and Scheme might be the best known, with Clojure a modern entrant. Arc is sort of a thing. Most folks know about emacs Lisp. All of these derive from the original Lisp.
> 
> But there were a whole slew of historical dialects descended from Lisp 1.5: MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant implemented by Symbolics before they adopted Common Lisp, Portable Standard Lisp...and any number of others that were implemented as extension languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the pseudo-Lisp from Gosling's Emacs, and plenty of others. And how about implementations? VAX Lisp, LispWorks, Allegro, etc. I think the thing is that "Lisp" isn't a single language, but rather a family of languages that all share common features (code is data, macros, etc, etc, etc) with lots of variation between them (I understand that there was serious argument about whether integer literals should be written in octal in Common Lisp, as they were in MacLisp. Somehow common sense prevailed).
> 
> So, how's this relevant to Unix? Well, I'd like to know more about the historical interplay between the Unix and Lisp communities. What about the Lisp done at Berkeley on the VAX (Franz Lisp).
> 
> One of the things that strikes me about Lisp and Unix is the conceptual similarity between image based languages (like Lisp) with a REPL and the Unix "process as virtual machine" model with a shell and set of utilities. An image is a sort of virtual machine and a REPL is a sort of shell; callable functions in the REPL are sort of like discrete programs in the $PATH. To a first order approximation, at any rate.
> 
> So anyway...some of you who were there, was there cross-pollination? Was Franz Lisp a thing Unix people at Berkeley played with, or was it mostly Lisp people who just happened to be using Unix because VAXen were expensive?
> 
>         - Dan C.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/00914085/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Toby Thain]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1448 bytes --]

On 2018-02-15 8:06 PM, Clem cole wrote:
> The whole reason VM was developed at UCB was because Ernie (the
> original) Vax was funded to develop the ability to port MacLisp and more
> importantly Macsyma from ITS.  
> V32’s static address space was not going to work. 
> 
> 
> Btw the program we used to debug the VM system on the original mc500 was
> macsyma’s competition, sms (which would later become wolfram).
> 

You probably meant "SMP", built by Wolfram and others at Caltech:
http://www.stephenwolfram.com/publications/smp-symbolic-manipulation-program/

It sounds like Mathematica probably did not _directly_ derive from SMP
due to a court ruling.

  "A dispute with the administration over the intellectual property
rights regarding SMP—patents, copyright, and faculty involvement in
commercial ventures—eventually caused him to resign from Caltech.
SMP was further developed and marketed commercially by Inference Corp.
of Los Angeles during 1983–1988."

Curiously, the above text has been copied and pasted verbatim all
over the web and it's not clear where it originated. "SMP was
essentially Version Zero of the more ambitious Mathematica system" is
also all over the web including Wikipedia.



> In both cases the idea was to ensure the memory system was being exercised. 

Nowadays we'd just run gcc :)

--Toby


> 
> Clem
> 
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not
> quite. 
> ...

[TUHS] Happy birthday, Niklaus Wirth!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On Thu, Feb 15, 2018 at 10:10 PM, Toby Thain <toby at telegraphics.com.au>
wrote:

> On 2018-02-15 8:06 PM, Clem cole wrote:
> > The whole reason VM was developed at UCB was because Ernie (the
> > original) Vax was funded to develop the ability to port MacLisp and more
> > importantly Macsyma from ITS.
> > V32’s static address space was not going to work.
> >
> >
> > Btw the program we used to debug the VM system on the original mc500 was
> > macsyma’s competition, sms (which would later become wolfram).
> >
>
> You probably meant "SMP",

​yes thank you... typo/dyslexia (I did not notice the error until you
pointed it out).


> > In both cases the idea was to ensure the memory system was being
> exercised.
>
> Nowadays we'd just run gcc :)
>
​indeed

​
- as for wolfram vs SMP sorry not trying to dig into old wounds, just
trying to point out how ironic that two early UNIX VM systems used the same
style of application (symbolic math) as a way to find corner cases in the
VM code.


​
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/3de29b8f/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Larry McVoy]

On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote:
> >> Worth mentioning one significant exception: the Lisp family.
> 
> So anyway...some of you who were there, was there cross-pollination? Was
> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
> Lisp people who just happened to be using Unix because VAXen were expensive?

This is just my opinion so there is a grain of salt.  Or a salt shaker.

I think there are two (at least) sorts of programmers, the systems people
and the lisp people.  Sometimes you get both kinds in the same person
but that tends to be rare (and awesome, I've employeed several of those,
they were magic).

I'm a systems guy.  I've played with lisp, even wrote a tiny lisp (haven't
we all?), tried to get to like it and utterly failed.  All sorts of smart
people I knew in my career loved lisp, sneered at any other language,
tended to think in ASTs, etc, etc.  I definitely felt inferior and tried
to like lisp but just never got what was so neat about it.

For good reason, I think.  Nobody has written a serious operating system,
or a serious $BIG_PROJECT in Lisp.  Not one that has been commercially
successful, so far as I know.  I know there were attempts but all those
attempts failed.  Why?  Performance I think.  C performs far better even
though it is, in the eyes of lisp people, far more awkward to do things.

I can't tell you the number of times I've heard "If we were using Lisp
we'd be done by now".  100's, 1000's.  What I have never heard is "I
recoded this pile of C in lisp and it's 10x faster".

I think the thing is that lisp programmers were optimizing for speed
of coding and C programmers were optimizing for speed of execution.

So I suspect that Franz Lisp was mostly lisp people who happened to be
using Unix.  But I wasn't at Berkeley so what do I know?

--lm

[TUHS] Happy birthday, Niklaus Wirth!

[George Michaelson]

syntactically, semantically, a lot of the strongly typed functional
programming outcomes have roots into ideas explored in the LISP
family.

the quants are using it heavily. The declarative, checked-at-compile
qualities reduce errors, the statements have some authority and the
formulaic expression of things as compositions over functions works
for their brains. the typing wasn't strong in LISP but the FP
expressive quality and lazy eval was. Sure, it was in Algol family
languages too, but I think it got sort-of left out when C hit the
road.

I struggle with FP. I have major envy of minds which can think like
that.  I wish I had that kind of mind. I sit with someone who does. He
front loads his problems with type statements and produces terse but
very efficient code. Its a marketable skill in the right place.

I think you're right its not very system-y but the lines are blurring.
Go introduces the need for GC. Once you need GC, you enter a door
where all the things we said we didn't do pop back into view,
including lazy evaluation which is in the foundation of FP, and ..
LISP. So for the set of problems which people say "coded in GO" you
can think "hmm: maybe GHC with the right frobs would work there"

Rust apparently doesn't do GC. So maybe its more in the 'not in my
world' camp. Syntactically Go is of course nothing LIKE an FP as I
understand it, but then I can't program functionally, so I don't
entirely know what I know any more here.

On Fri, Feb 16, 2018 at 11:18 AM, Larry McVoy <lm at mcvoy.com> wrote:
> On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote:
>> >> Worth mentioning one significant exception: the Lisp family.
>>
>> So anyway...some of you who were there, was there cross-pollination? Was
>> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
>> Lisp people who just happened to be using Unix because VAXen were expensive?
>
> This is just my opinion so there is a grain of salt.  Or a salt shaker.
>
> I think there are two (at least) sorts of programmers, the systems people
> and the lisp people.  Sometimes you get both kinds in the same person
> but that tends to be rare (and awesome, I've employeed several of those,
> they were magic).
>
> I'm a systems guy.  I've played with lisp, even wrote a tiny lisp (haven't
> we all?), tried to get to like it and utterly failed.  All sorts of smart
> people I knew in my career loved lisp, sneered at any other language,
> tended to think in ASTs, etc, etc.  I definitely felt inferior and tried
> to like lisp but just never got what was so neat about it.
>
> For good reason, I think.  Nobody has written a serious operating system,
> or a serious $BIG_PROJECT in Lisp.  Not one that has been commercially
> successful, so far as I know.  I know there were attempts but all those
> attempts failed.  Why?  Performance I think.  C performs far better even
> though it is, in the eyes of lisp people, far more awkward to do things.
>
> I can't tell you the number of times I've heard "If we were using Lisp
> we'd be done by now".  100's, 1000's.  What I have never heard is "I
> recoded this pile of C in lisp and it's 10x faster".
>
> I think the thing is that lisp programmers were optimizing for speed
> of coding and C programmers were optimizing for speed of execution.
>
> So I suspect that Franz Lisp was mostly lisp people who happened to be
> using Unix.  But I wasn't at Berkeley so what do I know?
>
> --lm

[TUHS] Happy birthday, Niklaus Wirth!

[Lawrence Stewart]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3429 bytes --]

ITA’s airline flight booking system, that was used by Orbitz and others was pretty much entirely written in Common LISP, and it was certainly both large and commercially successful.  Orbitz was bought by Google for $700 million.  I don’t know how much of the LISP survived sustained attention by Google.

Paul Graham’s company Viaweb was all LISP.  It was bought by Yahoo! for $50 million and became Yahoo! Store.

I think of myself as a systems person and C is still my primary language, but I wrote the routing software for the wacky Kautz graph in the Sicortex machines in Common LISP. It was substantially easier!  After it worked I recoded in C for production.  It isn’t that Common LISP isn’t perfectly fast enough, we just didn’t want garbage collection at that level of the software.

My favorite LISP story is the time I was hired to evaluate a proposed Cryptosystem.  I was handed 40 pages of C code.  I reimplemented it in 15 (short) lines of Common LISP.  It wasn’t hard to crack after it fit on one page!

I came to LISP 30 years late because I was in 6-1 at MIT rather than 6-3 so I didn’t learn LISP or Scheme.  I am not one of the awesome folks of which you speak, but I’ve met them and know what you mean.  One MIT physicist I met thought MILC was too complicated so his quantum chromodynamics code was in LISP.  He wrote his own LISP->C translator to get it to generate exactly the code he wanted.

-L

> On 2018, Feb 15, at 8:18 PM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote:
>>>> Worth mentioning one significant exception: the Lisp family.
>> 
>> So anyway...some of you who were there, was there cross-pollination? Was
>> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
>> Lisp people who just happened to be using Unix because VAXen were expensive?
> 
> This is just my opinion so there is a grain of salt.  Or a salt shaker.
> 
> I think there are two (at least) sorts of programmers, the systems people
> and the lisp people.  Sometimes you get both kinds in the same person
> but that tends to be rare (and awesome, I've employeed several of those,
> they were magic).
> 
> I'm a systems guy.  I've played with lisp, even wrote a tiny lisp (haven't
> we all?), tried to get to like it and utterly failed.  All sorts of smart
> people I knew in my career loved lisp, sneered at any other language,
> tended to think in ASTs, etc, etc.  I definitely felt inferior and tried
> to like lisp but just never got what was so neat about it.
> 
> For good reason, I think.  Nobody has written a serious operating system,
> or a serious $BIG_PROJECT in Lisp.  Not one that has been commercially
> successful, so far as I know.  I know there were attempts but all those
> attempts failed.  Why?  Performance I think.  C performs far better even
> though it is, in the eyes of lisp people, far more awkward to do things.
> 
> I can't tell you the number of times I've heard "If we were using Lisp
> we'd be done by now".  100's, 1000's.  What I have never heard is "I
> recoded this pile of C in lisp and it's 10x faster".
> 
> I think the thing is that lisp programmers were optimizing for speed
> of coding and C programmers were optimizing for speed of execution.
> 
> So I suspect that Franz Lisp was mostly lisp people who happened to be
> using Unix.  But I wasn't at Berkeley so what do I know?
> 
> --lm

[TUHS] Happy birthday, Niklaus Wirth!

[Dan Cross]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4287 bytes --]

On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
wrote:

> ITA’s airline flight booking system, that was used by Orbitz and others
> was pretty much entirely written in Common LISP, and it was certainly both
> large and commercially successful.  Orbitz was bought by Google for $700
> million.  I don’t know how much of the LISP survived sustained attention by
> Google.
>

Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common
Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the
expectation of that sort of elegance, you end up pretty unhappy pretty
quick. They do a lot of things very differently to squeeze as much
performance as they can out of what has, historically speaking, been a
fairly mediocre compiler.

        - Dan C.

Paul Graham’s company Viaweb was all LISP.  It was bought by Yahoo! for $50
> million and became Yahoo! Store.
>
> I think of myself as a systems person and C is still my primary language,
> but I wrote the routing software for the wacky Kautz graph in the Sicortex
> machines in Common LISP. It was substantially easier!  After it worked I
> recoded in C for production.  It isn’t that Common LISP isn’t perfectly
> fast enough, we just didn’t want garbage collection at that level of the
> software.
>
> My favorite LISP story is the time I was hired to evaluate a proposed
> Cryptosystem.  I was handed 40 pages of C code.  I reimplemented it in 15
> (short) lines of Common LISP.  It wasn’t hard to crack after it fit on one
> page!
>
> I came to LISP 30 years late because I was in 6-1 at MIT rather than 6-3
> so I didn’t learn LISP or Scheme.  I am not one of the awesome folks of
> which you speak, but I’ve met them and know what you mean.  One MIT
> physicist I met thought MILC was too complicated so his quantum
> chromodynamics code was in LISP.  He wrote his own LISP->C translator to
> get it to generate exactly the code he wanted.
>
> -L
>
> > On 2018, Feb 15, at 8:18 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > On Thu, Feb 15, 2018 at 07:51:14PM -0500, Dan Cross wrote:
> >>>> Worth mentioning one significant exception: the Lisp family.
> >>
> >> So anyway...some of you who were there, was there cross-pollination? Was
> >> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
> >> Lisp people who just happened to be using Unix because VAXen were
> expensive?
> >
> > This is just my opinion so there is a grain of salt.  Or a salt shaker.
> >
> > I think there are two (at least) sorts of programmers, the systems people
> > and the lisp people.  Sometimes you get both kinds in the same person
> > but that tends to be rare (and awesome, I've employeed several of those,
> > they were magic).
> >
> > I'm a systems guy.  I've played with lisp, even wrote a tiny lisp
> (haven't
> > we all?), tried to get to like it and utterly failed.  All sorts of smart
> > people I knew in my career loved lisp, sneered at any other language,
> > tended to think in ASTs, etc, etc.  I definitely felt inferior and tried
> > to like lisp but just never got what was so neat about it.
> >
> > For good reason, I think.  Nobody has written a serious operating system,
> > or a serious $BIG_PROJECT in Lisp.  Not one that has been commercially
> > successful, so far as I know.  I know there were attempts but all those
> > attempts failed.  Why?  Performance I think.  C performs far better even
> > though it is, in the eyes of lisp people, far more awkward to do things.
> >
> > I can't tell you the number of times I've heard "If we were using Lisp
> > we'd be done by now".  100's, 1000's.  What I have never heard is "I
> > recoded this pile of C in lisp and it's 10x faster".
> >
> > I think the thing is that lisp programmers were optimizing for speed
> > of coding and C programmers were optimizing for speed of execution.
> >
> > So I suspect that Franz Lisp was mostly lisp people who happened to be
> > using Unix.  But I wasn't at Berkeley so what do I know?
> >
> > --lm
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/987cb5b1/attachment-0001.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Larry McVoy]

On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
> On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
> wrote:
> 
> > ITA???s airline flight booking system, that was used by Orbitz and others
> > was pretty much entirely written in Common LISP, and it was certainly both
> > large and commercially successful.  Orbitz was bought by Google for $700
> > million.  I don???t know how much of the LISP survived sustained attention by
> > Google.
> >
> 
> Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common
> Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
> bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the
> expectation of that sort of elegance, you end up pretty unhappy pretty
> quick. They do a lot of things very differently to squeeze as much
> performance as they can out of what has, historically speaking, been a
> fairly mediocre compiler.

Which is sort of my point.  I don't know all the details but lisp and 
performance is not a thing.  

[TUHS] Happy birthday, Niklaus Wirth!

[Dan Cross]

On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
> > On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
> > wrote:
> >
> > > ITA???s airline flight booking system, that was used by Orbitz and
> others
> > > was pretty much entirely written in Common LISP, and it was certainly
> both
> > > large and commercially successful.  Orbitz was bought by Google for
> $700
> > > million.  I don???t know how much of the LISP survived sustained
> attention by
> > > Google.
> > >
> >
> > Google bought ITA, not Orbitz. Most of the logic in QPX is still in
> Common
> > Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
> > bunch of Paul Graham and Peter Norvig books and then gets onto QPX with
> the
> > expectation of that sort of elegance, you end up pretty unhappy pretty
> > quick. They do a lot of things very differently to squeeze as much
> > performance as they can out of what has, historically speaking, been a
> > fairly mediocre compiler.
>
> Which is sort of my point.  I don't know all the details but lisp and
> performance is not a thing.
>

That's a tad unfair.

It *can* be fast, it's just that the "Lisp" you're writing in that case
probably isn't the Lisp you wanted to be writing when you read about how
cool and elegant Lisp was: you're avoiding some constructs to prevent
boxing and unboxing arguments (e.g., put things inside of labels or flet's
instead of defun's or passing arbitrary lambdas around) or generating
useless garbage (don't cons up a list; setq the cdr) and favoring others
that are less elegant to get better object code out of the compiler.

If you can stomach the death-defying twists and turns from all the hoops
you have to jump through for all of that nonsense, then you can make it
fast -- but at the loss of the expressive advantage. But that trade-off
begs the question: why not write in a language that lets you write fast
(executing) code without jumping through hoops? That's a fair thing to ask
and most of the answers in Lisp's favor aren't particularly great.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/7b1768ab/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[George Michaelson]

I tried to hire an engineer in the 1990s. She came to the interview
with her (probably over-controlling) father who was the founder of the
two person consulting company she'd been working for. They coded a
huge traffic-light management system entirely in LISP. Major stuff.

From memory, we offered but I think daddy didn't like the way we
behaved, she didn't accept. I think she was an incredibly good
programmer. Really smart, competent. It was my first clue that out in
the "real world" (I was working in a university) you could code in
LISP and sell solutions that ran things like traffic lights: People
die if you get that wrong. Awesome. (it's equally likely we didn't
offer, being stupid)

On Fri, Feb 16, 2018 at 12:51 PM, Dan Cross <crossd at gmail.com> wrote:
> On Thu, Feb 15, 2018 at 9:41 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>
>> On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
>> > On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
>> > wrote:
>> >
>> > > ITA???s airline flight booking system, that was used by Orbitz and
>> > > others
>> > > was pretty much entirely written in Common LISP, and it was certainly
>> > > both
>> > > large and commercially successful.  Orbitz was bought by Google for
>> > > $700
>> > > million.  I don???t know how much of the LISP survived sustained
>> > > attention by
>> > > Google.
>> > >
>> >
>> > Google bought ITA, not Orbitz. Most of the logic in QPX is still in
>> > Common
>> > Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
>> > bunch of Paul Graham and Peter Norvig books and then gets onto QPX with
>> > the
>> > expectation of that sort of elegance, you end up pretty unhappy pretty
>> > quick. They do a lot of things very differently to squeeze as much
>> > performance as they can out of what has, historically speaking, been a
>> > fairly mediocre compiler.
>>
>> Which is sort of my point.  I don't know all the details but lisp and
>> performance is not a thing.
>
>
> That's a tad unfair.
>
> It *can* be fast, it's just that the "Lisp" you're writing in that case
> probably isn't the Lisp you wanted to be writing when you read about how
> cool and elegant Lisp was: you're avoiding some constructs to prevent boxing
> and unboxing arguments (e.g., put things inside of labels or flet's instead
> of defun's or passing arbitrary lambdas around) or generating useless
> garbage (don't cons up a list; setq the cdr) and favoring others that are
> less elegant to get better object code out of the compiler.
>
> If you can stomach the death-defying twists and turns from all the hoops you
> have to jump through for all of that nonsense, then you can make it fast --
> but at the loss of the expressive advantage. But that trade-off begs the
> question: why not write in a language that lets you write fast (executing)
> code without jumping through hoops? That's a fair thing to ask and most of
> the answers in Lisp's favor aren't particularly great.
>
>         - Dan C.
>

[TUHS] Clueless programmers - was Re: Happy birthday, Niklaus Wirth!

[Toby Thain]

On 2018-02-15 9:41 PM, Larry McVoy wrote:
> On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
>> On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
>> wrote:
>>
>>> ITA???s airline flight booking system, that was used by Orbitz and others
>>> was pretty much entirely written in Common LISP, and it was certainly both
>>> large and commercially successful.  Orbitz was bought by Google for $700
>>> million.  I don???t know how much of the LISP survived sustained attention by
>>> Google.
>>>
>>
>> Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common
>> Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
>> bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the
>> expectation of that sort of elegance, you end up pretty unhappy pretty
>> quick. They do a lot of things very differently to squeeze as much
>> performance as they can out of what has, historically speaking, been a
>> fairly mediocre compiler.
> 
> Which is sort of my point.  I don't know all the details but lisp and 
> performance is not a thing.  
> 

You can stop at "I don't know all the details". That meme about
performance is not actually true, but it's popular among people who
don't know Lisp technically or use it professionally.

There are a number of mature Common Lisp compilers and some of them
boast outstanding performance.

--T

[TUHS] Clueless programmers - was Re: Happy birthday, Niklaus Wirth!

[Larry McVoy]

On Thu, Feb 15, 2018 at 09:51:21PM -0500, Toby Thain wrote:
> On 2018-02-15 9:41 PM, Larry McVoy wrote:
> > On Thu, Feb 15, 2018 at 09:38:02PM -0500, Dan Cross wrote:
> >> On Thu, Feb 15, 2018 at 8:56 PM, Lawrence Stewart <stewart at serissa.com>
> >> wrote:
> >>
> >>> ITA???s airline flight booking system, that was used by Orbitz and others
> >>> was pretty much entirely written in Common LISP, and it was certainly both
> >>> large and commercially successful.  Orbitz was bought by Google for $700
> >>> million.  I don???t know how much of the LISP survived sustained attention by
> >>> Google.
> >>>
> >>
> >> Google bought ITA, not Orbitz. Most of the logic in QPX is still in Common
> >> Lisp, but it's not what you'd call "idiomatic" CL code. If one reads a
> >> bunch of Paul Graham and Peter Norvig books and then gets onto QPX with the
> >> expectation of that sort of elegance, you end up pretty unhappy pretty
> >> quick. They do a lot of things very differently to squeeze as much
> >> performance as they can out of what has, historically speaking, been a
> >> fairly mediocre compiler.
> > 
> > Which is sort of my point.  I don't know all the details but lisp and 
> > performance is not a thing.  
> > 
> 
> You can stop at "I don't know all the details". That meme about
> performance is not actually true, but it's popular among people who
> don't know Lisp technically or use it professionally.
> 
> There are a number of mature Common Lisp compilers and some of them
> boast outstanding performance.

I'm fine with your claim but I'd like to see a pile of C code that was
rewritten in lisp and it is faster.  I'm 99.9% sure that's not a thing.

Lisp is fantastic for programmers who know how to use it, which is why 
so many people are lisp fanatics.  But performant it is not.  Feel free
to show me how I'm wrong, I love being wrong, that's where I learn.

--lm

[TUHS] Happy birthday, Niklaus Wirth!

[Tim Bradshaw]

On 16 Feb 2018, at 02:41, Larry McVoy <lm at mcvoy.com> wrote:
> 
> I don't know all the details but lisp and 
> performance is not a thing.  


What this actually means is three things.

(1) Once upon a time, a very long time ago, there may have been some implementations of Lisp-family languages which, because people didn't know much about writing compilers or memory management systems in the early 1960s, were significantly slow compared to hand-written assembler or FORTRAN. This problem got solved in the 1970s and 1980s as people learnt about compiling high-level languages and about how to manage memory efficiently.

(2) The most distinctive (but never the only) compound data structure in Lisp-family languages is the singly-linked list (which Lisp calls just 'lists').  Incompetent or poorly-taught programmers make use of lists without understanding their performance characteristics (particularly they treat them like arrays), and this can result in programs which have terrible performance characteristics: they're slow and they scale poorly.  This is made worse because Lisp is an enormously safer language than, say, C. This means that incompetent programmers can make their programs work *at all* which, in C, would be a mass of memory errors.

(3) People use Lisp-family languages to solve hard problems, such as 'attempt to show that this metric in GR describes the same spacetime as this other metric'.  Problems which don't *have* general solutions and whose heuristic solutions involve enormous amounts of computation, much of it speculative as the program searches for ways of simplifying expressions.  These programs are 'slow' in the sense that it takes them many minutes to do what a human can spend three years getting a PhD doing (oh, and the program finds that the human made some mistakes).

The end result of this is that a myth grows up: 'Lisp is slow'.  This might have been true once, although even that is doubtful: like cannibals, it turns out that the implementation you can find was never, really, slow, but always, just across the river, over the hills, there was another implementation, which was.

But still the myth persists: it will always persist.

--tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/be85fd2c/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Ian Zimmerman]

On 2018-02-15 19:51, Dan Cross wrote:

> So, how's this relevant to Unix? Well, I'd like to know more about the
> historical interplay between the Unix and Lisp communities. What about
> the Lisp done at Berkeley on the VAX (Franz Lisp).

I know one of the Franz founders, I'll ask him when I have a chance.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[TUHS] Happy birthday, Niklaus Wirth!

[Ian Zimmerman]

On 2018-02-15 17:25, Ian Zimmerman wrote:

> I know one of the Franz founders, I'll ask him when I have a chance.

So, the main link seems to be John Foderaro, who worked on both BSD and Franz.

According to my source, he wrote biff(1).

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

On Mon, 23 Apr 2018, Ian Zimmerman wrote:

> According to my source, he wrote biff(1).

http://en.wikipedia.org/wiki/BIFF

(I'd post the whole thing, but Warren would probably have my nuts.)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Niklaus Wirth!

[Dan Stromberg]

On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman <itz at very.loosely.org> wrote:
> On 2018-02-15 17:25, Ian Zimmerman wrote:
>
>> I know one of the Franz founders, I'll ask him when I have a chance.
>
> So, the main link seems to be John Foderaro, who worked on both BSD and Franz.
>
> According to my source, he wrote biff(1).

I had been of the impression that biff(1) was named after a dog that
barked at the slightest provocation...

[TUHS] Happy birthday, Niklaus Wirth!

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]

On Tue, Apr 24, 2018 at 12:31 AM, Dan Stromberg <drsalists at gmail.com> wrote:

> On Mon, Apr 23, 2018 at 5:59 PM, Ian Zimmerman <itz at very.loosely.org>
> wrote:
> > On 2018-02-15 17:25, Ian Zimmerman wrote:
> >
> >> I know one of the Franz founders, I'll ask him when I have a chance.
> >
> > So, the main link seems to be John Foderaro, who worked on both BSD and
> Franz.
> >
> > According to my source, he wrote biff(1).
>
> I had been of the impression that biff(1) was named after a dog

​Indeed - Biff was Heidi's dog.​



> that
> ​ ​
> barked at the slightest provocation...
>
​Hmm, I'm not sure that is fair.  Biff just warned Heidi that someone had
entered their office​.

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180424/4fa835b3/attachment-0001.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Bakul Shah]

On Thu, 15 Feb 2018 19:51:14 -0500 Dan Cross <crossd at gmail.com> wrote:
Dan Cross writes:
> 
> On Thu, Feb 15, 2018 at 7:01 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> > On Wed, 14 Feb 2018, Toby Thain wrote:
> >
> >> ALGOL, one of the most influential languages ever, with just about every
> >>> programming language in use today tracing its roots to it.
> >>>
> >>
> >> Worth mentioning one significant exception: the Lisp family.
> >>
> >
> > I know about LISP (and even used it); it's on my history list.
> >
> > Actually, I can't think of any language that derived exclusively from LISP
> > (other than Scheme etc)...  Oh, and EMACS :-)
> >
> 
> There were (and are!) a whole bunch of dialects of Lisp: Common Lisp and
> Scheme might be the best known, with Clojure a modern entrant. Arc is sort
> of a thing. Most folks know about emacs Lisp. All of these derive from the
> original Lisp.

Scheme's lexical scope and block structure came from Algol.
The rest from Lisp. The joke was that the shortest and longest
language specs were of lisp dialects. The C++ spec may be
longer now.

> But there were a whole slew of historical dialects descended from Lisp 1.5:
> MacLisp, InterLisp, FranzLisp, Lisp Machine Lisp, the original variant
> implemented by Symbolics before they adopted Common Lisp, Portable Standard
> Lisp...and any number of others that were implemented as extension
> languages: AutoLisp from AutoCAD, the aforementioned Emacs Lisp, the

IIRC AutoLISP came from David Betz' Xlisp. Before it became a
superset of Scheme.

> So, how's this relevant to Unix? Well, I'd like to know more about the
> historical interplay between the Unix and Lisp communities. What about the
> Lisp done at Berkeley on the VAX (Franz Lisp).
> 
> One of the things that strikes me about Lisp and Unix is the conceptual
> similarity between image based languages (like Lisp) with a REPL and the
> Unix "process as virtual machine" model with a shell and set of utilities.
> An image is a sort of virtual machine and a REPL is a sort of shell;
> callable functions in the REPL are sort of like discrete programs in the
> $PATH. To a first order approximation, at any rate.

They feel very different to me.  Lisp was/is a closed world
& its FFI (foreign func. interface) always seemed like an
afterthought.  In a shell you can string together programs
written in any language so long as they input/output text
lines. Its pipe symbol allowed infix notation for function
composition.  As a programming language I prefer Scheme over
almost everything else but have to admit that most of my
oneliner scripts are in sh and I mostly program in Go these
days.

[TUHS] Happy birthday, Niklaus Wirth!

[Toby Thain]

On 2018-02-15 9:09 PM, Bakul Shah wrote:
> Scheme's lexical scope and block structure came from Algol.

I'd have said lambda calculus

but OK

[TUHS] Happy birthday, Niklaus Wirth!

[Tim Bradshaw]

On 16 Feb 2018, at 02:09, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> Scheme's lexical scope and block structure came from Algol.
> The rest from Lisp. The joke was that the shortest and longest
> language specs were of lisp dialects. The C++ spec may be
> longer now.

I don't think this is true in any meaningful sense.  There are famous plays on words which relate Scheme to Algol (The Scheme specifications are 'revised^n reports on the algorithmic language scheme', and I think lexical scope in Lisps probably originated with the Scheme people, but Scheme was the first standard language, anywhere, which took lexical scope seriously: in particular it was the first standard language with first-class continuations. (I'm saying 'standard language' because I'm sure there were research prototype implementations.).

The Common Lisp spec was very long at the time -- I think it was 1100 pages.  It was mostly as long as it was because they decided not to split out what other languages would call parts of the standard library.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/5f246f0a/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Bakul Shah]

On Fri, 16 Feb 2018 10:01:36 +0000 Tim Bradshaw <tfb at tfeb.org> wrote:
Tim Bradshaw writes:
> 
> On 16 Feb 2018, at 02:09, Bakul Shah <bakul at bitblocks.com> wrote:
> >=20
> > Scheme's lexical scope and block structure came from Algol.
> > The rest from Lisp. The joke was that the shortest and longest
> > language specs were of lisp dialects. The C++ spec may be
> > longer now.
> 
> I don't think this is true in any meaningful sense.  There are famous
> plays on words which relate Scheme to Algol (The Scheme specifications
> are 'revised^n reports on the algorithmic language scheme', and I think
> Scheme was the first standard language, anywhere, which took lexical
> scope seriously: in particular it was the first standard language with
> first-class continuations. (I'm saying 'standard language' because I'm
> sure there were research prototype implementations.).

On the second page of Sussman & Steele's "Scheme, an
Interpreter for Extended Lambda Calculus", AI Memo 349, it
says "The solution, which Hewitt also uses, is to adopt an
ALGOLesque block syntax". And it goes on to describe lexical
scoping. They even call it BLOCK! Algol is mentioned a number
of times. The discovery of correspondence between actor
semantics and lambda calculus was a happy coincidence.  From
wikipedia article on the history of Scheme:

  25 years later, in 1998, Sussman and Steele reflected that
  the minimalism of Scheme was not a conscious design goal,
  but rather the unintended outcome of the design process. "We
  were actually trying to build something complicated and
  discovered, serendipitously, that we had accidentally
  designed something that met all our goals but was much
  simpler than we had intended... we realized that the lambda
  calculus, a small, simple formalism, could serve as the core
  of a powerful and expressive programming language."

Now you may quibble about "came from" but I think the debt is
to Algol or at least Algol related papers. Even the connection
to lambda calculus is via Algol (Peter Landin's papers on
mechanical evaluation expressions (1964) and formal
description of Algol60 (1965)).

[TUHS] Happy birthday, Niklaus Wirth!

[tfb]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On 16 Feb 2018, at 12:10, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> Now you may quibble about "came from" 


I do so quibble.  In particular I quibble that features *that were not present in Algol*, such as full continuations (which I think exist in the AIM-349 language via CATCH) can have 'come from Algol'.  Full continuations are the place where Scheme actually takes lexical scope seriously.

But I'm not interested in getting into a fight about this.

(I think, in terms of modern Scheme, CATCH is:

(define-syntax catch
  (syntax-rules ()
    ((_ tag form ...)
     (call/cc (λ (tag) form ...)))))

although I might be wrong)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/44bcec77/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Bakul Shah]

On Fri, 16 Feb 2018 12:37:39 +0000 tfb at tfeb.org wrote:
tfb at tfeb.org writes:
> 
> On 16 Feb 2018, at 12:10, Bakul Shah <bakul at bitblocks.com> wrote:
> >=20
> > Now you may quibble about "came from"=20
> 
> I do so quibble.  In particular I quibble that features *that were not
> present in Algol*, such as full continuations (which I think exist in
> the AIM-349 language via CATCH) can have 'come from Algol'.  Full
> continuations are the place where Scheme actually takes lexical scope
> seriously.

They did lexical scoping "right", no doubt. But back when
Landin first found that lambda calculus was useful for
modeling programming languages these concepts were not clearly
understood.  I do not recall reading anything about whether
Algol designers not allowing full lexical scopin was due to an
oversight or realizing that efficient implementation of
functional argument was not possible. May be Algol's call by
name was deemed sufficient? At any rate Algol's not having
full lexical scoping does not mean one can simply reject the
idea of being influenced by it. Often at the start there is
lots of fumbling before people get it right. May be someone
should ask Steele?

And no, I do not think first class continuations automatically
follow from lexical scoping.  Go has lexical scoping including
closures but no call/cc.  The idea of representing future
program state as a function I think comes from Strachey,
Wadsworth and Reynolds. They used it extensively in
denotational semantics to model program behavior.

> But I'm not interested in getting into a fight about this.

We are just presenting our interpretation of history!  Not
that anybody cares!

[TUHS] Happy birthday, Niklaus Wirth!

[Bakul Shah]

On Fri, 16 Feb 2018 05:34:56 -0800 Bakul Shah <bakul at bitblocks.com> wrote:
Bakul Shah writes:
> closures but no call/cc.  The idea of representing future
> program state as a function I think comes from Strachey,

s/state/behavior/

[TUHS] Happy birthday, Niklaus Wirth!

[tfb]

On 16 Feb 2018, at 13:34, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> At any rate Algol's not having
> full lexical scoping does not mean one can simply reject the
> idea of being influenced by it. Often at the start there is
> lots of fumbling before people get it right. May be someone
> should ask Steele?

Yes, I certainly did not mean to imply that Scheme was not influenced by Algol: sorry if my message read that way.  What I was arguing against was that Scheme just somehow imported some concepts from Algol into Lisp: it *did* do that, but it also invented (or, at least, implemented in a practical, standardised language) a bunch of new concepts which were *not* present in Algol.

You are right of course that someone should ask Steele &co.

> And no, I do not think first class continuations automatically
> follow from lexical scoping.

I think they don't either, but I think that's because we've been talking about two things under one name: scope and extent.  What Scheme did was to say that it was going to be a language with lexical scope and indefinite extent, and it was going to take that seriously.  Most languages, even ones which purport to be lexically scoped, are usually both not entirely lexically scoped, and only take the indefinite extent thing seriously in sufficiently easy cases if they are.  An example of that is Common Lisp (I'm picking CL because CL is my favourite programming language which I've used for a very long time, so I think I'm allowed to be rude about it without causing offence).

CL has lexical scope and indefinite extent for variable and function bindings, so it has closures, for instance.  But it has dynamic scope and definite extent for condition handlers, for instance, as well as catch tags.  And finally it has lexical scope but definite extent for block names and go tags.

Scheme has lexical scope and indefinite extent for everything, and takes the attitude that if that makes it hard to implement then fine.  And I think that *that* was the new thing that Scheme did.  Whether the people designing Scheme knew that at the beginning (and whether their attitude was that rigorous from the beginning) I don't know.

(Of course, Scheme also made other Lisp people realise that lexical scope and mostly-indefinite-extent was a better approach than the older dynamic-scope-except-that-compiled-code-is-mostly-lexical horridness.  And I think all the Scheme implementations I've used have some mechanism of adding dynamic scope / definite extent for various things, because that's the obviously right scope for, say, condition handlers.)

I think this may be off-topic for this list, although I'm enjoying talking about it.

--tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/81591cbc/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Dan Stromberg]

On Thu, Feb 15, 2018 at 4:51 PM, Dan Cross <crossd at gmail.com> wrote:
> One of the things that strikes me about Lisp and Unix is the conceptual
> similarity between image based languages (like Lisp) with a REPL and the
> Unix "process as virtual machine" model with a shell and set of utilities.
> An image is a sort of virtual machine and a REPL is a sort of shell;
> callable functions in the REPL are sort of like discrete programs in the
> $PATH. To a first order approximation, at any rate.
>
> So anyway...some of you who were there, was there cross-pollination? Was
> Franz Lisp a thing Unix people at Berkeley played with, or was it mostly
> Lisp people who just happened to be using Unix because VAXen were expensive?

I definitely "wasn't there", but it's occurred to me before that
/bin/sh going through a file line by line, is similar to LISP going
through a list element by element.

When I took a "comparative languages" course, the professor said there
were two kinds of languages:
1) Languages that make you add convenience yourself to keep things
fast even though many people don't need the speed
2) Languages that make everyone pay (in performance) for conveniences
many developers will never need

So it's kind of the C vs. LISP thing from a (very) slightly different
perspective.

I still count C and bash among my favorites, but I mostly use Python
these days, and although I haven't done a ton in LISP, Python feels
kind of LISPy semantically - but not syntactically or lexically.  But
that's a happy accident: Python wasn't particularly influence by LISP.

On the other hand, with LISP focused on Linked Lists, and Python
focused on realloc()'d arrays, the similarly isn't especially deep.
But they're both "convenience at the expense of performance, even
though not everyone will need those conveniences".

And yes, there are exceptions.  As has already been mentioned, LISP
has some impressive compilers, and Python has things like Pypy and
Shedskin.

[TUHS] Happy birthday, Niklaus Wirth!

[Greg 'groggy' Lehey]

On Thursday, 15 February 2018 at  8:06:36 +1100, Dave Horsfall wrote:
> Computer pioneer Niklaus Wirth was born on this day in 1934; he basically
> designed ALGOL, one of the most influential languages ever, with just
> about every programming language in use today tracing its roots to it.
>
> His name is pronounced "vurt"

Maybe some English speakers pronounce it like that.  In German it's,
well, "Wirth".  English speakers might write it as "veart", where the
"ea" is as in the word "hear" or "fear".

Greg
--
Sent from my desktop computer.
Finger grog at lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180215/e1aee2c2/attachment.sig>

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

On Thu, 15 Feb 2018, Greg 'groggy' Lehey wrote:

>> His name is pronounced "vurt"
>
> Maybe some English speakers pronounce it like that.  In German it's, 
> well, "Wirth".  English speakers might write it as "veart", where the 
> "ea" is as in the word "hear" or "fear".

I wasn't giving a pedantic pronunciation lesson; as you pointed out, there 
is no direct English equivalent.  Hell, the English even pronounce words 
differently in different counties (and I should know).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Happy birthday, Niklaus Wirth!

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> wrote:
 |On Thu, 15 Feb 2018, Greg 'groggy' Lehey wrote:
 |>> His name is pronounced "vurt"
 |>
 |> Maybe some English speakers pronounce it like that.  In German it's, 
 |> well, "Wirth".  English speakers might write it as "veart", where the 
 |> "ea" is as in the word "hear" or "fear".
 |
 |I wasn't giving a pedantic pronunciation lesson; as you pointed out, there 
 |is no direct English equivalent.  Hell, the English even pronounce words 
 |differently in different counties (and I should know).

Just to add that (Gast)"Wirt"h is an innkeeper, and on the
Nikolaus-Day children place shoes in front of their doors so that
Nikolaus can put something in (chocolade!, for example).
But if you would speak "e" just like "ea" than "Wert"h would
surely be "Worth" it, too.

I want to affiliate to the colony of thankful who appreciate your
messages.  Unfortunately i started collecting them just a few
months ago and thus missed quite a lot of them.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Niklaus Wirth!

[Ian Zimmerman]

On 2018-02-15 18:32, Steffen Nurpmeso wrote:

> I want to affiliate to the colony of thankful who appreciate your
> messages.  Unfortunately i started collecting them just a few months
> ago and thus missed quite a lot of them.

Not to worry, you'll catch up within a year or so :-P

Birthdays and Yahrzeits are strange things to observe.

OB-Unix: when did the "message of the day" mechanism make it into our
favorite system?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

[TUHS] Happy birthday, Niklaus Wirth!

[Steffen Nurpmeso]

Ian Zimmerman <itz at very.loosely.org> wrote:
 |On 2018-02-15 18:32, Steffen Nurpmeso wrote:
 |> I want to affiliate to the colony of thankful who appreciate your
 |> messages.  Unfortunately i started collecting them just a few months
 |> ago and thus missed quite a lot of them.
 |
 |Not to worry, you'll catch up within a year or so :-P

Well, maybe not.  And then i have an incomplete archive.

 |Birthdays and Yahrzeits are strange things to observe.

No, i think here you are mistaken.  Likely only so if you are
either young or moved away from the natural world.  I can assure
you the remains of biodiversity here where i live currently has
a very strong notion of the Jahreszeit.

 |OB-Unix: when did the "message of the day" mechanism make it into our
 |favorite system?

I do not run a BSD system daily at the moment, my own calendar
file is thus unused for a while.  Maybe i should write an awk
script or so to have it portably available.
But still an automated mail by script is something different than
spending a minute to write an email to a list.  I mean, you can
use a drone to deliver flowers to your girl friend, or you can
pretty up yourself and bring it in person.  That is something
very, totally, completely different.  And that reminds me of
a film with hrhrm Sylvester Stallone and Sandra Bullock some
decades ago which joked with that exact difference.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[TUHS] Happy birthday, Niklaus Wirth!

[Jeremy C. Reed]

On Thu, 15 Feb 2018, Ian Zimmerman wrote:

> OB-Unix: when did the "message of the day" mechanism make it into our
> favorite system?

Always there! (My favorite is NetBSD which derived from BSD which 
originally derived from 32V and before that as enhancements and patches 
against v4 through v6.)

v1 has the concept
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/man/man7/login.7
but I don't find the code for it.

v2 has it
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/cmd/login.s

(By the way, where is the shell code referenced in init.s for the 
earlier Unix?
http://minnie.tuhs.org/cgi-bin/utree.pl?file=PDP7-Unix )

[TUHS] Happy birthday, Niklaus Wirth!

[Nemo]

On 14/02/2018, Dave Horsfall <dave at horsfall.org> wrote:
> Computer pioneer Niklaus Wirth was born on this day in 1934; he basically
> designed ALGOL, one of the most influential languages ever, with just
> about every programming language in use today tracing its roots to it.

And he is still tinkering:
https://www.srf.ch/radio-srf-3/digital/computer-pionier-niklaus-wirth-80-und-aktiv

N.

[TUHS] Happy birthday, Niklaus Wirth!

[Noel Chiappa]

    > From: Larry McVoy <lm at mcvoy.com>

I am completely non-LISP person (I think my brain was wired in C before C
existed :-), but...

    > Nobody has written a serious operating system

Well, the LISP Machine OS was written entirely in LISP. Dunno if you call that
a 'serious OS', but it was a significantly more capable OS than, say,
DOS. (OK, there was a lot of microcde that did a lot of the low-level stuff,
but...)

    > or a serious $BIG_PROJECT in Lisp.

Have you ever seen a set of Symbolics manuals? Sylph-like, it wesn't!

    > Not one that has been commercially successful, so far as I know.

It's true that Symbolics _eventually_ crashed, but I think the biggest factor
there was that commodity microprocessors (e.g. Pentium) got faster so much
faster than Symbolics' custom LISP hardware, so that the whole rationale for
Symbolics (custom hardware to run LISP fast) went away. They still exist as a
software company selling their coding environment, FWTW.

    > C performs far better even though it is, in the eyes of lisp people, far
    > more awkward to do things.

I think it depend on what you're doing. For some kinds of things, LISP is
probably better.

I mean, for most of the kind of things I do, I think C is the bees' knees
(well, except I had to add conditions and condition handlers when I went to
write a compiler in it), but for some of the AI projects I know a little
about, LISP seems (from a distance, admittedly) to be a better match.

       Noel

[TUHS] Happy birthday, Niklaus Wirth!

[Larry McVoy]

> I think it depend on what you're doing. For some kinds of things, LISP is
> probably better.

I'd like to be told, as a systems guy, what those things are.

I know that people have done awesome stuff in lisp.  But there is swimming
downstream and there is swimming upstream.

[TUHS] Happy birthday, Niklaus Wirth!

[Steve Nickolas]

On Thu, 15 Feb 2018, Larry McVoy wrote:

>> I think it depend on what you're doing. For some kinds of things, LISP is
>> probably better.
>
> I'd like to be told, as a systems guy, what those things are.
>
> I know that people have done awesome stuff in lisp.  But there is swimming
> downstream and there is swimming upstream.
>

Would MDL be considered a variety or derivative of LISP? Zork was 
originally written in that.

-uso.

[TUHS] Happy birthday, Niklaus Wirth!

[Tim Bradshaw]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5548 bytes --]

On 16 Feb 2018, at 02:48, Larry McVoy <lm at mcvoy.com> wrote:
> 
> I'd like to be told, as a systems guy, what those things are.

This is a story I was told in the 1980s about something which happened in the 1960s.  But I was told it by the person who did the thing in the 1960s so I believe it to be true subject to the limitations of my fading memory.

In General Relativity, one of the things you need to do is, starting from a metric (which is a specification, in terms of some basis -- usually a coordinate basis -- of how distances work in that basis), compute various geometrically and physically interesting properties.  Some of these are things like curvature, which tells you whether the spacetime the metric describes is flat, and some of them are related to understanding whether, given two apparently different metrics, do these metrics in fact describe the same spacetime, or parts of the same spacetime.

These calculations are laborious: really, seriously laborious. They're also not algorithmic: it's been known for a long time (this is all pretty much a corollary of Gödel incompleteness) that, for two quite simple algebraic expressions, you can't in general know if they are equal.  But they matter if you want to make progress in GR, because unless you can solve problems like this you end up with people churning out endless metrics and never knowing whether they describe the same spacetimes.  An early concrete example of this is the Schwarzschild metric (which describes nontorating, uncharged things and is a very good approximation for the gravitational field around stars and, famously, black holes).  In the obvious expression for this metric, it blows up in a horrible way at a particular radius (the Schwarzschild radius).  It took people a very long time to understand that this blowing up was not because something physically horrible happened at that radius, but because the coordinate system in which the metric was expressed went bad at that radius.  Eventually people found other metrics which were equivalent to the original one and which did not blow up at the Schwarzschild radius.

There's an important metric which I have always known as the 'Bondi metric' but I think is more properly known as the 'Lemaître–Tolman–Bondi metric', which was under investigation in the 1960s, towards the start of the GR renaissance.  Various properties of this thing needed to be computed, and this was assigned to a student as a PhD project (this is how laborious the computations are: they take a human several years).  I'm not sure who this person was, but they duly got their PhD for it.

At the same time another person (Ray d'Inverno) got interested in whether these computations could be done by machine.  He wrote a program on the Atlas (a second-generation British machine), and he may have written the Lisp in which it was implemented.  This was called ALAM: Atlas Lisp Algebraic Manipulation, and it gave rise to a slightly later thing called LAM (just dropping the 'Atlas': perhaps this was after it was ported somewhere else).

And it turns out that yes, these calculations can be done by machine: I was told that (A)LAM replicated the calculation that the PhD student had done over several years, and it took seven minutes (on, I think I was told, the Atlas).  Better: *it found mistakes in the original computation*.

LAM grew up and became, inevitably, SHEEP, in which form I used it in the 1980s. SHEEP and its derivatives (CLASSI) was widely used for computations in GR (and may still be), often extended by using another algebra system, REDUCE, to do some of the harder simplification -- REDUCE was also written in Lisp of course.  One of my early explorations in retrocomputing was to find the source of the original LAM, persuade it to run on a PC running muLisp that I discovered I could use at night, and use it to redo this original calculation.  I remember it took much longer than seven minutes: 8088-based PCs were still much slower than the Atlas in the early 1980s.  (This had all already been done on the mini we had, the interesting thing was making it work on a PC.)

Now of course, someone will make the silly argument that these systems could be written in C.  Yes, indeed they could be, and the way you do this is *by writing a Lisp system in C*.  Indeed there is a famous aphorism about this, Greenspun's tenth rule of programming:

"Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

There is a corollary to this due to Morris (of the worm):

"Including Common Lisp."

There are some very well-known examples of Greenspun's tenth: I don't want to describe the best one here because it would involve being rude about famous people with extremely large egos in a public forum, and I also own a copy of the thing so I'd be being at least a bit hypocritical.

However I currently work with a very large Fortran program and I can confirm at first hand that it -- specifically its runtime configuration system -- contains a grotty implementation of half of CL (actually less than half, but the configuration system would be *so much nicer* if it was in Lisp).  If only the people who had written this thing had *known* about Lisp rather than known only about Fortran and Python, the world would be a better place.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/72ab0d07/attachment-0001.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Nemo]

On 16/02/2018, Tim Bradshaw <tfb at tfeb.org> wrote (in part):
> In General Relativity, one of the things you need to do is, starting from a
> metric [...], compute various geometrically and physically interesting properties.

Susssman is trying to teach DG via lisp.  (Vide his "Functional
Differential Geometry".)
And a really nice post, by the way.

N.

P.S. Graham wants everyone to use LISP (http://www.paulgraham.com/hp.html ).

[TUHS] Happy birthday, Niklaus Wirth!

[Paul McJones]

On Feb 15, 2018, Ian Zimmerman <itz at very.loosely.org> wrote:

>> 
>> So, how's this relevant to Unix? Well, I'd like to know more about the
>> historical interplay between the Unix and Lisp communities. What about
>> the Lisp done at Berkeley on the VAX (Franz Lisp).
> 
> I know one of the Franz founders, I'll ask him when I have a chance.

There is some information about Franz Lisp and its origins here:

http://www.softwarepreservation.org/projects/LISP/maclisp_family/#Franz_Lisp_

(And lots more information about many other varieties of Lisp at the same web site.)

[TUHS] Happy birthday, Niklaus Wirth!

[Noel Chiappa]

    > From: Larry McVoy <lm at mcvoy.com>

    > I don't know all the details but lisp and performance is not a thing.

This isn't really about Unix, but I hate to see inaccuracies go into
archives...

You might want to read:

  http://multicians.org/lcp.html

Of course, when it comes to the speed/efficientcy of the compiled code, much
depends on the program/programmer. If one uses CONS wildly, there will have to
be garbage collection, which is of course not fast. But properly coded to stay
away from expensive constructs, my understanding is that 'lcp' and NCOMPLR
produced pretty amazing object code.

	 Noel

[TUHS] Happy birthday, Niklaus Wirth!

[Tim Bradshaw]

On 16 Feb 2018, at 13:42, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> This isn't really about Unix, but I hate to see inaccuracies go into
> archives...

I think it's also important to say that claims like 'lisp is slow' are essentially meaningless.

It is reasonable to say that 'this program is slow', where 'this program' refers to some definite bit of code, implicitly qualified by the machine it is running on, when the statement was made &c &c.  That's clearly a thing you can go out and test.

It's often safe to say that particular implementations of programming languages are slow, which means that many or most programs run using the specified implementation of the programming language are slower than they might be either using some other implementation of the same language, or written in some other programming language and run using an implementation of that. In particular I can say 'CPython is slow' for instance: this statement might be wrong, but it does at least have some content.

For programming languages which only *have* one implementation or have a single dominant implementation, you can get lazy and say, for instance 'Python is slow'.  What this really means is 'CPython is slow' (ie it's the same as the previous statement).  It's also dangerous because it tacitly assumes that there is only one implementation of Python, which is not  true (or at least has not been true in the past).  But you can usually get away with this.

For programming languages which have many implementations, and still more for *families* of related programming languages, each member of which may have many implementations, the statement loses all meaning.  What does the statement 'Lisp is slow' *mean*?  The only meaning it could really have is something like 'all implementations of Lisp that there have been are slow and all implementations *there ever will be* will also be slow'.  The only way this could possibly make sense is if the person making the statement understood that some feature or features of any Lisp-family language was so hard to implement that it was really clear that no fast implementation could ever exist.  I claim (without evidence) that Lisp-family languages, considered as a whole, do not contain such toxic features.  So the statement simply does not have any meaning.

I think that people making such statements, assuming they are not making them merely as insults (which very often, historically, they are, although I assume not here), make them because they are confused.  What they really mean, at best, is that certain implementations of Lisp-family languages of which they have (often apocryphal) experience have been rather slow.  In fact what they usually mean is even weaker than that: some particular programs (which someone told them about) run in some particular implementations were slow.  But somehow this becomes generalised to 'Lisp is slow': I think it would be interesting to understand how this generalisation happens, although its probably even more off-topic here than messages about Lisp are.

To bring it slightly back on-topic, I think these statements are very like statements along the lines of 'Unix is insecure', which I think we could all agree is meaningless: a particular implementation of Unix might be insecure, but I think the claim that Unix is *inherently* insecure simply has no content.

Finally I'll just add this quote about Stalin, a Scheme compiler by Siskind: "Stalin is the highest performing Scheme compiler and one of the highest performing compilers for any language".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/c3d07321/attachment-0001.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Paul McJones]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here:

http://www.softwarepreservation.org/projects/ALGOL/standards/

On Feb 16, 2018, Bakul Shah <bakul at bitblocks.com> wrote:

> They did lexical scoping "right", no doubt. But back when
> Landin first found that lambda calculus was useful for
> modeling programming languages these concepts were not clearly
> understood.  I do not recall reading anything about whether
> Algol designers not allowing full lexical scopin was due to an
> oversight or realizing that efficient implementation of
> functional argument was not possible. May be Algol's call by
> name was deemed sufficient? At any rate Algol's not having
> full lexical scoping does not mean one can simply reject the
> idea of being influenced by it. Often at the start there is
> lots of fumbling before people get it right. May be someone
> should ask Steele?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/fbcdb8f4/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Bakul Shah]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1726 bytes --]

Thanks for the correction. A stack is sufficient for invoking functional
arguments but not for invoking functional results. And once you allow
functional results you may have to use a heap to hold their lexical
environment and GC is pretty much a requirement. Algol60 avoided GC
by disallowing functional results. C avoided GC by disallowing nesting.

> On Feb 16, 2018, at 9:40 AM, Paul McJones <paul at mcjones.org> wrote:
> 
> Actually, Algol 60 did allow functions and procedures as arguments (with correct static scoping), but not as results, so they weren’t “first class” in the Scheme sense. The Algol 60 report (along with its predecessor and successor) is available, among other places, here:
> 
> http://www.softwarepreservation.org/projects/ALGOL/standards/
> 
>> On Feb 16, 2018, Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> They did lexical scoping "right", no doubt. But back when
>> Landin first found that lambda calculus was useful for
>> modeling programming languages these concepts were not clearly
>> understood.  I do not recall reading anything about whether
>> Algol designers not allowing full lexical scopin was due to an
>> oversight or realizing that efficient implementation of
>> functional argument was not possible. May be Algol's call by
>> name was deemed sufficient? At any rate Algol's not having
>> full lexical scoping does not mean one can simply reject the
>> idea of being influenced by it. Often at the start there is
>> lots of fumbling before people get it right. May be someone
>> should ask Steele?
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180216/09d550a2/attachment.html>

[TUHS] Happy birthday, Niklaus Wirth!

[Norman Wilson]

As an aside about Wolfram and SMP (and one that actually has
something to do with UNIX):

I ran the VAX on which Wolfram et al (and it was very much et al)
developed SMP.  It started out running UNIX/TS 1.0.  I know how
that system was snuck out of Bell Labs, but if I told you I'd have
to terminate you with extreme prejudice.  (I wasn't involved
anyway.)

SMP really needed dynamic paging; the TS 1.0 kernel had only
swapping.  We had quite a few discussions about what to do.
Moving wholesale to 3BSD or early 4BSD (this was in 1981)
would have been a big upheaval for our entire user community.
Those systems were also notorious at the time for their delicate
stability: some people reported that they ran well, others that
they crashed frequently.  Our existing system was pretty solid,
and I had already put some work into making it more so (better
handling of low-level machine errors, for example).

Somehow we ended up deciding that the least-painful path was
to lift the VM code out of 4BSD and shoehorn it into our
existing kernel, creating what we called Bastardized Paging
UNIX.  I did most of the work; I was younger and more energetic
back then.  Also considerably grumpier.  In the heart of the
page-in (I think) code, the Berkeley guys had written a single
C function that stretched to about ten printed pages.  (For those
too young to remember printers, that means about 600 lines.)
I was then and still am adamant that that's the wrong way to
write anything, but I didn't want to take the time to rewrite
it all, so (being young and grumpy) I relieved my feelings by
adding a grumpy comment at the top of the source file.

I also wrote a paper about the work, which was published in
(of all places) AUUGN.  I haven't read it in years but it was
probably a bit snotty.  It nevertheless ended up causing a
local UNIX-systems-software company to head-hunt me (but at
the time I had no interest in leaving Caltech), so it must
not have been too rude.

What days those were, when a single person could understand
enough of the OS to do stuff like that in only a month or two,
and get it pretty much right too.  I did end up finding some
interesting race-condition bugs, probably introduced by me, but
fascinating to track down; e.g. something that went wrong only
if a page fault happened at exactly the right time with respect
to something else.

Norman Wilson
Toronto ON

[TUHS] Happy birthday, Niklaus Wirth!

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1558 bytes --]

On Sun, 18 Feb 2018, Norman Wilson wrote:

> I also wrote a paper about the work, which was published in (of all 
> places) AUUGN.  I haven't read it in years but it was probably a bit 
> snotty.  It nevertheless ended up causing a local UNIX-systems-software 
> company to head-hunt me (but at the time I had no interest in leaving 
> Caltech), so it must not have been too rude.

Norman is obviously too modest to toot his own trumpet, so me being me 
I'll do it for him:

AUUGN-V04.2.pdf		A bastardized paging UNIX


 				ABSTRACT

     One of the VAXes in the Caltech High Energy Physics Group runs a
     peculiar hybrid of several versions of UNIX.  Its principle claim to
     fame is that it is recognizably a variant of UNIX/TS, but has virtual
     memory code grafted in from Berkeley’s 4BSD.  It is also compatible
     with the UNIX/TS system run on our PDP-II/45.  This paper is meant to
     give some idea of what our system is, why it exists, and how much
     effort went into its creation.

My favourite quote:

     Philosophy - We feel that many of Berkeley’s changes to the
     system and the supporting programs are unnecessary, un-UNIX-like,
     and just plain silly.  To take a favourite example: anyone who
     will add a flag to _cat_ to make it number lines, remove blank
     lines, and make control characters visible, rather than writing
     separate filters, simply doesn’t understand what UNIX is all
     about.

Well said, bro!

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."