The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] ratfor vibe
@ 2022-01-31 20:46 Will Senn
  2022-02-01 15:37 ` arnold
  2022-02-03  4:00 ` Will Senn
  0 siblings, 2 replies; 75+ messages in thread
From: Will Senn @ 2022-01-31 20:46 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2961 bytes --]

All,

I have been doing some language exploration in v7/4.3bsd and came across 
Software Tools (not the pascal version). It's written using ratfor, 
which I had seen in the v7 UPM. I fired up v7 and tried my hand at the 
first example:

    # copy - copy input characters to output
             integer getc
             integer c

             while(getc(c) != EOF)
                     call putc(c)
             stop
             end

The first thing I noticed was that it read more like C than Fortran (I 
know C quite well, Fortran just a smidge)... awesome, right? So I ran 
the preprocessor on it and got the following f77 code:

    c copy - copy input characters to output
           integer getc
           integer c
    c     while
    23000 if(.not.(getc(c) .ne. eof))goto 23001
              call putc(c)
              goto 23000
    c     endwhile
    23001 continue
           stop
           end

Cool. The way it translated the EOF test is weird, but ok. Trying to 
compile it results in complaints about missing getc and putc:

    $ f77 copy.f
    copy.f:
        MAIN:
    Undefined:
    _getc_
    _putc_
    _end

Ah well, no worries. I know that they're in the c lib, but don't about 
fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. 
But running it is no joy:

    $ ./a.out
    This is a test
    $

I remembered that the authors mentioned something about EOF, so I 
tweaked the code (changed EOF to -1) and rebuilt/reran:

    $ ./a.out
    This is a test
    This is a test
    $

Fascinating. Dunno why no complaints from F77 about the undefined EOF 
(or maybe mis-defined), but hey, it works and it's fun.

I'm curious how much ratfor was used in bell labs and other locations 
running v6, v7, and the BSD's. When I first came across it, I was under 
the impression that it was a wrapper to make f66 bearable, but the 
manpage says it's best used with f77, so that's not quite right. As 
someone coming from c, I totally appreciate what it does to make the 
control structures I know and love available, but that wasn't the case 
back then, was it? C was pretty new... Was it just a temporary fix to a 
problem that just went away, or is there tons of ratfor out there in the 
wild that I just haven't seen? I found ratfor77 and it runs just fine on 
my mac with a few tweaks, so it's not dead:

    ratfor77 -C copy.r | tee copy.f
    C Output from Public domain Ratfor, version 1.0
    C copy - copy input characters to output
           integer getc
           integer c
    23000 if(getc(c) .ne. eof)then
           call putc(c)
           goto 23000
           endif
    23001 continue
           stop
           end

What's the story? Oh, and in v6 it looks like it was rc - ratfor 
compiler, which is not present in v7 or 4.3BSD - is there a backstory 
there, too?

Will




[-- Attachment #2: Type: text/html, Size: 4193 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
@ 2022-02-01 15:37 ` arnold
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-03  4:00 ` Will Senn
  1 sibling, 1 reply; 75+ messages in thread
From: arnold @ 2022-02-01 15:37 UTC (permalink / raw)
  To: will.senn, tuhs

Will,

This will be a high level reply. I undoubtedly have some details wrong, as
I wasn't inside Bell Labs.

	Sherman, set the wayback machine for 1974.
		-- Mr. Peabody

In 1974, Unix was still young, and while C existed, it was not widespread.
The predominant programmng language in use at the time in Bell Labs
and in many, many other places, was Fortran.  For our purposes, Fortran IV
and Fortran 66 are the same thing: the only control flow constructs the
language had was 'if', 'goto' and a 'do' loop that could only count up.
The only data structure was the array.

Structured Programming had started to take hold in the Computer Science
community, with lots of discussion and papers about what the best control
flow structures were, and so on.

At the time there were preprocessors for Fortran that made it easier to
program in.  I don't know what got him started, by Brian Kernighan decided
to write one that would give Fortran control flow constructs similar or
identical to those of C.  This was ratfor, for RATional FORtran. He used
C and Yacc (which was also fairly young) to do this.

Recognizing that the Unix environment was very pleasant, but that the
wide world wouldn't drop everything they had to move to it, he and
P.J. (Bill) Plauger used ratfor to create a bunch of tools that provided
functionality similar or identical to many of the Unix utilities,
and wrote a book on the tools, using it as a platform to at the
same time teach good programming practices.  This is

https://www.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X/ref=sr_1_5?crid=LXBHQKV9D0QP&keywords=software+tools&qid=1643720166&s=books&sprefix=software+tools%2Cstripbooks%2C220&sr=1-5

which I STRONGLY recommend getting and reading, even almost 50 years
after it was published (1975 or 1976).

This book changed my life. Literally.

The original tools are in the TUHS archives. (If anyone has not synched
their copy, please do so, there were some errors in the files that I
have recently fixed and which Warren has put in place.)

(A modernized version of UNIX ratfor is at
https://github.com/arnoldrobbins/ratfor, so you don't have to use V7 to
get it. The doc is included and it's easy to make PDF of it.)

The book and tools were extremely popular into the early 80s, until Unix
itself started to spread.  Debbie Scherer can give the history of her
group, which took the tools and made them portable to all kinds of
computing environments. At Georgia Tech, 3 students took the tools and
adapted them into a lovely environment for use on Pr1me systems, which
were otherwise rather less user-friendly.

At Bell Labs, Brenda Baker wrote 'struct' which read Fortran and turned
it into ratfor; see the recent list archives for more on my efforts to bring
that program into the 21st century. (Apologies for the self plugs. :-)

In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
the book to go with it. This is

https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=sr_1_3?keywords=software+tools+in+pascal&link_code=qs&qid=1643727958&sourceid=Mozilla-search&sr=8-3

which I also recommend getting a copy of. This in turn led to Kernighan's
famous "Pascal is not my favorite programming language" memo (which is also
in my github :-).

The Pascal tools are also in the TUHS archive.

I hope this helps.

Arnold


Will Senn <will.senn@gmail.com> wrote:

> All,
>
> I have been doing some language exploration in v7/4.3bsd and came across 
> Software Tools (not the pascal version). It's written using ratfor, 
> which I had seen in the v7 UPM. I fired up v7 and tried my hand at the 
> first example:
>
>     # copy - copy input characters to output
>              integer getc
>              integer c
>
>              while(getc(c) != EOF)
>                      call putc(c)
>              stop
>              end
>
> The first thing I noticed was that it read more like C than Fortran (I 
> know C quite well, Fortran just a smidge)... awesome, right? So I ran 
> the preprocessor on it and got the following f77 code:
>
>     c copy - copy input characters to output
>            integer getc
>            integer c
>     c     while
>     23000 if(.not.(getc(c) .ne. eof))goto 23001
>               call putc(c)
>               goto 23000
>     c     endwhile
>     23001 continue
>            stop
>            end
>
> Cool. The way it translated the EOF test is weird, but ok. Trying to 
> compile it results in complaints about missing getc and putc:
>
>     $ f77 copy.f
>     copy.f:
>         MAIN:
>     Undefined:
>     _getc_
>     _putc_
>     _end
>
> Ah well, no worries. I know that they're in the c lib, but don't about 
> fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. 
> But running it is no joy:
>
>     $ ./a.out
>     This is a test
>     $
>
> I remembered that the authors mentioned something about EOF, so I 
> tweaked the code (changed EOF to -1) and rebuilt/reran:
>
>     $ ./a.out
>     This is a test
>     This is a test
>     $
>
> Fascinating. Dunno why no complaints from F77 about the undefined EOF 
> (or maybe mis-defined), but hey, it works and it's fun.
>
> I'm curious how much ratfor was used in bell labs and other locations 
> running v6, v7, and the BSD's. When I first came across it, I was under 
> the impression that it was a wrapper to make f66 bearable, but the 
> manpage says it's best used with f77, so that's not quite right. As 
> someone coming from c, I totally appreciate what it does to make the 
> control structures I know and love available, but that wasn't the case 
> back then, was it? C was pretty new... Was it just a temporary fix to a 
> problem that just went away, or is there tons of ratfor out there in the 
> wild that I just haven't seen? I found ratfor77 and it runs just fine on 
> my mac with a few tweaks, so it's not dead:
>
>     ratfor77 -C copy.r | tee copy.f
>     C Output from Public domain Ratfor, version 1.0
>     C copy - copy input characters to output
>            integer getc
>            integer c
>     23000 if(getc(c) .ne. eof)then
>            call putc(c)
>            goto 23000
>            endif
>     23001 continue
>            stop
>            end
>
> What's the story? Oh, and in v6 it looks like it was rc - ratfor 
> compiler, which is not present in v7 or 4.3BSD - is there a backstory 
> there, too?
>
> Will
>
>
>

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 15:37 ` arnold
@ 2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
                       ` (2 more replies)
  0 siblings, 3 replies; 75+ messages in thread
From: Ralph Corderoy @ 2022-02-01 15:52 UTC (permalink / raw)
  To: tuhs

Hi Arnold,

> In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
> the book to go with it. This is
> https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/
> which I also recommend getting a copy of.

I agree the original Software Tools is a must read, but having done so,
why would I suffer working through the hurdles put in place by Pascal
compared to Ratfor?  I never bothered so your recommendation makes me
wonder what I missed.  I did read Kernighan's ‘not my favourite’
and took from that I wouldn't enjoy the Pascal book given I'd read
the original.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
@ 2022-02-01 16:58     ` Clem Cole
  2022-02-01 17:02     ` silas poulson
  2022-02-02  7:47     ` arnold
  2 siblings, 0 replies; 75+ messages in thread
From: Clem Cole @ 2022-02-01 16:58 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 5192 bytes --]

On Tue, Feb 1, 2022 at 10:53 AM Ralph Corderoy <ralph@inputplus.co.uk>
wrote:

> I agree the original Software Tools is a must read, but having done so,
> why would I suffer working through the hurdles put in place by Pascal
> compared to Ratfor?

I'll take a stab.  Again set Arnold's  Way-Back machine to the late '60 and
through the mid 1970s.  The Algol vs. FTN war was raging.   FTN had 'won'
the Science and Engineering communities and Algol was the Math/CS types
[I'm over simplifying].   In fact, when I was at CMU in the mid-70s; my
professors all said *FTN was dead*  ( mind you production quality FTN code
has paid my salary in the HPC world my entire career ).  At CMU, the
compromise is all engineers were required to take an intro to computing
using in FTN/WATFIV course and then all other 200 level or greater CS
course after that were usualy based using an Algol/ or later Pascal.

The point being any reasonable computer system being brought to market
by a *credible
systems vendor* had at least an implementation of FTN4 that could pass the
ANSI test suite and many started to have one that support F77 [although
thank you DEC VMS FTN != F77].   But ... because of the push from the
teaching/CS side in most places, Pascal started to show up as a standard
offering [C did not - yet - have that backing].   I suspect if you check my
generation and for the next 10-20 years after, you will see Pascal was the
first language you saw in college.

So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
Pascal had become the primary teaching language for the CS communities at
most schools.   C was considered a tad 'dirty' [not as bad as assembler --
but close].  It might have been used in an OS or Compiler course.  In fact
in the grad Graphics course I took, which was taught by Xerox folks, I had
to get a special exception to use C.

But the fact is, at that time, if you read the literature, you would
believe that Pascal was going to be the future. Hence the concept of doing
the SWT in Pascal made sense >>in theory<<. Another important fact was that
while the P4 system made moving Pascal easier than many other languages, as
Rob pointed out, the Pascal I/O was so screwy and frankly not well bound to
the host OS, that every new implementation messed with it in some manner
[see Brian's wonderful tome for more details].   Similarly, the lack of
standardized way to do separate compilation for support libs (which had
been a prime idea in FTN and allowed a rich market for libraries), really
had a huge effect.  Again it was solved many times with each compiler
implementation, but each scheme tended to be a little different.

Fortran, of course, had been around long enough and had an ANSI standard
(and a test suite for it) at least made portable FTN possible.

So the theory was good -- Pascal was a 'better' language in theory and
everyone was coming out of school knowing it.

Again, reality ...  since UNIX came with C and was 'open source' in the
sense that everyone that had it, had the AT&T source code.  One of the
first things that happened was C was retargeted to a number of processors
-- often not by either the manufacturer or by the system vendor.
Interestingly, this was about 50/50 between Academics/Research and
Industry.   So while all the world's ISA were not a PDP-11, the fun part is
the code *could be made reasonably* portable - in fact *in practice*
[partly because C had a pre-processor which Pascal did not and of course is
what ratfor is] have one source base that could compile for different
targets.

The problem (as you note) these issues are >>obvious<< in hindsight, but
during that time -- it was not.  It certainly seems like Pascal had a lot
of momentum. They were a lot compilers for a lot of systems.   Look, it was
the language Apple used for the Lisa and Mac.  Things like UCSD Pascal was
being made by the press as 'the answer for 8 bit processors' [note MSFT had
a FTN for the 8080 on CPM in those days].   Turbo Pascal was, in fact,
an excellent compiler.  But C was starting to come on strong.

FWIW:  In the end, I personally believe that C 'won' because the practical
side made it cheaper to use (economics always beat architecture).  The
cynical part of me thinks that a big reason why C++ caught on is because a
lot of the pro-Pascal community got to sing the praises of OOP with C++ and
they could change sides without claiming C beat Pascal.  Hey, Microsoft
made a pretty good C for DOS and finally going C++ probably helped.  It
sold more than the FORTRAN and my guess is that people using FORTRAN at
that point were scientists and needed the address space that 8086 did not
have. The 386 with a linear address for using things like the PharLap tools
made it possible and frankly the Intel 8087 started to make that processor
a better target for science.

In the end, Pascal never had a code base like the FTN Scientific code base
or todays C and C++ code base.   FWIW: I can think of few production Pascal
codes from those days that are still being used [other than the Front-End
of the DEC/Intel FORTRAN compiler - which was moved from BLISS to Pascal
for all the same 'C is dirty' issues BTW].

[-- Attachment #2: Type: text/html, Size: 7504 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
@ 2022-02-01 17:02     ` silas poulson
  2022-02-02  7:47     ` arnold
  2 siblings, 0 replies; 75+ messages in thread
From: silas poulson @ 2022-02-01 17:02 UTC (permalink / raw)
  To: Ralph Corderoy; +Cc: Paul Ruizendaal via TUHS

> On 1 Feb 2022, at 15:52, Ralph Corderoy <ralph@inputplus.co.uk> wrote:
> I never bothered so your recommendation makes me wonder what I missed.

Whilst I haven’t read the original, believe Kernighan and Plauger
state in preface that Pascal enabled recursive algorithms to be
written in their natural manner.

Don’t believe Fortran has record or set datatypes and imagine those
enabled code improvements between the Ratfor and the Pascal

> I did read Kernighan's ‘not my favourite’ and took from that I
> wouldn't enjoy the Pascal book given I'd read the original.

Not quite sure reading both editions of the book but would definitely
recommend examining the code which Arnold states is available on the
TUHS archive.

Silas


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 15:52   ` Ralph Corderoy
  2022-02-01 16:58     ` Clem Cole
  2022-02-01 17:02     ` silas poulson
@ 2022-02-02  7:47     ` arnold
  2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
                         ` (2 more replies)
  2 siblings, 3 replies; 75+ messages in thread
From: arnold @ 2022-02-02  7:47 UTC (permalink / raw)
  To: tuhs, ralph

Ralph Corderoy <ralph@inputplus.co.uk> wrote:

> Hi Arnold,
>
> > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid
> > the book to go with it. This is
> > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/
> > which I also recommend getting a copy of.
>
> I agree the original Software Tools is a must read, but having done so,
> why would I suffer working through the hurdles put in place by Pascal
> compared to Ratfor?  I never bothered so your recommendation makes me
> wonder what I missed.  I did read Kernighan's ‘not my favourite’
> and took from that I wouldn't enjoy the Pascal book given I'd read
> the original.
>
> -- 
> Cheers, Ralph.

As others mentioned, recursion and real data structures make code
easier to read. They also refined the text some.

But in general, I think the principle of "ANYTHING written by Brian
Kernighan is worth reading, at least once" applies, even in this case.

FWIW, Brian has told me more than once that he wishes they'd done "Software
Tools In C" instead of in Pascal, and that the Pascal book was a failure
to read the market correctly.

Long ago, I once dreamed that I found "Software Tools In C" in a bookstore;
the cover had green lettering instead of the red and blue used in the
real books. I was sorta disappointed when I woke up... :-)

HTH,

Arnold

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
  2022-02-01 15:37 ` arnold
@ 2022-02-03  4:00 ` Will Senn
  2022-02-03  4:31   ` Al Kossow
  2022-02-03 20:00   ` Adam Thornton
  1 sibling, 2 replies; 75+ messages in thread
From: Will Senn @ 2022-02-03  4:00 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 4786 bytes --]

On 1/31/22 2:46 PM, Will Senn wrote:
> All,
>
> I have been doing some language exploration in v7/4.3bsd and came 
> across Software Tools (not the pascal version). It's written using 
> ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my 
> hand at the first example:

I thought I'd close the loop on the language side of this thread. I am 
happy to report that ratfor (and fortran) is alive and well. It works on 
my mac! The Software Tools book is awesome, if challenging. The first 
chapter is particularly challenging as it takes a bit to figure out 
where the authors are coming from and what they include, exclude, and 
highlight... and why. The key to understanding the book, as a modern 
reader, is to understand that the authors assume their readers are 
fortran (or PL/I) programmers.  Because of this, they don't explain 
anything that would be obvious to said programmers (read, write, LUNs, 
Hollerith cards, format, etc). In addition, they will push down details 
of implementation until they practically disappear (think singularity... 
annoyingly consistent in this regard). When they say something like "EOF 
is a symbolic constant... We won't tell you what its value is, since the 
particular value doesn't matter", they really mean it. Unfortunately, in 
order to actually implement stuff, you gotta know what every symbolic 
constant and macro replacement is :).

For example, even in the tiny copy program example, from the 
introductory chapter, once you include the primitive getc and putc 
subroutines, there are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, 
STDIN, STDOUT, EOF, SPACE and character, which is really an integer and 
gets replaced with integer by some mythical preprocessor (chapter 8). 
Anyhow, in the modern world, MAXLINE and MAXCARD don't really have 
meaning, but they can magically be treated as lines of a file, the rest 
do have meaning, but they don't evaluate to the same things in 
Fortran-land as in modern-land. STDIN is 5 and STDOUT is 6 (card reader 
and punch LUNs, again some magic that lets them be treated as terminal 
input and output),  EOF is -1, SPACE is 32, NEWLINE is 10. Anyhow, long 
story just a bit shorter, replace those constants, swap character for 
integer, and combine getc, putc, and copy and yahoo, a working copy 
program that works in v7, 4.xBSD, and Mac OS X Mojave (and BSD, etc), 
without any further modifications... at all.

Included for the curioius (copynew.r):

    # on v7
    # $ ratfor -C copynew.r > copynew.f
    # $ f77 -o copynew copynew.f
    # on mac
    # $ ratfor77 -C copynew.r > copynew.f
    # $ gfortran -o copynew copynew.f
    # $ ./copynew
    # This is a test.
    # This is a test.
    # CTRL-d
    # $

    # getc (simple version) - get characters from standard input
             integer function getc(c)
             integer buf(81), c
             integer i, lastc
             data lastc /81/,buf(81) /10/

             lastc = lastc + 1
             if(lastc > 81) {
                     read(5, 100, end=10) (buf(i), i = 1, 80)
                             100 format(80 a 1)
                     lastc = 1
                     }
             c = buf(lastc)
             getc = c
             return

    10      c = -1
             getc = -1
             return
             end

    # putc (simple version) - put characters on the standard output
             subroutine putc(c)
             integer buf(80), c
             integer i, lastc
             data lastc /0/

             if (lastc > 80 | c == 10) {
                     for (i = lastc + 1; i <= 80; i = i + 1)
                             buf(i) = 32
                     write(6, 100) (buf(i), i = 1, 80)
                             100 format(80 a 1)
                     lastc = 0
                     }
             if (c != 10) {
                     lastc = lastc + 1
                     buf(lastc) = c
                     }
             return
             end

    # copy - copy input characters to output
             integer getc
             integer c

             while(getc(c) != -1)
                     call putc(c)
             stop
             end

Of course, it's criminal to have all those hardcoded magic numbers, 
wouldn't it be swell if there were some sort of macro facility?... oh, 
wait, that's what Chapter 8's all about... I can't wait.

Will

[-- Attachment #2: Type: text/html, Size: 6184 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-03  4:00 ` Will Senn
@ 2022-02-03  4:31   ` Al Kossow
  2022-02-03  5:16     ` Warner Losh
  2022-02-03 20:00   ` Adam Thornton
  1 sibling, 1 reply; 75+ messages in thread
From: Al Kossow @ 2022-02-03  4:31 UTC (permalink / raw)
  To: tuhs

On 2/2/22 8:00 PM, Will Senn wrote:

> Of course, it's criminal to have all those hardcoded magic numbers

Graybeards chucking at the follies of youth.



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-03  4:31   ` Al Kossow
@ 2022-02-03  5:16     ` Warner Losh
  0 siblings, 0 replies; 75+ messages in thread
From: Warner Losh @ 2022-02-03  5:16 UTC (permalink / raw)
  To: Al Kossow; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

On Wed, Feb 2, 2022, 9:37 PM Al Kossow <aek@bitsavers.org> wrote:

> On 2/2/22 8:00 PM, Will Senn wrote:
>
> > Of course, it's criminal to have all those hardcoded magic numbers
>
> Graybeards chucking at the follies of youth.
>

Yea, this code is quite well written relative to most of the code of that
era...

Warner

>

[-- Attachment #2: Type: text/html, Size: 877 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* [TUHS] more about Brian...
  2022-02-02  7:47     ` arnold
@ 2022-02-03  5:47       ` Rich Morin
  2022-02-03  7:44         ` markus schnalke
  2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
  2022-02-10 15:18       ` Ralph Corderoy
  2 siblings, 1 reply; 75+ messages in thread
From: Rich Morin @ 2022-02-03  5:47 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

> On Feb 1, 2022, at 23:47, arnold@skeeve.com wrote:
> 
> ... in general, I think the principle of "ANYTHING written by Brian
> Kernighan is worth reading, at least once" applies, ...

I've been having a good time watching YouTube videos that have Brian either interviewing or being interviewed by assorted folks.  My favorite one, so far, is this "fireside chat":

	VCF East 2019 -- Brian Kernighan interviews Ken Thompson
	https://www.youtube.com/watch?v=EY6q5dv_B-o

In any case, the K&P book I'd _really_ like to see brought up to date is "The Elements of Programming Style".  It could have been subtitled "How to write small, simple programs that work."  It's still a very fine book, but I'm not sure that the current crop of beginning programmers would be patient enough to deal with the sadly dated example code.


If you're still here, I'll give you a vignette from many years ago.  My spouse and I were both early fans of AWK, having been introduced to it around 1983 by our friend Jim Joyce.  Indeed, she used AWK to process line printer plot files (dendograms, for the curious) into a format that my homegrown SunCore interpreter could render for screen display and printing on our dot matrix printer.  Some of them ended up in her Master's Thesis...

Anyway, we traveled with Jim to Copenhagen for a EurOpen conference.  At the closing banquet, I got to an empty table before anyone else and tossed down a "no smoking" placard.  Vicki and I then sat down.  Shortly thereafter, Brian walked past and saw the placard.

	Brian:  "Is this a non-smoking table?"
	Us: "It is now. (:-)"

So, he sat down and we had a chance to dine with a personal hero (and all-around nice guy). The next day, we got on a train to Stockholm, on our way to Helsinki (to teach a Unix Intro course with Jim).  Our four-person compartment turned out to include Brian, Vicki, me, and a long-suffering European businessman.  IIRC, we pestered Brian for hours about AWK, Bell Labs, and so forth.  He was unfailingly gracious and a wonderful person to spend the trip with.

-r


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
@ 2022-02-03  7:44         ` markus schnalke
  2022-02-03  8:18           ` Rich Morin
  2022-02-04  2:23           ` Adam Thornton
  0 siblings, 2 replies; 75+ messages in thread
From: markus schnalke @ 2022-02-03  7:44 UTC (permalink / raw)
  To: tuhs

Hoi.

[2022-02-02 21:47] Rich Morin <rdm@cfcl.com>
> 
> In any case, the K&P book I'd _really_ like to see brought up
> to date is "The Elements of Programming Style".  It could have
> been subtitled "How to write small, simple programs that work."
> It's still a very fine book, but I'm not sure that the current
> crop of beginning programmers would be patient enough to deal
> with the sadly dated example code.

Don't you think that ``The Practice of Programming'' is the modern
version of ``The Elements of Programming Style''? (Also a K&P book,
btw. ;-) ) (Of course, the C++ and Java code in there would be
seen as outdated as well, by now.)

But even this one, today's programmers don't wanna read. They all
go for ``Clean Code'', because they seem to like the style where
someone with perfect selfconfidence answers all their questions
and tells them what to do, as long it is not telling them to think
for themselves and compromise between various conflicting goals
that you all like go reach and thus that it depends on the
specific situation.

The problem IMO is not some dated example code but today's
programmers having few interest in learning things outside their
main modern focus and the style the're used to. They usually think
that running fast is the best way moving forward, but they don't
realize that slowing down, looking around, understanding the paths
that lead us where we are and taking time to learn and think,
isn't as slow as they might expect and eventually leads to better
results.

Being used to reading code and understanding concepts that are not
fully in the style you're used to and transferring them to one's
own world actually is a valuable ability, that people should train
instead of avoid. Thus especially students should do read that good
old ``Elements of Programming Style'' and discuss that, not a new
book.


Overall I don't really think that there's much hope in getting
programmers to read such stuff, because they simply don't want to.
Many don't care for good code, because they don't think in code
lifespans of more than three to five years. They don't care to
understand what they do and how the internals work, because that's
hard work without instant results. And in today's world it's
usually pays out to not do it. They don't care for simplicity but
they want features and nice GUIs. Besides, they use technologies
that favor huge programs and often are poorly suited for programming
with small programs. Likewise, their whole thinking is focussed on
large programs, because that's what they've been taught the whole
time.

What attracts them more and probably is more helpful is something
like Go, which solves their problems. They don't use it because of
conceptional beauty but because of its features. If you want to
attract the masses, then you have to give them solutions to their
problems and their wishes, not trying to educate them. ;-) To
really step forward with the Unix philosophy Go needs to enter
education and become today's Java as a main programming learning
language.


And for those, who are different, it doesn't matter so much how
dated the examples are. It's the ideas and concepts which attract
them. With Go there is a very modern technology, for beginners and
experts alike, that carries Unix concepts and its way of thinking
and decision making throughout. That probably is much more
effective than any book. Besides, there are lots of Youtube videos
around Go which transport the ideas and concepts, which as well are
probably much more effective today than books.

Anyone on this list, on the other hand, will probably be very happy
in reading on of these old books (again) ... and have a great time!
:-)


meillo


P.S.
Thanks for sharing your bwk stories!


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-03  7:44         ` markus schnalke
@ 2022-02-03  8:18           ` Rich Morin
  2022-02-04  2:23           ` Adam Thornton
  1 sibling, 0 replies; 75+ messages in thread
From: Rich Morin @ 2022-02-03  8:18 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

> On Feb 2, 2022, at 23:44, markus schnalke <meillo@marmaro.de> wrote:
> 
> Don't you think that ``The Practice of Programming'' is the modern
> version of ``The Elements of Programming Style''?

Not really.  It's a fine book, but a lot bigger, so it contains a lot more (and more diverse) material.  I like the facts that "The Elements of Programming Style" is pretty tightly focused and that it can be read quickly (and absorbed over time :-).  That is, the title's homage to "The Elements of Style" is not an accident...

-r



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-02  7:47     ` arnold
  2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
@ 2022-02-03 18:57       ` silas poulson
  2022-02-04  8:26         ` arnold
  2022-02-10 15:18       ` Ralph Corderoy
  2 siblings, 1 reply; 75+ messages in thread
From: silas poulson @ 2022-02-03 18:57 UTC (permalink / raw)
  To: arnold; +Cc: Paul Ruizendaal via TUHS

> FWIW, Brian has told me more than once that he wishes they'd done
> “Software Tools In C" instead of in Pascal, and that the Pascal book
> was a failure to read the market correctly.

Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper!

Has Brian ever said what would’ve been different if a C version had
been written?

Silas


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-03  4:00 ` Will Senn
  2022-02-03  4:31   ` Al Kossow
@ 2022-02-03 20:00   ` Adam Thornton
  2022-02-04  6:06     ` Ori Idan
  1 sibling, 1 reply; 75+ messages in thread
From: Adam Thornton @ 2022-02-03 20:00 UTC (permalink / raw)
  To: Will Senn, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote:

>
> For example, even in the tiny copy program example, from the introductory
> chapter, once you include the primitive getc and putc subroutines, there
> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF,
> SPACE and character, which is really an integer and gets replaced with
> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern
> world, MAXLINE and MAXCARD don't really have meaning, but they can
> magically be treated as lines of a file, the rest do have meaning, but they
> don't evaluate to the same things in Fortran-land as in modern-land. STDIN
> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that
> lets them be treated as terminal input and output),  EOF is -1, SPACE is
> 32, NEWLINE is 10.
>
> Pretty sure that EOF is _still_ -1.  SPACE and NEWLINE also look pretty
> familiar and their values haven't changed, although we might spell them a
> little differently these days.
>

[-- Attachment #2: Type: text/html, Size: 1560 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-03  7:44         ` markus schnalke
  2022-02-03  8:18           ` Rich Morin
@ 2022-02-04  2:23           ` Adam Thornton
  2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
                               ` (3 more replies)
  1 sibling, 4 replies; 75+ messages in thread
From: Adam Thornton @ 2022-02-04  2:23 UTC (permalink / raw)
  To: markus schnalke, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

It feels like the tide has turned from Go to Rust.  I speak Go relatively
fluently but have never used Rust in anger.  Do the august personages on
this
list have opinions about Rust?  People who generally have tastes consonant
with mine tell me I'd like Rust.

Although a bit outdated, I stand by what I wrote about Go several (six?)
years ago: https://athornton.github.io/go-it-mostly-doesnt-suck

Adam
On Thu, Feb 3, 2022 at 12:45 AM markus schnalke <meillo@marmaro.de> wrote:

>
>
> What attracts them more and probably is more helpful is something
> like Go, which solves their problems. They don't use it because of
> conceptional beauty but because of its features. If you want to
> attract the masses, then you have to give them solutions to their
> problems and their wishes, not trying to educate them. ;-) To
> really step forward with the Unix philosophy Go needs to enter
> education and become today's Java as a main programming learning
> language.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1452 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [really Rust]
  2022-02-04  2:23           ` Adam Thornton
@ 2022-02-04  2:34             ` Jon Steinhart
  2022-02-04 13:07               ` Thomas Paulsen
  2022-02-04 23:18               ` Dan Cross
  2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
                               ` (2 subsequent siblings)
  3 siblings, 2 replies; 75+ messages in thread
From: Jon Steinhart @ 2022-02-04  2:34 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Adam Thornton writes:
> Do the august personages on this list have opinions about Rust?
> People who generally have tastes consonant with mine tell me I'd like Rust.

Well, I'm not an august personage and am not a Rust programmer.  I did
spend a while trying to learn rust a while ago and wasn't impressed.

Now, I'm heavily biased in that I think that it doesn't add value to keep
inventing new languages to do the same old things, and I didn't see anything
in Rust that I couldn't do in a myriad of other languages.

But, my real issue came from some of the tutorials that I perused.  Rust is
being sold as "safer".  As near as I can tell from the tutorials, the model
is that nothing works unless you enable it.  Want to be able to write a
variable?  Turn that on.  So it seemed like the general style was to write
code and then turn various things on until it ran.

To me, this implies a mindset that programming errors are more important
than thinking errors, and that one should hack on things until they work
instead of thinking about what one is doing.  I know that that's the
modern definition of programming, but will never be for me.

Jon

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  2:23           ` Adam Thornton
  2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
@ 2022-02-04  3:28             ` Dan Stromberg
  2022-02-04  5:11             ` Rich Morin
  2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
  3 siblings, 0 replies; 75+ messages in thread
From: Dan Stromberg @ 2022-02-04  3:28 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

On Thu, Feb 3, 2022 at 6:25 PM Adam Thornton <athornton@gmail.com> wrote:

> It feels like the tide has turned from Go to Rust.  I speak Go relatively
> fluently but have never used Rust in anger.  Do the august personages on
> this
> list have opinions about Rust?  People who generally have tastes consonant
> with mine tell me I'd like Rust.
>
> Although a bit outdated, I stand by what I wrote about Go several (six?)
> years ago: https://athornton.github.io/go-it-mostly-doesnt-suck
>

I think Rust brings something new and interesting to language design.

Databases like to have many readers or a single writer for a given piece of
data.  Rust takes this idea and makes it part of the language.

It also manages to be largely memory-leak free, without a garbage collector.

And it still allows you to shoot your foot off if you really want to.  But
there's a hoop to jump through first, which, I think, is how it should be.

[-- Attachment #2: Type: text/html, Size: 1492 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  2:23           ` Adam Thornton
  2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
  2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
@ 2022-02-04  5:11             ` Rich Morin
  2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
  2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
  3 siblings, 1 reply; 75+ messages in thread
From: Rich Morin @ 2022-02-04  5:11 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Well, this topic certainly took an odd turn.  Owell...

> On Feb 3, 2022, at 18:23, Adam Thornton <athornton@gmail.com> wrote:
> 
> It feels like the tide has turned from Go to Rust.  ...

The incursions of Rust (and not Go) into Linux, Mozilla, and such may indicate a trend.  

> Although a bit outdated, I stand by what I wrote about Go several (six?) years ago: https://athornton.github.io/go-it-mostly-doesnt-suck

I quite enjoyed this and found it to be informative, as well.  My personal reaction to Go (mostly derived from skimming Brian's book) is that (a) it's well tuned to Google's needs and (b) not well tuned to mine.  Specifically...

Google needs a language which runs efficiently and links in a reasonable amount of time, even when HUGE sets of libraries are involved.  It also needs a convenient way to do massive concurrency.  Finally, it needs zillions of programmers to be fungible, dropping into code bases that they've never seen before, without tripping over landmines.  My impression is that Go meets these criteria admirably.  But, horses for courses...

I program mostly on my own, so most of these criteria are irrelevant to my needs.  I use Ruby for short scripts and Elixir for larger programs.  Neither one is blazingly fast, but they both feel comfortable to write in.  I like Matz's taste in design and think that José Valim has pulled together a very appealing mix of concepts and syntax from Clojure, Erlang, F#, Lisp, Ruby, etc.

One problem I have with Go is that it doesn't match the way I code.  Kind of like (I imagine) an oil painter might work, I start with broad swatches and fill in the details over time.  So, any new program is likely to have stubs lying about, waiting to be implemented.  Also, I might well calculate a variable only to support a trace statement which is currently commented out.  Go is very intolerant of this sort of thing: an unused variable, IIRC, is a fatal error.  Google isn't paying me to put up with this sort of thing, so I don't.

Another problem I have with Go is the concurrency model.  First, it uses threads, which I've never felt competent to use safely.  Shared mutable state is one of those things that seem to me like an accident waiting to happen.  Also, though I have no real experience with CSP, it seems like the Actor model may be better suited to exploratory programming.

Getting back to Rust, my impression is that its design assumes that having the computer put up guard rails will (mostly) keep programmers from making catastrophic mistakes.  In contrast, the Erlang (and thus Elixir) approach assumes that things WILL crash and that the important thing is to make sure that the system as a whole keeps running smoothly.  So, for example, it provides supervision trees which can handle any crash of an Actor, etc.

Also, I learned pretty early in my career (ca. 1972) that some of the biggest botches come from folks not understanding the needs of the users.  I wrote a 10 KLOC PDP-11 assembly language program, based on a 1" thick specification document.  It never got used, because it didn't solve the users' problem.  Fine code, broken spec...

Having said all this, I'm actually quite happy about the fact that Rust is creeping into Linux.  The coding style is likely to be a bit more careful and it may well help to provide some protection against security issues.  (ducks)

-r



^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-03 20:00   ` Adam Thornton
@ 2022-02-04  6:06     ` Ori Idan
  2022-02-04 17:35       ` Adam Thornton
  0 siblings, 1 reply; 75+ messages in thread
From: Ori Idan @ 2022-02-04  6:06 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

SPACE is 32 and NEWLINE is 10 is that the reason that space in ASCII is 32
As for EOF it is 0xFF which is not always -1, depending if your char is
signed or unsigned.

-- 
Ori Idan CEO Helicon Books
http://www.heliconbooks.com





On Thu, Feb 3, 2022 at 10:01 PM Adam Thornton <athornton@gmail.com> wrote:

>
>
> On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote:
>
>>
>> For example, even in the tiny copy program example, from the introductory
>> chapter, once you include the primitive getc and putc subroutines, there
>> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF,
>> SPACE and character, which is really an integer and gets replaced with
>> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern
>> world, MAXLINE and MAXCARD don't really have meaning, but they can
>> magically be treated as lines of a file, the rest do have meaning, but they
>> don't evaluate to the same things in Fortran-land as in modern-land. STDIN
>> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that
>> lets them be treated as terminal input and output),  EOF is -1, SPACE is
>> 32, NEWLINE is 10.
>>
>> Pretty sure that EOF is _still_ -1.  SPACE and NEWLINE also look pretty
>> familiar and their values haven't changed, although we might spell them a
>> little differently these days.
>>
>

[-- Attachment #2: Type: text/html, Size: 2442 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  2:23           ` Adam Thornton
                               ` (2 preceding siblings ...)
  2022-02-04  5:11             ` Rich Morin
@ 2022-02-04  7:38             ` Andy Kosela
  2022-02-04  8:10               ` Steve Nickolas
  3 siblings, 1 reply; 75+ messages in thread
From: Andy Kosela @ 2022-02-04  7:38 UTC (permalink / raw)
  To: Adam Thornton; +Cc: The Eunuchs Hysterical Society

On 2/4/22, Adam Thornton <athornton@gmail.com> wrote:
> It feels like the tide has turned from Go to Rust.  I speak Go relatively
> fluently but have never used Rust in anger.  Do the august personages on
> this
> list have opinions about Rust?  People who generally have tastes consonant
> with mine tell me I'd like Rust.
>
> Although a bit outdated, I stand by what I wrote about Go several (six?)
> years ago: https://athornton.github.io/go-it-mostly-doesnt-suck

2010 Go != 2022 Go

I used to be a big proponent of Go back in 2010.  The language
definitely felt fresh and minimal back then when Java and C++ were
dominant on the market.  And it definitely felt like the authors of Go
wanted to replace them .  It made sense in the Google environment, but
very soon people realized that you can't write everything in Go.
Garbage collector is cool but actually it prevents you from writing
kernel or performance critical code, e.g. games.

But Go became popular anyway.  A lot of substandard PHP and New Age
programmers started using it and it showed.  In the beginning the
humble authors of Go preferred minimal variable names and less than 80
char lines.  In time all this turned into Java-like long, expressive
variable names and extremely long lines.  I really hate lines longer
than 80 chars...in any language.  They are really hard to focus as you
need to constantly move your eyes from left to right.  The same
phenomenon happens with very wide browser windows.

And due to popular demand they started to add on to the language
features: modules, generics, etc..  The language still feels a lot
less bloated than C++, but IMHO plain old C just feels more natural
and minimal.

And because I still program on a lot of old retro systems today I
returned back to C.  You can use C on pretty much everything -- from
8-bit machines to amd64.  You can't say the same about Go.

And Rust?  If Go was trying to reinvent C, Rust definitely feels like
it is trying to reinvent C++...

--Andy

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
@ 2022-02-04  8:10               ` Steve Nickolas
  2022-02-04  8:44                 ` markus schnalke
  2022-02-04 18:54                 ` John Cowan
  0 siblings, 2 replies; 75+ messages in thread
From: Steve Nickolas @ 2022-02-04  8:10 UTC (permalink / raw)
  To: Andy Kosela; +Cc: The Eunuchs Hysterical Society

On Fri, 4 Feb 2022, Andy Kosela wrote:

> I used to be a big proponent of Go back in 2010.  The language
> definitely felt fresh and minimal back then when Java and C++ were
> dominant on the market.  And it definitely felt like the authors of Go
> wanted to replace them .  It made sense in the Google environment, but
> very soon people realized that you can't write everything in Go.
> Garbage collector is cool but actually it prevents you from writing
> kernel or performance critical code, e.g. games.
>
> But Go became popular anyway.  A lot of substandard PHP and New Age
> programmers started using it and it showed.  In the beginning the
> humble authors of Go preferred minimal variable names and less than 80
> char lines.  In time all this turned into Java-like long, expressive
> variable names and extremely long lines.  I really hate lines longer
> than 80 chars...in any language.  They are really hard to focus as you
> need to constantly move your eyes from left to right.  The same
> phenomenon happens with very wide browser windows.

I tend to prefer to keep everything to 77-79 when I'm actually formatting 
code for releases as opposed to "just don't care".

> And due to popular demand they started to add on to the language
> features: modules, generics, etc..  The language still feels a lot
> less bloated than C++, but IMHO plain old C just feels more natural
> and minimal.

I tend to feel that C strikes a perfect balance between minimalist and 
powerful.

> And because I still program on a lot of old retro systems today I
> returned back to C.  You can use C on pretty much everything -- from
> 8-bit machines to amd64.  You can't say the same about Go.

Same.

I mean, I've started to pick up 8086 assembler, but I can write C, I can 
code for my Apple //e, or I can code for my AMD64 boxen, or for my old 
PS/2, or theoretically for my ancient Macintoshes...or a number of other 
systems.  It's not quite "write once run everywhere", but it's pretty 
close.

-uso.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
@ 2022-02-04  8:26         ` arnold
  2022-02-04 19:41           ` John Cowan
  0 siblings, 1 reply; 75+ messages in thread
From: arnold @ 2022-02-04  8:26 UTC (permalink / raw)
  To: silas8642, arnold; +Cc: tuhs

silas poulson <silas8642@hotmail.co.uk> wrote:

> > FWIW, Brian has told me more than once that he wishes they'd done
> > “Software Tools In C" instead of in Pascal, and that the Pascal book
> > was a failure to read the market correctly.
>
> Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper!
>
> Has Brian ever said what would’ve been different if a C version had
> been written?

No, he has not. I suspect it would have looked like the ratfor code
but with real data structures and recursion, and without the need to
build the standard I/O library (getc, putc, etc.).

Arnold

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  8:10               ` Steve Nickolas
@ 2022-02-04  8:44                 ` markus schnalke
  2022-02-04  9:16                   ` Steve Nickolas
  2022-02-04 18:54                 ` John Cowan
  1 sibling, 1 reply; 75+ messages in thread
From: markus schnalke @ 2022-02-04  8:44 UTC (permalink / raw)
  To: tuhs

Hoi.

[2022-02-04 03:10] Steve Nickolas <usotsuki@buric.co>
> On Fri, 4 Feb 2022, Andy Kosela wrote:
> > 
> > And due to popular demand they started to add on to the language
> > features: modules, generics, etc..  The language still feels a lot
> > less bloated than C++, but IMHO plain old C just feels more natural
> > and minimal.
> 
> I tend to feel that C strikes a perfect balance between minimalist and 
> powerful.

You have to consider that each language is a child of its time;
the culture of each programming language is shaped by the people
who use it, write libraries and books and teach others.

If you would introduce the C language today for the first
time, it wouldn't become the same language that we like. Its
libraries and culture would be very different because today's
programmers are different. Likewise, would Go have been
introduced in older times, it probably would have evolved
differently.

Thus, with liking the minimalist/powerful balance of C and the
style of how programs in C are written (because that C culture
has grown decades ago and is now also a part of the language)
you actually say that you like the old times better than the new
times. (I don't blame you for that.)

This all is much more about culture and what types of people
program and the reasons why they program and the kinds of
projects they do and the kinds of companies and their motivation
in programming and how all this shapes the culture of any
language ... than it is about specific languages itself, IMO.


meillo

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  8:44                 ` markus schnalke
@ 2022-02-04  9:16                   ` Steve Nickolas
  0 siblings, 0 replies; 75+ messages in thread
From: Steve Nickolas @ 2022-02-04  9:16 UTC (permalink / raw)
  To: markus schnalke; +Cc: tuhs

On Fri, 4 Feb 2022, markus schnalke wrote:

> You have to consider that each language is a child of its time;
> the culture of each programming language is shaped by the people
> who use it, write libraries and books and teach others.
>
> If you would introduce the C language today for the first
> time, it wouldn't become the same language that we like. Its
> libraries and culture would be very different because today's
> programmers are different. Likewise, would Go have been
> introduced in older times, it probably would have evolved
> differently.

Probably true.

> Thus, with liking the minimalist/powerful balance of C and the
> style of how programs in C are written (because that C culture
> has grown decades ago and is now also a part of the language)
> you actually say that you like the old times better than the new
> times. (I don't blame you for that.)

Could be that I cut my teeth on an 8-bit computer and did a lot of work on 
16-bit systems, so I'm used to working with limited RAM and CPU.

> This all is much more about culture and what types of people
> program and the reasons why they program and the kinds of
> projects they do and the kinds of companies and their motivation
> in programming and how all this shapes the culture of any
> language ... than it is about specific languages itself, IMO.

There is certainly truth to that.  And even human languages tend to adapt 
in culture-specific ways ("two countries divided by a common language" 
being a common joke about the US versus the UK, for example).

-uso.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [really Rust]
  2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
@ 2022-02-04 13:07               ` Thomas Paulsen
  2022-02-04 23:18               ` Dan Cross
  1 sibling, 0 replies; 75+ messages in thread
From: Thomas Paulsen @ 2022-02-04 13:07 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: tuhs


--- Ursprüngliche Nachricht ---
Von: Jon Steinhart <jon@fourwinds.com>
Datum: 04.02.2022 03:34:40
An: The Eunuchs Hysterical Society <tuhs@tuhs.org>
Betreff: Re: [TUHS] more about Brian... [really Rust]


'Well, I'm not an august personage and am not a Rust programmer.  I did
spend a while trying to learn rust a while ago and wasn't impressed.
...instead of thinking about what one is doing.  I know that that's the
modern definition of programming, but will never be for me.'
check out go(lang), Ken and Rob are involved. 






^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-04  6:06     ` Ori Idan
@ 2022-02-04 17:35       ` Adam Thornton
  2022-02-04 17:44         ` Will Senn
  0 siblings, 1 reply; 75+ messages in thread
From: Adam Thornton @ 2022-02-04 17:35 UTC (permalink / raw)
  To: Ori Idan, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote:

> As for EOF it is 0xFF which is not always -1, depending if your char is
> signed or unsigned.
>
>
Ha!  You fell into my trap!  getc() returns an int!  (I don't know if EOF
is _always_ "all bits set", and even if it is, that's only -1 on a
twos-complement machine, if we want to head off into some real pedantry...)

The need to use feof() and ferror() at least appear in the BUGS section on
my Mac.  Linux is not so gracious.  The real bug, if you ask me, which no
one did, is that getc() and pals return an int rather than a char, which is
surprising and certainly has tripped me up several times across the decades
(and yes, I understand that since any character value is a legal character
to have gotten, you need some other way of signalling an error).

[-- Attachment #2: Type: text/html, Size: 1241 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-04 17:35       ` Adam Thornton
@ 2022-02-04 17:44         ` Will Senn
  0 siblings, 0 replies; 75+ messages in thread
From: Will Senn @ 2022-02-04 17:44 UTC (permalink / raw)
  To: Adam Thornton, Ori Idan, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1522 bytes --]

On 2/4/22 11:35 AM, Adam Thornton wrote:
>
>
> On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote:
>
>     As for EOF it is 0xFF which is not always -1, depending if your
>     char is signed or unsigned.
>
>
> Ha!  You fell into my trap!  getc() returns an int!  (I don't know if 
> EOF is _always_ "all bits set", and even if it is, that's only -1 on a 
> twos-complement machine, if we want to head off into some real 
> pedantry...)
>
> The need to use feof() and ferror() at least appear in the BUGS 
> section on my Mac.  Linux is not so gracious.  The real bug, if you 
> ask me, which no one did, is that getc() and pals return an int rather 
> than a char, which is surprising and certainly has tripped me up 
> several times across the decades (and yes, I understand that since any 
> character value is a legal character to have gotten, you need some 
> other way of signalling an error).
This is prolly why the authors steadfastly refused to commit to a 
particular value for EOF. Instead, they said in essence, that it was a 
matter of agreement, convention, if you will, and that whatever value 
was chosen, it should NEVER be a legal character. I made it -1, for v7, 
cuz it worked... and I wanted so badly to get a working ratfor program 
that I sacrificed any semblance of technical rigor to make it copy a 
character, onscreen, in real time, live. Heck, and it only took me a 
couple of days to figure out all how to get it working, EOF was easy, 
STDIN and STDOUT, not so much.


[-- Attachment #2: Type: text/html, Size: 2854 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04  8:10               ` Steve Nickolas
  2022-02-04  8:44                 ` markus schnalke
@ 2022-02-04 18:54                 ` John Cowan
  2022-02-04 19:45                   ` Thomas Paulsen
  1 sibling, 1 reply; 75+ messages in thread
From: John Cowan @ 2022-02-04 18:54 UTC (permalink / raw)
  To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 714 bytes --]

On Fri, Feb 4, 2022 at 3:20 AM Steve Nickolas <usotsuki@buric.co> wrote:


> > Garbage collector is cool but actually it prevents you from writing
> > kernel or performance critical code, e.g. games.
>

I'm sure kernels with GC are on their way.  I think they already exist in
research contexts.  As for games, the problem seems to be that the market
will not pay enough for hardware to do a good job. so the attitude is "So
what if it crashes, it's just a dumb game."

The last C program I worked on was an interpreter for the Joy language.  It
had a precise GC for objects, but strings were a mess.  I added libgc and
ripped out all the half-assed solutions.  If I had to write C today, I'd
write it with libgc.

[-- Attachment #2: Type: text/html, Size: 1692 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-04  8:26         ` arnold
@ 2022-02-04 19:41           ` John Cowan
  0 siblings, 0 replies; 75+ messages in thread
From: John Cowan @ 2022-02-04 19:41 UTC (permalink / raw)
  To: Aharon Robbins; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

On Fri, Feb 4, 2022 at 3:26 AM <arnold@skeeve.com> wrote:

No, he has not. I suspect it would have looked like the ratfor code
> but with real data structures and recursion, and without the need to
> build the standard I/O library (getc, putc, etc.).
>

See Jez Higgins's STinC++ (Software Tools in C++) project at <
https://www.jezuk.co.uk/tags/software-tools-in-c++.html>.  He's working
from ST in Pascal, but this is a rewrite from scratch, not a translation.
So far he's done Chapters 1, 2, and 5, implementing each tool as he goes.

[-- Attachment #2: Type: text/html, Size: 1188 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 18:54                 ` John Cowan
@ 2022-02-04 19:45                   ` Thomas Paulsen
  2022-02-04 20:28                     ` Hellwig Geisse
  0 siblings, 1 reply; 75+ messages in thread
From: Thomas Paulsen @ 2022-02-04 19:45 UTC (permalink / raw)
  To: John Cowan; +Cc: tuhs

[-- Attachment #1: Type: text/html, Size: 2723 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 19:45                   ` Thomas Paulsen
@ 2022-02-04 20:28                     ` Hellwig Geisse
  2022-02-04 21:03                       ` Jim Capp
                                         ` (2 more replies)
  0 siblings, 3 replies; 75+ messages in thread
From: Hellwig Geisse @ 2022-02-04 20:28 UTC (permalink / raw)
  To: tuhs

Hi Thomas,

On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
> I tell you one thing: I never ever experienced any problems with
> traditional malloc()/free().­

did you ever write a program which does heavy malloc()/free()
on complicated (i.e., shared) data structures *and* runs for
days, perhaps weeks? IMO it's very difficult to do this without
a GC, and you have to exercise quite an amount of discipline
to do it right.

> A kernel using GC is a kernel written by inexperienced kids.

Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990)
used a GC, and it did that quite efficiently.

Hellwig

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 20:28                     ` Hellwig Geisse
@ 2022-02-04 21:03                       ` Jim Capp
  2022-02-04 22:30                         ` Steffen Nurpmeso
  2022-02-04 22:25                       ` Steffen Nurpmeso
  2022-02-06  0:56                       ` Larry McVoy
  2 siblings, 1 reply; 75+ messages in thread
From: Jim Capp @ 2022-02-04 21:03 UTC (permalink / raw)
  To: Hellwig Geisse; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

I have a subsystem that populates a database from disparate data streams. 
It's been known to run for years without restarting, thanks to valgrind. 






From: "Hellwig Geisse" <hellwig.geisse@mni.thm.de> 
To: tuhs@minnie.tuhs.org 
Sent: Friday, February 4, 2022 3:28:10 PM 
Subject: Re: [TUHS] more about Brian... 

Hi Thomas, 

On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: 
> I tell you one thing: I never ever experienced any problems with 
> traditional malloc()/free().­ 

did you ever write a program which does heavy malloc()/free() 
on complicated (i.e., shared) data structures *and* runs for 
days, perhaps weeks? IMO it's very difficult to do this without 
a GC, and you have to exercise quite an amount of discipline 
to do it right. 

> A kernel using GC is a kernel written by inexperienced kids. 

Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) 
used a GC, and it did that quite efficiently. 

Hellwig 

[-- Attachment #2: Type: text/html, Size: 1277 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04  5:11             ` Rich Morin
@ 2022-02-04 21:22               ` Greg A. Woods
  2022-02-04 21:37                 ` Richard Salz
  0 siblings, 1 reply; 75+ messages in thread
From: Greg A. Woods @ 2022-02-04 21:22 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- Attachment #1: Type: text/plain, Size: 4268 bytes --]

I find programming in Go to be an extremely fun, and usually relatively
easy thing to do, and it's never boring or tedious (though when learning
some new idiom or technique or library it can be challenging, but that's
a good thing).

Maybe writing tests can be tedious at times, but it's also very
satisfying, and quite easy to do with the support in the Go environment.

At Thu, 3 Feb 2022 21:11:14 -0800, Rich Morin <rdm@cfcl.com> wrote:
Subject: Re: [TUHS] more about Brian...
>
> Another problem I have with Go is the concurrency model.  First,
> it uses threads, which I've never felt competent to use safely.
> Shared mutable state is one of those things that seem to me like
> an accident waiting to happen.  Also, though I have no real
> experience with CSP, it seems like the Actor model may be better
> suited to exploratory programming.

Go's concurrency model was a lot easier for me after I spent some time
working in a C environment that transparently supported working with
either proper threads (with the target system's libpthread as the
underlying implementation) or coroutines (with libcoro as the underlying
implementation).  Valgrind was my friend for finding races and other
things one should not do in a threaded program.

> Getting back to Rust, my impression is that its design assumes
> that having the computer put up guard rails will (mostly) keep
> programmers from making catastrophic mistakes.  In contrast, the
> Erlang (and thus Elixir) approach assumes that things WILL crash
> and that the important thing is to make sure that the system as a
> whole keeps running smoothly.  So, for example, it provides
> supervision trees which can handle any crash of an Actor, etc.

I find Rust to be appalling and very very very unappealing (to me).

It's C++ for Perl programmers -- and all the bad parts/warts of both.

Rust is, to me, ugly, inelegant, and hard to read and reason about.


I still work on and write lots of C, but I'm very tired of UB.  I want a
C-like language (in that it's close the metal/SiO2) and that has
absolutely zero UB in the spec.  None.  Everything MUST be defined
behaviour.

There are a couple of "new" languages in my sights (for applications
where Go might not be ideal):

- Drew Devault's secret new language:  https://drewdevault.com/

- Zig -- http://ziglang.org/ (by Andrew Kelley)

  ready and running, apparently.  BUT oh, gawd -- it's currently written
  in C++ and uses CMake (though apparently comes with its own built-in
  build system so that Zig programs don't need anything like CMake, etc.)

- Jai:  imperative static/strongly typed C-style language
  by Jonathan Loom

	https://inductive.no/jai/
	https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

  No implicit type conversions
  No header files
  Beautiful and elegant.
  Built-in build system.
  Jai code can be built on top of existing C libraries

- V -- https://vlang.io

  Perhaps the most mature of the lot.


But I would also be happy with just plain old C (though perhaps C99 not
C11), with all the UB caveats nailed down into Defined Behaviour.  The
authors and maintainers of modern compilers are not really truly sane.
They most certainly should not be allowed to exploit UB, especially not
behind the user's back as they mostly do now.

C's primitive nature engenders the programmer to think in terms of what
the target machine is going to do, and as such it is extremely sad and
disheartening that the standards committee chose to endanger C's users
in so many ways.  As Phil Pennock said:

    If I program in C, I need to defend against the compiler maintainers.
        [[ and future standards committee members!!! ]]
    If I program in Go, the language maintainers defend me from my mistakes.

And I say:

	Modern "Standard C" is actually "Useless C" and "Unusable C"

(especially if one does not fully embrace tools like Valgrind and enable
all compiler features that point out UB in all possible ways at all
times)


BTW, there's also a new scripting language I've got on my stack to
investigate further:

	    https://wren.io

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
@ 2022-02-04 21:37                 ` Richard Salz
  2022-02-04 22:32                   ` Steffen Nurpmeso
                                     ` (2 more replies)
  0 siblings, 3 replies; 75+ messages in thread
From: Richard Salz @ 2022-02-04 21:37 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- Attachment #1: Type: text/plain, Size: 123 bytes --]

I really wish there were a manpage that says "foo is the one true language"
just like ed(1).  Then this thread would stop.

[-- Attachment #2: Type: text/html, Size: 182 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 20:28                     ` Hellwig Geisse
  2022-02-04 21:03                       ` Jim Capp
@ 2022-02-04 22:25                       ` Steffen Nurpmeso
  2022-02-06  0:56                       ` Larry McVoy
  2 siblings, 0 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2022-02-04 22:25 UTC (permalink / raw)
  To: Hellwig Geisse; +Cc: tuhs

Hellwig Geisse wrote in
 <1644006490.2458.78.camel@mni.thm.de>:
 |Hi Thomas,
 |
 |On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
 |> I tell you one thing: I never ever experienced any problems with
 |> traditional malloc()/free().
 |
 |did you ever write a program which does heavy malloc()/free()
 |on complicated (i.e., shared) data structures *and* runs for
 |days, perhaps weeks? IMO it's very difficult to do this without

Yes.

 |a GC, and you have to exercise quite an amount of discipline
 |to do it right.

And i fail to see the relationship really.
Especially given that all kernels and all daemons i know (he!) are
all written in C.

Object based programming is surely easier to manage, as containers
manage containers manage containers manage whatever allocations.
So you have a very natural chain of life, so to say.

 |> A kernel using GC is a kernel written by inexperienced kids.
 |
 |Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990)
 |used a GC, and it did that quite efficiently.

Well i have no idea of that also really, so i am not saying
anything.  I never liked GC; i looked at the source of "that" C GC
however (yes, i have forgotten the name).

It maybe different to languages like Nim or Lua or, sigh, JAVA, Go
and such environments etc., where possibly every object is
reference counted.  And that where recursive mutexes are declared
evil for performance reasons, and kernel code is full of
ASSERT(is_locked()) stuff.
But this is speculative execution and thus far out of my league.

--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)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 21:03                       ` Jim Capp
@ 2022-02-04 22:30                         ` Steffen Nurpmeso
  0 siblings, 0 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2022-02-04 22:30 UTC (permalink / raw)
  To: Jim Capp; +Cc: tuhs

Jim Capp wrote in
 <8901533.793.1644008621545.JavaMail.root@zimbraanteil>:
 |I have a subsystem that populates a database from disparate data streams. 
 |It's been known to run for years without restarting, thanks to valgrind. 

Oh please, not.  Have they fixed their file descriptor problems?
Just go a bit and your allocator will tell you what there still
is, and where it came from.
I mean gigantic billions of modules plugged together to form
a brilliant whole that is larger than its particels may be harder.

  $ prt-get quickdep libreoffice
  libnghttp2 openssl zlib xz expat jsoncpp attr bzip2 lzo libuv lzlib ncurses rhash ninja libffi libnsl libtirpc mpdecimal xorg-util-macros libgmp chrpath fakeroot giflib libpcre kmod db nasm xorg-libpciaccess xorg-libpixman libspiro libuninameslist libgpg-error linux-pam npth alsa-lib libogg libvisual opus hyphen icu cppunit glm libexttextcat hunspell libnumbertext libpaper libqrcodegen libtommath lpsolve libaio libpcre2 nspr libtool unzip file libpng potrace zstd libxml2 dbus neon acl elfutils zip readline xorg-xtrans glpk libmpfr swig eudev libgcrypt libksba libassuan libcap libvorbis libmythes curl boost libxslt libarchive gdbm sqlite3 unixodbc gcc-fortran util-linux libusb libtheora librevenge mdds raptor xmlsec cmake perl python3 nss openblas pinentry libabw libepubgen libwpd libmwaw libodfgen libpagemaker libqxp libstaroffice libvisio libwps libzmf rasqal abseil-cpp clucene metis libjpeg-turbo brotli libcuckoo fmt mariadb p5-xml-parser python3-setuptools xorg-xcb-proto lapack gnupg libmspub libwpg redland libtiff woff2 spdlog intltool meson python3-libxml2 llvm python3-markupsafe python3-chardet python3-soupsieve python3-cssselect python3-cython python3-webencodings coin-or-coinutils suitesparse gpgme libwebp lcms2 sane libixion xorg-xorgproto glib libdrm fribidi freetype orc itstool python3-mako python3-beautifulsoup4 python3-html5lib coin-or-osi libcdr libfreehand openjpeg2 liborcus xorg-libxau xorg-libxdmcp xorg-libxshmfence xorg-libice gobject-introspection liblangtag fontconfig graphite2 shared-mime-info python3-lxml coin-or-clp xorg-libxcb xorg-libsm atk graphene gstreamer libgudev libe-book libetonyek gdk-pixbuf coin-or-cgl xorg-libx11 xorg-xcb-util coin-or-cbc xorg-libxext xorg-libxfixes xorg-libxrender coin-or-mp xorg-libxinerama libglvnd xorg-libxv xorg-libxxf86vm xorg-libxi xorg-libxdamage xorg-libxcomposite xorg-libxcursor xorg-libxrandr cairo gl-headers xorg-libxvmc xorg-libxtst box2d harfbuzz mesa at-spi2-core xorg-libxft libepoxy at-spi2-atk pango gtk3 gst-plugins-base fontforge libreoffice

It could be this requires a bit of work.

--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)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04 21:37                 ` Richard Salz
@ 2022-02-04 22:32                   ` Steffen Nurpmeso
  2022-02-04 23:05                   ` Thomas Paulsen
  2022-02-04 23:15                   ` Seth J. Morabito
  2 siblings, 0 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2022-02-04 22:32 UTC (permalink / raw)
  To: Richard Salz; +Cc: The Unix Heritage Society mailing list

Richard Salz wrote in
 <CAFH29tpSUoQ08vfVJKgBqV54CAq_vHX6-Y5mfmaOxEP73mtz4A@mail.gmail.com>:
 |I really wish there were a manpage that says "foo is the one true language"
 |just like ed(1).  Then this thread would stop.

 |I really wish there were a manpage that says "foo is the one true langua\
 |ge" just like ed(1).  Then this thread would stop.

Manpages are second class citizens.

--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)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04 21:37                 ` Richard Salz
  2022-02-04 22:32                   ` Steffen Nurpmeso
@ 2022-02-04 23:05                   ` Thomas Paulsen
  2022-02-04 23:15                   ` Seth J. Morabito
  2 siblings, 0 replies; 75+ messages in thread
From: Thomas Paulsen @ 2022-02-04 23:05 UTC (permalink / raw)
  To: Richard Salz; +Cc: tuhs

[-- Attachment #1: Type: text/html, Size: 1660 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04 21:37                 ` Richard Salz
  2022-02-04 22:32                   ` Steffen Nurpmeso
  2022-02-04 23:05                   ` Thomas Paulsen
@ 2022-02-04 23:15                   ` Seth J. Morabito
  2022-02-05  1:41                     ` Adam Thornton
  2 siblings, 1 reply; 75+ messages in thread
From: Seth J. Morabito @ 2022-02-04 23:15 UTC (permalink / raw)
  To: tuhs


Richard Salz <rich.salz@gmail.com> writes:

> I really wish there were a manpage that says "foo is the one true
> language" just like ed(1).  Then this thread would stop.

[...]
  -rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
  -rwxr-xr-t  4 root     1310720 Jan  1  1970 /usr/ucb/vi
  -rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs
[...]


Of course, the wonderful thing about programming languages is that, like
editors, there are so many to choose from and everyone can find one that
they find enjoyment using.

I really like C, and Rust, and Haskell, and Lisp, and Python, and
Erlang, and many others. Some others I enjoy quite a bit less than
these. And all of them can be used to write good programs and bad
programs.

-Seth
-- 
Seth Morabito
web@loomcom.com
Poulsbo, WA, USA

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [really Rust]
  2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
  2022-02-04 13:07               ` Thomas Paulsen
@ 2022-02-04 23:18               ` Dan Cross
  1 sibling, 0 replies; 75+ messages in thread
From: Dan Cross @ 2022-02-04 23:18 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: COFF

[-- Attachment #1: Type: text/plain, Size: 10779 bytes --]

[TUHS to Bcc, +COFF <coff@minnie.tuhs.org> ]

This isn't exactly COFF material, but I don't know what list is more
appropriate.

On Thu, Feb 3, 2022 at 9:41 PM Jon Steinhart <jon@fourwinds.com> wrote:

> Adam Thornton writes:
> > Do the august personages on this list have opinions about Rust?
> > People who generally have tastes consonant with mine tell me I'd like
> Rust.
>
> Well, I'm not an august personage and am not a Rust programmer.  I did
> spend a while trying to learn rust a while ago and wasn't impressed.
>
> Now, I'm heavily biased in that I think that it doesn't add value to keep
> inventing new languages to do the same old things, and I didn't see
> anything
> in Rust that I couldn't do in a myriad of other languages.
>

I'm a Rust programmer, mostly using it for bare-metal kernel programming
(though in my current gig, I find myself mostly in Rust
userspace...ironically, it's back to C for the kernel). That said, I'm not
a fan-boy for the language: it's not perfect.

I've written basically four kernels in Rust now, to varying degrees of
complexity from, "turn the computer on, spit hello-world out of the UART,
and halt" to most of a v6 clone (which I really need to get around to
finishing) to two rather more complex ones. I've done one ersatz kernel in
C, and worked on a bunch more in C over the years. Between the two
languages, I'd pick Rust over C for similar projects.

Why? Because it really doesn't just do the same old things: it adds new
stuff. Honest!

Further, the sad reality (and the tie-in with TUHS/COFF) is that modern C
has strayed far from its roots as a vehicle for systems programming, in
particular, for implementing operating system kernels (
https://arxiv.org/pdf/2201.07845.pdf). C _implementations_ target the
abstract machine defined in the C standard, not hardware, and they use
"undefined behavior" as an excuse to make aggressive optimizations that
change the semantics of one's program in such a way that some of the tricks
you really do have to do when implementing an OS are just not easily done.
For example, consider this code:

uint16_t mul(uint16_t a, uint16_t b) { return a * b; }

Does that code ever exhibit undefined behavior? The answer is that "it
depends, but on most platforms, yes." Why? Because most often uint16_t is a
typedef for `unsigned short int`, and because `short int` is of lesser
"rank" than `int` and usually not as wide, the "usual arithmetic
conversions" will apply before the multiplication. This means that the
unsigned shorts will be converted to (signed) int. But on many
platforms `int` will be a 32-bit integer (even 64-bit platforms!). However,
the range of an unsigned 16-bit integer is such that the product of two
uint16_t's can include values whose product is larger than whatever is
representable in a signed 32-bit int, leading to overflow, and signed
integer overflow is undefined overflow is undefined behavior. But does that
_matter_ in practice? Potentially: since signed int overflow is UB, the
compiler can decide it would never happen. And so if the compiler decides,
for whatever reason, that (say) a saturating multiplication is the best way
to implement that multiplication, then that simple single-expression
function will yield results that (I'm pretty sure...) the programmer did
not anticipate for some subset of inputs. How do you fix this?

uint16_t mul(uint16_t a, uint16_t b) { unsigned int aa = a, bb = b; return
aa * bb; }

That may sound very hypothetical, but similar things have shown up in the
wild: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf

In practice, this one is unlikely. But it's not impossible: the compiler
would be right, the programmer would be wrong. One thing I've realized
about C is that successive generations of compilers have tightened the
noose on UB so that code that has worked for *years* all of a sudden breaks
one day. There be dragons in our code.

After being bit one too many times by such issues in C I decided to
investigate alternatives. The choices at the time were either Rust or Go:
for the latter, one gets a nice, relatively simple language, but a big
complex runtime. For the former, you get a big, ugly language, but a
minimal runtime akin to C: to get it going, you really don't have to do
much more than set up a stack and join to a function. While people have
built systems running Go at the kernel level (
https://pdos.csail.mit.edu/papers/biscuit.pdf), that seemed like a pretty
heavy lift. On the other hand, if Rust could deliver on a quarter of the
promises it made, I'd be ahead of the game. That was sometime in the latter
half of 2018 and since then I've generally been pleasantly surprised at how
much it really does deliver.

For the above example, integer overflow is defined to trap. If you want
wrapping (or saturating!) semantics, you request those explicitly:

fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) }

This is perfectly well-defined, and guaranteed to work pretty much forever.

But, my real issue came from some of the tutorials that I perused.  Rust is
> being sold as "safer".  As near as I can tell from the tutorials, the model
> is that nothing works unless you enable it.  Want to be able to write a
> variable?  Turn that on.  So it seemed like the general style was to write
> code and then turn various things on until it ran.
>

That's one way to look at it, but I don't think that's the intent: the
model is rather, "immutable by default."

Rust forces you to think about mutability, ownership, and the semantics of
taking references, because the compiler enforces invariants on all of those
things in a way that pretty much no other language does. It is opinionated,
and not shy about sharing those opinions.

To me, this implies a mindset that programming errors are more important
> than thinking errors, and that one should hack on things until they work
> instead of thinking about what one is doing.  I know that that's the
> modern definition of programming, but will never be for me.


It's funny, I've had the exact opposite experience.

I have found that it actually forces you to invest a _lot_ more in-up front
thought about what you're doing. Writing code first, and then sprinkling in
`mut` and `unsafe` until it compiles is a symptom of writing what we called
"crust" on my last project at Google: that is, "C in Rust syntax." When I
convinced our team to switch from C(++) to Rust, but none of us were really
particularly adept at the language, and all hit similar walls of
frustration; at one point, an engineer quipped, "this language has a
near-vertical learning curve." And it's true that we took a multi-week
productivity hit, but once we reached a certain level of familiarity,
something equally curious happened: our debugging load went way, _way_ down
and we started moving much faster.

It turned out it was harder to get a Rust program to build at first,
particularly with the bad habits we'd built up over decades of whatever
languages we came from, but once it did those programs very often ran
correctly the first time. You had to think _really hard_ about what data
structures to use, their ownership semantics, their visibility, locking,
etc. A lot of us had to absorb an emotional gut punch when the compiler
showed us things that we _knew_ were correct were, in fact, not correct.
But once code compiled, it tended not to have the kinds of errors that were
insta-panics or triple faults (or worse, silent corruption you only noticed
a million instructions later): no dangling pointers, no use-after-free
bugs, no data races, no integer overflow, no out-of-bounds array
references, etc. Simply put, the language _forced_ a level of discipline on
us that even veteran C programmers didn't have.

It also let us program at a moderately higher level of abstraction;
off-by-one errors were gone because we had things like iterators. ADTs and
a "Maybe" monad (the `Result<T,E>` type) greatly improved our error
handling. `match` statements have to be exhaustive so you can't add a
variant to an enum and forget to update code to account in just that one
place (the compiler squawks at you). It's a small point, but the `?`
operator removed a lot of tedious boilerplate from our code, making things
clearer without sacrificing robust failure handling. Tuples for multiple
return values instead of using pointers for output arguments (that have to
be manually checked for validity!) are really useful. Pattern matching and
destructuring in a fast systems language? Good to go.

In contrast, I ran into a "bug" of sorts with KVM due to code I wrote that
manifested itself as an "x86 emulation error" when it was anything but: I
was turning on paging very early in boot, and I had manually set up an
identity mapping for the low 4GiB of address space for the jump from 32-bit
to 64-bit mode. I used gigabyte pages since it was easy, and I figured it
would be supported, but I foolishly didn't check the CPU features when
running this under virtualization for testing and got that weird KVM error.
What was going on? It turned out KVM in this case didn't support gig pages,
but the hardware did; the software worked just fine until the first time
the kernel went to do IO. Then, when the hypervisor went to fetch the
instruction bytes to emulate the IO instruction, it saw the gig-sized pages
and errored. Since the incompatibility was manifest deep in the bowels of
the instruction emulation code, that was the error that returned, even
though it had nothing to do with instruction emulation. It would have been
nice to plumb through some kind of meaningful error message, but in C
that's annoying at best. In Rust, it's trivial.
https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/

70% of CVEs out of Microsoft over the last 15 years have been memory safety
issues, and while we may poo-poo MSFT, they've got some really great
engineers and let's be honest: Unix and Linux aren't that much better in
this department. Our best and brightest C programmers continue to turn out
highly buggy programs despite 50 years of experience.

But it's not perfect. The allocator interface was a pain (it's defined to
panic on allocation failure; I'm cool with a NULL return), though work is
ongoing in this area. There's no ergonomic way to initialize an object
'in-place' (https://mcyoung.xyz/2021/04/26/move-ctors/), and there's no
great way to say, essentially, "this points at RAM; even though I haven't
initialized it, just trust me don't poison it" (
https://users.rust-lang.org/t/is-it-possible-to-read-uninitialized-memory-without-invoking-ub/63092
-- we really need a `freeze` operation). However, right now? I think it
sits at a local maxima for systems languages targeting bare-metal.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 12941 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...)
  2022-02-04 23:15                   ` Seth J. Morabito
@ 2022-02-05  1:41                     ` Adam Thornton
  0 siblings, 0 replies; 75+ messages in thread
From: Adam Thornton @ 2022-02-05  1:41 UTC (permalink / raw)
  To: Seth J. Morabito, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

I've written COBOL for money.  I'm not proud of it but I won't deny it.
I've written Python, C, Perl, and Go (and doubtless some others) for both
love and money at different times.  I've written LISP (well, Scheme) for a
grade and for love.  I've written Inform 6 and 7, and 6502 assembler, and a
bunch of other things, just for love.  I am sure I couldn't stop writing
programs if I had to.

As Emmylou Harris sang:

Well, I did it for kicks and I did it for hate
I did it for lust and I did it for faith
I did it for need and I did it for love
Addiction stayed on tight like a glove

On Fri, Feb 4, 2022 at 4:22 PM Seth J. Morabito <web@loomcom.com> wrote:

>
> I really like C, and Rust, and Haskell, and Lisp, and Python, and
> Erlang, and many others.

[-- Attachment #2: Type: text/html, Size: 1249 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-04 20:28                     ` Hellwig Geisse
  2022-02-04 21:03                       ` Jim Capp
  2022-02-04 22:25                       ` Steffen Nurpmeso
@ 2022-02-06  0:56                       ` Larry McVoy
  2022-02-06  1:10                         ` Will Senn
  2 siblings, 1 reply; 75+ messages in thread
From: Larry McVoy @ 2022-02-06  0:56 UTC (permalink / raw)
  To: Hellwig Geisse; +Cc: tuhs

On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
> Hi Thomas,
> 
> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
> > I tell you one thing: I never ever experienced any problems with
> > traditional malloc()/free().??
> 
> did you ever write a program which does heavy malloc()/free()
> on complicated (i.e., shared) data structures *and* runs for
> days, perhaps weeks? IMO it's very difficult to do this without
> a GC, and you have to exercise quite an amount of discipline
> to do it right.

I've done this and I've employed people who have done this.  We're
a dieing breed, the focus seems to be on programming languages and
tools for idiots.  People don't want to learn the discipline it takes
to work with malloc()/free().  It's sad.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  0:56                       ` Larry McVoy
@ 2022-02-06  1:10                         ` Will Senn
  2022-02-06  4:52                           ` Rob Pike
  2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
  0 siblings, 2 replies; 75+ messages in thread
From: Will Senn @ 2022-02-06  1:10 UTC (permalink / raw)
  To: Larry McVoy, Hellwig Geisse; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1327 bytes --]

On 2/5/22 6:56 PM, Larry McVoy wrote:
> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>> Hi Thomas,
>>
>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>>> I tell you one thing: I never ever experienced any problems with
>>> traditional malloc()/free().??
>> did you ever write a program which does heavy malloc()/free()
>> on complicated (i.e., shared) data structures *and* runs for
>> days, perhaps weeks? IMO it's very difficult to do this without
>> a GC, and you have to exercise quite an amount of discipline
>> to do it right.
> I've done this and I've employed people who have done this.  We're
> a dieing breed, the focus seems to be on programming languages and
> tools for idiots.  People don't want to learn the discipline it takes
> to work with malloc()/free().  It's sad.

I completely agree. This is ridiculous. Do modern programmer's seriously 
think that the old code wasn't complex or robust? Sheesh, there's code 
out there that has run through more millions of transactions an hour for 
more years than most of these folks have been alive. There's also code 
that's been running without any updates, for decades. Most code written 
by the newbreed won't run for a month without surfacing dozens of bugs. 
Margaret Hamilton would prolly have some choice words for these folks.


[-- Attachment #2: Type: text/html, Size: 2034 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  1:10                         ` Will Senn
@ 2022-02-06  4:52                           ` Rob Pike
  2022-02-06  4:58                             ` Dan Halbert
                                               ` (2 more replies)
  2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
  1 sibling, 3 replies; 75+ messages in thread
From: Rob Pike @ 2022-02-06  4:52 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2294 bytes --]

Be careful with your castigations. Yes, there is lots of old working code,
but keep in mind that that code has often not been as widely tested and
deployed as much of the software that runs today. The fact that it worked
well on old hardware doesn't mean it will be suitable for modern networked
remotely administered multicore machines pounded on by millions of people.

And speaking of multicore, it's possible to write code using malloc/free
that doesn't leak when run concurrently, but it's a lot easier, safer, and
robust to let the machine do the memory accounting. And the fact that "kids
today" can't do it doesn't mean they are lazy or failures, it means they
grew up in a different time. And a lot of them are as capable as you all,
just in a different environment.

Lately this list has a lot of attitude and prejudice pretending to be
wisdom and superiority.

-rob


On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:

> On 2/5/22 6:56 PM, Larry McVoy wrote:
>
> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>
> Hi Thomas,
>
> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>
> I tell you one thing: I never ever experienced any problems with
> traditional malloc()/free().??
>
> did you ever write a program which does heavy malloc()/free()
> on complicated (i.e., shared) data structures *and* runs for
> days, perhaps weeks? IMO it's very difficult to do this without
> a GC, and you have to exercise quite an amount of discipline
> to do it right.
>
> I've done this and I've employed people who have done this.  We're
> a dieing breed, the focus seems to be on programming languages and
> tools for idiots.  People don't want to learn the discipline it takes
> to work with malloc()/free().  It's sad.
>
>
> I completely agree. This is ridiculous. Do modern programmer's seriously
> think that the old code wasn't complex or robust? Sheesh, there's code out
> there that has run through more millions of transactions an hour for more
> years than most of these folks have been alive. There's also code that's
> been running without any updates, for decades. Most code written by the
> newbreed won't run for a month without surfacing dozens of bugs. Margaret
> Hamilton would prolly have some choice words for these folks.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3154 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  4:52                           ` Rob Pike
@ 2022-02-06  4:58                             ` Dan Halbert
  2022-02-06  5:06                             ` Will Senn
  2022-02-06  6:19                             ` Ed Carp
  2 siblings, 0 replies; 75+ messages in thread
From: Dan Halbert @ 2022-02-06  4:58 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 2632 bytes --]

  Thank you, Rob. I composed a similar reply, and debated whether to 
send it. You hit all the right points more succinctly and directly. --Dan H.

On 2/5/22 23:52, Rob Pike wrote:
> Be careful with your castigations. Yes, there is lots of old working 
> code, but keep in mind that that code has often not been as widely 
> tested and deployed as much of the software that runs today. The fact 
> that it worked well on old hardware doesn't mean it will be suitable 
> for modern networked remotely administered multicore machines pounded 
> on by millions of people.
>
> And speaking of multicore, it's possible to write code using 
> malloc/free that doesn't leak when run concurrently, but it's a lot 
> easier, safer, and robust to let the machine do the memory accounting. 
> And the fact that "kids today" can't do it doesn't mean they are lazy 
> or failures, it means they grew up in a different time. And a lot of 
> them are as capable as you all, just in a different environment.
>
> Lately this list has a lot of attitude and prejudice pretending to be 
> wisdom and superiority.
>
> -rob
>
>
> On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
>
>     On 2/5/22 6:56 PM, Larry McVoy wrote:
>>     On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>>>     Hi Thomas,
>>>
>>>     On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>>>>     I tell you one thing: I never ever experienced any problems with
>>>>     traditional malloc()/free().??
>>>     did you ever write a program which does heavy malloc()/free()
>>>     on complicated (i.e., shared) data structures *and* runs for
>>>     days, perhaps weeks? IMO it's very difficult to do this without
>>>     a GC, and you have to exercise quite an amount of discipline
>>>     to do it right.
>>     I've done this and I've employed people who have done this.  We're
>>     a dieing breed, the focus seems to be on programming languages and
>>     tools for idiots.  People don't want to learn the discipline it takes
>>     to work with malloc()/free().  It's sad.
>
>     I completely agree. This is ridiculous. Do modern programmer's
>     seriously think that the old code wasn't complex or robust?
>     Sheesh, there's code out there that has run through more millions
>     of transactions an hour for more years than most of these folks
>     have been alive. There's also code that's been running without any
>     updates, for decades. Most code written by the newbreed won't run
>     for a month without surfacing dozens of bugs. Margaret Hamilton
>     would prolly have some choice words for these folks.
>
>

[-- Attachment #2: Type: text/html, Size: 4193 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  4:52                           ` Rob Pike
  2022-02-06  4:58                             ` Dan Halbert
@ 2022-02-06  5:06                             ` Will Senn
  2022-02-06  6:19                             ` Ed Carp
  2 siblings, 0 replies; 75+ messages in thread
From: Will Senn @ 2022-02-06  5:06 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2588 bytes --]

Sure. It's gone off topic, quite a ways. I wasn't really castigating, 
just marveling at the hubris.

On 2/5/22 10:52 PM, Rob Pike wrote:
> Be careful with your castigations. Yes, there is lots of old working 
> code, but keep in mind that that code has often not been as widely 
> tested and deployed as much of the software that runs today. The fact 
> that it worked well on old hardware doesn't mean it will be suitable 
> for modern networked remotely administered multicore machines pounded 
> on by millions of people.
>
> And speaking of multicore, it's possible to write code using 
> malloc/free that doesn't leak when run concurrently, but it's a lot 
> easier, safer, and robust to let the machine do the memory accounting. 
> And the fact that "kids today" can't do it doesn't mean they are lazy 
> or failures, it means they grew up in a different time. And a lot of 
> them are as capable as you all, just in a different environment.
>
> Lately this list has a lot of attitude and prejudice pretending to be 
> wisdom and superiority.
>
> -rob
>
>
> On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
>
>     On 2/5/22 6:56 PM, Larry McVoy wrote:
>>     On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>>>     Hi Thomas,
>>>
>>>     On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>>>>     I tell you one thing: I never ever experienced any problems with
>>>>     traditional malloc()/free().??
>>>     did you ever write a program which does heavy malloc()/free()
>>>     on complicated (i.e., shared) data structures *and* runs for
>>>     days, perhaps weeks? IMO it's very difficult to do this without
>>>     a GC, and you have to exercise quite an amount of discipline
>>>     to do it right.
>>     I've done this and I've employed people who have done this.  We're
>>     a dieing breed, the focus seems to be on programming languages and
>>     tools for idiots.  People don't want to learn the discipline it takes
>>     to work with malloc()/free().  It's sad.
>
>     I completely agree. This is ridiculous. Do modern programmer's
>     seriously think that the old code wasn't complex or robust?
>     Sheesh, there's code out there that has run through more millions
>     of transactions an hour for more years than most of these folks
>     have been alive. There's also code that's been running without any
>     updates, for decades. Most code written by the newbreed won't run
>     for a month without surfacing dozens of bugs. Margaret Hamilton
>     would prolly have some choice words for these folks.
>
>

[-- Attachment #2: Type: text/html, Size: 4150 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  4:52                           ` Rob Pike
  2022-02-06  4:58                             ` Dan Halbert
  2022-02-06  5:06                             ` Will Senn
@ 2022-02-06  6:19                             ` Ed Carp
  2022-02-06  6:27                               ` Rob Pike
  2 siblings, 1 reply; 75+ messages in thread
From: Ed Carp @ 2022-02-06  6:19 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

"it's a lot easier, safer, and robust to let the machine do the memory
accounting"

I disagree. "The machine" is, as you know, is in reality app code
built on top of frameworks built on top of libraries built on top of
more libraries built on top of malloc/free calls. While the automated
testing tools are a lot better than they were when I started coding C
back in 1985, we're still talking about a *lot* of complexity and a
lot of layers of code, and programmers today know far less about
things like boundary conditions, off-by-one bugs, and the like that
bit us in the ass - hard - and so we learned to watch for those sorts
of things.

On 2/5/22, Rob Pike <robpike@gmail.com> wrote:
> Be careful with your castigations. Yes, there is lots of old working code,
> but keep in mind that that code has often not been as widely tested and
> deployed as much of the software that runs today. The fact that it worked
> well on old hardware doesn't mean it will be suitable for modern networked
> remotely administered multicore machines pounded on by millions of people.
>
> And speaking of multicore, it's possible to write code using malloc/free
> that doesn't leak when run concurrently, but it's a lot easier, safer, and
> robust to let the machine do the memory accounting. And the fact that "kids
> today" can't do it doesn't mean they are lazy or failures, it means they
> grew up in a different time. And a lot of them are as capable as you all,
> just in a different environment.
>
> Lately this list has a lot of attitude and prejudice pretending to be
> wisdom and superiority.
>
> -rob
>
>
> On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
>
>> On 2/5/22 6:56 PM, Larry McVoy wrote:
>>
>> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>>
>> Hi Thomas,
>>
>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>>
>> I tell you one thing: I never ever experienced any problems with
>> traditional malloc()/free().??
>>
>> did you ever write a program which does heavy malloc()/free()
>> on complicated (i.e., shared) data structures *and* runs for
>> days, perhaps weeks? IMO it's very difficult to do this without
>> a GC, and you have to exercise quite an amount of discipline
>> to do it right.
>>
>> I've done this and I've employed people who have done this.  We're
>> a dieing breed, the focus seems to be on programming languages and
>> tools for idiots.  People don't want to learn the discipline it takes
>> to work with malloc()/free().  It's sad.
>>
>>
>> I completely agree. This is ridiculous. Do modern programmer's seriously
>> think that the old code wasn't complex or robust? Sheesh, there's code
>> out
>> there that has run through more millions of transactions an hour for more
>> years than most of these folks have been alive. There's also code that's
>> been running without any updates, for decades. Most code written by the
>> newbreed won't run for a month without surfacing dozens of bugs. Margaret
>> Hamilton would prolly have some choice words for these folks.
>>
>>
>>
>

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:19                             ` Ed Carp
@ 2022-02-06  6:27                               ` Rob Pike
  2022-02-06  6:40                                 ` Stuart Remphrey
                                                   ` (3 more replies)
  0 siblings, 4 replies; 75+ messages in thread
From: Rob Pike @ 2022-02-06  6:27 UTC (permalink / raw)
  To: Ed Carp; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 3980 bytes --]

I don't understand your disagreement. In what way is automatic memory
management harder, more unsafe, and less robust than hand-written memory
management using malloc and free?

You seem to think that garbage collection only exists in languages that
have a smell you don't like. Perhaps that's true, but it's been around for
60 or more years and a lot of important languages use it, while the
programmers that use those languages are often quite capable.

Using malloc and free might be a badge of honor to some, but it's also a
failure of automation.

This discussion should probably go to COFF, or perhaps I should just leave
the list. I am starting to feel uncomfortable here. Too much swagger.

-rob


On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote:

> "it's a lot easier, safer, and robust to let the machine do the memory
> accounting"
>
> I disagree. "The machine" is, as you know, is in reality app code
> built on top of frameworks built on top of libraries built on top of
> more libraries built on top of malloc/free calls. While the automated
> testing tools are a lot better than they were when I started coding C
> back in 1985, we're still talking about a *lot* of complexity and a
> lot of layers of code, and programmers today know far less about
> things like boundary conditions, off-by-one bugs, and the like that
> bit us in the ass - hard - and so we learned to watch for those sorts
> of things.
>
> On 2/5/22, Rob Pike <robpike@gmail.com> wrote:
> > Be careful with your castigations. Yes, there is lots of old working
> code,
> > but keep in mind that that code has often not been as widely tested and
> > deployed as much of the software that runs today. The fact that it worked
> > well on old hardware doesn't mean it will be suitable for modern
> networked
> > remotely administered multicore machines pounded on by millions of
> people.
> >
> > And speaking of multicore, it's possible to write code using malloc/free
> > that doesn't leak when run concurrently, but it's a lot easier, safer,
> and
> > robust to let the machine do the memory accounting. And the fact that
> "kids
> > today" can't do it doesn't mean they are lazy or failures, it means they
> > grew up in a different time. And a lot of them are as capable as you all,
> > just in a different environment.
> >
> > Lately this list has a lot of attitude and prejudice pretending to be
> > wisdom and superiority.
> >
> > -rob
> >
> >
> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
> >
> >> On 2/5/22 6:56 PM, Larry McVoy wrote:
> >>
> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
> >>
> >> Hi Thomas,
> >>
> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
> >>
> >> I tell you one thing: I never ever experienced any problems with
> >> traditional malloc()/free().??
> >>
> >> did you ever write a program which does heavy malloc()/free()
> >> on complicated (i.e., shared) data structures *and* runs for
> >> days, perhaps weeks? IMO it's very difficult to do this without
> >> a GC, and you have to exercise quite an amount of discipline
> >> to do it right.
> >>
> >> I've done this and I've employed people who have done this.  We're
> >> a dieing breed, the focus seems to be on programming languages and
> >> tools for idiots.  People don't want to learn the discipline it takes
> >> to work with malloc()/free().  It's sad.
> >>
> >>
> >> I completely agree. This is ridiculous. Do modern programmer's seriously
> >> think that the old code wasn't complex or robust? Sheesh, there's code
> >> out
> >> there that has run through more millions of transactions an hour for
> more
> >> years than most of these folks have been alive. There's also code that's
> >> been running without any updates, for decades. Most code written by the
> >> newbreed won't run for a month without surfacing dozens of bugs.
> Margaret
> >> Hamilton would prolly have some choice words for these folks.
> >>
> >>
> >>
> >
>

[-- Attachment #2: Type: text/html, Size: 5097 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:27                               ` Rob Pike
@ 2022-02-06  6:40                                 ` Stuart Remphrey
  2022-02-06  6:44                                 ` Bakul Shah
                                                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 75+ messages in thread
From: Stuart Remphrey @ 2022-02-06  6:40 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 4578 bytes --]

I like the point that malloc()/free() could be seen as a "failure of
automation".

As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this
increasingly-off-topic thread:
perhaps it's an issue of whether that automation is applied at runtime or
compile-time...


(the latter still requiring guidance from the programmer, trading some
programmer-brain-time against cpu-execution-time & memory space?)

On Sun, 6 Feb 2022, 14:28 Rob Pike, <robpike@gmail.com> wrote:

> I don't understand your disagreement. In what way is automatic memory
> management harder, more unsafe, and less robust than hand-written memory
> management using malloc and free?
>
> You seem to think that garbage collection only exists in languages that
> have a smell you don't like. Perhaps that's true, but it's been around for
> 60 or more years and a lot of important languages use it, while the
> programmers that use those languages are often quite capable.
>
> Using malloc and free might be a badge of honor to some, but it's also a
> failure of automation.
>
> This discussion should probably go to COFF, or perhaps I should just leave
> the list. I am starting to feel uncomfortable here. Too much swagger.
>
> -rob
>
>
> On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote:
>
>> "it's a lot easier, safer, and robust to let the machine do the memory
>> accounting"
>>
>> I disagree. "The machine" is, as you know, is in reality app code
>> built on top of frameworks built on top of libraries built on top of
>> more libraries built on top of malloc/free calls. While the automated
>> testing tools are a lot better than they were when I started coding C
>> back in 1985, we're still talking about a *lot* of complexity and a
>> lot of layers of code, and programmers today know far less about
>> things like boundary conditions, off-by-one bugs, and the like that
>> bit us in the ass - hard - and so we learned to watch for those sorts
>> of things.
>>
>> On 2/5/22, Rob Pike <robpike@gmail.com> wrote:
>> > Be careful with your castigations. Yes, there is lots of old working
>> code,
>> > but keep in mind that that code has often not been as widely tested and
>> > deployed as much of the software that runs today. The fact that it
>> worked
>> > well on old hardware doesn't mean it will be suitable for modern
>> networked
>> > remotely administered multicore machines pounded on by millions of
>> people.
>> >
>> > And speaking of multicore, it's possible to write code using malloc/free
>> > that doesn't leak when run concurrently, but it's a lot easier, safer,
>> and
>> > robust to let the machine do the memory accounting. And the fact that
>> "kids
>> > today" can't do it doesn't mean they are lazy or failures, it means they
>> > grew up in a different time. And a lot of them are as capable as you
>> all,
>> > just in a different environment.
>> >
>> > Lately this list has a lot of attitude and prejudice pretending to be
>> > wisdom and superiority.
>> >
>> > -rob
>> >
>> >
>> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
>> >
>> >> On 2/5/22 6:56 PM, Larry McVoy wrote:
>> >>
>> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
>> >>
>> >> Hi Thomas,
>> >>
>> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
>> >>
>> >> I tell you one thing: I never ever experienced any problems with
>> >> traditional malloc()/free().??
>> >>
>> >> did you ever write a program which does heavy malloc()/free()
>> >> on complicated (i.e., shared) data structures *and* runs for
>> >> days, perhaps weeks? IMO it's very difficult to do this without
>> >> a GC, and you have to exercise quite an amount of discipline
>> >> to do it right.
>> >>
>> >> I've done this and I've employed people who have done this.  We're
>> >> a dieing breed, the focus seems to be on programming languages and
>> >> tools for idiots.  People don't want to learn the discipline it takes
>> >> to work with malloc()/free().  It's sad.
>> >>
>> >>
>> >> I completely agree. This is ridiculous. Do modern programmer's
>> seriously
>> >> think that the old code wasn't complex or robust? Sheesh, there's code
>> >> out
>> >> there that has run through more millions of transactions an hour for
>> more
>> >> years than most of these folks have been alive. There's also code
>> that's
>> >> been running without any updates, for decades. Most code written by the
>> >> newbreed won't run for a month without surfacing dozens of bugs.
>> Margaret
>> >> Hamilton would prolly have some choice words for these folks.
>> >>
>> >>
>> >>
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 6052 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:27                               ` Rob Pike
  2022-02-06  6:40                                 ` Stuart Remphrey
@ 2022-02-06  6:44                                 ` Bakul Shah
  2022-02-06 19:08                                   ` Steffen Nurpmeso
  2022-02-06 12:52                                 ` Ralph Corderoy
  2022-02-06 13:14                                 ` Ed Carp
  3 siblings, 1 reply; 75+ messages in thread
From: Bakul Shah @ 2022-02-06  6:44 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

Just ignore the swagger.

I would go further than Rob in that even for sequential
programs there is no virtue in sticking to malloc/free if you
don't have to. The whole point of automation (for me) is to
delegate all the boring and repetitive work to computers so
that I can focus on more interesting things! And solving
malloc/free related bugs is boring and repetitive. For
embedded code in limited space you want to use memory
carefully but for most of userland code we don't have to
worry about saving every byte. Most userland code is not real
time code (and doesn't run on realtime OSes).  That doesn't
mean using memory like water -- there is a middle ground.
Don't blame the GC for incompetently programmed websites or
for layers of code using third party libraries using other
third party libraries.

> On Feb 5, 2022, at 10:27 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> I don't understand your disagreement. In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free?
> 
> You seem to think that garbage collection only exists in languages that have a smell you don't like. Perhaps that's true, but it's been around for 60 or more years and a lot of important languages use it, while the programmers that use those languages are often quite capable.
> 
> Using malloc and free might be a badge of honor to some, but it's also a failure of automation.
> 
> This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger.
> 
> -rob
> 
> 
> On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote:
> "it's a lot easier, safer, and robust to let the machine do the memory
> accounting"
> 
> I disagree. "The machine" is, as you know, is in reality app code
> built on top of frameworks built on top of libraries built on top of
> more libraries built on top of malloc/free calls. While the automated
> testing tools are a lot better than they were when I started coding C
> back in 1985, we're still talking about a *lot* of complexity and a
> lot of layers of code, and programmers today know far less about
> things like boundary conditions, off-by-one bugs, and the like that
> bit us in the ass - hard - and so we learned to watch for those sorts
> of things.
> 
> On 2/5/22, Rob Pike <robpike@gmail.com> wrote:
> > Be careful with your castigations. Yes, there is lots of old working code,
> > but keep in mind that that code has often not been as widely tested and
> > deployed as much of the software that runs today. The fact that it worked
> > well on old hardware doesn't mean it will be suitable for modern networked
> > remotely administered multicore machines pounded on by millions of people.
> >
> > And speaking of multicore, it's possible to write code using malloc/free
> > that doesn't leak when run concurrently, but it's a lot easier, safer, and
> > robust to let the machine do the memory accounting. And the fact that "kids
> > today" can't do it doesn't mean they are lazy or failures, it means they
> > grew up in a different time. And a lot of them are as capable as you all,
> > just in a different environment.
> >
> > Lately this list has a lot of attitude and prejudice pretending to be
> > wisdom and superiority.
> >
> > -rob
> >
> >
> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote:
> >
> >> On 2/5/22 6:56 PM, Larry McVoy wrote:
> >>
> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote:
> >>
> >> Hi Thomas,
> >>
> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote:
> >>
> >> I tell you one thing: I never ever experienced any problems with
> >> traditional malloc()/free().??
> >>
> >> did you ever write a program which does heavy malloc()/free()
> >> on complicated (i.e., shared) data structures *and* runs for
> >> days, perhaps weeks? IMO it's very difficult to do this without
> >> a GC, and you have to exercise quite an amount of discipline
> >> to do it right.
> >>
> >> I've done this and I've employed people who have done this.  We're
> >> a dieing breed, the focus seems to be on programming languages and
> >> tools for idiots.  People don't want to learn the discipline it takes
> >> to work with malloc()/free().  It's sad.
> >>
> >>
> >> I completely agree. This is ridiculous. Do modern programmer's seriously
> >> think that the old code wasn't complex or robust? Sheesh, there's code
> >> out
> >> there that has run through more millions of transactions an hour for more
> >> years than most of these folks have been alive. There's also code that's
> >> been running without any updates, for decades. Most code written by the
> >> newbreed won't run for a month without surfacing dozens of bugs. Margaret
> >> Hamilton would prolly have some choice words for these folks.
> >>
> >>
> >>
> >


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:27                               ` Rob Pike
  2022-02-06  6:40                                 ` Stuart Remphrey
  2022-02-06  6:44                                 ` Bakul Shah
@ 2022-02-06 12:52                                 ` Ralph Corderoy
  2022-02-06 13:14                                 ` Ed Carp
  3 siblings, 0 replies; 75+ messages in thread
From: Ralph Corderoy @ 2022-02-06 12:52 UTC (permalink / raw)
  To: tuhs

rob wrote:
> This discussion should probably go to COFF

It should have long ago; way too noisy and off-topic for TUHS.

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:27                               ` Rob Pike
                                                   ` (2 preceding siblings ...)
  2022-02-06 12:52                                 ` Ralph Corderoy
@ 2022-02-06 13:14                                 ` Ed Carp
  2022-02-06 14:13                                   ` Dan Cross
  2022-02-06 14:15                                   ` Larry McVoy
  3 siblings, 2 replies; 75+ messages in thread
From: Ed Carp @ 2022-02-06 13:14 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

Since you made this personal and called me out specifically, I will respond:

"In what way is automatic memory management harder, more unsafe, and
less robust than hand-written memory management using malloc and
free?"

Because there's no difference in the two. Someone had to write the
"automatic memory management", right?

"You seem to think that garbage collection only exists in languages
that have a smell you don't like."

I said nothing of the kind. You've got me mixed up with someone else.
Just because I respond to a thread doesn't mean I agree with
everything said in the thread.

"Using malloc and free might be a badge of honor to some, but it's
also a failure of automation."

Again, the automation code has to written by *someone*. It doesn't
just appear by itself.

"This discussion should probably go to COFF, or perhaps I should just
leave the list. I am starting to feel uncomfortable here. Too much
swagger."

I read through the thread. Just because people don't agree with each
other doesn't equate to "swagger". I've seen little evidence of
anything other than reasoned analysis and rational, respectful
discussion. Was there any sort of personal attacks that I missed?

The fact of the matter is, code written with malloc/free, if written
carefully, will run for *years*. There are Linux boxes that have been
running for literally years without being rebooted, and mainframes and
miniframes that get booted only when a piece of hardware fails.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06 13:14                                 ` Ed Carp
@ 2022-02-06 14:13                                   ` Dan Cross
  2022-02-06 14:15                                   ` Larry McVoy
  1 sibling, 0 replies; 75+ messages in thread
From: Dan Cross @ 2022-02-06 14:13 UTC (permalink / raw)
  To: Ed Carp; +Cc: COFF

[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]

Oh dear. This is getting a little heated. TUHS to Bcc:, replies to COFF.

On Sun, Feb 6, 2022 at 8:15 AM Ed Carp <erc@pobox.com> wrote:

> Since you made this personal and called me out specifically, I will
> respond:
>
> "In what way is automatic memory management harder, more unsafe, and
> less robust than hand-written memory management using malloc and
> free?"
>
> Because there's no difference in the two. Someone had to write the
> "automatic memory management", right?
>

I cannot agree with this, there is a big difference.

With GC, you are funneling all of the fiddly bits of dealing with memory
management through a runtime that is written by a very small pool of people
who are intimately familiar with the language, the runtime, the compilation
environment, and so on. That group of subject matter experts produce a
system that is tested by every application (much like the _implementation_
of malloc/free itself, which is not usually reproduced by every programmer
who _uses_ malloc/free).

It's like in "pure" functional languages such as Haskell, where everything
is immutable: that doesn't mean that registers don't change values, or that
memory cells don't get updated, or that IO doesn't happen, or the clock
doesn't tick. Rather, it means that the programmer makes a tradeoff where
they cede control over those things to the compiler and a runtime written
by a constrained set of contributors, in exchange for guarantees those
things make about the behavior of the program.

With manual malloc/free, one smears responsibility for getting it right
across every program that does dynamic memory management. Some get it
right; many do not.

In many ways, the difference between automatic and manual memory management
is like the difference between programming in assembler and programming in
a high-level language. People have written reliable, robust assembler for
decades (look at the airline industry), but few people would choose to do
so today; why? Because it's tedious and life is too short as it is.
Further, the probability of error is greater than in a high-level language;
why tempt fate?

[snip]
> "This discussion should probably go to COFF, or perhaps I should just
> leave the list. I am starting to feel uncomfortable here. Too much
> swagger."
>
> I read through the thread. Just because people don't agree with each
> other doesn't equate to "swagger". I've seen little evidence of
> anything other than reasoned analysis and rational, respectful
> discussion. Was there any sort of personal attacks that I missed?
>

It is very difficult, in a forum like this, to divine intent. I know for a
fact that I've written things to this list that were interpreted very
differently than I meant them.

That said, there has definitely been an air that those who do not master
manual memory management are just being lazy and that "new" programmers are
unskilled. Asserting that this language or that is "ours" due to its
authors while that is "theirs" or belongs solely to some corporate sponsor
is a bit much. The reality is that languages and operating systems and
hardware evolve over time, and a lot of the practices we took for granted
10 years ago deserve reexamination in the light of new context. There's
nothing _wrong_ with that, even if it may be uncomfortable (I know it is
for me).

The fact of the matter is, code written with malloc/free, if written
> carefully, will run for *years*. There are Linux boxes that have been
> running for literally years without being rebooted, and mainframes and
> miniframes that get booted only when a piece of hardware fails.
>

That there exist C programs that have run for many years without faults is
indisputable. Empirically, people _can_ write reliable C programs, but it
is often harder than it seems to do so, particularly since the language
standard gives so much latitude for implementations to change semantics in
surprising ways over time. Just in the past couple of weeks a flaw was
revealed in some Linux daemon that allowed privilege escalation to
root...due to improper memory management. That flaw had been in production
for _12 years_. Sadly, this is not an isolated incident.

That said, does manual memory management have a place in modern computing?
Of course it does, as you rightly point out. So does assembly language.
Rust came up in the context of this thread as a GC'd language, and it may
be worth mentioning that Rust uses manual memory management; the language
just introduces some facilities that make this safer. For instance, the
concept of ownership is elevated to first-class status in Rust, and there
are rules about taking references to things; when something's owner goes
out of scope, it is "dropped", but the compiler statically enforces that
there are no outstanding references to that thing. Regardless, when dealing
with some resource it is often the programmer's responsibility to make sure
that a suitable drop implementation exists. FWIW, I used to sit down the
hall from a large subgroup of the Go developers; we usually ate lunch
together. I know that many of them shared my opinion that Rust and Go are
very complimentary. No one tool is right for all tasks.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 6350 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06 13:14                                 ` Ed Carp
  2022-02-06 14:13                                   ` Dan Cross
@ 2022-02-06 14:15                                   ` Larry McVoy
  2022-02-06 16:31                                     ` Warner Losh
                                                       ` (2 more replies)
  1 sibling, 3 replies; 75+ messages in thread
From: Larry McVoy @ 2022-02-06 14:15 UTC (permalink / raw)
  To: Ed Carp; +Cc: TUHS main list

Let's keep it civil and non-personal, I don't think Rob was pointing 
at anyone, I think he was pointing at some not so forward thinking.

I have to side with Rob on this one, even though I'm squarely in the
I like C best camp.

While I _can_ do all the malloc/free stuff myself (and have decades of
working code to prove it), it's become harder and harder to find other
people who can.  Younger programmers just sort of stare at you with a
"I have to do what?" look.  They think you are a dinosaur for working
like that when other reasonable languages do that work for you.

When I did little-lang.org, granted, not widely used but we used it a
lot, it did all the memory management behind the scenes, used reference
counting so you never had the big GC sweep that some languages used,
worked great.  And super pleasant to not have to do all that memory
management.

Having the languages do more for you, and put up guard rails so people
can't make stupid mistakes, seems to be the way of the future.  It's 
not my future, I love C, it does what I want and I can live with what
it needs me to do to have working code.  But I'm a dinosaur and I 
know it.  I'm not trying to push C where people don't want it.

On Sun, Feb 06, 2022 at 06:14:36AM -0700, Ed Carp wrote:
> Since you made this personal and called me out specifically, I will respond:
> 
> "In what way is automatic memory management harder, more unsafe, and
> less robust than hand-written memory management using malloc and
> free?"
> 
> Because there's no difference in the two. Someone had to write the
> "automatic memory management", right?
> 
> "You seem to think that garbage collection only exists in languages
> that have a smell you don't like."
> 
> I said nothing of the kind. You've got me mixed up with someone else.
> Just because I respond to a thread doesn't mean I agree with
> everything said in the thread.
> 
> "Using malloc and free might be a badge of honor to some, but it's
> also a failure of automation."
> 
> Again, the automation code has to written by *someone*. It doesn't
> just appear by itself.
> 
> "This discussion should probably go to COFF, or perhaps I should just
> leave the list. I am starting to feel uncomfortable here. Too much
> swagger."
> 
> I read through the thread. Just because people don't agree with each
> other doesn't equate to "swagger". I've seen little evidence of
> anything other than reasoned analysis and rational, respectful
> discussion. Was there any sort of personal attacks that I missed?
> 
> The fact of the matter is, code written with malloc/free, if written
> carefully, will run for *years*. There are Linux boxes that have been
> running for literally years without being rebooted, and mainframes and
> miniframes that get booted only when a piece of hardware fails.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  1:10                         ` Will Senn
  2022-02-06  4:52                           ` Rob Pike
@ 2022-02-06 16:16                           ` Brad Spencer
  2022-02-08  5:22                             ` Ed Carp
  1 sibling, 1 reply; 75+ messages in thread
From: Brad Spencer @ 2022-02-06 16:16 UTC (permalink / raw)
  To: Will Senn; +Cc: tuhs

Will Senn <will.senn@gmail.com> writes:

[snip]

>> I've done this and I've employed people who have done this.  We're
>> a dieing breed, the focus seems to be on programming languages and
>> tools for idiots.  People don't want to learn the discipline it takes
>> to work with malloc()/free().  It's sad.
>
> I completely agree. This is ridiculous. Do modern programmer's seriously 
> think that the old code wasn't complex or robust? Sheesh, there's code 
> out there that has run through more millions of transactions an hour for 
> more years than most of these folks have been alive. There's also code 
> that's been running without any updates, for decades. Most code written 
> by the newbreed won't run for a month without surfacing dozens of bugs. 
> Margaret Hamilton would prolly have some choice words for these folks.

This would appear to be a Not Unix conversation... but...

So...  the idea that code would run that long was not at all valued at
my last job.  The management found it simpler and better (for some
definition of better) to just reinvent everything every 3 to 6 years.
In the mean time, the languages used would change.  The idea that one
would "have to waste time" figuring out how to use malloc() and free()
properly was not looked upon well when the development time would be
better spend solving the needed higher level problems.  In other words
there literally was no interest in creating code that was going to be
maintained for more than about 6 years and in a lot of cases would not
be maintained more than 3 or even 1 year.

To bring this back to Unix somewhat...  When I started there, everything
was a Solaris based private cloud (SmartOS by Joyent) running Java apps.
In the 5 years I was there, the move was from Java to Go, due to the
licensing changes that Oracle made to Java and then a move to
containers.  SmartOS has a container technology that is sort of like
Docker, but since the majority of the containers in the world that
people know about are fully Docker in some form with Linux it wasn't as
compatible as required so SmartOS was dumped and everything was redone
in Azure public cloud with Linux and as much of the native Azure stuff
as they could stand to use.  Make everything "green field" all of the
time, or something....

I didn't really agree with much of this, but I became pretty mercenary
as I got old and the place paid well.







-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06 14:15                                   ` Larry McVoy
@ 2022-02-06 16:31                                     ` Warner Losh
  2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
  2022-02-06 19:27                                     ` Jon Steinhart
  2 siblings, 0 replies; 75+ messages in thread
From: Warner Losh @ 2022-02-06 16:31 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

On Sun, Feb 6, 2022 at 7:17 AM Larry McVoy <lm@mcvoy.com> wrote:

> While I _can_ do all the malloc/free stuff myself (and have decades of
> working code to prove it), it's become harder and harder to find other
> people who can.
>

 While it's not too bad to do malloc/free in userspace in single threaded
programs, it gets harder for multi-threaded where you have multiple objects
holding references to an object you might want to free. And to get things
to run fast, you have to use increasingly sophisticated "locking" primitives
to get performance: RCU, lifetime flexibility, etc. Those methods are
hard to get right, which is why most of them include extensive run-time
proofing / asserts to try to catch leaks and other problems.

For kernel work, that adds a whole other level of complexity as well.

I'd love to have all this stuff automatically optimized and correct.
However, the state of the art for alternatives to C aren't there today
for the kernel context. While rust in Linux is a thing, it's not in the
fast path yet. Time will tell if it can grow up to do that or not, and
I'll stop there since it's a rapidly developing area and I'm sure
anything I say about the state of the art when I last looked will
be wrong in some way.

Warner

[-- Attachment #2: Type: text/html, Size: 1818 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ]
  2022-02-06 14:15                                   ` Larry McVoy
  2022-02-06 16:31                                     ` Warner Losh
@ 2022-02-06 18:36                                     ` Jon Steinhart
  2022-02-06 19:27                                     ` Jon Steinhart
  2 siblings, 0 replies; 75+ messages in thread
From: Jon Steinhart @ 2022-02-06 18:36 UTC (permalink / raw)
  To: TUHS main list

Larry McVoy writes:
> Let's keep it civil and non-personal, I don't think Rob was pointing 
> at anyone, I think he was pointing at some not so forward thinking.
>
> I have to side with Rob on this one, even though I'm squarely in the
> I like C best camp.
>
> While I _can_ do all the malloc/free stuff myself (and have decades of
> working code to prove it), it's become harder and harder to find other
> people who can.  Younger programmers just sort of stare at you with a
> "I have to do what?" look.  They think you are a dinosaur for working
> like that when other reasonable languages do that work for you.
>
> When I did little-lang.org, granted, not widely used but we used it a
> lot, it did all the memory management behind the scenes, used reference
> counting so you never had the big GC sweep that some languages used,
> worked great.  And super pleasant to not have to do all that memory
> management.
>
> Having the languages do more for you, and put up guard rails so people
> can't make stupid mistakes, seems to be the way of the future.  It's 
> not my future, I love C, it does what I want and I can live with what
> it needs me to do to have working code.  But I'm a dinosaur and I 
> know it.  I'm not trying to push C where people don't want it.

I look at this from a different perspective.

The world needs a lot of programmers these days.  It takes a lot of work to
have internet-connected refrigerators push advertising, to make washers and
dryers sing about their work, to have Bixby piss off Samsung phone users,
to ensure that IoT devices are insecure, and of course to leak personally
identifying information on government web sites.  This is critical work
and there just aren't enough "good" programmers to go around.

I view people that programming for Android, making web pages unusable,
and so on, as if they're using domain-specific languages.  The difference
is that while many of us grew up loving domain-specific "little languages"
these languages are huge.  While I'm not an expert here, I'm sure that
being an expert in the Android, IOS, Java, or WWW ecosystems involves more
"learning" than many of us had to do when we learned our craft.

A big problem with our profession is that we have no agreed on terminology
to distinguish among practitioners.  A story told to me by a co-worker in
the '80s illustrates this well.  Ken had gone home for Christmas with his
family.  One of his uncles took him aside and asked something like "Hey,
you're a computer guy.  Can you help me with this .COM and .BAT stuff?"
Ken replied "Don't have a clue what you're talking about."  When Ken
related this story to me, he said "The funny thing about it was that
we both walked away thinking that the other person didn't know anything
about computers."

I think some of what we're debating here is whether or not "programmers"
need to understand fundamentals.  Many of us think that they do, but
we're not the ones working on a subscription model for starting your car.

I replaced my deck last summer.  Had to do a lot of contractor
interviewing.  I didn't choose one who said "I can do it" and showed me
photos of work he had done.  I chose one who said "I can do it" and looked
around and said "You know, won't be able to tell until I get the old one
removed but I think that there some things that need fixing underneath."

Another example, because I'm also a hardware engineer.  Many digital
circuit designers think that digital is an isolated domain.  There was
a time a few decades ago when an analog engineer couldn't get a job.
But then there was an awakening when folks realized that everything was
analog at its core and all of a sudden "full stack hardware engineers"
were writing their own tickets.  Sure, many digital designers said
"Why do I need to know this stuff?  Nobody uses Rubylith anymore and
the DRC (design rule checker) software takes care of stuff for me.
Analog designers bail those people out when things don't work.

To me, a big problem with what I'll call domain-specific programmers is
that they get involved in standards and specifications and aren't trained
in how to abstract.  So standards are produced that result in enlarged,
more complex domains.  One of the best examples is CSS, a standard that is
too complex to be documented.  I have no clue as to how many CSS properties
exist anymore.  It's not cleanly designed, and of course with the addition
of each new property the interaction matrix grows exponentially.  And the
increasing number of mode-switching properties is growing the number
of interaction matrices.  There are literally thousands of things a CSS
"programmer" needs to know, yet people still ask question like "How do
I vertically center something" because it's still hard to do.  Even the
worst programming language is orders of magnitude simpler than CSS.
But hey, CSS isn't "programming" so of course it's better.

Bottom line to me is that people with serious expertise are always going
to be needed.  Someone has to design the hardware, someone has to make the
tools used to design the hardware, someone has to implement programming
languages and operating systems and all that.  But that's a different
domain than what the majority of the world wants today.

Jon

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06  6:44                                 ` Bakul Shah
@ 2022-02-06 19:08                                   ` Steffen Nurpmeso
  0 siblings, 0 replies; 75+ messages in thread
From: Steffen Nurpmeso @ 2022-02-06 19:08 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

Bakul Shah wrote in
 <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org>:
 |Just ignore the swagger.
 |
 |I would go further than Rob in that even for sequential
 |programs there is no virtue in sticking to malloc/free if you
 |don't have to. The whole point of automation (for me) is to

Well maybe.  When i do perl or awk i do not even think about that
memory as such exists, mostly.  In so far.

 |delegate all the boring and repetitive work to computers so
 |that I can focus on more interesting things! And solving
 |malloc/free related bugs is boring and repetitive. For

But, you know, this is a philosophy i do not like.

Just like i never understood why Stroustrup gave C++ exceptions
the full power of flexibility instead of allowing only a single
base class but giving the entire C++ environment a toggle to
produce __FILE__/__LINE__ diagnosis out of the box.  Or instead of
even introducing symbols which go the non-preprocessor if(XY) way
and allowing access to these from within code if XY is true.
So you have to invent preprocessor mess in order to be able to
pass debug info down the call chain, or use non-portable ELF or so
related info (which i never did).
But if you do have the information at hand, your program could say

  #?1|kent:steffen$ s-nail -Rf /dev/empty
  s-nail: /dev/empty: No such entry, file or directory
  ...
  #?0!0/NONE#ERROR|:? quit
  ...
  s-nail[info]:    Count cur/peek/all:       4/   1658/     12524
  ...
  s-nail[info]:   0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064  There are messages in the error ring, manageable via `errors' command???
  s-nail[info]:   0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035  ????????????????E???????P?X??U??E???????
  s-nail[info]:   0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064  /dev/empty: No such entry, file or directory????
  s-nail[info]:   0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035  ??X??U??????????,??????? ?X??U??,???^???

even upon receive of a signal.  And this is just a silly wrapper,
not even a complete thing.
It is just like always, "there is no wrong weather, just the wrong
clothes".

 |embedded code in limited space you want to use memory
 |carefully but for most of userland code we don't have to
 |worry about saving every byte. Most userland code is not real
 |time code (and doesn't run on realtime OSes).  That doesn't
 |mean using memory like water -- there is a middle ground.
 |Don't blame the GC for incompetently programmed websites or
 |for layers of code using third party libraries using other
 |third party libraries.

All the new languages [offer] [myriads] of [symbol] [annotations]
in order to improve things, which also aids in giving more info to
the tools.

And, what is maybe more important, all programs written in these
languages are written from scratch.  And even if people tend to
produce bugs here and there, and tend to forget the background of
a problem now and then, or did not know about it when they wrote
the code, ... the experience with programming has improved a lot
compared to times that members of these list went through!

That is of course only my personal opinion.  I like C a lot (like
C++ without everything but classes).

--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)

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ]
  2022-02-06 14:15                                   ` Larry McVoy
  2022-02-06 16:31                                     ` Warner Losh
  2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
@ 2022-02-06 19:27                                     ` Jon Steinhart
  2022-02-06 19:33                                       ` Warner Losh
  2 siblings, 1 reply; 75+ messages in thread
From: Jon Steinhart @ 2022-02-06 19:27 UTC (permalink / raw)
  To: TUHS main list

Oh, one more thing.  It was kind of implied in my earlier post, but
a big concern is when domain-specific programmers cross over into a
different domain but think that the rules from the domain with which
they're familiar apply.  For example, I wouldn't want someone from a
GC domain messing with an OS kernel without learning about memory and
memory management.  Stuff has to interoperate in a way that an insecure
talking toaster doesn't.  I probably have the quote completely wrong,
but Dan Healy, sound man for The Grateful Dead an inventor of much of
modern concert hall sound technology said something like "Bozos are
fine people and fun to be around but that doesn't mean that I would
let one near my soundboard with a pair of diagonal pliers."

Jon

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ]
  2022-02-06 19:27                                     ` Jon Steinhart
@ 2022-02-06 19:33                                       ` Warner Losh
  2022-02-06 19:37                                         ` Jon Steinhart
  0 siblings, 1 reply; 75+ messages in thread
From: Warner Losh @ 2022-02-06 19:33 UTC (permalink / raw)
  To: Jon Steinhart; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

On Sun, Feb 6, 2022 at 12:27 PM Jon Steinhart <jon@fourwinds.com> wrote:

> I probably have the quote completely wrong,
> but Dan Healy, sound man for The Grateful Dead an inventor of much of
> modern concert hall sound technology said something like "Bozos are
> fine people and fun to be around but that doesn't mean that I would
> let one near my soundboard with a pair of diagonal pliers."
>

I personally like having the choices. I don't want to be bothered with
malloc/free when I'm hacking together an awk or python script. On
the other hand, when it has to run fast or do lots of TPS inside a kernel,
I really don't want somebody else deciding when a good time to take
a 'hiccup' in performance is...  It all depends on what I'm doing since
using techniques from the latter to optimize the former is a waste of
time. The whole reason I do a GC'd language is to write what I'm writing
faster with less hassle...

Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :)

Warner

[-- Attachment #2: Type: text/html, Size: 1515 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ]
  2022-02-06 19:33                                       ` Warner Losh
@ 2022-02-06 19:37                                         ` Jon Steinhart
  2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
  0 siblings, 1 reply; 75+ messages in thread
From: Jon Steinhart @ 2022-02-06 19:37 UTC (permalink / raw)
  To: TUHS main list

Warner Losh writes:
> I personally like having the choices. I don't want to be bothered with
> malloc/free when I'm hacking together an awk or python script. On
> the other hand, when it has to run fast or do lots of TPS inside a kernel,
> I really don't want somebody else deciding when a good time to take
> a 'hiccup' in performance is...  It all depends on what I'm doing since
> using techniques from the latter to optimize the former is a waste of
> time. The whole reason I do a GC'd language is to write what I'm writing
> faster with less hassle...
>
> Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :)

Completely agree with you.  I do the same.  But I actually know how to use
those diagonal pliers; I don't want someone who doesn't know what they're
doing to start snipping things.

Jon

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] COFF is over there.
  2022-02-06 19:37                                         ` Jon Steinhart
@ 2022-02-06 20:21                                           ` Ralph Corderoy
  0 siblings, 0 replies; 75+ messages in thread
From: Ralph Corderoy @ 2022-02-06 20:21 UTC (permalink / raw)
  To: TUHS main list

Hi Jon,

You've brought up an interesting point to start this subthread,
but it still isn't TUHS-worthy IME.  COFF would welcome it.  :-)

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] more about Brian...
  2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
@ 2022-02-08  5:22                             ` Ed Carp
  0 siblings, 0 replies; 75+ messages in thread
From: Ed Carp @ 2022-02-08  5:22 UTC (permalink / raw)
  To: Brad Spencer; +Cc: tuhs

And that reminds me of the old "Three Envelopes" joke:


A new CEO takes his seat at the helm of a large corporation
He finds three envelopes on his desk, numbered 1 to 3, and a note.

"Dear successor,
On this desk you find 3 envelopes that will help you in times of a
crisis. Open them only in the order they are numbered, and only when
you face a crisis that you cannot manage.
Best of luck".

He stores them in his safe and goes to work. But the economy isn't
picking up, the corporation isn't doing too well and the board wants
an explanation. He decides it's time for the first envelope. He rips
it open and reads:

"Blame your predecessor".

And he does. He steps up at the press conference and blames everything
on the shortcomings and nearsightedness of his predecessor and how he
just needs a bit more time to turn things around. Everyone is pleased
and he remains CEO.

But after a while, the displeasure isn't waning and the corporation
isn't doing any better. Another press conference is held and he rips
open the next envelope:

"Call for reorganizations".

And he does. He presents a great reorganization project with no stone
remaining unturned, this will surely improve productivity and move the
corporation into the future. Everyone's so busy reorganizing that
nobody can even notice how the corporation is running worse and worse,
until there's really no way to cover it up anymore. He reaches for the
third and last envelope, hoping for the great reveal that will save
him once and for all. He rips it open and reads:

"Prepare 3 envelopes and a note".


On 2/6/22, Brad Spencer <brad@anduin.eldar.org> wrote:
> Will Senn <will.senn@gmail.com> writes:
>
> [snip]
>
>>> I've done this and I've employed people who have done this.  We're
>>> a dieing breed, the focus seems to be on programming languages and
>>> tools for idiots.  People don't want to learn the discipline it takes
>>> to work with malloc()/free().  It's sad.
>>
>> I completely agree. This is ridiculous. Do modern programmer's seriously
>> think that the old code wasn't complex or robust? Sheesh, there's code
>> out there that has run through more millions of transactions an hour for
>> more years than most of these folks have been alive. There's also code
>> that's been running without any updates, for decades. Most code written
>> by the newbreed won't run for a month without surfacing dozens of bugs.
>> Margaret Hamilton would prolly have some choice words for these folks.
>
> This would appear to be a Not Unix conversation... but...
>
> So...  the idea that code would run that long was not at all valued at
> my last job.  The management found it simpler and better (for some
> definition of better) to just reinvent everything every 3 to 6 years.
> In the mean time, the languages used would change.  The idea that one
> would "have to waste time" figuring out how to use malloc() and free()
> properly was not looked upon well when the development time would be
> better spend solving the needed higher level problems.  In other words
> there literally was no interest in creating code that was going to be
> maintained for more than about 6 years and in a lot of cases would not
> be maintained more than 3 or even 1 year.
>
> To bring this back to Unix somewhat...  When I started there, everything
> was a Solaris based private cloud (SmartOS by Joyent) running Java apps.
> In the 5 years I was there, the move was from Java to Go, due to the
> licensing changes that Oracle made to Java and then a move to
> containers.  SmartOS has a container technology that is sort of like
> Docker, but since the majority of the containers in the world that
> people know about are fully Docker in some form with Linux it wasn't as
> compatible as required so SmartOS was dumped and everything was redone
> in Azure public cloud with Linux and as much of the native Azure stuff
> as they could stand to use.  Make everything "green field" all of the
> time, or something....
>
> I didn't really agree with much of this, but I became pretty mercenary
> as I got old and the place paid well.
>
>
>
>
>
>
>
> --
> Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
>

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-02  7:47     ` arnold
  2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
  2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
@ 2022-02-10 15:18       ` Ralph Corderoy
  2 siblings, 0 replies; 75+ messages in thread
From: Ralph Corderoy @ 2022-02-10 15:18 UTC (permalink / raw)
  To: tuhs

Hi Arnold,

> > I agree the original Software Tools is a must read, but having done
> > so, why would I suffer working through the hurdles put in place by
> > Pascal compared to Ratfor?  I never bothered so your recommendation
> > makes me wonder what I missed.  I did read Kernighan's ‘not my
> > favourite’ and took from that I wouldn't enjoy the Pascal book given
> > I'd read the original.
>
> As others mentioned, recursion and real data structures make code
> easier to read. They also refined the text some.
>
> But in general, I think the principle of "ANYTHING written by Brian
> Kernighan is worth reading, at least once" applies, even in this case.

Well, that's true.  I've read every other technical book of his apart
from the ‘AMPL: A Modeling Language for Mathematical Programming’.
https://amzn.to/3BdQ0dV

It was the quality of his writing which meant I could learn C and Unix
at home well enough to get a C programming job on Sun OS on leaving
school, which is sixteen over here.  Within a year or so, work sent me
to Sydney as part of shipping the flight simulator to Qantas.  Good
books have immeasurable worth across all their readers.

Thanks, it's ordered, arriving Valentine's Day, which will impress
SWMBO.  :-)

-- 
Cheers, Ralph.

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 22:30   ` Erik E. Fair
@ 2022-02-02  0:54     ` Yeechang Lee
  0 siblings, 0 replies; 75+ messages in thread
From: Yeechang Lee @ 2022-02-02  0:54 UTC (permalink / raw)
  To: tuhs

Erik E. Fair says:
> With regard to programming languages at UCB in 1980 ...
>
> I'd done something of a survey of colleges, and in my mind at the
> time, there were two approaches to a CS degree: mostly or entirely
> theoretical (those CS departments that had grown out of Mathematics
> tended to have this focus), or more practical
> tools/techniques/operational theory (those CS departments that had
> grown out of Engineering tended to be this way).

Quoting my 2019 message to the cctech mailing list:

----

Adam Thornton <athornton@gmail.com> says:
> The genealogy of Computer Science departments (and their curricula)
> (at least in the US) is also weird and historically-contingent.
> Basically it seems to have been a tossup at any given school whether
> it came out of the Electr[ical|onic] Engineering department, in
> which case it was memories and logic gates and a bottom-up,
> hardware-focused curriculum, or out of the Mathematics department,
> in which case it was algorithms and complexity analysis and a
> software-focused curriculum.

Yes, I've noticed the same thing. Example: Harvard's CS department is
originally from the math side, while MIT's is from EE (thus today's
EECS).

Berkeley = EE
Brown = Math
BYU = Math
Caltech = EE
Columbia = EE
Cornell = Operations research, math
Dartmouth = Math
Illinois = Math
NYU = Both (because Polytechnic developed its own CS program long
before NYU acquired it to regain an engineering school)
Penn = EE
UCLA = OR (probably because of the RAND heritage)

Caltech until very recently did not formally offer CS degrees;
students received degrees in Engineering and Applied Science, with a
focus on CS (or aeronautics, or civil, or ME).

Illinois is an example of a track we might call "other" or even
"defense". With government funding the university built its own
computers (including ILLIAC and PLATO), and the group that did so
became the CS department, but the undergraduate CS program began
within the math department. Harvard's and Penn's programs might also
qualify.

Undergraduate CS degrees are BA (Example: Harvard), BS (Example:
Penn), or both (Example: Columbia). At Penn one must be an engineering
student to major in CS. At Columbia one can major in CS in either the
liberal arts or engineering schools, but with different
curriculums. At Yale there is one undergraduate school, within which
one can receive a BA or BS in CS, with different curriculums. Cornell,
Northwestern, and Berkeley offer CS in their separate liberal arts and
engineering schools; undergraduates receive BA or BS degrees with
identical CS curriculums, with only other requirements differing.

I've read that medical schools are good at teaching either
pharmacology (drugs), or pathology (diseases); perhaps this is also
because of the expertise/specialty of their early faculty members.

----

> Two paths to a computer science degree: A.B. CS from L&S, or
> B.S. EECS from the College of Engineering (which you had to be
> explicitly admitted to before you got there).

Still true today. As I mention above, Berkeley's CS curriculum is identical regardless of the degree (or was the last time I checked), something not always true at other universities that offer multiple CS undergraduate degree options.

-- 
geo:37.783333,-122.416667

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 21:33         ` Clem Cole
@ 2022-02-01 23:12           ` John Cowan
  0 siblings, 0 replies; 75+ messages in thread
From: John Cowan @ 2022-02-01 23:12 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Tue, Feb 1, 2022 at 4:33 PM Clem Cole <clemc@ccc.com> wrote:


> My disagreement with them using scripting (python) as step one is the lack
> of teaching data typing early
>

Teaching types is very important.  But Python is strongly typed: a string
is not a number is not a hashtable.  When it's important for performance
reasons or consistency across a large codebase, you can add static type
information to your Python code without overloading n00b brains with
mandatory type annotations.

AND python's silly use space/tabs to set up structure instead of  real {}
> or B/E blocks.
>

Nobody would accept code that was incorrectly indented (although some
languages have more than one indentation convention, like C) in an
assignment or pull request.  And when looking at correct or mostly correct
code, we look at the indentation structure, not the braces.  That being so,
having both braces and indentation is fundamentally a DRY violation.

Automatic data conversion has never been a good idea in my experience
> because like many things that happen magically, it almost never works as
> I expect.
>

I think it was a customer revolt that persuaded IBM to add "mixed-mode"
expressions like "A + I" to Fortran IV; they had been disallowed in Fortran
II.  I haven't heard anyone saying we ought to revert that change.

[-- Attachment #2: Type: text/html, Size: 2907 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
  2022-02-01 19:39   ` Richard Salz
@ 2022-02-01 22:30   ` Erik E. Fair
  2022-02-02  0:54     ` Yeechang Lee
  2 siblings, 1 reply; 75+ messages in thread
From: Erik E. Fair @ 2022-02-01 22:30 UTC (permalink / raw)
  To: Unix Historical Something or other

With regard to programming languages at UCB in 1980 ...

I'd done something of a survey of colleges, and in my mind at the time, there were two approaches to a CS degree: mostly or entirely theoretical (those CS departments that had grown out of Mathematics tended to have this focus), or more practical tools/techniques/operational theory (those CS departments that had grown out of Engineering tended to be this way). UCB was definitely the latter, and that's what I wanted.

I got to UCB in fall 1980, admitted to the College of Letters & Science. At the time, there were two ways to get intro to programming:

CS1 - FORTRAN IV, taught on the CDC 6400 running CalidoSCOPE in batch mode with real punch cards, punched up on IBM 029 keypunch machines.

CS3 - Pascal, as Clem described.

CS1 was for engineers & scientists, CS3 for students who wanted to get into the CS degree program in L&S. You could take CS1 in lieu of CS3, but that was frowned upon.

Two paths to a computer science degree: A.B. CS from L&S, or B.S. EECS from the College of Engineering (which you had to be explicitly admitted to before you got there).

There was a basic difference in emphasis between L&S and Engineering for CS: L&S was "software with a smattering of hardware" (cf. CS-150, CS-152), and Engineering's EECS (B.S.) degree was the inverse: "hardware with a smattering of software."

L&S was the largest "college" at UCB: everyone got into that one "undeclared", and for your freshman & sophmore years, you studied to accumulate course credits towards declaring a major once you had "sophmore standing" (however, if you were prudent, you accumulated credits towards a "backup" major if the undergraduate degree program you wanted wouldn't/couldn't let you in). If you couldn't declare major at sophmore standing, you were bounced out of the university. Some of this setup was hangover from anti-student radical policies from the 1960s: prevent "students" from hanging around the university forever (and fomenting).

The "weeder" course for L&S CS was CS40: more Pascal than you'd ever want to code in a lifetime. L&S CS needed that filter: just before I got there, they'd let anyone into the program, but in 1980 or 1981, they limited the class size to 200 undergrads because there was too much demand from students for that degree program for the department to handle - didn't make the cut? I hope you have a backup major ...

They didn't formally teach C to undergrads until "upper division" (declared major in CS, junior or senior standing), and IIRC, there wasn't a formal course in it - you were expected to pick it up as part of the upper division course in operating systems. After all, you already know Pascal and Assembly, right?

Of course, once you had an account on one of the PDP-11/70s running Unix, C and shell programming was entirely available to you, so I went for what amounted to self-directed learning (reading manuals & books) as fast as I could.

	Erik

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 18:19 Noel Chiappa
  2022-02-01 18:47 ` Clem Cole
@ 2022-02-01 21:50 ` Win Treese
  1 sibling, 0 replies; 75+ messages in thread
From: Win Treese @ 2022-02-01 21:50 UTC (permalink / raw)
  To: The Unix Heritage Society


> On Feb 1, 2022, at 1:19 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
>> From: Clem Cole
> 
>> So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]
> 
> Not quite. The picture is complicated, because outside the EECS department,
> they all did their own thing - e.g. in the mid-70's I took a programming
> intro couse in the Civil Engineering department which used Fortran. But in
> EECS, in the mid-70's, their intro programming course used assembler
> (PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later
> on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used
> later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or
> if they did part of it in other languages.

I took 6.001 (with Scheme) in the spring of 1983, which was using a course
handout version of what became Structure and Interpretation of Computer
Programs by Sussman and Abelson. My impression was that it had been
around for a year before that, but not much more, and it was part of
revamping the EECS core curriculum at the time.

In at least the early 80s, CLU was used in 6.170, Software Engineering
Laboratory, in which a big project was writing a compiler.

And Fortran was still being taught for the other engineering departments.
In 1982(ish), those departments had the Joint Computing Facility for a lot
of their computing, of which the star then was a new VAX 11/782.

- Win


^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 21:21       ` Dan Cross
@ 2022-02-01 21:33         ` Clem Cole
  2022-02-01 23:12           ` John Cowan
  0 siblings, 1 reply; 75+ messages in thread
From: Clem Cole @ 2022-02-01 21:33 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

On Tue, Feb 1, 2022 at 4:22 PM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Feb 1, 2022 at 2:40 PM Clem Cole <clemc@ccc.com> wrote:
>
>> Dan - thanks.
>>
>
> Sure thing.
>
> By the way: the thing I was thinking about earlier that was so biting
> towards OOP was an earlier version of Harper's post, in which he writes,
> "Object-oriented programming is eliminated entirely from the introductory
> curriculum, because it is both anti-modular and anti-parallel by its very
> nature, and hence unsuitable for a modern CS curriculum."
> https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
> (How's _that_ for an academic glove-slap?)
>
Amen...

My disagreement with them using scripting (python) as step one is the lack
of teaching data typing early AND python's silly use space/tabs to set up
structure instead of  real {} or B/E blocks.  Automatic data conversion has
never been a good idea in my experience because like many things that
happen magically, it almost never works as I expect.

Funny we were discussing the roff family and that is why I like it over
things like Word -- way too much hidden behind the screen for my taste.
I'm a make it explicit kinda guy I guess.  I hate surprises ...

Also, it remains to be seen if teaching FP early helps - which they are
clearly making play.  Who am I to say, as one of the earliest languages I
learned APL, so FP thinking was drilled into me in my youth.

Clem

[-- Attachment #2: Type: text/html, Size: 3229 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 19:39     ` Clem Cole
@ 2022-02-01 21:21       ` Dan Cross
  2022-02-01 21:33         ` Clem Cole
  0 siblings, 1 reply; 75+ messages in thread
From: Dan Cross @ 2022-02-01 21:21 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

On Tue, Feb 1, 2022 at 2:40 PM Clem Cole <clemc@ccc.com> wrote:

> Dan - thanks.
>

Sure thing.

By the way: the thing I was thinking about earlier that was so biting
towards OOP was an earlier version of Harper's post, in which he writes,
"Object-oriented programming is eliminated entirely from the introductory
curriculum, because it is both anti-modular and anti-parallel by its very
nature, and hence unsuitable for a modern CS curriculum."
https://web.archive.org/web/20110321004746/https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
(How's _that_ for an academic glove-slap?)

It would appear that language was softened to read "unsuitable for our
purposes" sometime in 2013, and then that rather inflammatory clause was
removed entirely by early March, 2015. I had read the original and felt
some schadenfreude.

        - Dan C.

On Tue, Feb 1, 2022 at 2:10 PM Dan Cross <crossd@gmail.com> wrote:
>
>> On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:
>>
>>> [snip]
>>> FWIW:  Through the 60s, the early and into the later 70s, CMU used to
>>> call its 15-104 "Intro to Computer Programming" and was based on batch
>>> (card) computing using FTN4, later WATFIV.  They used a number of books.
>>> The book I had was from Waterloo and other than being blue and black in
>>> color, I remember little from it - since I already knew how and the TA let
>>> me take 'self-taught' by turning in assignments/taking the tests without
>>> going to class.  Like Freshman Physics and Calc, all intro science
>>> and engineering majors were required to take it however, since the
>>> engineering depts were sure what you would see when you graduated was FTN
>>> based code [which was probably true for the more pure Science types].
>>> Much later (many years after I left)  the CS Dept finally convinced Mat
>>> Sci, Chem E and Mech E to allow the course to be taught using Pascal.  I
>>> think they use either Java or Python now, but I haven't checked.
>>>
>>
>> There was a bit of a stir about 10 years ago when CMU switched from Java
>> (I think?) to Python and SML for introductory computer science education. I
>> remember reading a report at the time, which I _think_ is this:
>> http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf
>>
>> Though perhaps not, because it _really_ bit into Java and the whole OOP
>> thing.
>>
>> Robert Harper had a blog post that I found interesting about exposing
>> freshmen to functional programming:
>> https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
>>
>>         - Dan C.
>>
>>

[-- Attachment #2: Type: text/html, Size: 4449 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 19:10   ` Dan Cross
@ 2022-02-01 19:39     ` Clem Cole
  2022-02-01 21:21       ` Dan Cross
  0 siblings, 1 reply; 75+ messages in thread
From: Clem Cole @ 2022-02-01 19:39 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

Dan - thanks.
Clem

On Tue, Feb 1, 2022 at 2:10 PM Dan Cross <crossd@gmail.com> wrote:

> On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:
>
>> [snip]
>> FWIW:  Through the 60s, the early and into the later 70s, CMU used to
>> call its 15-104 "Intro to Computer Programming" and was based on batch
>> (card) computing using FTN4, later WATFIV.  They used a number of books.
>> The book I had was from Waterloo and other than being blue and black in
>> color, I remember little from it - since I already knew how and the TA let
>> me take 'self-taught' by turning in assignments/taking the tests without
>> going to class.  Like Freshman Physics and Calc, all intro science
>> and engineering majors were required to take it however, since the
>> engineering depts were sure what you would see when you graduated was FTN
>> based code [which was probably true for the more pure Science types].
>> Much later (many years after I left)  the CS Dept finally convinced Mat
>> Sci, Chem E and Mech E to allow the course to be taught using Pascal.  I
>> think they use either Java or Python now, but I haven't checked.
>>
>
> There was a bit of a stir about 10 years ago when CMU switched from Java
> (I think?) to Python and SML for introductory computer science education. I
> remember reading a report at the time, which I _think_ is this:
> http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf
>
> Though perhaps not, because it _really_ bit into Java and the whole OOP
> thing.
>
> Robert Harper had a blog post that I found interesting about exposing
> freshmen to functional programming:
> https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/
>
>         - Dan C.
>
>

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
@ 2022-02-01 19:39   ` Richard Salz
  2022-02-01 22:30   ` Erik E. Fair
  2 siblings, 0 replies; 75+ messages in thread
From: Richard Salz @ 2022-02-01 19:39 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

> Interesting .. I trust you, but I had thought ( famously) you folks had
> required a LISP and/or Scheme in the required "intro to computers" course
> using the Gerald  Sussman and Hal Abelson "Structure of Computer
> Programs" [Scheme IIRC] until it was finally replaced a few years ago
> with a Python based one [I thought it was tjt that told me that, but I
> could easily have been misled/misunderstood].
>

I think that wasn't until 1981.  I took 6.912, which was an experimental
pre-cursor to the SICP class as a sophomore.  We did LISP programming on
Multics. I might have the years off by one -- it was when "Fear of Music"
came out. :) The mainstream intro classes used Algol on a PDP-11 I think?
To emphasize Noel's point about the distributed nature, the intro to
programming class in the MechE department, 2.10, was Fortran first on punch
cards and then interactive when they got a big-ass DEC 20 running Digital
software. Amusingly MIT AI got one shortly after, and there was some
controversy about leaving TOPS-20 or converting it to ITS; ITS lost.

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 18:47 ` Clem Cole
@ 2022-02-01 19:10   ` Dan Cross
  2022-02-01 19:39     ` Clem Cole
  2022-02-01 19:39   ` Richard Salz
  2022-02-01 22:30   ` Erik E. Fair
  2 siblings, 1 reply; 75+ messages in thread
From: Dan Cross @ 2022-02-01 19:10 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list, Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On Tue, Feb 1, 2022 at 1:49 PM Clem Cole <clemc@ccc.com> wrote:

> [snip]
> FWIW:  Through the 60s, the early and into the later 70s, CMU used to call
> its 15-104 "Intro to Computer Programming" and was based on batch (card)
> computing using FTN4, later WATFIV.  They used a number of books.  The book
> I had was from Waterloo and other than being blue and black in color, I
> remember little from it - since I already knew how and the TA let me take
> 'self-taught' by turning in assignments/taking the tests without going to
> class.  Like Freshman Physics and Calc, all intro science and engineering
> majors were required to take it however, since the engineering depts were
> sure what you would see when you graduated was FTN based code [which was
> probably true for the more pure Science types].   Much later (many years
> after I left)  the CS Dept finally convinced Mat Sci, Chem E and Mech E to
> allow the course to be taught using Pascal.  I think they use either Java
> or Python now, but I haven't checked.
>

There was a bit of a stir about 10 years ago when CMU switched from Java (I
think?) to Python and SML for introductory computer science education. I
remember reading a report at the time, which I _think_ is this:
http://reports-archive.adm.cs.cmu.edu/anon/2010/CMU-CS-10-140.pdf

Though perhaps not, because it _really_ bit into Java and the whole OOP
thing.

Robert Harper had a blog post that I found interesting about exposing
freshmen to functional programming:
https://existentialtype.wordpress.com/2011/03/15/teaching-fp-to-freshmen/

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 2261 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
  2022-02-01 18:19 Noel Chiappa
@ 2022-02-01 18:47 ` Clem Cole
  2022-02-01 19:10   ` Dan Cross
                     ` (2 more replies)
  2022-02-01 21:50 ` Win Treese
  1 sibling, 3 replies; 75+ messages in thread
From: Clem Cole @ 2022-02-01 18:47 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2167 bytes --]

On Tue, Feb 1, 2022 at 1:19 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Clem Cole
>
>     > So by the late 70s/early 80s, [except for MIT where LISP/Scheme
> reigned]
>
> Not quite. The picture is complicated, because outside the EECS department,
> they all did their own thing -
>
Interesting .. I trust you, but I had thought ( famously) you folks had
required a LISP and/or Scheme in the required "intro to computers" course
using the Gerald  Sussman and Hal Abelson "Structure of Computer Programs"
[Scheme IIRC] until it was finally replaced a few years ago with a
Python based one [I thought it was tjt that told me that, but I could
easily have been misled/misunderstood].

FWIW:  Through the 60s, the early and into the later 70s, CMU used to call
its 15-104 "Intro to Computer Programming" and was based on batch (card)
computing using FTN4, later WATFIV.  They used a number of books.  The book
I had was from Waterloo and other than being blue and black in color, I
remember little from it - since I already knew how and the TA let me take
'self-taught' by turning in assignments/taking the tests without going to
class.  Like Freshman Physics and Calc, all intro science and engineering
majors were required to take it however, since the engineering depts were
sure what you would see when you graduated was FTN based code [which was
probably true for the more pure Science types].   Much later (many years
after I left)  the CS Dept finally convinced Mat Sci, Chem E and Mech E to
allow the course to be taught using Pascal.  I think they use either Java
or Python now, but I haven't checked.

On the other hand, at UCB the intro course was called CS-40 "Introduction
to Computing" which was required of all Letters and Science Majors.   When
I helped to teach it in the early 80s as a grad student, we could only
handle a thousand students and turned away over another thousand [for a
required undergrad course].   We used Clancy and Cooper's "Oh Pascal" as
the text and the UCB pi interpreter on the 11/70s running a flavor of V7 /
2BSD.  Before I got there, they must have taught it on the CDC machine
using FTN, but I'm not sure.

[-- Attachment #2: Type: text/html, Size: 3198 bytes --]

^ permalink raw reply	[flat|nested] 75+ messages in thread

* Re: [TUHS] ratfor vibe
@ 2022-02-01 18:19 Noel Chiappa
  2022-02-01 18:47 ` Clem Cole
  2022-02-01 21:50 ` Win Treese
  0 siblings, 2 replies; 75+ messages in thread
From: Noel Chiappa @ 2022-02-01 18:19 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Clem Cole

    > So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned]

Not quite. The picture is complicated, because outside the EECS department,
they all did their own thing - e.g. in the mid-70's I took a programming
intro couse in the Civil Engineering department which used Fortran. But in
EECS, in the mid-70's, their intro programming course used assembler
(PDP-11), Algol, and LISP - very roughly, a third of the time in each. Later
on, I think it used CLU (hey, that was MIT-grown :-). I think Scheme was used
later. In both of these cases, I have no idea if it was _only_ CLU/Scheme, or
if they did part of it in other languages.

	Noel

^ permalink raw reply	[flat|nested] 75+ messages in thread

end of thread, other threads:[~2022-02-10 15:21 UTC | newest]

Thread overview: 75+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-31 20:46 [TUHS] ratfor vibe Will Senn
2022-02-01 15:37 ` arnold
2022-02-01 15:52   ` Ralph Corderoy
2022-02-01 16:58     ` Clem Cole
2022-02-01 17:02     ` silas poulson
2022-02-02  7:47     ` arnold
2022-02-03  5:47       ` [TUHS] more about Brian Rich Morin
2022-02-03  7:44         ` markus schnalke
2022-02-03  8:18           ` Rich Morin
2022-02-04  2:23           ` Adam Thornton
2022-02-04  2:34             ` [TUHS] more about Brian... [really Rust] Jon Steinhart
2022-02-04 13:07               ` Thomas Paulsen
2022-02-04 23:18               ` Dan Cross
2022-02-04  3:28             ` [TUHS] more about Brian Dan Stromberg
2022-02-04  5:11             ` Rich Morin
2022-02-04 21:22               ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods
2022-02-04 21:37                 ` Richard Salz
2022-02-04 22:32                   ` Steffen Nurpmeso
2022-02-04 23:05                   ` Thomas Paulsen
2022-02-04 23:15                   ` Seth J. Morabito
2022-02-05  1:41                     ` Adam Thornton
2022-02-04  7:38             ` [TUHS] more about Brian Andy Kosela
2022-02-04  8:10               ` Steve Nickolas
2022-02-04  8:44                 ` markus schnalke
2022-02-04  9:16                   ` Steve Nickolas
2022-02-04 18:54                 ` John Cowan
2022-02-04 19:45                   ` Thomas Paulsen
2022-02-04 20:28                     ` Hellwig Geisse
2022-02-04 21:03                       ` Jim Capp
2022-02-04 22:30                         ` Steffen Nurpmeso
2022-02-04 22:25                       ` Steffen Nurpmeso
2022-02-06  0:56                       ` Larry McVoy
2022-02-06  1:10                         ` Will Senn
2022-02-06  4:52                           ` Rob Pike
2022-02-06  4:58                             ` Dan Halbert
2022-02-06  5:06                             ` Will Senn
2022-02-06  6:19                             ` Ed Carp
2022-02-06  6:27                               ` Rob Pike
2022-02-06  6:40                                 ` Stuart Remphrey
2022-02-06  6:44                                 ` Bakul Shah
2022-02-06 19:08                                   ` Steffen Nurpmeso
2022-02-06 12:52                                 ` Ralph Corderoy
2022-02-06 13:14                                 ` Ed Carp
2022-02-06 14:13                                   ` Dan Cross
2022-02-06 14:15                                   ` Larry McVoy
2022-02-06 16:31                                     ` Warner Losh
2022-02-06 18:36                                     ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart
2022-02-06 19:27                                     ` Jon Steinhart
2022-02-06 19:33                                       ` Warner Losh
2022-02-06 19:37                                         ` Jon Steinhart
2022-02-06 20:21                                           ` [TUHS] COFF is over there Ralph Corderoy
2022-02-06 16:16                           ` [TUHS] more about Brian Brad Spencer
2022-02-08  5:22                             ` Ed Carp
2022-02-03 18:57       ` [TUHS] ratfor vibe silas poulson
2022-02-04  8:26         ` arnold
2022-02-04 19:41           ` John Cowan
2022-02-10 15:18       ` Ralph Corderoy
2022-02-03  4:00 ` Will Senn
2022-02-03  4:31   ` Al Kossow
2022-02-03  5:16     ` Warner Losh
2022-02-03 20:00   ` Adam Thornton
2022-02-04  6:06     ` Ori Idan
2022-02-04 17:35       ` Adam Thornton
2022-02-04 17:44         ` Will Senn
2022-02-01 18:19 Noel Chiappa
2022-02-01 18:47 ` Clem Cole
2022-02-01 19:10   ` Dan Cross
2022-02-01 19:39     ` Clem Cole
2022-02-01 21:21       ` Dan Cross
2022-02-01 21:33         ` Clem Cole
2022-02-01 23:12           ` John Cowan
2022-02-01 19:39   ` Richard Salz
2022-02-01 22:30   ` Erik E. Fair
2022-02-02  0:54     ` Yeechang Lee
2022-02-01 21:50 ` Win Treese

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).