[TUHS] [TULSA] Re: python

[Dan Cross]

On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar <alx.manpages at gmail.com> wrote:
> On 2023-08-03 19:51, John Cowan wrote:
> > On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar <alx.manpages at gmail.com>
> > wrote:
> >
> > But if speed is not a problem, I'd keep the good ol' syntax that
> >
> > everybody knows.  No need to make everybody learn a "cool" new print
> >> function, that probably won't be as tunable as printf(3) is.
> >>
> >>
> > By that argument, there would be no C, only Algol 68 and PL/I, or subsets
> > of them.
> >
>
> I didn't claim that there's never a reason to invent new syntax.  My claim
> was rather that in this case, there isn't.
>
> -  printf(3) is more powerful than any other existing formatting function
>    that I know of any language --I'm still curious of what's the equivalent
>    of "%+'0#8.5f" in other formatting functions--.

One issue is that this isn't standard C: the `'` verb for grouping by
thousands is an SUSv2 extension. I just checked the latest C23 draft,
and unless I missed it, it doesn't appear to have made it in.

But things like that are fairly straight-forward in many other
languages. For example, in Go, the format string is nearly identical,
modulo the `'`:

: prithvi; cat print.go
package main

import "fmt"

func main() {
        fmt.Printf("%+0#8.5f\n", 3.1415)
}
: prithvi; go run print.go
+3.14150
: prithvi;

Type safety is achieved through reflection.

In Rust, which has a very pleasant formatted print facility, type
safety is handled by implementing `print` and `println` as macros. I
don't miss `printf` there.

> -  It is also reasonably fast (at least for such a highly-customizable
>    formatting function), and I'd like to see any system beat that while
>    keeping the customizability.

At Google, a group of exceptionally talented engineers wrote a
replacement in C++ for both type safety and because, bluntly, `printf`
(actually `snprintf`) was too slow. I believe the overall mechanism
made it into ABSL.

> -  It is type-safe, with the right tools.

No it's not, and it really can't be. True, there are linters that can
try to match up types _if_ the format string is a constant and all the
arguments are known at e.g. compile time, but C permits one to
construct the format string at run time (or just select between a
bunch of variants); the language gives you no tools to enforce type
safety in a meaningful way once you do that.

> I can understand the need for less-customizable faster formatting functions
> for very-high-performance programs, and std::format may fit well there.  But
> other than that, I don't see a reason to invent so many different formatting
> functions.  Of course, one may do that just for fun, in which case I applaud
> that.  But printf(3) is superior to them, IMO.

That sort of relative value judgement can be difficult to justify
without specifying the criteria that goes into one's judgement. As you
said, it is an opinion and that's fine, but opinions vary. :-)

        - Dan C.