A review by someone who chose a different product is likely to be more valuable in choosing a product, assuming that person can articulate why he/she chose the other product, because that means the person knows not only this product, but also other products on the market. By contrast, someone who chose the product he/she is reviewing has a very high probability of being familiar with only that product and not any others on the market. Given a choice, I'd take reviews from non-owners over reviews by owners any day.
That's some pretty convoluted logic there, at least by my reckoning. If the user hasn't purchased the item in question, how exactly are you assuming he/she knows the product sufficiently that they're in a suitable position to review it, judging it's strengths and weaknesses? Can you assume they're not simply biased against a completing product they happen to own, for example? You're telling me that, for example, a Playstation 4 owner is in a better position to review an Xbox one, and we should trust their judgment as being more objective and fair than someone who actually purchased an Xbox one?
Also, if the product sucks, assuming the product isn't so bad that folks return it, people who own the product are more likely to feel the need to give it better reviews to justify the money they spent.
Wow... again. I'd bet that people who have purchased a product and are unhappy with it are actually *more* likely to review it harshly in an effort to punish the company for their poor product, and at least warn others against a crappy purchase. There are some old marketing saws that say similar things, I believe. At the very least, that holds true for me. I've purchased a couple of stinkers, and I made damn sure to leave a one or two star review, and explain in detail *why* it was such a terrible product.
Heh, your expectations of human nature runs about 180 degrees opposite of mine, for whatever reason.
Instead we are stuck with UTF16 as the default, and even the larger encodings use modifiers etc.
Who's "we"? Windows and Mac use UTF-16, while Linux and the web use the vastly superior UTF-8. Internally, assuming you're in a language that supports it like C++, you can actually use any encoding you want - it just means you need to transcode strings at API boundaries. You'd have to do this for one or more of your target platforms anyhow if you're writing cross-platform code (all three major PC OSes).
A lot of Windows programmers think "Unicode == UTF-16", which is not the case at all. In my own applications, I use UTF-8 as the native format, even on Windows and Mac. When I need to render glyphs (I write games, so I have my own low-level bitmapped based glyph rendering system), I convert them to UTF-32 code points for simple mapping. If you want to, nothing is stopping you from using UTF-32 internally as you'd seem to prefer, but I've found there's really no need, because you can always convert between formats on the fly as needed.
Yet every story has to be embellished like this. It's crap journalism
Tell me exactly what's being embellished here. I saw nothing about "unicorns" in the article or summary - just a humorous poke by a slashdot poster in reference to, yes, a story that was later debunked. But good heavens, NK still provides such great material that *hasn't* been refuted! For instance:
The dictatorship is known for making outlandish claims about its own prowess. The state claims that Kim Jong Il invented the hamburger and had magical powers which meant he did not need to use the toilet.
They also claim that he was born atop a North Korean mountain prompting a double rainbow and new star to spontaneously appear. Unfortunately for the state, records show that he was born in Siberia.
People like this live in a bubble, where no one in the entire country is allowed to call "bullshit" about obvious lies for fear of their well-being, so they think they can spout the same nonsense internationally and not have it mocked for the ridiculousness that it is.
Technically speaking, Unicode represents characters, not glyphs, so it's a matter of whether you consider the different language-specific visual representations of those characters to be distinct characters themselves, not simply visual differences of the same character (which most native speakers would, of course). Obviously, since most text would not bother to interject a Chinese version of a character into an otherwise Japanese text, this works out reasonably well in most situations, so long as you're indicating which language you're reading (something Unicode was not supposed to need, right?). However, this multiple mapping creates significant difficulty for scholarly work in particular, which may need to reference individual glyphs of various countries within a single piece of work - something that was not easily done thanks to the way the characters were unified. Or for instance, say you have a small section of Japanese text inside a larger Chinese document, or vice versa, as you might see on the web... oops, sorry.
In version 3.2, Unicode introduced the ability to select among visual variants to help solve this issue, but I think many people feel this is a bandaid (and apparently poorly supported) solution over a poorly thought-out decision in the first place, made by representatives from North America corporations (with Chinese advisers) who didn't appreciate or care about the problems they were creating with this decision for other countries like Japan and Korea. It also may be the case that there was pressure to fit the codes into a 16-bit space, which was an initial goal until it was recognized to be completely infeasible to do so, but is pointless with the large encoding space we have today of a million character code points. Note that separate encodings would take 120,000 points instead of 21,000, which while significant, could easily be accommodated even today.
I have no idea what other flaws AmiMoJo is talking about, but the gripes with the way the committee handled Han unification was legitimate.
While the claims about its effectiveness as a treatment for cancer are dubious, North Korea is not the pantomime many in the west seem to think it is. I'd also hasten to point out how many bullshit medical claims are made on a daily basis in the west, so this isn't even unique.
Let's keep the propaganda and borderline racism off Slashdot.
The claims are "dubious"? They're fucking laughable. North Korea is... pantomime? That wasn't the word I was thinking of. Brutal? Repressive? Backwards? Ridiculous? Yes to all of those, but only when talking about the leadership. Their people are starving, they can barely keep the lights on, yet they developed a nuke and launcher system.
As far as being racist... I have nothing but respect for Koreans, and in fact, used to work for a South Korean company. No one mocks North Korea (again, just the leadership) because they're Korean. We mock them because they're making a mockery of the lives and well-being their own citizens, and it's a fucking tragedy, really, because who knows how much more strong and vibrant Korea would be were they all free and prosperous like the South.
Well, no, it's not, they're still working on that bit meaning that you get to keep upgrading all your programs to use newer and ever bigger libraries supporting more complex rules regularly. It's not stable.
Nonsense. The Unicode encoding formats are stable, and have been for a very long time. New character are added all the time, but the underlying OS and it's fonts are typically upgraded to support these, and so most programs need to do absolutely nothing once their support is in place. The vast, vast majority of applications that support Unicode don't actually explicitly need to use those "official" Unicode libraries (which are monstrously complex), because all modern operating systems provide most of the support they need. For simple conversions, there are a number of excellent free and simple-to-use libraries (many languages have standard libraries available), or you can just use OS-specific versions, or a number of very easy-to-use free and open-source libraries.
If you're concerned about size, just use UTF-8. There's no need to "switch encodings on the fly", because that's what variable-width encodings already do for you. And the vast majority of common encodings, even in Asian languages, are only 16-bits, not 24 or 32. The issue of inefficiency of text size with Asian languages is greatly exaggerated, and becoming less and less relevant anyhow with our machines with gigabytes of RAM and processors efficient enough to compress and decompress text on the fly. BTW, you can do that just fine even in Microsoft and Apple environments. It just means you need to transcode from UTF-8 to UTF-16 or back again at any API boundary that takes text, and this is fairly simple to do. I've written my own cross-platform code this way because UTF-8 is a much easier encoding to work with internally IMO.
I don't think anyone would try to argue that Unicode is a perfect solution, but it's a damn sight better than what we used to have. Your comparison to USB is pretty good, in fact. Ask just about any PC user what they'd prefer - modern USB devices or the old system of parallel, serial, PS/2, and joystick ports. Whatever faults USB has, it's a hell of an improvement over the old system.
Don't let the door hit you in the ass on the way out to the pasture of obsolescence. The rest of us will continue to use Unicode, which, despite some flaws, such as their mess-up with Han Unification, does a pretty good job at solving the problem of language intercommunication. If anyone thinks they can do a better job (not counting reverting back to English-only ASCII), have at it.
So go ahead and use ASCII, don't type in any of those dern foreign charcturs, and pretend you're back in the happy past where we had a mess of incompatible standards, and no way to easily discern which of the many possible encodings was actually used, resulting in the scrambled text we always used to see (notice you *don't* actually see that much anymore?). And most software just ignored the rest of the non-English-speaking world anyhow because of that mess.
Personally, I'm thankful people are willing to take on largely thankless (and mind-numbing to most of us) tasks such as these.
A bytecode format is easy to maintain backward compatibility with, and because it's bytecode, not native code, it's fairly easy to enforce proper sandboxing at a pretty low level. It could be argued that this is actually what JavaScript and the security disaster that is the Java plugin should have been from the beginning.
Like with the.NET CLR (Common Language Runtime), you can actually use just about any language you want to that's designed to compile down to this common runtime (or in this case bytecode format). This means you aren't stuck with using only Javascript or a language that translates to Javascript. Hell, if Javascript can be compiled to this bytecode format, then web browsers can actually depreciate the JavaScript-specific runtimes in favor of a generic bytecode runtime (although that would be pretty distant).
It's pretty easy to think of several advantages to a more generic bytecode versus a specific language. The obvious downside is another round of security issues with another way to run script code from a website on a person's local machine. No matter how carefully implemented this is, there *are* going to be new security issues found and exploited. The good news is that with a common bytecode format, you really only need to solve most of those issues *once*, and not for every new supported language or plugin.
There's a good argument for remakes or sequels for many game properties. As much as people love to stick their nose up in the air in disdain at remakes and sequels (and yeah, sometimes I'm guilty of that), in truth, fans of a world or character they've enjoyed in the past are also likely to appreciate the chance to revisit those same worlds or characters on a modern platform.
Besides, let's face it, while they're still enjoyable to play, many early videogames haven't exactly aged all that gracefully. It's not just about shinier graphics, although that's certainly a factor of course. There are a lot of examples of downright clunky gameplay mechanics that we once thought were acceptable, but wouldn't put up with in a modern game. And oh lord, don't get me started on the state of voice acting in the first games that attempted to do so. Cringe-worth doesn't even begin to describe it, mostly because earlier developers thought it would be a great idea for people in the studio or friends and family to do the voice-acting.
There are also some examples of fantastic games that had nothing wrong with them at a fundamental level, but would be great to see in a modern sequel. Star Wars Battlefront is a great example of this. Another good example (sticking with the Star Wars universe as an example) would be the X-Wing/Tie Fighter series of games, although as a PC franchise, I'm far less hopeful we'd ever see a remake of that one. It has nothing to do with the original being inadequate in any way given technology of the time, but a lot of fans of the original would love to see what could be done with modern state-of-the-art capabilities.
It's the same analysis that lead people to conclude that because mobile gaming was on the rise, console gaming was therefore going to disappear. And the same logic let pundits to conclude that we're now in a "post-PC" world. The ascendance of one market does cause a shift in proportions of other parts of the market, but doesn't necessarily lead to a complete collapse. Even if.NET is in overall decline, I think that speaks to the larger decline, proportionally speaking, of the desktop PC market. However, Windows still *completely* dominates that market, so.NET/C# will likely remain strong there.
So, I'd say if we're talking about a "decline", that makes sense to me. If we're talking about a "collapse", that's absurd. Even if no one except Windows developers were using it, it would still not go away completely, because that's why the.NET platform and C# language were invented in the first place... to simplify Windows development.
C++ is a great language, but it takes a huge amount of effort to deal with memory management issues and such crap. C++ is also a language filled with lots of pitfalls. It is incredibly easy to write bad C++ code, and you really need to study the language itself for a few years just to be a truly competent coder.
While the rest of your statements are true enough, C++ (as of C++ 11) is pretty easy to use in terms of memory management. As long as you use smart pointers and proper RAII techniques, memory management is almost as automatic as with a managed language. My new game / game engine was written in 100% modern C++, and I've had incredibly few memory issues. For the most part, as long as I properly manage object lifetime, I don't even have to think about memory management, which is quite a relief even for this long time C++ programmer.
Unfortunately, there's a *huge* amount of legacy code out there that uses a lot of old and unsafe techniques that make it so difficult to use correctly and safely. It's going to be quite a few more years before we see a proper transition of these techniques, but if C++ has anything going for it, it's stubborn longevity.
Anyone who thinks.NET is in danger of being abandoned is delusional. It's a core technology for MS at this point, and there's about as much chance of it being abandoned as the Windows API being abandoned. The fact that MS is actively promoting.NET as a cross-platform solution would also argue against the notion that it will be abandoned in the foreseeable future.
I get your point, but Visual Basic and the.NET platform aren't even in the same league.
No, that's absurd..NET will be around for decades to come. There's too much infrastructure built on top of it, and there's no reason for Microsoft to abandon it, since it's still the modern way to write Windows applications, for both app store & full desktop applications. As long as Windows is around in its current incarnation,.NET will be around as well. Whether it will be around on *other* platforms is up for debate, but I suspect that it will at least be maintained at it's current level.
BTW, COM is still supported, and you could write a new VB6 app even today if you really wanted to. And HTML5/JavaScript killed Silverlight, not MS. Hell, it killed *Flash*, so it's a bit hard to blame that on MS.
I'm not defending Microsoft, nor justifying all their mistakes or missteps. I said they've *courted* developers, not always treated them perfectly. Do you know you can be immune from issues like that? Don't always go chasing after the newest, greatest technology, no matter how sparkling fresh and cool the MS evangelists make it sound. Maybe it's best to stick with tried and true for a while if you're betting your whole business on something.
.NET is not a new thing at this point. It's been around for over a decade now, and it's pretty obviously it's going to hang around for a few more decades. In fact, thanks to Mono, it's actually out of Microsoft's hands whether they want to continue supporting it or not, because they don't *control* Mono. For people that have been burned by Microsoft abandoning support for products, they should feel a lot safer with Mono, I'd think.
Patent issues? What would Microsoft have to gain by suing someone for using their own technology? That makes about as much sense as Oracle suing a developer for using Java. It's an utterly nonsensical argument, as Microsoft is officially and releasing.NET as open source, and has indicated their support of Mono and Xamarin as well.
Personally, I feel a lot better when I understand a company's motivation. As far as I can figure, Microsoft is interested in keeping Windows relevant, and they can help do this by ensuring developers can use Windows as a development springboard for targeting other platforms. This keeps those developers in the Microsoft ecosystem, even if they have to acknowledge that fewer people are living in a Windows-only world - *especially* in mobile. The alternative would be that developers would have to turn to other development tools on other platforms, and they might find another cross platform solution that leaves Windows as an "also-ran", marginalizing it as a development platform, which in turn might lead to the erosion of Windows as a *user* platform.
Microsoft has always been fairly smart about courting developers with excellent tools and development platforms, and making it quite easy to build applications for Windows. As far as I can tell, this is no different - it's just that Microsoft has finally acknowledged that open source and multi-platform development is critical in today's world, and they're going their best now to play catch-up in this field. This doesn't suddenly make them nice guys, but it's not in their business interest to start attacking developers - the people that they're actively trying to court with these latest strategies.
PS3s are still better for this sort of thing. Or PS4s, or Xbones. Or your PC. Any of those devices have roughly a thousand times the computational power it typically needs when idling, or doing whatever lightweight tasks that take up most of it's time.
The only way this would make any remote sort of sense is if you have far, far more IoT devices in your house, enough to where you can outperform your PC or videogame console. I can't even imagine what you'd need all that sort of computational horsepower for in all those devices. It would be stupidly energy inefficient to over-power everything like that.
seti@home and BOINC already have this covered using *practical* technology.
In debug mode, that runtime check is not guaranteed to be optimized out, even if it's not executed, but in my version it certainly would, because it's performed by the preprocessor. All a normal if() check with a constant is doing is obscuring the fact that you're removing code at compile time. It's also likely to generate a compiler warning of "unreachable code" as well. Just because it's in the Linux kernel doesn't mean it's necessarily a good practice, I'm sorry to say.
Anyhow, I'm not saying #ifdef'd code isn't useful or has no place. I use it myself to switch diagnostic code on and off, or to completely remove profiling code in a release build, for instance. And it's great for wrapping new features so they can be instantly compiled out of the code for test purposes if needed. But for the most part, if you're scattering platform-specific #ifdefs throughout your code, that's generally not considered a very clean way to approach the problem - at least in my opinion.
What's your opinion of C#/Xamarin for cross-platform apps that don't require a lot of client-side heavy lifting?
I have no experience with it specifically (so take my advice with a grain of salt), but I do have quite a bit of C# experience. I think it's a pretty clean, readable language for the most part, so I certainly wouldn't be opposed to going that direction if I had a project that could make use of it. My feeling is that programmers are more likely to be more productive writing C# than C++. Personally, (I'm a videogame developer) I write all my game development tools in C#, while my game and engine code are C++, if that tells you anything. Many professional videogame development houses do the same.
To be honest, a big part of it is also what the project developers are comfortable with as well. If they're all C++ experts, it might not be worth switching to C#. If you've already got some C# experience (or even Java), Xamarin/C# might not be a bad way to go. C# is shaping up to be a very portable language (at least the core language and libraries) thanks not only to Xamarin, but also Microsoft's recent efforts at making it all open source.
One example I can think of: Head coach of the Seattle Seahawks Pete Carroll, winner of one out of two SuperBowl appearances in the past two years. He's obviously doing something right in terms of leadership. By all reports, he's a laid-back guy, likes to make the organization fun for the players, and doesn't subscribe to the "yelling, blustering" type of coaching style that's so prevalent. Your personality traits are made public in such a high-profile position, so I don't think there's much of a question as to the veracity of these reports. A lot of pundits said that sort of thing might work in college football, but wouldn't work in the pros.
Obviously, anyone in charge of an organization has to mean business at times and get serious, but being an abusive asshole isn't a pre-requisite for being successful. I think there may be a *correlation* between that personality type and the people who are driven to make it to the top and be successful, but it's not universal by any means.
Maybe so, but C++ is actually a smart way to go if you need to write cross-platform code, especially now that C++ 11/14 has fixed a lot of the most troublesome and problem-prone aspects of the language. Other than C#/Xamarin, I can't think of another language that would be easily portable across all platforms, and C++ certainly has a performance edge for any sort of heavy lifting that has to be done on the client.
C++ compiles natively on Android, so I *suspect* they're using that translation to automatically create an interop layer at the SDK bounaries. I don't know why they'd write in C++ only to translate the entire thing to Java. There might have been something subtle there lost in translation when talking to the media about this. Otherwise, yeah, I'd agree that this would make me nervous as well. I tend to avoid auto-generated code myself for exactly this reason - any bugs in it would be maddeningly difficult to find and fix.
Generally, you'd hide that sort of code behind some abstract interfaces. You don't need an #ifdef if you replace an entire.cpp file per OS target. My entire game engine, written in cross-platform C++, uses very few #ifdefs to divide between platforms (Windows/Mac/Linux).
It's also clear the author doesn't really understand what modern C++ actually looks like because of this statement:
It is less widely used, however, for mobile platforms, given that it can be a challenge to program in because it forces the developer to deal with memory management and other subtle nuances in abstraction.
This simply isn't true any more for code written using modern (i.e. C++ 11/14) techniques. Using smart pointers (automatic reference counting) and proper RAII techniques means that you never really have to worry about explicitly managing your memory - you simply need to manage your object lifetime, and when all references are released, the memory goes away as well. In fact, while managed memory may be slightly superior in terms of ease of use, I've found smart pointers + RAII to be arguably *superior* for managing *other* types of system resources, because you can guarantee exactly when they'll be released (via a destructor).
Also, I'm a bit confused about this:
From Dropbox, the company borrowed a piece of software called Djinni, which converts C++ data models into Java code, the runtime language for Android.
You can compile C++ natively for Android, so I suspect they're talking about using Djinni to automatically create an interop layer between their C++ code and Java, which would be handy for accessing a large portion of the SDK via Java. They also talked about how it's fairly easy to create an interop bridge between C++ and Objective-C, something I've also done with my own code.
People keep on about Apple dropping support for Objective-C, which seem ridiculous to me. A huge number of OS X's existing APIs are Objective-C based. And if nothing else, these are likely to remain for the next decade or two simply to maintain compatibility with today's apps, nearly ALL of whom are written in Objective-C. There are also a number of APIs Apple relies on that are C based as well, which requires either C/C++ or Objective-C to interface with. You seriously think Apple is going to replace OpenGL, OpenAL, and ALL their Objective-C based APIs as well? For what benefit? So they can drop support for a language that only requires a bit of maintenance work here and there, but otherwise is working just fine right now?
What's with people's obsession of killing off Objective-C just because there's a new language available for use? It makes zero sense to me. Do people think that Apple is somehow incapable of (gasp) supporting TWO languages for their platforms? And what about support for C or C++? Lots of that code still floating around as well.
No... Objective-C will very likely be supported for decades to come. Sure, the language will stagnate while Swift moves forward, and at some point it will be used purely for legacy purposes or to bridge Swift and C-based APIs like OpenGL, but the support will still be there.
Assuming we're talking about non-zero-day exploits (stuff that white hats reported in confidence), part of the issue is that actually releasing a patch tells black hats a lot about how to create an exploit, and this applies to both open source and non-open source, but with slightly different methodologies. It's fairly easy for black hats to reverse engineer a patch to determine exactly how you can now exploit unpatched systems. So, the clock starts ticking the moment the patch is released, essentially. Hence "Patch Tuesday", and "Exploit Wednesday".
If the patches are released as they're ready, then you're putting corporation IT departments into a near-continuous patch and test cycle. What happens if they're in the middle of some other project and a critical patch is issued? The monthly patch cycle gives them a bit of predictability so they can schedule products around this date.
Naturally, this doesn't apply to zero-day exploits/patches, especially those which are widely known about. The monthly cycle obviously works against zero day issues in terms of response time, but there's always the option of a temporary workaround, or even an out-of-band patch for extremely serious issues - and that isn't unprecedented.
Personally, I've got four machines to patch (two Windows, one Mac, one Linux), and didn't mean to imply otherwise. It's rather common knowledge that "patch Tuesday" was started by MS in order to make things more convenient for corporate customers, instead of releasing patches on an ad hoc schedule.
Slashdot Mirror
A review by someone who chose a different product is likely to be more valuable in choosing a product, assuming that person can articulate why he/she chose the other product, because that means the person knows not only this product, but also other products on the market. By contrast, someone who chose the product he/she is reviewing has a very high probability of being familiar with only that product and not any others on the market. Given a choice, I'd take reviews from non-owners over reviews by owners any day.
That's some pretty convoluted logic there, at least by my reckoning. If the user hasn't purchased the item in question, how exactly are you assuming he/she knows the product sufficiently that they're in a suitable position to review it, judging it's strengths and weaknesses? Can you assume they're not simply biased against a completing product they happen to own, for example? You're telling me that, for example, a Playstation 4 owner is in a better position to review an Xbox one, and we should trust their judgment as being more objective and fair than someone who actually purchased an Xbox one?
Also, if the product sucks, assuming the product isn't so bad that folks return it, people who own the product are more likely to feel the need to give it better reviews to justify the money they spent.
Wow... again. I'd bet that people who have purchased a product and are unhappy with it are actually *more* likely to review it harshly in an effort to punish the company for their poor product, and at least warn others against a crappy purchase. There are some old marketing saws that say similar things, I believe. At the very least, that holds true for me. I've purchased a couple of stinkers, and I made damn sure to leave a one or two star review, and explain in detail *why* it was such a terrible product.
Heh, your expectations of human nature runs about 180 degrees opposite of mine, for whatever reason.
Instead we are stuck with UTF16 as the default, and even the larger encodings use modifiers etc.
Who's "we"? Windows and Mac use UTF-16, while Linux and the web use the vastly superior UTF-8. Internally, assuming you're in a language that supports it like C++, you can actually use any encoding you want - it just means you need to transcode strings at API boundaries. You'd have to do this for one or more of your target platforms anyhow if you're writing cross-platform code (all three major PC OSes).
A lot of Windows programmers think "Unicode == UTF-16", which is not the case at all. In my own applications, I use UTF-8 as the native format, even on Windows and Mac. When I need to render glyphs (I write games, so I have my own low-level bitmapped based glyph rendering system), I convert them to UTF-32 code points for simple mapping. If you want to, nothing is stopping you from using UTF-32 internally as you'd seem to prefer, but I've found there's really no need, because you can always convert between formats on the fly as needed.
Yet every story has to be embellished like this. It's crap journalism
Tell me exactly what's being embellished here. I saw nothing about "unicorns" in the article or summary - just a humorous poke by a slashdot poster in reference to, yes, a story that was later debunked. But good heavens, NK still provides such great material that *hasn't* been refuted! For instance:
The dictatorship is known for making outlandish claims about its own prowess. The state claims that Kim Jong Il invented the hamburger and had magical powers which meant he did not need to use the toilet.
They also claim that he was born atop a North Korean mountain prompting a double rainbow and new star to spontaneously appear. Unfortunately for the state, records show that he was born in Siberia.
People like this live in a bubble, where no one in the entire country is allowed to call "bullshit" about obvious lies for fear of their well-being, so they think they can spout the same nonsense internationally and not have it mocked for the ridiculousness that it is.
CJK is supported, but the early Unicode committee unfortunately decided to "unify" the codepoints of characters with shared ancestry, even though they may be rendered differently in different language.
Technically speaking, Unicode represents characters, not glyphs, so it's a matter of whether you consider the different language-specific visual representations of those characters to be distinct characters themselves, not simply visual differences of the same character (which most native speakers would, of course). Obviously, since most text would not bother to interject a Chinese version of a character into an otherwise Japanese text, this works out reasonably well in most situations, so long as you're indicating which language you're reading (something Unicode was not supposed to need, right?). However, this multiple mapping creates significant difficulty for scholarly work in particular, which may need to reference individual glyphs of various countries within a single piece of work - something that was not easily done thanks to the way the characters were unified. Or for instance, say you have a small section of Japanese text inside a larger Chinese document, or vice versa, as you might see on the web... oops, sorry.
In version 3.2, Unicode introduced the ability to select among visual variants to help solve this issue, but I think many people feel this is a bandaid (and apparently poorly supported) solution over a poorly thought-out decision in the first place, made by representatives from North America corporations (with Chinese advisers) who didn't appreciate or care about the problems they were creating with this decision for other countries like Japan and Korea. It also may be the case that there was pressure to fit the codes into a 16-bit space, which was an initial goal until it was recognized to be completely infeasible to do so, but is pointless with the large encoding space we have today of a million character code points. Note that separate encodings would take 120,000 points instead of 21,000, which while significant, could easily be accommodated even today.
I have no idea what other flaws AmiMoJo is talking about, but the gripes with the way the committee handled Han unification was legitimate.
While the claims about its effectiveness as a treatment for cancer are dubious, North Korea is not the pantomime many in the west seem to think it is. I'd also hasten to point out how many bullshit medical claims are made on a daily basis in the west, so this isn't even unique.
Let's keep the propaganda and borderline racism off Slashdot.
The claims are "dubious"? They're fucking laughable. North Korea is... pantomime? That wasn't the word I was thinking of. Brutal? Repressive? Backwards? Ridiculous? Yes to all of those, but only when talking about the leadership. Their people are starving, they can barely keep the lights on, yet they developed a nuke and launcher system.
As far as being racist... I have nothing but respect for Koreans, and in fact, used to work for a South Korean company. No one mocks North Korea (again, just the leadership) because they're Korean. We mock them because they're making a mockery of the lives and well-being their own citizens, and it's a fucking tragedy, really, because who knows how much more strong and vibrant Korea would be were they all free and prosperous like the South.
Well, no, it's not, they're still working on that bit meaning that you get to keep upgrading all your programs to use newer and ever bigger libraries supporting more complex rules regularly. It's not stable.
Nonsense. The Unicode encoding formats are stable, and have been for a very long time. New character are added all the time, but the underlying OS and it's fonts are typically upgraded to support these, and so most programs need to do absolutely nothing once their support is in place. The vast, vast majority of applications that support Unicode don't actually explicitly need to use those "official" Unicode libraries (which are monstrously complex), because all modern operating systems provide most of the support they need. For simple conversions, there are a number of excellent free and simple-to-use libraries (many languages have standard libraries available), or you can just use OS-specific versions, or a number of very easy-to-use free and open-source libraries.
If you're concerned about size, just use UTF-8. There's no need to "switch encodings on the fly", because that's what variable-width encodings already do for you. And the vast majority of common encodings, even in Asian languages, are only 16-bits, not 24 or 32. The issue of inefficiency of text size with Asian languages is greatly exaggerated, and becoming less and less relevant anyhow with our machines with gigabytes of RAM and processors efficient enough to compress and decompress text on the fly. BTW, you can do that just fine even in Microsoft and Apple environments. It just means you need to transcode from UTF-8 to UTF-16 or back again at any API boundary that takes text, and this is fairly simple to do. I've written my own cross-platform code this way because UTF-8 is a much easier encoding to work with internally IMO.
I don't think anyone would try to argue that Unicode is a perfect solution, but it's a damn sight better than what we used to have. Your comparison to USB is pretty good, in fact. Ask just about any PC user what they'd prefer - modern USB devices or the old system of parallel, serial, PS/2, and joystick ports. Whatever faults USB has, it's a hell of an improvement over the old system.
Don't let the door hit you in the ass on the way out to the pasture of obsolescence. The rest of us will continue to use Unicode, which, despite some flaws, such as their mess-up with Han Unification, does a pretty good job at solving the problem of language intercommunication. If anyone thinks they can do a better job (not counting reverting back to English-only ASCII), have at it.
So go ahead and use ASCII, don't type in any of those dern foreign charcturs, and pretend you're back in the happy past where we had a mess of incompatible standards, and no way to easily discern which of the many possible encodings was actually used, resulting in the scrambled text we always used to see (notice you *don't* actually see that much anymore?). And most software just ignored the rest of the non-English-speaking world anyhow because of that mess.
Personally, I'm thankful people are willing to take on largely thankless (and mind-numbing to most of us) tasks such as these.
A bytecode format is easy to maintain backward compatibility with, and because it's bytecode, not native code, it's fairly easy to enforce proper sandboxing at a pretty low level. It could be argued that this is actually what JavaScript and the security disaster that is the Java plugin should have been from the beginning.
Like with the .NET CLR (Common Language Runtime), you can actually use just about any language you want to that's designed to compile down to this common runtime (or in this case bytecode format). This means you aren't stuck with using only Javascript or a language that translates to Javascript. Hell, if Javascript can be compiled to this bytecode format, then web browsers can actually depreciate the JavaScript-specific runtimes in favor of a generic bytecode runtime (although that would be pretty distant).
It's pretty easy to think of several advantages to a more generic bytecode versus a specific language. The obvious downside is another round of security issues with another way to run script code from a website on a person's local machine. No matter how carefully implemented this is, there *are* going to be new security issues found and exploited. The good news is that with a common bytecode format, you really only need to solve most of those issues *once*, and not for every new supported language or plugin.
There's a good argument for remakes or sequels for many game properties. As much as people love to stick their nose up in the air in disdain at remakes and sequels (and yeah, sometimes I'm guilty of that), in truth, fans of a world or character they've enjoyed in the past are also likely to appreciate the chance to revisit those same worlds or characters on a modern platform.
Besides, let's face it, while they're still enjoyable to play, many early videogames haven't exactly aged all that gracefully. It's not just about shinier graphics, although that's certainly a factor of course. There are a lot of examples of downright clunky gameplay mechanics that we once thought were acceptable, but wouldn't put up with in a modern game. And oh lord, don't get me started on the state of voice acting in the first games that attempted to do so. Cringe-worth doesn't even begin to describe it, mostly because earlier developers thought it would be a great idea for people in the studio or friends and family to do the voice-acting.
There are also some examples of fantastic games that had nothing wrong with them at a fundamental level, but would be great to see in a modern sequel. Star Wars Battlefront is a great example of this. Another good example (sticking with the Star Wars universe as an example) would be the X-Wing/Tie Fighter series of games, although as a PC franchise, I'm far less hopeful we'd ever see a remake of that one. It has nothing to do with the original being inadequate in any way given technology of the time, but a lot of fans of the original would love to see what could be done with modern state-of-the-art capabilities.
It's the same analysis that lead people to conclude that because mobile gaming was on the rise, console gaming was therefore going to disappear. And the same logic let pundits to conclude that we're now in a "post-PC" world. The ascendance of one market does cause a shift in proportions of other parts of the market, but doesn't necessarily lead to a complete collapse. Even if .NET is in overall decline, I think that speaks to the larger decline, proportionally speaking, of the desktop PC market. However, Windows still *completely* dominates that market, so .NET/C# will likely remain strong there.
So, I'd say if we're talking about a "decline", that makes sense to me. If we're talking about a "collapse", that's absurd. Even if no one except Windows developers were using it, it would still not go away completely, because that's why the .NET platform and C# language were invented in the first place... to simplify Windows development.
C++ is a great language, but it takes a huge amount of effort to deal with memory management issues and such crap. C++ is also a language filled with lots of pitfalls. It is incredibly easy to write bad C++ code, and you really need to study the language itself for a few years just to be a truly competent coder.
While the rest of your statements are true enough, C++ (as of C++ 11) is pretty easy to use in terms of memory management. As long as you use smart pointers and proper RAII techniques, memory management is almost as automatic as with a managed language. My new game / game engine was written in 100% modern C++, and I've had incredibly few memory issues. For the most part, as long as I properly manage object lifetime, I don't even have to think about memory management, which is quite a relief even for this long time C++ programmer.
Unfortunately, there's a *huge* amount of legacy code out there that uses a lot of old and unsafe techniques that make it so difficult to use correctly and safely. It's going to be quite a few more years before we see a proper transition of these techniques, but if C++ has anything going for it, it's stubborn longevity.
Anyone who thinks .NET is in danger of being abandoned is delusional. It's a core technology for MS at this point, and there's about as much chance of it being abandoned as the Windows API being abandoned. The fact that MS is actively promoting .NET as a cross-platform solution would also argue against the notion that it will be abandoned in the foreseeable future.
I get your point, but Visual Basic and the .NET platform aren't even in the same league.
No, that's absurd. .NET will be around for decades to come. There's too much infrastructure built on top of it, and there's no reason for Microsoft to abandon it, since it's still the modern way to write Windows applications, for both app store & full desktop applications. As long as Windows is around in its current incarnation, .NET will be around as well. Whether it will be around on *other* platforms is up for debate, but I suspect that it will at least be maintained at it's current level.
BTW, COM is still supported, and you could write a new VB6 app even today if you really wanted to. And HTML5/JavaScript killed Silverlight, not MS. Hell, it killed *Flash*, so it's a bit hard to blame that on MS.
A "shitty language"? Which language would that be? C#, Basic, F#, IronPython, COBOL, Perl, Java, Scala, Boo...?
I'm not defending Microsoft, nor justifying all their mistakes or missteps. I said they've *courted* developers, not always treated them perfectly. Do you know you can be immune from issues like that? Don't always go chasing after the newest, greatest technology, no matter how sparkling fresh and cool the MS evangelists make it sound. Maybe it's best to stick with tried and true for a while if you're betting your whole business on something.
.NET is not a new thing at this point. It's been around for over a decade now, and it's pretty obviously it's going to hang around for a few more decades. In fact, thanks to Mono, it's actually out of Microsoft's hands whether they want to continue supporting it or not, because they don't *control* Mono. For people that have been burned by Microsoft abandoning support for products, they should feel a lot safer with Mono, I'd think.
Patent issues? What would Microsoft have to gain by suing someone for using their own technology? That makes about as much sense as Oracle suing a developer for using Java. It's an utterly nonsensical argument, as Microsoft is officially and releasing .NET as open source, and has indicated their support of Mono and Xamarin as well.
Personally, I feel a lot better when I understand a company's motivation. As far as I can figure, Microsoft is interested in keeping Windows relevant, and they can help do this by ensuring developers can use Windows as a development springboard for targeting other platforms. This keeps those developers in the Microsoft ecosystem, even if they have to acknowledge that fewer people are living in a Windows-only world - *especially* in mobile. The alternative would be that developers would have to turn to other development tools on other platforms, and they might find another cross platform solution that leaves Windows as an "also-ran", marginalizing it as a development platform, which in turn might lead to the erosion of Windows as a *user* platform.
Microsoft has always been fairly smart about courting developers with excellent tools and development platforms, and making it quite easy to build applications for Windows. As far as I can tell, this is no different - it's just that Microsoft has finally acknowledged that open source and multi-platform development is critical in today's world, and they're going their best now to play catch-up in this field. This doesn't suddenly make them nice guys, but it's not in their business interest to start attacking developers - the people that they're actively trying to court with these latest strategies.
PS3s are still better for this sort of thing. Or PS4s, or Xbones. Or your PC. Any of those devices have roughly a thousand times the computational power it typically needs when idling, or doing whatever lightweight tasks that take up most of it's time.
The only way this would make any remote sort of sense is if you have far, far more IoT devices in your house, enough to where you can outperform your PC or videogame console. I can't even imagine what you'd need all that sort of computational horsepower for in all those devices. It would be stupidly energy inefficient to over-power everything like that.
seti@home and BOINC already have this covered using *practical* technology.
Why not just use the standard:
#ifdef COOL_FEATURE_INSTALLED
#endif
In debug mode, that runtime check is not guaranteed to be optimized out, even if it's not executed, but in my version it certainly would, because it's performed by the preprocessor. All a normal if() check with a constant is doing is obscuring the fact that you're removing code at compile time. It's also likely to generate a compiler warning of "unreachable code" as well. Just because it's in the Linux kernel doesn't mean it's necessarily a good practice, I'm sorry to say.
Anyhow, I'm not saying #ifdef'd code isn't useful or has no place. I use it myself to switch diagnostic code on and off, or to completely remove profiling code in a release build, for instance. And it's great for wrapping new features so they can be instantly compiled out of the code for test purposes if needed. But for the most part, if you're scattering platform-specific #ifdefs throughout your code, that's generally not considered a very clean way to approach the problem - at least in my opinion.
What's your opinion of C#/Xamarin for cross-platform apps that don't require a lot of client-side heavy lifting?
I have no experience with it specifically (so take my advice with a grain of salt), but I do have quite a bit of C# experience. I think it's a pretty clean, readable language for the most part, so I certainly wouldn't be opposed to going that direction if I had a project that could make use of it. My feeling is that programmers are more likely to be more productive writing C# than C++. Personally, (I'm a videogame developer) I write all my game development tools in C#, while my game and engine code are C++, if that tells you anything. Many professional videogame development houses do the same.
To be honest, a big part of it is also what the project developers are comfortable with as well. If they're all C++ experts, it might not be worth switching to C#. If you've already got some C# experience (or even Java), Xamarin/C# might not be a bad way to go. C# is shaping up to be a very portable language (at least the core language and libraries) thanks not only to Xamarin, but also Microsoft's recent efforts at making it all open source.
One example I can think of: Head coach of the Seattle Seahawks Pete Carroll, winner of one out of two SuperBowl appearances in the past two years. He's obviously doing something right in terms of leadership. By all reports, he's a laid-back guy, likes to make the organization fun for the players, and doesn't subscribe to the "yelling, blustering" type of coaching style that's so prevalent. Your personality traits are made public in such a high-profile position, so I don't think there's much of a question as to the veracity of these reports. A lot of pundits said that sort of thing might work in college football, but wouldn't work in the pros.
Obviously, anyone in charge of an organization has to mean business at times and get serious, but being an abusive asshole isn't a pre-requisite for being successful. I think there may be a *correlation* between that personality type and the people who are driven to make it to the top and be successful, but it's not universal by any means.
Maybe so, but C++ is actually a smart way to go if you need to write cross-platform code, especially now that C++ 11/14 has fixed a lot of the most troublesome and problem-prone aspects of the language. Other than C#/Xamarin, I can't think of another language that would be easily portable across all platforms, and C++ certainly has a performance edge for any sort of heavy lifting that has to be done on the client.
C++ compiles natively on Android, so I *suspect* they're using that translation to automatically create an interop layer at the SDK bounaries. I don't know why they'd write in C++ only to translate the entire thing to Java. There might have been something subtle there lost in translation when talking to the media about this. Otherwise, yeah, I'd agree that this would make me nervous as well. I tend to avoid auto-generated code myself for exactly this reason - any bugs in it would be maddeningly difficult to find and fix.
Generally, you'd hide that sort of code behind some abstract interfaces. You don't need an #ifdef if you replace an entire .cpp file per OS target. My entire game engine, written in cross-platform C++, uses very few #ifdefs to divide between platforms (Windows/Mac/Linux).
It's also clear the author doesn't really understand what modern C++ actually looks like because of this statement:
It is less widely used, however, for mobile platforms, given that it can be a challenge to program in because it forces the developer to deal with memory management and other subtle nuances in abstraction.
This simply isn't true any more for code written using modern (i.e. C++ 11/14) techniques. Using smart pointers (automatic reference counting) and proper RAII techniques means that you never really have to worry about explicitly managing your memory - you simply need to manage your object lifetime, and when all references are released, the memory goes away as well. In fact, while managed memory may be slightly superior in terms of ease of use, I've found smart pointers + RAII to be arguably *superior* for managing *other* types of system resources, because you can guarantee exactly when they'll be released (via a destructor).
Also, I'm a bit confused about this:
From Dropbox, the company borrowed a piece of software called Djinni, which converts C++ data models into Java code, the runtime language for Android.
You can compile C++ natively for Android, so I suspect they're talking about using Djinni to automatically create an interop layer between their C++ code and Java, which would be handy for accessing a large portion of the SDK via Java. They also talked about how it's fairly easy to create an interop bridge between C++ and Objective-C, something I've also done with my own code.
People keep on about Apple dropping support for Objective-C, which seem ridiculous to me. A huge number of OS X's existing APIs are Objective-C based. And if nothing else, these are likely to remain for the next decade or two simply to maintain compatibility with today's apps, nearly ALL of whom are written in Objective-C. There are also a number of APIs Apple relies on that are C based as well, which requires either C/C++ or Objective-C to interface with. You seriously think Apple is going to replace OpenGL, OpenAL, and ALL their Objective-C based APIs as well? For what benefit? So they can drop support for a language that only requires a bit of maintenance work here and there, but otherwise is working just fine right now?
What's with people's obsession of killing off Objective-C just because there's a new language available for use? It makes zero sense to me. Do people think that Apple is somehow incapable of (gasp) supporting TWO languages for their platforms? And what about support for C or C++? Lots of that code still floating around as well.
No... Objective-C will very likely be supported for decades to come. Sure, the language will stagnate while Swift moves forward, and at some point it will be used purely for legacy purposes or to bridge Swift and C-based APIs like OpenGL, but the support will still be there.
Well, I can give you at least one reason:
Assuming we're talking about non-zero-day exploits (stuff that white hats reported in confidence), part of the issue is that actually releasing a patch tells black hats a lot about how to create an exploit, and this applies to both open source and non-open source, but with slightly different methodologies. It's fairly easy for black hats to reverse engineer a patch to determine exactly how you can now exploit unpatched systems. So, the clock starts ticking the moment the patch is released, essentially. Hence "Patch Tuesday", and "Exploit Wednesday".
If the patches are released as they're ready, then you're putting corporation IT departments into a near-continuous patch and test cycle. What happens if they're in the middle of some other project and a critical patch is issued? The monthly patch cycle gives them a bit of predictability so they can schedule products around this date.
Naturally, this doesn't apply to zero-day exploits/patches, especially those which are widely known about. The monthly cycle obviously works against zero day issues in terms of response time, but there's always the option of a temporary workaround, or even an out-of-band patch for extremely serious issues - and that isn't unprecedented.
Personally, I've got four machines to patch (two Windows, one Mac, one Linux), and didn't mean to imply otherwise. It's rather common knowledge that "patch Tuesday" was started by MS in order to make things more convenient for corporate customers, instead of releasing patches on an ad hoc schedule.