OMG Ponies (Aka Humanity: Epic Fail)(msmvps.com)
msmvps.com
OMG Ponies (Aka Humanity: Epic Fail)
http://msmvps.com/blogs/jon_skeet/archive/2009/11/02/omg-ponies-aka-humanity-epic-fail.aspx
11 comments
What you're saying is that people will finally understand that thinking about a problem and preventing bugs before you begin is better than trying to fight fires afterwards.
Can we get significant digit support too? That would make my life a happier place.
edit: the joke about the horse mispelling "main()" by force of habit made me chuckle.
edit: the joke about the horse mispelling "main()" by force of habit made me chuckle.
>a language approaching Haskell's pedantic-ness
I believe the word you're looking for is "pedantry".
/pedant
I believe the word you're looking for is "pedantry".
/pedant
Yes, Haskell is not pedantic enough!
"due to rainfall thousands of miles away, my unit test had moved Greenland into Argentina. Fail."
Argentina's 11-day notice for changing their DST rules wreaked all sorts of unexpected havoc. It's sort of awesome (small worlds are more fun) and also totally exasperating.
Argentina's 11-day notice for changing their DST rules wreaked all sorts of unexpected havoc. It's sort of awesome (small worlds are more fun) and also totally exasperating.
The video, for those that missed the link in the second paragraph: http://vimeo.com/7403673
WAAAAY more entertaining w/ actual sock puppets.
Unicode has its own special line terminator character as well, just for kicks
<clippy>It looks like you're trying to refer to NEL, which is in Unicode because it was distinct in EBCDIC, and who doesn't want lossless round-trips? </clippy>
<clippy>It looks like you're trying to refer to NEL, which is in Unicode because it was distinct in EBCDIC, and who doesn't want lossless round-trips? </clippy>
Unicode also has separate Line Breaks and Paragraph Breaks somewhere around U+2000.
It's important to note that choice of language affects a lot of these issues. For example, the unicode issue in Python:
>>> s = unicode('Les Misérables','utf-8')
>>> print s[::-1]
selbarésiM seLNope, Python fucks this up just the same, even in Python 3:
>>> print u'Les Mise\u0301rables'[::-1] #2
>>> print('Les Mise\u0301rables'[::-1]) #3
selbaŕesiM seL
You can get the correct result by normalizing the string first:
>>> import unicodedata
>>> print unicodedata.normalize('NFC', u'Les Mise\u0301rables')[::-1]
selbarésiM seLThat's in some sense even more broken: Not all combined characters have a normalized form, so the result is even less predictable. (I don't have an example ready.)
[deleted]
Here’s a good series of articles on how it works in Ruby: http://blog.grayproductions.net/categories/character_encodin...
Apparently Ruby 1.9 handles it well.
(I wouldn’t be surprised if this had previously been linked on HN.)
Apparently Ruby 1.9 handles it well.
(I wouldn’t be surprised if this had previously been linked on HN.)
I saw this presentation at the London DevDays where Jon gave it.
I was quite far back, and when he walked on stage with the sock puppet on, I assumed it was one of those wrist support gloves that you use when you get RSI because you won't just stop typing all day long, even though you're harming yourself.
After all, I thought, it's Jon Skeet - he never stops typing, surely? :-)
I was quite far back, and when he walked on stage with the sock puppet on, I assumed it was one of those wrist support gloves that you use when you get RSI because you won't just stop typing all day long, even though you're harming yourself.
After all, I thought, it's Jon Skeet - he never stops typing, surely? :-)
I'm embarrassed. I admit it, I forgot Turkish upcases 'i' to İ. But the core teaching, which is "if it involves internationalization or talking to humans find a library written by a legitimate expert and use it instead" is true gold.
Yeah, but who expects to need a special library for uppercasing some seemingly Latin text?
The article really was entertaining. These are all common problems for new C# programmers.
Doubles in .net are IEEE 64-bit (8-byte) double-precision floating-point numbers . I've written a few different comparers to deal with problems like the one he demoed. He should have typed it to be a decimal if it was currency or he wanted it to have an exact value instead of be a double-precision floating-point number.
As for the reverse on the string. He reversed the characters, which are defined in .net as char / byte. Not unicode. If you want to play nice with unicode in .net you need to parse it as unicode. A hugely common mistake for all of us who have done some internationalization in .net.
I remember or sorts of trouble with java.util.GregorianCalendar back in the day. Ugh.
I'm not defending .net or C#. I'm just not surprised he ran into these newbie problems. You guys should see the evilness that is Access, the inconsistencies there make this look like nothing. And it's a black art with almost no documentation anywhere.
Doubles in .net are IEEE 64-bit (8-byte) double-precision floating-point numbers . I've written a few different comparers to deal with problems like the one he demoed. He should have typed it to be a decimal if it was currency or he wanted it to have an exact value instead of be a double-precision floating-point number.
As for the reverse on the string. He reversed the characters, which are defined in .net as char / byte. Not unicode. If you want to play nice with unicode in .net you need to parse it as unicode. A hugely common mistake for all of us who have done some internationalization in .net.
I remember or sorts of trouble with java.util.GregorianCalendar back in the day. Ugh.
I'm not defending .net or C#. I'm just not surprised he ran into these newbie problems. You guys should see the evilness that is Access, the inconsistencies there make this look like nothing. And it's a black art with almost no documentation anywhere.
Jon didn't run into most of these problems so much as answer others who did run into them on stackoverflow.com or the MS newsgroups.
> You guys should see the evilness that is Access, the inconsistencies there make this look like nothing. And it's a black art with almost no documentation anywhere.
Are you talking about MS Access? It's about 15 years old. There should be a lot of documentation. You need to look for old books form the last decade though.
Are you talking about MS Access? It's about 15 years old. There should be a lot of documentation. You need to look for old books form the last decade though.
he sums it up quite well at the end.
if you write a lot of code under a set of assumptions which then changes, you're in trouble.
I think the key question is: do my assumptions differ from my customers assumptions, if so where?
if you write a lot of code under a set of assumptions which then changes, you're in trouble.
I think the key question is: do my assumptions differ from my customers assumptions, if so where?
[deleted]
I think lisp is a good example: Most lisps have a full numeric tower that automatically converts between ints and bignums and ratios as appropriate. You don't have to think about the floating-point representation of 0.3 unless you wrote (double 0.3) in your code somewhere. Correctness should be the default, because it's much easier to trade some correctness for performance. Going the other way is much harder, and most people don't need performance.
This goes a long way, but now I notice the biggest obstacle is "legacy systems". The only time I get in trouble with the Clojure numeric tower is when I want to store a Ratio in the DB.