Re: [TUHS] roff(7) [ and other related stuff ]

Re: [TUHS] roff(7) [ and other related stuff ]

[Douglas McIlroy]

> Lisp, _that's_ elegant.

The machine shines through Lisp even more brightly than it does
through C. Lisp attains incredible power from a tiny base: car, cdr,
cons, cond, T, F, null, lambda, def, exuding elegance that survives
even in a raging sea of parentheses.

For Lisp-friendly applications nowadays, I prefer Haskell, which is
much further away from the machine. Haskell code approaches--and
sometimes surpasses--the cleanliness of good mathematical notation.
For string processing, I remember Snobol 3 with great fondness.

But for everyday work with arrays and numbers, C is the workhorse.
Still, I wish that C would evaluate comma expressions in parallel
rather than in series, as in (a,b) = (b,a).

Doug

Re: [TUHS] roff(7) [ and other related stuff ]

[markus schnalke]

Hoi.

[2022-01-01 23:02] jnc@mercury.lcs.mit.edu (Noel Chiappa)
>
>     > From: John Cowan
> 
>     > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax,
>     > extended to do what you wanted?
> 
> Why do all hammers look basically the same? Because there's an 'ideal
> hammer', and over time hammer design has asymtoted toward that 'ideal hammer'
> design.

Hammers don't look so much the same, except that each has a stick
and a head. Seems this example is a too simple one.

Saws for instance look quite differently, even within western
culture, but even more between western and japanese culture!


> So I suspect there is, to some degree, a Platonic 'ideal syntax' for a
> 'classic block-structured' programming language, and to me, C came pretty
> close to it.

I suspect that this assumption is limited to our programming
culture. We can hardly think outside of it. That's for the same
reason, Europeans did not create saws in Japanese style -- they
simply solved the same problems in a different way.

Thus I'd rather call it one of many possible good syntaxes for a
classic block-structured programming language ... and within our
culture about the best one.

But as well, in such views we obviously like to ignore the very
suboptimal `switch' (good for compilers; bad for programmers) and
the not so clean optional braces for single-statement blocks. C's
syntax is by no means as perfect, as we like to see it, but
nonetheless, it is very good. (And I like it a lot myself.)


Btw: With the rest of your message, I agree. Good that we're not
stuck with one syntax (and thus with one programming model)
forever. ;-)


meillo

Re: [TUHS] roff(7) [ and other related stuff ]

[Noel Chiappa]

    > From: John Cowan

    > Why use C syntax? What was wrong with Fortran, Lisp, or Cobol syntax,
    > extended to do what you wanted?

Why do all hammers look basically the same? Because there's an 'ideal
hammer', and over time hammer design has asymtoted toward that 'ideal hammer'
design. One can't just keep improving the design indefinitely - diminishing
returns set in.

So I suspect there is, to some degree, a Platonic 'ideal syntax' for a
'classic block-structured' programming language, and to me, C came pretty
close to it.

I except LISP from that assessment, because LISP is built around a
fundamentally different model of how computations/algorithms are organized,
and C and LISP aren't directly comparable.

But that realization points to a deeper bug with the 'Platonic ideal
language' concept above, which is that languages are fundamentally, albeit at
a very deep conceptual level, tied to the basic concept of the computing
hardware they are to run on. C/COBOL/FORTRAN/etc are all for von Neumann-like
(in a broad sense) computing engines - a single thread of computation, which
happens sequentially.

But we've pushed that paradigm about as far as it can go, we're into
diminishing returns territory on that one. The future, starting with the
hardware, will be very different - and will need quite different languages.
(Go, from what little I know of it, is a baby step in this direction - it is
intended to make it easy to use multiple simultaneous loci of execution,
making use of the mutiple cores that are common now.)

I suspect we'll be shifting to radically different paradigms, 50 years from
now - massively parallel computing meshes (think Connection Machines on
steroids - or the human brain), and those will use fundamentally different
computing paradigms, and programming languages for them, which in turn will
need very different syntax.

	Noel

Re: [TUHS] roff(7) [ and other related stuff ]

[Jon Steinhart]

I'm hoping that this doesn't devolved into another language preference war.
What I really wanted to discuss was the nature of adding value and maybe
nail down what's meant by value.  The roffians versus the texans was just
a good excuse.

One example to me is that while it has it's own thing, perl packages are
available via dnf/apt so one doesn't have to add extra steps to keep a
system up to date.  Things like pear and npm are negative value to me;
they're an extra step.  Maybe the mentality is that someone else maintains
the system and they just maintain their little corner.

My classic example is make.  Works pretty well, was missing a few things
that Sun and Gnu added later.  The negative value stuff is [a-z]make,
ninja, meson and all that.  Does about the same stuff but in an incompatible
way.

Re: [TUHS] roff(7) [ and other related stuff ]

[Warner Losh]

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

On Sat, Jan 1, 2022, 8:05 PM John Cowan <cowan@ccil.org> wrote:

>
>
> On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy <lm@mcvoy.com> wrote:
>
>
>> I'm almost speechless.  My progression was Basic, Pascal, C (and later
>> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess).  Then
>> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like
>> Rust, Go, D, and couldn't.
>>
>> If you think any of those other languages remotely approach the elegance
>> of C, I just don't know what to say.
>>
>
> Elegance?  C?  I think not.  Lisp, _that's_ elegant.
>

LISP is all about the syntax. It was completely opaque until that moment
when prefix notation clicked and it was all clear...

C is beautiful, you look at the code and you can see what the hardware
>> will be doing but it isn't assembler.
>
>
> Not really. You see what the hardware would be doing if it were a PDP-11.
> That's not the same thing at all.
>

Read the CHERI papers to find out that C is just doing approximately what
you want / think is going on... unless you've been burned by UB that you
thought you knew... At least compilers are getting stricter about flagging
it, much to the annoyance of anybody with a code base more than a couple
years old...

Warner

>

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

Re: [TUHS] roff(7) [ and other related stuff ]

[John Cowan]

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

On Sat, Jan 1, 2022 at 8:20 PM Larry McVoy <lm@mcvoy.com> wrote:


> I'm almost speechless.  My progression was Basic, Pascal, C (and later
> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess).  Then
> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like
> Rust, Go, D, and couldn't.
>
> If you think any of those other languages remotely approach the elegance
> of C, I just don't know what to say.
>

Elegance?  C?  I think not.  Lisp, _that's_ elegant.

C is beautiful, you look at the code and you can see what the hardware
> will be doing but it isn't assembler.


Not really. You see what the hardware would be doing if it were a PDP-11.
That's not the same thing at all.

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

Re: [TUHS] roff(7) [ and other related stuff ]

[Larry McVoy]

On Sat, Jan 01, 2022 at 08:47:11PM -0500, Steve Nickolas wrote:
> >If you think any of those other languages remotely approach the elegance
> >of C, I just don't know what to say.
> 
> This.
> 
> I think it blends terseness, cleanness, simplicity and ease of use in just
> the right quantities in a way no language before or since has really been
> able to muster.  Its only real weakness to me is that it isn't very good at
> string handling (the reason I sometimes kitbash stuff in BASIC still).

Function pointer decls drive me nuts.  

I agree with the string stuff, any scripting language handles that for
you behind the scenes.  C could add a String type that did all of that.
We did that by hand in BitKeeper and it worked great, it is completely
doable.

All of the warts aside, you could take C and extend it to do a bunch
of useful stuff and still have it be C.  We tried with little-lang.org
that is very C like but has almost all of the scripting goodness that
tcl has exposed in a C like way.  Check out the switch statement.
Check out regexp.  It's just part of the language, it is not function
calls.  Very pleasant and easy to use.  little as a programming 
language is pretty dead, but as a proof of concept, it should be
very much alive.

If I had more money, cough, Rob, Google does, I'd fund a dialect of C
that had all the C goodness and mixed in the right amount of scripting
goodness.  I'd come out of retirement to work on that.  And I say that as
this guy: http://mcvoy.com/lm/boat who is going out on the ocean tomorrow
for crab.  I love my retirement, I fish all the time, 60+ times per year,
I'm really not interested in going back to work.

But if someone threw a bunch of money at a team of people who wanted
to make C as fun as Perl (or Python, I get it, Perl isn't cool any more
but I loved the usefulness), I'd like to be Rob and Ken for that project,
this is a giant overreach but I think I could bring taste to that project.
If that ever happened, I think a lot of people on this list and elsewhere
would like the result.

Re: [TUHS] roff(7) [ and other related stuff ]

[Jon Steinhart]

Larry McVoy writes:
> On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote:
> > On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote:
> > > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they
> > > picked a different syntax.  Why not just use C syntax and extend it to do
> > > what you want?  Why must every project redo everything.
> > 
> > Why use C syntax?  What was wrong with Fortran, Lisp, or Cobol syntax,
> > extended to do what you wanted?
>
> I'm almost speechless.  My progression was Basic, Pascal, C (and later
> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess).  Then
> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like
> Rust, Go, D, and couldn't.  
>
> If you think any of those other languages remotely approach the elegance
> of C, I just don't know what to say.
>
> C is beautiful, you look at the code and you can see what the hardware
> will be doing but it isn't assembler.  It's what assembler wished it 
> could be.  It's the right mix of high enough that it works over all
> architectures and low enough that you see the hardware.
>
> You don't see the hardware with any of the other languages you listed.

I look at it slightly differently as the person who opened this particular
can of worms.

I'm not saying that the world should be fixed in stone; for example that
there should never be another language because we already have one.

I have trouble imagining how the features of C could be added to Fortran,
Lisp, or Cobol in a reasonably compatible manner.  And I have no issue
with C not being an extension of an existing language even though it uses
some of the features of other languages; to me C was the first non-clunky
programming language.  While I find C++ ugly, at least it uses C syntax
where possible making it a reasonable transition for programmers.

Going back to the original *roff discussion, I would have preferred to see
a ".2D" request for *roff that added two-dimensional formatting.

Guess what I'm saying is that I'm against change for the sake of change;
I'm not against innovation.

Re: [TUHS] roff(7) [ and other related stuff ]

[Steve Nickolas]

On Sat, 1 Jan 2022, Larry McVoy wrote:

> On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote:
>
>> Why use C syntax?  What was wrong with Fortran, Lisp, or Cobol syntax,
>> extended to do what you wanted?
>
> I'm almost speechless.  My progression was Basic, Pascal, C (and later
> Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess).  Then
> on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like
> Rust, Go, D, and couldn't.

Kinda sounds like me.  Classic Microsoft BASIC, then QBASIC which was a 
mutant freak dialect with structs, functions and stuff... started learning 
C++ and then moved to C.  I rarely use anything these days but C and once 
in a blue moon QBASIC for something quick and dirty.

> If you think any of those other languages remotely approach the elegance
> of C, I just don't know what to say.

This.

I think it blends terseness, cleanness, simplicity and ease of use in just 
the right quantities in a way no language before or since has really been 
able to muster.  Its only real weakness to me is that it isn't very good 
at string handling (the reason I sometimes kitbash stuff in BASIC still).

-uso.

Re: [TUHS] roff(7) [ and other related stuff ]

[Larry McVoy]

On Sat, Jan 01, 2022 at 08:04:58PM -0500, John Cowan wrote:
> On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote:
> > My big complaint with stuff like Rust, or even Go (sorry Rob), is that they
> > picked a different syntax.  Why not just use C syntax and extend it to do
> > what you want?  Why must every project redo everything.
> 
> Why use C syntax?  What was wrong with Fortran, Lisp, or Cobol syntax,
> extended to do what you wanted?

I'm almost speechless.  My progression was Basic, Pascal, C (and later
Fortran, Lisp, no Cobol, I did an Ada Compiler so Ada I guess).  Then
on to awk, perl, tcl, I tried to like C++ but couldn't, tried to like
Rust, Go, D, and couldn't.  

If you think any of those other languages remotely approach the elegance
of C, I just don't know what to say.

C is beautiful, you look at the code and you can see what the hardware
will be doing but it isn't assembler.  It's what assembler wished it 
could be.  It's the right mix of high enough that it works over all
architectures and low enough that you see the hardware.

You don't see the hardware with any of the other languages you listed.

Re: [TUHS] roff(7) [ and other related stuff ]

[John Cowan]

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

On Sat, Jan 1, 2022 at 7:13 PM Larry McVoy <lm@mcvoy.com> wrote:


> My big complaint with stuff like Rust, or even Go (sorry Rob), is that they
> picked a different syntax.  Why not just use C syntax and extend it to do
> what you want?  Why must every project redo everything.
>

Why use C syntax?  What was wrong with Fortran, Lisp, or Cobol syntax,
extended to do what you wanted?

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

Re: [TUHS] roff(7) [ and other related stuff ]

[Larry McVoy]

On Sat, Jan 01, 2022 at 12:00:15PM -0800, Jon Steinhart wrote:
> This is my biggest issue with "modern software development".  Seems like every
> project has to begin with it's own language, build system, package manager,
> and so on.  Were I a modern software developer I'd create all that plus a new
> email client just to send this message :-)  None of this behavior adds value.
> It makes it so that practitioners have to learn many arcane incompatible
> systems that all do pretty much the same thing.

This.  This is it.  You and I must be the same kind of weird because when
I wanted a scripting language that wasn't TCL weirdness, I had a compiler
built that compiled stuff that so looked like C, I had a guy fix a bug in
a patch that flew by.

My big complaint with stuff like Rust, or even Go (sorry Rob), is that they
picked a different syntax.  Why not just use C syntax and extend it to do
what you want?  Why must every project redo everything.

--lm who has moved to full on "Get off my lawn"

Re: [TUHS] roff(7) [ and other related stuff ]

[Jon Steinhart]

Larry McVoy writes:
> On Sat, Jan 01, 2022 at 09:07:49AM +1000, George Michaelson wrote:
> > But macros aside, anyone who had used runoff had a
> > massively simpler path into roff than TeX. My future was set. The phd
> > students at Leeds looked down their noses at me for using cryptic .2 letter
> > inline magic. They were the high priests of things, I was just a computer
> > operator.  Watching them spend weeks and weeks wrangling a one em offset
> > problem stopping perfection in print was.. entertaining.
>
> I was program committee chair for Linux Expo in 1999 (all that means is
> I formatted the proceedings into a book).  I let people use LaTex but
> encouraged troff.  A few people tried out troff and their reaction was
> "Wow, that was so easy and groff is really fast!"
>
> The only negative reaction was table of contents complaints, LaTex is
> 2 pass so it can do them, roff is one pass so you have to fiddle with
> things.  A lot.
>
> I've used *roff for almost 40 years and I've never had the urge to use
> something else.  I wrote a paper a while back where they insisted on
> LaTex and it just made me like *roff more.
>
> It's Betamax and VHS all over again, the crappy answer won.

Happy New Year to everybody.  COVID has taken its toll if people are
spending New Year's Eve thinking about text formatting :-)  Warning - this
is a grumpy pendantic Jon post...

First of all, I love *roff.  It's the thing that got me started on UNIX when
I needed to write documentation for my first summer project at BTL.  There was
a V3 UNIX machine across the hall from my lab (2C-517?) that I used for that.
Been a fan ever since.

Complaints about things like tables of contents are just that - complaints.
C'mon - this is UNIX, composable software tools.  So what if LaTex is 2 pass
and *roff is 1 pass.  I have a simple script and a Makefile that adds a 2nd
pass and does all that.  Even with that the LaTex ecosystem is way more
complex than *roff.

The one thing that *roff doesn't do which I think I remember from runoff is
that runoff allowed in-line formatting requests; not just special escape
sequences but everything.

I never got into TeX although I've tried.  Probably just first language
syndrome.  Coming from UNIX, I just find using \ as a non-escape character
ugly, just like DOS\Windows pathnames.  But there are a number of things
that annoy me about it leading to the pendantic part.

In my opinion, the big innovation in TeX is the two-dimensional layout.  I
do spend a bit of time on big documents adding keeps and such to avoid orphan
and widow lines.

In my opinion, much of what Don did in TeX added no value.  Been meaning to
ask him about it but with COVID haven't seen him in a while.  For example,
the language parsing broke no new ground.  If it were me, and I wanted to
explore/demo/implement two-dimensional layout, I would have added it to *roff.
To me, the rest of it was not only a waste of time, but actually made the
world worse by making two incompatible ways of doing things that practitioners
have to learn instead of one.  Make's life harder, not easier.

How much time went into the development of the TeX front end that could have
been done in a few hours had Don used lex/yacc?  I made a similar comment to
Alan Wirfs-Brock when proofreading his big 20th anniversary article on
JavaScript.  I don't get the "oooo, Eich did this one-week sprint to get a
demo up and running" stuff.  Had Eich used lex/yacc instead of rolling his
own not only would he have not had to sprint, but we likely wouldn't still be
fighting with optional semicolons decades later since that's harder to do with
those tools.  I read it as praising him for making a bad decision.

This is my biggest issue with "modern software development".  Seems like every
project has to begin with it's own language, build system, package manager,
and so on.  Were I a modern software developer I'd create all that plus a new
email client just to send this message :-)  None of this behavior adds value.
It makes it so that practitioners have to learn many arcane incompatible
systems that all do pretty much the same thing.

While I haven't given it a hard look, I'd look at the netstat/ss/... stuff
with the same lens.  Sure, new features were needed, but was it necessary
to make the old stuff work differently?

In my roll as a mentor, this is the stuff that freaks out students, especially
during their first internships.  I have to explain that there are two types of
knowledge at play: their coursework and company crap.  I tell them that they
should be secure in the quality of their education and never ask their boss
how to copy a string or something like that.  But, it's perfectly OK to ask for
help on the internal undocumented crufty development environment.

In some respects, it's similar to how I decide what to bill for and what not
to on consulting projects.  I don't bill for learning some general knowledge
thing that I didn't know.  I do bill for learning odd project-specific
weirdness that I'll never use on anything else.

Back to *roff.  Might have said this before, but pic is probably my favorite
little language.  It's like having an artist on staff because I can tell it
what to draw and it will; I'm terrible at drawing.  One of its best features
that unfortunately was missed by the people who wrote fig is invisible
objects.  I typically start a figure with a big invisible box and hang things
on it.  If I need to move or scale things I just change the size of the box.
Sure beats hours of carpal-tunnel clicking to move a pile of objects in a
drawing program.  I guess it's relative addressing versus absolute all over
again; relative addressing makes it easier to relocate objects.

One more way to look at this.  I think that a lot depends on the state of the
world when one starts using stuff.  I remember a friend of mine telling me how
much simpler DOS was as compared to UNIX.  I told him that I thought that it
was because he was growing up with DOS, and learned new features as they came
along which is what I did with UNIX.  By the the time he got started UNIX was
more complicated.  Of course, DOS caught up.

It's sadly amusing how this applies to markup languages.  People who carped
about *roff requests are happy to craft HTML.

I guess what's missing from the field is Lorites from Neal Stephenson's Anathem
if you haven't read it.  A priesthood who's role is to inform people claiming
to invent something new that it's already been done.

Jon