First hunger disappears and if you still force yourself to continue eating, you will start feeling nauseous and if you ignore that, at some point you start vomiting.
The cold drinks. (Many placed do not even serve hot/warm/room temperature drinks!)
According to some doctors, the cold drinks cause stomach to flush its content down the intestines. That means the food not yet fully dissolved and can't be fully digested.
IOW, shortly after a bug gulp of cold Cola, you stomach is empty and ready to accept new food.
However, some foods don't trigger that reactions fast enough [...]
I think you are on the wrong track.
Couple of fancy facts which I have picked up at different times.
1. Most fast food contains lots of carbs, because the carbs trigger the satiety reaction in the body. So that you feel sat very shortly after start of the meal.
2. Typical fast food lunch contains only about 40% of substances, required by the body to actually digest the meal. No food is perfect, but the fast food is worst.
3. (Fact from personal experience) Unlike the vegetables, the red meat takes quite a lot of time to go through the digestive tract. And lots of food this days has meat. Many do not consider meal without meat a meal.
It seems to me that many people are simply caught up in the loop. Fast food has enough calories, but our digestive system can't extract them. It goes through the digestive tract slowly (due to high meat content) and it extracts from it what it can.
After learning the things I simply started eating more salads. On one of the jobs, I even had to extend my lunch time so that I can go to the nearest place which had the salad bar. (Because the usual salads suck.)
"Up to 80 percent of users who wrote at least 5000 words across their posts could be identified using linguistic techniques. Techniques such as stylometric analysis were used to track users who posted across different forums, and could even be used to unveil authors of thesis papers or blogs who had taken to underground networks."
Not really new. I heard about the techniques long time ago - in mid 90s - in a context of a MS-DOS tool which was unintentionally designed to foil the identification methods.
It was designed for Russian and Belarussian languages (but for English I gather the task should be even easier) and was a byproduct of Prolog-based system for natural language processing and translation. This particular program was allowing to improve or change writing style, e.g. simplify dry legalese or formalize spoken-like text. It wasn't particularly good at it: meaning was occasionally changed or sometimes reformulated sentenced made no sense. But still, it did the job of obfuscating the original writing style.
That's nice, but I think you might be missing the point. The problem is not operator overloading *in your own code* the issue is integrating a lot of third party code (re-use is the best way to do software development) where each library you integrate has different conventions for the meaning of the various operators. That was the problem that they tried to avoid.
And as I have said - the problem doesn't exist anymore. Probably never really existed. Not even with 3rd party libraries. There is no problem to avoid.
Unwritten (and often written) rule of the operator overload is that operator should do what is expected in normal case of the operator: 'operator ==' compares, 'operator +' adds and so on. Over the past decade, with couple of exceptions, I haven't seen a single operator overload case deviating from the rule. And even the exceptions were generally justified and used to preserve familiar coding paradigms from other programming languages when moving to C++.
Using your "logic," pretty much any feature or utility open to even slightest abuse supposedly should be banned. But I do not see for example exceptions or interfaces being removed and banned from the Java, despite the fact that in my experience those are among the most abused and/or improperly used features of the language.
Operator overload is just a tool. The fact that some high-level languages still do not provide the widely popular tool is simply sad. And there is no need to say anything more, least excuses.
All I was saying that the general case is that the experience of the community is that operator overloading is a fertile source of errors in large systems. This knowledge led Gosling et al. to
Man, I can't read the B.S. anymore. I'm surprised you haven't plainly named Gosling et al your gods and declared yourself to be a priest of their church. Amen. (Or change your "community" - because it sucks.)
There was probably some time when operator overload was a "problem" - when it first became available in popular languages and people started experimenting. But the times are long over.
The project I work on is not even large - it is f*cking huge. 1Mln of ELOC was exceeded long time ago and nobody's counting it anymore. And it is more than 80% in C++. There is precisely zero, zelch, nada of a problems related to the operator overload. My previous C++ projects were much much smaller - and also had zero problems.
Just in case you weren't sure, OpenJDK and Oracle JDK *are the same thing* in terms of technology (apart from some tiny library differences, eg. some graphics handling). It is the licenses that differ.
Precisely. Now go back up in the comment tree and see that that was the original point: Java == Oracle.
I can only attest that there is a growing negative sentiment in industry against Oracle. Though I haven't seen it impacting Java yet.
Operator overloading seems like a good idea but it is often shitty to maintain someone else's C++ who has used it.
I have a huge pile of financial Java code using arbitrary precision numbers. My whole team would strongly disagree with your assessment. Which is based solely on the "think of the children!" rhetoric.
P.S. I haven't seen operator overload abuse for very very long time. Few bother with it today, since libraries do it already for them.
Your comment might become relevant - when I would see at least one enterprise system running OpenJDK.
Oracle/Sun Java SDK and run-time are pretty much sole alternative for the businesses, since it is pretty much only Java implementation providing commercial support.
When googling for 'openjdk commercial support' or 'java commercial support', first hit is from www.oracle.com. After filtering few pages of results, Oracle remains sole relevant hit.
I can't see a future for a platform with no apps apart from toy ones.
You should get out more often. 90% of time I see people playing some simple games on their smartphones. Remaining 10% mostly browsing, reading news.
I guess it's aimed at dumb-phones [...]
You can't imagine how hard right now it is to come by a decent dumb/feature-phone.
[...] given away free by the carriers, but a phone with no apps is going to be a hard sell.
Not many people need the apps. A phone which has weather widget and decent browser covers heck a lot of consumers.
If Sammy/Docomo also would manage to improve battery life (e.g. Samsung Wave with Bada OS can go 2-4 days on single charge) I personally would gladly trade the choice of apps for the dumbphone.
For consumers what is the benefit of another phone OS with another incompatible app store? What features does this OS have. Is it faster? Cheaper? Prettier?
Probably the same advantages as the Bada OS. In other words, very few advantages for consumers. (Though I'm hopeful that Bada's battery life would get to Tizen. 2-4 days on single charge!)
The purpose of the new OS is to ensure that the manufacturers have a bargaining chip when dealing with the OS providers, Google and Microsoft. Also they can develop it independently and integrate whatever features they want - if the Google or Microsoft are reluctant to act or demand too high pay for the customization.
The only real advantage of another mobile OS I can imagine is that we, consumers, potentially now even further from monopoly/duopoly of mobile OSs. That guarantees that we would have more choices down the road.
From Samsung and HTC sure. Buy some other brand, and they get nothing.
And I'm not even sure that they are collecting anything from the two - considering how fast the deals were made.
MSFT needs Samsung and HTC - as Windows phone producers - more than they need MSFT. It's very likely that under the deal they pay the usual Windows phone license fees, which now also magically (and mostly for PR purposes) covers the MSFT's Android claims.
[...] In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?".
Bad example.
A good sign of a non-master is attempt at concatenating string. Think of it, even Java *cannot* concatenate strings.:)
Contemporary C master wouldn't even think about it. Far cry from StringBuilder, but all the functions for safe string handling are already there - one only has to use them. (Although some thought might go into defining the limits for the buffers.)
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
A link/name for the idiom I can pass to our Java people?
Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
We allow to start several instances of the same process: if one goes down, others are still there.
However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
In all fairness, I'm not a specialist in Java. Probably your experience is more relevant than mine.
But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened.
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.
Are you CTO per chance? VP of tech? You talk like one.
But if you want it to be addressed in a programming language.
Until language developers suck it up and start making languages that allow for opposite concepts in the same language, it would remain the same.
For example.
Most stupid errors in strict typed languages are in the code for some type weakness - because, duh, strictly typed languages provide zero standard facilities to implement weak typing when you need it. So you have to roll out your own.
Most stupid errors in weak-typed languages are related to wrong intermixing of types - because, duh, weakly typed languages provide zero standard facilities to implement strict typing when you need it. So you have to roll out your own.
especially in servers where robustness is important.
Ditto for C/C++ applications "where robustness is important". Implementation looks different, but same in the essence.
Some memory debuggers and code analyzers (Insure for example) can even catch the error during compilation (IIRC so called "wild pointers" in the Insure speak).
Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
What I'm getting here to. If robustness is expected from the software, to customer, it doesn't matter how it fails - crashes or denies service - what matters is that the problem can be quickly localized and fixed. Trivial problems like missing null pointer check in C can be localized from core dump within seconds. Trivial problems like missing null pointer check in Java occasionally cause high level fsckups, thanks to the blank exception handling one often has to resort to. So from practical point of view, the languages unfortunately are very close.
At the time, this spec meant a lot—and, to be honest, I think it worked marvelously.
It didn't. It caused uproar among gamers and all games which supported lower specs (no sound, CD drive required only during installation) were standing out and played more than the rest.
IIRC the spec was literally unused, but still some claimed some success to it. But that happened only after one could buy a sound card for $30 or less and CD drive for $50 or less.
Let the powers that be come up with a new baseline specification.
Be careful what you wish for. Mass market now is a low-power laptop, mostly used for Facebook. If not a tablet. We are at the down-scaling/miniaturization/reshaping of the PC. Most devices used for gaming today do NOT have: CD drive, keyboard or mouse.
Game competition is as high as ever - especially from the adjacent markets (mobile). Game developers are unlikely to try to limit their own market.
Insisting on some minimum spec has already created its own (closed) market: game consoles.
When sex itself is deemed something that's not "pristine" something is very wrong - way beyond wrong.....
And that IMO is the cause of the trauma. Modern parenting including feeding children piles of idealistic crap (too much TV I would say), at best useless for the real life.
Does not help. And Amazon already has some sort of system in place with the "Was the review helpful? Yes/No" stats. You can also add a comment to a review.
Facts:
1. Authors (esp. writing in the same genres, living in the same area) are very often know each other and often are buddies. That might adds positive bias to their reviews. Occasionally they are also competitors - making the bias negative. (The buddying I have seen with my own eyes, where authors were recommending books of their buddy-authors without even reading them first.)
2. Authors have fans. Fans would react disproportionally to a review written by their author. They would also react disproportionally on the negative comments to the review. (I have already seen comment section of a book review with ~120 comments.)
What that means in the end, that book reviews could easily become battleground for the fans and stop being helpful to the consumers.
Decision is probably way too far reaching - but I think Amazon simply does not want to deal with the mess. Especially since they allow ebook self-publishing via "Kindle Direct Publishing," I guess they want to make sure that it runs smoothly on its own.
But I have looked it costs anyway. From what I can find, average satellite launch costs $10-20M while SpaceX launch costs around $5+M. The cost difference isn't big enough to drastically change anything:(
Otherwise, the point I was trying to make was that the satellites are so expensive in part because launches are so expensive. One attempts to pack into one expensive trip as much as possible - to make as few trips as possible. If price for launch was magnitude (or two) less, I'm pretty sure that would have made cheaper satellites possible.
I wasn't taking about manufacturing specifically - more like building/assembling the stuff using off-the-shelf parts. I was also thinking about potential expansion of the ISS. Right now it is made of older space modules, what is rather expensive building material. But probably you are right anyway.
That was just an idea, follow up on the possibilities offered by cheaper transportation to the space. Just like the accessible infrastructure down here, possibilities expand greatly.
"You can thrift on cost. You can take cost out of a rocket. But I will guarantee you, in my experience, when you start pulling a lot of costs out of a rocket, your quality and your probability of success in delivering a payload to orbit diminishes."
Fishy argument. Most of the payload I gather is pretty cheap stuff to make astronauts' life on ISS possible.
In a way, price gauging of the launchers has resulted in the reactive price gauging of the payload. But if one can cheaply transport materials to the ISS, some stuff can be actually built and assembled right there - instead of creating the stuff on surface up to the very high standards, required for it to survive the lift off.
That epic battle between commercial software and open-source only exists on RMS's head and on a handful of follower's heads. Fact is that OSS predates RMS [...]
Predates him, indeed. But you have probably forgotten that pretty much all *NIX and *BSD clones - actively developed clones - have abandoned it. Throw in here the USL v. BSDi case, and actually there was a period of time when there was no open source - except for the FSF/GNU.
pcc exists since the seventies.
Riiiight. It has, as BSD, fathered piles of *commercial* forks. Yet itself AFAIK it still can not even claim full ANSI C support - least C++ support or support of any arch except x86/x64. So how that rich history "since the seventies" played out?? Stagnation and irrelevance, because every good idea got implemented - in a commercial fork.
The point being before RMS, OSS was equivalent to BSD. What sucked for very obvious reasons. But RMS had showed that it can be improved upon with his community-centric license. And things have improved since then.
Still, early versions of GNU libc and cc in the 80s and 90s where crucial. At the time it was not only the open source model which was doubted - it was doubted whether "bunch of unemployed hippies" can write anything as sophisticated and of production quality. FSF/GNU under RMS guidance had managed it.
EGCS happened much later, in the end of the 90s. As old saying goes (I have forgotten original wording), person who have contributed something major to development eventually becomes a major impediment to development himself. RMS religious zeal was important instrument to persist through the times of total commercialization of the software. Now, after he made sure that open source exists and thrives, he himself is more of an obstacle to the future of what he had created.
As somebody who actually occasionally uses AIX, but most and foremost who does support for HA system for past 5+ years, let me just say that the uptime stability of any system is asymptotically equivalent to the minimum distance idiot admins are kept from it. Farther you keep idiots away from important system - the system which you want to have great uptime - longer the uptime gets.
Otherwise, our AIX 5.x, 6.x and 7.x boxes run pretty well over here and with great uptime (500+ days between reboots; most commonly rebooted for network/storage reconfiguration or power outlet/physical relocation). Yeah, system is out-dated, mostly sucks and is unused. But try to think of it positively, as about the "glass half-full": Thanks God It's Not HP-sUX!!!!!!!!
Slashdot Mirror
First hunger disappears and if you still force yourself to continue eating, you will start feeling nauseous and if you ignore that, at some point you start vomiting.
The cold drinks. (Many placed do not even serve hot/warm/room temperature drinks!)
According to some doctors, the cold drinks cause stomach to flush its content down the intestines. That means the food not yet fully dissolved and can't be fully digested.
IOW, shortly after a bug gulp of cold Cola, you stomach is empty and ready to accept new food.
However, some foods don't trigger that reactions fast enough [...]
I think you are on the wrong track.
Couple of fancy facts which I have picked up at different times.
1. Most fast food contains lots of carbs, because the carbs trigger the satiety reaction in the body. So that you feel sat very shortly after start of the meal.
2. Typical fast food lunch contains only about 40% of substances, required by the body to actually digest the meal. No food is perfect, but the fast food is worst.
3. (Fact from personal experience) Unlike the vegetables, the red meat takes quite a lot of time to go through the digestive tract. And lots of food this days has meat. Many do not consider meal without meat a meal.
It seems to me that many people are simply caught up in the loop. Fast food has enough calories, but our digestive system can't extract them. It goes through the digestive tract slowly (due to high meat content) and it extracts from it what it can.
After learning the things I simply started eating more salads. On one of the jobs, I even had to extend my lunch time so that I can go to the nearest place which had the salad bar. (Because the usual salads suck.)
"Up to 80 percent of users who wrote at least 5000 words across their posts could be identified using linguistic techniques. Techniques such as stylometric analysis were used to track users who posted across different forums, and could even be used to unveil authors of thesis papers or blogs who had taken to underground networks."
Not really new. I heard about the techniques long time ago - in mid 90s - in a context of a MS-DOS tool which was unintentionally designed to foil the identification methods.
It was designed for Russian and Belarussian languages (but for English I gather the task should be even easier) and was a byproduct of Prolog-based system for natural language processing and translation. This particular program was allowing to improve or change writing style, e.g. simplify dry legalese or formalize spoken-like text. It wasn't particularly good at it: meaning was occasionally changed or sometimes reformulated sentenced made no sense. But still, it did the job of obfuscating the original writing style.
That's nice, but I think you might be missing the point. The problem is not operator overloading *in your own code* the issue is integrating a lot of third party code (re-use is the best way to do software development) where each library you integrate has different conventions for the meaning of the various operators. That was the problem that they tried to avoid.
And as I have said - the problem doesn't exist anymore. Probably never really existed. Not even with 3rd party libraries. There is no problem to avoid.
Unwritten (and often written) rule of the operator overload is that operator should do what is expected in normal case of the operator: 'operator ==' compares, 'operator +' adds and so on. Over the past decade, with couple of exceptions, I haven't seen a single operator overload case deviating from the rule. And even the exceptions were generally justified and used to preserve familiar coding paradigms from other programming languages when moving to C++.
Using your "logic," pretty much any feature or utility open to even slightest abuse supposedly should be banned. But I do not see for example exceptions or interfaces being removed and banned from the Java, despite the fact that in my experience those are among the most abused and/or improperly used features of the language.
Operator overload is just a tool. The fact that some high-level languages still do not provide the widely popular tool is simply sad. And there is no need to say anything more, least excuses.
All I was saying that the general case is that the experience of the community is that operator overloading is a fertile source of errors in large systems. This knowledge led Gosling et al. to
Man, I can't read the B.S. anymore. I'm surprised you haven't plainly named Gosling et al your gods and declared yourself to be a priest of their church. Amen. (Or change your "community" - because it sucks.)
There was probably some time when operator overload was a "problem" - when it first became available in popular languages and people started experimenting. But the times are long over.
The project I work on is not even large - it is f*cking huge. 1Mln of ELOC was exceeded long time ago and nobody's counting it anymore. And it is more than 80% in C++. There is precisely zero, zelch, nada of a problems related to the operator overload. My previous C++ projects were much much smaller - and also had zero problems.
Just in case you weren't sure, OpenJDK and Oracle JDK *are the same thing* in terms of technology (apart from some tiny library differences, eg. some graphics handling). It is the licenses that differ.
Precisely. Now go back up in the comment tree and see that that was the original point: Java == Oracle.
I can only attest that there is a growing negative sentiment in industry against Oracle. Though I haven't seen it impacting Java yet.
Operator overloading seems like a good idea but it is often shitty to maintain someone else's C++ who has used it.
I have a huge pile of financial Java code using arbitrary precision numbers. My whole team would strongly disagree with your assessment. Which is based solely on the "think of the children!" rhetoric.
P.S. I haven't seen operator overload abuse for very very long time. Few bother with it today, since libraries do it already for them.
Your comment might become relevant - when I would see at least one enterprise system running OpenJDK.
Oracle/Sun Java SDK and run-time are pretty much sole alternative for the businesses, since it is pretty much only Java implementation providing commercial support.
When googling for 'openjdk commercial support' or 'java commercial support', first hit is from www.oracle.com. After filtering few pages of results, Oracle remains sole relevant hit.
do you have any idea what a marketing or sales Exec VP hears when he or she hears this ??
it translates to drop this dog as fast as possible
Don't be an idiot. N9 is popular with enthusiasts because it is Linux based and well spec'ed. I was eyeing it too.
It never became "recommended" to normal users for the simple reason that Nokia announced drop of MeeGo OS about the same time as the N9 was released.
I can't see a future for a platform with no apps apart from toy ones.
You should get out more often. 90% of time I see people playing some simple games on their smartphones. Remaining 10% mostly browsing, reading news.
I guess it's aimed at dumb-phones [...]
You can't imagine how hard right now it is to come by a decent dumb/feature-phone.
[...] given away free by the carriers, but a phone with no apps is going to be a hard sell.
Not many people need the apps. A phone which has weather widget and decent browser covers heck a lot of consumers.
If Sammy/Docomo also would manage to improve battery life (e.g. Samsung Wave with Bada OS can go 2-4 days on single charge) I personally would gladly trade the choice of apps for the dumbphone.
For consumers what is the benefit of another phone OS with another incompatible app store? What features does this OS have. Is it faster? Cheaper? Prettier?
Probably the same advantages as the Bada OS. In other words, very few advantages for consumers. (Though I'm hopeful that Bada's battery life would get to Tizen. 2-4 days on single charge!)
The purpose of the new OS is to ensure that the manufacturers have a bargaining chip when dealing with the OS providers, Google and Microsoft. Also they can develop it independently and integrate whatever features they want - if the Google or Microsoft are reluctant to act or demand too high pay for the customization.
The only real advantage of another mobile OS I can imagine is that we, consumers, potentially now even further from monopoly/duopoly of mobile OSs. That guarantees that we would have more choices down the road.
From Samsung and HTC sure. Buy some other brand, and they get nothing.
And I'm not even sure that they are collecting anything from the two - considering how fast the deals were made.
MSFT needs Samsung and HTC - as Windows phone producers - more than they need MSFT. It's very likely that under the deal they pay the usual Windows phone license fees, which now also magically (and mostly for PR purposes) covers the MSFT's Android claims.
[...] In the hands of a master, it makes the master that much more productive, because they're not wasting wetware cycles on details like "will concatenating this string overflow my destination buffer?".
Bad example.
A good sign of a non-master is attempt at concatenating string. Think of it, even Java *cannot* concatenate strings. :)
Contemporary C master wouldn't even think about it. Far cry from StringBuilder, but all the functions for safe string handling are already there - one only has to use them. (Although some thought might go into defining the limits for the buffers.)
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
This used to be a more serious problem, but fortunately, these days you can wrap an exception in a new exception and not lose the underlying stack trace. It's the common idiom now. For example: catch (IOException e) { throw new MyLibraryException(e); }
A link/name for the idiom I can pass to our Java people?
Core dumps are useful, of course, but it meant the entire process -- including all the threads -- went down. For high reliability requirements, we typically used a watcher daemon to restart processes that crashed unexpectedly.
We allow to start several instances of the same process: if one goes down, others are still there.
However, I'm not recommending Java over C, or vice-versa, though. I consider the application domains where C and Java compete to be pretty small these days, so typically I consider the correct choice to be dictated by the application domain.
In all fairness, I'm not a specialist in Java. Probably your experience is more relevant than mine.
But I have seen already enough of spaghetti Java code to stop believing entirely the fairy tail of "better language will solve all problems."
In Java, unless you go out of your way to catch NullPointerExceptions and then purposefully eat the attached stack trace, you should know precisely where and why it happened.
Simple response: interface layer of libraries. It's pretty much given to find there some exception-munging code: after all we do not want to expose with exceptions the innards of the library.
Overall, I think the issue of crashes/etc of C programs is overblown. I have checked my historical TODO lists and lion share of stuff are complains that stuff doesn't work as expected. For the whole year 2012 I had only 2 core dump issues out of around 100 tickets which I had to process. Largest feature I did this year had problems with dead-locks in multi-threaded mode, but not a single crash.
The main thing is that we need a language which provides scalable data structures, as servicing IRC messages involves many data lookups.
Are you CTO per chance? VP of tech? You talk like one.
But if you want it to be addressed in a programming language.
Until language developers suck it up and start making languages that allow for opposite concepts in the same language, it would remain the same.
For example.
Most stupid errors in strict typed languages are in the code for some type weakness - because, duh, strictly typed languages provide zero standard facilities to implement weak typing when you need it. So you have to roll out your own.
Most stupid errors in weak-typed languages are related to wrong intermixing of types - because, duh, weakly typed languages provide zero standard facilities to implement strict typing when you need it. So you have to roll out your own.
And it goes on.
especially in servers where robustness is important.
Ditto for C/C++ applications "where robustness is important". Implementation looks different, but same in the essence.
Some memory debuggers and code analyzers (Insure for example) can even catch the error during compilation (IIRC so called "wild pointers" in the Insure speak).
Experience we made with HA software, null pointer problems are (often but only) nasty in C/C++ and are horrible in Java. Some stats. As new release went into tests/production, we found in total about 200 *crashes* due to null pointers in C/C++ apps. In Java part (about half the size of the C/C++) there were about 20 null pointer exceptions - with one which was occurring only in the production. This sole exception cost about 6 month of work to localize - because unlike core dump, Java's stack trace (due to your "which is often the case") was already unwound and couldn't point to the location of the show-stopper problem. This particular case (and it's not a sole Java debacle) became famous, because CTO of the customer, during a meeting, exclaimed that he wished the software was written in C instead, so that developers can see from core dump where the problem is.
What I'm getting here to. If robustness is expected from the software, to customer, it doesn't matter how it fails - crashes or denies service - what matters is that the problem can be quickly localized and fixed. Trivial problems like missing null pointer check in C can be localized from core dump within seconds. Trivial problems like missing null pointer check in Java occasionally cause high level fsckups, thanks to the blank exception handling one often has to resort to. So from practical point of view, the languages unfortunately are very close.
Video taken down by "copyright owners" in 3... 2... 1...
At the time, this spec meant a lot—and, to be honest, I think it worked marvelously.
It didn't. It caused uproar among gamers and all games which supported lower specs (no sound, CD drive required only during installation) were standing out and played more than the rest.
IIRC the spec was literally unused, but still some claimed some success to it. But that happened only after one could buy a sound card for $30 or less and CD drive for $50 or less.
Let the powers that be come up with a new baseline specification.
Be careful what you wish for. Mass market now is a low-power laptop, mostly used for Facebook. If not a tablet. We are at the down-scaling/miniaturization/reshaping of the PC. Most devices used for gaming today do NOT have: CD drive, keyboard or mouse.
Game competition is as high as ever - especially from the adjacent markets (mobile). Game developers are unlikely to try to limit their own market.
Insisting on some minimum spec has already created its own (closed) market: game consoles.
When sex itself is deemed something that's not "pristine" something is very wrong - way beyond wrong .....
And that IMO is the cause of the trauma. Modern parenting including feeding children piles of idealistic crap (too much TV I would say), at best useless for the real life.
Does not help. And Amazon already has some sort of system in place with the "Was the review helpful? Yes/No" stats. You can also add a comment to a review.
Facts:
1. Authors (esp. writing in the same genres, living in the same area) are very often know each other and often are buddies. That might adds positive bias to their reviews. Occasionally they are also competitors - making the bias negative. (The buddying I have seen with my own eyes, where authors were recommending books of their buddy-authors without even reading them first.)
2. Authors have fans. Fans would react disproportionally to a review written by their author. They would also react disproportionally on the negative comments to the review. (I have already seen comment section of a book review with ~120 comments.)
What that means in the end, that book reviews could easily become battleground for the fans and stop being helpful to the consumers.
Decision is probably way too far reaching - but I think Amazon simply does not want to deal with the mess. Especially since they allow ebook self-publishing via "Kindle Direct Publishing," I guess they want to make sure that it runs smoothly on its own.
I have used ISS as an example.
But I have looked it costs anyway. From what I can find, average satellite launch costs $10-20M while SpaceX launch costs around $5+M. The cost difference isn't big enough to drastically change anything :(
Otherwise, the point I was trying to make was that the satellites are so expensive in part because launches are so expensive. One attempts to pack into one expensive trip as much as possible - to make as few trips as possible. If price for launch was magnitude (or two) less, I'm pretty sure that would have made cheaper satellites possible.
I wasn't taking about manufacturing specifically - more like building/assembling the stuff using off-the-shelf parts. I was also thinking about potential expansion of the ISS. Right now it is made of older space modules, what is rather expensive building material. But probably you are right anyway.
That was just an idea, follow up on the possibilities offered by cheaper transportation to the space. Just like the accessible infrastructure down here, possibilities expand greatly.
"You can thrift on cost. You can take cost out of a rocket. But I will guarantee you, in my experience, when you start pulling a lot of costs out of a rocket, your quality and your probability of success in delivering a payload to orbit diminishes."
Fishy argument. Most of the payload I gather is pretty cheap stuff to make astronauts' life on ISS possible.
In a way, price gauging of the launchers has resulted in the reactive price gauging of the payload. But if one can cheaply transport materials to the ISS, some stuff can be actually built and assembled right there - instead of creating the stuff on surface up to the very high standards, required for it to survive the lift off.
That epic battle between commercial software and open-source only exists on RMS's head and on a handful of follower's heads. Fact is that OSS predates RMS [...]
Predates him, indeed. But you have probably forgotten that pretty much all *NIX and *BSD clones - actively developed clones - have abandoned it. Throw in here the USL v. BSDi case, and actually there was a period of time when there was no open source - except for the FSF/GNU.
pcc exists since the seventies.
Riiiight. It has, as BSD, fathered piles of *commercial* forks. Yet itself AFAIK it still can not even claim full ANSI C support - least C++ support or support of any arch except x86/x64. So how that rich history "since the seventies" played out?? Stagnation and irrelevance, because every good idea got implemented - in a commercial fork.
The point being before RMS, OSS was equivalent to BSD. What sucked for very obvious reasons. But RMS had showed that it can be improved upon with his community-centric license. And things have improved since then.
Still, early versions of GNU libc and cc in the 80s and 90s where crucial. At the time it was not only the open source model which was doubted - it was doubted whether "bunch of unemployed hippies" can write anything as sophisticated and of production quality. FSF/GNU under RMS guidance had managed it.
EGCS happened much later, in the end of the 90s. As old saying goes (I have forgotten original wording), person who have contributed something major to development eventually becomes a major impediment to development himself. RMS religious zeal was important instrument to persist through the times of total commercialization of the software. Now, after he made sure that open source exists and thrives, he himself is more of an obstacle to the future of what he had created.
If you are talking about the "uptime" stability
As somebody who actually occasionally uses AIX, but most and foremost who does support for HA system for past 5+ years, let me just say that the uptime stability of any system is asymptotically equivalent to the minimum distance idiot admins are kept from it. Farther you keep idiots away from important system - the system which you want to have great uptime - longer the uptime gets.
Otherwise, our AIX 5.x, 6.x and 7.x boxes run pretty well over here and with great uptime (500+ days between reboots; most commonly rebooted for network/storage reconfiguration or power outlet/physical relocation). Yeah, system is out-dated, mostly sucks and is unused. But try to think of it positively, as about the "glass half-full": Thanks God It's Not HP-sUX!!!!!!!!