So if I say "you're cluelessly explaining", versus "you're cluelessly explaining in a MAN way", does the second add any information besides the implication that men are bad? If "mansplaining" is a pejorative term, this situation becomes simple: in the US, if someone is a bigot in public and gets caught, their company typically fires them.
I don't think you've quite gotten the definition of "mansplaining", it's men making simple, condescending explanations to women on the assumption that women are either ignorant or less intelligent. Basically she's accusing him of being a bigot and that he'd not talk like that to her if she was a man. However the world is full of armchair quarterbacks who offer advice or opinions on things they know very little about, often dismissing or belittling experts with many years of experience.
As a multi-decade game developer, I can't even count the number of times somebody has "mansplained" various aspects of game design to me. Thing is, I'm male, and everyone knows it. The world is indeed full of armchair quarterbacks, and men aren't exempt from it.
God, if only my typical armchair quarterback message was as polite as Derior's. What wonderful world that would be.
I've seen it work at large scale in exactly one place.
In order for dev/ops to work well, a lot of things have to be done correctly. Most of it is culture and design of the organizations and communications channels; social engineering in terms of how the groups are set up and their incentives. Failure to do this is generally why dev/ops fails or doesn't perform.
You don't fix this kind of problem (perverse market incentives) by adding another layer to 'correct' for the results. You fix this kind of problem by addressing the underlying incentives in some fashion.
The underlying incentive here is that there's a benefit to keeping salary information private. (Whether that benefit is merely perceived or real is irrelevant.) One obvious solution to this is to have the SEC require that all salaries and compensation data at publicly listed companies be made public, similar to how all government salary data is public. Public companies already have to run open books anyway. This just extends that a bit.
The big problem with C++ is that you literally can't master it quickly. You can learn the basics quickly; you can become decently good at it in a couple of years if you have prior programming experience. But I know a lot of professional programmers, and I can point to precisely zero of them (myself included) that have 'mastered' the language. We each know pieces of the language, and some of us cover rather wide areas, but all of us have to occasionally research how exactly various constructs work.
People are stupid, and news sites like to print the most horrible, twisted and eye grabbing thing they possibly can. In that kind of environment, it only takes a single crash due to a software glitch to get the project outlawed statewide. I'd keep the information private too, and probably pay off the guilty party anyway just to keep them quiet.
When I was growing up, my sisters would spend fully 1-3 hours a day doing makeup, hair, clothing, and other prep work to look presentable in public. Society expected this of them, or rather they felt society expected it. I spent 15-30 minutes a day on the same task.
When I was growing up, my sisters spent virtually no time at the computer, or building things, or learning about engineering. Society expected this of them, and my parents largely supported it. I spent 1-3 hours a day on these tasks.
The gender gap isn't due to lack of raw talent, or lack of ability. It's not due to the jobs not being "interesting" or "world changing". The gender gap is because women don't spend the same amount of time doing engineering that men do in their formative years, when it matters the most. We aren't going to fix the problem by trying to bring women into the picture after the damage has been done - the best we can do at that point is mitigate the issue. To really fix it, society is going to have to value engineering more highly than spending two hours on makeup and appearance.
I've looked at D before. It looks promising, and I've considered using it. The reason I don't is a bad reason, but it's the most common bad reason: legacy code.
I have two hundred and sixty four thousand lines of code in my personal project/library archive (my own code, not counting custom versions of external packages like openssl and portaudio), all in C/C++, all with a unified build system, that's been ported and debugged on serveral platforms. Every new project I start uses those core libraries and header files. When I think about switching to a new language, my biggest concerns are how new code will integrate with my existing, how the new language will make use of my existing libraries, and how to remain productive in a dual language environment. The long term gain might eventually make it worthwhile - but it might also just cost me time should the new language die out or not support a platform I need it to.
Bennett, please just shut the fuck up about your improvements to burning man. For your traffic flow 'improvement', you notably didn't provide simulations, suggested a broken alternative, and didn't even bother to fully understand the situation before jumping in with both feet. For this one, you've done something similar.
In particular, the problem when the ice line is backed up is -not- because the ice wasn't prefetched. It's because half the time they can't get it out of the trucks any faster, and half the time they can't get the customers out of the way faster. Adding prefetch to a throughput bound system does not improve performance. If you had the experience of going through the lines more than a few times, you'd have maybe picked up on that before offering your advice.
I'm not going to say that traffic isn't a problem, or that ice queues aren't stupidly long at times. But these are hard problems, and they have been thought about extensively by smarter people than you, smarter people who have more information and experience than you. You insult all of them by discounting that so blatantly.
Oh yeah, (a) is definitely true, but that's no reason to blackhole it immediately, especially if it does something good at the parsing layer. There have been plenty of instances of 'deprecated' features being used for several years with compiler switches to allow it.
It would be better if you asked along the lines of "If you could change any aspect of C++ and have it immediately adopted/supported" - you never know, his preference might be to change template syntax or something similar instead of adding something new.
- learn the minimum aspects of the language needed to navigate your specific codebase, and learn them very well - copy/paste of terrible syntax to avoid compiler failures - avoid using templates if at all possible - create strongly typed specific-use classes that export only the minimum functionality of the underlying libstdc++ classes without using templates - keep all pointer casting to well defined, central locations - all production code runs with asserts on all the time - thou shalt never use multiple inheritance. Ever.
Regarding managing inheritance and figuring out inheritance trees and which classes own what functions where, I'm still basically at a loss and I've been fighting that problem for years. The best advice I can give is try to keep your inheritance trees as shallow as possible; but for real world systems, it often doesn't make sense. I have a set of socket libraries which pretty much has to be 4-5 levels deep in spots to do what it needs to do properly, and it's disconcerting to have to look back to for example layers 1 and 3 to try to figure out what's going on.
Further, in my opinion, we should look at the most common coding conventions and consider adding pieces of them to the compiler and language specification if it makes sense to do so. Naming of functions almost certainly doesn't make sense; but requiring braces after all conditionals very well might (and may make compiler parsing of other constructs easier to handle.)
The most common coding styles almost always touch on what would be 'best practices' in the field. Adding those 'best practices' to the core language specification seems like something that should at least be considered.
This is a very good set of observations, and I also feel that C++ has become a 'niche language for insiders'. The syntax is difficult; it's remarkably easy to shoot yourself in the foot in unobvious ways; and porting can be problematic, as no two compilers compile the same code the same way. Trivial mistakes such as pointer aliasing are often compiled -silently and without error-, producing different results at different optimization levels, and -this is considered normal-. Over the years, you learn these things and you figure out which things to avoid, but for new people coming into the language, it's a huge barrier to entry.
If the goal is to really get a lot more programmers to use it, the base syntax almost certainly needs to be improved. Rather than providing some obscure syntax to do some obscure library feature, make it easy to do simple things and make the language as idiotproof as possible. Make compilers either strictly produce well defined output as per the spec, or throw an error. Do -something- to improve template syntax.
Pretty much all of the new features I've seen in the C++11 spec are niche features, things used by high-end library writers with 20 years of experience to do complicated library things. That's good, libraries are important. But libraries will not translate into users if normal users cannot use them, and libraries will not translate into users if the language itself is the bulk of the learning curve.
Further, since C++ is often called 'a better C' and is not backwards compatible with C compilers, will there be specification changes to sanitize and improve the lower level C aspects that are problematic? Examples would be strict parsing of the language without compiler dependent ambiguity, removal of duplicate constructs such as the ternary operator, requiring braces after all conditionals, strictly defining the bit width of standard types (int = 32 bits, short = 16 bits, char = 8 bits), etc.
"Are there any plans for future c++ specifications to focus on readability and debugging at the source level, as opposed to adding new features?"
As everyone well knows, maintenance and debugging are by far the most time intensive aspects of software engineering. Over the years, I and many of the others I work with have evolved various 'personal standards' in our use of C and C++; these personal standards are almost entirely to aid in debugging and readability. A few examples from the C side:
- pretend that the return type of the = operator is void, disallowing both "a=b=c" and "if (a = b)" constructs - all 'if', 'while', 'for' etc statements must be braced - certain types of simple arithmetic operations, for example a signed 16 bit integer multiplied by an unsigned 16 bit integer, may only be handled by dedicated macros to ensure proper operation. These macros must be manually tested and verified on each platform the software is ported to.
Many of these things seem trivial, but they add up. I have seen many hours lost to unbraced 'if' statements; I have seen five different compilers require five different sets of casts to ensure that a 16x16->32 bit integer multiply produces the correct results. There are many holes in the language specification which allow compilers to silently generate arbitrary code, requiring extensive debug and testing time when porting to new platforms.
Both porting and maintenance would be eased by truly looking at the lower layers and making some difficult decisions to improve parsing and deprecate dangerous or confusing constructs. Are there plans in future specifications to do this?
The problem isn't so much that new grads are missing some specific piece of technology or some specific piece of information. It's that new grads are typically missing, quite frankly, everything.
Programming and software engineering are -hard-. If you're a couple standard deviations above the average IQ, you can become barely passable in four years and reasonably good after ten. 'Reasonably good' is ideally the minimum standard that most companies would prefer to hire at, and the percentage of new grads which meet that standard is quite low.
Your best bets are two-fold: maintain one large personal/open source project for many years to demonstrate that you understand software engineering, and work on many smaller projects to gain diversity of experience. Optionally, you can pour your effort into the large project if it supports sufficiently diverse requirements. As an example, my large project was a mud server, which exposed me to everything from web server management, volunteer team building, and customer support to memory management, unix sockets, reference counting and coroutines.
In short, nothing substitutes for experience and breadth.
Stuff like this can help, but keep in mind that nutrition is, in the long run, a dead end. Even the best of nutrition and exercise will see you very lucky indeed to reach one hundred years old; for an indefinite lifespan, we will need actual repair and maintenance techniques. http://sens.org has more information on what will be necessary, and areas where research is (at the moment) particularly weak.
It's not at all that I don't care. It's that I care more about the hundred thousand people per day dying terrible deaths in pain and fear due to completely preventable and repairable biochemical failure. Taken in isolation, yeah, I'd prefer privacy - but when weighed against that level of suffering and death, it's not even a contest.
I'm actually shocked by the shortsightedness of the slashdot crowd on this one. I expected at least -some- positive responses to be moderated up. Instead, I see a lot of misconceptions and ignorance of the actual problem Page, like Aubrey Degray, is trying to address.
We have a hundred thousand people worldwide dying due to various medical problems and the diseases of old age. These medical problems and diseases are complicated. They consist of tens of thousands of interlocking subproblems, so many that we often take several thousand specific issues and lump them together to call them something like 'cancer'. Fixing these problems - all of them - isn't something that a single drug company, or a single nation is going to do.
It's going to take everybody, everywhere. And in order to fix all these things - cancers, diseases of old age, genetic problems, and more - is going to take research, time, and data. Lots of data.
Lots and lots of data.
People whine about privacy, oh no the bad guys are going to steal my information, ignoring the fact that a hundred thousand people a day die and that thier information could help. All of these medical problems are tractable, all of them are soluble, but they'd be a hell of a lot easier to solve if researchers weren't hamstrung by ridiculous information privacy restrictions.
I don't want immortality in good health just for me, I want it for everyone, and this idiotic fear of having information released is standing in the way of that. A hundred thousand people a day dead, because we fear someone might discover an abnormally BPH score, HIV, or a genetic propensity for Alzheimers. What a steaming load of shortsighted crap.
Slashdot Mirror
So if I say "you're cluelessly explaining", versus "you're cluelessly explaining in a MAN way", does the second add any information besides the implication that men are bad? If "mansplaining" is a pejorative term, this situation becomes simple: in the US, if someone is a bigot in public and gets caught, their company typically fires them.
I don't think you've quite gotten the definition of "mansplaining", it's men making simple, condescending explanations to women on the assumption that women are either ignorant or less intelligent. Basically she's accusing him of being a bigot and that he'd not talk like that to her if she was a man. However the world is full of armchair quarterbacks who offer advice or opinions on things they know very little about, often dismissing or belittling experts with many years of experience.
As a multi-decade game developer, I can't even count the number of times somebody has "mansplained" various aspects of game design to me. Thing is, I'm male, and everyone knows it. The world is indeed full of armchair quarterbacks, and men aren't exempt from it.
God, if only my typical armchair quarterback message was as polite as Derior's. What wonderful world that would be.
I've seen it work at large scale in exactly one place.
In order for dev/ops to work well, a lot of things have to be done correctly. Most of it is culture and design of the organizations and communications channels; social engineering in terms of how the groups are set up and their incentives. Failure to do this is generally why dev/ops fails or doesn't perform.
You don't fix this kind of problem (perverse market incentives) by adding another layer to 'correct' for the results. You fix this kind of problem by addressing the underlying incentives in some fashion.
The underlying incentive here is that there's a benefit to keeping salary information private. (Whether that benefit is merely perceived or real is irrelevant.) One obvious solution to this is to have the SEC require that all salaries and compensation data at publicly listed companies be made public, similar to how all government salary data is public. Public companies already have to run open books anyway. This just extends that a bit.
The big problem with C++ is that you literally can't master it quickly. You can learn the basics quickly; you can become decently good at it in a couple of years if you have prior programming experience. But I know a lot of professional programmers, and I can point to precisely zero of them (myself included) that have 'mastered' the language. We each know pieces of the language, and some of us cover rather wide areas, but all of us have to occasionally research how exactly various constructs work.
People are stupid, and news sites like to print the most horrible, twisted and eye grabbing thing they possibly can. In that kind of environment, it only takes a single crash due to a software glitch to get the project outlawed statewide. I'd keep the information private too, and probably pay off the guilty party anyway just to keep them quiet.
When I was growing up, my sisters would spend fully 1-3 hours a day doing makeup, hair, clothing, and other prep work to look presentable in public. Society expected this of them, or rather they felt society expected it. I spent 15-30 minutes a day on the same task.
When I was growing up, my sisters spent virtually no time at the computer, or building things, or learning about engineering. Society expected this of them, and my parents largely supported it. I spent 1-3 hours a day on these tasks.
The gender gap isn't due to lack of raw talent, or lack of ability. It's not due to the jobs not being "interesting" or "world changing". The gender gap is because women don't spend the same amount of time doing engineering that men do in their formative years, when it matters the most. We aren't going to fix the problem by trying to bring women into the picture after the damage has been done - the best we can do at that point is mitigate the issue. To really fix it, society is going to have to value engineering more highly than spending two hours on makeup and appearance.
Good luck with that.
I've looked at D before. It looks promising, and I've considered using it. The reason I don't is a bad reason, but it's the most common bad reason: legacy code.
I have two hundred and sixty four thousand lines of code in my personal project/library archive (my own code, not counting custom versions of external packages like openssl and portaudio), all in C/C++, all with a unified build system, that's been ported and debugged on serveral platforms. Every new project I start uses those core libraries and header files. When I think about switching to a new language, my biggest concerns are how new code will integrate with my existing, how the new language will make use of my existing libraries, and how to remain productive in a dual language environment. The long term gain might eventually make it worthwhile - but it might also just cost me time should the new language die out or not support a platform I need it to.
I simply can't justify the gamble.
Bennett, please just shut the fuck up about your improvements to burning man. For your traffic flow 'improvement', you notably didn't provide simulations, suggested a broken alternative, and didn't even bother to fully understand the situation before jumping in with both feet. For this one, you've done something similar.
In particular, the problem when the ice line is backed up is -not- because the ice wasn't prefetched. It's because half the time they can't get it out of the trucks any faster, and half the time they can't get the customers out of the way faster. Adding prefetch to a throughput bound system does not improve performance. If you had the experience of going through the lines more than a few times, you'd have maybe picked up on that before offering your advice.
I'm not going to say that traffic isn't a problem, or that ice queues aren't stupidly long at times. But these are hard problems, and they have been thought about extensively by smarter people than you, smarter people who have more information and experience than you. You insult all of them by discounting that so blatantly.
The FDA has -safety concerns- testing a drug that might be effective against a -contagious disease with a 90% fatality rate-?
Somebody's priorities are in the wrong order.
Don't be a dumbass. CCl4 isn't used in HVAC, CFC's are, and no, they aren't liquid at room temperatures.
Oh yeah, (a) is definitely true, but that's no reason to blackhole it immediately, especially if it does something good at the parsing layer. There have been plenty of instances of 'deprecated' features being used for several years with compiler switches to allow it.
It would be better if you asked along the lines of "If you could change any aspect of C++ and have it immediately adopted/supported" - you never know, his preference might be to change template syntax or something similar instead of adding something new.
Personally, I do a lot of the following:
- learn the minimum aspects of the language needed to navigate your specific codebase, and learn them very well
- copy/paste of terrible syntax to avoid compiler failures
- avoid using templates if at all possible
- create strongly typed specific-use classes that export only the minimum functionality of the underlying libstdc++ classes without using templates
- keep all pointer casting to well defined, central locations
- all production code runs with asserts on all the time
- thou shalt never use multiple inheritance. Ever.
Regarding managing inheritance and figuring out inheritance trees and which classes own what functions where, I'm still basically at a loss and I've been fighting that problem for years. The best advice I can give is try to keep your inheritance trees as shallow as possible; but for real world systems, it often doesn't make sense. I have a set of socket libraries which pretty much has to be 4-5 levels deep in spots to do what it needs to do properly, and it's disconcerting to have to look back to for example layers 1 and 3 to try to figure out what's going on.
Even when they do fully implement the entire language, the 'compiler dependent' aspects of the language allow compilers to produce arbitrary results.
No. No no no no no. No.
Just, no.
Having lived through the embedded C/C++ debacle, I can't stress 'no' hard enough.
Hopefully, not for a long time. C++ doesn't need more complexity at the moment. It needs less.
The last thing C++ needs right now is another complex feature which adds more syntax and fundamentally new operation.
Further, in my opinion, we should look at the most common coding conventions and consider adding pieces of them to the compiler and language specification if it makes sense to do so. Naming of functions almost certainly doesn't make sense; but requiring braces after all conditionals very well might (and may make compiler parsing of other constructs easier to handle.)
The most common coding styles almost always touch on what would be 'best practices' in the field. Adding those 'best practices' to the core language specification seems like something that should at least be considered.
This is a very good set of observations, and I also feel that C++ has become a 'niche language for insiders'. The syntax is difficult; it's remarkably easy to shoot yourself in the foot in unobvious ways; and porting can be problematic, as no two compilers compile the same code the same way. Trivial mistakes such as pointer aliasing are often compiled -silently and without error-, producing different results at different optimization levels, and -this is considered normal-. Over the years, you learn these things and you figure out which things to avoid, but for new people coming into the language, it's a huge barrier to entry.
If the goal is to really get a lot more programmers to use it, the base syntax almost certainly needs to be improved. Rather than providing some obscure syntax to do some obscure library feature, make it easy to do simple things and make the language as idiotproof as possible. Make compilers either strictly produce well defined output as per the spec, or throw an error. Do -something- to improve template syntax.
Pretty much all of the new features I've seen in the C++11 spec are niche features, things used by high-end library writers with 20 years of experience to do complicated library things. That's good, libraries are important. But libraries will not translate into users if normal users cannot use them, and libraries will not translate into users if the language itself is the bulk of the learning curve.
Further, since C++ is often called 'a better C' and is not backwards compatible with C compilers, will there be specification changes to sanitize and improve the lower level C aspects that are problematic? Examples would be strict parsing of the language without compiler dependent ambiguity, removal of duplicate constructs such as the ternary operator, requiring braces after all conditionals, strictly defining the bit width of standard types (int = 32 bits, short = 16 bits, char = 8 bits), etc.
"Are there any plans for future c++ specifications to focus on readability and debugging at the source level, as opposed to adding new features?"
As everyone well knows, maintenance and debugging are by far the most time intensive aspects of software engineering. Over the years, I and many of the others I work with have evolved various 'personal standards' in our use of C and C++; these personal standards are almost entirely to aid in debugging and readability. A few examples from the C side:
- pretend that the return type of the = operator is void, disallowing both "a=b=c" and "if (a = b)" constructs
- all 'if', 'while', 'for' etc statements must be braced
- certain types of simple arithmetic operations, for example a signed 16 bit integer multiplied by an unsigned 16 bit integer, may only be handled by dedicated macros to ensure proper operation. These macros must be manually tested and verified on each platform the software is ported to.
Many of these things seem trivial, but they add up. I have seen many hours lost to unbraced 'if' statements; I have seen five different compilers require five different sets of casts to ensure that a 16x16->32 bit integer multiply produces the correct results. There are many holes in the language specification which allow compilers to silently generate arbitrary code, requiring extensive debug and testing time when porting to new platforms.
Both porting and maintenance would be eased by truly looking at the lower layers and making some difficult decisions to improve parsing and deprecate dangerous or confusing constructs. Are there plans in future specifications to do this?
The problem isn't so much that new grads are missing some specific piece of technology or some specific piece of information. It's that new grads are typically missing, quite frankly, everything.
Programming and software engineering are -hard-. If you're a couple standard deviations above the average IQ, you can become barely passable in four years and reasonably good after ten. 'Reasonably good' is ideally the minimum standard that most companies would prefer to hire at, and the percentage of new grads which meet that standard is quite low.
Your best bets are two-fold: maintain one large personal/open source project for many years to demonstrate that you understand software engineering, and work on many smaller projects to gain diversity of experience. Optionally, you can pour your effort into the large project if it supports sufficiently diverse requirements. As an example, my large project was a mud server, which exposed me to everything from web server management, volunteer team building, and customer support to memory management, unix sockets, reference counting and coroutines.
In short, nothing substitutes for experience and breadth.
Stuff like this can help, but keep in mind that nutrition is, in the long run, a dead end. Even the best of nutrition and exercise will see you very lucky indeed to reach one hundred years old; for an indefinite lifespan, we will need actual repair and maintenance techniques. http://sens.org has more information on what will be necessary, and areas where research is (at the moment) particularly weak.
It's not at all that I don't care. It's that I care more about the hundred thousand people per day dying terrible deaths in pain and fear due to completely preventable and repairable biochemical failure. Taken in isolation, yeah, I'd prefer privacy - but when weighed against that level of suffering and death, it's not even a contest.
I'm actually shocked by the shortsightedness of the slashdot crowd on this one. I expected at least -some- positive responses to be moderated up. Instead, I see a lot of misconceptions and ignorance of the actual problem Page, like Aubrey Degray, is trying to address.
We have a hundred thousand people worldwide dying due to various medical problems and the diseases of old age. These medical problems and diseases are complicated. They consist of tens of thousands of interlocking subproblems, so many that we often take several thousand specific issues and lump them together to call them something like 'cancer'. Fixing these problems - all of them - isn't something that a single drug company, or a single nation is going to do.
It's going to take everybody, everywhere. And in order to fix all these things - cancers, diseases of old age, genetic problems, and more - is going to take research, time, and data. Lots of data.
Lots and lots of data.
People whine about privacy, oh no the bad guys are going to steal my information, ignoring the fact that a hundred thousand people a day die and that thier information could help. All of these medical problems are tractable, all of them are soluble, but they'd be a hell of a lot easier to solve if researchers weren't hamstrung by ridiculous information privacy restrictions.
I don't want immortality in good health just for me, I want it for everyone, and this idiotic fear of having information released is standing in the way of that. A hundred thousand people a day dead, because we fear someone might discover an abnormally BPH score, HIV, or a genetic propensity for Alzheimers. What a steaming load of shortsighted crap.