4 ms·

Actually, in defense of C++, there are not very many statically typed, compiled languages that can implement a type-safe print function that takes a variable nu

Actually, in defense of C++, there are not very many statically typed, compiled languages that can implement a type-safe print function that takes a variable number of arguments (that do not all share a base class) using the language itself. For many languages, print is special and the implementation is provided as part of the language implementation. ADDENDUM: Even iostreams back in the 1980's was a huge deal at the time, as it showed that it was possible to implement type-safe io in a statically typed, compiled language using language features just like any other library, instead of having it be special purpose.

forrestthewoods 4y ago
huh? Every new language has type safe print functions. Having to specify the type with printf formatters is archaic and awful.
- kccqzy 4y ago
  Most new languages with type-safe print functions are either dynamically typed (which makes this whole discussion moot) or leverage some significant advance in PL theory in order to make the print function type-safe. By advance, I mean not known before the 1990s.
  - forrestthewoods 4y ago
    Sorry, I explicitly meant statically typed languages. Rust, Nim, Zig, Odin, Jai, etc. > For many languages, print is special and the implementation is provided as part of the language implementation. Sure. Printing variables to strings is definitely worth language-level features imho. It's a bad thing if a language (C++) requires users to come up with extremely complex libraries (fmt/std::format) because the language lacks the features to make such a common operation simple and reliable. C style printf is a dumpster fire. C++ iostreams are unuseably slow. Modern languages definitely solve this particular problem much better!
    - atq2119 4y ago
      Rust's print! implementation is pretty darn complicated, wouldn't you say?
      - xigoi 4y ago
        However, Nim's is very simple: https://github.com/nim-lang/Nim/blob/version-1-6/lib/system/io.nim#L598 https://github.com/nim-lang/Nim/blob/version-1-6/lib/system/...
        elcritch 4y ago
        The magic that makes Nim’s print / repr functions really neat is the `fieldPairs` iterator that works on any type. It’s a comptime function to iterate fields of a type, very handy and very simple to use. It can work on any type unlike Rust’s Debug macro which only works on types you own and can annotate. https://nim-lang.org/docs/iterators.html#fieldPairs.i%2CS%2CT https://nim-lang.org/docs/iterators.html#fieldPairs.i%2CS%2C...
      - forrestthewoods 4y ago
        I don't know what Rust's print! implementation looks like. I also don't care. I am not a Programming Language programmer. I am a user of programming languages. Using C-style printf sucks balls. It's extremely error prone and it doesn't support complex types. Using Rust's print system is delightful. I can't make a type error and arbitrarily complex types can be printed with roughly zero effort via {:?} and #[derive(Debug)].
    - lmm 4y ago
      > Sorry, I explicitly meant statically typed languages. Rust, Nim, Zig, Odin, Jai, etc. Requiring a macro is no better than what C does. Most of those languages have a less awful macro system than C's, but that's not an actual language advancement. The state of printing is still awful in the languages you mention.
      - dilap 4y ago
joenot443 4y ago
Swift can do it, yes?
- meindnoch 4y ago
  Swift can do what? String interpolation is part of the language in Swift.
dureuill 4y ago
> For many languages, print is special and the implementation is provided as part of the language implementation. what's the point of not having print provided as part of the language implementation, though?
- int_19h 4y ago
  Print is not the only facility where strongly typed variadic arguments are useful. If you implement it as a builtin, all those other cases will have to be implemented as a library, and as a result, argument passing looks very different from print. And it is desirable that the same thing is consistently expressed in the same manner.
- Karellen 4y ago
  Because plenty of places where C is used won't need it, or indeed any part of libc. Also, it's a fairly simple to decide upon dividing line between the language and the library - if it can be implemented in a handful of assembly instructions (or, ideally, 1 instruction) it's part of the language. If it can't and needs a "function" (either in C, or implemented in assembly) to work, or needs to talk to some other part of the computer (like a kernel, or a BIOS) it's part of the library. Like malloc()/free() - again, not part of the core language spec, but part of the standard library, which can be omitted in some ("freestanding", as opposed to "hosted") implementations. Remember, C was created in the '70s. Memory was measured in kilobytes. Tens of kilobytes if you were lucky. Even through the '80s, 1 megabyte was a lot.
tragomaskhalos 4y ago
I always thought that iostreams was very elegant. But it wasn't until the internet came along that I learned that most of the rest of the world regards its use of `operator <<` as a crime against decency, so what do I know?

forrestthewoods 4y ago

huh? Every new language has type safe print functions. Having to specify the type with printf formatters is archaic and awful.

kccqzy 4y ago
Most new languages with type-safe print functions are either dynamically typed (which makes this whole discussion moot) or leverage some significant advance in PL theory in order to make the print function type-safe. By advance, I mean not known before the 1990s.
- forrestthewoods 4y ago
  Sorry, I explicitly meant statically typed languages. Rust, Nim, Zig, Odin, Jai, etc. > For many languages, print is special and the implementation is provided as part of the language implementation. Sure. Printing variables to strings is definitely worth language-level features imho. It's a bad thing if a language (C++) requires users to come up with extremely complex libraries (fmt/std::format) because the language lacks the features to make such a common operation simple and reliable. C style printf is a dumpster fire. C++ iostreams are unuseably slow. Modern languages definitely solve this particular problem much better!
  - atq2119 4y ago
    Rust's print! implementation is pretty darn complicated, wouldn't you say?
    - xigoi 4y ago
      However, Nim's is very simple: https://github.com/nim-lang/Nim/blob/version-1-6/lib/system/io.nim#L598 https://github.com/nim-lang/Nim/blob/version-1-6/lib/system/...
      - elcritch 4y ago
        The magic that makes Nim’s print / repr functions really neat is the `fieldPairs` iterator that works on any type. It’s a comptime function to iterate fields of a type, very handy and very simple to use. It can work on any type unlike Rust’s Debug macro which only works on types you own and can annotate. https://nim-lang.org/docs/iterators.html#fieldPairs.i%2CS%2CT https://nim-lang.org/docs/iterators.html#fieldPairs.i%2CS%2C...
    - forrestthewoods 4y ago
      I don't know what Rust's print! implementation looks like. I also don't care. I am not a Programming Language programmer. I am a user of programming languages. Using C-style printf sucks balls. It's extremely error prone and it doesn't support complex types. Using Rust's print system is delightful. I can't make a type error and arbitrarily complex types can be printed with roughly zero effort via {:?} and #[derive(Debug)].
  - lmm 4y ago
    > Sorry, I explicitly meant statically typed languages. Rust, Nim, Zig, Odin, Jai, etc. Requiring a macro is no better than what C does. Most of those languages have a less awful macro system than C's, but that's not an actual language advancement. The state of printing is still awful in the languages you mention.
    - dilap 4y ago

joenot443 4y ago

Swift can do it, yes?

meindnoch 4y ago
Swift can do what? String interpolation is part of the language in Swift.

dureuill 4y ago

> For many languages, print is special and the implementation is provided as part of the language implementation. what's the point of not having print provided as part of the language implementation, though?

int_19h 4y ago
Print is not the only facility where strongly typed variadic arguments are useful. If you implement it as a builtin, all those other cases will have to be implemented as a library, and as a result, argument passing looks very different from print. And it is desirable that the same thing is consistently expressed in the same manner.
Karellen 4y ago
Because plenty of places where C is used won't need it, or indeed any part of libc. Also, it's a fairly simple to decide upon dividing line between the language and the library - if it can be implemented in a handful of assembly instructions (or, ideally, 1 instruction) it's part of the language. If it can't and needs a "function" (either in C, or implemented in assembly) to work, or needs to talk to some other part of the computer (like a kernel, or a BIOS) it's part of the library. Like malloc()/free() - again, not part of the core language spec, but part of the standard library, which can be omitted in some ("freestanding", as opposed to "hosted") implementations. Remember, C was created in the '70s. Memory was measured in kilobytes. Tens of kilobytes if you were lucky. Even through the '80s, 1 megabyte was a lot.

tragomaskhalos 4y ago

I always thought that iostreams was very elegant. But it wasn't until the internet came along that I learned that most of the rest of the world regards its use of `operator <<` as a crime against decency, so what do I know?