If you add back in the rest of the ingredients that women need, and remove the violent aspect of most hard-core porn, then you have soft-core porn.
We may be working from different definitions of soft-core porn. By soft-core porn I mean the kind of stuff you see on Skinemax -- a split second of boobs, followed by two or three seconds of rear nudity, followed by lots of soft-focus closeups of faces or vague motion under the bedcovers in a dark room. When I say hard-core porn I mean anything where you can clearly see that people are having sex. I don't mean rape and donkeys. Perhaps that's the basis of our disagreement.
What is 'Sex in the City' if it is not soft-core porn? And women watch that show voluntarily in their millions.
'Sex and the City' has very little sex in it. I say that having borrowed fast-forwarded through my roommates' Season 1 and 2 DVD sets looking for the juicy bits. When the characters have sex, the act itself is represented by a few seconds of film that segues into narration that talks about the sex and quickly moves past it to the aftereffects. I think the appeal of 'Sex and the City' is based on its treatment of sex through characters, relationships (in the general sense), plot, and occasionally witty writing. Although the portrayal of sex is graphic by American TV standards, the sex is basically summed up by a few little snippets, in contrast to the pre- and post-coital bedroom scenes, which are given lengthy treatment and are often key to plot and character development.
You see, for women, sex is a package deal, and hard-core porn leaves out 90% of what needs to be in the package. Added to which hard-core porn is basically violence, not sex, and generally women aren't turned on by violence (although they do respond to aggression, which is different).
Soft-core porn adds nothing at all -- no plot, no characterization, no suspense, no context. Romance novels at least put sex into the context of a female fantasy. Porn, both hard-core and soft-core, puts sex into the context of no context. This IS the male fantasy -- people getting it on for absolutely no reason at all. Ja, I fix your Kabel. Ich bin Expert. Waka-chika waka-chika waka-chika. (Granted, there are also many pornos that create a context of exploitation, where women are forced or blackmailed into sex, but there are no pornos where a man and a woman have totally nasty sex because she's acting out feelings of shame stemming from the fact that she lied to her husband about her previous sexual experience when she met him.)
Basically, soft-core porn CAN'T contain any meaningful characterization, because if you suggest to a male consumer of porn that a woman's desire is sensitive to the social or emotional context (beyond the context of a guy having a really, really, really big dick) then his pecker shrivels up and he runs away because he knows in real life this is where he gets confused and screws up. A romance novel provides emotional and social context because that's what gives women social permission to be sexual. Establish the right contex, and bam, suddenly something shameful becomes permissible. If a romance novelist wrote soft-core porn, it would go something like this: "Hello, I am a rich Hungarian count. Ever since my wife died, I am lonely and afraid to be truly intimate with a woman. You, however, are different. I find you beautiful and intriguing." Waka-chika-waka-chika-waka-chika oh no! conflict erupts and the characters must leave behind their emotional baggage and grow personally before they can do the nasty again! Yay, they managed it! Waka-chika-waka-chika-waka-chika.... Instead, you get stuff that's just as silly as hardcore porn.
hard-core porn is basically violence, not sex
Much hard-core porn is violent, but 90% of anything is crap. Most fictional entertainment is based around violence or threats of violence, so I don't think hard-core porn is special in this way. Men have a hard time vividly connecting with an
Ooh, the acting is terrible, the plot is asinine, there are only fleeting glimpses of the woman's attractive body, but I am aware that the people on the screen are supposedly having sex!
Softcore porn is terrible. The people who make softcore porn are exactly as artful and sophisticated as the people who make hardcore porn. Softcore porn is just hardcore porn with various things subtracted and nothing else added in. Softcore porn is:
Bill O'Reilly without the incivility....
Taco Bell without the industrial additives....
Macrobrew beer without the intoxication....
A Hummer without the egocentrism....
Taking a fat chick out and not getting laid....
In other words, a waste of time. That's what softcore porn is, as well as most of the stuff sold under the label "erotica." When I hear that women like softcore porn, I think, yeah, right, some guy pressures his overly compliant wife/girlfriend into watching porn with him, and she chooses softcore as a way of limiting the misery. It's true that much of the really vile stuff in hardcore porn simply can't be done in softcore. There's no softcore version of Back Door Sluts 9. But there's no reason you have to put up with any vileness when you choose porn.
(Sigh, except for the cumshot, which is obligatory. I can't figure out why there isn't a larger market for cumshot-free porn. There are probably more geriatric midget granny pee DVDs at your local porn store than DVDs with no cumshots. But if you overlook the cumshot, some porn is actually okay, so decent in fact that when the cumshot happens it's a complete WHAT THE....? WHAT JUST HAPPENED? kind of moment, exactly as shocking and out of place as if you tried it in real life after having normal boring sex with a normal straightlaced girl on your third date. Which I know some guys do, and they deserve to be strung up by their balls along with 98% of the porn producers on the planet... but I digress.)
Exactly! Now why isn't that common knowledge? I used Linux for five years before even hearing about screen. Many of my acquaintances who have been using Linux much longer than me have never heard of it. Why is that? It's the coolest thing since sliced bread.
Also, the only decent way to work on a Linux box from Windows (assuming that like me you can't afford a fancy commercial X server) is by running a screen session inside Putty.
An unsophisticated approach goes a long way to ensure sanity with exceptions and top-level exception handlers, even if the execution isn't particularly disciplined. There are lots of situations where a programming mistake, such as failure anticipate and handle a possible error condition, is much less harmful in the presence of exceptions than when using error codes that must be explicitly checked.
First, if the application is going to fail, it's better that the user knows, and the sooner the better. If the application fails silently, the user can do hours of work based on a result returned by a failed operation, only to find out later that it was wasted. Or the user can wait hours for a job to finish, only to find out that the job produced bad output because of a condition that could have been detected near the beginning of the run.
Second, some operations finish by updating an existing (good) dataset with newly calculated data. Obviously in this case it's preferable to crash rather than miss an error.
Third, even when program crashes with no bad side effects, it is much better to have exceptions, because the exception can be caught and logged at the top level before the program terminates. This gives a chance to provide feedback to the user, who might be able to work around the exception quite easily if the error is obvious -- maybe the user entered a nonexistent path, expecting the program to create it for him, or something like that. It also gives programmers a chance of getting a decent bug report. The top-level handler might even be able to autosave all open documents and give the user a chance to recover them the next time he starts the program.
I could go on, but you get the drift. Silent errors can leave users with corrupted files (destroying weeks of work), mysterious crashes (with no clue how to prevent or work around the error), bad data that appears to be good and affects important decisions made by the user, etc. On top of all that, it's much more professional, and more reassuring to the user, to terminate an operation or application with a message like, "FooApp has detected an internal error and is shutting down to prevent damage to user data. Please send the log file FooApp.log to [technical support|the developers] at bugfeedback@fooapp.com. We regret the inconvenience." This is terribly unsophisticated compared to the approaches you suggest, but it's within the grasp of almost any developer to add a top-level handler that logs a message and terminates the program, and the result is immeasurably superior to any approach that makes errors silent by default.
No side effects other than halting the application, you mean;-) To expand on your statement, the optional nature of asserts means you should:
Never put important checks into asserts whose compilation status you don't control.
Never use asserts to check for errors originating in other modules. (I usually go much further than this and only use asserts to check for errors originating in the same function (for free-standing functions) or class (for member functions).)
Never use asserts to check for conditions that might be caused by user error or external conditions.
Never use asserts to guard against conditions that are recoverable. (If you are ever tempted to catch and handle an assertion failure, it should be converted into a normal exception. Assertion failures should never be caught and handled, except by handlers that can log extra information before rethrowing, or log the assention info into a sink that the throwing code didn't have access to.)
Basically, you should only use assertions for checks that can be removed when the module is declared bug-free. I follow this practice even though I never plan on declaring my code bug-free (hubris!), because I know that developers succeeding me might assume it is reasonable to turn off assertions in stable code.
Another good idea, though I have never had a need to use it myself, is to create two categories of assertions: those that have been shown to affect performance, and those that presumably do not affect performance. This is a good way to profit by the 90/10 rule, and a good way to placate weirdos who think that safety and speed are eternal enemies, locked in a battle for the soul of software, instead of desirable qualities that occasionally must be traded off against each other.
Oriental does apply to people, although that meaning has been so damaged by its association with backwards thinking that it has been essentially retired. I used it intentionally to highlight how out-of-date and unwelcome the original post's stereotypes are.
Nothing odd about that. I would expect him to have the weakest single-threading skills, too. You can't have much education and experience if you're Java-only.
select() only handles input that arrives through file descriptors. If you have to handle many different kinds of events, you have to go around polling all the possible places where they could arrive. Or, I suppose you could provide a wrapper for every single kind of input event that channels the events through file descriptors, so you could use select for everything.
Even then, you have to come up with a way of making sure you don't spend too much time on one task. Basically, you have to reimplement task-switching and process scheduling to avoid one computationally expensive task highjacking the program and making it unresponsive. Why not let the operating system or threading library handle that?
Most tasks, other than system-wide tasks, are inherently serial in nature. It's the way we think.
Few programs only perform a single task.
How many parallel flow charts have you ever seen?
Many. They're called dataflow diagrams, and people generate concurrent programs from them the same way people generate single-threaded programs from flowcharts.
Think of all the major computer applications. How many of them deal with anything in other than a serial manner?
E-mail clients, word processors, text editors, and browsers all have to perform concurrent tasks: checking for new mail, doing spell check, autosaving drafts, parsing text for grammar highlighting, downloading pages in the background, displaying animations, and checking for application updates, all while responding to user input.
Add to this the fact that nearly all of us have been programming in serial mode all of our programming lives
Java changed that. Basically every programmer who has had a basic Java course or worked through an introductory Java book has learned the basics of threading and written several multi-threaded programs. I would guess that the majority of professional Java programmers have to consider threading issues when they write code, though I might be wrong about that. In any case, that's a hell of a lot of programmers. Java is not an elite language.
most of the time, your application is waiting. Either for input from the user or for data from a slow source, like a network or even the internet
And a single-threaded program, unless it is written very cleverly, can only wait for one thing at a time. Don't you hate it when a program you're using tries to access a slow resource and completely locks up until the resource responds, preventing you from even cancelling the action? That's the kind of bug you get when a programmer assumes that a single-threaded design is always easier, even when solving a naturally concurrent problem.
You can get a single-threaded program to fake concurrency correctly, but it takes special care, just like multithreading takes special care. The single-threaded program will rely on baroque control flow hacks that cause control to skip all over the source code, trying to keep all the plates spinning, while the execution flows in multithreaded programs can proceed quite linearly, blocking whenever they feel like it. These aspects have to be balanced against the difficulty of protecting shared resources, which is much easier in single-threaded programs. It's a complexity tradeoff that by no means always favors the single-threaded solution. It's possible to decide in favor of a multithreaded solution even when performance is not a factor at all.
$FOO programming is too hard. Few programmers can really handle it. Projects run into unpredictable difficulties. There's no way to do it without introducing lots of bugs which have to be laboriously tracked down and fixed by programmers. We need a revolution in tools and methodologies before $FOO programming becomes a reasonable and predictable task.
Try replacing $FOO with various words: "parallel," "large-scale," "object-oriented," "cross-platform." No matter what you plug in there, the spiel sounds familiar. Now just take $FOO out altogether:
Programming is too hard. Few programmers can really handle it. Projects run into unpredictable difficulties. There's no way to do it without introducing lots of bugs which have to be laboriously tracked down and fixed by programmers. We need a revolution in tools and methodologies before programming becomes a reasonable and predictable task.
Yep, we hear that all the time too. These are meaningless words. I won't say they're pointless, since dissatisfaction drives progress, but they don't mean a damn thing at all.
How would a string of Chinese characters like beads on a string be any better than a string of alphanumeric characters like beads on a string? Many (most?) Chinese words are written using multiple characters, so a language that had a special use for lone characters would end up looking a lot like Fortran 77 anyway. (What does the FSSCRD function do?)
I think you're reasoning from some notion about the way "Oriental" people think differently from "Western" people. I tend to doubt that idea based on the kinds of people who have enthusiastically pushed it: originally imperialist racists of various groups, each bent on proving the superiority of their group, and more recently western PC racists who compulsively idealize everything non-Western. Despite the taint of racism, the idea may have some basis in fact as well -- there is ongoing research that occasionally manages to produce some evidence for it -- but the sad fact is that we have only been able to create programming languages that express a very tiny subset of the way "Western" people supposedly think anyway. The problem is not a lack of nonlinear, context-sensitive ways of thinking; the problem is that before we can use a given way of thinking to communicate with a computer, we must essentially enable the computer to think the same way. If you buy into the western PC version of the dualism, "Oriental = nonlinear, inclusive, sensitive, flexible, context-sensitive; Western = linear, exclusive, autistic, rigid, blinkered," then digital computers are quintessentially Western beings that cannot be made to appreciate Eastern ways of thinking, at least not without a few more decades of AI research and performance improvements.
The Chinese government might very well be hard at work creating a quintessentially Chinese programming language, but it's a bad idea to pin your hopes on political science. It tends to suck. On top of that, many excellent programming languages have been doomed by much smaller barriers to entry than learning an entirely new system of writing. On top of that, your 2D array of characters is doomed by the multitudes of multicharacter words in Chinese. To add yet more on top of that, another poster just pointed out that the idea that it expresses has already been expressed in other languages using ASCII.
I wouldn't have bothered piling on you like this if your post didn't strike me as racist. The commonly accepted story about the differences between Eastern and Western ways of thinking is propagated by uninformed repitition. Chinese, Americans, left-wingers, right-wingers, everybody has learned to love it and interpret it to flatter their side, so they all repeat it in unison. It pollutes the discourse. Wouldn't it be nice if everyone who didn't have firsthand experience just shut the hell up? Then we might hear something different from the standard story that gets passed around like a centuries-old fruitcake. Or we might hear the same thing, but then at least it would mean something.
When you have a large (0.5TB) database that requires quite literally 100% availability, globally, 24x7, you cannot afford to be playing with broken toy database systems.
You have a database system that instantly solves all communications problems that occur between it and any client anywhere in the world? That's awesome! I can't wait to run one at home so my internet access never goes down.
I think in the case of the JFK assassination, it would be very difficult to argue that any line of investigation, no matter how silly, wasn't looked at by somebody.
How many were investigated by organizations that were skilled in investigation, had plenty of resources, and weren't just out to make a TV show? Not to mention the legal devices that the government has at its disposal. But actually I don't know when the results of the first bullet analysis were available, so I don't know what impact it had on the investigation.
The level of confidence is a crucial part of the conclusion. In this case, a very high degree of confidence eliminated entire lines of investigation. A very low level of confidence, which is what the new tests show (essentially no confidence in any conclusion), is an entirely different matter and an entirely different conclusion.
This can only be considered "news" if mainstream scientists can back up the lone research team.
This is indeed a "lone" research team, but it's hard to get more mainstream. In case you missed it: "Tobin was the FBI lab's chief metallurgy expert for more than two decades. He analyzed metal evidence in major cases that included the 1995 Oklahoma City bombing and the 1996 explosion of TWA Flight 800 off Long Island."
Really, if you know of a way a person can be more mainstream, square, and conventional than that, please speak up. Oh, wait, there is a way: "The questions he and others raised prompted a National Academy of Sciences review that in 2003 concluded that the FBI's bullet lead analysis was flawed. The FBI agreed and generally ended the use of that type of analysis." This guy sets the standard for mainstream. He makes Dick Cheney look like a hippie. He makes J. Edgar Hoover look like a crossdresser. Wait... ignore that. He makes Thomas Friedman look like a Juggalo. I predict a sharp rise in conspiracy theories in which Oswald is the lone gunmen, as conspiracy nuts rush to distance themselves from his overwhelming and undeniable stench of mainstreamness.
Maintain a list of features users might expect, and whether your software supports them. Make this list a focal point of the project's web site.
Nothing sucks more than having to download, build, install, and use a program to see if feature X is present and functioning. Most people won't even bother. If you're releasing a dev tool for C++, make a checklist of C++ language features and document which ones your tool supports. Don't make someone run it on their data and see a bunch of errors just to find out the code is incomplete.
Plus, the only way to get bug reports on features that are supposed to work is to document the fact that they're supposed to work. Otherwise, when people encounter weird bugs, they'll just say screw this, the basic features aren't even implemented yet.
You should be able to say "I can't do my job without it" and that should be that. If you can't do that, then you probably don't need it.
This is not how a sysadmin does his job. This is how a sysadmin copes in a screwed up organization where he isn't allowed to do his job right. "I can't do my job without it" is a childish standard only liars will ever claim to meet. I could do my job with just ed, gcc, and ssh, and if you don't offer me a reasonable standard, I have a choice between working that way at 1/2 or 1/4 productivity or lying to you and installing a few useful apps. By setting an unreasonable standard, you've abdicated all responsibility for figuring out the tradeoff between the value of an application and the cost of installing it. You've changed the standard from "how valuable is this app, compared to how dangerous it is?" to "how willing is this user to lie to IT staff?" I guess it cuts down your workload to set a standard like that, but in a healthy organization you would want to support everybody, not just liars and abusers.
Hey, this is the internet, where every utterance is Sincere, Sarcasm, or Troll, and everyone defends their position to the bitter end. That requires a little dumbing down of the writing, but isn't it worth it to be able to communicate with a bunch of teenagers?
Re:This is (now) a famous number-theory integer!
on
Censoring a Number
·
· Score: 1
You piqued my curiousity, so I googled. (At first I thought it was something to do with karma-whoring by appealing to Slashdotters' sense of inadequacy, which at least would have had an element of truth, since I suspected the idea would resonate with my fellow nerds.) Here's part of the characterization I found for the Adequacy Troll:
* A tone of calmness and rationalism is maintained. This creates an enhanced contrast between the AST itself and the responses, which are likely to be emotional and less thoroughly considered. * The initial starting position for argument is unassailably sensible. * Each step of the argument is completely reasonable. * Substantial, even excessive, documentation is provided. * The final conclusion is outrageous and completely unacceptable to the target victim group.
There's nothing wrong with the first one. The second and third don't apply, since I didn't make an argument -- the bulk of my post was a prediction, with little justification given. I provided no documentation at all. The final conclusion could be seen as outrageous and unacceptable, but I expected the post to be mostly well received, and as you can see, it was. Trolling means deliberately provoking unedifying responses, and I was actually trying to provoke interesting ones. (I don't think it's a good idea to define trolling so broadly, since it tends to include satire -- any refutation of effective satire is dull and pointless, and when posting satire in most cases you know that if you hit the mark there will be someone stupid enough to attempt a refutation. That's another conversation, though. I didn't intend my post to be satire.)
I am very disappointed with the lack of responses, though. The idea has been bouncing around in my head since Virginia Tech, and I wanted to get some feedback. I'm shocked at how it was modded so high up without anybody disagreeing, posting their own theories, or agreeing and providing some support for the prediction. I really don't know whether to take the idea seriously myself, and the (lack of) response here didn't help:-/ If your post wasn't the closest thing to a real response, I probably wouldn't have bothered replying.
Just to prove I actually gave some thought to it, I'm very interested in the parallel between nerds' role in technology and the role of a parellel class of people in religion. Many influential religious mystics and leaders seem to have had epilepsy, schizophrenia, or other mental illnesses. Mild forms of those illnesses may have provided a talent for religious intuition and imagination, just like mild forms of autism seem to provide a capacity for certain kinds of technical work. In both cases, a small number of people have been able to function at a high level despite rather severe "symptoms" and put their "symptoms" to extraordinary use. Many others have done the same thing on a smaller scale. Now, religion no longer provides a way to turn those "symptoms" into socially valued work.
Mental illness seems to play a similar role in art, but art has also declined, at least as a way for ordinary people to be valued in society. Except for commercial art, our art (music, movies, poetry, fiction) is produced by a tiny subset of the population, so artistic creation has essentially disappeared as a realistic role for people to play. The production and distribution of music, movies, clothing, and household decorations is so efficient that there are only places for a very small number of valued artists, compared to the past.
The decline of religion and art has turned what might previously have been called "mystical tendencies" or "artistic sensibilities" into a fairly useless talent, unless a person is one of the elite few who produces creative artistic works. Epilepsy, schizophrenia, and other disorders that might previously have carried some religious or artistic ability as compensation are now simply handicaps.
It is well-known that Java is a "write once, debug everywhere" solution.
Funny, I worked in a Java shop with dozens of programmers where nobody developed on the deployment platform. We deployed to Solaris, but we developed, tested, debugged, etc. on Windows and Linux. In most cases, new code never ran on Solaris until it was sent to QA. When a bug was found on Solaris, we reproduced it and debugged it under Windows. This never caused any problems, nor do I recall tests ever passing under Windows and failing under Solaris, or vice-versa. This was in 2000-2002.
Seconded. There are so many ways to set up differently paced and differently balanced games. If I still played games, I would be looking for worthy successors to AoE2. I love the large-scale aspect of the game, but last time i checked it seemed that most gamers prefer to closely manage smaller-scale battles rather than spread their attention thinly over a larger board:-/
It makes all the difference in the world. There's something toxic about trying to ignore each other when you can see or hear each other. When the door is closed, you have immersion-in-work time and immersion-in-each-other time, which is a lot better than being not quite immersed in one because it's hard to ignore the other.
From my perspective you've got it backwards. Every single program in a pipeline chain is burdened with the job of converting "human-readable" data to a useful, processable form - and then back to text again for the next chump in the line. So maybe you save one step, because you don't need to reformat the output of your last command - but you've added on two steps for every command in the chain (minus one, for the first) - and when programs start to get even moderately outside the realm of the common, everyday stuff, the user starts having to deal with those processes themselves.
Yet handling these steps seems more practical than trying to share data format definitions between languages.
Every language that takes part in a Unix pipeline has to handle text -- awkward, but doable.
Every language that takes part in the object pipeline you describe has to have a shared way of defining structured binary data -- historically, a huge tangled problem that has probably spawned more short-lived and nonstandard "standards" than any other kind of computing problem. These "standards," despite being intended to enable compatibility, have caused more incompatibilities than any other kind of computing technology.
In this case, text is the best solution, perhaps because it isn't a solution at all.
Slashdot Mirror
If you add back in the rest of the ingredients that women need, and remove the violent aspect of most hard-core porn, then you have soft-core porn.
We may be working from different definitions of soft-core porn. By soft-core porn I mean the kind of stuff you see on Skinemax -- a split second of boobs, followed by two or three seconds of rear nudity, followed by lots of soft-focus closeups of faces or vague motion under the bedcovers in a dark room. When I say hard-core porn I mean anything where you can clearly see that people are having sex. I don't mean rape and donkeys. Perhaps that's the basis of our disagreement.
What is 'Sex in the City' if it is not soft-core porn? And women watch that show voluntarily in their millions.
'Sex and the City' has very little sex in it. I say that having borrowed fast-forwarded through my roommates' Season 1 and 2 DVD sets looking for the juicy bits. When the characters have sex, the act itself is represented by a few seconds of film that segues into narration that talks about the sex and quickly moves past it to the aftereffects. I think the appeal of 'Sex and the City' is based on its treatment of sex through characters, relationships (in the general sense), plot, and occasionally witty writing. Although the portrayal of sex is graphic by American TV standards, the sex is basically summed up by a few little snippets, in contrast to the pre- and post-coital bedroom scenes, which are given lengthy treatment and are often key to plot and character development.
You see, for women, sex is a package deal, and hard-core porn leaves out 90% of what needs to be in the package. Added to which hard-core porn is basically violence, not sex, and generally women aren't turned on by violence (although they do respond to aggression, which is different).
Soft-core porn adds nothing at all -- no plot, no characterization, no suspense, no context. Romance novels at least put sex into the context of a female fantasy. Porn, both hard-core and soft-core, puts sex into the context of no context. This IS the male fantasy -- people getting it on for absolutely no reason at all. Ja, I fix your Kabel. Ich bin Expert. Waka-chika waka-chika waka-chika. (Granted, there are also many pornos that create a context of exploitation, where women are forced or blackmailed into sex, but there are no pornos where a man and a woman have totally nasty sex because she's acting out feelings of shame stemming from the fact that she lied to her husband about her previous sexual experience when she met him.)
Basically, soft-core porn CAN'T contain any meaningful characterization, because if you suggest to a male consumer of porn that a woman's desire is sensitive to the social or emotional context (beyond the context of a guy having a really, really, really big dick) then his pecker shrivels up and he runs away because he knows in real life this is where he gets confused and screws up. A romance novel provides emotional and social context because that's what gives women social permission to be sexual. Establish the right contex, and bam, suddenly something shameful becomes permissible. If a romance novelist wrote soft-core porn, it would go something like this: "Hello, I am a rich Hungarian count. Ever since my wife died, I am lonely and afraid to be truly intimate with a woman. You, however, are different. I find you beautiful and intriguing." Waka-chika-waka-chika-waka-chika oh no! conflict erupts and the characters must leave behind their emotional baggage and grow personally before they can do the nasty again! Yay, they managed it! Waka-chika-waka-chika-waka-chika.... Instead, you get stuff that's just as silly as hardcore porn.
hard-core porn is basically violence, not sex
Much hard-core porn is violent, but 90% of anything is crap. Most fictional entertainment is based around violence or threats of violence, so I don't think hard-core porn is special in this way. Men have a hard time vividly connecting with an
Softcore porn is terrible. The people who make softcore porn are exactly as artful and sophisticated as the people who make hardcore porn. Softcore porn is just hardcore porn with various things subtracted and nothing else added in. Softcore porn is:
Bill O'Reilly without the incivility....
Taco Bell without the industrial additives....
Macrobrew beer without the intoxication....
A Hummer without the egocentrism....
Taking a fat chick out and not getting laid....
In other words, a waste of time. That's what softcore porn is, as well as most of the stuff sold under the label "erotica." When I hear that women like softcore porn, I think, yeah, right, some guy pressures his overly compliant wife/girlfriend into watching porn with him, and she chooses softcore as a way of limiting the misery. It's true that much of the really vile stuff in hardcore porn simply can't be done in softcore. There's no softcore version of Back Door Sluts 9. But there's no reason you have to put up with any vileness when you choose porn.
(Sigh, except for the cumshot, which is obligatory. I can't figure out why there isn't a larger market for cumshot-free porn. There are probably more geriatric midget granny pee DVDs at your local porn store than DVDs with no cumshots. But if you overlook the cumshot, some porn is actually okay, so decent in fact that when the cumshot happens it's a complete WHAT THE....? WHAT JUST HAPPENED? kind of moment, exactly as shocking and out of place as if you tried it in real life after having normal boring sex with a normal straightlaced girl on your third date. Which I know some guys do, and they deserve to be strung up by their balls along with 98% of the porn producers on the planet... but I digress.)
Exactly! Now why isn't that common knowledge? I used Linux for five years before even hearing about screen. Many of my acquaintances who have been using Linux much longer than me have never heard of it. Why is that? It's the coolest thing since sliced bread.
Also, the only decent way to work on a Linux box from Windows (assuming that like me you can't afford a fancy commercial X server) is by running a screen session inside Putty.
An unsophisticated approach goes a long way to ensure sanity with exceptions and top-level exception handlers, even if the execution isn't particularly disciplined. There are lots of situations where a programming mistake, such as failure anticipate and handle a possible error condition, is much less harmful in the presence of exceptions than when using error codes that must be explicitly checked.
First, if the application is going to fail, it's better that the user knows, and the sooner the better. If the application fails silently, the user can do hours of work based on a result returned by a failed operation, only to find out later that it was wasted. Or the user can wait hours for a job to finish, only to find out that the job produced bad output because of a condition that could have been detected near the beginning of the run.
Second, some operations finish by updating an existing (good) dataset with newly calculated data. Obviously in this case it's preferable to crash rather than miss an error.
Third, even when program crashes with no bad side effects, it is much better to have exceptions, because the exception can be caught and logged at the top level before the program terminates. This gives a chance to provide feedback to the user, who might be able to work around the exception quite easily if the error is obvious -- maybe the user entered a nonexistent path, expecting the program to create it for him, or something like that. It also gives programmers a chance of getting a decent bug report. The top-level handler might even be able to autosave all open documents and give the user a chance to recover them the next time he starts the program.
I could go on, but you get the drift. Silent errors can leave users with corrupted files (destroying weeks of work), mysterious crashes (with no clue how to prevent or work around the error),
bad data that appears to be good and affects important decisions made by the user, etc. On top of all that, it's much more professional, and more reassuring to the user, to terminate an operation or application with a message like, "FooApp has detected an internal error and is shutting down to prevent damage to user data. Please send the log file FooApp.log to [technical support|the developers] at bugfeedback@fooapp.com. We regret the inconvenience." This is terribly unsophisticated compared to the approaches you suggest, but it's within the grasp of almost any developer to add a top-level handler that logs a message and terminates the program, and the result is immeasurably superior to any approach that makes errors silent by default.
Basically, you should only use assertions for checks that can be removed when the module is declared bug-free. I follow this practice even though I never plan on declaring my code bug-free (hubris!), because I know that developers succeeding me might assume it is reasonable to turn off assertions in stable code.
Another good idea, though I have never had a need to use it myself, is to create two categories of assertions: those that have been shown to affect performance, and those that presumably do not affect performance. This is a good way to profit by the 90/10 rule, and a good way to placate weirdos who think that safety and speed are eternal enemies, locked in a battle for the soul of software, instead of desirable qualities that occasionally must be traded off against each other.
Oriental does apply to people, although that meaning has been so damaged by its association with backwards thinking that it has been essentially retired. I used it intentionally to highlight how out-of-date and unwelcome the original post's stereotypes are.
Nothing odd about that. I would expect him to have the weakest single-threading skills, too. You can't have much education and experience if you're Java-only.
Oh, I see, it's just like all the others!
select() only handles input that arrives through file descriptors. If you have to handle many different kinds of events, you have to go around polling all the possible places where they could arrive. Or, I suppose you could provide a wrapper for every single kind of input event that channels the events through file descriptors, so you could use select for everything.
Even then, you have to come up with a way of making sure you don't spend too much time on one task. Basically, you have to reimplement task-switching and process scheduling to avoid one computationally expensive task highjacking the program and making it unresponsive. Why not let the operating system or threading library handle that?
Few programs only perform a single task.
Many. They're called dataflow diagrams, and people generate concurrent programs from them the same way people generate single-threaded programs from flowcharts.
E-mail clients, word processors, text editors, and browsers all have to perform concurrent tasks: checking for new mail, doing spell check, autosaving drafts, parsing text for grammar highlighting, downloading pages in the background, displaying animations, and checking for application updates, all while responding to user input.
Java changed that. Basically every programmer who has had a basic Java course or worked through an introductory Java book has learned the basics of threading and written several multi-threaded programs. I would guess that the majority of professional Java programmers have to consider threading issues when they write code, though I might be wrong about that. In any case, that's a hell of a lot of programmers. Java is not an elite language.
And a single-threaded program, unless it is written very cleverly, can only wait for one thing at a time. Don't you hate it when a program you're using tries to access a slow resource and completely locks up until the resource responds, preventing you from even cancelling the action? That's the kind of bug you get when a programmer assumes that a single-threaded design is always easier, even when solving a naturally concurrent problem.
You can get a single-threaded program to fake concurrency correctly, but it takes special care, just like multithreading takes special care. The single-threaded program will rely on baroque control flow hacks that cause control to skip all over the source code, trying to keep all the plates spinning, while the execution flows in multithreaded programs can proceed quite linearly, blocking whenever they feel like it. These aspects have to be balanced against the difficulty of protecting shared resources, which is much easier in single-threaded programs. It's a complexity tradeoff that by no means always favors the single-threaded solution. It's possible to decide in favor of a multithreaded solution even when performance is not a factor at all.
Try replacing $FOO with various words: "parallel," "large-scale," "object-oriented," "cross-platform." No matter what you plug in there, the spiel sounds familiar. Now just take $FOO out altogether:
Yep, we hear that all the time too. These are meaningless words. I won't say they're pointless, since dissatisfaction drives progress, but they don't mean a damn thing at all.
How would a string of Chinese characters like beads on a string be any better than a string of alphanumeric characters like beads on a string? Many (most?) Chinese words are written using multiple characters, so a language that had a special use for lone characters would end up looking a lot like Fortran 77 anyway. (What does the FSSCRD function do?)
I think you're reasoning from some notion about the way "Oriental" people think differently from "Western" people. I tend to doubt that idea based on the kinds of people who have enthusiastically pushed it: originally imperialist racists of various groups, each bent on proving the superiority of their group, and more recently western PC racists who compulsively idealize everything non-Western. Despite the taint of racism, the idea may have some basis in fact as well -- there is ongoing research that occasionally manages to produce some evidence for it -- but the sad fact is that we have only been able to create programming languages that express a very tiny subset of the way "Western" people supposedly think anyway. The problem is not a lack of nonlinear, context-sensitive ways of thinking; the problem is that before we can use a given way of thinking to communicate with a computer, we must essentially enable the computer to think the same way. If you buy into the western PC version of the dualism, "Oriental = nonlinear, inclusive, sensitive, flexible, context-sensitive; Western = linear, exclusive, autistic, rigid, blinkered," then digital computers are quintessentially Western beings that cannot be made to appreciate Eastern ways of thinking, at least not without a few more decades of AI research and performance improvements.
The Chinese government might very well be hard at work creating a quintessentially Chinese programming language, but it's a bad idea to pin your hopes on political science. It tends to suck. On top of that, many excellent programming languages have been doomed by much smaller barriers to entry than learning an entirely new system of writing. On top of that, your 2D array of characters is doomed by the multitudes of multicharacter words in Chinese. To add yet more on top of that, another poster just pointed out that the idea that it expresses has already been expressed in other languages using ASCII.
I wouldn't have bothered piling on you like this if your post didn't strike me as racist. The commonly accepted story about the differences between Eastern and Western ways of thinking is propagated by uninformed repitition. Chinese, Americans, left-wingers, right-wingers, everybody has learned to love it and interpret it to flatter their side, so they all repeat it in unison. It pollutes the discourse. Wouldn't it be nice if everyone who didn't have firsthand experience just shut the hell up? Then we might hear something different from the standard story that gets passed around like a centuries-old fruitcake. Or we might hear the same thing, but then at least it would mean something.
You have a database system that instantly solves all communications problems that occur between it and any client anywhere in the world? That's awesome! I can't wait to run one at home so my internet access never goes down.
How many were investigated by organizations that were skilled in investigation, had plenty of resources, and weren't just out to make a TV show? Not to mention the legal devices that the government has at its disposal. But actually I don't know when the results of the first bullet analysis were available, so I don't know what impact it had on the investigation.
This is indeed a "lone" research team, but it's hard to get more mainstream. In case you missed it: "Tobin was the FBI lab's chief metallurgy expert for more than two decades. He analyzed metal evidence in major cases that included the 1995 Oklahoma City bombing and the 1996 explosion of TWA Flight 800 off Long Island."
Really, if you know of a way a person can be more mainstream, square, and conventional than that, please speak up. Oh, wait, there is a way: "The questions he and others raised prompted a National Academy of Sciences review that in 2003 concluded that the FBI's bullet lead analysis was flawed. The FBI agreed and generally ended the use of that type of analysis." This guy sets the standard for mainstream. He makes Dick Cheney look like a hippie. He makes J. Edgar Hoover look like a crossdresser. Wait... ignore that. He makes Thomas Friedman look like a Juggalo. I predict a sharp rise in conspiracy theories in which Oswald is the lone gunmen, as conspiracy nuts rush to distance themselves from his overwhelming and undeniable stench of mainstreamness.
It's hardly a battle. Each group pays attention to what it cares about.
The missing step 12:
Maintain a list of features users might expect, and whether your software supports them. Make this list a focal point of the project's web site.
Nothing sucks more than having to download, build, install, and use a program to see if feature X is present and functioning. Most people won't even bother. If you're releasing a dev tool for C++, make a checklist of C++ language features and document which ones your tool supports. Don't make someone run it on their data and see a bunch of errors just to find out the code is incomplete.
Plus, the only way to get bug reports on features that are supposed to work is to document the fact that they're supposed to work. Otherwise, when people encounter weird bugs, they'll just say screw this, the basic features aren't even implemented yet.
Hey, this is the internet, where every utterance is Sincere, Sarcasm, or Troll, and everyone defends their position to the bitter end. That requires a little dumbing down of the writing, but isn't it worth it to be able to communicate with a bunch of teenagers?
There's nothing wrong with the first one. The second and third don't apply, since I didn't make an argument -- the bulk of my post was a prediction, with little justification given. I provided no documentation at all. The final conclusion could be seen as outrageous and unacceptable, but I expected the post to be mostly well received, and as you can see, it was. Trolling means deliberately provoking unedifying responses, and I was actually trying to provoke interesting ones. (I don't think it's a good idea to define trolling so broadly, since it tends to include satire -- any refutation of effective satire is dull and pointless, and when posting satire in most cases you know that if you hit the mark there will be someone stupid enough to attempt a refutation. That's another conversation, though. I didn't intend my post to be satire.)
:-/ If your post wasn't the closest thing to a real response, I probably wouldn't have bothered replying.
I am very disappointed with the lack of responses, though. The idea has been bouncing around in my head since Virginia Tech, and I wanted to get some feedback. I'm shocked at how it was modded so high up without anybody disagreeing, posting their own theories, or agreeing and providing some support for the prediction. I really don't know whether to take the idea seriously myself, and the (lack of) response here didn't help
Just to prove I actually gave some thought to it, I'm very interested in the parallel between nerds' role in technology and the role of a parellel class of people in religion. Many influential religious mystics and leaders seem to have had epilepsy, schizophrenia, or other mental illnesses. Mild forms of those illnesses may have provided a talent for religious intuition and imagination, just like mild forms of autism seem to provide a capacity for certain kinds of technical work. In both cases, a small number of people have been able to function at a high level despite rather severe "symptoms" and put their "symptoms" to extraordinary use. Many others have done the same thing on a smaller scale. Now, religion no longer provides a way to turn those "symptoms" into socially valued work.
Mental illness seems to play a similar role in art, but art has also declined, at least as a way for ordinary people to be valued in society. Except for commercial art, our art (music, movies, poetry, fiction) is produced by a tiny subset of the population, so artistic creation has essentially disappeared as a realistic role for people to play. The production and distribution of music, movies, clothing, and household decorations is so efficient that there are only places for a very small number of valued artists, compared to the past.
The decline of religion and art has turned what might previously have been called "mystical tendencies" or "artistic sensibilities" into a fairly useless talent, unless a person is one of the elite few who produces creative artistic works. Epilepsy, schizophrenia, and other disorders that might previously have carried some religious or artistic ability as compensation are now simply handicaps.
This is what originally inspired me to won
Seconded. There are so many ways to set up differently paced and differently balanced games. If I still played games, I would be looking for worthy successors to AoE2. I love the large-scale aspect of the game, but last time i checked it seemed that most gamers prefer to closely manage smaller-scale battles rather than spread their attention thinly over a larger board :-/
It makes all the difference in the world. There's something toxic about trying to ignore each other when you can see or hear each other. When the door is closed, you have immersion-in-work time and immersion-in-each-other time, which is a lot better than being not quite immersed in one because it's hard to ignore the other.
Yet handling these steps seems more practical than trying to share data format definitions between languages.
Every language that takes part in a Unix pipeline has to handle text -- awkward, but doable.
Every language that takes part in the object pipeline you describe has to have a shared way of defining structured binary data -- historically, a huge tangled problem that has probably spawned more short-lived and nonstandard "standards" than any other kind of computing problem. These "standards," despite being intended to enable compatibility, have caused more incompatibilities than any other kind of computing technology.
In this case, text is the best solution, perhaps because it isn't a solution at all.