Clearcase sucks for Java. Anything else sucks for C/C++. Don't even consider Clearcase if you're an Eclipse shop. Don't even consider doing serious C++ job on Git. Just use the right tool and move on.
Will your computer take into account that the small C172 VFR guy just picked the wrong taxiway and is now making you miss your 5minutes slot, and needs to recompute the whole thing? And if you only rely on TCAS, good luck avoiding the PA28 pilot who forgot to turn his transponder on once engaged on the rwy (because you know we need to turn that stuff off when on ground frequency to avoid wrong TCAS alarms from landing airliners). Computers are good, but planes are still piloted by humans...
I mean like supporting writing of shared objects without having to deal with inconsistent mangling approaches between compilers, having to resort to manually-maintained export files? Or having to use the exact same version of the compiler between the library and the code using it? Being able to expose functions throwing exceptions through a library (gasp! who wants to do that?) or to reliabily use an std container through the library interface?
Without all this, you can't write C++ code spliting the logic into multiple binaries in a platform-independant way...
This is the main reason why all libraries are still written in C, or at least expose interfaces in C.
I'm doing a lot of programming interviews these days, and I can tell you that it really doesn't matter.
During interviews I couldn't care less about pointers: I will check problem solving skills, I will assess how they react to existing code they are not familiar with (this is the real challenge you face when getting a new job). I will use good old FizzBuzz test, I will play with basic recursion (insane how most candidates will fail at even the most basic recursive logic). None of this is language specific.
C developers might also be lacking notion of proper data abstraction and will scatter global variables all over the place. This is as bad (if not worse). And believe me, most C developers don't understand memory management neither (is this virtual memory? is this page committed or just reserved in the address space? how comes you get an out of memory in your process and yet you still have tons of free physical memory? what is heap fragmentation? is malloc slow? is it thread-safe? what are heap protection canaries?) A lot of C developers will be using static data with constant size in order to avoid dynamic memory allocation. The result? Java developers are typically more versed in dynamic structures such as double linked lists than C developers...
And by the way, Java has "pointers", we just call them references, and any Java developer worth working with knows the difference between a value-type (int) and a pointer (Integer), they just have different names, you can't assign arbitrary values to your references and you don't need to free them explicitly, that's all.
This could be a slippery slope if this was a new law or a new application of the law, but it is neither of these: this is just the existing application of existing EU laws that exist for, what, 30 years or more? There are very precise and well-understood laws in many countries of Europe stating that yes indeed, it is absolutely forbidden for a company to retain information about EU Citizen that can be processed automatically without these citizens having their say about it. Having that information as part of an index, meta-data or whatever doesn't really matter. You have that kind of information, you must abide by the law. The companies storing personal information are very aware of these laws and have processes in place to cater for the "having their say about it" part. And believe me or not all the newspaper are fully compliant with the law, for many, many decades. And no, this part of Europe (that is, not UK) is not well-known for its strong censorship stance. So there is no problems. At all. What you are depicting here is for some kind of arrogant US company that believes it knows better than the people of Europe how to deal with their own laws. Surprisingly enough, that will not end up well for them.
I’m a European expat working in Malaysia. I never heard of WhatsApp before getting into the country one year ago. Now I’m using it every single day. It seems the whole country gave up on SMS and using nothing but WhatsApp for everything from photo sharing to group messaging.
We are probably not talking about the same applications then... Look at "azureus java" or "azureus screenshot" on Google Images and tell what reminds you of Eclipse from that.
I couldn't disagree more: I've been doing SWT development for many years, and I can tell you that SWT applications are impossible to distinguish from native applications, on any platform. Sure Eclipse looks like nothing but Eclipse, but if you take well-written SWT applications (Azureus for instance), no-one would be able to tell you that it is made out of Java. From a user point of view, SWT is just invisible. On a programming point of view, I would agree though: SWT is extremely low-level and the first think you need to put in place is a higher-level API. It has nothing to compare with Swing, which is a real pleasure to develop with. SWT is a pain in the ass, difficult to extend and very difficult to use. So it really depends what matters more to you: the integration of your application with the user desktop and preferences, or the convenience of the development framework itself? One of the (many) reasons why Java never really took off on the desktop is because, unfortunately, many developers chose the latter.
Well it depends, observe how the package explorer tree is actually the native tree widget. How the tables are actually native tables with proper look&feel for the sorting and column resizing. Observe how the menu bar on OS X is actually properly positionned. Observe how the buttons in the configuration sreens, all the scrollbars are native. Notice that drag&drop from and to the desktop or the Windows Explorer actually works, and also proper copy/pasting of files from external applications. These are all these smalls details that make a big difference at the end of the day.
Note that in Java you can get something similar by using SWT, which uses JNI to call the native underlying platform widgets. Used by Eclipse but can be used in a small standalone J2SE application. http://eclipse.org/swt/
This requires self-signed applet with full privileges so by using this new security solution I will put my computer at risk. Isn't that great? I would have expected that people working in the security domain would not have the "I don't bother about actual rights I need so let us request full access" attitude.
This being said, I never appreciated FSX as much as since I got my PPL license. Sure I can't see my house, but I can actually practice and prepare VFR navigations using the default scenery since the stuff that really matters to the real pilots are is there. I also bought X-Plane to compare and it failed completely: it looks prettier but I almost got lost before leaving the CTR. So I can tell you, from a pilot's point of view, FSX really feels like flying over the landscape since I can use my low-altitude map in the game (and this is my Belgian countryside, not some fancy touristic places).
It's called a Java applet: every applet either runs within a very strict sandbox (even stricter than Javascript itself by the way), or the application manifest must declare and request any further access. Even better, this is only allowed if the application has been digitally signed by the software vendor.
In practice it never worked, because:
1) The default rights could be modified by the user, which meant that the vendor never got quite sure what was going to happen practically at run-time;
2) As a consequence, application vendors never bothered to use individual permissions: they requested "full access right" and damnit. Even Sun (I mean Oracle) demo's do exactly that;
3) Anyway, users got not idea what "accessing local files" meant, and just blindly clicked on "agree" as usual;
4) And even if vendors really tried hard to play it nice, what was actually allowed by default, how to practically request additional privileges, and how to provide the signature: all these got modified through each major version of Java during the early days, and therefore everybody just gave up (even though it is very stable by now, nobody cares anymore).
You're right, but reality is never fully black or white. I'm interested into cross-platform compatibility let's say 95% of the time. But I'm perfectly ready to give up the last 5% to please the user and deliver the extra mile in term of platform integration and usesability. This is why we didn't use C# in one of my projects: we wanted cross-platform, but we then selected SWT as we knew (and it turned out the be the right decision) that at some point integration and platform-specific features would be needed.
This is the problem with Java and Swing in particular: to refuse any pragmatism and to sacrifice the end-user experience to the "purity" of the framework. "100% pure Java" is considered to be an ultimate goal within the Java community. This is weird: I've never seen such as thing as "100% pure C# code" or "100% pure C++ code" or whatever. In SWT if I want to use ActiveX on Windows I'm able to do so. Sure this will only work on Windows, but then I'm able to if-then-else my code to offer an alternative implementation on other platforms. I'm able to use application-wide menus on MacOSX. Sure this makes no sense on other platforms but again who cares? Swing prohibits this kind of pragmatism and this is one of the reason, IMHO, why Java never actually took off on the desktop.
This is the whole issue with Swing: this a wonderful piece of software, the best GUI framework I ever worked on. Really. SWT, on the other hand, is inconsistent and difficult to use, brittle at times and indeed full of dirty hacks when you look at the code. And still I'm using SWT because at the end of the day the end-user doesn't care whether the toolkit is nice and neat.
What matters is platform integration: SWT supports Windows 7 jumplists, non-rectangular windows for ages, uses the native file selector (gosh how I hate Swing as a user for this), has a decent native drag&drop, is low on resource consumption, supports other OS plugins such as Windows speech recognition etc... Most importantly, it allows you to get out of the sandbox by directly exposing the underlying platform's APIs. Want to use some Windows-specific effects such as transparency or whatever? Just call OS.sendWindowMessage and you're done. Sure this will cause platform incompatibility but the end-user doesn't care (hint: users don't care whether the application they're using looks the same on their neighbour's computer, what matters in how it looks on theirs).
Pluggable look&feel and cross-platform consistency is almost never part of any requirement, and I'll trade cross-platform compatibility for a Java P-Invoke instead of JNI anytime.
Not quite. The root cause here is the thunderstorm. Famous sentence here: “There is no reason to fly through a thunderstorm in peacetime". Any pilot knows that entering a Cb cloud (thunderstorm) is basically comitting suicide. Now, if on top on that you're losing your speed indicator, then you're really fucked up, but you called for it. Losing the pitots in clear air is just annoying. Entering a Cb is suicide. Losing the pitots in a Cb is just going to kill you quicker...
You only use ONE screen? Ok... 1990 called, it wants its hardware back.
I typically have my main application maximized on my main screen (Eclipse...), whereas all side applications are left on the secondary screen.
Except that most applications don't care about the kind of GPU being installed. However they care a lot about input devices, screen layout, look-and-feel, available system APIs, network connectivity and so on. All things that have been normalized and didn't change between XP, Vista or Seven making the "fragmentation" of the Windows platform totally irrelevant for >99% of developers.
Here in Belgium you'll typically need to feed the calculator with two numbers: the first one is the bank's reference, while the second one is composed of the target bank account number and the amount of money you're willing to transfer. The way this second number is calculated is emphasized on the website's display. That way, even if a Trojan intercepts the traffic either way, there is nothing it can do except transfering that specific amount of money to that specific account. This only works if you spend the 3 seconds that are required to check that the second code indeed matches your order, but I didn't spot any major flaws with that system.
Slashdot Mirror
I didn't call anyone an idiot. Keep your flamebait away from me.
Clearcase sucks for Java. Anything else sucks for C/C++. Don't even consider Clearcase if you're an Eclipse shop. Don't even consider doing serious C++ job on Git. Just use the right tool and move on.
Will your computer take into account that the small C172 VFR guy just picked the wrong taxiway and is now making you miss your 5minutes slot, and needs to recompute the whole thing? And if you only rely on TCAS, good luck avoiding the PA28 pilot who forgot to turn his transponder on once engaged on the rwy (because you know we need to turn that stuff off when on ground frequency to avoid wrong TCAS alarms from landing airliners). Computers are good, but planes are still piloted by humans...
I mean like supporting writing of shared objects without having to deal with inconsistent mangling approaches between compilers, having to resort to manually-maintained export files? Or having to use the exact same version of the compiler between the library and the code using it? Being able to expose functions throwing exceptions through a library (gasp! who wants to do that?) or to reliabily use an std container through the library interface?
Without all this, you can't write C++ code spliting the logic into multiple binaries in a platform-independant way...
This is the main reason why all libraries are still written in C, or at least expose interfaces in C.
I'm doing a lot of programming interviews these days, and I can tell you that it really doesn't matter.
During interviews I couldn't care less about pointers: I will check problem solving skills, I will assess how they react to existing code they are not familiar with (this is the real challenge you face when getting a new job). I will use good old FizzBuzz test, I will play with basic recursion (insane how most candidates will fail at even the most basic recursive logic). None of this is language specific.
C developers might also be lacking notion of proper data abstraction and will scatter global variables all over the place. This is as bad (if not worse). And believe me, most C developers don't understand memory management neither (is this virtual memory? is this page committed or just reserved in the address space? how comes you get an out of memory in your process and yet you still have tons of free physical memory? what is heap fragmentation? is malloc slow? is it thread-safe? what are heap protection canaries?) A lot of C developers will be using static data with constant size in order to avoid dynamic memory allocation. The result? Java developers are typically more versed in dynamic structures such as double linked lists than C developers...
And by the way, Java has "pointers", we just call them references, and any Java developer worth working with knows the difference between a value-type (int) and a pointer (Integer), they just have different names, you can't assign arbitrary values to your references and you don't need to free them explicitly, that's all.
This could be a slippery slope if this was a new law or a new application of the law, but it is neither of these: this is just the existing application of existing EU laws that exist for, what, 30 years or more? There are very precise and well-understood laws in many countries of Europe stating that yes indeed, it is absolutely forbidden for a company to retain information about EU Citizen that can be processed automatically without these citizens having their say about it. Having that information as part of an index, meta-data or whatever doesn't really matter. You have that kind of information, you must abide by the law. The companies storing personal information are very aware of these laws and have processes in place to cater for the "having their say about it" part. And believe me or not all the newspaper are fully compliant with the law, for many, many decades. And no, this part of Europe (that is, not UK) is not well-known for its strong censorship stance. So there is no problems. At all. What you are depicting here is for some kind of arrogant US company that believes it knows better than the people of Europe how to deal with their own laws. Surprisingly enough, that will not end up well for them.
Hey! SWIFT developer here... We are doing all sorts of crazy stuff, but I can tell you COBOL is none of them. We're mostly a Java/C++ shop.
Sure, and Linux being completely secure this means you need to open a text editor with root privileges each time you visit a website, mmh...
I’m a European expat working in Malaysia. I never heard of WhatsApp before getting into the country one year ago. Now I’m using it every single day. It seems the whole country gave up on SMS and using nothing but WhatsApp for everything from photo sharing to group messaging.
We are probably not talking about the same applications then... Look at "azureus java" or "azureus screenshot" on Google Images and tell what reminds you of Eclipse from that.
I couldn't disagree more: I've been doing SWT development for many years, and I can tell you that SWT applications are impossible to distinguish from native applications, on any platform. Sure Eclipse looks like nothing but Eclipse, but if you take well-written SWT applications (Azureus for instance), no-one would be able to tell you that it is made out of Java. From a user point of view, SWT is just invisible. On a programming point of view, I would agree though: SWT is extremely low-level and the first think you need to put in place is a higher-level API. It has nothing to compare with Swing, which is a real pleasure to develop with. SWT is a pain in the ass, difficult to extend and very difficult to use. So it really depends what matters more to you: the integration of your application with the user desktop and preferences, or the convenience of the development framework itself? One of the (many) reasons why Java never really took off on the desktop is because, unfortunately, many developers chose the latter.
Well it depends, observe how the package explorer tree is actually the native tree widget. How the tables are actually native tables with proper look&feel for the sorting and column resizing. Observe how the menu bar on OS X is actually properly positionned. Observe how the buttons in the configuration sreens, all the scrollbars are native. Notice that drag&drop from and to the desktop or the Windows Explorer actually works, and also proper copy/pasting of files from external applications. These are all these smalls details that make a big difference at the end of the day.
Note that in Java you can get something similar by using SWT, which uses JNI to call the native underlying platform widgets. Used by Eclipse but can be used in a small standalone J2SE application. http://eclipse.org/swt/
There are thirty million Netflix subscribers in the states or about ten percent of the adult population of the US.
Fixed it for you. This represents roughly 0.5% of the World's population. The Internet is meant to be also relevant for the remaining 99.5%...
This requires self-signed applet with full privileges so by using this new security solution I will put my computer at risk. Isn't that great? I would have expected that people working in the security domain would not have the "I don't bother about actual rights I need so let us request full access" attitude.
Sure, so do you prefer a Javascript, C#, Java or Objective-C cross-platform library?
This being said, I never appreciated FSX as much as since I got my PPL license. Sure I can't see my house, but I can actually practice and prepare VFR navigations using the default scenery since the stuff that really matters to the real pilots are is there. I also bought X-Plane to compare and it failed completely: it looks prettier but I almost got lost before leaving the CTR. So I can tell you, from a pilot's point of view, FSX really feels like flying over the landscape since I can use my low-altitude map in the game (and this is my Belgian countryside, not some fancy touristic places).
In practice it never worked, because:
You're right, but reality is never fully black or white. I'm interested into cross-platform compatibility let's say 95% of the time. But I'm perfectly ready to give up the last 5% to please the user and deliver the extra mile in term of platform integration and usesability. This is why we didn't use C# in one of my projects: we wanted cross-platform, but we then selected SWT as we knew (and it turned out the be the right decision) that at some point integration and platform-specific features would be needed.
This is the problem with Java and Swing in particular: to refuse any pragmatism and to sacrifice the end-user experience to the "purity" of the framework. "100% pure Java" is considered to be an ultimate goal within the Java community. This is weird: I've never seen such as thing as "100% pure C# code" or "100% pure C++ code" or whatever. In SWT if I want to use ActiveX on Windows I'm able to do so. Sure this will only work on Windows, but then I'm able to if-then-else my code to offer an alternative implementation on other platforms. I'm able to use application-wide menus on MacOSX. Sure this makes no sense on other platforms but again who cares? Swing prohibits this kind of pragmatism and this is one of the reason, IMHO, why Java never actually took off on the desktop.
This is the whole issue with Swing: this a wonderful piece of software, the best GUI framework I ever worked on. Really. SWT, on the other hand, is inconsistent and difficult to use, brittle at times and indeed full of dirty hacks when you look at the code. And still I'm using SWT because at the end of the day the end-user doesn't care whether the toolkit is nice and neat.
What matters is platform integration: SWT supports Windows 7 jumplists, non-rectangular windows for ages, uses the native file selector (gosh how I hate Swing as a user for this), has a decent native drag&drop, is low on resource consumption, supports other OS plugins such as Windows speech recognition etc... Most importantly, it allows you to get out of the sandbox by directly exposing the underlying platform's APIs. Want to use some Windows-specific effects such as transparency or whatever? Just call OS.sendWindowMessage and you're done. Sure this will cause platform incompatibility but the end-user doesn't care (hint: users don't care whether the application they're using looks the same on their neighbour's computer, what matters in how it looks on theirs).
Pluggable look&feel and cross-platform consistency is almost never part of any requirement, and I'll trade cross-platform compatibility for a Java P-Invoke instead of JNI anytime.
Article dated from May 2010...
Not quite. The root cause here is the thunderstorm. Famous sentence here: “There is no reason to fly through a thunderstorm in peacetime". Any pilot knows that entering a Cb cloud (thunderstorm) is basically comitting suicide. Now, if on top on that you're losing your speed indicator, then you're really fucked up, but you called for it. Losing the pitots in clear air is just annoying. Entering a Cb is suicide. Losing the pitots in a Cb is just going to kill you quicker...
You only use ONE screen? Ok... 1990 called, it wants its hardware back. I typically have my main application maximized on my main screen (Eclipse...), whereas all side applications are left on the secondary screen.
Except that most applications don't care about the kind of GPU being installed. However they care a lot about input devices, screen layout, look-and-feel, available system APIs, network connectivity and so on. All things that have been normalized and didn't change between XP, Vista or Seven making the "fragmentation" of the Windows platform totally irrelevant for >99% of developers.
Here in Belgium you'll typically need to feed the calculator with two numbers: the first one is the bank's reference, while the second one is composed of the target bank account number and the amount of money you're willing to transfer. The way this second number is calculated is emphasized on the website's display. That way, even if a Trojan intercepts the traffic either way, there is nothing it can do except transfering that specific amount of money to that specific account. This only works if you spend the 3 seconds that are required to check that the second code indeed matches your order, but I didn't spot any major flaws with that system.