I made a bug once, and I need to tell you about it. So, in 2001, I wrote a
reference library for JSON, in Java, and in it, I had this line
private int index
that created a variable called "index" which counted the number of characters in
the JSON text that we were parsing, and it was used to produce an error message.
Last year, I got a bug report from somebody. It turns out that they had a JSON
text which was several gigabytes in size, and they had a syntax error past two
gigabytes, and my JSON library did not properly report where the error was — it
was off by two gigabytes, which, that's kind of a big error, isn't it? And the
reason was, I used an int.
Now, I can justify my choice in doing that. At the time that I did it, two
gigabytes was a really big disk drive, and my use of JSON still is very small
messages. My JSON messages are rarely bigger than a couple of K. And — a
couple gigs, yeah that's about a thousand times bigger than I need, I should be
all right. No, turns out it wasn't enough.
You might think well, one bug in 12 years you're doing pretty good. And I'm
saying no, that's not good enough. I want my programs to be perfect. I don't
want anything to go wrong. And in this case it went wrong simply because *Java
gave me a choice that I didn't need, and I made the wrong choice*.
EDIT: is there a reference for formatting comments? I've never been able to find one.
Most programs written in the real world (enterprise-y Java apps) do not need strong control on GC, choice of integer types, or many other things offered to them. Reducing choice will increase code/tool quality.
I think that we should make the uncommon choice reallllly hard to put into place. Make it a pain to configure the GC, give specific integer types really long names. Just stop people from premature optimization and leave these tools to people who know what they're doing.
One the one hand "implicit int" are being phased out in favour of explicit int size. Your variables cannot be `int` anymore, you have to sit down, think and choose: u8? u16? u32? i32? u64? i64? This avoids all the pains of programs behaving differently or crashing when compiled on different architectures.
On the other hand, a new "native integer for sizes that do not matter, minimum 32 bits" is being brewed, for example for pointer offsets or collection sizes. The idea is that you will not be able to have a collection with more of 2^32 elements in a 32-bit architecture nor more than 2^64 in a 64-bit architecture.
After this discussion, my hope is to see the introduction of a fast-ish dynamic bigint (that starts native and grow up to 256 or 512 bits) that can be used in all the cases where you do not care about the exact size type, yet you want to be future-proof (this `private int index` fits this case, IMO).
[1] http://discuss.rust-lang.org/t/if-int-has-the-wrong-size/454... [2] https://github.com/rust-lang/rfcs/pull/464
However, an overflow to floating point isn't necessarily an improvement because, while a float will hold bigger numbers, it does so with limited precision and sometimes that lack of precision will cause bugs too. Probably more often, in fact.
In the example given it wouldn't be so bad, but you'd only get an approximate indication of where the error occurred rather than a specific line/character. So of course, whatever is reporting the error would now need to understand and handle the much more complex scenario of "fuzzy" location information instead of a simple unique index to a specific character. Depending on what it then needs to do with that information, the complexity could spiral from there.
If you want to just have things work no matter what, you have no choice but to use bignums. I was wondering about this recently, so did some benchmarks in Clojure. The performance was horrible, so frankly this is still not a viable alternative. Maybe in 10 years time, if every CPU has a bignum coprocessor by then.
Also, there are times, particularly in low-level graphics programming or cryptography, where you actually want integer modulo arithmetic, or to be able to do bitwise booleans predictably. In those cases, JavaScript-style loose typing can be a huge pain.
BTW, I've been a big advocate of JavaScript for about as long as Doug Crockford, so my point isn't that JavaScript-style type handling is bad: just that it's very far from a silver bullet.
What if Java gave an arguably more useful choice--whether to use a signed or unsigned integer?
And I certainly don't believe there are programmers making only 1 mistake for 12 years. I believe he's just making a joke, or using the example as a means to an end.
*Java gave me a choice that I didn't need, and I made the wrong choice*IMHO Java makes some choices about safety. If you don't agree with those choices, use a different tool. It doesn't make Java wrong for having a different opinion. Likewise I wouldn't berate C for being too low level or Ruby for favouring readability over performance.
========
What kind of formatting can you use in comments?
http://news.ycombinator.com/formatdoc
========
Was that what you were looking for?
Put in perspective that is probably in excess the number of times the most favored "I Love Lucy" show has been seen. Or put another way, you've got a music video with the same eyeball impact as the highest rated television show ever.
That says to me that either advertising on Youtube is a bargain or advertising on TV is way over priced :-)
[1] http://tvbythenumbers.zap2it.com/2014/02/10/the-walking-dead...
(Of course, none of these streams show the same ads the original broadcast does—but if you're a clever ad agency, you're already doing product-placement instead of interstitials most of the time anyway.)
Can you name any examples of this?
The closest thing I can think of is Veronica Mars which was Kickstarted many years later and raised ~5 million dollars from 91,000 backers to make a single movie.
I think perhaps the "alternate consumption streams" viewers are not as lucrative as you think.
I think you just backdoored into the most interesting ad campaign ever: 1) Find a show with a directory / writer / production team known for producing content that "stands the test of time" (e.g. likely to have a high total_views_over_time:broadcast_views ratio) 2) Include product placement for a non-existent product by a currently-existing company with strong brand recognition 3) Test response to non-existent product by initial viewers 4) Start viral campaign around non-existent product (this likely favors "Hunh?" shows a la Lost or Fringe) 5) Trigger view bump in show (win award, produce new episodes in partnership with Netflix, produce new movie, etc.) 6) Launch real-product multiple years after initial product placement
For example, with I Love Lucy, the audience member likely sat and watched the entire commercial. With a YouTube video, the audience member can skip the ad or move on to other content.
TV = 22 minutes of content.
YouTube Video = 3 minutes of content.
Plus, the metrics that constitute views between the two media formats are completely different.
This song has been played many times by a relatively small section of the Dutch population :)
>there are plenty of other things to do on a computer while you wait through the ad.
Yea, for example you can buy the advertised product with a few clicks. If you are quick enough then you can finish the buying even before the video ad finishes (sure it's not the most realistic scenario but it's possible). Or with a quick search you can learn more about the product to check how honest is the ad. TV ads cannot compete with this efficiency. The only thing TV ads can do better is reaching bigger and the less tech interested audience.
NEITHER. Advertising on YT is worthless and yes it used to be way overpriced on TV.
EDIT: Which is the solution they apparently implemented, converting signed to unsigned at some higher layer.
"You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this." [0]
[0]: http://google-styleguide.googlecode.com/svn/trunk/cppguide.h...
"Never use a signed type for a number that can never be negative"
One of my pet peeves is developers using int (instead of unsigned ints) for primary keys in database tables.
... and now I realize you may be correct, and that it's probably inevitable that a viewcount will not only exceed the total number of people alive, but will double or even quadruple it. Our total population is actually about 100 billion, but only ~7% of us are still alive.
The shadows of the dead will be forever enshrined as YouTube view counts. Our shadows.
Edit: Now I realize that would mean Google couldn't have made this joke. But I am still not sure this was foreseen by Youtube devs from day one.
But it's real?! It seems incredibly absurd that it could actually overflow, how are signed values useful for a count of views? How are you going to have negative views?
http://stackoverflow.com/a/1555186/67591
TL;DR: Google's C++ coding standard says: "Document that a variable is non-negative using assertions. Don't use an unsigned type."
As someone who has written a lot of C++ code to interact with hardware: I view an unsigned as a bucket of bits, and a signed as a number.
I'm sure some software will need to be re-written between now and 2038, but I don't think it will be quite as bad as Y2K just because that was only a 15 year gap (Sometimes less), whereas this is over 24 years.
I just think a lot of software will be naturally replaced between now and then. And while there will be a slight mad scramble to fix stuff at the last minute, I don't think it is Y2K-2.
I doubt this will be a real problem in 2038, then again the prevalence of computing devices is much larger now and will continue to grow by 2038, but so will technical aptitude, so hopefully they'll cancel out and this will still not be a problem.
Regardless, it was bound to happen sooner or later as youtube is getting older.
Being Korean might've given it crossover appeal into much of Asia? Just a guess.
I think they gave people who would otherwise have looked down on a silly craze an excuse to enjoy the video.
Also, there are perfectly valid applications that require numbers of 8, 16, 32 or 64 bits (or variable encodings with arbitrary precision). Petabytes, embedded microcontrollers, etc.
I remember when Twitter had rolled over their tweet ID's because they were using an int type that was too short. Should have gone with variable length strings to avoid that problem.
It isn't a uint32, it is an int32.
Using strings avoids one problem but introduce a bunch of others (e.g. a string is harder to verify, therefore less secure, and therefore needs to be handled with the kiddie gloves). Checking that every character is between 0-9 and dropping all other characters is easy, cheap, and effective. Then just check it is between uint64.Min and uint64.Max, and you're done.
uint32 gives them twice as much capacity (which isn't enough at this stage), they'll likely want to go with a uint64.
Direct link to the video: https://www.youtube.com/watch?v=9bZkp7q19f0
https://www.youtube.com/watch?v=9bZkp7q19f0
EDIT: I just realized that YouTube also posted a comment to that effect just below the video. :P