[TUHS] Re: python

[TUHS] Re: python

[Noel Chiappa]

How is discussing Python's output options related to the history of Unix?

	Noel

[TUHS] Re: python

[Larry McVoy]

Perhaps it is a stretch, but I'd say that printf() is a good example of
the type of thinking done by the original Unix folks.  Seeing how other
people didn't learn that lesson kind of underscores the good engineering
done at Bell Labs.

On Fri, Aug 04, 2023 at 04:11:02PM -0400, Noel Chiappa wrote:
> How is discussing Python's output options related to the history of Unix?
> 
> 	Noel

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: python

[Adam Thornton]

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

I think it's again helpful to consider golang as "roughly as modern as
Python, but definitely more C-inspired".

The thing that Python f-strings do (other than allow interpolation of
arbitrary code to be executed, which can be very handy) is that they
generally provide a sane default representation of the value you want.  For
instance, you can say:

print(f"Value of foo == {foo}") and you get either something sane if foo is
a primitive type, or you get whatever foo's __str__() method gives you if
it's an instance of a class; the default class general does something
not-terrible with that, but you can add __str__() and __repr__() if you
have opinions about how you want to represent your class when printed for
humans or for machine consumption (effectively, __repr__() should let you
reconstruct the object, while __str__() is for display to humans).

This overcomes something C doesn't easily let you do.  Most of the time I'd
rather not have to care whether the thing I'm printing is a string, or a
pointer, or an integer, or whatever: I just want to see its value.

Go has %v for exactly this.  It's very nice for debugging.

On Fri, Aug 4, 2023 at 1:15 PM Larry McVoy <lm@mcvoy.com> wrote:

> Perhaps it is a stretch, but I'd say that printf() is a good example of
> the type of thinking done by the original Unix folks.  Seeing how other
> people didn't learn that lesson kind of underscores the good engineering
> done at Bell Labs.
>
> On Fri, Aug 04, 2023 at 04:11:02PM -0400, Noel Chiappa wrote:
> > How is discussing Python's output options related to the history of Unix?
> >
> >       Noel
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>

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

[TUHS] Re: python

[Norman Wilson]

At the risk of releasing more heat than light (so if you feel
compelled to flame by this message, please reply just to me
or to COFF, not to TUHS):

The fussing here over Python reminds me very much of Unix in
the 1980s.  Specifically wars over editors, and over BSD vs
System V vs Research systems, and over classic vs ISO C, and
over embracing vendor-specific features (CSRG and USG counting
as vendors as well as Digital, SGI, Sun, et al) vs sticking
to the common core.  And more generally whether any of the
fussing is worth it, and whether adding stuff to Unix is
progress or just pointless complication.

Speaking as an old fart who no longer gets excited about this
stuff except where it directly intersects something I want to
do, I have concluded that nobody is entirely right and nobody
is entirely wrong.  Fancy new features that are there just to
be fancy are usually a bad idea, especially when they just copy
something from one system to a completely different one, but
sometimes they actually add something.  Sometimes something
brand new is a useful addition, especially when its supplier
takes the time and thought to fit cleanly into the existing
ecosystem, but sometimes it turns out to be a dead end.

Personal taste counts, but never as much as those of us
brandishing it like to think.

To take Python as an example: I started using it about fifteen
years ago, mostly out of curiousity.  It grew on me, and these
days I use it a lot.  It's the nearest thing to an object-
oriented language that I have ever found to be usable (but I
never used the original Smalltalk and suspect I'd have liked
that too).  It's not what I'd use to write an OS, nor to do
any sort of performance-limited program, but computers and
storage are so fast these days that that rarely matters to me.

Using white space to denote blocks took a little getting used
to, but only a little; no more than getting used to typing
if ...: instead of if (...).  The lack of a C-style for loop
occasionally bothers me, but iterating over lists and sets
handles most of the cases that matter, and is far less cumbersome.
It's a higher-level language than C, which means it gets in the
way of some things but makes a lot of other things easier.  It
turns out the latter is more significant than the former for
the things I do with it.

The claim that Python doesn't have printf (at least since ca. 2.5,
when I started using it) is just wrong:
	print 'pick %d pecks of %s' % (n, fruit)
is just a different spelling of
	printf("pick %d pecks of %s\n", n, fruit)
except that sprintf is no longer a special case (and snprintf
becomes completely needless).  I like the modern
	print(f'pick {n} pecks of {fruit}')
even better; f strings are what pushed me from Python 2 to
Python 3.

I really like the way modules work in Python, except the dumbass
ways you're expected to distribute a program that is broken into
modules of its own.  As a low-level hacker I came up with my own
way to do that (assembling them all into a single Python source
file in which each module is placed as a string, evaled and
inserted into the module table, and then the starting point
called at the end; all using documented, stable interfaces,
though they changed from 2 to 3; program actually written as
a collection of individual source files, with a tool of my
own--written in Python, of course--to create the single file
which I can then install where I need it).

I have for some years had my own hand-crafted idiosyncratic
program for reading mail.  (As someone I know once said,
everybody writes a mailer; it's simple and easy and makes
them feel important.  But in this case I was doing it just
for myself and for the fun of it.)  The first edition was
written 20 years ago in C.  I rewrote it about a decade ago
in Python.  It works fine; can now easily deal with on-disk
or IMAP4 or POP3 mailboxes, thanks both to modules as a
concept and to convenient library modules to do the hard work;
and updating in the several different work and home environments
where I use it no longer requires recompiling (and the source
code need no longer worry about the quirks of different
compilers and libraries); I just copy the single executable
source-code file to the different places it needs to run.

For me, Python fits into the space between shell scripts and
awk on one hand, and C on the other, overlapping some of the
space of each.

But personal taste is relevant too.  I didn't know whether I'd
like Python until I'd tried it for a few real programs (and
even then it took a couple of years before I felt like I'd
really figured out out to use it).  Just as I recall, about
45 years ago, moving from TECO (in which I had been quite
expert) to ed and later the U of T qed and quickly feeling
that ed was better in nearly every way; a year or so later,
trying vi for a week and giving up in disgust because it just
didn't fit my idea of how screen editors should work; falling
in love with jim and later sam (though not exclusively, I still
use ed/qed daily) because they got the screen part just right
even if their command languages weren't quite such a good match
for me.

And I have never cottoned on to Perl for, I suspect, the same
reason I'd be really unhappy to go back to TECO.  Tastes
evolve.  I bet there's a lot of stuff I did in the 1980s that
I'd do differently could I have another go at it.

The important thing is to try new stuff.  I haven't tried Go
or Rust yet, and I should.  If you haven't given Python or
Perl a good look, you should.  Sometimes new tools are
useless or cumbersome, sometimes they are no better than
what you've got now, but sometimes they make things easier.
You won't know until you try.

Here endeth today's sermon from the messy office, which I ought
to be cleaning up, but preaching is more fun.

Norman Wilson
Toronto ON

[TUHS] Re: python

[Ed Bradford]

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

Very nice serman, Norman. I moved from (cb unix) BTL C (1976) to C++ to
Java to PHP and JavaScript to Python. I never went for the object oriented
view but loved C++'s strict type checking.

I got very frustrated with the active support for Python2 and Python3
versions and vacationed
for several years. Then Python went out of the Python 2 support
business and I started using
Python again. Over the span of all those languages Python 3 has supported
almost anything
I could think of with free downloadable modules. That has happened nowhere
I have ever seen.

I also struggled with writing and supporting print functions where the
variables were
in one place and the formats for them were in another place.
Python3's f-strings reduced
my strings substantially. Now the format and variable can be defined in one
place and used in lots of places.

That is a huge help to me for documentation and support.

That's my two cents.

Thanks for your thoughts

Ed Bradford
Pflugerville, TX
egbegb2@gmail.com

PS: Has anyone else but me on this list tried chatGPT generated python
programs? We should
move such a conversation elsewhere, but I simply don't know where. Email me
if you
want to start a discussion on this topic in a more appropriate place.



On Sun, Aug 6, 2023 at 2:46 PM Norman Wilson <norman@oclsc.org> wrote:

> At the risk of releasing more heat than light (so if you feel
> compelled to flame by this message, please reply just to me
> or to COFF, not to TUHS):
>
> The fussing here over Python reminds me very much of Unix in
> the 1980s.  Specifically wars over editors, and over BSD vs
> System V vs Research systems, and over classic vs ISO C, and
> over embracing vendor-specific features (CSRG and USG counting
> as vendors as well as Digital, SGI, Sun, et al) vs sticking
> to the common core.  And more generally whether any of the
> fussing is worth it, and whether adding stuff to Unix is
> progress or just pointless complication.
>
> Speaking as an old fart who no longer gets excited about this
> stuff except where it directly intersects something I want to
> do, I have concluded that nobody is entirely right and nobody
> is entirely wrong.  Fancy new features that are there just to
> be fancy are usually a bad idea, especially when they just copy
> something from one system to a completely different one, but
> sometimes they actually add something.  Sometimes something
> brand new is a useful addition, especially when its supplier
> takes the time and thought to fit cleanly into the existing
> ecosystem, but sometimes it turns out to be a dead end.
>
> Personal taste counts, but never as much as those of us
> brandishing it like to think.
>
> To take Python as an example: I started using it about fifteen
> years ago, mostly out of curiousity.  It grew on me, and these
> days I use it a lot.  It's the nearest thing to an object-
> oriented language that I have ever found to be usable (but I
> never used the original Smalltalk and suspect I'd have liked
> that too).  It's not what I'd use to write an OS, nor to do
> any sort of performance-limited program, but computers and
> storage are so fast these days that that rarely matters to me.
>
> Using white space to denote blocks took a little getting used
> to, but only a little; no more than getting used to typing
> if ...: instead of if (...).  The lack of a C-style for loop
> occasionally bothers me, but iterating over lists and sets
> handles most of the cases that matter, and is far less cumbersome.
> It's a higher-level language than C, which means it gets in the
> way of some things but makes a lot of other things easier.  It
> turns out the latter is more significant than the former for
> the things I do with it.
>
> The claim that Python doesn't have printf (at least since ca. 2.5,
> when I started using it) is just wrong:
>         print 'pick %d pecks of %s' % (n, fruit)
> is just a different spelling of
>         printf("pick %d pecks of %s\n", n, fruit)
> except that sprintf is no longer a special case (and snprintf
> becomes completely needless).  I like the modern
>         print(f'pick {n} pecks of {fruit}')
> even better; f strings are what pushed me from Python 2 to
> Python 3.
>
> I really like the way modules work in Python, except the dumbass
> ways you're expected to distribute a program that is broken into
> modules of its own.  As a low-level hacker I came up with my own
> way to do that (assembling them all into a single Python source
> file in which each module is placed as a string, evaled and
> inserted into the module table, and then the starting point
> called at the end; all using documented, stable interfaces,
> though they changed from 2 to 3; program actually written as
> a collection of individual source files, with a tool of my
> own--written in Python, of course--to create the single file
> which I can then install where I need it).
>
> I have for some years had my own hand-crafted idiosyncratic
> program for reading mail.  (As someone I know once said,
> everybody writes a mailer; it's simple and easy and makes
> them feel important.  But in this case I was doing it just
> for myself and for the fun of it.)  The first edition was
> written 20 years ago in C.  I rewrote it about a decade ago
> in Python.  It works fine; can now easily deal with on-disk
> or IMAP4 or POP3 mailboxes, thanks both to modules as a
> concept and to convenient library modules to do the hard work;
> and updating in the several different work and home environments
> where I use it no longer requires recompiling (and the source
> code need no longer worry about the quirks of different
> compilers and libraries); I just copy the single executable
> source-code file to the different places it needs to run.
>
> For me, Python fits into the space between shell scripts and
> awk on one hand, and C on the other, overlapping some of the
> space of each.
>
> But personal taste is relevant too.  I didn't know whether I'd
> like Python until I'd tried it for a few real programs (and
> even then it took a couple of years before I felt like I'd
> really figured out out to use it).  Just as I recall, about
> 45 years ago, moving from TECO (in which I had been quite
> expert) to ed and later the U of T qed and quickly feeling
> that ed was better in nearly every way; a year or so later,
> trying vi for a week and giving up in disgust because it just
> didn't fit my idea of how screen editors should work; falling
> in love with jim and later sam (though not exclusively, I still
> use ed/qed daily) because they got the screen part just right
> even if their command languages weren't quite such a good match
> for me.
>
> And I have never cottoned on to Perl for, I suspect, the same
> reason I'd be really unhappy to go back to TECO.  Tastes
> evolve.  I bet there's a lot of stuff I did in the 1980s that
> I'd do differently could I have another go at it.
>
> The important thing is to try new stuff.  I haven't tried Go
> or Rust yet, and I should.  If you haven't given Python or
> Perl a good look, you should.  Sometimes new tools are
> useless or cumbersome, sometimes they are no better than
> what you've got now, but sometimes they make things easier.
> You won't know until you try.
>
> Here endeth today's sermon from the messy office, which I ought
> to be cleaning up, but preaching is more fun.
>
> Norman Wilson
> Toronto ON
>


-- 
Advice is judged by results, not by intentions.
  Cicero

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

[TUHS] Re: python

[Douglas McIlroy]

> Most of the time I'd rather not have to care whether the thing
> I'm printing is a string, or a pointer, or an integer, or whatever:
> I just want to see its value.

> Go has %v for exactly this.  It's very nice for debugging.

Why so verbose? In Basic, PRINT required no formatting directives at all.

Doug

[TUHS] Re: python

[Dan Cross]

On Fri, Aug 4, 2023 at 5:17 PM Douglas McIlroy
<douglas.mcilroy@dartmouth.edu> wrote:
> > Most of the time I'd rather not have to care whether the thing
> > I'm printing is a string, or a pointer, or an integer, or whatever:
> > I just want to see its value.
>
> > Go has %v for exactly this.  It's very nice for debugging.
>
> Why so verbose? In Basic, PRINT required no formatting directives at all.

There is a form in Go that doesn't require the "%v"s.

: chandra; cat v.go
package main

import "fmt"

func main() {
        fmt.Println("Hi", "there", "world", "pi is close to", 3.14159)
}
: chandra; go run v.go
Hi there world pi is close to 3.14159
: chandra;

I believe that `%v` exists so that one can compose it with other
formatting directives of various kinds; perhaps one wants to print the
string representation of an object with no additional ceremony, but
wants to emit a number in some specific format.

        - Dan C.

[TUHS] Re: python

[Rob Pike]

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

And neither does go.
   fmt.Print(x)
prints x, using its default format, which is not coincidentally available
in Printf as %v.

-rob


On Sat, Aug 5, 2023 at 7:17 AM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > Most of the time I'd rather not have to care whether the thing
> > I'm printing is a string, or a pointer, or an integer, or whatever:
> > I just want to see its value.
>
> > Go has %v for exactly this.  It's very nice for debugging.
>
> Why so verbose? In Basic, PRINT required no formatting directives at all.
>
> Doug
>

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

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Erik E. Fair]

	Date: Mon, 31 Jul 2023 09:34:56 +1000
	From: George Michaelson <ggm@algebras.org>

	[...]

	Execute on read is just awful. But, now we have HTML to track "they
	read it" through URL fetch.

And then the utterly disastrous: JavaScript. It should be *eliminated*
from the WWW as the gross security violation it is.

	"don't run software from strangers",

	Erik Fair

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Erik E. Fair]

	Date: Tue, 1 Aug 2023 05:22:17 -0400
	From: Marc Donner <marc.donner@gmail.com>

	Nathaniel (Mr Mime) Borenstein came up with something (atomicmail?)
	that was intended to be more functional than raw text but safer
	than free execution of unknown code. I disremember the details.
	I don't think it ever got traction.


You remember correctly. It got stomped by those of us in the IETF MIME working group with approximately the same forceful negative reaction as you've seen here to Mike Lesk's idea of instantly executed Unix commands in e-mail.

I'm hardly innocent of this - while writing & operating the AppleLink/Internet e-mail gateway at Apple in the 1990s, I discovered that I could download the entire user directory from AppleLink (over 50k users: all Apple employees, Apple 3rd-party developers, Apple retail dealers - the whole "Apple Federation" at that time was on AppleLink), which included both usernames and "full name" fields, which could provide the basis for an AppleLink directory lookup service on the Internet. I figured it'd be easy to use FINGER & WHOIS as the protocol ports since the outputs of those are basically unstructured (unspecified) ASCII text, e.g. "finger fair@applelink.apple.com" would return a list of all usernames and full names matching "fair".

I was writing in Perl because e-mail gatewaying is primarily about string handling, and it sucks to write in C for that. The best performing way to implement the text search was to use its eval() function with a regex constructed from the network protocol input. I tested it, and it worked great, but I bet you can guess where this is going - how to perfectly sanitize the search term inputs taken directly from the net so they don't become arbitrary Perl code?

I never deployed it, partly because I couldn't convince myself I'd made the service completely secure, and partly as a privacy matter: finger (especially after the 1989 Morris Worm & the increasing amounts of e-mail spam) was not a service that sites were offering any longer because there were too many bad actors on the Internet, and it just wasn't a good idea to be as open & trusting as the ARPANET had been. I lament the passing of that culture from time to time.

I think anyone with a modicum of experience in computer & systems security can instantly recognize the dangers in executable code transmitted unsolicited to unwary recipients and automatically executed without prior, explicit permission, and works to stop anything along those lines from becoming standard practice because, despite all the protestations that "it's run in a sandbox, it's safe!", the proponents can never prove their case beyond reasonable doubt.

How many bugs were discovered in the "restricted shell" (rsh) over the years?

Sometimes we fail to prevent such bad ideas from being implemented: JavaScript in HTML/HTTP is one such. What concerns me these days is how often JavaScript is showing up in text/html e-mail. At least visiting a website (URL) with a web browser is, to some degree, an act of volition. Particularly with MIME, Internet e-mail has to be parsed and presented (and which HTML parsers these days do not also include a JavaScript interpreter?), not merely spewed to a presumed-ASCII (OK, UTF-8) terminal. Even simple spew could be dangerous: who remembers "intelligent terminal" transmit-back codes and the mischief those caused?

IIRC, the question we posed to Nathaniel was: "do we really want to enable letter bombs?"

Some of us also remembered (and possibly referenced) the UNAbomber.

	Erik

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Dave Horsfall]

On Tue, 1 Aug 2023, Erik E. Fair wrote:

> Even simple spew could be dangerous: who remembers "intelligent 
> terminal" transmit-back codes and the mischief those caused?

ASCII bombs were fairly popular in the old MS-DOS BBS days (format the 
disk, anyone?), and it was possible over packet radio too (sort of a BBS 
via Amateur i.e. "ham" radio).

-- Dave (vk2kfu)

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Ron Natalie]

ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)?

https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ

It seems to have lost something in the formatting (the leading spaces 
were all removed).



------ Original Message ------
From "Dave Horsfall" <dave@horsfall.org>
To "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Date 8/1/23, 8:37:20 PM
Subject [TUHS] Re: Cool talk on Unix and Sendmail history, by Eric 
Allman

>On Tue, 1 Aug 2023, Erik E. Fair wrote:
>
>>  Even simple spew could be dangerous: who remembers "intelligent
>>  terminal" transmit-back codes and the mischief those caused?
>
>ASCII bombs were fairly popular in the old MS-DOS BBS days (format the
>disk, anyone?), and it was possible over packet radio too (sort of a BBS
>via Amateur i.e. "ham" radio).
>
>-- Dave (vk2kfu)

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Grant Taylor via TUHS]

On 8/2/23 9:52 AM, Ron Natalie wrote:
> ASCII Bombs?   Like my Letter Bomb Transport Protocol (LBTP)?
> 
> https://groups.google.com/g/net.followup/c/OJBALbzTq4w/m/LoxMnbz0bwMJ

~chuckle~

> It seems to have lost something in the formatting (the leading spaces 
> were all removed).

Ya....

People think I'm weird for not liking languages that use white space as 
structural definition.  Frequently those people have not experienced 
such a failure as what has happened to your ASCII Bomb.



Grant. . . .

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[segaloco via TUHS]

> People think I'm weird for not liking languages that use white space as
> structural definition.
>
> Grant. . . .

This is my chief gripe with Python, although on the flip side Python isn't the right language anyway for most scenarios where I use whitespace/indentation to imply structure the language itself can't articulate.  It's meant for mainly functional programming as I understand it so the structure does enforce some stylistic practices conducive to good functional programming.  Still a shame to force a particular style approach by default rather than just strongly suggest it.

What strikes me particularly odd about the Python case is that its not like that space-sensitivity evolved out of the same line of reasoning as the compulsory spacing in FORTRAN, COBOL, etc.  It seems mainly to be a way to operate without code blocks, with the "blocks" being implied by indentation rather than braces, parens, or some other delimiter.

In UNIX of course we have our own little variation on this problem with make(1) and the need to tab out the rule definition.  I seem to recall reading somewhere (perhaps Doug's McIlroy's UPM excerpts) that that Stu Feldman considered undoing that but there were already users who that would've caused trouble for, so make's early, entrenched adoption stymied attempts at the time to rectify this.  Anyone with better details feel free to correct me.

- Matt G.

P.S. This answer can be off list or spin off a separate thread for make junkies, but did any AT&T or BSD revision of make(1) support rule names coming from variables rather than explicitly entered?

For instance:

$(BIN): $(OBJS)
    $(CC) $(LDFLAGS) -o $(BIN) $(OBJS) $(LIBS)

I used to use this in makefiles but at some point, I think with one of the BSDs, it balked at the idea of a variable rule name and so it fell out of my practice in trying to avoid GNUisms.

It's been a while but I feel like I ran through and tried this on V7, System III, and PDP-11 System V and all of them were unhappy about that construct.  I can try and get on the LCMs 3B400 later to see what SVR3 does.  I don't remember which of the BSDs (if not multiple) I ran into that issue on initially, but I can't imagine one of the major streams would work that in without the other two wanting to copy their notes.

Maybe an alternative question is if folks are aware of make implementations besides GNU that *do* support that sort of thing.

[TUHS] Re: Cool talk on Unix and Sendmail history, by Eric Allman

[Rich Salz]

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

> [Python is] meant for mainly functional programming as I understand it

Not true. It has some neat functional features (list comprehensions) but
that's not really its intent.

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

[TUHS] Re: python

[Larry McVoy]

On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> > [Python is] meant for mainly functional programming as I understand it
> 
> Not true. It has some neat functional features (list comprehensions) but
> that's not really its intent.

I've really tried to like python but any language that doesn't has printf
as builtin is not for me.  Yes, I know about their library printf but it
is weird.  
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: python

[George Michaelson]

Python has limited support for map/reduce patterns, and cannot
implement lazy eval.  It's functional support is no different to any
classical language with an ability to apply a function over data and
you can curry to your hearts content if you can define functions over
functions (as arguments)

Guido is on record as saying he didn't aim it as an FP language. I
wouldn't cast him an FP hater, I think thats a silly concept anyway.

I tried to learn a real FP language. It's hard to think in new ways. I
wish I'd started sooner because I do believe the stories about the
upside of investing in strong types (which are not unique to FP but
are a mainstay of most of the FP which have succeeded in breaking
through)

The resurgence of chatter about Common LISP says something to me. I'm
not sure what, possibly "all those LISP-like turn out not to be as
good as they said" but there's also a resurgence in OCAML in the same
places.

I think the fusion of UNIX and FP was sort of a road not taken. Yes,
there's lots of LISP and GHC. No, it's really an ecosystem "on top"
and there are some grumpy edges to coding in FP to deploy on UNIX.

Maybe it's no worse a fit than "containers" and after all, we're in
Kubernetes because of Plan9, right?

G

[TUHS] Re: python

[Bakul Shah]

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

On Aug 2, 2023, at 6:20 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> Maybe it's no worse a fit than "containers" and after all, we're in
> Kubernetes because of Plan9, right?

Wait, what? How did Plan9 beget Kubernetes? plan9 namespaces are wonderful, while kubernetes.... 

But this made me do some googling and I found "K9P: Kubernetes as 9P files" YT video.

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

[TUHS] Re: python

[segaloco via TUHS]

> The resurgence of chatter about Common LISP says something to me.
> 
> G

LISP is one of those things I always say I'm going to go study more, try and understand the implications of, but it continues to be so far afield from the typical realms I work in that I just haven't found that catch point to get me more interested in it.  That said, there is a little voice in that same part of my brain whispering about exploring FP for creating software polygon rendering stuff, which right now I only really work with through the OpenGL and video game console lenses.  Probably the closest I got to something LISPy was futzing with some Guile stuff pertaining to GDB.

Also pardon the whole "Python's a functional language I am very smart about things", that's based on plenty of commentary I've heard and read, not any sort of formal analysis or research.  Feel free to call me out anywhere you think I might be parroting (inaccurate) common sentiment about things I have tangential understanding of, I try not to but sometimes it just still crops up in casual chit chat :P

To attempt a tie-back to TUHS, has anyone here ever tried to bring up bits of Python on a historic UNIX implementation?

- Matt G.

[TUHS] Re: python

[George Michaelson]

Tail recursion not lazy eval.

I wish words meant what I meant "inside" when I think them, not
"outside" what they mean when I write them.

[TUHS] Re: python

[Warner Losh]

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

On Wed, Aug 2, 2023, 9:24 PM George Michaelson <ggm@algebras.org> wrote:

> Tail recursion not lazy eval.
>
> I wish words meant what I meant "inside" when I think them, not
> "outside" what they mean when I write them.
>

Python is an ugly ass language to be sure. It's a useful tool. I have this
rather ugly axe. I've split a lot of wood with it. Chopped down nasty
weeds. Pounded in nails, spikes, landscaping staples, and the odd screw or
two. I've cut impromptu joints to make lean too structures that I threw
painter's tarps over to save the tomatoes from frost. And maybe a dozen
other things. But to do framing or naked furniture, I use different tools
more suited for those specific tasks... but the axe still has its uses...
much like python...

Warner

>

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

[TUHS] Re: python

[Bakul Shah]

python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. 

> On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm@algebras.org> wrote:
> 
> Tail recursion not lazy eval.
> 
> I wish words meant what I meant "inside" when I think them, not
> "outside" what they mean when I write them.

[TUHS] Re: python

[Rob Pike]

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

I once inherited maintenance of a critical piece of infrastructure written
in exquisitely well written, tested, and documented Python. I mean it, it
was really really good.

It crashed about once a week and I had to fix it over and over because in
those exponentially vast combinations of paths through the code would arise
yet another way to turn a string into a list, or something analogous. It
was hell.

Critical code needs static typing.

-rob


On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org> wrote:

> python can certainly implement tail call optimization (TCO). Pretty much
> any language can implement TCO but for some reason people think such
> programs are harder to debug (and yet they don't similarly complain about
> loops!). The beauty of Scheme was that it *mandated* tail recursion.
>
> > On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm@algebras.org> wrote:
> >
> > Tail recursion not lazy eval.
> >
> > I wish words meant what I meant "inside" when I think them, not
> > "outside" what they mean when I write them.
>
>

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

[TUHS] Re: python

[Bakul Shah]

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

I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-)

> On Aug 3, 2023, at 1:32 AM, Rob Pike <robpike@gmail.com> wrote:
> 
> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good.
> 
> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell.
> 
> Critical code needs static typing.
> 
> -rob
> 
> 
> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org <mailto:bakul@iitbombay.org>> wrote:
>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion. 
>> 
>> > On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm@algebras.org <mailto:ggm@algebras.org>> wrote:
>> > 
>> > Tail recursion not lazy eval.
>> > 
>> > I wish words meant what I meant "inside" when I think them, not
>> > "outside" what they mean when I write them.
>> 


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

[TUHS] Re: python

[Dan Halbert]

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

Python has optional type annotations. There are batch tools (e.g., MyPy) 
to do type analysis and IDE's also provide help. Example:

def greeting(name: str) -> str:
     return 'Hello ' + name

I found Python to be an enormous improvement over Perl for writing the 
kinds of things I used to write in Perl, with the Perl book at my side. 
I currently make my living working on Python for microcontrollers. 
Neverthless, I am fond of type checking too, and if I were writing a 
large Python system, I would use type annotations.

I have used BCPL too, in the 70's, and we achieved some measure of type 
safety by careful naming.

Dan H.

On 8/3/23 10:19, Bakul Shah wrote:
> I have not heard such horror stories about Common Lisp (or may be I 
> have forgotten them!). My impression is that python doesn't quite have 
> the kind of {meta,}programming tools Common Lisp has. CL has been used 
> for large critical programs. Perhaps Von Rossum had more experience 
> with statically typed languages than Lisp (because -- pure speculation 
> here -- if he had used CL enough, he would never have designed python :-)
>
>> On Aug 3, 2023, at 1:32 AM, Rob Pike <robpike@gmail.com> wrote:
>>
>> I once inherited maintenance of a critical piece of infrastructure 
>> written in exquisitely well written, tested, and documented Python. I 
>> mean it, it was really really good.
>>
>> It crashed about once a week and I had to fix it over and over 
>> because in those exponentially vast combinations of paths through the 
>> code would arise yet another way to turn a string into a list, or 
>> something analogous. It was hell.
>>
>> Critical code needs static typing.
>>
>> -rob
>>
>>
>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org> wrote:
>>
>>     python can certainly implement tail call optimization (TCO).
>>     Pretty much any language can implement TCO but for some reason
>>     people think such programs are harder to debug (and yet they
>>     don't similarly complain about loops!). The beauty of Scheme was
>>     that it *mandated* tail recursion.
>>
>>     > On Aug 2, 2023, at 8:24 PM, George Michaelson
>>     <ggm@algebras.org> wrote:
>>     >
>>     > Tail recursion not lazy eval.
>>     >
>>     > I wish words meant what I meant "inside" when I think them, not
>>     > "outside" what they mean when I write them.
>>
>

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

[TUHS] Re: python

[will.senn]

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

Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice.

Will

On August 3, 2023 9:56:22 AM CDT, Dan Halbert <halbert@halwitz.org> wrote:
>Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example:
>
>def greeting(name: str) -> str:
>    return 'Hello ' + name
>
>I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations.
>
>I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming.
>
>Dan H.
>
>On 8/3/23 10:19, Bakul Shah wrote:
>> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-)
>> 
>>> On Aug 3, 2023, at 1:32 AM, Rob Pike <robpike@gmail.com> wrote:
>>> 
>>> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good.
>>> 
>>> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell.
>>> 
>>> Critical code needs static typing.
>>> 
>>> -rob
>>> 
>>> 
>>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org> wrote:
>>> 
>>>     python can certainly implement tail call optimization (TCO).
>>>     Pretty much any language can implement TCO but for some reason
>>>     people think such programs are harder to debug (and yet they
>>>     don't similarly complain about loops!). The beauty of Scheme was
>>>     that it *mandated* tail recursion.
>>> 
>>>     > On Aug 2, 2023, at 8:24 PM, George Michaelson
>>>     <ggm@algebras.org> wrote:
>>>     >
>>>     > Tail recursion not lazy eval.
>>>     >
>>>     > I wish words meant what I meant "inside" when I think them, not
>>>     > "outside" what they mean when I write them.
>>> 
>> 

-- Sent from /e/OS Mail.

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

[TUHS] Re: python

[Dan Cross]

On Thu, Aug 3, 2023 at 11:21 AM will.senn@gmail.com <will.senn@gmail.com> wrote:
> Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice.

Types in programming languages vary across two axes: strong versus
weak, and static versus dynamic. Common Lisp is strongly typed: for
example, you cannot add an integer to a list, or `cons` something onto
a vector (Common Lisp vectors are not lists).

Indeed, exactly the former caused a production outage in a large Lisp
system I worked on for about a year: someone had needed to store a
pair of integers, so they used a CONS cell; after a while, the pair
needed to be expanded to a triple, so someone converted the single
CONS cell into a (proper) list. Consequently, the function for
accessing the second value went from being CDR to CADR (or `SECOND`),
but the programmer missed one place: the value of `(cdr foo)`, now a
list, was passed to some function that expected a fixnum and tried to
add something to it: this, of course, ran afoul of the type system and
raised a condition, which resulted as an ISE in prod. The fix was
trivial (change CDR to SECOND in the right place) but it really struck
me that if the system were statically typed, this would have been
trivially discovered at compile-time.

On the other axis, Lisps are usually dynamically typed, which in this
context, means that the type of a value associated with a symbol may
change over time and one matters when the value is actually used.
Common Lisp does allow you to declare types in some limited regards;
these are usually hints to the compiler for code generation.
Conversely, in statically typed languages, the type of every value is
known at all times (particularly at compile time).

Incidentally, this episode --- along with something similar in a
Python program --- really soured me on dynamically-typed languages.
The python failure was particularly maddening: it was heavily unit
tested (100% coverage) but as soon as we put it out, we immediately
got an error report: a type error with processing the arguments to
`main` (Google had some non-standard internal libraries for that that
were challenging to test). This was highly frustrating: like Rob, I
greatly prefer strong, static typing.

Incidentally, C is weakly (you can add a pointer to an integer: the
result is another pointer), but statically typed.

        - Dan C.

> On August 3, 2023 9:56:22 AM CDT, Dan Halbert <halbert@halwitz.org> wrote:
>>
>> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example:
>>
>> def greeting(name: str) -> str:
>>     return 'Hello ' + name
>>
>> I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations.
>>
>> I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming.
>>
>> Dan H.
>>
>> On 8/3/23 10:19, Bakul Shah wrote:
>>
>> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-)
>>
>> On Aug 3, 2023, at 1:32 AM, Rob Pike <robpike@gmail.com> wrote:
>>
>> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good.
>>
>> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell.
>>
>> Critical code needs static typing.
>>
>> -rob
>>
>>
>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org> wrote:
>>>
>>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion.
>>>
>>> > On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm@algebras.org> wrote:
>>> >
>>> > Tail recursion not lazy eval.
>>> >
>>> > I wish words meant what I meant "inside" when I think them, not
>>> > "outside" what they mean when I write them.
>>>
>>
>>
> -- Sent from /e/OS Mail.

[TUHS] Re: python

[John Cowan]

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

On Thu, Aug 3, 2023 at 6:06 PM Dan Cross <crossd@gmail.com> wrote:

> On Thu, Aug 3, 2023 at 11:21 AM will.senn@gmail.com <will.senn@gmail.com>
> wrote:
>


> someone had needed to store a
> pair of integers, so they used a CONS cell;


Of course, that was a bad idea.  The pair of integers should have been a
struct or a class named after whatever its application-level purpose was: a
point, for example.

after a while, the pair
> needed to be expanded to a triple, so someone converted the single
> CONS cell into a (proper) list.


In that case, a derived struct or class should have been created.  The two
classes would use the same accessor methods, just as in C++.

this, of course, ran afoul of the type system and
> raised a condition, which resulted as an ISE in prod. The fix was
> trivial (change CDR to SECOND in the right place) but it really struck
> me that if the system were statically typed, this would have been
> trivially discovered at compile-time.
>

Absolutely, and if the failure was intolerable, CL's static type
declarations would have caught the use of the wrong type.  But you don't
have to declare *everything*.  For that matter, there is nothing in a fully
statically typed system that requires every variable, function, argument,
etc. to be *declared*: type inference is powerful.

Common Lisp does allow you to declare types in some limited regards;
> these are usually hints to the compiler for code generation.
>

They may or may not be, depending on how you set the OPTIMIZE declaration.


> like Rob, I
> greatly prefer strong, static typing.
>

Then why weren't you using mypy?


> Incidentally, C is weakly (you can add a pointer to an integer: the
> result is another pointer), but statically typed.
>

That's not weak typing, it's operator overloading, just as when you add an
int to a double.  C will not let you, e.g., add an int to a function.  Weak
typing is quite rare in high-level languages: PL/I pointer variables are
weakly typed (that is, when you allocate an object you specify the type of
the object and then assign it to the pointer variable), but the rest of the
language is strongly typed.

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

[TUHS] Re: python

[Dan Cross]

On Thu, Aug 3, 2023 at 8:24 PM John Cowan <cowan@ccil.org> wrote:
> On Thu, Aug 3, 2023 at 6:06 PM Dan Cross <crossd@gmail.com> wrote:
>> someone had needed to store a
>> pair of integers, so they used a CONS cell;
>
> Of course, that was a bad idea.  The pair of integers should have been a struct or a class named after whatever its application-level purpose was: a point, for example.

Probably, but I didn't write the original code, or even make the
change; I did submit the fix, however. :-)

An issue with CLs aggregation primitives is that they can be
expensive, however. QPX was weird; despite things that have been said
about it publicly (http://www.paulgraham.com/carl.html) QPX was not a
"typical" Lisp program: it is more like FORTRAN written in
S-expressions (many thousand-line Lisp functions with jumps between
various points inside of them are common; those functions like, say,
setq [not setf] a boolean on line 1387, and then reference it on
3298...kind of a mess, but that's what you need to make Lisp fast).

>> after a while, the pair
>> needed to be expanded to a triple, so someone converted the single
>> CONS cell into a (proper) list.
>
> In that case, a derived struct or class should have been created.  The two classes would use the same accessor methods, just as in C++.

Of course, we all knew this. But when you've got an O(10^6) line
codebase that's extremely fragile, technology and business limitations
demand tradeoffs that are not always what the engineers would choose.

>> this, of course, ran afoul of the type system and
>> raised a condition, which resulted as an ISE in prod. The fix was
>> trivial (change CDR to SECOND in the right place) but it really struck
>> me that if the system were statically typed, this would have been
>> trivially discovered at compile-time.
>
> Absolutely, and if the failure was intolerable, CL's static type declarations would have caught the use of the wrong type.  But you don't have to declare *everything*.  For that matter, there is nothing in a fully statically typed system that requires every variable, function, argument, etc. to be *declared*: type inference is powerful.

Not really, unless they were used consistently across the entire
codebase (and sadly, they were not).

>> Common Lisp does allow you to declare types in some limited regards;
>> these are usually hints to the compiler for code generation.
>
> They may or may not be, depending on how you set the OPTIMIZE declaration.
>
>> like Rob, I
>> greatly prefer strong, static typing.
>
> Then why weren't you using mypy?

Because it didn't exist at the time (the early 2010s), or if it did,
it was in a very nascent state.

>> Incidentally, C is weakly (you can add a pointer to an integer: the
>> result is another pointer), but statically typed.
>
> That's not weak typing, it's operator overloading, just as when you add an int to a double. C will not let you, e.g., add an int to a function.

I think there's a bit of a debate as to whether C is weakly or
strongly typed (and certainly, these exist on a spectrum), and some
good judges say it's "moderately typed". I've never heard anyone refer
to implicit type conversions as "operator overloading", however.

> Weak typing is quite rare in high-level languages: PL/I pointer variables are weakly typed (that is, when you allocate an object you specify the type of the object and then assign it to the pointer variable), but the rest of the language is strongly typed.

Once `memcpy` and `void *` are in the mix, all bets are off in C.

        - Dan C.

[TUHS] Re: python

[Bakul Shah]

Sorry for beating a dead horse but...

What I was getting at when I invoked lisp is because I was thinking
of the ability to debug live processes as opposed analyzing dead
programs (core dumps). With lisps you can not only access a lot of
the dynamic state of the program at the language level but (in theory)
you may also be able to fix the problem and let the process continue.
Especially when a program crashes rather infrequently, having access
to only a core dump & stack trace can be quite frustrating. Why do we
continue to live in a virtual "batch processing" world when it comes
to dealing with such problems? [I once spent a month analyzing a problem
a customer reported. I had guessed what the problem might be but couldn't
reproduce it. In their live setup, it took 15 minutes to catch the bug
with a logic analyzer!]

The other thing both you and Rob pointed out is that even "well-tested"
programs can crash. While you can use more type annotations even in
dynamic languages to catch type errors, types are not sufficiently
expressive so you always have that potential problem (and we can't 
*prove* large programs to be bug free). It is of course better to do
all the testing you can but that typically occurs in "lab conditions",
not in the real world. That is why many large services can run a small
subset of servers with newer version of s/w as a "canary" to catch
errors early (but that is usually a binary decision -- if the canary
dies, you don't do the software update). With a dynamic language you
can add situation specific tests on the fly if the program misbehaves.

Live debugging should be even easier now -- with the right setup one
should be attach a bot to do some initial checking etc. Instead we
have apps that use 100s of MB to GBs of space but die silently. Guess
we all suffer from Stockholm Syndrome!


> On Aug 3, 2023, at 3:05 PM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Thu, Aug 3, 2023 at 11:21 AM will.senn@gmail.com <will.senn@gmail.com> wrote:
>> Nice. I've never appreciated type checking at 'compile' time, but I understand why others might (ocd). C was my first exposure to blending types, then Perl was fuzzier, then Python was even better at pretending types didn't matter. Now, with Lisp, I am freed from type concerns... until I'm not. Thankfully, it's my choice.
> 
> Types in programming languages vary across two axes: strong versus
> weak, and static versus dynamic. Common Lisp is strongly typed: for
> example, you cannot add an integer to a list, or `cons` something onto
> a vector (Common Lisp vectors are not lists).
> 
> Indeed, exactly the former caused a production outage in a large Lisp
> system I worked on for about a year: someone had needed to store a
> pair of integers, so they used a CONS cell; after a while, the pair
> needed to be expanded to a triple, so someone converted the single
> CONS cell into a (proper) list. Consequently, the function for
> accessing the second value went from being CDR to CADR (or `SECOND`),
> but the programmer missed one place: the value of `(cdr foo)`, now a
> list, was passed to some function that expected a fixnum and tried to
> add something to it: this, of course, ran afoul of the type system and
> raised a condition, which resulted as an ISE in prod. The fix was
> trivial (change CDR to SECOND in the right place) but it really struck
> me that if the system were statically typed, this would have been
> trivially discovered at compile-time.
> 
> On the other axis, Lisps are usually dynamically typed, which in this
> context, means that the type of a value associated with a symbol may
> change over time and one matters when the value is actually used.
> Common Lisp does allow you to declare types in some limited regards;
> these are usually hints to the compiler for code generation.
> Conversely, in statically typed languages, the type of every value is
> known at all times (particularly at compile time).
> 
> Incidentally, this episode --- along with something similar in a
> Python program --- really soured me on dynamically-typed languages.
> The python failure was particularly maddening: it was heavily unit
> tested (100% coverage) but as soon as we put it out, we immediately
> got an error report: a type error with processing the arguments to
> `main` (Google had some non-standard internal libraries for that that
> were challenging to test). This was highly frustrating: like Rob, I
> greatly prefer strong, static typing.
> 
> Incidentally, C is weakly (you can add a pointer to an integer: the
> result is another pointer), but statically typed.
> 
>       - Dan C.
> 
>> On August 3, 2023 9:56:22 AM CDT, Dan Halbert <halbert@halwitz.org> wrote:
>>> 
>>> Python has optional type annotations. There are batch tools (e.g., MyPy) to do type analysis and IDE's also provide help. Example:
>>> 
>>> def greeting(name: str) -> str:
>>>   return 'Hello ' + name
>>> 
>>> I found Python to be an enormous improvement over Perl for writing the kinds of things I used to write in Perl, with the Perl book at my side. I currently make my living working on Python for microcontrollers. Neverthless, I am fond of type checking too, and if I were writing a large Python system, I would use type annotations.
>>> 
>>> I have used BCPL too, in the 70's, and we achieved some measure of type safety by careful naming.
>>> 
>>> Dan H.
>>> 
>>> On 8/3/23 10:19, Bakul Shah wrote:
>>> 
>>> I have not heard such horror stories about Common Lisp (or may be I have forgotten them!). My impression is that python doesn't quite have the kind of {meta,}programming tools Common Lisp has. CL has been used for large critical programs. Perhaps Von Rossum had more experience with statically typed languages than Lisp (because -- pure speculation here -- if he had used CL enough, he would never have designed python :-)
>>> 
>>> On Aug 3, 2023, at 1:32 AM, Rob Pike <robpike@gmail.com> wrote:
>>> 
>>> I once inherited maintenance of a critical piece of infrastructure written in exquisitely well written, tested, and documented Python. I mean it, it was really really good.
>>> 
>>> It crashed about once a week and I had to fix it over and over because in those exponentially vast combinations of paths through the code would arise yet another way to turn a string into a list, or something analogous. It was hell.
>>> 
>>> Critical code needs static typing.
>>> 
>>> -rob
>>> 
>>> 
>>> On Thu, Aug 3, 2023 at 1:56 PM Bakul Shah <bakul@iitbombay.org> wrote:
>>>> 
>>>> python can certainly implement tail call optimization (TCO). Pretty much any language can implement TCO but for some reason people think such programs are harder to debug (and yet they don't similarly complain about loops!). The beauty of Scheme was that it *mandated* tail recursion.
>>>> 
>>>>> On Aug 2, 2023, at 8:24 PM, George Michaelson <ggm@algebras.org> wrote:
>>>>> 
>>>>> Tail recursion not lazy eval.
>>>>> 
>>>>> I wish words meant what I meant "inside" when I think them, not
>>>>> "outside" what they mean when I write them.
>>>> 
>>> 
>>> 
>> -- Sent from /e/OS Mail.

[TUHS] Re: python

[John Cowan]

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

On Thu, Aug 3, 2023 at 10:20 AM Bakul Shah <bakul@iitbombay.org> wrote:

I have not heard such horror stories about Common Lisp (or may be I have
> forgotten them!).
>

Both Common Lisp and Python have optional static typing that is as rigorous
as you might want.  In the case of Python it is an outboard tool that you
put into your build file; Python itself ignores declarations.  (That means
that the declarations are not used to optimize runtime performance.)  The
mypy tool does extensive type inference; you can get a long way without
ever writing a declaration.

For CL, type checking is part of the compiler; the interpreter generally
ignores type declarations, although Steel Bank CL, the fastest existing
implementation, uses the compiler even in the REPL.

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

[TUHS] Re: python

[Clem Cole]

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

IMO (Like Larry) no printf stinks.  But the real killer for my sustain for
Python is the use white space and being typeless.   My daughter loves it
for her cloud development and we argue a bit.  But it was the first
language she really mastered in college and she never took a competitive
languages course so I’m not so sure really had experienced much beyond it
for real programs.   Maybe I’m just an old fart but between C, Go and Rust
I’m pretty good.  I do write scripts in Bourne shell and or awk truth be
known.

On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> > > [Python is] meant for mainly functional programming as I understand it
> >
> > Not true. It has some neat functional features (list comprehensions) but
> > that's not really its intent.
>
> I've really tried to like python but any language that doesn't has printf
> as builtin is not for me.  Yes, I know about their library printf but it
> is weird.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>
-- 
Sent from a handheld expect more typos than usual

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

[TUHS] Re: python

[Pete Wright via TUHS]

On 8/2/23 19:07, Clem Cole wrote:
> IMO (Like Larry) no printf stinks.  But the real killer for my sustain 
> for Python is the use white space and being typeless.   My daughter 
> loves it for her cloud development and we argue a bit.  But it was the 
> first language she really mastered in college and she never took a 
> competitive languages course so I’m not so sure really had experienced 
> much beyond it for real programs.   Maybe I’m just an old fart but 
> between C, Go and Rust I’m pretty good.  I do write scripts in Bourne 
> shell and or awk truth be known.
> 

as one of those "new kids" who finds python to be a decent enough 
language for my cloud development tasks - my main observation is that 
having the python REPL was an eye opener.

after fighting the learning curve of C and Java the interactivity of the 
whole thing was a revelation.  being able to open a unix shell, run 
python and have a basic webserver running in a few lines of code was 
fantastic for my young hacker mind.  this also probably helps explain 
the popularity of javascript too.

this isn't to say i think python is the end-all of programming, far from 
it, but it certainly took a lot of the novice programmer anxiety out of 
programming for me.

if only i'd encountered erlang during those formative years...

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA

[TUHS] Re: python

[Warner Losh]

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

On Wed, Aug 2, 2023 at 8:21 PM Pete Wright via TUHS <tuhs@tuhs.org> wrote:

> this isn't to say i think python is the end-all of programming, far from
> it, but it certainly took a lot of the novice programmer anxiety out of
> programming for be.
>

python doesn't suck because batteries are included and what's not included
is pretty easy to just drag in and get craptops of useful stuff done in a
hurry.
Would I write a kernel in? Hell no. But would I knock together a bit of data
visualization after massaging data in an almost throw-a-way manner? You
betcha. It's stunningly adequate... A latter day awk for junk I need to do
from time to time...

Warner

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

[TUHS] Re: python

[Mike Markowski]

Clem and all,

I find python string format syntax to be close enough to printf. E.g.,

   print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag))

However, the example highlights a shortcoming.  While complex numbers 
are supported by the language, there is no formatting support like 
'%.5j' ('j' is my made up format char) to directly format a complex number.

I work in an RF lab focused on work with hardware and lab gear. Some 
points in favor of python are (1) lab gear is controlled by SCPI, (2) 
DSP relies on complex math, and (3) RF propagation modeling is 
computationally intense.

Item (1) is easily performed with python, (2) with python or 
Matlab/octave, and (3) is 'it depends.'  An engineer's friend went from 
slide rule, to calculator, fortran/c (fortran for numbers, c for 
hardware), and now python. A laptop with python or matlab is the new 
'calculator.'  As to (3), if you will use the program for large 
scenarios, use c or fortran. For small runs or to dovetail results with 
control of lab gear python fills the bill.  (I even went to the slightly 
insane length of converting a classic prop model from fortran to python 
for that reason: https://udel.edu/~mm/itm/ )

I agree 110% that python white space formatting is horrible.  I can't 
say many times I took someone else's program, made a quick change, to 
discover one of us used tabs and the other spaces.

Mike Markowski

On 8/2/23 10:07 PM, Clem Cole wrote:
> IMO (Like Larry) no printf stinks.  But the real killer for my sustain 
> for Python is the use white space and being typeless.   My daughter 
> loves it for her cloud development and we argue a bit.  But it was the 
> first language she really mastered in college and she never took a 
> competitive languages course so I’m not so sure really had experienced 
> much beyond it for real programs.   Maybe I’m just an old fart but 
> between C, Go and Rust I’m pretty good.  I do write scripts in Bourne 
> shell and or awk truth be known.
>

[TUHS] Re: python

[Rob Pike]

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

The idea of indentation defining structure seemed really cool when it
arose. I first saw it in a toy language called Henry, back in the early
1980s.

But over time the notion that invisible characters define program execution
created so many problems that in retrospect it is ill advised despite its
prevalence. In fact its prevalence makes it even less advisable, as it
creates yet more areas for trouble.

-rob


On Thu, Aug 3, 2023 at 10:36 PM Mike Markowski <mike.ab3ap@gmail.com> wrote:

> Clem and all,
>
> I find python string format syntax to be close enough to printf. E.g.,
>
>    print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag))
>
> However, the example highlights a shortcoming.  While complex numbers
> are supported by the language, there is no formatting support like
> '%.5j' ('j' is my made up format char) to directly format a complex number.
>
> I work in an RF lab focused on work with hardware and lab gear. Some
> points in favor of python are (1) lab gear is controlled by SCPI, (2)
> DSP relies on complex math, and (3) RF propagation modeling is
> computationally intense.
>
> Item (1) is easily performed with python, (2) with python or
> Matlab/octave, and (3) is 'it depends.'  An engineer's friend went from
> slide rule, to calculator, fortran/c (fortran for numbers, c for
> hardware), and now python. A laptop with python or matlab is the new
> 'calculator.'  As to (3), if you will use the program for large
> scenarios, use c or fortran. For small runs or to dovetail results with
> control of lab gear python fills the bill.  (I even went to the slightly
> insane length of converting a classic prop model from fortran to python
> for that reason: https://udel.edu/~mm/itm/ )
>
> I agree 110% that python white space formatting is horrible.  I can't
> say many times I took someone else's program, made a quick change, to
> discover one of us used tabs and the other spaces.
>
> Mike Markowski
>
> On 8/2/23 10:07 PM, Clem Cole wrote:
> > IMO (Like Larry) no printf stinks.  But the real killer for my sustain
> > for Python is the use white space and being typeless.   My daughter
> > loves it for her cloud development and we argue a bit.  But it was the
> > first language she really mastered in college and she never took a
> > competitive languages course so I’m not so sure really had experienced
> > much beyond it for real programs.   Maybe I’m just an old fart but
> > between C, Go and Rust I’m pretty good.  I do write scripts in Bourne
> > shell and or awk truth be known.
> >
>

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

[TUHS] Re: python

[emanuel stiebler]

On 2023-08-03 09:29, Rob Pike wrote:
> The idea of indentation defining structure seemed really cool when it 
> arose. I first saw it in a toy language called Henry, back in the early 
> 1980s.
> 
> But over time the notion that invisible characters define program 
> execution created so many problems that in retrospect it is ill advised 
> despite its prevalence. In fact its prevalence makes it even less 
> advisable, as it creates yet more areas for trouble.

Most editors have some "beautify modes" which can fix indentation,
so the programmer sees what he is doing in deep nested stuff.

Counting "white spaces" in 21st century?

[TUHS] Re: python

[Steffen Nurpmeso]

emanuel stiebler wrote in
 <99511256-1c0a-732b-4b78-a879a67a2291@e-bbes.com>:
 |On 2023-08-03 09:29, Rob Pike wrote:
 |> The idea of indentation defining structure seemed really cool when it 
 |> arose. I first saw it in a toy language called Henry, back in the early 
 |> 1980s.
 |> 
 |> But over time the notion that invisible characters define program 
 |> execution created so many problems that in retrospect it is ill advised 
 |> despite its prevalence. In fact its prevalence makes it even less 
 |> advisable, as it creates yet more areas for trouble.
 |
 |Most editors have some "beautify modes" which can fix indentation,
 |so the programmer sees what he is doing in deep nested stuff.
 |
 |Counting "white spaces" in 21st century?

Normally a newer C compiler beats unto you if your indentation
does not satisfy him?  (Or was that clang only?  That one maybe
learns to cook your favorite hot beverage if its size exceeds the
second gigabyte.)

 --End of <99511256-1c0a-732b-4b78-a879a67a2291@e-bbes.com>

Ciao.

P.S.: unfair + without any insider knowledge: it must be like that.

  $ ll /usr/ports/built/tcc#20230731-1.pkg.tar.xz
  -rw-rw---- 1 ports ports 250632 Jul 31 21:14 /usr/ports/built/tcc#20230731-1.pkg.tar.xz
  $ xz -l /usr/ports/built/tcc#20230731-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
      1       1    244.8 KiB   1180.5 KiB  0.207  CRC64   /usr/ports/built/tcc#20230731-1.pkg.tar.xz


No pcc here at the moment :(


  $ ll /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz
  -rw-rw---- 1 ports ports 50662716 May 27 20:45 /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz
  $ xz -l /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
      1       9     48.3 MiB    206.5 MiB  0.234  CRC64   /usr/ports/built/gcc#12.3.0-2.pkg.tar.xz
  $ prt-get info gcc|grep Depend
  Dependencies: libmpc,zlib,zstd


  $ ll /usr/ports/built/clang#16.0.6-1.pkg.tar.xz
  -rw-rw---- 1 ports ports 103260340 Jun 23 22:19 /usr/ports/built/clang#16.0.6-1.pkg.tar.xz
  $ xz -l /usr/ports/built/clang#16.0.6-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
      1      42     98.5 MiB    991.7 MiB  0.099  CRC64   /usr/ports/built/clang#16.0.6-1.pkg.tar.xz

  $ prt-get info clang|grep Depend
  Dependencies: compiler-rt

  $ ll /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz
  -rw-rw---- 1 ports ports 3633680 Jun 23 21:04 /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz
  $ xz -l /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
      1       2   3548.5 KiB     36.3 MiB  0.096  CRC64   /usr/ports/built/compiler-rt#16.0.6-1.pkg.tar.xz

  $ prt-get info compiler-rt|grep Depend
  Dependencies: llvm

  $ ll /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz
  -rw-rw---- 1 ports ports 115485456 Jun 23 21:00 /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz
  $ xz -l /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz
  Strms  Blocks   Compressed Uncompressed  Ratio  Check   Filename
      1      29    110.1 MiB    678.9 MiB  0.162  CRC64   /usr/ports/built/llvm#16.0.6-1.pkg.tar.xz

  $ prt-get info llvm|grep Depend
  Dependencies: cmake,libffi,libxml2,ninja,python3-setuptools

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

[TUHS] Re: python

[Larry McVoy]

I agree with Rob.  I get why Guido did it, he wanted some sane style.  Any 
of us who were kernel engineers and saw a sane C style, then you see GNU
C style and you recoil in horror.  I don't know if that was his path but
I get that you would like some sanity in the formatting.

That said, as a person who thinks of himself as a professional, when I go
in to someone else's code, I adopt their style.  It's really rude to not
do so.  I've written code in GNU C style.

On Thu, Aug 03, 2023 at 11:29:18PM +1000, Rob Pike wrote:
> The idea of indentation defining structure seemed really cool when it
> arose. I first saw it in a toy language called Henry, back in the early
> 1980s.
> 
> But over time the notion that invisible characters define program execution
> created so many problems that in retrospect it is ill advised despite its
> prevalence. In fact its prevalence makes it even less advisable, as it
> creates yet more areas for trouble.
> 
> -rob
> 
> 
> On Thu, Aug 3, 2023 at 10:36???PM Mike Markowski <mike.ab3ap@gmail.com> wrote:
> 
> > Clem and all,
> >
> > I find python string format syntax to be close enough to printf. E.g.,
> >
> >    print('%.4f ns, (%.4f, %.4fj)' % (tap[0], tap[1].real, tap[1].imag))
> >
> > However, the example highlights a shortcoming.  While complex numbers
> > are supported by the language, there is no formatting support like
> > '%.5j' ('j' is my made up format char) to directly format a complex number.
> >
> > I work in an RF lab focused on work with hardware and lab gear. Some
> > points in favor of python are (1) lab gear is controlled by SCPI, (2)
> > DSP relies on complex math, and (3) RF propagation modeling is
> > computationally intense.
> >
> > Item (1) is easily performed with python, (2) with python or
> > Matlab/octave, and (3) is 'it depends.'  An engineer's friend went from
> > slide rule, to calculator, fortran/c (fortran for numbers, c for
> > hardware), and now python. A laptop with python or matlab is the new
> > 'calculator.'  As to (3), if you will use the program for large
> > scenarios, use c or fortran. For small runs or to dovetail results with
> > control of lab gear python fills the bill.  (I even went to the slightly
> > insane length of converting a classic prop model from fortran to python
> > for that reason: https://udel.edu/~mm/itm/ )
> >
> > I agree 110% that python white space formatting is horrible.  I can't
> > say many times I took someone else's program, made a quick change, to
> > discover one of us used tabs and the other spaces.
> >
> > Mike Markowski
> >
> > On 8/2/23 10:07 PM, Clem Cole wrote:
> > > IMO (Like Larry) no printf stinks.  But the real killer for my sustain
> > > for Python is the use white space and being typeless.   My daughter
> > > loves it for her cloud development and we argue a bit.  But it was the
> > > first language she really mastered in college and she never took a
> > > competitive languages course so I???m not so sure really had experienced
> > > much beyond it for real programs.   Maybe I???m just an old fart but
> > > between C, Go and Rust I???m pretty good.  I do write scripts in Bourne
> > > shell and or awk truth be known.
> > >
> >

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: python

[segaloco via TUHS]

> That said, as a person who thinks of himself as a professional, when I go
> in to someone else's code, I adopt their style. It's really rude to not
> do so. I've written code in GNU C style.
> 
> Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat

I've adopted a variation on this in that I try and write additions to existing code stylistically similar to what is there, anything presenting glue logic to some sort of external vendor library in a way resembling their style, and then anything else is mine.

That middle one I've found particularly helpful even for myself over the years as there are plenty of places in the dayjob codebases I can drop in and tell almost immediately "Oh this is a wrapper over so and so based on the variable names" or "Yeah this is an interface to library <xyz> based on the way the operations are named."

Generally the only thing I have a hard time sticking to is casing, I'm a fervent snake caser in my assembly and C code, but then fervent pascal caser in my JavaScript and C#.  Then again, that may also tie into my middle practice in that those are the common cases seen in model examples of those languages.  One of the weirder side effects of that stylistic practice is the rare occasion where I blindly copy something between languages with relatively similar syntax (C to C# or JavaScript for instance) I can tell going back later because there's a hunk of code with snake case smack in the middle of a bunch of pascal case.  I usually go and clean that up though because otherwise the codebase starts to look like a copypaste job from StackOverflow after a while, that stuff drives me up the wall.

- Matt G.

P.S. For TUHS subject appropriateness, I have TUHS to thank for my C style practices.  I learned from KnR 2nd Edition back when I was a kid, but diverged a bit from the typical KnR way of things for a while, when I caught wind of TUHS and started pouring over all the code, unbeknownst to my own consciousness I started absorbing stylistic patterns from UNIX sources.  I'm thankful to Warren and all the others who have facilitated this community, I think TUHS should be in any programmer's bookmark list :)

[TUHS] Re: python

[Adam Thornton]

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

What we've done on my current project is pretty much equivalent to the
route Go chose.

Go has go fmt; doesn't matter what you personally believe, just run that
pre-commit, and you get a consistent style.  For Python we use black.  Same
idea.  It's not what everyone would have chosen--in fact, precisely what it
does is not what *anyone* on the project, probably, would have chosen--but
the fact is, it does something sane and pretty readable, and then there's
no fighting over style.

Adam

On Thu, Aug 3, 2023 at 6:28 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> > That said, as a person who thinks of himself as a professional, when I go
> > in to someone else's code, I adopt their style. It's really rude to not
> > do so. I've written code in GNU C style.
> >
> > Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
>
> I've adopted a variation on this in that I try and write additions to
> existing code stylistically similar to what is there, anything presenting
> glue logic to some sort of external vendor library in a way resembling
> their style, and then anything else is mine.
>
> That middle one I've found particularly helpful even for myself over the
> years as there are plenty of places in the dayjob codebases I can drop in
> and tell almost immediately "Oh this is a wrapper over so and so based on
> the variable names" or "Yeah this is an interface to library <xyz> based on
> the way the operations are named."
>
> Generally the only thing I have a hard time sticking to is casing, I'm a
> fervent snake caser in my assembly and C code, but then fervent pascal
> caser in my JavaScript and C#.  Then again, that may also tie into my
> middle practice in that those are the common cases seen in model examples
> of those languages.  One of the weirder side effects of that stylistic
> practice is the rare occasion where I blindly copy something between
> languages with relatively similar syntax (C to C# or JavaScript for
> instance) I can tell going back later because there's a hunk of code with
> snake case smack in the middle of a bunch of pascal case.  I usually go and
> clean that up though because otherwise the codebase starts to look like a
> copypaste job from StackOverflow after a while, that stuff drives me up the
> wall.
>
> - Matt G.
>
> P.S. For TUHS subject appropriateness, I have TUHS to thank for my C style
> practices.  I learned from KnR 2nd Edition back when I was a kid, but
> diverged a bit from the typical KnR way of things for a while, when I
> caught wind of TUHS and started pouring over all the code, unbeknownst to
> my own consciousness I started absorbing stylistic patterns from UNIX
> sources.  I'm thankful to Warren and all the others who have facilitated
> this community, I think TUHS should be in any programmer's bookmark list :)
>

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

[TUHS] Re: python

[Dan Cross]

On Thu, Aug 3, 2023 at 9:58 PM Adam Thornton <athornton@gmail.com> wrote:
> What we've done on my current project is pretty much equivalent to the route Go chose.
>
> Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style.  For Python we use black.  Same idea.  It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style.

This.

I despised Google's C++ style standards, but I respected them because
they allowed Google to scale to hundreds of millions of lines of C++
code that was at least intelligible to more or less anyone who worked
there. After a couple of months, people stop noticing the sharp edges
and differences from their personal styles.

The decades spent arguing over where to put the braces seem wasted, in
retrospect.

        - Dan C.

[TUHS] Re: python

[Larry McVoy]

On Fri, Aug 04, 2023 at 11:04:16AM -0400, Dan Cross wrote:
> On Thu, Aug 3, 2023 at 9:58???PM Adam Thornton <athornton@gmail.com> wrote:
> > What we've done on my current project is pretty much equivalent to the route Go chose.
> >
> > Go has go fmt; doesn't matter what you personally believe, just run that pre-commit, and you get a consistent style.  For Python we use black.  Same idea.  It's not what everyone would have chosen--in fact, precisely what it does is not what *anyone* on the project, probably, would have chosen--but the fact is, it does something sane and pretty readable, and then there's no fighting over style.
> 
> This.
> 
> I despised Google's C++ style standards, but I respected them because
> they allowed Google to scale to hundreds of millions of lines of C++
> code that was at least intelligible to more or less anyone who worked
> there. After a couple of months, people stop noticing the sharp edges
> and differences from their personal styles.
> 
> The decades spent arguing over where to put the braces seem wasted, in
> retrospect.

I can get used to anything, no argument there.  I'm teaching my kid 
some programming and he is eating up my style because I tell him why
it is like that.  For example, 

int
some_func(int some_arg)
{
}

not 

int some_func(int some_arg)
{
}

because I can do

grep '^some_func(' *.c

and find the declaration.

I "won" the braces argument by starting my own company and people were
pretty happy with the resulting code.

--lm

[TUHS] Re: python

[Ed Bradford]

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

To all:

Python 3's fstrings
  https://realpython.com/python-f-strings/
seem to me to be a huge improvement over printf
and its close relatives.

What are people's views about the pro's and con's and
how do print and strings compare in usability?

Ed


On Wed, Aug 2, 2023 at 9:07 PM Clem Cole <clemc@ccc.com> wrote:

> IMO (Like Larry) no printf stinks.  But the real killer for my sustain for
> Python is the use white space and being typeless.   My daughter loves it
> for her cloud development and we argue a bit.  But it was the first
> language she really mastered in college and she never took a competitive
> languages course so I’m not so sure really had experienced much beyond it
> for real programs.   Maybe I’m just an old fart but between C, Go and Rust
> I’m pretty good.  I do write scripts in Bourne shell and or awk truth be
> known.
>
> On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy <lm@mcvoy.com> wrote:
>
>> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
>> > > [Python is] meant for mainly functional programming as I understand it
>> >
>> > Not true. It has some neat functional features (list comprehensions) but
>> > that's not really its intent.
>>
>> I've really tried to like python but any language that doesn't has printf
>> as builtin is not for me.  Yes, I know about their library printf but it
>> is weird.
>> --
>> ---
>> Larry McVoy           Retired to fishing
>> http://www.mcvoy.com/lm/boat
>>
> --
> Sent from a handheld expect more typos than usual
>


-- 
Advice is judged by results, not by intentions.
  Cicero

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

[TUHS] Re: python

[Larry McVoy]

We did something sort of like that in Little, all double quoted strings
look for ${anything} in the string and evaluates it and prints.  Like
fstrings, you can do puts("Print 5 + 7 = ${5 + 7}");  

We used single quoted strings as pure strings.

It's handy and sometimes more readable than printf.

http://www.little-lang.org/little.html#String_interpolation

On Fri, Aug 04, 2023 at 02:20:06PM -0500, Ed Bradford wrote:
> To all:
> 
> Python 3's fstrings
>   https://realpython.com/python-f-strings/
> seem to me to be a huge improvement over printf
> and its close relatives.
> 
> What are people's views about the pro's and con's and
> how do print and strings compare in usability?
> 
> Ed
> 
> 
> On Wed, Aug 2, 2023 at 9:07???PM Clem Cole <clemc@ccc.com> wrote:
> 
> > IMO (Like Larry) no printf stinks.  But the real killer for my sustain for
> > Python is the use white space and being typeless.   My daughter loves it
> > for her cloud development and we argue a bit.  But it was the first
> > language she really mastered in college and she never took a competitive
> > languages course so I???m not so sure really had experienced much beyond it
> > for real programs.   Maybe I???m just an old fart but between C, Go and Rust
> > I???m pretty good.  I do write scripts in Bourne shell and or awk truth be
> > known.
> >
> > On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> >> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> >> > > [Python is] meant for mainly functional programming as I understand it
> >> >
> >> > Not true. It has some neat functional features (list comprehensions) but
> >> > that's not really its intent.
> >>
> >> I've really tried to like python but any language that doesn't has printf
> >> as builtin is not for me.  Yes, I know about their library printf but it
> >> is weird.
> >> --
> >> ---
> >> Larry McVoy           Retired to fishing
> >> http://www.mcvoy.com/lm/boat
> >>
> > --
> > Sent from a handheld expect more typos than usual
> >
> 
> 
> -- 
> Advice is judged by results, not by intentions.
>   Cicero

-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: python

[Ed Bradford]

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

Thanks Larry. I've found printf a jump in usability among the
languages I've used (FORTRAN, Visual Basic, Java, PHP and a few more).
Python3's
f-strings are a major readability/suportability advance over printf. There
is nothing I know of as usable, readable, and supportable.
I have yet to find anything I can't do
with f-strings than I could with printf.

There must be some one who has pros and cons of f-strings on this list?
I would like to hear thoughts.

Ed





On Fri, Aug 4, 2023 at 2:47 PM Larry McVoy <lm@mcvoy.com> wrote:

> We did something sort of like that in Little, all double quoted strings
> look for ${anything} in the string and evaluates it and prints.  Like
> fstrings, you can do puts("Print 5 + 7 = ${5 + 7}");
>
> We used single quoted strings as pure strings.
>
> It's handy and sometimes more readable than printf.
>
> http://www.little-lang.org/little.html#String_interpolation
>
> On Fri, Aug 04, 2023 at 02:20:06PM -0500, Ed Bradford wrote:
> > To all:
> >
> > Python 3's fstrings
> >   https://realpython.com/python-f-strings/
> > seem to me to be a huge improvement over printf
> > and its close relatives.
> >
> > What are people's views about the pro's and con's and
> > how do print and strings compare in usability?
> >
> > Ed
> >
> >
> > On Wed, Aug 2, 2023 at 9:07???PM Clem Cole <clemc@ccc.com> wrote:
> >
> > > IMO (Like Larry) no printf stinks.  But the real killer for my sustain
> for
> > > Python is the use white space and being typeless.   My daughter loves
> it
> > > for her cloud development and we argue a bit.  But it was the first
> > > language she really mastered in college and she never took a
> competitive
> > > languages course so I???m not so sure really had experienced much
> beyond it
> > > for real programs.   Maybe I???m just an old fart but between C, Go
> and Rust
> > > I???m pretty good.  I do write scripts in Bourne shell and or awk
> truth be
> > > known.
> > >
> > > On Wed, Aug 2, 2023 at 8:51 PM Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > >> On Wed, Aug 02, 2023 at 07:49:18PM -0400, Rich Salz wrote:
> > >> > > [Python is] meant for mainly functional programming as I
> understand it
> > >> >
> > >> > Not true. It has some neat functional features (list
> comprehensions) but
> > >> > that's not really its intent.
> > >>
> > >> I've really tried to like python but any language that doesn't has
> printf
> > >> as builtin is not for me.  Yes, I know about their library printf but
> it
> > >> is weird.
> > >> --
> > >> ---
> > >> Larry McVoy           Retired to fishing
> > >> http://www.mcvoy.com/lm/boat
> > >>
> > > --
> > > Sent from a handheld expect more typos than usual
> > >
> >
> >
> > --
> > Advice is judged by results, not by intentions.
> >   Cicero
>
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>


-- 
Advice is judged by results, not by intentions.
  Cicero

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