The proper list starts with:

   1956: Fortran I:
            PRINT 1, X
         1  FORMAT (F10.2)

Fortran was able to use the same format specification for more than one print statement, that's why the format statement is referenced by number. It was even able to do repeats, for example this code from 1956

        PRINT 2, X, Y, A, B, C, D, N
      2 FORMAT ( 3 ( F10.3, F10.4 ), I4 )

is an equivalent of the following C:

    printf( "%10.3f%10.4f%10.3f%10.4f%10.3f%10.4f%4d",
    x, y, a, b, c, d, n );

Moreover, C interprets the format specification at runtime, in FORTRAN the compiler uses it during the compilation.

Fortran was invented by John Backus and there was already a finished compiler in 1956:

"Programmer's Reference Manual Fortran Automatic Coding System For IBM 704"

http://www.fh-jena.de/~kleine/history/languages/FortranAutom...

I/O in the first Fortran, I believe including the FN.M syntax, was implemented by Roy Nutt, also one obvious genius:

http://www.smartcomputing.com/editorial/dictionary/detail.as...

char format[10] = "%10.3f%10.4f%10.3f%10.4f%10.3f%10.4f%4d";

printf( format, x, y, a, b, c, d, n );

You can get similar behavior from C, reusing the format specification? No idea if this was true in the K&R days though.

But not the repetition inside of one specification which I illustrated in the example (note the 3 before the braces in the 2 FORMAT), and much more important, no compile-time type checking and compile time code generation for output. In C it's a library call and most of the processing happens at the run-time. And yes I know of gcc checks.

Still whoever uses some printf variant today, misses some aspects of what was working in 1956.

I was only addressing your first point, not your second example which you demonstrated clearly earlier. The recursive syntax is impressive alright - thanks for sharing it. I was unaware of it, as I'm sure many others were. I was not suggesting C has a built in method for achieving the results of the second example. I'm not certain about the compile time versus execution time distinctions. The compiler behaviour could depend on the mutability of the objects. It's possible a C #define constant would cause different compile time behaviour to variables. I'm not a compiler expert in either language so I can't provide any insight in any case.

Those GCC checks you mentioned are handy and would have avoided a bug in production code a colleague encountered a few years ago, but I imagine they are more recent than C in 1982, and certainly more recent than Fortran in 1956

#define formata "%10.3f%10.4f"

#define formatb(z) z z z "%4d\n"

printf( formatb(formata), x, y, a, b, c, d, n );

The example you've given is thought provoking!

Neat, I didn't know Fortran did printf right.

OCaml and Rust both have compile-time format string checking and code generation as well.

I think you started your code on the wrong column... ;-)

I'm not sure what the point of this is. It seems pretty petty. To wit, we could have just we well written...

    MACLISP (1980):
    (format t "Week ~R of the ~:R month of the year ~:@R~%" 15 102 1996)
        --> Week fifteen of the one hundred second month of the year MDCCCCLXXXXVI

    C/C++/Java/Python/Ruby:
    ...uh...

    COMMON LISP:
    (format t "Week ~R of the ~:R month of the year ~:@R~%" 15 102 1996)
        --> Week fifteen of the one hundred second month of the year MDCCCCLXXXXVI

There are powerful print functions and then there are powerful print functions.

Where's your sense of humor? It was intended to be funny, and it was.

Of course, like all irony the glass is only half funny.

Clojure has cl-format. (http://richhickey.github.com/clojure/clojure.pprint-api.html...)

Ditto for Perl: https://metacpan.org/module/Lisp::Fmt

This is a very specific selection. There are plenty of modern languages that don't use printf semantics or C-like syntax. Too, there's languages from the 80s and 90s that did: Python (1991), R (1993), and PHP (1995) come to mind for direct printf analogs.

Unfortunately, much of the industry is still stuck in 1996 because, hey, IDEs take care of the boilerplate, so it's "free", right?

Hmm

      printf "%10.2f"

-- Haskell, 1990.

Is the author related to this post made 4 days ago here on HN? http://news.ycombinator.com/item?id=3942636

Both claim to have gotten it from http://www.horstmann.com/

None of these are syntax. `printf` in C or scala/groovy is a function call, which relates to the language's API, the C++ use of streams is an API decision, Java being funky is due to its API (and its semantics to a lesser extent). The only language I can think of off the top of my head where print would be syntax would be python, and even then 1) that's only for versions <=2, and 2) the formatting would still be an API choice.

printf/scanf do have a syntax. But you're not wrong saying it is not part of the syntax of the language stricto sensu.

I personnaly don't like the printf/scanf style, which unfortunately often prevails in newer languages. I definitely prefer the string interpolation method, or just plain string concatenation.

> I definitely prefer the string interpolation method, or just plain string concatenation.

You're mixing things up; the point of printf is to format data, of which "%s / %s / %s" is a subset. Constructs like "0x%04x" or "%12s" really are about formatting.

Yes, but they're often used for "mere" interpolation, especially in languages where, rightly or wrongly, string concatenation is believed to be inefficient. I personally do this nine times out of ten, if only out of habit.

For my part, I've never personally liked the use of "+", in particular, to denote concatenation, for the (admittedly silly) reason that string concatenation is not commutative. If nothing else, it's a bit of a slippery slope to even more dubious operator overloads, though not nearly so much as C++'s bloody I/O "operators"!

It's not uncommon to use + for groups even if they're not abelian, esp. with near-rings.

This takes all its importance with duck-typing, as syntactic sugar of binary operators will be translated to a method call, e.g in Ruby a + b becomes a.+(b) [0]. while in Python it's a.__add__(b) [1]. The result might be commutative, but the call and evaluation order certainly is not.

[0] http://ruby-doc.org/core-1.9.3/Fixnum.html#method-i-2B [1] http://docs.python.org/reference/datamodel.html#object.__add...

Fortunately, Java is "developing" with regard to its expressiveness.

Using Scala and co only brings you a part of the way, especially if you have to interact with Javaesque APIs like in Android, where you have dozens of different abstract classes (or sometimes interfaces) begging for anonymous inner classes.

In 1956 there was such a thing as "the compiler business". Companies bought compilers.

Now, most programmers only speculate what a compiler does. They are so focused on language details.

Few want to write compilers. Many want to write yet another new language.

Heh. Cute.

As a Java programmer, I agree that NumberFormat looks ridiculous there. It's a lot of work for a single number to string conversion.

Luckily, since Java 5 there is a printf function:

    System.out.printf(...);

That's in the article.

Does anyone else find a headline about the emergence of traditional orthodoxy in syntax that omits a closing paren in favor of an emoticon to be maddeningly ironic?

OP is being manipulative, selecting a tiny slice of a language's API to exaggerate his petty point.

You just have to type hello world in HTML. Beat that.

  H

is "Hello World" in HQ9+

http://www.dangermouse.net/esoteric/hq9plusplus.html

:P

Ruby: p "%10.2f" % x

Progress™!