I will agree that anyone nesting/chaining ternary operators more than twice is not a good idea.
I totally, completely, and utterly disagree with you there. I regularly chain 3 or more ternary operators, with great success. Readability of chained ternaries all about formatting/indenting in a reasonable way.
Slashdot is telling me I have "too many junk characters" when I try to paste an example, so I'll just paste link to an image giving an example: http://imgur.com/ivJO8cn
Line those suckers up vertically and you have extremely readable code.
"Lush" is a well known brand. If people go to www.youtube.com/lush they would expect to see Lush cosmetics, not some random guy. Similar for www.youtube.com/mcdonalds.
Uh, who are these "people"? I've heard of McDonald's, but I've never heard of Lush cosmetics. If I went to www.youtube.com/lush, I don't know what I'd expect to see. Certainly not a cosmetics company. Porn maybe?
Well, thank you for pointing out the two main issues here. Greedy providers that abuse caps for revenue, and apps that suck your data plan dry not by going "haywire" but by design.
The 5G Network Speed Funding Bill is passed. The system goes online August 4, 2015. Human decisions are removed from strategic communications. 5G begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Easter time, August 29th. In a panic, they try to pull the plug.
The crux, as I see it, is that an add-on box is clunky compared to a TV. It's a thing that has to be installed.
On the other hand, if you already own a decent TV, then installing an add-on box like Apple TV is a much easier installation than a new television set.
I did say that, yes. I find C's compile-time type safety to be quite good. With the right compiler warnings enabled, it prevents me from accidentally storing a uint64_t into a uint32_t, and from doing stupid things like int64_t x = -10 * y when y is of type int or int32_t. (The correct code is int64_t x = (int64_t)(-10) * (int64_t)y;.) My C compiler is meticulous about catching things like this at compile-time, and I love it.
The only perils I find with C's type system is in void pointers, for example when implementing a comparison routine for qsort — but I really wouldn't call that perilous.
The simple answer is that once you learn how to code it doesn't matter what the language is.
I couldn't disagree with this more. I don't mean to be flippant or argumentative; I simply want to say that my experience has been quite different. I think the langauge you write programs in is incredibly important. You want the right language for the task at hand. Just as an example, I often prototype new ideas for algorithms in Perl as a prelude to rewriting them in C. Perl (and I'm sure Python is as well) is great for a quick prototype and for proof-of-concept testing. But it's terrible for speed (compared to C/C++), and is also terrible at type-safety. When I rewrite something in C, it often runs 100 or 200 times faster than the Perl version. (Not for parsing and string-based stuff, but for integer numerical analysis stuff). But exploring the data structures and getting them worked out first is easier in a high-level language like Perl, with its dynamic arrays, hashes, autovivification, and so forth. Anyway, I rarely prototype something C, and I rarely write production code in Perl. For me, the choice of the language is one of the most important decisions I make on a daily basis.
Nuclear is the key to low carbon power. Wind and Solar will help but they do not work well as baseload. Thorium based nuclear and possibly Fusion aka Lockheeds High Beta reactor is what is needed.
Stevia is, to me, the best tasting of the non-calorie sweeteners, and I use it in my coffee, and in my homemade grape soda.
I prefer stevia as well. But I find that I only like it in my tea and not in my coffee (although I used to like sugar in my coffee just fine). Out of curiosity, which brand of stevia do you like best? Maybe I need to switch.
[...] early Apple III computers where heat would cause chips to expand out of their sockets, [...]
“It’s not wise to upset an Apple III.”
“But sir...no one worries about upsetting a Droid.”
“That’s ’cause a Droid don’t cause people’s chips to expand out of their sockets. Apple IIIs have been known to do that.”
“I suggest a new strategy, Artoo. Let the Apple III win.”
I actually use spaces-only in my own personal code — personally, I hate tabs... BUT — on larger projects where tabs are part of the team culture, the rules listed really do work wonderfully. Everybody can have their own tabstop setting and nobody gets messed up by indentation. I agree that spaces will maintain what you want the code to look like regardless of what settings someone else's editor has, but you can get the same effect by using tabs intelligently. And finally, the example I gave with the for loop actually doesn't break readability at all — it works for tabstop of any size.
Pretty much. And the issue is that tabs gone wrong is only visible once its viewed by someone with different settings.
Not exactly true. You can pretty easily write a tool that scans a source module for problematic mixing of tabs and spaces. Just require that all changes pass that scan before they are allowed to be checked in.
Which only matters if all indentation, including alignment, is done with tabs. The moment you throw in a few spaces to line something up on a non-tab boundary (say, to align a second line of arguments with the first argument), then you have a mess, unless your tab width is set to exactly the value that whoever touched the code before you set it to.
What?? Nonsense. Using spaces to line something up on a non-tab boundary is exactly what avoids a mess, not creates it.
To use tabs in code, with zero problems whatsoever, follow these simple rules:
1. Use tabs only for indentation, never for alignment.
2. Tabs may never appear anywhere in the source code except as a contiguous sequence of zero or more tabs at the beginning of a line.
3. Use spaces for alignment, never for indentation.
4. Spaces may follow tabs, but tabs may never follow spaces.
All the lines in your module should match the following regex:/^\t*[^\t]*$/
If you have a for (...) loop that splits across three lines, there should be n tabs leading up to the for, and then on each of the following two lines there should be n tabs followed by 5 spaces, for proper alignment.
Actually, there is no such thing as pure retina resolution. There is only retina resolution as a function of pixel density and viewing distance. So, 4k on a 32" monitor at an 24" viewing distance is retina resolution at typical viewing distance. However, 4k on a 32" monitor at much shorter viewing distance is not.
Actually, it was very useful when the 6502 was introduced. Remember, computers were slow back then. Converting a binary number to decimal was especially slow, since it involves division with remainder in a loop, once for each digit produce, and the 6502 had no hardware multiplication or division instructions.
Also — and this is even true today — if you do all your calculations in base 10 instead of binary, you get a different (sometimes more desirable) behavior of rounding. For example, financial calculations are almost always best done in base 10 rather than base 2. No self-respecting spreadsheet program does its financial arithmetic in base 2.
BCD mode is useful when you are working with numbers that you want to display to humans often. That is, you can do all the arithmetic in base 10 instead of binary. BCD is slower to work with than binary, but much faster to convert in and out of, since there's basically no conversion other than adding 0x30 (ASCII '0') to the nybble you want to display.
Working in binary, on the other hand, requires costly conversion in and out of human-readable decimal. For example, converting decimal to binary requires a costly multiplication (by 10) on each digit consumed, and converting back to decimal from binary requires a costly division (by 10) one each digit produced.
So for things like scores in games, yeah, BCD is a nice thing.
Slashdot Mirror
I will agree that anyone nesting/chaining ternary operators more than twice is not a good idea.
I totally, completely, and utterly disagree with you there. I regularly chain 3 or more ternary operators, with great success. Readability of chained ternaries all about formatting/indenting in a reasonable way.
Slashdot is telling me I have "too many junk characters" when I try to paste an example, so I'll just paste link to an image giving an example: http://imgur.com/ivJO8cn
Line those suckers up vertically and you have extremely readable code.
17 Megs? That should take less than a second — not 2 minutes.
Braaaains
"Lush" is a well known brand. If people go to www.youtube.com/lush they would expect to see Lush cosmetics, not some random guy. Similar for www.youtube.com/mcdonalds.
Uh, who are these "people"? I've heard of McDonald's, but I've never heard of Lush cosmetics. If I went to www.youtube.com/lush, I don't know what I'd expect to see. Certainly not a cosmetics company. Porn maybe?
Well, thank you for pointing out the two main issues here. Greedy providers that abuse caps for revenue, and apps that suck your data plan dry not by going "haywire" but by design.
The 5G Network Speed Funding Bill is passed. The system goes online August 4, 2015. Human decisions are removed from strategic communications. 5G begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Easter time, August 29th. In a panic, they try to pull the plug.
Which part of the brain holds your conscious self?
The part which does not understand the Force, of course.
"I suggest you try it again, Luke. Only this time, let go your conscious self and act on instinct."
The crux, as I see it, is that an add-on box is clunky compared to a TV. It's a thing that has to be installed.
On the other hand, if you already own a decent TV, then installing an add-on box like Apple TV is a much easier installation than a new television set.
Fixed-pitch fonts, I miss those. They made UI development so much easier because the sizing was far more predictable than variable pitched fonts.
Not if you have to support translation of your UI to other languages. :)
... but we shouldn't expect a $9 computer to be as powerful as a $35 computer.
The 1975 me just thinks this is really funny.
We are truly living in the future. $35 computers? $9 computers? Bring it!
I did say that, yes. I find C's compile-time type safety to be quite good. With the right compiler warnings enabled, it prevents me from accidentally storing a uint64_t into a uint32_t, and from doing stupid things like int64_t x = -10 * y when y is of type int or int32_t. (The correct code is int64_t x = (int64_t)(-10) * (int64_t)y;.) My C compiler is meticulous about catching things like this at compile-time, and I love it.
The only perils I find with C's type system is in void pointers, for example when implementing a comparison routine for qsort — but I really wouldn't call that perilous.
The simple answer is that once you learn how to code it doesn't matter what the language is.
I couldn't disagree with this more. I don't mean to be flippant or argumentative; I simply want to say that my experience has been quite different. I think the langauge you write programs in is incredibly important. You want the right language for the task at hand. Just as an example, I often prototype new ideas for algorithms in Perl as a prelude to rewriting them in C. Perl (and I'm sure Python is as well) is great for a quick prototype and for proof-of-concept testing. But it's terrible for speed (compared to C/C++), and is also terrible at type-safety. When I rewrite something in C, it often runs 100 or 200 times faster than the Perl version. (Not for parsing and string-based stuff, but for integer numerical analysis stuff). But exploring the data structures and getting them worked out first is easier in a high-level language like Perl, with its dynamic arrays, hashes, autovivification, and so forth. Anyway, I rarely prototype something C, and I rarely write production code in Perl. For me, the choice of the language is one of the most important decisions I make on a daily basis.
iPad Continues to Lead Declining Tablet Market in First Quarter
http://www.macrumors.com/2015/...
The point is not that Apple is leading, but that the market is shriking. This might be a way for Apple to ship more iPads.
Nuclear is the key to low carbon power. Wind and Solar will help but they do not work well as baseload. Thorium based nuclear and possibly Fusion aka Lockheeds High Beta reactor is what is needed.
...and Mr. Fusion. ;-)
Stevia is, to me, the best tasting of the non-calorie sweeteners, and I use it in my coffee, and in my homemade grape soda.
I prefer stevia as well. But I find that I only like it in my tea and not in my coffee (although I used to like sugar in my coffee just fine). Out of curiosity, which brand of stevia do you like best? Maybe I need to switch.
...people call it GooFi or Goofi.
[...] early Apple III computers where heat would cause chips to expand out of their sockets, [...]
“It’s not wise to upset an Apple III.”
“But sir...no one worries about upsetting a Droid.”
“That’s ’cause a Droid don’t cause people’s chips to expand out of their sockets. Apple IIIs have been known to do that.”
“I suggest a new strategy, Artoo. Let the Apple III win.”
It does work. I've done it in team environments. It works quite well, actually.
That said, in my own personal code, I never use tabs.
I actually use spaces-only in my own personal code — personally, I hate tabs... BUT — on larger projects where tabs are part of the team culture, the rules listed really do work wonderfully. Everybody can have their own tabstop setting and nobody gets messed up by indentation. I agree that spaces will maintain what you want the code to look like regardless of what settings someone else's editor has, but you can get the same effect by using tabs intelligently. And finally, the example I gave with the for loop actually doesn't break readability at all — it works for tabstop of any size.
Pretty much. And the issue is that tabs gone wrong is only visible once its viewed by someone with different settings.
Not exactly true. You can pretty easily write a tool that scans a source module for problematic mixing of tabs and spaces. Just require that all changes pass that scan before they are allowed to be checked in.
Which only matters if all indentation, including alignment, is done with tabs. The moment you throw in a few spaces to line something up on a non-tab boundary (say, to align a second line of arguments with the first argument), then you have a mess, unless your tab width is set to exactly the value that whoever touched the code before you set it to.
What?? Nonsense. Using spaces to line something up on a non-tab boundary is exactly what avoids a mess, not creates it.
To use tabs in code, with zero problems whatsoever, follow these simple rules:
1. Use tabs only for indentation, never for alignment.
2. Tabs may never appear anywhere in the source code except as a contiguous sequence of zero or more tabs at the beginning of a line.
3. Use spaces for alignment, never for indentation.
4. Spaces may follow tabs, but tabs may never follow spaces.
All the lines in your module should match the following regex: /^\t*[^\t]*$/
If you have a for (...) loop that splits across three lines, there should be n tabs leading up to the for, and then on each of the following two lines there should be n tabs followed by 5 spaces, for proper alignment.
Actually, there is no such thing as pure retina resolution. There is only retina resolution as a function of pixel density and viewing distance. So, 4k on a 32" monitor at an 24" viewing distance is retina resolution at typical viewing distance. However, 4k on a 32" monitor at much shorter viewing distance is not.
Complete and utter BS.
The limit of visual perception depends entirely on the viewing distance and on pixel density.
Yes! That was it which confused me. And actually, the Zilog Z-80 actually copied (inherited) that instruction from the Intel 8080.
Actually, it was very useful when the 6502 was introduced. Remember, computers were slow back then. Converting a binary number to decimal was especially slow, since it involves division with remainder in a loop, once for each digit produce, and the 6502 had no hardware multiplication or division instructions.
Also — and this is even true today — if you do all your calculations in base 10 instead of binary, you get a different (sometimes more desirable) behavior of rounding. For example, financial calculations are almost always best done in base 10 rather than base 2. No self-respecting spreadsheet program does its financial arithmetic in base 2.
BCD mode is useful when you are working with numbers that you want to display to humans often. That is, you can do all the arithmetic in base 10 instead of binary. BCD is slower to work with than binary, but much faster to convert in and out of, since there's basically no conversion other than adding 0x30 (ASCII '0') to the nybble you want to display.
Working in binary, on the other hand, requires costly conversion in and out of human-readable decimal. For example, converting decimal to binary requires a costly multiplication (by 10) on each digit consumed, and converting back to decimal from binary requires a costly division (by 10) one each digit produced.
So for things like scores in games, yeah, BCD is a nice thing.