> There's practically no pain from the procedure if you just relax
Or were the original author of goatse (sorry, I couldn't resist, this is/. after all - and sorry to hear about your medical troubles).
I hope the procedure was successful - for my part I've just been part of a project developing software to manage the records for a bowel cancer programme in my country, the intent is to can get the slow-growing bowel cancer early. I hope the screening system works (I know our software does:) ).
Sometimes though when people abbreviate you can get more than one abbreviation that fits the context. This is worse the more you know, as there are more ways you can see an abbreviation could possibly fit. The solution, of course, is for the original poster (OP) to define the abbreviation the first time they use it. That's a good rule of thumb for technical writing, and just as good on Slashdot too:)
Tried using html p paragraph tags but Slashdot doesn't like it. That's ok you can't be bothered to read it, but I did try and format it (just Slashdot took the formatting away, and unfortunately I can't edit it to correct it).
If you are not documenting and validating the input methods of your methods (regardless of whether they are public or private) then you are making a colossal mistake. How do you know when the maintainer who comes after you is going to refactor the class; answer: you don't. If you are not validating your inputs and thinking out the overall object state when you first write the method just because you're too lazy to then no wonder people like myself are forced to re-invent the code people like you write. I *hate* re-implementing code that other people have done, but it turns out that people that don't design for re-use by others (that is, hide methods that are required to extend functionality while maintaining invariant conditions) are the majority and mistake the contrived examples given in textbooks (showing you how to hide *critical* methods) as examples take this as what should be done for *all* classes.
You are welcome to think I'm full of it. Like I said, I used to think as you do, but with a lot more experience of using other's code I realized how unfriendly this is for third-party devs trying to use your code (who will need to re-use it in ways you never thought of - thanks to their particular requirements). For example, just try extending JavaMail to allow to arbitrarily muck around with MIME mail parts and nest them as you see fit. Turns out the methods you need to do that are all implemented but hidden away, yet looking at the source (thank goodness I had access to it - not always the case) there was no good reason for hiding it away that I could see, apart from it being 'orthodoxy' (which means the author never thought about it too hard, as they probably never had to try using his own code while trying not to access the source, as a user would try to do). In the end I had to wastefully re-write a chunk of Javamail for the clients use. This kind of crap is why 'Not Invented Here' is so prevalent - because orthodox Java development as promoted by the textbooks and circuit speakers goes too far so as to make encapsulation a straightjacket. Some encapsulation is good, but too much is worse than too little, if you know what you are doing (as most professional Java devs do these days - which is why it is so frustrating). Basically I see the excessive hiding of information as an unhelpful 'denial of service' by the author - maybe because they are too damned lazy to document the method, validate its inputs, or test it in isolation (of course getter/setters [accessors/mutators] don't need this level of work), and it sucks when I have to re-implement what they did just because they unnecessarily closed off a few very helpful methods. I'd bet you money that if you've been developing for a while you've had this yourself. One last thing, when developing a class I believe you should always be thinking of how the class could be used in a stand-alone fashion (as any Java Bean can be) without the rest of the machinery of your particular application. The corollary is that the smaller the dependencies (example, choose JRE standard classes like java.util.logging over third party libraries) the easier it is for other people to use. Most Java developers don't try to minimize their library dependencies and think whether each library contributes enough to justify the extra weight, but they should. This is why some small Java programs come with hundreds of extra JAR libraries, some of which have very tenuous utility for the application (and sometimes a single class is used from a library, which brings in a raft of other libraries, when a simple implementation of the simple class would have saved the dependency mire).
I understand what you are saying. I just happen to disagree that methods should be hidden by default. With proper documentation and unit test examples for client developers to follow (you do unit test, don't you?) then trying to 'protect the developer from themselves by hiding functionality' becomes unnecessary - which gives the client more freedom to use more of your classes, and therefore the client
I'm just finishing up my first Android app. It's a simple app, yet several times I've already needed to use reflection to dig around in undocumented APIs or roll my own version of a class included in the framework because of differences between the API versions. I have also found that it is difficult to add functionality to framework classes because Google makes many of the methods either private or final.
Good luck with that app. Yes, unfortunately many Java developers think that good encapsulation means making a lot of stuff private or final. Actually what it often means is that the code is not fit for re-use, you end up re-writing code to do the same stuff that in a more open way and use that. IMHO if you are a Java developer that automatically defaults to private and final methods, forces the use of singletons or factories instead of trying to make POJO JavaBeans which can then be used as singletons (or as ordinary objects, as the need arises) then you ought to consider yourself an orthodox developer that is probably not like by anyone forced to re-use your code.
Part of the problem is the attempt of Java library writers to try and protect the user from themselves. I used to do this but after using so many other libraries over the years I now think this is misguided. Now I try and make POJOs and POJO services whereever I can and make sure I properly Javadoc what needs to happen and also check the preconditions and arguments of all method calls. IMHO I find that in later stages of a project I have access to all sorts of information I need, rather than having to continually go back and publish formerly private methods due to inflexible and closed interfaces. A little bit of encapsulation is good (avoid non-final public members for sure) but that does not mean encapsulating yourself into a straightjacket is good either
Sorry for getting a bit off-topic there, but I hear your pain with the currently 'orthodox' way that Google close their framework off. If there are any Java devs reading out there - keep it POJO if you can and unless you have an extremely good reason for using a private method you should make it public (which also helps unit testing too). And ffs write *meaningful* Javadoc about what can and can't cause usage of the class to fail (eg. preconditions, what argument values are invalid etc).
Lol. Great stories!
Don't forget to check out Google Web Toolkit (GWT) for the web if you haven't already. It has its limitations but it is pretty damn good (and portable, since it uses Java -> Javascript compilation for AJAX without the hassle).
Oh cool, you were one of the Sun team that developed Java then? Otherwise you're like me and used it for 15 years so far. But that is nit picking so let's not go there. Ok, so please tell me how Java's new is not 'dynamic memory', I'm curious how you see them as being different? how does that differ from new or new[] in any way that really matters? Please tell me how Java's int[] foo = new int[1]; differs in any meaningful way from the C++ equivalent (that is, how it is any less dynamic than the C++ equivalent, ignoring the bounds-checking which can be optimized away etc)?
No, I'm no weekend warrior with regard to Java - so trying to pre-empt the argument by claiming longer dev time rather than debating based on the merit of your argument points is not going to work this time. I use it Java daily as a professional consultant, and have used it from embedded systems in scientific devices and radars to Internet-scale applications (thousands of transactions a second), and applications that were required to be *very* reliable and have (soft) real-time constraints. So, while I hear what you are saying, you should listen up too since I'm no n00b either.
I've used C++ on pretty much the same systems you have, and pretty much for as long as you have. On all of these it was *always* a pain to port any C++ program from one system to another and even between different releases of the same compiler, let alone different C++ compilers - and I know and watched what I was doing with regard to portable code and library selection. These days I avoid C++ unless I really have to - the productivity is just so low and I don't need an ego boost to make be feel 'l33t' for using it - since I've done pretty much done everything there is to do with it. So, these days I reach for Java as a first choice since I value language and library simplicity over nearly everything else - my problem domains are complicated enough as it is and project scale so big that complicating it with old-style languages is unnecessary. I also realize that a lot of the code that veterans like you and I produce has to be maintained by teams of lesser minds - and this is an important business consideration for me. In short, I have, as have most other ex-C++ folks, evolved past the point where we see C++ as useful.
Now, you have a point that Java ME is not the greatest, but I confess I'm not an expert in JME. The "Java" these days that people actually use for mobile goes by the marketing name of "Android", and perhaps you could consider that for future "Java vs C++" comparisons. With this one's "productivity" and "features delivered" are much greater than with shitty old C++, which translates to better quality (more time for the testers to do their thing) and lower cost (and surely a 'master' has learned that technical considerations never beat business considerations in this non-deal world?).
> Everybody, apart from you apparently, loathed and despised Java's threading model.
Everybody? I don't think so. The C++ dinosaurs perhaps. Perhaps "Who moved by cheese" should be on the reading list these days. Plus, is there something comparable (and portable!) in C++ to Doug Lea's excellent concurrency library (a standard part of Java these days). Oh that's right, C++ users are still struggling with getting STL to work nicely when they use different compilers (now which pre-processor macros do I have to muddy the code with again?)
Look, C++ is not without some merit, but it turns out that the majority of developers and businesses see Java (or Android) as a better solution than C++. You can call us all fools if you like, but basically even very developers with a similar degree of experience to yourself have made the switch from C++ to Java and got on with producing useful modern applications and embedded systems. Sure, you have decided that Java doesn't work for you personally, cool, but claiming C++ is better is a bit of a stretch - everyone has already decided this is not true for them (even on mobile phones).
Well, GUIs in Java can actually be excellent, and with themes like Nimbus can look superb. There are several factors here:
* if the programmer doesn't know what they are doing with Swing they will block what is known as the Event Dispatch Thread (EDT). Do that and you may get performance issues. On the other hand, if the developer does know what you they are doing with regard to the EDT (or have one of the tools to check this for you) then you can create a multi-threaded GUI that is *very* responsive even for very large tasks.
* Ever since Java 1.6.0u10 all of Java2D (and therefore Swing) has been completely hardware (that is, GPU shader) accelerated. On Windows DirectX shaders are used and everywhere else OpenGL shaders are used. Nicely 'stroked' and anti-aliased text rendering can be a little slow, but that is not noticeable compared to dump programmers blocking the EDT.
Third, in the particular case of Swing it is far more extensible than either WinForms or SWT. I know, I have had to write custom controls for all three and Swing was the easiest by far to extend (again, if you know what you are doing - as in everything in development).
So, perhaps Java GUIs require a bit more skill for new programmers to master, and unfortunately users seeing the interfaces produced by these less experienced developers blame the technology rather than the level of development experience. However, once you get past the n00b stage I reckon Swing is much much better for advanced UI projects than many other toolkits (which are easy for very simple stuff, but are a curse when you actually want to build a serious custom-tailored GUI).
Actually it is write once and run unit tests and integration tests everywhere. If the tests don't pass then it means you coded some platform or JVM dependency in somewhere and it can be removed. Usually verification on Java on other platforms (the analogue of 'porting' in C/C++) is very quick and painless if you have decent coverage of unit and integration tests. Java rocks when you do it right.
Anyone using the "Write once, debug everywhere" mantra should be a Big Red Flag to you that they don't follow modern software development practices (test driven development being especially valuable for *any* system - if someone isn't doing it, or worse, doesn't even know how necessary it is, then you know they have a lot to learn from a professional software *engineering* perspective).
LOL! Your statements are almost all verifiably false. I can see you read articles saying "C++ is better than Java cause it is more obscure and l33t" rather than having to use both on a daily basis.
For example, Java has direct language and library support for concurrency and threading which is vastly better than C++'s non-existing language support and non-standard library support for threading (you need different libraries depending on the platform you are on). Java also most certainly has pointer-like constructs, they just happen to be called 'references' instead of pointers.
The dynamic memory support in Java is vastly better (although non-deterministic in the OpenJDK) than C++, with C++ it is a nightmare to use resources in a multi-threaded application whereas in Java the garbage collector will sort it all out for you (and the new G1 collector is very very efficient). In short, your statements are not true about Java and were not even true of the early (slow) versions of Java, let alone the current versions that leave C++ for dead on current hardware. Next time I would suggest doing some actual reading from both Java proponents (as well as C++ proponents, of course) before posting - especially if you are not a developer or a developer with little experience in *both* languages. As someone who has used C++ for over a decade and Java since it was first released I would say both have their place but in general Java is vastly superior to C++ for many, many reasons (which I won't go into here) and anyone contemplating writing a new project in C++ (or even C#, given the increasingly multi-platform nature of the world) rather than Java really better either have a fantastic reason or is a nutter.
Whenever you hear the word "Android" and it's explosive growth of adoption you should be saying to yourself that this actually means "Java on Linux". Android is a slightly modified version of Java on a customized Linux.
Java is everywhere and runs on just about everything (by design, with exceptions only where it has been kept out for stupid selfish corporate reasons - thank you Mr Jobs [iOS] and Gates [XBox360]). If you are only going to learn one general-purpose programming language then Java is *the* language to learn, even though it doesn't get much press these days (since it is ubiquitous, successful and dependable it doesn't make for good 'scare' or 'ooh, shiny!' stories anymore). Java has a very large market share of modern development (that is, in the enterprise and running the Web, even if people as consumers don't know they are using it behind the scenes).
In case some of the Slashdot readers take the joke (and what used to be true) as the current state of affairs I thought it worth correcting them (otherwise they will have a mistaken view of the *current* performace of the JVM). It turns out today that Java on the Oracle JVM is faster than pretty much every other general-purpose language except for FORTRAN (which is fast 'cause it so simple - which is why FORTRAN programs still dominate much of supercomputing). Don't take my word for it. Take that of James Gosling (a biased source): http://blogs.oracle.com/jag/entry/current_state_of_java_for
and the French supercomputing facilties of INRIA (an unbiased source): http://hal.inria.fr/inria-00312039/en
> Too late now, as it no longer matters if you are paranoid or not.... they are after you anyway.
Yes 'they' are after you. However, you don't have to give your consent to them hoovering up every last piece of info about you (which you pretty much do with Facebook, since FB can be compelled to spill the beans to anyone who needs the information under subpeona, or any of the dodgy laws that have recently been enacted).
What many posters have not grokked is something that is wrong with the pervasive surveillance society is not the information they have on you that is correct, it is the information they have on you that is not correct - and they use that to make erroneous decisions about you. This happens quite frequently but the privacy safeguards at the moment prevent some parts of government accessing this bad data, so the problem doesn't affect you too badly.
Another concrete problem is that even if you do believe there is no issue with the government having information about you and using it - you may well have a problem with corrupt *government employees* selling that data to third parties (eg. using you government health record to give to your insurer, or even to a nosy neighbour or employer). This is not an abstract problem, there are many, many cases where this has happened around the World. By forcing the government to 'silo' its data due to privacy concerns and limit access prevents this from happening easily.
Unfortunately many people on Facebook give the same information away to the World. Fortunately some of the material is only cringe-worthy rather than really personal - but I bet you the statements and activities you make when you are 18 are not what you want the world or your employer to see later on in life. Moglen knows this but it is a shame no-one wants to listen since they think they know better. That's ok, they can make their own mistakes - they just can't say no one told them bad stuff was coming as a result of their short-sightedness.
Perhaps the company was paid by the CIA. Perhaps the company changed direction and saw a market opportunity. Will we ever know?
One thing is for sure, the World needs a lot more fighting of political corruption (in every country). Transparency International (TI) seems a good place to start, as it uses locals in each country, rather than video games. I supposed it would be hard for TI to get a hold in many countries through, including Iran.
Actually when the US withheld weapons during the initial stages of the 1967 'Six Day War' the Israelis decided to create their own defense industry (and supporting scientific facilities). Now many of the innovations that people attribute to the US actually are designed in Israel (mainstream Intel CPUs, helmet-mounted sights, laser weaponry, advanced SAMs). I understand some Israeli politicians would like the US aid to stop since it comes with strings. It is not the US funding that is keeping Israel going - it is the sheer 'bloody-mindedness' of the Israeli citizens that kept them from being overrun (well before the US supplied any money). This bloody-mindedness is both a great strength and a great weakness.
Actually, stuff gets left in patients because surgeons don't use checklists. Apparently think they have fantastic memories and no-one who is not a higher-qualified surgeon is gonna tell them what to do. However, a recent study was done where surgeons took a left from pilot's books and actually started using checklists - the rate of post-operative complications plummeted. The use of checklists has not yet reached widespread use in surgery, AFAIK. I hope it does soon.
I think the question is not whether law enforcement can or can't do their job - I think what is being discussed is which laws should apply to this case.
I agree that defending the rights of a fellow citizen is very important. However, in this case the perpetrator in question was a foreign national 'attacking' 400,000 people of the populace and banking system of another country. His motivation was not for personal financial gain (as existing organized crime legislation presumably handles - I don't know Israeli law) but for the disruption of citizen lives and banking system.
In this case the closest existing laws dealing with an external foreign national attacking the institutions of another country are generally the terrorism laws that most countries have enacted. Now, I don't personally agree with many aspects of those laws, and certainly do not agree with how many of those laws are applied (where enforcement agents routinely ignore the safeguards put in place to preserve the rights of *citizens*), but to me it seems that
* the perpetrator needs to be prosecuted in some way, lest copycat attacks start, and
* the existing terrorism laws and agencies are probably the closest (but not perfect) fit to this 'cyberterrorism' case.
For a citizen then using the terrorism laws for massive credit card theft would be an overkill - I'm with you on that one. For a non-citizen foreign national doing it from foreign territory, then I think that 'cyberterrorism' might not be such a bad term for it - leading to handling as a terrorist event.
What if not one but 400,000 people got robbed (according to the reports)? What if this person wanted to rob everyone in the whole country? but not so much rob for pecuniary gain, but rob to try and screw your population and whole financial system (nb: this is Israel's system we're talking about, not America's - which we can agree needed no outside force to mess up). This was not done by one of your citizens, but by an international agent. Which set of law do you think would be closest to this event? should the government draft a whole set of laws just to cover this one case when existing terrorism laws cover nearly all the same aspects (international jurisdiction, agencies responsible, the powers delegated to them by the government to proceed with their duty, etc etc).
I think I understand your reservation for condemning this (arguably) 'cyberterrorist' act as something other than routine fraud, but I do think this case is different due to the intent of the perpetrator.
My apologies Oswald if you regarded by tone as interrogatory, angry or insulting. It was intended to be open questions for yourself to think very hard about. Again, my it is my sincere regret that you took my statements as a personal accusation.
I believe I understand your position, and thanks for re-clarifying. On one hand I agree with you, I mean, why conflate the leakage of personal financial information with terrorism? isn't that going too far? Perhaps it is.
However I believe just because the crime was not physically violent or threatened with violence does not mean it is not terrorist or have a terrorist-like motivation - which is to cause disruption to the lives of civilians who have no fight with the perpetrator. Sure, it is not terrorism in the 'traditional' sense but if you accept a term of 'cyberterrorism' as having any meaning (I do) then this probably fits under that category. The laws that fit terrorism probably fit cyberterrorism as well, with regard to international jurisdictions, which agencies should do investigation etc. and that is why I believe the Israelis have chosen to try and fit terrorism and cyberterrorism under the same laws, rather than try and shoehorn organized crime laws (which it is not, due to different motivations and breath of affected civilians etc) or create a whole new set of laws that essentially only substitute the word 'terrorism' for 'cyberterrorism'. What should definitely differ is the method of enforcement and the rights of suspects and arrested individuals - which should be more liberal than in the case of physical terrorists (since the cyberterrorists are probably not a danger if they see their lawyer without access to a laptop etc).
So I get why you have made your argument, and agree to the dangerous precedent that using terrorist laws could set. I hope you also get some of my point (even if you disagree) that existing terrorist laws cover most of the legal framework needed to deal with this (especially international cases) where ordinary criminal laws probably don't cut it. I think we could both agree that detainment and enforcement should differ between terrorism and cyberterrorism.
I'm interested to hear your point of view on this.
Oh it could be fixed, but the banks don't want to do this. Much cheaper to write it off as "bad debt" than implement systems that would prevent this (and prevent people's lives from being disrupted/ruined). To be fair, most customers would give you their credit card details for the promise of a $100 voucher (they give away personal details all the time do things like phone credit etc). Customers also don't like even the slightest inconvenience even for much greater security (if more than one authentication method is involved).
Slashdot Mirror
> The most terrifying thing must be knowing (or not knowing) when the shit volcano is finally over.
Would that be Krapatoa ?
> There's practically no pain from the procedure if you just relax /. after all - and sorry to hear about your medical troubles). :) ).
Or were the original author of goatse (sorry, I couldn't resist, this is
I hope the procedure was successful - for my part I've just been part of a project developing software to manage the records for a bowel cancer programme in my country, the intent is to can get the slow-growing bowel cancer early. I hope the screening system works (I know our software does
Totally off-topic, and it's just a part of your job I suppose, but thanks for making stuff that helps people in such a direct way.
This leap is the same as going off a cliff. Use Java please.
lol. The 12 years were probably getting *one* project out ... just kidding.
Sometimes though when people abbreviate you can get more than one abbreviation that fits the context. This is worse the more you know, as there are more ways you can see an abbreviation could possibly fit. The solution, of course, is for the original poster (OP) to define the abbreviation the first time they use it. That's a good rule of thumb for technical writing, and just as good on Slashdot too :)
Tried using html p paragraph tags but Slashdot doesn't like it. That's ok you can't be bothered to read it, but I did try and format it (just Slashdot took the formatting away, and unfortunately I can't edit it to correct it).
If you are not documenting and validating the input methods of your methods (regardless of whether they are public or private) then you are making a colossal mistake. How do you know when the maintainer who comes after you is going to refactor the class; answer: you don't. If you are not validating your inputs and thinking out the overall object state when you first write the method just because you're too lazy to then no wonder people like myself are forced to re-invent the code people like you write. I *hate* re-implementing code that other people have done, but it turns out that people that don't design for re-use by others (that is, hide methods that are required to extend functionality while maintaining invariant conditions) are the majority and mistake the contrived examples given in textbooks (showing you how to hide *critical* methods) as examples take this as what should be done for *all* classes.
You are welcome to think I'm full of it. Like I said, I used to think as you do, but with a lot more experience of using other's code I realized how unfriendly this is for third-party devs trying to use your code (who will need to re-use it in ways you never thought of - thanks to their particular requirements). For example, just try extending JavaMail to allow to arbitrarily muck around with MIME mail parts and nest them as you see fit. Turns out the methods you need to do that are all implemented but hidden away, yet looking at the source (thank goodness I had access to it - not always the case) there was no good reason for hiding it away that I could see, apart from it being 'orthodoxy' (which means the author never thought about it too hard, as they probably never had to try using his own code while trying not to access the source, as a user would try to do). In the end I had to wastefully re-write a chunk of Javamail for the clients use. This kind of crap is why 'Not Invented Here' is so prevalent - because orthodox Java development as promoted by the textbooks and circuit speakers goes too far so as to make encapsulation a straightjacket. Some encapsulation is good, but too much is worse than too little, if you know what you are doing (as most professional Java devs do these days - which is why it is so frustrating). Basically I see the excessive hiding of information as an unhelpful 'denial of service' by the author - maybe because they are too damned lazy to document the method, validate its inputs, or test it in isolation (of course getter/setters [accessors/mutators] don't need this level of work), and it sucks when I have to re-implement what they did just because they unnecessarily closed off a few very helpful methods. I'd bet you money that if you've been developing for a while you've had this yourself. One last thing, when developing a class I believe you should always be thinking of how the class could be used in a stand-alone fashion (as any Java Bean can be) without the rest of the machinery of your particular application. The corollary is that the smaller the dependencies (example, choose JRE standard classes like java.util.logging over third party libraries) the easier it is for other people to use. Most Java developers don't try to minimize their library dependencies and think whether each library contributes enough to justify the extra weight, but they should. This is why some small Java programs come with hundreds of extra JAR libraries, some of which have very tenuous utility for the application (and sometimes a single class is used from a library, which brings in a raft of other libraries, when a simple implementation of the simple class would have saved the dependency mire).
I understand what you are saying. I just happen to disagree that methods should be hidden by default. With proper documentation and unit test examples for client developers to follow (you do unit test, don't you?) then trying to 'protect the developer from themselves by hiding functionality' becomes unnecessary - which gives the client more freedom to use more of your classes, and therefore the client
I'm just finishing up my first Android app. It's a simple app, yet several times I've already needed to use reflection to dig around in undocumented APIs or roll my own version of a class included in the framework because of differences between the API versions. I have also found that it is difficult to add functionality to framework classes because Google makes many of the methods either private or final.
Good luck with that app. Yes, unfortunately many Java developers think that good encapsulation means making a lot of stuff private or final. Actually what it often means is that the code is not fit for re-use, you end up re-writing code to do the same stuff that in a more open way and use that. IMHO if you are a Java developer that automatically defaults to private and final methods, forces the use of singletons or factories instead of trying to make POJO JavaBeans which can then be used as singletons (or as ordinary objects, as the need arises) then you ought to consider yourself an orthodox developer that is probably not like by anyone forced to re-use your code.
Part of the problem is the attempt of Java library writers to try and protect the user from themselves. I used to do this but after using so many other libraries over the years I now think this is misguided. Now I try and make POJOs and POJO services whereever I can and make sure I properly Javadoc what needs to happen and also check the preconditions and arguments of all method calls. IMHO I find that in later stages of a project I have access to all sorts of information I need, rather than having to continually go back and publish formerly private methods due to inflexible and closed interfaces. A little bit of encapsulation is good (avoid non-final public members for sure) but that does not mean encapsulating yourself into a straightjacket is good either
Sorry for getting a bit off-topic there, but I hear your pain with the currently 'orthodox' way that Google close their framework off. If there are any Java devs reading out there - keep it POJO if you can and unless you have an extremely good reason for using a private method you should make it public (which also helps unit testing too). And ffs write *meaningful* Javadoc about what can and can't cause usage of the class to fail (eg. preconditions, what argument values are invalid etc).
Lol. Great stories!
Don't forget to check out Google Web Toolkit (GWT) for the web if you haven't already. It has its limitations but it is pretty damn good (and portable, since it uses Java -> Javascript compilation for AJAX without the hassle).
Oh cool, you were one of the Sun team that developed Java then? Otherwise you're like me and used it for 15 years so far. But that is nit picking so let's not go there. Ok, so please tell me how Java's new is not 'dynamic memory', I'm curious how you see them as being different? how does that differ from new or new[] in any way that really matters? Please tell me how Java's int[] foo = new int[1]; differs in any meaningful way from the C++ equivalent (that is, how it is any less dynamic than the C++ equivalent, ignoring the bounds-checking which can be optimized away etc)?
No, I'm no weekend warrior with regard to Java - so trying to pre-empt the argument by claiming longer dev time rather than debating based on the merit of your argument points is not going to work this time. I use it Java daily as a professional consultant, and have used it from embedded systems in scientific devices and radars to Internet-scale applications (thousands of transactions a second), and applications that were required to be *very* reliable and have (soft) real-time constraints. So, while I hear what you are saying, you should listen up too since I'm no n00b either.
I've used C++ on pretty much the same systems you have, and pretty much for as long as you have. On all of these it was *always* a pain to port any C++ program from one system to another and even between different releases of the same compiler, let alone different C++ compilers - and I know and watched what I was doing with regard to portable code and library selection. These days I avoid C++ unless I really have to - the productivity is just so low and I don't need an ego boost to make be feel 'l33t' for using it - since I've done pretty much done everything there is to do with it. So, these days I reach for Java as a first choice since I value language and library simplicity over nearly everything else - my problem domains are complicated enough as it is and project scale so big that complicating it with old-style languages is unnecessary. I also realize that a lot of the code that veterans like you and I produce has to be maintained by teams of lesser minds - and this is an important business consideration for me. In short, I have, as have most other ex-C++ folks, evolved past the point where we see C++ as useful.
Now, you have a point that Java ME is not the greatest, but I confess I'm not an expert in JME. The "Java" these days that people actually use for mobile goes by the marketing name of "Android", and perhaps you could consider that for future "Java vs C++" comparisons. With this one's "productivity" and "features delivered" are much greater than with shitty old C++, which translates to better quality (more time for the testers to do their thing) and lower cost (and surely a 'master' has learned that technical considerations never beat business considerations in this non-deal world?).
> Everybody, apart from you apparently, loathed and despised Java's threading model.
Everybody? I don't think so. The C++ dinosaurs perhaps. Perhaps "Who moved by cheese" should be on the reading list these days. Plus, is there something comparable (and portable!) in C++ to Doug Lea's excellent concurrency library (a standard part of Java these days). Oh that's right, C++ users are still struggling with getting STL to work nicely when they use different compilers (now which pre-processor macros do I have to muddy the code with again?)
Look, C++ is not without some merit, but it turns out that the majority of developers and businesses see Java (or Android) as a better solution than C++. You can call us all fools if you like, but basically even very developers with a similar degree of experience to yourself have made the switch from C++ to Java and got on with producing useful modern applications and embedded systems. Sure, you have decided that Java doesn't work for you personally, cool, but claiming C++ is better is a bit of a stretch - everyone has already decided this is not true for them (even on mobile phones).
* if the programmer doesn't know what they are doing with Swing they will block what is known as the Event Dispatch Thread (EDT). Do that and you may get performance issues. On the other hand, if the developer does know what you they are doing with regard to the EDT (or have one of the tools to check this for you) then you can create a multi-threaded GUI that is *very* responsive even for very large tasks.
* Ever since Java 1.6.0u10 all of Java2D (and therefore Swing) has been completely hardware (that is, GPU shader) accelerated. On Windows DirectX shaders are used and everywhere else OpenGL shaders are used. Nicely 'stroked' and anti-aliased text rendering can be a little slow, but that is not noticeable compared to dump programmers blocking the EDT.
Third, in the particular case of Swing it is far more extensible than either WinForms or SWT. I know, I have had to write custom controls for all three and Swing was the easiest by far to extend (again, if you know what you are doing - as in everything in development).
So, perhaps Java GUIs require a bit more skill for new programmers to master, and unfortunately users seeing the interfaces produced by these less experienced developers blame the technology rather than the level of development experience. However, once you get past the n00b stage I reckon Swing is much much better for advanced UI projects than many other toolkits (which are easy for very simple stuff, but are a curse when you actually want to build a serious custom-tailored GUI).
Anyone using the "Write once, debug everywhere" mantra should be a Big Red Flag to you that they don't follow modern software development practices (test driven development being especially valuable for *any* system - if someone isn't doing it, or worse, doesn't even know how necessary it is, then you know they have a lot to learn from a professional software *engineering* perspective).
For example, Java has direct language and library support for concurrency and threading which is vastly better than C++'s non-existing language support and non-standard library support for threading (you need different libraries depending on the platform you are on). Java also most certainly has pointer-like constructs, they just happen to be called 'references' instead of pointers.
The dynamic memory support in Java is vastly better (although non-deterministic in the OpenJDK) than C++, with C++ it is a nightmare to use resources in a multi-threaded application whereas in Java the garbage collector will sort it all out for you (and the new G1 collector is very very efficient). In short, your statements are not true about Java and were not even true of the early (slow) versions of Java, let alone the current versions that leave C++ for dead on current hardware. Next time I would suggest doing some actual reading from both Java proponents (as well as C++ proponents, of course) before posting - especially if you are not a developer or a developer with little experience in *both* languages. As someone who has used C++ for over a decade and Java since it was first released I would say both have their place but in general Java is vastly superior to C++ for many, many reasons (which I won't go into here) and anyone contemplating writing a new project in C++ (or even C#, given the increasingly multi-platform nature of the world) rather than Java really better either have a fantastic reason or is a nutter.
Whenever you hear the word "Android" and it's explosive growth of adoption you should be saying to yourself that this actually means "Java on Linux". Android is a slightly modified version of Java on a customized Linux.
Java is everywhere and runs on just about everything (by design, with exceptions only where it has been kept out for stupid selfish corporate reasons - thank you Mr Jobs [iOS] and Gates [XBox360]). If you are only going to learn one general-purpose programming language then Java is *the* language to learn, even though it doesn't get much press these days (since it is ubiquitous, successful and dependable it doesn't make for good 'scare' or 'ooh, shiny!' stories anymore). Java has a very large market share of modern development (that is, in the enterprise and running the Web, even if people as consumers don't know they are using it behind the scenes).
In case some of the Slashdot readers take the joke (and what used to be true) as the current state of affairs I thought it worth correcting them (otherwise they will have a mistaken view of the *current* performace of the JVM). It turns out today that Java on the Oracle JVM is faster than pretty much every other general-purpose language except for FORTRAN (which is fast 'cause it so simple - which is why FORTRAN programs still dominate much of supercomputing). Don't take my word for it. Take that of James Gosling (a biased source):
http://blogs.oracle.com/jag/entry/current_state_of_java_for
and the French supercomputing facilties of INRIA (an unbiased source):
http://hal.inria.fr/inria-00312039/en
Yes 'they' are after you. However, you don't have to give your consent to them hoovering up every last piece of info about you (which you pretty much do with Facebook, since FB can be compelled to spill the beans to anyone who needs the information under subpeona, or any of the dodgy laws that have recently been enacted).
What many posters have not grokked is something that is wrong with the pervasive surveillance society is not the information they have on you that is correct, it is the information they have on you that is not correct - and they use that to make erroneous decisions about you. This happens quite frequently but the privacy safeguards at the moment prevent some parts of government accessing this bad data, so the problem doesn't affect you too badly.
Another concrete problem is that even if you do believe there is no issue with the government having information about you and using it - you may well have a problem with corrupt *government employees* selling that data to third parties (eg. using you government health record to give to your insurer, or even to a nosy neighbour or employer). This is not an abstract problem, there are many, many cases where this has happened around the World. By forcing the government to 'silo' its data due to privacy concerns and limit access prevents this from happening easily.
Unfortunately many people on Facebook give the same information away to the World. Fortunately some of the material is only cringe-worthy rather than really personal - but I bet you the statements and activities you make when you are 18 are not what you want the world or your employer to see later on in life. Moglen knows this but it is a shame no-one wants to listen since they think they know better. That's ok, they can make their own mistakes - they just can't say no one told them bad stuff was coming as a result of their short-sightedness.
One thing is for sure, the World needs a lot more fighting of political corruption (in every country). Transparency International (TI) seems a good place to start, as it uses locals in each country, rather than video games. I supposed it would be hard for TI to get a hold in many countries through, including Iran.
Actually when the US withheld weapons during the initial stages of the 1967 'Six Day War' the Israelis decided to create their own defense industry (and supporting scientific facilities). Now many of the innovations that people attribute to the US actually are designed in Israel (mainstream Intel CPUs, helmet-mounted sights, laser weaponry, advanced SAMs). I understand some Israeli politicians would like the US aid to stop since it comes with strings. It is not the US funding that is keeping Israel going - it is the sheer 'bloody-mindedness' of the Israeli citizens that kept them from being overrun (well before the US supplied any money). This bloody-mindedness is both a great strength and a great weakness.
Actually, stuff gets left in patients because surgeons don't use checklists. Apparently think they have fantastic memories and no-one who is not a higher-qualified surgeon is gonna tell them what to do. However, a recent study was done where surgeons took a left from pilot's books and actually started using checklists - the rate of post-operative complications plummeted. The use of checklists has not yet reached widespread use in surgery, AFAIK. I hope it does soon.
lol. What brain! :)
I agree that defending the rights of a fellow citizen is very important. However, in this case the perpetrator in question was a foreign national 'attacking' 400,000 people of the populace and banking system of another country. His motivation was not for personal financial gain (as existing organized crime legislation presumably handles - I don't know Israeli law) but for the disruption of citizen lives and banking system.
In this case the closest existing laws dealing with an external foreign national attacking the institutions of another country are generally the terrorism laws that most countries have enacted. Now, I don't personally agree with many aspects of those laws, and certainly do not agree with how many of those laws are applied (where enforcement agents routinely ignore the safeguards put in place to preserve the rights of *citizens*), but to me it seems that
* the perpetrator needs to be prosecuted in some way, lest copycat attacks start, and
* the existing terrorism laws and agencies are probably the closest (but not perfect) fit to this 'cyberterrorism' case.
For a citizen then using the terrorism laws for massive credit card theft would be an overkill - I'm with you on that one. For a non-citizen foreign national doing it from foreign territory, then I think that 'cyberterrorism' might not be such a bad term for it - leading to handling as a terrorist event.
I think I understand your reservation for condemning this (arguably) 'cyberterrorist' act as something other than routine fraud, but I do think this case is different due to the intent of the perpetrator.
I believe I understand your position, and thanks for re-clarifying. On one hand I agree with you, I mean, why conflate the leakage of personal financial information with terrorism? isn't that going too far? Perhaps it is.
However I believe just because the crime was not physically violent or threatened with violence does not mean it is not terrorist or have a terrorist-like motivation - which is to cause disruption to the lives of civilians who have no fight with the perpetrator. Sure, it is not terrorism in the 'traditional' sense but if you accept a term of 'cyberterrorism' as having any meaning (I do) then this probably fits under that category. The laws that fit terrorism probably fit cyberterrorism as well, with regard to international jurisdictions, which agencies should do investigation etc. and that is why I believe the Israelis have chosen to try and fit terrorism and cyberterrorism under the same laws, rather than try and shoehorn organized crime laws (which it is not, due to different motivations and breath of affected civilians etc) or create a whole new set of laws that essentially only substitute the word 'terrorism' for 'cyberterrorism'. What should definitely differ is the method of enforcement and the rights of suspects and arrested individuals - which should be more liberal than in the case of physical terrorists (since the cyberterrorists are probably not a danger if they see their lawyer without access to a laptop etc).
So I get why you have made your argument, and agree to the dangerous precedent that using terrorist laws could set. I hope you also get some of my point (even if you disagree) that existing terrorist laws cover most of the legal framework needed to deal with this (especially international cases) where ordinary criminal laws probably don't cut it. I think we could both agree that detainment and enforcement should differ between terrorism and cyberterrorism.
I'm interested to hear your point of view on this.
Oh it could be fixed, but the banks don't want to do this. Much cheaper to write it off as "bad debt" than implement systems that would prevent this (and prevent people's lives from being disrupted/ruined). To be fair, most customers would give you their credit card details for the promise of a $100 voucher (they give away personal details all the time do things like phone credit etc). Customers also don't like even the slightest inconvenience even for much greater security (if more than one authentication method is involved).