Slashdot Mirror
Tech Companies Looking Into Sarcasm Detection
Nerval's Lobster writes "Now here's the greatest thing ever: French tech firm Spotter has apparently devised an analytics platform capable of identifying sarcastic comments, according to the BBC. Spotter's platform scans social media and other sources to create reputation reports for clients such as the EU Commission and Air France. As with most analytics packages that determine popular sentiment, the software parses semantics, heuristics and linguistics. However, automated data-analytics systems often have a difficult time with some of the more nuanced elements of human speech, such as sarcasm and irony — an issue that Spotter has apparently overcome to some degree, although company executives admit that their solution isn't perfect. (Duh.) Spotter isn't alone: IBM, Salesforce, and other IT vendors are hard at work on analytics software that can more perfectly determine when you're mouthing off, you little punks. In theory, sarcasm detection can help with customer service, and judging how well products are doing on the open market... and we all know it's going to work perfectly, right? Nothing could possibly go wrong with automated platforms built to assess the nuances of human speech."
I can't believe that I'm reading a comment that is so clearly uninformed like yours on Slashdot.
Every language has its tradeoffs. It's apparent that you've not only disregarded the benefits of OO languages, but that you've also failed to correctly identify their drawbacks. Put two equally competent developers up against each other, one in C and one in C#, and I'd put my money on the C# app being more reliable and stable out of the gate, and quite possibly more efficient as well, since optimization takes time. Anyone with any experience at all in C can tell you about times that they've forgotten to free up memory, failed to place a null terminator at the end of a string, or went out of bounds on an array (even worse: without it telling you that you did so)*, simply because it lacks safeguards to catch those (I still remember one particular bad memory leak I introduced in a text parser I was using to go through the data my grad school research group had pulled during our 6.3B page web crawl...let's just say that my colleagues who were using that server were not too happy with me...). So suggesting that C is so much more reliable and that OO languages should be avoided "with a passion" is really only true in the sort of frictionless, vacuum world that physicists dream of, where developers never write bugs and things work on the first try.
Also, if you're making broad, sweeping generalizations about efficiency and how OO languages shouldn't be used, I'm guessing you're also unfamiliar with JIT compiling and the advancements that have been made on that front. You might want to look into it.
And if you're going to dismiss an entire class of languages on the grounds that they're less stable and efficient, then I feel compelled to point out that you should be using FORTRAN instead of C, since it's what all of the serious number crunching apps use (in fact, it was the first language I used professionally, back when I interned at Lockheed Martin for a summer, working on meteorological software used by NASA). Or, hell, why stop at FORTRAN? You should use machine code! By your standard, it's far more stable, efficient, and reliable than C, so it must be better! Who needs inefficient abstractions like loops when we have jump statements? Not you, right?
* A quick note: I'm not suggesting that all of these bugs are inherently fixed in OO languages, just that they are examples of the sorts of issues one commonly encounters in C that many (though not all) OO languages happen to avoid. Quite obviously, you could change the garbage collector to address that first bug without having to use an OO language, for instance, but many OO languages just so happen to have more advanced garbage collectors that address that problem rather well.