• anonymous (unregistered)

frist!

• Brillant (unregistered) in reply to anonymous

Brillant!

• allo (unregistered)

Now try to calculate, which colors will appear more often than others.

• (nodebb)

TIL the character "10" is the hexadecimal equivalent of the bit value FILE_NOT_FOUND.

Anyone knows that bit values are either 0, or 1, or FILE_NOT_FOUND, or something in between, so never 2.

0.81347 would be totally acceptable, though.

• Lurch (unregistered) in reply to PWolff

Well, there is only one number, 1. Every other number is constructed from it. So yes, 0.81347 is totally acceptable.

• (nodebb)

I teach a beginner's Python course. When the question came up of what `repr()` does, I tried explaining that it is used to get a standardized representation of a Python data structure. To illustrate, I used the example of `repr(0x100)` which evaluates to `256` just like `repr(256)`, you see? This was a complete surprise to people not accustomed to hexadecimal notation, i.e. most everybody. I managed to further sow confusion about the nature of numbers in Python, because I couldn't resist also mentioning `0b100000000`. "You see how binary has four digits for every hex digit?" It then devolved into a discussion of the different values of 10, 0x10, and 0b10 and that only the first of the three may be called "ten".

Understanding that numbers are not stored in decimal notation is an important step in programming but better not introduced off-handedly. Next time this happens I will do what every parent does once in a while: "repr() is for when you want to get exactly what's inside a variable, you will be very glad this exists in the future." and leave it at that.

• kktkkr (unregistered) in reply to PWolff

How to read bit values: 0: binary 0.000000... is really 0. 1: binary 0.111111... is really 1. 10: binary 0.101010... is really 2/3.

(By the same logic, the hex digit '10' is really 16/17, so 10<1.)

Of course now that we have quantum computing this is almost relevant as a qbit can be either 1, 0 or undetermined....but then again if you try to read it it will settle to an observable 1 or 0 state so....

• Sarcasto (unregistered) in reply to gleemonk

"I will do what every parent does once in a while: "repr() is for when you want to get exactly what's inside a variable, you will be very glad this exists in the future." and leave it at that."

But if you don't talk to your kids about repr() then they'll have to learn about it from the street...

• configurator (unregistered) in reply to Ron Fox

A single qubit can only have six states, 0, 1, +, -, clockwise or counter-clockwise. The real brilliance is once you have more than one qubit in a single system, when they can achieve an entangled probabilistic space, where e.g. two qubit can either be 0+ or 1- but not 0- or 11.

• Foo AKA Fooo (unregistered) in reply to kktkkr

Nope, 16/255.

Anyway, this individual wouldn't be writing code in any of my projects either. Not because of that bug (things happen), but because the person obviously doesn't have any kind of debugging mindset. The code doesn't behave as expected? So either there's a bug in your code (impossible, I know), or the language/runtime/OS/... is buggy (time to file a report) or your hardware is broken (get a replacement, especially as a programmer it's pointless to work on buggy hardware). But just plastering it over with a stupid workaround, without finding the cause? Worse Than Failure indeed!

• (nodebb) in reply to Sarcasto

Yeah but I trust them to be responsible. They've already discovered python.org and are passing links around. Though the API docs are reportedly a bit "hard to understand". I assured them that it "will all make sense".

Joking about this reminds me of the old saying: "Documentation is like sex. If it's good, it's really, really good. If it's bad, it's better than nothing." The least you could say about Python is that there is a lot of documentation.

• Matt (unregistered)

TRWTF is setting a color with a random hex code just isn't acceptable... how many hurt eyes is that... ;)

• Erik (unregistered)

char! char! char! That's all I say! char!

• Norman Diamond (unregistered)

"Documentation is like sex. If it's good, it's really, really good. If it's bad, it's better than nothing."

You can get herpes from MSDN.

• The Original Fritz (unregistered) in reply to Norman Diamond

• Herby (unregistered)

Bases are a bit weird! In the language FORTH, there is a variable that tells the interpreter how to convert numeric input. The best thing to play on a FORTH noob, is to ask them to write a program to tell you the base being used.

It isn't as simple as it sounds.

• isthisunique (unregistered)

Futurama reference? I thought I saw a two!

• RichP (unregistered) in reply to isthisunique

There, there... there's no such thing as two.

• (nodebb) in reply to gleemonk

"Documentation is like sex. If it's good, it's really, really good. If it's bad, it's better than nothing."

The second part isn't true. There are different ways in which documentation can be bad, and some of those ways make it worse than nothing.

Case in point: the Windows 98 DDK (Driver Development Kit). This was divided into two parts, the classic VxD part (like Windows 95, 3.11, 3.1, and 3.0 used) and the newer "WDM" (Windows Driver Model or some such) part, about which I know nothing.

The documentation for the programming interfaces for VxDs managed to hit most of the ways that documentation can be bad. Much of it dated from the days of Windows/386, which was a variant of Windows 2.11 and also the direct forerunner of Windows 3.0 Enhanced Mode. Some parts were introduced in Windows 3.0, or 3.1, or 3.11, or even 95. Some parts of the documentation covered features that had been updated for one or more of the aforementioned versions (or even for every single one of them) and had missed documentation updates to account for one or more of the changes, so no longer reflected what really happened. Some parts had, in fact, never been correct at all.

In general, documentation that is incorrect may in fact be dangerous, because it may conceal hazards. (The canonical example is documentation that says that the next room is safe. If I trust this, I will not wear my hazard suit, and the radiation source in there will kill me. The alternative version is one that is known to contain frequent errors, and often exaggerates dangers. When it says that the next room is dangerous, do I trust it? What if I suspect that it misidentifies the hazard?)

• Karl Bielefeldt (github)

I can somewhat empathize with this guy. I think we've all had occasions like this where we stare at code for an hour and just can't figure it out, usually the last hour of the day. Of course, most of us call it a day, and in the morning we can't believe how stupid we were.

• TimothyB (unregistered)

@Norman Diamond and Steve_The_Cynic: What would you consider good documentation then? These days I'm using the C# drivers for MongoDB. All the "documentation" was automatically generated from comments in the source code. It's a WTF. I so miss MSDN where most of the pages have examples on how to use the API.

• Norman Diamond (unregistered)

I so miss MSDN where most of the pages have examples on how to use the API.

Do you miss examples that don't work? Do you miss examples that don't even compile? Do you miss examples that work sometimes but not other times, so they'll fail on your customers' machines? The only thing more fun than Microsoft making Microsoft's customers do the testing is Microsoft making my customers do the testing.

• (nodebb)

I don't see any strings with a "10." - however there is an element containing the string "10". Don't know why the author included the dot in the string literal.

• Dave N (unregistered)

Because, in English, when you end a sentence with a quotation, the full-stop (or "period" if you prefer) goes inside the quotes, "like this."

• TimothyB (unregistered) in reply to Norman Diamond

My experience with MSDN is that it has given me sufficient information to successfully develop applications. That's good enough for me.

I'm sorry your experience with Windows was so bad. It's been a decade, since I first saw you writing similar things on MS blogs. I hope you've been able to move onto a different OS and are happier now.

• Mike_H (unregistered) in reply to Dave N

Put simply, in British English, which you seem to lean towards, since you called a period a "full-stop" (incidentally there's no hyphen), punctuation goes where it logically belongs. In US English it always goes inside the quotes.

• Nathan J. (unregistered) in reply to Mike_H

No, actually, punctuation does not "always go inside the quotes for US English. There are three main situations: periods and commas are always inside, colons and semi-colons are always outside, and exclamation points and question marks depend on whether they were in the original quote.