I sometimes use different fingers for the same key - entirely subconsciously. I find it fascinating how my brain automatically computes the movements needed based on the word I'm about to type. That's the catch, though - I actually need to know ahead of time what I'm about to type, so I'm not nearly as good at copying material as I am at typing put my thoughts.
"Touch typing" is hardly the only "correct" way of typing.
I had one of these where the keyboard involved was wireless. The keyboard was haphazardly stored in a stack of junk near the computer (after the user installed a new keyboard, apparently), with the receiver still plugged in, and then books were placed on top of it.
Seeing the situation after responding to the complaint about the beeping, I immediately knew what the problem was, but it took me some time to actually find the keyboard.
Although I don't think it qualifies as best of 2012, since it's updated just once in 2012, it's still very good. I also didn't know it updated, since it hasn't in years. Thanks for the heads up!
The art is done by the artist (David Hellman) who did the art for Braid (which was right after the comic stopped updating).
and now had enough cash I didn't need to work and could actually enjoy games as a player rather than as a developer.
Personally, as a player-turned-developer, I find it difficult to enjoy games past a certain point without the opportunity to participate in their creation.
"The problem was named after an incident in 1996 in which AOL's dirty-word filter prevented residents of the town of Scunthorpe, North Lincolnshire, England from creating accounts with AOL, because the town's name contains the substring cunt.[1] Years later, Google's filters apparently made the same mistake, preventing residents from searching for local businesses that included Scunthorpe in their names.[2]"
I know plenty of 'geeks', myself included, who hate [i]the way CGI is sometimes (ab)used[/i], but not CGI itself, not across the board. There is a key difference there that should not be oversimplified.
In almost any context, there is room for appreciable value in both the high-tech approach as well as the raw, "old school" approach(es). It's great that C is reviving old approaches. There's been a general retro lean lately, but still plenty of room.
The more I spend time watching older films, the more I'm saddened by the eventuality that I am going to exhaust the cache of (decent) films that do certain things which are unlikely to be repeated in quite the same way (e.g. Lean's epics). So, things like this are a welcome sight, even if they rarely have the same feel when produced now as they did 30-100 years ago (which is also okay, because they have their own, unique feel instead; something new to bring to the table).
Burn-down charts are supposed to measure time remaining, not time spent working. They are most useful for avoiding situations where you suddenly realize that the project is behind schedule, at least short term. They are also intended for the team as a whole, not individuals (emphasis on the team is one of the core principles of Agile).
If you're tracking time worked as part of scrum, you're (probably) doing it wrong.
In a situation where things are simple enough to be handled ad hoc practically, that's fine and preferred, but some situations are too complex where you don't necessarily want your developers spending their time trying to sort through politics to figure out what they need to implement.
It seems to me that translation is one of, if not the main role of management:
(not an exhaustive list) * Translate requirements from users to developers * Translate developer feedback to users * Translate developer needs to reasonable budgetary possibilities * Translate across departments * Translate developers to each other (avoid and resolve internal communication problems)
Communication breakdown is oft cited as one of the main reasons for failure. By facilitating effective communication, you add a strong layer of protection against failure.
Do this well and leave it the developers to translate the requirements to working solutions.
You should never have to use extern unless you are trying to interoperate with some external library.
Regarding strings, you're right, UTF support was tricky (although if you don't know std::string is just a typedef of std::basic_string, so abstraction IS there, to a degree). C++0x improves the situation considerably (quoting wikipedia):
There are three Unicode encodings that C++0x will support: UTF-8, UTF-16, and UTF-32. In addition to the previously noted changes to the definition of char, C++0x will add two new character types: char16_t and char32_t. These are designed to store UTF-16 and UTF-32 respectively."
It also adds both UTF string literal syntax and user-defined literals.
Regarding XML, I don't think it belongs in a "standard" library. Yes, it's common. It wasn't very common when the current C++ standard was introduced. But, it's a specific file format, not a general language/math/software feature. It might be "convenient", but there's something to be said for simplicity and keeping the standard library slim. It doesn't belong in the standard library any more than an image parsing library does. There are also many ways to write an XML parser, depending on what you are trying to optimize for (performance? memory? convenience?) That's pretty hard to "standardize".
Similar things can be said regarding GUIs. They are inherently platform specific and thus fall outside the domain of a general purpose, relatively low level compiled language like C++, in my opinion. This is even more so something that everyone has wildly differing opinions on how to implement. There is no "correct" solution. There are GUI libraries with immense amount of work put into them, many of them for C++ and cross platform (e.g. Qt) and they change rapidly due to changing requirements. For all these reasons it makes sense to keep such a thing separate from the language.
C++ is not supposed to be a convenient language. It's supposed to be a powerful, efficient language first and foremost. Convenience is nice, but when it interferes with the main goals, it takes a back seat in C++. This isn't necessarily a bad thing, it just depends on what your use case is. Do you want power, or convenience? (This is not to say that you can't write convenient constructs and libraries in C++, and C++0x makes that quite a bit easier still).
Those are all fairly common concerns about C++, but primarily ones made by inexperienced C++ users.
The complex syntax (particularly templates and the preprocessor) indeed presents a problem for writing helpful IDEs both in terms of autocomplete/refactoring and useful error reporting.
There is a plugin for MSVC called Visual Assist X that does a much better job than (at least 2008's) Intellisense. It's not free but myself and people I work with find it indispensable. It handles almost everything very well except for particularly crazy preprocessed constructs.
Header inclusion is really a very simple affair - all the #include directive does is paste the contents of the file in place. Everything else falls out of that. Forward declarations may seem archaic, but they allow you to be explicit about depending on skeletal declarations rather than full definitions (although this can admittedly get kludgy in some circumstances, e.g. typedefs), and they allow you to have a sort of cheat sheet of declarations that is separate from the implementation.
I'm not sure what you mean by the direction of declarations. As long as you avoid unnecessarily cyclic dependencies (which should be easy if you keep definitions out of your headers), you should be fine. I'm also not sure what you mean about the difference between classes and functions in "modules". Both classes and functions can be "forward declared". Nothing needs to depend on the definition of a function, but you need to see the definition of a class if you want to do anything more with it than hold/pass pointers/references of its type. Declarations can be repeated as long as they are the same. Definitions can not be. (and neither can typedefs, which is indeed irritating, but the new standard does improve on typedefs in various ways).
Java is built for virtual machines. By definition, I don't think it's possible to write a different sort of compiler that improves on the performance situation of a VM very much. If you were to attempt something like this, you'd be at best creating a subset of Java which essentially would be a restricted subset of C++ anyway, I think.
I really hate that attitude regarding C++. Yes, C++ has a learning curve. C++ isn't necessarily the best solution to a given problem. But if you know how to use it, you will be very productive.
Also from what I've seen, C++ can do just about anything that any other language can do, and more, in some fashion. To me, this makes C++ the best (but not only!) tool for most projects where I am not burdened by naysayers who refuse to learn a "difficult" language.
You mentioned scripting languages. Scripting languages are great for a variety of uses, but they terrible for others. They don't scale. They don't have much or any compile-time safety. They are typically slow.
If an API is written in a way where the user has to be "very careful", then it isn't written very well. There might also be performance reasons but I've found that you are rarely absolutely required to sacrifice safety, readability, etc, to attain substantial performance gains if you truly know what you are doing.
C++ is one of the more "safe" languages available if you use it properly. It's compile time safety features trump all other popular languages in my opinion (runtime safety is another story).
Slashdot Mirror
A tautology is a tautology.
++
i
;
whitespace is whitespace
Or if you prefer a variant with the same number of characters per line:
+\
+\
i;
I type 130wpm using only 6/10 of my fingers.
I sometimes use different fingers for the same key - entirely subconsciously. I find it fascinating how my brain automatically computes the movements needed based on the word I'm about to type. That's the catch, though - I actually need to know ahead of time what I'm about to type, so I'm not nearly as good at copying material as I am at typing put my thoughts.
"Touch typing" is hardly the only "correct" way of typing.
I had one of these where the keyboard involved was wireless. The keyboard was haphazardly stored in a stack of junk near the computer (after the user installed a new keyboard, apparently), with the receiver still plugged in, and then books were placed on top of it.
Seeing the situation after responding to the complaint about the beeping, I immediately knew what the problem was, but it took me some time to actually find the keyboard.
The game Sleep Is Death (Geisterfahrer) sounds exactly like what you're describing: "a storytelling game for two players by Jason Rohrer"
http://sleepisdeath.net/
However, you do need to be very creative to play this effectively.
Even in C++98, it is possible to write a local function equivalent like this:
void foo() {
struct { void operator()() {
printf("I'm local, yo!");
}} localFunction;
localFunction();
}
However, the anonymous struct cannot be used as a template argument, severely limiting the usefulness of this construct.
Although I don't think it qualifies as best of 2012, since it's updated just once in 2012, it's still very good. I also didn't know it updated, since it hasn't in years. Thanks for the heads up!
The art is done by the artist (David Hellman) who did the art for Braid (which was right after the comic stopped updating).
On the château?
Please put your accent back on, Mr. Exposé...
and now had enough cash I didn't need to work and could actually enjoy games as a player rather than as a developer.
Personally, as a player-turned-developer, I find it difficult to enjoy games past a certain point without the opportunity to participate in their creation.
There is a Wikipedia article about this issue:
http://en.wikipedia.org/wiki/Scunthorpe_problem
"The problem was named after an incident in 1996 in which AOL's dirty-word filter prevented residents of the town of Scunthorpe, North Lincolnshire, England from creating accounts with AOL, because the town's name contains the substring cunt.[1] Years later, Google's filters apparently made the same mistake, preventing residents from searching for local businesses that included Scunthorpe in their names.[2]"
There is also a stub article about a specific instance of the replacement effect: http://en.wikipedia.org/wiki/Medireview
Sweet. This means I no longer have to worry about losing my thumb drive - I'd just plug myself in!
Now, where should I put the pr0n folder...
I see what you did there.
I think you've nailed it. Pity I'm out of mod points.
I know plenty of 'geeks', myself included, who hate [i]the way CGI is sometimes (ab)used[/i], but not CGI itself, not across the board. There is a key difference there that should not be oversimplified.
In almost any context, there is room for appreciable value in both the high-tech approach as well as the raw, "old school" approach(es). It's great that C is reviving old approaches. There's been a general retro lean lately, but still plenty of room.
The more I spend time watching older films, the more I'm saddened by the eventuality that I am going to exhaust the cache of (decent) films that do certain things which are unlikely to be repeated in quite the same way (e.g. Lean's epics). So, things like this are a welcome sight, even if they rarely have the same feel when produced now as they did 30-100 years ago (which is also okay, because they have their own, unique feel instead; something new to bring to the table).
Burn-down charts are supposed to measure time remaining, not time spent working. They are most useful for avoiding situations where you suddenly realize that the project is behind schedule, at least short term. They are also intended for the team as a whole, not individuals (emphasis on the team is one of the core principles of Agile).
If you're tracking time worked as part of scrum, you're (probably) doing it wrong.
I think you are referring to the Technological Singularity:
http://en.wikipedia.org/wiki/Technological_singularity
You are incredible. I don't believe you.
Secure from brute force attacks != secure. Hello, exploits!
http://www.wi-fiplanet.com/news/article.php/3784251/WPA-Vulnerability-Discovered.htm
In a situation where things are simple enough to be handled ad hoc practically, that's fine and preferred, but some situations are too complex where you don't necessarily want your developers spending their time trying to sort through politics to figure out what they need to implement.
I think the key term there is "translate".
It seems to me that translation is one of, if not the main role of management:
(not an exhaustive list)
* Translate requirements from users to developers
* Translate developer feedback to users
* Translate developer needs to reasonable budgetary possibilities
* Translate across departments
* Translate developers to each other (avoid and resolve internal communication problems)
Communication breakdown is oft cited as one of the main reasons for failure. By facilitating effective communication, you add a strong layer of protection against failure.
Do this well and leave it the developers to translate the requirements to working solutions.
You should never have to use extern unless you are trying to interoperate with some external library.
Regarding strings, you're right, UTF support was tricky (although if you don't know std::string is just a typedef of std::basic_string, so abstraction IS there, to a degree). C++0x improves the situation considerably (quoting wikipedia):
There are three Unicode encodings that C++0x will support: UTF-8, UTF-16, and UTF-32. In addition to the previously noted changes to the definition of char, C++0x will add two new character types: char16_t and char32_t. These are designed to store UTF-16 and UTF-32 respectively."
It also adds both UTF string literal syntax and user-defined literals.
Regarding XML, I don't think it belongs in a "standard" library. Yes, it's common. It wasn't very common when the current C++ standard was introduced. But, it's a specific file format, not a general language/math/software feature. It might be "convenient", but there's something to be said for simplicity and keeping the standard library slim. It doesn't belong in the standard library any more than an image parsing library does. There are also many ways to write an XML parser, depending on what you are trying to optimize for (performance? memory? convenience?) That's pretty hard to "standardize".
Similar things can be said regarding GUIs. They are inherently platform specific and thus fall outside the domain of a general purpose, relatively low level compiled language like C++, in my opinion. This is even more so something that everyone has wildly differing opinions on how to implement. There is no "correct" solution. There are GUI libraries with immense amount of work put into them, many of them for C++ and cross platform (e.g. Qt) and they change rapidly due to changing requirements. For all these reasons it makes sense to keep such a thing separate from the language.
C++ is not supposed to be a convenient language. It's supposed to be a powerful, efficient language first and foremost. Convenience is nice, but when it interferes with the main goals, it takes a back seat in C++. This isn't necessarily a bad thing, it just depends on what your use case is. Do you want power, or convenience? (This is not to say that you can't write convenient constructs and libraries in C++, and C++0x makes that quite a bit easier still).
Those are all fairly common concerns about C++, but primarily ones made by inexperienced C++ users.
The complex syntax (particularly templates and the preprocessor) indeed presents a problem for writing helpful IDEs both in terms of autocomplete/refactoring and useful error reporting.
There is a plugin for MSVC called Visual Assist X that does a much better job than (at least 2008's) Intellisense. It's not free but myself and people I work with find it indispensable. It handles almost everything very well except for particularly crazy preprocessed constructs.
Header inclusion is really a very simple affair - all the #include directive does is paste the contents of the file in place. Everything else falls out of that. Forward declarations may seem archaic, but they allow you to be explicit about depending on skeletal declarations rather than full definitions (although this can admittedly get kludgy in some circumstances, e.g. typedefs), and they allow you to have a sort of cheat sheet of declarations that is separate from the implementation.
I'm not sure what you mean by the direction of declarations. As long as you avoid unnecessarily cyclic dependencies (which should be easy if you keep definitions out of your headers), you should be fine. I'm also not sure what you mean about the difference between classes and functions in "modules". Both classes and functions can be "forward declared". Nothing needs to depend on the definition of a function, but you need to see the definition of a class if you want to do anything more with it than hold/pass pointers/references of its type. Declarations can be repeated as long as they are the same. Definitions can not be. (and neither can typedefs, which is indeed irritating, but the new standard does improve on typedefs in various ways).
Java is built for virtual machines. By definition, I don't think it's possible to write a different sort of compiler that improves on the performance situation of a VM very much. If you were to attempt something like this, you'd be at best creating a subset of Java which essentially would be a restricted subset of C++ anyway, I think.
I really hate that attitude regarding C++. Yes, C++ has a learning curve. C++ isn't necessarily the best solution to a given problem. But if you know how to use it, you will be very productive.
Also from what I've seen, C++ can do just about anything that any other language can do, and more, in some fashion. To me, this makes C++ the best (but not only!) tool for most projects where I am not burdened by naysayers who refuse to learn a "difficult" language.
You mentioned scripting languages. Scripting languages are great for a variety of uses, but they terrible for others. They don't scale. They don't have much or any compile-time safety. They are typically slow.
If an API is written in a way where the user has to be "very careful", then it isn't written very well. There might also be performance reasons but I've found that you are rarely absolutely required to sacrifice safety, readability, etc, to attain substantial performance gains if you truly know what you are doing.
C++ is one of the more "safe" languages available if you use it properly. It's compile time safety features trump all other popular languages in my opinion (runtime safety is another story).