Ah yes, the fundamental, though much too common, misunderstanding of economics and oil production. Hint: we will NEVER run out of oil. EVER.
We certainly won't run out. But you may find that filling that SUV up becomes quite expensive. I guess if that hog is important enough to you to swallow the expense, more power to you. Whether you'd give it up at $10/gallon, $20/gallon, $100/gallon or more just depends upon how stubborn (and rich) you are. A lot of people are going to have to give up their SUVs; whether you're one of them or not is sort of irrelevant.
Of course, if you don't live long enough to see those prices, you may well be correct... but the primary question of concern is, will prices of oil rise more quickly than our economy can adapt to them?
Doesn't freedom include the freedom to organize in opposition to one's employers? It seems to me that in the absence of government regulation that Libertarians advocate that unions would only grow stronger, since workers would have to be self-reliant in their negotiations for working conditions.
Hell, unions first arose and grew powerful in response to the abuses of business during the industrial revolution, a period when government regulation was much lower than it is now.
You describe this situation as an irreconcilable problem, but I don't think that's really true - the reconciliation lies in the fact that there will always be a dynamic balance of power between employers and employees. If locus of power strays too far from the center, force will be used to restore it in one way or another. People institute governments to attempt to act as a damper on the oscillations of that balance of power and thus reduce the amount of force (and human pain and suffering) that's required to restore the balance.
Either that, or the bread and circuses will just keep up until there's a bloody violent collapse.
The point of this whole democracy thing is the orderly transfer of power and incremental steps towards making things better for everyone. Since we all disagree on exactly how to do that that there will never be such a thing as an ideal candidate. Although the Dems have unarguably betrayed the left, they have done so in the process of representing some segment of our increasingly right-leaning society. I attribute that rightward drift in part to the propaganda machine of the currently empowered right, so I see any movement to the left as having at least the power to start mitigating the effects of that propaganda. Thus, even if Obama isn't an ideal candidate, I see his candidacy as a step in the right direction.
I'd love it if other parties could gain some fraction of power, but that's just not going to happen until we get rid of plurality voting. And THAT is certain never to happen under a Republican administration, while I think that with sufficient cajoling and convincing the Dems might be convinced to work toward changing the system.
You don't think that if the Democratic National Committee had even a hint of real vote fraud that they wouldn't be fomenting bloody rebellion? Are you kidding me?
You think that the Dems actually have that much of a spine?
Not everyone eats crappy food and has a sedentary lifestyle. Particularly not the sort who end up as Olympic athletes, who on average have a lot more time to train and a lot more research on how to train effectively than at any time in history.
Rock, ice, and alpine climbs are rated according to a subjective degree of difficulty, so according to your criteria climbing should not be a sport.
I prefer Barnaby Conrad's definition (often misattributed to Hemingway): "Only bullfighting, mountain climbing and auto racing are sports, the rest are merely games"
I think that it depends upon the type of strength training you're doing. Typical weight training is focused on building muscle mass and bulk rather than improving strength-to-weight ratio. Dynamic anaerobic training such as that in rock climbing or gymnastics, which require high strength-to-weight ratios, tends to build smaller but still lean and strong muscle mass.
Basically, the body adapts to the type of activity. Since ordinary weight training doesn't impose a penalty for having a low strength-to-weight ratio, the body doesn't optimize appropriately for weight loss.
It sounds like you didn't need any encouragement to get interested in programming! The question we've been asked, though, is how to get a kid interested in the first place, and I think that to do something like what you've described you have to already have a self-sustaining level of interest.
In order to do that with a child who's totally new to programming, I think that you have to really focus on the fun parts of the process itself instead of the product, and manage the child's expectations with respect to the final outcome accordingly. The process of getting something working should be as painless as possible so that the kid can focus on the pleasure of playing with the logic itself and practice thinking in terms of abstractions. They can deal with optimization when it becomes necessary, and in doing so learn the lessons of efficiency in a more personal manner. I remember well writing my first 3D game using a totally naive line-drawing based algorithm of my own creation, and realizing that I needed to learn a bit more about 3D rendering when it took minutes to change the perspective of a scene. The exploration that experience resulted in taught me a whole lot more about efficiency than I would have learned otherwise.
I think that learning what goes on behind the scenes is something that comes later, if and when they're interested. I don't disagree that fundamentals are important for people to learn, but they're only really important when you get to the point of writing software that others might want to use. When you're doing it just for your own pleasure, it's nice to be able to just play with code without worrying too much about what's going on at the lower levels.
I love Java. I use it every day. But I would never recommend it as a good beginner language.
Object Oriented programming is powerful, elegant, and introduces a huge amount of learning overhead for somebody who's just starting out. The main component of this overhead is that for a beginner, figuring out what the boundaries of objects should be and what responsibilities each class should have is a real headache. While there may be lots of tutorials out there, I'd hardly consider Swing to be a beginner-friendly toolkit - it's rife with inconsistent naming and figuring out when all the callbacks are executed can be a serious hassle even if you know what you're doing.
The key to getting kids interested in programming is for them to realize how much fun it can be. For me, creating simple games and then brainstorming and implementing tons of interesting rules variants and playtesting the games with friends was key to this enjoyment. The most fun thing about programming is that it's fundamentally a creative activity. Whatever language is chosen should make it easy to be creative, without having to get bogged down in issues of design, language internals, and deployment packaging at first. I think that the grandparent's suggestion of ActionScript is pretty good in this regard, with the exception of the deployment packaging issue.
The thing with complicated graphics is that the amount of effort required to do something eye-pleasing is pretty high. The amount of effort required to hack together a game with a simple GUI in Python is pretty minimal - even an outright beginner to programming can get something interesting working in a few days.
C++ would probably be the WORST language that one could possibly use to introduce someone to programming. Kids should learn to cut wood with a hand saw before being handed the power tools, you know?
The problem with that naming convention is that the user of the class shouldn't care about the distinction of whether a class implements an interface or extends some base class - in both cases it's an "is-a" relationship.
"is a Stuff" makes sense to me. "is an IStuff" seems like it's revealing implementation details to the caller when it really shouldn't be.
That sort of misses the parent's point, though, doesn't it? In your example, if the 'else' was accidentally deleted, the code would not only compile just fine, but because you've got a comment starting at the same place as the 'else' should be, it could easily pass a cursory visual inspection.
Count me in the braces-on-the-line-and-cuddle-else camp.
We humans aren't designed to keep our hands extended and not resting on something for any length of time, and after a while, our arms will feel like they've weighted down with lead. Then, when you quit, you feel you have arms the size of a gorilla. And then the pain sets in.
Not resting on something? My arms stretch out fully along my desktop and are entirely supported. My chair is set as low as it can go, fully reclined, with my feet on an upside-down trash can. When I use my mouse, my entire forearm is resting on the desktop and the amount of motion required to get the pointer to any part of the screen is minimal (with pointer acceleration set to the maximum.)
The problem you're describing sounds more like a symptom of trying to have "correct" posture. The low-rider approach is far more ergonomically correct.
My grandfather had me in his shop constantly from when I was four or five years old, and I was working in a supervised manner with power tools (bandsaw, table saw, grinders, etc.) by 9 or 10. By the time I was 14 I was totally independent in the shop, using an arc welder and plasma torch in addition to everything else.
It all depends upon how the kids have been introduced to the tools in question (speaking of guns, my father was hunting small game on his own by the time he was seven, living in a rural community) - if they've been familiarized with the tools over a long period and both been taught safe techniques and observed safe techniques being used by others then the risk isn't any greater to them than it would be to an adult.
What's the scope of your problem? If you're going to have to have some serious back-end business logic, I'd say that Rails (or any dynamic language) is probably the wrong choice.
These days, I'm getting really interested in lift. It's written in Scala, which gives you all the benefits of a bytecode-compiled, typesafe language while borrowing a lot of stuff from Rails. They claim a LOC equivalent to Rails for the application itself, with a 60% reduction in the amount of tests that have to be written (mostly the bits that would be required to make sure you didn't have type errors.)
Plus (and this is a biggie) you can readily use any of the MASSIVE number of Java libraries that are out there with virtually no extra effort.
The only real drawback I can see thus far is that the framework is still not fully mature, but for an internal project that shouldn't be too much of a problem.
XML tag attributes are generally horribly misused, as demonstrated by your example above. Tag attributes are supposed to contain metadata about the contents of the tag, not the data itself. Granted, a name and email address may be considered to be metadata in some cases, but I think you'd have to stretch pretty far to find them.
It seems like people generally use tag attributes for data instead of metadata because they're less verbose to type. Which, of course, is one of the reasons why XML sucks.
That raises a really interesting topic, from my point of view. Since software is always evolving, how does that interact with the copyright date on a piece of code?
If I write a GPL app this year, then make modifications to it next year, when does the copyright on the app expire? Do portions of the app, even on a line-by-line basis, come out of copyright such that they can be used in a closed-source app at respective offsets of 70 years (or whatever it is now) from the date they were written?
I've looked at the latest stable release of SVN, and still found it pretty severely wanting. I'm glad that it's got changesets now, but still think that their approach to tagging and branching is both heavy-weight and clumsy compared to Git. Also, where is the support for lightweight local development branches? Squashed merges?
Maybe it's just a matter of style, but I love the fact that with Git all repositories are equal peers - and that I can therefore do all kinds of complex stuff with the repository even when I'm offline sitting at a picnic table in the hills working, and that my team members can then get all those changes when I get back to the office and get online. SVN just doesn't support that kind of usage.
Finally, the server administration overhead for svn usually means that if you've got big projects with lots of modules, all of those modules will be stored in a common repository rather than independent repositories. This can be a maintenance nightmare - in git, the submodule functionality means that your independent modules are all in their own repositories, and you can aggregate them as needed - and it's a lot cleaner than using svn:externals.
I've flown several times a year since 9/11, koth domestically and internationally, and the only thing that's changed for me is that I have to remember to pack my pocketknife in my checked baggage. I've never had a security line take me more than 10 minutes to get through, never been harassed because of my electronics, never really had any sort of problem whatsoever. I've heard a few horror stories over the net, of course, but my personal experience has none of that.
Hmmm... somewhere in this thread there was something about not having anything to fear but fear itself?
Of course, I'm the sort who always gets to the airport two hours in advance and hence can make my way through in a leisurely fashion. Most of the time I'm checked in and at the gate within 15 minutes, with either a book out or my laptop writing code. If somebody's stressed an in a hurry, maybe that triggers some sort of predatory response in the TSA folks.
If you haven't used Git, then you don't quite understand why SVN is such a turd. I certainly didn't until I switched.
Things that are more or less impossible in SVN are trivial in Git. Forget branching and merging (which git's approach to is MUCH more sane than SVN's copy-on-write approach) -- look at git-rebase or git merge --interactive to see things that you wouldn't dream to attempt with SVN.
I only used Perforce for about three months, but sure thought it sucked during that period. It always seemed ridiculous to me that so much depended upon having a correctly configured clientspec - and that the clientspec itself wasn't under version control!
Now that I'm in a git-only shop, even SVN seems antiquated. Using SVN, my goal was to avoid repeated merges at all costs; with Git it's so trivial that I do it multiple times a day.
Slashdot Mirror
Ah yes, the fundamental, though much too common, misunderstanding of economics and oil production. Hint: we will NEVER run out of oil. EVER.
We certainly won't run out. But you may find that filling that SUV up becomes quite expensive. I guess if that hog is important enough to you to swallow the expense, more power to you. Whether you'd give it up at $10/gallon, $20/gallon, $100/gallon or more just depends upon how stubborn (and rich) you are. A lot of people are going to have to give up their SUVs; whether you're one of them or not is sort of irrelevant.
Of course, if you don't live long enough to see those prices, you may well be correct... but the primary question of concern is, will prices of oil rise more quickly than our economy can adapt to them?
Doesn't freedom include the freedom to organize in opposition to one's employers? It seems to me that in the absence of government regulation that Libertarians advocate that unions would only grow stronger, since workers would have to be self-reliant in their negotiations for working conditions.
Hell, unions first arose and grew powerful in response to the abuses of business during the industrial revolution, a period when government regulation was much lower than it is now.
You describe this situation as an irreconcilable problem, but I don't think that's really true - the reconciliation lies in the fact that there will always be a dynamic balance of power between employers and employees. If locus of power strays too far from the center, force will be used to restore it in one way or another. People institute governments to attempt to act as a damper on the oscillations of that balance of power and thus reduce the amount of force (and human pain and suffering) that's required to restore the balance.
Either that, or the bread and circuses will just keep up until there's a bloody violent collapse.
Which would still be better than the status quo.
But would it be better than measured, gradual change for the better? I think not.
Either that, or the bread and circuses will just keep up until there's a bloody violent collapse.
The point of this whole democracy thing is the orderly transfer of power and incremental steps towards making things better for everyone. Since we all disagree on exactly how to do that that there will never be such a thing as an ideal candidate. Although the Dems have unarguably betrayed the left, they have done so in the process of representing some segment of our increasingly right-leaning society. I attribute that rightward drift in part to the propaganda machine of the currently empowered right, so I see any movement to the left as having at least the power to start mitigating the effects of that propaganda. Thus, even if Obama isn't an ideal candidate, I see his candidacy as a step in the right direction.
I'd love it if other parties could gain some fraction of power, but that's just not going to happen until we get rid of plurality voting. And THAT is certain never to happen under a Republican administration, while I think that with sufficient cajoling and convincing the Dems might be convinced to work toward changing the system.
I severely doubt that these kids are sitting at a desk for 7 hours a day.
You don't think that if the Democratic National Committee had even a hint of real vote fraud that they wouldn't be fomenting bloody rebellion? Are you kidding me?
You think that the Dems actually have that much of a spine?
Not everyone eats crappy food and has a sedentary lifestyle. Particularly not the sort who end up as Olympic athletes, who on average have a lot more time to train and a lot more research on how to train effectively than at any time in history.
</obvious>
Rock, ice, and alpine climbs are rated according to a subjective degree of difficulty, so according to your criteria climbing should not be a sport.
I prefer Barnaby Conrad's definition (often misattributed to Hemingway): "Only bullfighting, mountain climbing and auto racing are sports, the rest are merely games"
I think that it depends upon the type of strength training you're doing. Typical weight training is focused on building muscle mass and bulk rather than improving strength-to-weight ratio. Dynamic anaerobic training such as that in rock climbing or gymnastics, which require high strength-to-weight ratios, tends to build smaller but still lean and strong muscle mass.
Basically, the body adapts to the type of activity. Since ordinary weight training doesn't impose a penalty for having a low strength-to-weight ratio, the body doesn't optimize appropriately for weight loss.
It sounds like you didn't need any encouragement to get interested in programming! The question we've been asked, though, is how to get a kid interested in the first place, and I think that to do something like what you've described you have to already have a self-sustaining level of interest.
In order to do that with a child who's totally new to programming, I think that you have to really focus on the fun parts of the process itself instead of the product, and manage the child's expectations with respect to the final outcome accordingly. The process of getting something working should be as painless as possible so that the kid can focus on the pleasure of playing with the logic itself and practice thinking in terms of abstractions. They can deal with optimization when it becomes necessary, and in doing so learn the lessons of efficiency in a more personal manner. I remember well writing my first 3D game using a totally naive line-drawing based algorithm of my own creation, and realizing that I needed to learn a bit more about 3D rendering when it took minutes to change the perspective of a scene. The exploration that experience resulted in taught me a whole lot more about efficiency than I would have learned otherwise.
I think that learning what goes on behind the scenes is something that comes later, if and when they're interested. I don't disagree that fundamentals are important for people to learn, but they're only really important when you get to the point of writing software that others might want to use. When you're doing it just for your own pleasure, it's nice to be able to just play with code without worrying too much about what's going on at the lower levels.
I love Java. I use it every day. But I would never recommend it as a good beginner language.
Object Oriented programming is powerful, elegant, and introduces a huge amount of learning overhead for somebody who's just starting out. The main component of this overhead is that for a beginner, figuring out what the boundaries of objects should be and what responsibilities each class should have is a real headache. While there may be lots of tutorials out there, I'd hardly consider Swing to be a beginner-friendly toolkit - it's rife with inconsistent naming and figuring out when all the callbacks are executed can be a serious hassle even if you know what you're doing.
Starting on OpenGL? That sounds painful.
The key to getting kids interested in programming is for them to realize how much fun it can be. For me, creating simple games and then brainstorming and implementing tons of interesting rules variants and playtesting the games with friends was key to this enjoyment. The most fun thing about programming is that it's fundamentally a creative activity. Whatever language is chosen should make it easy to be creative, without having to get bogged down in issues of design, language internals, and deployment packaging at first. I think that the grandparent's suggestion of ActionScript is pretty good in this regard, with the exception of the deployment packaging issue.
The thing with complicated graphics is that the amount of effort required to do something eye-pleasing is pretty high. The amount of effort required to hack together a game with a simple GUI in Python is pretty minimal - even an outright beginner to programming can get something interesting working in a few days.
C++ would probably be the WORST language that one could possibly use to introduce someone to programming. Kids should learn to cut wood with a hand saw before being handed the power tools, you know?
The problem with that naming convention is that the user of the class shouldn't care about the distinction of whether a class implements an interface or extends some base class - in both cases it's an "is-a" relationship.
"is a Stuff" makes sense to me. "is an IStuff" seems like it's revealing implementation details to the caller when it really shouldn't be.
That sort of misses the parent's point, though, doesn't it? In your example, if the 'else' was accidentally deleted, the code would not only compile just fine, but because you've got a comment starting at the same place as the 'else' should be, it could easily pass a cursory visual inspection.
Count me in the braces-on-the-line-and-cuddle-else camp.
Ummm... I sort of see proper indentation as the solution to this problem, not wasted lines on the page.
We humans aren't designed to keep our hands extended and not resting on something for any length of time, and after a while, our arms will feel like they've weighted down with lead. Then, when you quit, you feel you have arms the size of a gorilla. And then the pain sets in.
Not resting on something? My arms stretch out fully along my desktop and are entirely supported. My chair is set as low as it can go, fully reclined, with my feet on an upside-down trash can. When I use my mouse, my entire forearm is resting on the desktop and the amount of motion required to get the pointer to any part of the screen is minimal (with pointer acceleration set to the maximum.)
The problem you're describing sounds more like a symptom of trying to have "correct" posture. The low-rider approach is far more ergonomically correct.
Kids of what age?
My grandfather had me in his shop constantly from when I was four or five years old, and I was working in a supervised manner with power tools (bandsaw, table saw, grinders, etc.) by 9 or 10. By the time I was 14 I was totally independent in the shop, using an arc welder and plasma torch in addition to everything else.
It all depends upon how the kids have been introduced to the tools in question (speaking of guns, my father was hunting small game on his own by the time he was seven, living in a rural community) - if they've been familiarized with the tools over a long period and both been taught safe techniques and observed safe techniques being used by others then the risk isn't any greater to them than it would be to an adult.
It was all downhill after Oingo Boingo broke up. Oh, well. At least the band knew that they were going out on a high note!
What's the scope of your problem? If you're going to have to have some serious back-end business logic, I'd say that Rails (or any dynamic language) is probably the wrong choice.
These days, I'm getting really interested in lift. It's written in Scala, which gives you all the benefits of a bytecode-compiled, typesafe language while borrowing a lot of stuff from Rails. They claim a LOC equivalent to Rails for the application itself, with a 60% reduction in the amount of tests that have to be written (mostly the bits that would be required to make sure you didn't have type errors.)
Plus (and this is a biggie) you can readily use any of the MASSIVE number of Java libraries that are out there with virtually no extra effort.
The only real drawback I can see thus far is that the framework is still not fully mature, but for an internal project that shouldn't be too much of a problem.
XML tag attributes are generally horribly misused, as demonstrated by your example above. Tag attributes are supposed to contain metadata about the contents of the tag, not the data itself. Granted, a name and email address may be considered to be metadata in some cases, but I think you'd have to stretch pretty far to find them.
It seems like people generally use tag attributes for data instead of metadata because they're less verbose to type. Which, of course, is one of the reasons why XML sucks.
That raises a really interesting topic, from my point of view. Since software is always evolving, how does that interact with the copyright date on a piece of code?
If I write a GPL app this year, then make modifications to it next year, when does the copyright on the app expire? Do portions of the app, even on a line-by-line basis, come out of copyright such that they can be used in a closed-source app at respective offsets of 70 years (or whatever it is now) from the date they were written?
I've looked at the latest stable release of SVN, and still found it pretty severely wanting. I'm glad that it's got changesets now, but still think that their approach to tagging and branching is both heavy-weight and clumsy compared to Git. Also, where is the support for lightweight local development branches? Squashed merges?
Maybe it's just a matter of style, but I love the fact that with Git all repositories are equal peers - and that I can therefore do all kinds of complex stuff with the repository even when I'm offline sitting at a picnic table in the hills working, and that my team members can then get all those changes when I get back to the office and get online. SVN just doesn't support that kind of usage.
Finally, the server administration overhead for svn usually means that if you've got big projects with lots of modules, all of those modules will be stored in a common repository rather than independent repositories. This can be a maintenance nightmare - in git, the submodule functionality means that your independent modules are all in their own repositories, and you can aggregate them as needed - and it's a lot cleaner than using svn:externals.
So, you avoid flying solely based on hearsay?
I've flown several times a year since 9/11, koth domestically and internationally, and the only thing that's changed for me is that I have to remember to pack my pocketknife in my checked baggage. I've never had a security line take me more than 10 minutes to get through, never been harassed because of my electronics, never really had any sort of problem whatsoever. I've heard a few horror stories over the net, of course, but my personal experience has none of that.
Hmmm... somewhere in this thread there was something about not having anything to fear but fear itself?
Of course, I'm the sort who always gets to the airport two hours in advance and hence can make my way through in a leisurely fashion. Most of the time I'm checked in and at the gate within 15 minutes, with either a book out or my laptop writing code. If somebody's stressed an in a hurry, maybe that triggers some sort of predatory response in the TSA folks.
If you haven't used Git, then you don't quite understand why SVN is such a turd. I certainly didn't until I switched.
Things that are more or less impossible in SVN are trivial in Git. Forget branching and merging (which git's approach to is MUCH more sane than SVN's copy-on-write approach) -- look at git-rebase or git merge --interactive to see things that you wouldn't dream to attempt with SVN.
Merging is *easier* in SVN than in Perforce?
I only used Perforce for about three months, but sure thought it sucked during that period. It always seemed ridiculous to me that so much depended upon having a correctly configured clientspec - and that the clientspec itself wasn't under version control!
Now that I'm in a git-only shop, even SVN seems antiquated. Using SVN, my goal was to avoid repeated merges at all costs; with Git it's so trivial that I do it multiple times a day.