Well, as a Microsoft employee I'm surprised you need to ask, but let's go...
Embrace
For trivial examples the Microsoft C++ compiler will work ok. The only real pragma needed here is one to prevent a spurious compiler warning, something like 1481 IIRC. The embrace phase is intended to assuage fears that developing for this platform means you won't have Standard C++.
Extend
Now for non-trivial examples we start to have to use #defines to get around optimizations that Microsoft bake into their compiler that will break standard-compliant code if you don't put the #define in (cite: http://msdn.microsoft.com/en-US/library/vstudio/bb531344.aspx; some are needed to be more standards compliant [good!], some are needed to regain standards compliant because the default implementation is not to be [bad:(]). Once these #defines are in a large codebase you are starting to get tied to the Microsoft compiler only unless you do a lot of additional work to add additional #ifdefs. Now this may not be intentional by the Microsoft C++ compiler team these days but at one point it absolutely was Microsoft's goal to tie developers into their technology and make it hard to get out (eg. all the extensions for Managed C++, now deprecated, sigh) - which means the legacy behavior of their compiler and current accepted techniques (eg. requiring special defines to get standard behavior back) are permitted by their design team (they should not be, non-standard behavior should be selected by specifying exceptions/defines, not the other way around).
Extinguish
Now we get to the bits of a program that are dependent on Windows (that is, required to make a program do anything useful on Windows). Here we get types and macros all over the place that are specific to Windows. Once you start using these your code is not going anywhere else. Now you may argue that this is the case on any platform but it is not so. Most other toolkits use Standard C++ types in their interfaces, they don't define a whole new set of types via macros. Now, this may be a legacy of old ways of doing Windows development (grrr Charles Simonyi, stealing FORTRAN abominations to make Hungarian Notation 'warts' that persist in C# today with the 'I' prefix [completely unnecessary and unhelpful when you refactor between classes and interfaces - but the drones cannot help themselves any more and can't see the badness of that style]). Anyway, my point is that you can't write modern C++ for Windows without injecting a whole lot of platform-dependencies into the code (eg. types, macros) that are far more than just the class interfaces of Windows-specific libraries. The original intent from Microsoft was to tie your code to the Windows platform (hence decrease the ability to move code to competitors). IMHO, it seems the Windows engineers are valiantly trying to remove the sins of the past (for which I give them full credit) - I even remember Microsoft announcing in the first releases of.NET that not only was C++ not standard but it would never be standard. Fortunately this attitude has changed, but we still remember the danger of depending on Microsoft C++ before. I aim never to be in a position where my code is tied to Microsoft again, hence my post warning others.
I just looked up the licensing terms (http://en.wikipedia.org/wiki/Microsoft_XNA). You have to be approved by Microsoft for commercial development and they get 30% of your revenue (plus you'll have to pay about the same in tax, depending where you are).
Commercially and technologically I'll think I'll stick with Java/JoGL(OpenGL) for now. Compared to using XNA I just increased my profits by 50% by making that one choice!:)
Oh yes, of course it is possible, but not really convenient. This is not a major issue, but for the posters pushing Visual Studio (and associated compiler) as if it was the best development environment since hot toast then I beg to differ.
> They are a niche and always have been, and are growing. I'd rather release a title for them than hope to be the next angry birds in the very noisy mobile environment.
That's me too. I'm developing for a high end niche (high-fidelity jet combat flight sim). However, I accept that this is not optimal from an economic point of view. Much of the commercial shrink-wrapped developers do consider the size of the market. I expect they are mostly sitting on the sidelines waiting to see if anything good happens (with everyone waiting, chicken and egg means not enough will happen to make an impact on the established players).
> C# and mono targets all platforms.
The language does, but the libraries for MS.NET are not interchangeable with Mono. This means using this is a bit more work (I'm using Java,JOAL,JoGL,JInput etc where the libraries mostly work cross-platform; so C# is a win compared to C++ but not compared to what I'm using at the moment).
"They" (the corporates) have seen how good Linux, Android and Free Software have become. They understand that leaving general purpose computing open would mean they cannot protect their current profit margins as software becomes more and more a commodity. Hence in order for them to "win" (have control over profit streams), they must make you "lose" (lose control over your own devices).
First came TPM in hardware. Fortunately users defeated this by making it optional and controlled by the device owner.
Apple were the first to successfully foist it on users and people were happy and smiled, "I love my Apple, I don't mind Apple having all the control for safety. What is there to worry about".
Now it is the turn of the Windows folks to lose control. Applications will pass through Microsoft censorship, hardware will be controlled by them, since only they will write (closed-source) software that can run on it. Still we will have people laughing a Richard Stallman's prescience, seeing this decades ago.
The Linux guys are being shut out now, since the Empire knows it must snuff out the Rebel Alliance to get complete control of the computing galaxy (and all the riches therein).
If you are still a believer in "walled gardens" ("I prefer convenience to control of my devices") then you ought to reconsider your views in light of these developments. For those that were always distrustful of the walled gardens, your fears are starting to come to pass, but at least you had the wisdom to recognize them. Now it is time to raise hue and cry about this. Corporates will listen to disgruntled customers if there are enough of them to threaten sales significantly. Blog your asses off about how Intel are doing the dirty on the tech community with their misleading statements.
No Microsoft Phone 8 (MP8) will only succeed if they convince developers that it is worthwhile developing for their platform. Hence all the spam on these Slashdot threads, among other places - they think we're too stupid to notice their manipulation.
Microsoft would actually interest developers if they made fantastic tools and a fantastic open platform (rather than these troll posts, thinking developers are the same as general 'sheeple'). In fact, they would guarantee success if their tools allowed you to develop for Android and iOS as first-class citizens of a development framework. This will never happen, so developers will look at MP8 and see that they can't leverage their existing code to easily get customers on that platform.
Purely rational developers will conclude that the platforms that should be supported (based on market share and current market share momentum) are Android and iOS, in that order. Once the Android code is complete the developer will look around what to do next, but since Microsoft's tools and tech is different the developer will conclude that it is probably not worth creating a whole new port for the fledgling user base of WP8. Going for iOS would bring in much more money (which is what it is all about, after all). Hence, WP8 faces a chicken-and-egg problem and is already vastly behind adoption and application availability in the market. Only a fanboi would get a Windows Phone these days hoping it will succeed where all the other Windows Phones failed (probability: WP8 will be just as spectacularly unsuccessful as its predecessors, it is just too late to market and has too much going against it to make up the lost ground against great competitors).
> Even if WP8 loses, Microsoft still wins in the end.
No. WP8 is likely to lose and that means Microsoft loses. It may get modest financial returns from its Android patent extortions but continuing to lose developer mindshare keeps weakening their grip on IT. A decade ago most developers only looked at Windows and Windows development tools, now they use all sorts of tools, tech (nb: better than Visual Studio) and Free Software/Open Source to rapidly develop for the web/mobile and desktop. Even the C# guys are somewhat shafted by the change of Microsoft's focus away from this (don't say they weren't told this would happen, Microsoft has to periodically change tools and tech to drive revenue - "In order for Microsoft to win, the customer must lose" holds true for Windows developers too).
If Android ever becomes a viable OS choice for the corporate desktop then Microsoft is in a world of hurt. Apple is already a viable choice (for professionals and executives) but not for the budget low-end stuff given to the proles. The huge profits Microsoft makes at the moment would not be sustainable long term once there arises true competition on the desktop again (and it will come eventually, it is a market ripe for competition and innovation where Microsoft is not providing any). The markets have long realised that significant growth is not really possible for Microsoft. Now there is real danger that with saturated markets and alternatives to the PC that Microsoft's revenues may actually go in to fundamental decline (rather than loss of revenue from the one-off $6 billion blunder from a bad acquisition).
With all these factors, one would probably do best not to bet your business on only using Microsoft-only technology (.NET), tools (Visual Studio), or platforms (Windows Phone). Better to reduce your risk and choose technology (such as Java [both OpenJDK and Android], GWT/vaadin, Standard C++, Objective-C), tools (Eclipse, Netbeans, IntelliJ, Emacs!) and platforms (Android, the Web) that will always be around provided there are enough users (that is, can't be killed on corporate whims and changes in strategic direction). That is the safe way to bet.
Yes, but does it support *ALL* of the C++ standard, or a Microsoft bastardized version (meaning to do anything useful you need Microsoft-specofic #pragmas and #defines)? If so, the Visual Studio is just another on-ramp to the Microsoft lock-in herd pen.
> Except to say that you go to the trouble of using JVisualVM to examine your running code Java for memory leaks - which makes sense in most applications but certainly not in a non-deterministic highly parallel application.
Ok, this is bullshit right here. With a highly non-deterministic application the first approach is to look at the statistical overall expectation behaviour of the application, for which this tool is awesomely suited.
> I use a lot of GPGPU for offloading massively parallel tasks, the language that drives it doesn't really matter so long as it has bindings for the GPGPU library (in my case mostly CUDA).
Ah, I get it now. Based (solely) on this your problem domain is massively parallizable. That is *not the same* as the massively multi-threaded program that I was talking about where you have different resources with different hard and soft real time requirements (and usually low-latency is what you are aiming for). I am surprised you didn't see the difference.
Ok, for the CUDA-esque problems what one tries to achieve is not usually not complex (in relative terms) it just has to have be speed up to fit within useful timeframes. I feel I understand this problem as I did planetary gravitational microlensing simulations that would have been awesome to use CUDA on, if it had existed at the time.
Ok, now for some libraries I'm not so fond of. Well, I find that even something as core as STL is quirky between implementations. I found I needed to spend a lot of effort #ifdefing to handle the differences when using different compilers (or versions of the compiler) - this is quite a fail to me (yes there are differences between JDK implementations and versions too [grrr the stupid breaking change in java.sql.DataSource in v7], but they are fair more avoidable and less effort to resolve IMHO). Then there are the unicode problems with all C++ libraries. Depending where the program was running was you could never tell whether your wchar_t would be able to accept asian character sets or not (since wchar_t was often shitty old UCS-2 rather than a proper unicode format; and if you are developing software for China you must meet GB18030 to meet government standards). For multi-threading pthreads was ok, but managing shared collections was a lot of work (unlike Doug Lea's genius poured into java.util.concurrent). Then there is OpenGL context creation that is a PITA to set up for each platform. Sure, there's GLUT etc for toy programs, but it is not well suited for programs where mostly you want a higher level of abstraction and integration with your UI toolkit but then occasionally want to get down to the nuts and bolts.
Ok, now I wanna do device I/O, hmm let's see, I get to use DirectInput or libusb and keep tabs on who is releasing resources when (and don't fsck it up or you'll be in a world of pain - your program will run for another five minutes before it crashes [hopefully not crashing the system due to bugs in the graphics driver; curse AMD's trouty bodies], then you get a core that you have to go through to work out where the problem was, which is not necessarily the same place the pointer violation occurred due to the unprotected memory). Oh, and once you have your program running and ported you have end users running it and find it won't run and you have to debug remotely but the standard library gives you no convenient stack trace of the calls made, and you can't just plug in to their running system and watch what their system is doing (hence my unseemly love for JVisualVM; strace is good but I don't always get shell access to use it on a client system). Then I really miss annotation-based libraries like JAXB and JPA2/Hibernate, I've not seen C++ libraries that are anywhere near as convenient. Also RTTI was not nearly as good as Reflection once I got used to the latter.
So, the more and more varied application domains led me to conclude that C++ is not the best choice for modern apps doing a lot of stuff outside C++'s limited standard library. The more com
> You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.
There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.
> So then why do you have so much difficulty writing non-leaking code in c++?
Because once you are massively multi-threaded then resource management requires a colossal amount of effort to get right. Everything is non-deterministic. You then have the potential that you will not allocate large chunks of memory *in a timely manner*. Then once you factor in third-party C and C++ libraries that may have different resource allocation strategies to yours you end up with a decent probability of leaks. In the end you spend so much effort trying to do memory management in C++ you are basically writing your own memory management system/garbage collector - at least, for the large, complex real-time systems I've worked on.
> I don't even know you much less give a shit what programming language you use.
Actually, what I'm trying to discern is you reason for arguing. Is your argument that it is perfectly possible to write massively multi-threaded, cross-platform real-time applications in C++ in a manner that is easier than doing it in Java? otherwise I don't really get your point at all. It is always a lot more effort and risky to write such programs in C++ relative to Java (which was my point) - apparently do disagree, yeah? In that case, may I ask whether you have ever written such a large massively multi-threaded, cross-platform real-time application? if so then was it easy with C++ and were you very bug-free? because I am writing such an application and my *experience* has lead me to make the statements I do, it is not theoretical (although I will admit, my latest project is not written in C++, since it simply is not a contender for such an application once you factor in developer effort/cost). So, if you can be bothered to outline your experience in solving this problem then I'll bother to give a list of libraries that I've found shitty to work with when doing cross-platform stuff. Deal?
There were some excellent libraries, eg Turbo C and C++ libraries, the BGI etc. Although it has to be said that there wasn't a standard 3D library (well, OpenGL [Doom!] and PHIGs etc were among the standards but not for DOS/early Windows PCs; the first version of DirectX came well after gaming was established and it leaked resources like a cardboard bucket - I remember having 20 player connection slots that accumulated and were never recycled, just awful stuff from Microsoft for those of us that were looking at it).
> use != using, try to keep up.
All I can go on is what you write. Since you are am ambiguous communicator (and it appears an arrogant prick to boot) that is not my problem. So no need for the attitude. k? If you want to make a point try and explain clearly and unambiguously, thanks.
> Vile and unnatural
Well, the fav C++ GUI toolkit around here seems to be QT. When I started playing with QT I was astounded by how horrible it was to use. Slots and macro madness abounded. Meta Object compilation - no thanks. Fortunately they have cleaned somewhat and it has become more OO like, say, Swing. But why settle for the imitation when I can have the real thing?
> "awful porting nonsense"
As in, moving C++ code between the same compiler. I remember using STL with g++ 2.7.2 back in the day (that version was stable for a long time) and then a patch-level release broke the tens of thousands of lines of code I'd been working on. Had to go and fix it all up. Just the other day I got some example code on atmospheric shading (the code wasn't important, it is nothing compared to the maths required). It didn't work right in Visual Studio and it didn't work right on Xcode. I then had to go and fix all the stuff up because each system puts its system headers in different places and the code required porting. Because C++ comes with fsck all as part of its standard library it means every platform has it own libraries (and way of doing things) that you have to fix up. Contrast that with Java. If you can see the JVM and your local lib/ then you are almost always good to go. My Java implementation of the optical atmospheric transmission just works when I *copy* (not recompile) it between Win7, Ubuntu and Mac OS X. I do know what I am doing (I was writing multi-platform C and C++ for nearly two decades using older versions of g++ and Turbo C++ - were you?).
> Then why are you so ignorant of things like memory leaks in Java?
Because I use JVisualVM and carefully examine the runtime execution of my code. I ensure that my products don't have resource leaks. Maybe I know what I'm doing.
> what dumb loopholes?
Every third-party C++ library you get that uses stcmp() instead of strncmp() or pointer-arithmetics their way into segfaulting. There are a lot of ways C++ developers can and do trip themselves - ways that Java was *designed* not to allow you to do (since the designers were heartily sick of all the fsckups with C++). Now, sure you can screw yourself over with Java, but usually I find the third party libraries to be of much better quality than the crap you get in the C++ world. And let's face it, modern software development is about re-using everything you can get your hands on.
> If you do know what you're talking about you can tell me exactly but since you actually don't have any experience you can't specify what you meant by any of these things, they are just baseless.
The only thing that is baseless is your assumption that I'm just another dumb Java guy who doesn't know diddly about C++. Like I said, I've been doing C and C++ for nearly two decades and have evolved past it. That's why I tire of folks like yourself that think because C++ is old and crufty it must be more l33t than modern alternatives. Here I would say, "I've been there, done that, and IMHO you are missing the point about software development". The point of software development is to develop *reliable* solutions with minimum time and effort/cost. C++ was good but is now behind the curve on this for most new development.
> I'm not using or advocating C++
So you don't use C++? well I do, as well as Java. It is laughable you think that I "clearly have no idea..." when as a non-practitioner I suggest you have a look in the mirror... and open your mind a little to the points others are trying to make (even if you find them made clumsily).
> and then the senior manager goes "Wow, that's great, lets drop the delivery date from 6 months from now to 2 months!"
Well, it is your job as developer (or actually, the project manager's job) to show the work plan you have and point out what has yet to be done. It is mostly a matter of education such folks, and of course, planning (you do develop and maintain a work plan, yeah?). Just because they are senior and a manager doesn't mean you can't patiently explain why they can't arbitrarily move dates - it is in both your interests to politely explain how the project needs to stick to your original budgeted time.
Sucking it up silently without explaining the features you'd have to cut is not professional - in fact, that is really where developer "experience" comes in, old timers know when a fight cannot be won (which is actually, most of the time), and will politely point out when changes to a schedule or feature-set are risking the success of the project. Project timelines can be shortened successfully but features/scope are always cut/deferred for this to happen.
I feel that your scenarios are caricatures of how development used to work, rather than what happens when the team has any experience (which is more common now than in the early days of mass software development).
> "It was very normal to worry about saving 2 bytes, or just a few cycles of CPU time back then. So you did everything bespoke by hand, and didn't genericsize much."
Microsoft were famous for doing stuff like this. I remember some story about changing the bootloader for a 5% speed up when booting a 386 that hampered Windows for a few versions (since they needed to remain as backward compatible as they could all sorts of cruft hung around). This kind of thinking cost them a lot of headaches over the years - and resulted in problems (which grizzled Slashdotters remember) and bad perceptions which no amount of PR money is making go away.
Saving 2 bytes here and there but being so frantic you miss out on big optimizations is not the mark of a heroic programmer or heroic era. It is the mark of people that were then too new to know that "software engineering" requires thought and planning, not caffeine-drenched seat-of-the-pants hackery.
Here's an interesting data point that reinforces your statement. For a long time Sun Microsystems was considered to have the best assembly of engineers in IT (although their sales team was balkanized and not customer focussed, hence Sun's demise, but that is a different store). The Sun engineers knew it, and anyone who knew anything also knew it.
For a long time Sun was subject to 'Not Invented Here' (NIH) syndrome. Since they were the smartest whatever they didn't seem to look around much since they would always implement the idea better. However, and this is what I think made these guys even greater in the end, eventually Sun realized that despite their impressive talents the bulk of great ideas was not actually in the room with them but actual out in the rest of the World (with customers and competitors), "The smartest guys work for someone else". Sun then started to outreach a bit and incorporated good ideas. Unfortunately, due to the impossibility of getting Sun stuff quickly and easily (their sales teams were ponderous and mental in the Internet Age - it was hard to buy their stuff without going through all the sale's teams hoops; despite the Sun gear being reliable and competitively priced) the company died.
So, if even the awesome Sun guys can humbly realize that they can learn from others (that is, sometimes others are just as smart or smarter) then perhaps we all ought to as well.... I'd better follow my own advise I guess...:)
Well, I'm surprised linked lists were being used. For my in-progress game (Java combat flight simulator) I will almost never iterate over lists. Using an (associative) 'map' structure is vastly more efficient at runtime. You can still access the complete set as you would an unordered list if you need to, but most of the time you are trying to find a specific object based on some criteria (which the map is good for). Yeah, sounds like having a green programmer work on a bit of code that was heavily used affected everyone in the team. It is a surprised one of the more senior devs didn't see the problem coming and rectify it - but then most commericial games have insanely ambitious development timelines. Fortunately, mine game does not (since, as an 'indie', I'm not relying on it for my main income; and I'm not burning much capital on it either; slower to market, but guaranteed to be a better base for a long lived product line:) re-using the good code in later versions is where I'll make the real money).
> "scrapped it to increase the speed of save time"
That seems to be a real flaw in the mindset of games (and system) developers. They put in all these hacks thinking it'll shave off little slivers of execution time and overall make big savings when it is not the most significant impact on the assembled system. The time savings are usually negligible compared to bigger optimizations you can do later (using a profiler) and the development time increases (meaning you don't have time to run the profiler since you are too busy hunting down dumb bugs). As the great Don Knuth joked, "Premature optimization is the root of all evil".
If you are a developer on these forums bragging how you used some trick to save a sliver of time it would be good to take note of this StarCraft experience - since more experienced devs simply roll their eyes when they hear such talk (recognizing such development practices as n00b traps, which we probably were tempted by ourselves at some point in the past). Write the program to be correct first (usually means the most straightforward efficient implementation, rather than the absolutely fastest implementation, should be used). Then, you can refactor (you *are* writing unit/integration tests, aren't you?) to get more efficient, all the while guided by your profiler to prioritize the development time you have remaining.
nb: the best speed-ups are almost always algorithmic. Code hacks are minor. For example, by sitting down for several hours with a pencil, paper, and google I was able to analytically work out the optical transmission of a multi-band (eg. RGB) light source through and exponential density decay atmosphere using Mie and Rayleigh scattering into a simple analytic expression (for direct and single-scattered illumination) rather than use the integration that many other people use (eg. as published). This allowed me to implement the algorithm in a GLSL shader in real-time and saved on precious Video RAM (eg. no need to precompute and store the integral). Sure, other people have done this too, but my point is that the big speed up for me was to sit down and think rather than make minor code twiddles. Unfortunately, you need to be a good mathematician (using basic calculus and geometry in my case) rather than just a good coder to do this (which I guess may be hard for the poor young schleps that games companies hire and burn out).
I understand your point of view. One of my points was that "Java" is more than the Java Applet, so care has to be made to differentiate the terms. The other thing is I have written Java applets and were forced to because HTML/CSS is just not functional enough at the moment. Sure, you can do simple form-based stuff with it (and get fairly advanced even using the wonderful Google Web Toolkit and vaadin), even do some graphics with Canvas and the (not yet universal) WebGL, but unfortunately the Web experience still falls short of what is possible using an applet (video is designed for playing forward in HTML5, for my engineering purposes I needed forward and backward playback, single-frame stepping and exact frame seek - stuff that requires something like a Java applet to do). This forces me to use applets from time to time. Now requiring users to switch off applets because they have some holes seems to me as short sighted as switching off images (for example) or video because their video rendering libraries have holes discovered from time to time. We must demand that our browser plugins are made secure for sure, but basically throwing plugins out (the essence of your suggestion) is not the solution either. IMHO, the way forward is to hold plugin creators responsible for their product. That way effort would be directed to close the holes in those products. We would not only end up with a more functional web, but a safer one too.
> The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence.
The killing of alternative tech helps Apple's agenda but doesn't help who is really important - me, the end user. Also, even a casual Google search would show you that despite the removal of Apple's competitor products iOS still has exploits. Doing a denial-of-service on yourself does reduce risk but certainly does not eliminate it. Therefore, removing functionality is not the solution - the solution is to make the product creators spend more effort on making the product secure (or if the effort is too great, ditch the product).
Why the vitriol? Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined. Mind you, it suits me perfectly well to have commercial competitors using outdated tech like C++, since I get an easy development efficiency advantage for free. So, by all means, please continue using and advocating C++ rather than more modern solutions:)
Thanks for taking the time to make interesting comments. With regard to your performance woes have you attached the JVisualVM to your running application? It comes as a standard part of the Sun/Oracle/OpenJDK. There you'll be able to see whether your performance issue is caused by: memory thrashing (when near the limit of the allocated heap), synchronization problems (threads locking/blocking each other), resource contention (eg. database row locks), or stuck in a loop somewhere. I'd be very interested to hear what your problem was once you discover it. I've tested by simulator and examined it under JVisualVM and the latency spikes from the GC are about 3% of one CPU core every 5 seconds (which is completely negligible for my purposes).
nb: I'm originally a C guy so understand very well what Java is doing for me. I love the simplicity of the C language and the design where the complexity is placed in the libraries rather than adding (or worse, overloading) more and more keywords. I like C++ too, but don't consider it superior to modern Java (C++ used to be better because of its speed, but in the last 5 years I think that has fallen away and thus I don't consider C++ better anymore).
With regard to XML processing. I used to have to use libraries like Xerces but now use JAXB, which is standard in Java. It's pretty hard to go back to manually wrangling XML once you have the ease of use of JAXB (a few annotations and you can serialize and deserialize any complex object graph). Of course, JAXB is not a one-size-fits-all solution, but for 90% of my XML needs it solves them very quickly. The reason I mention JAXB is that it neatly illustrates the design philosophy between (modern, new-style) Java and its C++ inheritance.
Well, Swing used to be slow when Java2D did software rendering. Quite a few things have changed in seven years. For starters the Nimbus theme is standard in Swing and is very nice to look at (looks as nice as the Mac widgets). Then, there is the fact that Java2D is now completely hardware accelerated through GPU shaders (OpenGL or DirectX, depending on the host platform) but not a single line of Java code needs to be changed to take advantage of this. As long as you don't block the Event Dispatch Thread in Swing (which bad programmers still do, even after all this time) your application is very, very responsive. So I don't disagree with your criticism of Swing, I just think it is quite outdated. If the disadvantages of Swing have fallen away and you are mostly only left with the advantages then I would suggest that many C++ developers ask themselves whether it is worth their time (or their employers money) that their next project should be started in C++. While I used to interleave C++ and Java projects (depending on the application) I find no compelling reasons to start with C++ anymore. So, all I'm trying to do is to counter out-of-date perceptions of Java and suggest to C++ folks that perhaps it is worth taking a second look at modern Java for just getting stuff done with less hassle than C++.
Have you ever seen the Google Web Toolkit (GWT) or vaadin? These are both Java technologies (almost no one uses the 'browser plugin' Java applets for new projects).
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
> There are plenty of strategies for dealing with memory management (smart points, basic ref counting, etc...), but you prefer to not worry about that and that's your main concern then yes a GC language will serve you better.
It is possible to leak memory even using these in a long running application. If you have a statically allocated pointer then the memory can easily be held on to. With Java the VM actively looks at what can be released. This is a problem on uniprocessors but on today's hardware most cores that are often idle so letting the GC do work for you makes a lot of sense (it is analogous to the benefits that the C++ compiler and linker have over doing stuff in assembly; sure, you can build stuff in assembly but by choosing a higher level of abstraction you are free to concentrate on other concerns, like the 'problem domain').
Huh? users can choose a less vulnerable O/S. Also, users will be secure if they don't install anything at all - but that is kinda doing a "denial of service" on themselves. So calling Java "malware" and saying "just don't install it" kinda seems non-sensical to me (especially since Java is not alone in potential attack surface - I mean, most would consider it ridiculous to not install Flash on the modern web browser, or not install MS Office [with all the macro viruses], or Adobe Reader - yet that is exactly what the grandparent poster was proposing for Java).
Slashdot Mirror
Well, as a Microsoft employee I'm surprised you need to ask, but let's go ...
Embrace
For trivial examples the Microsoft C++ compiler will work ok. The only real pragma needed here is one to prevent a spurious compiler warning, something like 1481 IIRC. The embrace phase is intended to assuage fears that developing for this platform means you won't have Standard C++.
Extend :(]). Once these #defines are in a large codebase you are starting to get tied to the Microsoft compiler only unless you do a lot of additional work to add additional #ifdefs. Now this may not be intentional by the Microsoft C++ compiler team these days but at one point it absolutely was Microsoft's goal to tie developers into their technology and make it hard to get out (eg. all the extensions for Managed C++, now deprecated, sigh) - which means the legacy behavior of their compiler and current accepted techniques (eg. requiring special defines to get standard behavior back) are permitted by their design team (they should not be, non-standard behavior should be selected by specifying exceptions/defines, not the other way around).
Now for non-trivial examples we start to have to use #defines to get around optimizations that Microsoft bake into their compiler that will break standard-compliant code if you don't put the #define in (cite: http://msdn.microsoft.com/en-US/library/vstudio/bb531344.aspx; some are needed to be more standards compliant [good!], some are needed to regain standards compliant because the default implementation is not to be [bad
Extinguish .NET that not only was C++ not standard but it would never be standard. Fortunately this attitude has changed, but we still remember the danger of depending on Microsoft C++ before. I aim never to be in a position where my code is tied to Microsoft again, hence my post warning others.
Now we get to the bits of a program that are dependent on Windows (that is, required to make a program do anything useful on Windows). Here we get types and macros all over the place that are specific to Windows. Once you start using these your code is not going anywhere else. Now you may argue that this is the case on any platform but it is not so. Most other toolkits use Standard C++ types in their interfaces, they don't define a whole new set of types via macros. Now, this may be a legacy of old ways of doing Windows development (grrr Charles Simonyi, stealing FORTRAN abominations to make Hungarian Notation 'warts' that persist in C# today with the 'I' prefix [completely unnecessary and unhelpful when you refactor between classes and interfaces - but the drones cannot help themselves any more and can't see the badness of that style]). Anyway, my point is that you can't write modern C++ for Windows without injecting a whole lot of platform-dependencies into the code (eg. types, macros) that are far more than just the class interfaces of Windows-specific libraries. The original intent from Microsoft was to tie your code to the Windows platform (hence decrease the ability to move code to competitors). IMHO, it seems the Windows engineers are valiantly trying to remove the sins of the past (for which I give them full credit) - I even remember Microsoft announcing in the first releases of
I just looked up the licensing terms (http://en.wikipedia.org/wiki/Microsoft_XNA). You have to be approved by Microsoft for commercial development and they get 30% of your revenue (plus you'll have to pay about the same in tax, depending where you are).
Commercially and technologically I'll think I'll stick with Java/JoGL(OpenGL) for now. Compared to using XNA I just increased my profits by 50% by making that one choice! :)
Cool. Do you perchance know how much the XNA license is for commercial development?
Personally I'd rather rely on Free Software for the long term, but I can see monogame under MS-PL is viable for some.
Oh yes, of course it is possible, but not really convenient. This is not a major issue, but for the posters pushing Visual Studio (and associated compiler) as if it was the best development environment since hot toast then I beg to differ.
> They are a niche and always have been, and are growing. I'd rather release a title for them than hope to be the next angry birds in the very noisy mobile environment.
That's me too. I'm developing for a high end niche (high-fidelity jet combat flight sim). However, I accept that this is not optimal from an economic point of view. Much of the commercial shrink-wrapped developers do consider the size of the market. I expect they are mostly sitting on the sidelines waiting to see if anything good happens (with everyone waiting, chicken and egg means not enough will happen to make an impact on the established players).
> C# and mono targets all platforms. .NET are not interchangeable with Mono. This means using this is a bit more work (I'm using Java,JOAL,JoGL,JInput etc where the libraries mostly work cross-platform; so C# is a win compared to C++ but not compared to what I'm using at the moment).
The language does, but the libraries for MS
Cory Doctorow wrote about this:
The Coming Civil War over General Purpose Computing
http://boingboing.net/2012/08/23/civilwar.html
http://boingboing.net/2012/01/10/lockdown.html
"They" (the corporates) have seen how good Linux, Android and Free Software have become. They understand that leaving general purpose computing open would mean they cannot protect their current profit margins as software becomes more and more a commodity. Hence in order for them to "win" (have control over profit streams), they must make you "lose" (lose control over your own devices).
First came TPM in hardware. Fortunately users defeated this by making it optional and controlled by the device owner.
Apple were the first to successfully foist it on users and people were happy and smiled, "I love my Apple, I don't mind Apple having all the control for safety. What is there to worry about".
Now it is the turn of the Windows folks to lose control. Applications will pass through Microsoft censorship, hardware will be controlled by them, since only they will write (closed-source) software that can run on it. Still we will have people laughing a Richard Stallman's prescience, seeing this decades ago.
The Linux guys are being shut out now, since the Empire knows it must snuff out the Rebel Alliance to get complete control of the computing galaxy (and all the riches therein).
If you are still a believer in "walled gardens" ("I prefer convenience to control of my devices") then you ought to reconsider your views in light of these developments. For those that were always distrustful of the walled gardens, your fears are starting to come to pass, but at least you had the wisdom to recognize them. Now it is time to raise hue and cry about this. Corporates will listen to disgruntled customers if there are enough of them to threaten sales significantly. Blog your asses off about how Intel are doing the dirty on the tech community with their misleading statements.
No Microsoft Phone 8 (MP8) will only succeed if they convince developers that it is worthwhile developing for their platform. Hence all the spam on these Slashdot threads, among other places - they think we're too stupid to notice their manipulation.
Microsoft would actually interest developers if they made fantastic tools and a fantastic open platform (rather than these troll posts, thinking developers are the same as general 'sheeple'). In fact, they would guarantee success if their tools allowed you to develop for Android and iOS as first-class citizens of a development framework. This will never happen, so developers will look at MP8 and see that they can't leverage their existing code to easily get customers on that platform.
Purely rational developers will conclude that the platforms that should be supported (based on market share and current market share momentum) are Android and iOS, in that order. Once the Android code is complete the developer will look around what to do next, but since Microsoft's tools and tech is different the developer will conclude that it is probably not worth creating a whole new port for the fledgling user base of WP8. Going for iOS would bring in much more money (which is what it is all about, after all). Hence, WP8 faces a chicken-and-egg problem and is already vastly behind adoption and application availability in the market. Only a fanboi would get a Windows Phone these days hoping it will succeed where all the other Windows Phones failed (probability: WP8 will be just as spectacularly unsuccessful as its predecessors, it is just too late to market and has too much going against it to make up the lost ground against great competitors).
> Even if WP8 loses, Microsoft still wins in the end.
No. WP8 is likely to lose and that means Microsoft loses. It may get modest financial returns from its Android patent extortions but continuing to lose developer mindshare keeps weakening their grip on IT. A decade ago most developers only looked at Windows and Windows development tools, now they use all sorts of tools, tech (nb: better than Visual Studio) and Free Software/Open Source to rapidly develop for the web/mobile and desktop. Even the C# guys are somewhat shafted by the change of Microsoft's focus away from this (don't say they weren't told this would happen, Microsoft has to periodically change tools and tech to drive revenue - "In order for Microsoft to win, the customer must lose" holds true for Windows developers too).
If Android ever becomes a viable OS choice for the corporate desktop then Microsoft is in a world of hurt. Apple is already a viable choice (for professionals and executives) but not for the budget low-end stuff given to the proles. The huge profits Microsoft makes at the moment would not be sustainable long term once there arises true competition on the desktop again (and it will come eventually, it is a market ripe for competition and innovation where Microsoft is not providing any). The markets have long realised that significant growth is not really possible for Microsoft. Now there is real danger that with saturated markets and alternatives to the PC that Microsoft's revenues may actually go in to fundamental decline (rather than loss of revenue from the one-off $6 billion blunder from a bad acquisition).
With all these factors, one would probably do best not to bet your business on only using Microsoft-only technology (.NET), tools (Visual Studio), or platforms (Windows Phone). Better to reduce your risk and choose technology (such as Java [both OpenJDK and Android], GWT/vaadin, Standard C++, Objective-C), tools (Eclipse, Netbeans, IntelliJ, Emacs!) and platforms (Android, the Web) that will always be around provided there are enough users (that is, can't be killed on corporate whims and changes in strategic direction). That is the safe way to bet.
Yes, but does it support *ALL* of the C++ standard, or a Microsoft bastardized version (meaning to do anything useful you need Microsoft-specofic #pragmas and #defines)? If so, the Visual Studio is just another on-ramp to the Microsoft lock-in herd pen.
> Except to say that you go to the trouble of using JVisualVM to examine your running code Java for memory leaks - which makes sense in most applications but certainly not in a non-deterministic highly parallel application.
Ok, this is bullshit right here. With a highly non-deterministic application the first approach is to look at the statistical overall expectation behaviour of the application, for which this tool is awesomely suited.
> I use a lot of GPGPU for offloading massively parallel tasks, the language that drives it doesn't really matter so long as it has bindings for the GPGPU library (in my case mostly CUDA).
Ah, I get it now. Based (solely) on this your problem domain is massively parallizable. That is *not the same* as the massively multi-threaded program that I was talking about where you have different resources with different hard and soft real time requirements (and usually low-latency is what you are aiming for). I am surprised you didn't see the difference.
Ok, for the CUDA-esque problems what one tries to achieve is not usually not complex (in relative terms) it just has to have be speed up to fit within useful timeframes. I feel I understand this problem as I did planetary gravitational microlensing simulations that would have been awesome to use CUDA on, if it had existed at the time.
Ok, now for some libraries I'm not so fond of. Well, I find that even something as core as STL is quirky between implementations. I found I needed to spend a lot of effort #ifdefing to handle the differences when using different compilers (or versions of the compiler) - this is quite a fail to me (yes there are differences between JDK implementations and versions too [grrr the stupid breaking change in java.sql.DataSource in v7], but they are fair more avoidable and less effort to resolve IMHO). Then there are the unicode problems with all C++ libraries. Depending where the program was running was you could never tell whether your wchar_t would be able to accept asian character sets or not (since wchar_t was often shitty old UCS-2 rather than a proper unicode format; and if you are developing software for China you must meet GB18030 to meet government standards). For multi-threading pthreads was ok, but managing shared collections was a lot of work (unlike Doug Lea's genius poured into java.util.concurrent). Then there is OpenGL context creation that is a PITA to set up for each platform. Sure, there's GLUT etc for toy programs, but it is not well suited for programs where mostly you want a higher level of abstraction and integration with your UI toolkit but then occasionally want to get down to the nuts and bolts.
Ok, now I wanna do device I/O, hmm let's see, I get to use DirectInput or libusb and keep tabs on who is releasing resources when (and don't fsck it up or you'll be in a world of pain - your program will run for another five minutes before it crashes [hopefully not crashing the system due to bugs in the graphics driver; curse AMD's trouty bodies], then you get a core that you have to go through to work out where the problem was, which is not necessarily the same place the pointer violation occurred due to the unprotected memory). Oh, and once you have your program running and ported you have end users running it and find it won't run and you have to debug remotely but the standard library gives you no convenient stack trace of the calls made, and you can't just plug in to their running system and watch what their system is doing (hence my unseemly love for JVisualVM; strace is good but I don't always get shell access to use it on a client system). Then I really miss annotation-based libraries like JAXB and JPA2/Hibernate, I've not seen C++ libraries that are anywhere near as convenient. Also RTTI was not nearly as good as Reflection once I got used to the latter.
So, the more and more varied application domains led me to conclude that C++ is not the best choice for modern apps doing a lot of stuff outside C++'s limited standard library. The more com
> You specifically mentioned Android in your original post, are you running Swing on Android? If you don't like Qt that's fine, but that's not an objective criticism.
There is a small piece of code to load a different type of parent window on Android - detected using the normal Java mechanism. Once it hands over to the JoGL code then there is nothing really to do, since JoGL supports Android the same as any other platform.
> So then why do you have so much difficulty writing non-leaking code in c++?
Because once you are massively multi-threaded then resource management requires a colossal amount of effort to get right. Everything is non-deterministic. You then have the potential that you will not allocate large chunks of memory *in a timely manner*. Then once you factor in third-party C and C++ libraries that may have different resource allocation strategies to yours you end up with a decent probability of leaks. In the end you spend so much effort trying to do memory management in C++ you are basically writing your own memory management system/garbage collector - at least, for the large, complex real-time systems I've worked on.
> I don't even know you much less give a shit what programming language you use.
Actually, what I'm trying to discern is you reason for arguing. Is your argument that it is perfectly possible to write massively multi-threaded, cross-platform real-time applications in C++ in a manner that is easier than doing it in Java? otherwise I don't really get your point at all. It is always a lot more effort and risky to write such programs in C++ relative to Java (which was my point) - apparently do disagree, yeah? In that case, may I ask whether you have ever written such a large massively multi-threaded, cross-platform real-time application? if so then was it easy with C++ and were you very bug-free? because I am writing such an application and my *experience* has lead me to make the statements I do, it is not theoretical (although I will admit, my latest project is not written in C++, since it simply is not a contender for such an application once you factor in developer effort/cost). So, if you can be bothered to outline your experience in solving this problem then I'll bother to give a list of libraries that I've found shitty to work with when doing cross-platform stuff. Deal?
There were some excellent libraries, eg Turbo C and C++ libraries, the BGI etc. Although it has to be said that there wasn't a standard 3D library (well, OpenGL [Doom!] and PHIGs etc were among the standards but not for DOS/early Windows PCs; the first version of DirectX came well after gaming was established and it leaked resources like a cardboard bucket - I remember having 20 player connection slots that accumulated and were never recycled, just awful stuff from Microsoft for those of us that were looking at it).
> use != using, try to keep up.
All I can go on is what you write. Since you are am ambiguous communicator (and it appears an arrogant prick to boot) that is not my problem. So no need for the attitude. k? If you want to make a point try and explain clearly and unambiguously, thanks.
> Vile and unnatural
Well, the fav C++ GUI toolkit around here seems to be QT. When I started playing with QT I was astounded by how horrible it was to use. Slots and macro madness abounded. Meta Object compilation - no thanks. Fortunately they have cleaned somewhat and it has become more OO like, say, Swing. But why settle for the imitation when I can have the real thing?
> "awful porting nonsense"
As in, moving C++ code between the same compiler. I remember using STL with g++ 2.7.2 back in the day (that version was stable for a long time) and then a patch-level release broke the tens of thousands of lines of code I'd been working on. Had to go and fix it all up. Just the other day I got some example code on atmospheric shading (the code wasn't important, it is nothing compared to the maths required). It didn't work right in Visual Studio and it didn't work right on Xcode. I then had to go and fix all the stuff up because each system puts its system headers in different places and the code required porting. Because C++ comes with fsck all as part of its standard library it means every platform has it own libraries (and way of doing things) that you have to fix up. Contrast that with Java. If you can see the JVM and your local lib/ then you are almost always good to go. My Java implementation of the optical atmospheric transmission just works when I *copy* (not recompile) it between Win7, Ubuntu and Mac OS X. I do know what I am doing (I was writing multi-platform C and C++ for nearly two decades using older versions of g++ and Turbo C++ - were you?).
> Then why are you so ignorant of things like memory leaks in Java?
Because I use JVisualVM and carefully examine the runtime execution of my code. I ensure that my products don't have resource leaks. Maybe I know what I'm doing.
> what dumb loopholes?
Every third-party C++ library you get that uses stcmp() instead of strncmp() or pointer-arithmetics their way into segfaulting. There are a lot of ways C++ developers can and do trip themselves - ways that Java was *designed* not to allow you to do (since the designers were heartily sick of all the fsckups with C++). Now, sure you can screw yourself over with Java, but usually I find the third party libraries to be of much better quality than the crap you get in the C++ world. And let's face it, modern software development is about re-using everything you can get your hands on.
> If you do know what you're talking about you can tell me exactly but since you actually don't have any experience you can't specify what you meant by any of these things, they are just baseless.
The only thing that is baseless is your assumption that I'm just another dumb Java guy who doesn't know diddly about C++. Like I said, I've been doing C and C++ for nearly two decades and have evolved past it. That's why I tire of folks like yourself that think because C++ is old and crufty it must be more l33t than modern alternatives. Here I would say, "I've been there, done that, and IMHO you are missing the point about software development". The point of software development is to develop *reliable* solutions with minimum time and effort/cost. C++ was good but is now behind the curve on this for most new development.
> I'm not using or advocating C++ ..." when as a non-practitioner I suggest you have a look in the mirror ... and open your mind a little to the points others are trying to make (even if you find them made clumsily).
So you don't use C++? well I do, as well as Java. It is laughable you think that I "clearly have no idea
> and then the senior manager goes "Wow, that's great, lets drop the delivery date from 6 months from now to 2 months!"
Well, it is your job as developer (or actually, the project manager's job) to show the work plan you have and point out what has yet to be done. It is mostly a matter of education such folks, and of course, planning (you do develop and maintain a work plan, yeah?). Just because they are senior and a manager doesn't mean you can't patiently explain why they can't arbitrarily move dates - it is in both your interests to politely explain how the project needs to stick to your original budgeted time.
Sucking it up silently without explaining the features you'd have to cut is not professional - in fact, that is really where developer "experience" comes in, old timers know when a fight cannot be won (which is actually, most of the time), and will politely point out when changes to a schedule or feature-set are risking the success of the project. Project timelines can be shortened successfully but features/scope are always cut/deferred for this to happen.
I feel that your scenarios are caricatures of how development used to work, rather than what happens when the team has any experience (which is more common now than in the early days of mass software development).
> "It was very normal to worry about saving 2 bytes, or just a few cycles of CPU time back then. So you did everything bespoke by hand, and didn't genericsize much."
Microsoft were famous for doing stuff like this. I remember some story about changing the bootloader for a 5% speed up when booting a 386 that hampered Windows for a few versions (since they needed to remain as backward compatible as they could all sorts of cruft hung around). This kind of thinking cost them a lot of headaches over the years - and resulted in problems (which grizzled Slashdotters remember) and bad perceptions which no amount of PR money is making go away.
Saving 2 bytes here and there but being so frantic you miss out on big optimizations is not the mark of a heroic programmer or heroic era. It is the mark of people that were then too new to know that "software engineering" requires thought and planning, not caffeine-drenched seat-of-the-pants hackery.
Here's an interesting data point that reinforces your statement. For a long time Sun Microsystems was considered to have the best assembly of engineers in IT (although their sales team was balkanized and not customer focussed, hence Sun's demise, but that is a different store). The Sun engineers knew it, and anyone who knew anything also knew it.
For a long time Sun was subject to 'Not Invented Here' (NIH) syndrome. Since they were the smartest whatever they didn't seem to look around much since they would always implement the idea better. However, and this is what I think made these guys even greater in the end, eventually Sun realized that despite their impressive talents the bulk of great ideas was not actually in the room with them but actual out in the rest of the World (with customers and competitors), "The smartest guys work for someone else". Sun then started to outreach a bit and incorporated good ideas. Unfortunately, due to the impossibility of getting Sun stuff quickly and easily (their sales teams were ponderous and mental in the Internet Age - it was hard to buy their stuff without going through all the sale's teams hoops; despite the Sun gear being reliable and competitively priced) the company died.
So, if even the awesome Sun guys can humbly realize that they can learn from others (that is, sometimes others are just as smart or smarter) then perhaps we all ought to as well. ... I'd better follow my own advise I guess ... :)
Well, I'm surprised linked lists were being used. For my in-progress game (Java combat flight simulator) I will almost never iterate over lists. Using an (associative) 'map' structure is vastly more efficient at runtime. You can still access the complete set as you would an unordered list if you need to, but most of the time you are trying to find a specific object based on some criteria (which the map is good for). Yeah, sounds like having a green programmer work on a bit of code that was heavily used affected everyone in the team. It is a surprised one of the more senior devs didn't see the problem coming and rectify it - but then most commericial games have insanely ambitious development timelines. Fortunately, mine game does not (since, as an 'indie', I'm not relying on it for my main income; and I'm not burning much capital on it either; slower to market, but guaranteed to be a better base for a long lived product line :) re-using the good code in later versions is where I'll make the real money).
> "scrapped it to increase the speed of save time"
That seems to be a real flaw in the mindset of games (and system) developers. They put in all these hacks thinking it'll shave off little slivers of execution time and overall make big savings when it is not the most significant impact on the assembled system. The time savings are usually negligible compared to bigger optimizations you can do later (using a profiler) and the development time increases (meaning you don't have time to run the profiler since you are too busy hunting down dumb bugs). As the great Don Knuth joked, "Premature optimization is the root of all evil".
If you are a developer on these forums bragging how you used some trick to save a sliver of time it would be good to take note of this StarCraft experience - since more experienced devs simply roll their eyes when they hear such talk (recognizing such development practices as n00b traps, which we probably were tempted by ourselves at some point in the past). Write the program to be correct first (usually means the most straightforward efficient implementation, rather than the absolutely fastest implementation, should be used). Then, you can refactor (you *are* writing unit/integration tests, aren't you?) to get more efficient, all the while guided by your profiler to prioritize the development time you have remaining.
nb: the best speed-ups are almost always algorithmic. Code hacks are minor. For example, by sitting down for several hours with a pencil, paper, and google I was able to analytically work out the optical transmission of a multi-band (eg. RGB) light source through and exponential density decay atmosphere using Mie and Rayleigh scattering into a simple analytic expression (for direct and single-scattered illumination) rather than use the integration that many other people use (eg. as published). This allowed me to implement the algorithm in a GLSL shader in real-time and saved on precious Video RAM (eg. no need to precompute and store the integral). Sure, other people have done this too, but my point is that the big speed up for me was to sit down and think rather than make minor code twiddles. Unfortunately, you need to be a good mathematician (using basic calculus and geometry in my case) rather than just a good coder to do this (which I guess may be hard for the poor young schleps that games companies hire and burn out).
I understand your point of view. One of my points was that "Java" is more than the Java Applet, so care has to be made to differentiate the terms. The other thing is I have written Java applets and were forced to because HTML/CSS is just not functional enough at the moment. Sure, you can do simple form-based stuff with it (and get fairly advanced even using the wonderful Google Web Toolkit and vaadin), even do some graphics with Canvas and the (not yet universal) WebGL, but unfortunately the Web experience still falls short of what is possible using an applet (video is designed for playing forward in HTML5, for my engineering purposes I needed forward and backward playback, single-frame stepping and exact frame seek - stuff that requires something like a Java applet to do). This forces me to use applets from time to time. Now requiring users to switch off applets because they have some holes seems to me as short sighted as switching off images (for example) or video because their video rendering libraries have holes discovered from time to time. We must demand that our browser plugins are made secure for sure, but basically throwing plugins out (the essence of your suggestion) is not the solution either. IMHO, the way forward is to hold plugin creators responsible for their product. That way effort would be directed to close the holes in those products. We would not only end up with a more functional web, but a safer one too.
> The advent of iOS went a long way towards killing these technologies, and the web is a safer place for their absence.
The killing of alternative tech helps Apple's agenda but doesn't help who is really important - me, the end user. Also, even a casual Google search would show you that despite the removal of Apple's competitor products iOS still has exploits. Doing a denial-of-service on yourself does reduce risk but certainly does not eliminate it. Therefore, removing functionality is not the solution - the solution is to make the product creators spend more effort on making the product secure (or if the effort is too great, ditch the product).
Many thanks for the link Mighty Odin. I'll take a look.
Why the vitriol? Java is not perfect, I just happen to consider it better than its competitors for soe of the reasons I have outlined. Mind you, it suits me perfectly well to have commercial competitors using outdated tech like C++, since I get an easy development efficiency advantage for free. So, by all means, please continue using and advocating C++ rather than more modern solutions :)
Thanks for taking the time to make interesting comments. With regard to your performance woes have you attached the JVisualVM to your running application? It comes as a standard part of the Sun/Oracle/OpenJDK. There you'll be able to see whether your performance issue is caused by: memory thrashing (when near the limit of the allocated heap), synchronization problems (threads locking/blocking each other), resource contention (eg. database row locks), or stuck in a loop somewhere. I'd be very interested to hear what your problem was once you discover it. I've tested by simulator and examined it under JVisualVM and the latency spikes from the GC are about 3% of one CPU core every 5 seconds (which is completely negligible for my purposes).
nb: I'm originally a C guy so understand very well what Java is doing for me. I love the simplicity of the C language and the design where the complexity is placed in the libraries rather than adding (or worse, overloading) more and more keywords. I like C++ too, but don't consider it superior to modern Java (C++ used to be better because of its speed, but in the last 5 years I think that has fallen away and thus I don't consider C++ better anymore).
With regard to XML processing. I used to have to use libraries like Xerces but now use JAXB, which is standard in Java. It's pretty hard to go back to manually wrangling XML once you have the ease of use of JAXB (a few annotations and you can serialize and deserialize any complex object graph). Of course, JAXB is not a one-size-fits-all solution, but for 90% of my XML needs it solves them very quickly. The reason I mention JAXB is that it neatly illustrates the design philosophy between (modern, new-style) Java and its C++ inheritance.
Well, Swing used to be slow when Java2D did software rendering. Quite a few things have changed in seven years. For starters the Nimbus theme is standard in Swing and is very nice to look at (looks as nice as the Mac widgets). Then, there is the fact that Java2D is now completely hardware accelerated through GPU shaders (OpenGL or DirectX, depending on the host platform) but not a single line of Java code needs to be changed to take advantage of this. As long as you don't block the Event Dispatch Thread in Swing (which bad programmers still do, even after all this time) your application is very, very responsive. So I don't disagree with your criticism of Swing, I just think it is quite outdated. If the disadvantages of Swing have fallen away and you are mostly only left with the advantages then I would suggest that many C++ developers ask themselves whether it is worth their time (or their employers money) that their next project should be started in C++. While I used to interleave C++ and Java projects (depending on the application) I find no compelling reasons to start with C++ anymore. So, all I'm trying to do is to counter out-of-date perceptions of Java and suggest to C++ folks that perhaps it is worth taking a second look at modern Java for just getting stuff done with less hassle than C++.
Java is a single program? Do you have any idea about what you are talking about halfling?
Have you ever seen the Google Web Toolkit (GWT) or vaadin? These are both Java technologies (almost no one uses the 'browser plugin' Java applets for new projects).
With regard to the "awful porting nonsense" I'm afraid I have to stand by my comment. Apart from trivial applications and even with good libraries it is still fairly painful to port a large application between Linux, Windows and Mac OS X.
> There are plenty of strategies for dealing with memory management (smart points, basic ref counting, etc...), but you prefer to not worry about that and that's your main concern then yes a GC language will serve you better.
It is possible to leak memory even using these in a long running application. If you have a statically allocated pointer then the memory can easily be held on to. With Java the VM actively looks at what can be released. This is a problem on uniprocessors but on today's hardware most cores that are often idle so letting the GC do work for you makes a lot of sense (it is analogous to the benefits that the C++ compiler and linker have over doing stuff in assembly; sure, you can build stuff in assembly but by choosing a higher level of abstraction you are free to concentrate on other concerns, like the 'problem domain').
Huh? users can choose a less vulnerable O/S. Also, users will be secure if they don't install anything at all - but that is kinda doing a "denial of service" on themselves. So calling Java "malware" and saying "just don't install it" kinda seems non-sensical to me (especially since Java is not alone in potential attack surface - I mean, most would consider it ridiculous to not install Flash on the modern web browser, or not install MS Office [with all the macro viruses], or Adobe Reader - yet that is exactly what the grandparent poster was proposing for Java).