Anyway. It's in about three hours.
- perl -le 'print time'
perl -le 'print scalar localtime(1234567890)'
3:31:30 PM PST, today. Please make a note of it.
today in time_t news
If you're like me, you've been seeing blog posts about "OMG it's time_t 1234567890!!" for the last two weeks. Stupid decimalists. There weren't nearly as many posts when time_t hit 0x40000000, and that's a far more interesting number.
perl -le 'print scalar localtime(1234567890)'
Tags: computers, firstperson, space, time_t
Current Music: Bow Wow Wow -- What's the Time (Hey Buddy) ♬
15 Responses:
And why was there no fanfare about 1234554321?
That's not a pangram!
That was fun. I drank champagne and kissed a Python programmer.
Damn! I missed it! But I did see the leap second on New Years Eve.
you're aware those parentheses are completely unnecessary?
You're aware that just because you can leave a byte out doesn't mean you should?
speaking as a disciple of arthur whitney, the idea never crossed my mind
(incidentally, in k4, it's
%"z"$(1234567890+86400*1970.01.01)%86400
in the unlikely even that anyone cares)
Although, out of curiosity, why did you choose to put the parens where you did? I would have expected either:
print( scalar( localtime( 1234567890 ) ) );(whitespace to taste) or
print scalar localtime 1234567890;Not criticizing; just curious, and since someone else brought up the topic...
I think of scalar as a cast, not a function. And nobody with any sense of taste or propriety puts space after an open paren or before a close paren.
Fair enough -- although, in most C-ish languages, casts require parens, don't they? Either way, why doesn't
printget parens as well?Then I guess I'm lacking in both. :-/
For me, it depends on the language. In Lisp, where there's a space before the first arg regardless, the closing paren make sense without a space (since it closes the entire sexp).
In C-ish languages such as Perl, however, I find it more natural to associate the parens with the function call than with the argument list. Taking that a step further, I prefer to see each argument as its own atomic entity, and not have to worry about whether a leading paren is a part of the expression evaluating to the first argument, or if it starts the argument list. I realize that this is a point of taste, and fortunately you'll never have to look at my code. :)
(Either way, I find the GNU standard of putting a space before the parens to be hideous:
function (arg1, arg2);... gah.)Since you asked, in C the type needs to be parenthesized in a case, viz.
(int) 3.5. In perl,(scalar) localtime(...)is syntactically incorrect and ugly as sin. C++ is an abomination and will not be discussed further. Perl's print doesn't get parenthesized because (depending on your rationale) it is only executed for its side-effects (so isn't properly a function) or because its the first function of a statement, which amounts to the same thing. This convention probably has more to do with BASIC than C. In Lisp terms, print is thought of as closer to a special form than to a function.Wow, my indifference to this whole thread could only be described as sexual in intensity, but I can't let your last sentence go: in what possible way is perl print a special form? It always evaluates all its arguments and does not include control structure. (The side effect thing is sufficiently specious as to warrant no further discussion.)
I said it's thought of in that way, not that it is a special form. Look at a perl program. Note where in the structure of the program special forms are used. Note where print is used.
In BASIC, print actually was a special form. The statment ender used on a print determined whether print output a newline at the end or not. Yeah, BASIC is awesome.
You're talking to one of the premier elisp hackers in the world, and you're asking him to reduce the number of parentheses?
That roll-over was fun when it broke AFS, which we rely on heavily at work. Doing some assumptions in the ubik code that caused the db servers to fail to compute a quorum was genius.