Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re: An unreadable sentence (Score 1) 86

Yes, there were national fads that came and went—and the practice wasn't always universal, albeit beneficial for legibility to an inexperienced reader and safer for the type. By making the spaces not a fixed part of the block, it was still possible to remove them for tighter typesetting in limited spaces and to make sure there weren't unnecessary gaps at the ends of lines. Here's an example from 1808 that puts spaces around colons and semicolons, but not apostrophes, periods, or commas—and quotation marks are handled irregularly (they're hard to find, but there's an example on page 132, at the bottom.) For a comparable debate, German can be typeset with four different quote patterns (normal English-style quotation marks, using double low-nine inverted quotation marks, guillemets, and inverted guillemets, which is the style used in Switzerland.)

Comment Re: An unreadable sentence (Score 2) 86

Spacing around punctuation has been steadily declining as time goes on. Books from 200 years ago might go so far as to put spaces around commas and semicolons on both sides, with the following space also being larger—a convention also used for periods at the time. This is related to the practice of putting quotation marks and parentheses on the outside; slender punctuation blocks of metal type like periods, commas, and semicolons were fragile, so surrounding them in sturdier blocks made them less likely to get broken when the word was added to the page's master negative (the frame) or if the text needed to be reflowed. Double spacing originated as a typewriter-user's emulation of this practice, and as literacy and equipment improved, convention came to cater to both minimalism (thereby also saving paper) and skilled readers.

Comment Re:Infinity (Score 1) 1067

I mentioned the +/- zero thing in another comment elsewhere in this tree, actually! So we're all on board there.

It's not really that signless infinity is a contender for 'consensus' inasmuch as number systems which use signless infinity have utilities different from systems that have signed infinities, just like integer math continues to exist despite the 'improvements' of fractions and decimals.

Comment Re:Exceptions in Python list comprehensions (Score 1) 1067

Same reply: Python is not fully functional, and so list constructors like that cannot be counted upon to work elegantly in all situations. This is a completely normal thing common to basically every imperative language, and it's just something you have to accept—and write a special-purpose function for.

Comment Re:Exceptions in a map function (Score 1) 1067

I think that just means you're a zealot of functional programming; your expectations are wrong. If the language isn't fully functional in nature, don't expect key patterns like map() to work elegantly. They're hacks at best and not really part of the core language design; this is excellent proof of that.

Comment Re:Infinity (Score 1) 1067

You're just validating your own arbitrary decision to use that integer set. IEEE 754 defines positive and negative infinity separately. (However, if you look at the other comments below this one, you'll see that I argued for exactly this, reassigning the largest negative value to NaN in a signed integer format—but only for select situations.)

We're here to give you a computer, not a religion. - attributed to Bob Pariseau, at the introduction of the Amiga