Because graphics cost a lot of money, and effort there would be better off on gameplay or the next title. or on a cheaper game-I'd rather have it coat half as much and have snes era graphics.
Add for realism- for some games, it's good. For most, out actively detracts from fun gameplay. Concentrate on it only if it's a key concept, otherwise ignore it
It would work horribly. The algorithms don't work well on straight lines-hence the put pot pit out problems. Dvorak would have way too many straight lines for good recognition.
But it really isn't that there wouldn't be a few who tried it. It's that the number would be negligible, and none of them would want to pay for it. Not enough to base a business off of.
I worked on one of those keyboards you probably used for about 2 years (Swype). To quote my CEO when asked about some new competitor who bought some talk in the Android press- "non-qwerty non-starty". Nobody is even going to try a non-qwerty keyboard. Even most techies won't.
Start where you can win, then when people see the world didn't end, hetero marriage didn't get destroyed, and things work pretty smoothly it'll be easier in the next place. Same reason why in the US supporters started in deep blue states and not in Texas or Utah.
I don't think I am. Take a survey of average C++ programmers who don't work directly with you on that type of code. See how many of them know they can do that. I actually think 5% is an overestimate. And if that small a percentage actually know about and use a feature, I question how much that feature is worth. Especially when it at best offers a miniscule speed boost over just passing in the number as a parameter.
Sorry, my mind was slipping. I meant functors, not constructors. Functors are implemented by overriding the constructor of a class to preform an odd type of initialization and then overriding the operator () to do computation. It's an ugly, difficult to understand hack. It completely destroys the idea of what a class is, and for those of us who use type as the center of understnading how code works, it completely fucks us over by throwing dozens of non-types. It's also the basis for how all of the STL algorithms code works. It should never have existed to begin with, and it should die a horrible death.
Can't say I've ever wanted to perform a set difference. But if I did, there's be a method difference in the class Set, and it would take the second set as a parameter and spit out the result.
Same with a sort- the class would have a sort function. I would reluctantly not bounce using the sort function of the STL since it's so useful, but it's still not the right way of doing things. And it's much more complex than it should be, since the calling code has to worry about things like passing in comparators, when that should really be the job of the sort function.
Yes, i would have container classes, they're useful. I wouldn't have any generic algorithms, they tend not to be useful, are easy to make wrong in subtle ways, and the "smarter" you try to be with them the less readable your code is. They're also much less readable- give me a loop over all the indices in an array over an ugly foreach that gets passed a function any day of the week.
Sometimes. But let's be honest- how many times when you write const char* foo="some string" do you really want that? It's a miniscule fraction of the time. Almost all of them should be double const.
Value templates- yes, templating on the value, rather than the type. It's an extremely niche use case that causes difficult to read code and provides little in the way of benefits. I doubt even 5% of the user base knows it exists. Kill it.
Diamond inheritance- it isn't used much, but when it is it's a problem. Because you don't know when the common base class will be initialized, or which constructor will be called by what values. Make it illegal to solve those problems (or add it to the specification)
STL algorithms- sorry, totally disagree. The entire thing is a horrible hack based on using constructors to make quasi-first order functions. They were never meant to work like that. At best it's confusing, at worst it's unreadable and hard to debug. I bounce any code review I see using them. Worse, it encourages people to make more code like that, which tends to be done worse and be even more unreadable and frequently just wrong (generic programming has a lot of gotchas). I'd rather see the whole thing killed.
Structs vs class- it is pretty harmless, but we're talking bloat. It's bloat. There's no reason to have both. I wouldn't say this is something that has to be fixed, but it's silly to have the two of them.
Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.
I like C++, but I can think of a few. Lets ignore for the moment things like macros that are outdated in C++ and kept for C compatibility. We can easily get rid of:
*Value templates. *Diamond inheritance (just make it illegal) *The entire algorithms part of the STL. Nobody uses it and it makes for unreadable code (keep the container classes, of course) *Kill either structs or classes. We don 't need both, with one being syntactic sugar to change the default visibility on the other *The iostream libraries. I don't think I've ever seen code that didn't say fuck that and just use C style stdio. They're clunky.
That's off the top of my head, without going into things we could do better. And I like C++, it's my preferred language. The real argument here is even though C++ is bloated, it's far from the worst that way. Perl takes that crown, with it's 500 special variables. And the people who complain about C++'s bloat generally like Python or Ruby, which are both just as bloated as C++, without the bonus of it's simplicity.
And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.
Nope, I'm going to stick by my original statement. In 11 years of professional development, the majority of which had a GUI in some shape or form- 10% is the highest I've ever seen, the average is probably on the order of 3-5%. GUIs just aren't that hard to write and don't really do that much.
Using a 3rd party library can work as well- if your platform supports the toolkit you want to use, and supports it well. Swing last I checked was a nightmare that never worked the same on any two platforms. I'm going to assume it's been fixed, as it's been years since I've used it, but trust me, it was shit. Tk looks like shit on all platforms, it's an ugly UI. It's good for a quick one off, but you'll never see it in professional software.
Then there's the question of what OSes you target. If you ever want to target a proprietary hardware OS, all of those get thrown out. They won't work, and porting them would take more time than rewriting by orders of magnitude. Nor would an OEM selling your stuff ever want to bloat the ROM with a whole QT library. And don't forget, until about a year ago the phone market was dominated by proprietary OSes, until Android came.
Then there are the smartphone OSes- Android, iOS. They don't support any of those. So once again, you're back to not using them.
And in the end, that's why you don't use them- because they aren't truly universal. Because you can't count on them being available on the next port. And the tiny cost to encapsulate the small amount of functionality you actually need is well spent to have the flexibility to say yes when an opportunity to port to a device for a few million comes up.
Now if you're only porting to Windows, Mac, and Linux you're probably good with one of those libraries. Which are all those 3 run on.
If 50% of your modules have GUI calls, you're developing your software wrong. MVC isn't just for webpages. If you have UI specific code in your business logic, you fail.
If the GUI code is more than a tiny fraction of your overall code, you're working on absolutely trivial software. I can't say I've ever worked on a GUI app where the GUI itself was more than 5-10% of the code.
Basically, there's two ways of writing cross-platform apps:
1)Write your main business logic as a library. Then for each platform, write code that runs the UI and calls it as appropriate
Pros: Can take advantage of all the features of the OS, and make a customized experience for it. Easy to fit in with design standards for the OS. Minimizes bugs due to differences in APIs and capabilities between platforms.
Cons: May not be possible to write the buisness logic in this way, or may not be easy. May require ugliness in the business logic to do so. May be hard to maintain the line of abstraction between the two halves, depending on how the platform is implemented.
2)Abstract away the UI and OS specific calls into a library, and implement them for each OS.
Pros: Easy to do, with a little bit of discipline. It's always possible to do it this way, and *if* you can implement each API call so they act identically on all platforms then maintenance is a breeze and no ugliness in the business logic.
Cons: Subtle differences between how platforms handle common APIs can cause bugs. Differences between how they handle less common APIs can cause major issues. Cannot take advantage of advanced OS specific features, may not be able to follow UI standards for each platform. You'll end up with features not working on some platforms if they don't provide a needed API.
It's probably about a 50/50 split between the two paths (and I won't suggest a path, it really depends on your code and target platforms). But this is how it's done. And in either case, in fact in ALL well designed software the GUI is far separated from the business code.
Simple- don't bother. Negligible userbase, and it's making it difficult to port to? Not worth the investment.
Also, that list is incomplete- it also works for every custom embedded OS out there, which can make a real difference if you can talk an OEM into buying your software. Basically the only OSes it won't work for is Chrome (dead) and Windows Phone 7 (insignificant, and likely to remain so).
And allows code sharing. The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to. Pretty much all cross platform phone apps are C++ backends with a thin GUI layer in whatever that platform is pushing.
C runs on way too many devices without floating point support to add those as standard libraries. It wouldn't be useful on many platforms.
And C isn't about adding every feature in the world. The language itself is pretty much done. They're just changing libraries. They'll never add a major feature like closures, nor should they. If you want them, use another language when they're designed in well, not hacked on.
You have a fucked up definition of chump change. Chump change is so little you wouldn't notice the loss. The vast, vast, vast majority of people will always notice 50K. Even if you have a couple million in the bank, 50K isn't chump change, it's a huge portion of your yearly income.
We do. That was the order I put down. VP, then Speaker, then President of the Senate, then the 15 cabinet heads in a special order. I forget the exact order, but the Secretary of State is first. That gives you 18 people to take over before there's any question, plus the bureaucracy and military chain of command will still be around to give orders to various departments. How many people in exact order do you need?
We have a ridiculously long line of succession that we shouldn't be worried.
President VP Speaker of the House President Pro Tem of the Senate 15 cabinet secretaries, starting with the Secretary of State
Really, you just need to protect the top 3-4, unless there's a particular threat to another one (Clinton as SoS gets special protection as a former first lady, for example). It would be nearly impossible to knock out the first 20. And if they did, the House would immediately elect a new Speaker, who would be elevated to president by being speaker. So really after that you get all the ranking members of the majority party. It's not worth worrying about.
Depends on how you do it. I'm on summer vacation right now. My startup got bought, I turned down the full time offer and negotiated a 3.5 moth bonus for staying 6 months to help transition, and I'm spending that bonus by traveling Europe. It's pretty damn carefree.
Bullshit. Unemployment benefits are a fraction of what you made last, not a multiple. It's enough to live off of, but not at the lifestyle you previously had. The number of people who would happily take that decrease in life style is miniscule.
It's the ease with which it's done, and the fact that physical security is no longer enough. If the card isn't NFC capable, you have to physically hand the card to someone. With an NFC reader, bumping up against them in a crowded club/street may be enough. I can protect against handing my card to people who don't have a legit reason for it, and I can prevent it leaving my sight when not at home. I'm not capable of preventing anyone who wants to from brushing against me. So yes, this is a big deal.
I received a new credit card about two year ago, my old one expired. 3 months ago, a website denied my card. After a few double checks, I found out the problem. The new card had the same number, but a different code. The code I had entered was th one from the old card, 2 years old. Every single place until then I had tried it at had accepted the old code, for two years.
Oh, and many places, including most pay by phones and about 1/3-1/2 of websites I go to don't ask for it. So not only do you not need it to bilk someone, but you don't even need the right one most of the time. I'm not even convinced that a random 3 digits wouldn't work for most of them if a 2 year old code did.
Cheap? If I want to cook a steak, it costs me more to buy the raw steak and sides than to just go out and buy one at a restaurant. This is especially true if you're cooking for yourself. Your options there are to eat the same meal for a week straight (bleh, boring), freeze leftovers after cooking (which never tastes good after), or only make things that have no spoiling ingredients (so no milk, cream, etc). Oh and you're going to throw out half your excess ingredients, because grocery stores don't really sell in individual serving sizes for most things. Meals I cook are generally the same or slightly more expensive than going out to get the same meal, with the exception of nights I just decide on a bowl of cereal.
I actually kind of like that. It also enables you to have 3 or 4 cases that all need different minor initializations (say they all want to initialize a starting condition to different values) to then jump to a common case, which was actually a frequent pattern in assembly programming that's unfortunately difficult in modern languages.
Program in Java? Everywhere you see interfaces, that's multiple inheritance, they just restricted you to only inherit from the interface, not the implementation. Which means every class that implements it has to rewrite that code. Depending on the interface and the class, that may or may not be a good idea. But I'll frequently find myself writing very similar code for multiple classes that implement the same interface.
What they really needed to do was just block diamond inheritance- inheriting from two classes with the same base class. Of course since in Java everything derives from Object, that would be impossible unless you allow that as an exception.
Slashdot Mirror
Because graphics cost a lot of money, and effort there would be better off on gameplay or the next title. or on a cheaper game-I'd rather have it coat half as much and have snes era graphics.
Add for realism- for some games, it's good. For most, out actively detracts from fun gameplay. Concentrate on it only if it's a key concept, otherwise ignore it
It would work horribly. The algorithms don't work well on straight lines-hence the put pot pit out problems. Dvorak would have way too many straight lines for good recognition.
But it really isn't that there wouldn't be a few who tried it. It's that the number would be negligible, and none of them would want to pay for it. Not enough to base a business off of.
I worked on one of those keyboards you probably used for about 2 years (Swype). To quote my CEO when asked about some new competitor who bought some talk in the Android press- "non-qwerty non-starty". Nobody is even going to try a non-qwerty keyboard. Even most techies won't.
Start where you can win, then when people see the world didn't end, hetero marriage didn't get destroyed, and things work pretty smoothly it'll be easier in the next place. Same reason why in the US supporters started in deep blue states and not in Texas or Utah.
I don't think I am. Take a survey of average C++ programmers who don't work directly with you on that type of code. See how many of them know they can do that. I actually think 5% is an overestimate. And if that small a percentage actually know about and use a feature, I question how much that feature is worth. Especially when it at best offers a miniscule speed boost over just passing in the number as a parameter.
Sorry, my mind was slipping. I meant functors, not constructors. Functors are implemented by overriding the constructor of a class to preform an odd type of initialization and then overriding the operator () to do computation. It's an ugly, difficult to understand hack. It completely destroys the idea of what a class is, and for those of us who use type as the center of understnading how code works, it completely fucks us over by throwing dozens of non-types. It's also the basis for how all of the STL algorithms code works. It should never have existed to begin with, and it should die a horrible death.
Can't say I've ever wanted to perform a set difference. But if I did, there's be a method difference in the class Set, and it would take the second set as a parameter and spit out the result.
Same with a sort- the class would have a sort function. I would reluctantly not bounce using the sort function of the STL since it's so useful, but it's still not the right way of doing things. And it's much more complex than it should be, since the calling code has to worry about things like passing in comparators, when that should really be the job of the sort function.
Yes, i would have container classes, they're useful. I wouldn't have any generic algorithms, they tend not to be useful, are easy to make wrong in subtle ways, and the "smarter" you try to be with them the less readable your code is. They're also much less readable- give me a loop over all the indices in an array over an ugly foreach that gets passed a function any day of the week.
Sometimes. But let's be honest- how many times when you write const char* foo="some string" do you really want that? It's a miniscule fraction of the time. Almost all of them should be double const.
Value templates- yes, templating on the value, rather than the type. It's an extremely niche use case that causes difficult to read code and provides little in the way of benefits. I doubt even 5% of the user base knows it exists. Kill it.
Diamond inheritance- it isn't used much, but when it is it's a problem. Because you don't know when the common base class will be initialized, or which constructor will be called by what values. Make it illegal to solve those problems (or add it to the specification)
STL algorithms- sorry, totally disagree. The entire thing is a horrible hack based on using constructors to make quasi-first order functions. They were never meant to work like that. At best it's confusing, at worst it's unreadable and hard to debug. I bounce any code review I see using them. Worse, it encourages people to make more code like that, which tends to be done worse and be even more unreadable and frequently just wrong (generic programming has a lot of gotchas). I'd rather see the whole thing killed.
Structs vs class- it is pretty harmless, but we're talking bloat. It's bloat. There's no reason to have both. I wouldn't say this is something that has to be fixed, but it's silly to have the two of them.
Yup, I stand by my original opinion- all of these could be cut with no real loss to the language. Then again, if I were writing my own language I'd take C, add constructors, destructors, and C++ style syntax for member functions, add container classes, and call it perfect.
I like C++, but I can think of a few. Lets ignore for the moment things like macros that are outdated in C++ and kept for C compatibility. We can easily get rid of:
*Value templates.
*Diamond inheritance (just make it illegal)
*The entire algorithms part of the STL. Nobody uses it and it makes for unreadable code (keep the container classes, of course)
*Kill either structs or classes. We don 't need both, with one being syntactic sugar to change the default visibility on the other
*The iostream libraries. I don't think I've ever seen code that didn't say fuck that and just use C style stdio. They're clunky.
That's off the top of my head, without going into things we could do better. And I like C++, it's my preferred language. The real argument here is even though C++ is bloated, it's far from the worst that way. Perl takes that crown, with it's 500 special variables. And the people who complain about C++'s bloat generally like Python or Ruby, which are both just as bloated as C++, without the bonus of it's simplicity.
And the funny thing is that most people who write const char* foo really want char const * const foo. You don't want either the pointer or the data pointed at to change. However, almost nobody knows that, so even those who do just use the weaker const char* so people understand the code.
Designing a GUI is hard to get right. The code to implement it tends to be trivial, and almost all handled by the OS.
Nope, I'm going to stick by my original statement. In 11 years of professional development, the majority of which had a GUI in some shape or form- 10% is the highest I've ever seen, the average is probably on the order of 3-5%. GUIs just aren't that hard to write and don't really do that much.
Using a 3rd party library can work as well- if your platform supports the toolkit you want to use, and supports it well. Swing last I checked was a nightmare that never worked the same on any two platforms. I'm going to assume it's been fixed, as it's been years since I've used it, but trust me, it was shit. Tk looks like shit on all platforms, it's an ugly UI. It's good for a quick one off, but you'll never see it in professional software.
Then there's the question of what OSes you target. If you ever want to target a proprietary hardware OS, all of those get thrown out. They won't work, and porting them would take more time than rewriting by orders of magnitude. Nor would an OEM selling your stuff ever want to bloat the ROM with a whole QT library. And don't forget, until about a year ago the phone market was dominated by proprietary OSes, until Android came.
Then there are the smartphone OSes- Android, iOS. They don't support any of those. So once again, you're back to not using them.
And in the end, that's why you don't use them- because they aren't truly universal. Because you can't count on them being available on the next port. And the tiny cost to encapsulate the small amount of functionality you actually need is well spent to have the flexibility to say yes when an opportunity to port to a device for a few million comes up.
Now if you're only porting to Windows, Mac, and Linux you're probably good with one of those libraries. Which are all those 3 run on.
If 50% of your modules have GUI calls, you're developing your software wrong. MVC isn't just for webpages. If you have UI specific code in your business logic, you fail.
If the GUI code is more than a tiny fraction of your overall code, you're working on absolutely trivial software. I can't say I've ever worked on a GUI app where the GUI itself was more than 5-10% of the code.
Basically, there's two ways of writing cross-platform apps:
1)Write your main business logic as a library. Then for each platform, write code that runs the UI and calls it as appropriate
Pros: Can take advantage of all the features of the OS, and make a customized experience for it. Easy to fit in with design standards for the OS. Minimizes bugs due to differences in APIs and capabilities between platforms.
Cons: May not be possible to write the buisness logic in this way, or may not be easy. May require ugliness in the business logic to do so. May be hard to maintain the line of abstraction between the two halves, depending on how the platform is implemented.
2)Abstract away the UI and OS specific calls into a library, and implement them for each OS.
Pros: Easy to do, with a little bit of discipline. It's always possible to do it this way, and *if* you can implement each API call so they act identically on all platforms then maintenance is a breeze and no ugliness in the business logic.
Cons: Subtle differences between how platforms handle common APIs can cause bugs. Differences between how they handle less common APIs can cause major issues. Cannot take advantage of advanced OS specific features, may not be able to follow UI standards for each platform. You'll end up with features not working on some platforms if they don't provide a needed API.
It's probably about a 50/50 split between the two paths (and I won't suggest a path, it really depends on your code and target platforms). But this is how it's done. And in either case, in fact in ALL well designed software the GUI is far separated from the business code.
Simple- don't bother. Negligible userbase, and it's making it difficult to port to? Not worth the investment.
Also, that list is incomplete- it also works for every custom embedded OS out there, which can make a real difference if you can talk an OEM into buying your software. Basically the only OSes it won't work for is Chrome (dead) and Windows Phone 7 (insignificant, and likely to remain so).
And allows code sharing. The standard way to write a cross-platform app is to write the main logic in C++ or C (which is pretty portable), then to write the UI in whatever the platform is forcing you to. Pretty much all cross platform phone apps are C++ backends with a thin GUI layer in whatever that platform is pushing.
C runs on way too many devices without floating point support to add those as standard libraries. It wouldn't be useful on many platforms.
And C isn't about adding every feature in the world. The language itself is pretty much done. They're just changing libraries. They'll never add a major feature like closures, nor should they. If you want them, use another language when they're designed in well, not hacked on.
You have a fucked up definition of chump change. Chump change is so little you wouldn't notice the loss. The vast, vast, vast majority of people will always notice 50K. Even if you have a couple million in the bank, 50K isn't chump change, it's a huge portion of your yearly income.
We do. That was the order I put down. VP, then Speaker, then President of the Senate, then the 15 cabinet heads in a special order. I forget the exact order, but the Secretary of State is first. That gives you 18 people to take over before there's any question, plus the bureaucracy and military chain of command will still be around to give orders to various departments. How many people in exact order do you need?
We have a ridiculously long line of succession that we shouldn't be worried.
President
VP
Speaker of the House
President Pro Tem of the Senate
15 cabinet secretaries, starting with the Secretary of State
Really, you just need to protect the top 3-4, unless there's a particular threat to another one (Clinton as SoS gets special protection as a former first lady, for example). It would be nearly impossible to knock out the first 20. And if they did, the House would immediately elect a new Speaker, who would be elevated to president by being speaker. So really after that you get all the ranking members of the majority party. It's not worth worrying about.
Depends on how you do it. I'm on summer vacation right now. My startup got bought, I turned down the full time offer and negotiated a 3.5 moth bonus for staying 6 months to help transition, and I'm spending that bonus by traveling Europe. It's pretty damn carefree.
Bullshit. Unemployment benefits are a fraction of what you made last, not a multiple. It's enough to live off of, but not at the lifestyle you previously had. The number of people who would happily take that decrease in life style is miniscule.
It's the ease with which it's done, and the fact that physical security is no longer enough. If the card isn't NFC capable, you have to physically hand the card to someone. With an NFC reader, bumping up against them in a crowded club/street may be enough. I can protect against handing my card to people who don't have a legit reason for it, and I can prevent it leaving my sight when not at home. I'm not capable of preventing anyone who wants to from brushing against me. So yes, this is a big deal.
I received a new credit card about two year ago, my old one expired. 3 months ago, a website denied my card. After a few double checks, I found out the problem. The new card had the same number, but a different code. The code I had entered was th one from the old card, 2 years old. Every single place until then I had tried it at had accepted the old code, for two years.
Oh, and many places, including most pay by phones and about 1/3-1/2 of websites I go to don't ask for it. So not only do you not need it to bilk someone, but you don't even need the right one most of the time. I'm not even convinced that a random 3 digits wouldn't work for most of them if a 2 year old code did.
Cheap? If I want to cook a steak, it costs me more to buy the raw steak and sides than to just go out and buy one at a restaurant. This is especially true if you're cooking for yourself. Your options there are to eat the same meal for a week straight (bleh, boring), freeze leftovers after cooking (which never tastes good after), or only make things that have no spoiling ingredients (so no milk, cream, etc). Oh and you're going to throw out half your excess ingredients, because grocery stores don't really sell in individual serving sizes for most things. Meals I cook are generally the same or slightly more expensive than going out to get the same meal, with the exception of nights I just decide on a bowl of cereal.
I actually kind of like that. It also enables you to have 3 or 4 cases that all need different minor initializations (say they all want to initialize a starting condition to different values) to then jump to a common case, which was actually a frequent pattern in assembly programming that's unfortunately difficult in modern languages.
Program in Java? Everywhere you see interfaces, that's multiple inheritance, they just restricted you to only inherit from the interface, not the implementation. Which means every class that implements it has to rewrite that code. Depending on the interface and the class, that may or may not be a good idea. But I'll frequently find myself writing very similar code for multiple classes that implement the same interface.
What they really needed to do was just block diamond inheritance- inheriting from two classes with the same base class. Of course since in Java everything derives from Object, that would be impossible unless you allow that as an exception.