Spaces work better than tabs because the code is always formatted properly. Code that is formatted improperly does not do what you think it does. This matters a lot when you have projects developed by 200+ developers with multiple millions of LOC. It matters even more when you have 3000+ developers working on many such code bases and they move between said projects with high frequency.
You cannot have your indent be two and me with 8 and have the code line up properly, especially when lining up complex if or math statements (where you may be using the level of indent to help with showing how the parens or operators nest). While you could argue "then split into multiple statements", I could argue "it's actually more readable as is". Subjective is neat that way.
Files that are being constantly updated because someone doesn't like someone elses formatting is dumb. Have a standard, stick to it. Fire the offender who refuses to play ball, problem solved.
Who prints code? Fine, let's say you do. Modifying the number of spaces per tab causes the issue I pointed out at phase 1.
Relationship argument makes no sense to me, sorry. Where the code lines up is what matters to me, not how many invisible characters appear between the beginning of the line and the first character.
It's a little shortsighted to use "always" to describe the web's winning streak for two reasons:
1) The web has not always won. Despite Google's Office suite, Microsoft continues to dominate the office space and will continue to do so for the foreseeable future. So at least in one market, thick clients have continued to win out over thin clients.
2) The web is just not that old. Claiming that the web will win because it has always won is a weak appeal to tradition made especially weak by the fact that the web is realistically 13-15 years old.
Here's my slightly offtopic rant for you slashdotters that think it's funny or clever to replace an 's' with a dollar sign.
I get it. You think that the entity being referred to is greedy. Here's what you don't seem to get. It's childish, and it does one of three things:
1) It gives the impression that your rhetoric wouldn't be strong enough to stand on its own--therefore you need a gimmick to ensure that people really get your message. 2) It's unrelated to your rhetoric, and therefore distracting from your overall message. 3) It makes you seem to be an uninformed, out of touch individual who has no concept of how things work in the real world.
I'm going to offer a bit of free advice, whether you want it or not. Spelling and presentation matter. And do you know why they matter? They matter because you're trying to convey a message. Your readers and listeners only have so much concentration they can or will devote to understanding your message. If we have to spend effort translating your spelling or grammatical errors, or we have to perform in-place symbol substitution, that is distracting us from the point you are trying to make. Do yourself a favor, and give up on these childish devices.
Here's a short list of the slashdotisms that need to die:
- Substituting '$' for 's' - ^H (acceptable for Funny posts only) - Calling Microsoft employees or users Microserfs
How many single workloads do you think were already pushing the 2G or 4G in the numbers that Intel was trying to sell into? And how many of those workloads do you think would've benefited from less than 50% more memory?
I can express this easily in python as well, and honestly given reasonable functions in C/C++, I could do so there. A lot of complexity in code is entirely dependent on how clearly you decide to make your code, and where you decide to provide helper functions.
For example, I'd probably do something like this in python:
for item in filter(lambda x: x.Checked, styleMenu):
if item.Style not in currentFont.ProvidedStyles:
item.Checked = false
Contrary to what a lot of purists say, I disagree that syntax is unimportant. I think it's very important. But I also think that where the syntax of a language fails you, you can (typically) make up a lot by writing helpful functions. For example, here's a stab at this in C++. Please forgive my early adoption of the auto keyword, I agree that the syntax of iterating over containers in stl is pretty verbose.
if (currentFont) {
auto items = styleMenu.items();
for (auto it = items.begin(); it != items.end(); ++it) {
if (!it->IsChecked()) continue;
if (!currentFont->ProvidesStyle(it->Style)) {
it->SetChecked(false);
}
} }
Language choice definitely matters, and many new languages offer high level abstractions that just make coding easier and more productive. But old languages can, for some cost, be made more easily readable, too.
According to this article, ~40% of class action lawsuits are dismissed, and virtually all others are settled. It's so rare, this article is ABOUT the novelty of a class action lawsuit going to trial.
The question is whether it will save you at least the overhead, where the overhead is a scrum master + 6.25% of the total project. Let's call that 10% total overhead.
If SCRUM doesn't save you 10%, it wasn't worth it--you should've used something else or nothing at all.
I see. On your PC that you bought from Best Buy 11 years ago, you were able to have your shows recorded to a digital medium from any arbitrary analog source? You could both watch a show and record something else, simultaneously? You had software that utilized a control scheme that realized you were human and it took you some time from the time you saw what you wanted to watch to when you pressed the button and adjusted accordingly? You had software that kept up with the shows you were watching, scheduling recordings based on a priority list, adjusted recording times when schedule changes occurred and warned you about conflicts when you recorded new shows? And you managed to do all of this for ~$450 (with no future expenditure required)?
Calling all of that innovation trivial is remarkably disingenuous.
What you're talking about is not particularly a good idea though, and would be done only by specific programs where they know that they need to have very large (> 2GB) data sets available, in memory, all at once, and that they are to be deployed on 32-bit systems--and was written entirely by masochists.
In order to take advantage of this functionality, the application would need to manage its own page table. Or instead of doing so, they could continue to allow the OS to manage it for them by either:
1) Targeting a 64-bit platform (easiest) 2) Providing a multi-process solution where each process provides access to no more than 2 Gb each, and then use a handle-based approach to access data in other processes.
Either of these solutions is both easier to implement (the first case in fact is trivial, but reduces your potential market footprint) than managing your own page table with the OS--which is error prone. Oh, and note that the second solution will take advantage of something else you're likely trying to do: scale versus the number of cores.
I don't suffer the lag you're talking about. I run a gtx260+ at 2560x1600 with 8xAA and every option turned up. I'm usually at 60, and never below 30.
I don't get network lag either, except when my cable is acting up. I run 25-mans and have no problems in Dalaran even when it's packed.
Moreover, I find the graphics and effects in WoTLK to be quite good. Sure they're not EQ2, but that's not the art style they're going for, so that's fine with me.
Why would anyone think that paying by the mile would reduce the amount I'm driving?
I don't go on long jaunts around the town just for the hell of it, I go because I need to get somewhere, or pick something up.
So pretty much what this would do is either be a savings for me--because it'd be less than my buffet style policy--or it'd be more expensive for me. I'm guessing that the majority of people, myself included, would fall into the latter category.
This is the key that sucks with SQL, once you commit to one vendor, its hard to escape.
This is laughably false if you stick to ANSI/ISO SQL. SQL is itself vendor-agnostic, it's a promise for an api.
Don't use vendor specific queries and you'll be completely portable. I've migrated many applications and DBs between postgresql, mysql, sqllite and oracle with little difficulty.
Slashdot Mirror
Spaces work better than tabs because the code is always formatted properly. Code that is formatted improperly does not do what you think it does. This matters a lot when you have projects developed by 200+ developers with multiple millions of LOC. It matters even more when you have 3000+ developers working on many such code bases and they move between said projects with high frequency.
You cannot have your indent be two and me with 8 and have the code line up properly, especially when lining up complex if or math statements (where you may be using the level of indent to help with showing how the parens or operators nest). While you could argue "then split into multiple statements", I could argue "it's actually more readable as is". Subjective is neat that way.
Files that are being constantly updated because someone doesn't like someone elses formatting is dumb. Have a standard, stick to it. Fire the offender who refuses to play ball, problem solved.
Who prints code? Fine, let's say you do. Modifying the number of spaces per tab causes the issue I pointed out at phase 1.
Relationship argument makes no sense to me, sorry. Where the code lines up is what matters to me, not how many invisible characters appear between the beginning of the line and the first character.
Read his post again, it was clearly written sarcastically.
Citation needed.
The reason it's the number 80 was rather arbitrary, but a throwback to old punch-card systems.
I say this in a slightly different, but more concise way:
Comments (and self-documenting code) should tell you "what" and "why", because the code is telling you "how".
It's a little shortsighted to use "always" to describe the web's winning streak for two reasons:
1) The web has not always won. Despite Google's Office suite, Microsoft continues to dominate the office space and will continue to do so for the foreseeable future. So at least in one market, thick clients have continued to win out over thin clients.
2) The web is just not that old. Claiming that the web will win because it has always won is a weak appeal to tradition made especially weak by the fact that the web is realistically 13-15 years old.
You must be new here... ;)
Here's my slightly offtopic rant for you slashdotters that think it's funny or clever to replace an 's' with a dollar sign.
I get it. You think that the entity being referred to is greedy. Here's what you don't seem to get. It's childish, and it does one of three things:
1) It gives the impression that your rhetoric wouldn't be strong enough to stand on its own--therefore you need a gimmick to ensure that people really get your message.
2) It's unrelated to your rhetoric, and therefore distracting from your overall message.
3) It makes you seem to be an uninformed, out of touch individual who has no concept of how things work in the real world.
I'm going to offer a bit of free advice, whether you want it or not. Spelling and presentation matter. And do you know why they matter? They matter because you're trying to convey a message. Your readers and listeners only have so much concentration they can or will devote to understanding your message. If we have to spend effort translating your spelling or grammatical errors, or we have to perform in-place symbol substitution, that is distracting us from the point you are trying to make. Do yourself a favor, and give up on these childish devices.
Here's a short list of the slashdotisms that need to die:
- Substituting '$' for 's'
- ^H (acceptable for Funny posts only)
- Calling Microsoft employees or users Microserfs
How many single workloads do you think were already pushing the 2G or 4G in the numbers that Intel was trying to sell into? And how many of those workloads do you think would've benefited from less than 50% more memory?
I can express this easily in python as well, and honestly given reasonable functions in C/C++, I could do so there. A lot of complexity in code is entirely dependent on how clearly you decide to make your code, and where you decide to provide helper functions.
For example, I'd probably do something like this in python:
for item in filter(lambda x: x.Checked, styleMenu):
if item.Style not in currentFont.ProvidedStyles:
item.Checked = false
Contrary to what a lot of purists say, I disagree that syntax is unimportant. I think it's very important. But I also think that where the syntax of a language fails you, you can (typically) make up a lot by writing helpful functions. For example, here's a stab at this in C++. Please forgive my early adoption of the auto keyword, I agree that the syntax of iterating over containers in stl is pretty verbose.
if (currentFont) {
auto items = styleMenu.items();
for (auto it = items.begin(); it != items.end(); ++it) {
if (!it->IsChecked()) continue;
if (!currentFont->ProvidesStyle(it->Style)) {
it->SetChecked(false);
}
}
}
Language choice definitely matters, and many new languages offer high level abstractions that just make coding easier and more productive. But old languages can, for some cost, be made more easily readable, too.
As a bit of a sidebar, you pay more than a "mild penalty" for using Ruby as opposed to C/C++
Comparison
You know, Palin is very familiar with Russian Roulette, primarily because Russia is her neighbor.
That's just false. All non-Live games work in offline mode in some capacity. It's part of logo testing.
According to this article, ~40% of class action lawsuits are dismissed, and virtually all others are settled. It's so rare, this article is ABOUT the novelty of a class action lawsuit going to trial.
That whooshing sound you hear all the time? That's every joke ever told rushing past you without any sort of comprehension on your part.
Brainfuck, whitespace, etc? These are all jokes. You're never intended to use them at all.
There are companies that do this. I'm fortunate enough to work for one.
It could, or it could not.
The question is whether it will save you at least the overhead, where the overhead is a scrum master + 6.25% of the total project. Let's call that 10% total overhead.
If SCRUM doesn't save you 10%, it wasn't worth it--you should've used something else or nothing at all.
I see. On your PC that you bought from Best Buy 11 years ago, you were able to have your shows recorded to a digital medium from any arbitrary analog source? You could both watch a show and record something else, simultaneously? You had software that utilized a control scheme that realized you were human and it took you some time from the time you saw what you wanted to watch to when you pressed the button and adjusted accordingly? You had software that kept up with the shows you were watching, scheduling recordings based on a priority list, adjusted recording times when schedule changes occurred and warned you about conflicts when you recorded new shows? And you managed to do all of this for ~$450 (with no future expenditure required)?
Calling all of that innovation trivial is remarkably disingenuous.
What you're talking about is not particularly a good idea though, and would be done only by specific programs where they know that they need to have very large (> 2GB) data sets available, in memory, all at once, and that they are to be deployed on 32-bit systems--and was written entirely by masochists.
In order to take advantage of this functionality, the application would need to manage its own page table. Or instead of doing so, they could continue to allow the OS to manage it for them by either:
1) Targeting a 64-bit platform (easiest)
2) Providing a multi-process solution where each process provides access to no more than 2 Gb each, and then use a handle-based approach to access data in other processes.
Either of these solutions is both easier to implement (the first case in fact is trivial, but reduces your potential market footprint) than managing your own page table with the OS--which is error prone. Oh, and note that the second solution will take advantage of something else you're likely trying to do: scale versus the number of cores.
I don't suffer the lag you're talking about. I run a gtx260+ at 2560x1600 with 8xAA and every option turned up. I'm usually at 60, and never below 30.
I don't get network lag either, except when my cable is acting up. I run 25-mans and have no problems in Dalaran even when it's packed.
Moreover, I find the graphics and effects in WoTLK to be quite good. Sure they're not EQ2, but that's not the art style they're going for, so that's fine with me.
Shrug, to each their own I suppose.
Usually at the end of the interview, I ask if I can speak with someone I'll be directly working with. Then I ask them questions like:
How do you like the work you're doing? Do you find it engaging and interesting? Is there a lot of red-tape to getting things done?
And my personal favorite. "What is your least favorite thing about this place?"
Answers like "my boss" or "work environment" are typically red flags to me. I'm looking for companies that wow me, though.
I saw this at New Scientist yesterday and almost submitted it, until I actually read the article.
Oh you newbies, reading articles before submitting them.
Why would anyone think that paying by the mile would reduce the amount I'm driving?
I don't go on long jaunts around the town just for the hell of it, I go because I need to get somewhere, or pick something up.
So pretty much what this would do is either be a savings for me--because it'd be less than my buffet style policy--or it'd be more expensive for me. I'm guessing that the majority of people, myself included, would fall into the latter category.
He mentioned terrorism and the war on drugs in a positive manner.
That would make his post rightist, not leftist.
Just sayin'.
But at least it's not redirecting me to a page offering me other helpful links.
Maybe I'm not in one of the test areas. (Austin).
This is the key that sucks with SQL, once you commit to one vendor, its hard to escape.
This is laughably false if you stick to ANSI/ISO SQL. SQL is itself vendor-agnostic, it's a promise for an api.
Don't use vendor specific queries and you'll be completely portable. I've migrated many applications and DBs between postgresql, mysql, sqllite and oracle with little difficulty.