Yep. I learnt that lesson too when recording astronomical observations for research. You must design your software to *automatically* put in *all* the relevant information - just in case you need it. Rely on a human to put it in and you get mistakes that take a huge amount of time to untangle (if at all possible, sometimes you just don't have enough information to deconflict bad human-recorded values). My general rule is, "Never lose information". Once information has been thrown away it becomes a huge effort to try reconstruct it. Better to always keep as much as you can around to begin with. This is where using database to record 'state' stuff makes sense, and then have that point to the data files that are too big to go in the database. Then you can slice-and-dice the database tables as you need to. As a researcher I avoided writing software to existing databases (I now love Postgresql) but I wished I'd used Postgresql a lot earlier.
Believe me, when you are working on image processing, or scientific software, or research software, or hardware integration, or real-time systems, or massive internet-scale software (as I have) you get *hard* problems. The run of the mill web and CRUD stuff is nothing in comparison.
My point was, if you are in a zone and *concentrating on solving **hard** problems and getting it right the first time* you simply can't do it for 20 hours. No one can can solve the really complex problems like that for twenty hours straight.
Two decades ago I could code for 20 hours thinking I was being real productive in the 'zone'. It was only later I realized that such 'heroic coding' stints are a complete crock and the best coders don't need to do them, only the n00b-ish.
Oh sure, you can do easier stuff (like boilerplate or routine coding) for 20 hours no sweat, but people who can do that are a dime a dozen (just ask all the willing bodies in Bangalore). Solving hard problems is non-linear in effort, just as anyone can run a marathon slow but even the greatest athletics are exhausted if they run hard (sprint) for 10 seconds.
Agree completely. I find I need two solid blocks of 4 hours coding to be most productive. Past this I produce code but I spend the next day fixing it up instead of getting it almost all right first time.
If you can 'code' for 20 hour stints then you're:
a) clearly not concentrating with all your might
b) producing crap code
c) probably producing mindless boilerplate instead of figuring out a smarter way
d) missing out, there ought to be worth more to your life than work, and finally
e) a fool, only other fools (poor management and other poor coders) think that long stints are 'heroic' rather than counterproductive in the long term.
Yes, the legal aspect is important. The judiciary in Chile now have a solid guideline on how they should interpret the law (which is, in the interests of Net Neutrality).
Mining the seafloor would be a local ecological disaster. A great deal of thought needs to be put in to how disrupting the sea floor would affect the entire food chain. Unfortunately the Chinese record on such things is not very good - witness the devastation caused by deforestation and flooding in areas affected by the Three Gorges Dam project.
Yes! At the point a problem is detected all the information about the problem is known and ought to be reported. After that point the relevant information that could fix the problem may be lost. Well-written (and tested) programs only die if they get bad input, since the code will be good. You can't always know that input is bad initially but as soon as it becomes a problem you must report a relevant statement of the problem, the bad value and its name (especially if there are multiple calls on the line, eg. chained method calls) and probably the limits of value values (not null, non-negative, between some range, can only be "Fred" or "Susan" etc). Coupled with a stack trace that is a lot more information than most programmers give to to those that maintain their code. Trying to fix someone else's bug is bad enough, but when they are too damned lazy to report problems properly (or even check in the first place - you should never get a NullPointerException in Java ever, good programs pretty much deal with IllegalArgumentException, IllegalStateException an resource exceptions, eg. IOException before they're transformed to application-level *unchecked* exceptions).
Of course I've done C# you arrogant git, as part of my 20 year software development career. I just found it had poor portability for the parts of the library I needed - and I found Java solved my problems on whatever platform I chose and whatever application domain I was in. The world is not only desktop apps on Windows, Mac and Linux you know. By and large I find it is Windows aficionados that lack the experience in other systems and problem domains.
Recruiters? If you have the right skills you get headhunted. I won't start on what those enterprise-handy skills are.
Good luck with your job hunting in the future.
Meh. You're still stuck with Windows whether you (or your customer) likes it or not. C# is good, but Java on Netbeans will run wherever *you* want to be: Windows, Linux, Mac OS X, real UNIX, Android, Symbian, embedded Linux (I've developed for that and it worked well) etc etc
C#s goodness doesn't mitigate the fact that it is non-portable, and portability is starting to matter again these days.
Actually, according to the Tiobe index there's about 400% more Java out there. Since C# and Java are more similar than different viz-a-viz other languages (no suprise, C# is the Microsoft evolution of Java via the intermediate development language "Cool").
Yeah. The Morder and Unearthly (dessert pizza!) are simply superb. Many a late night spent gaming powered by that combo - just what you need for the freshly-minted Starcraft II.
Mate, you should try a Hell pizza. They are completely awesome. The website used to have pictures of the pizzas and they not like Italian/American pizzas at all as they have a large number of ingredients on top (not just cheese, pizza sauce and peperoni). My favourite is the "Mordor" and if you ever get to NZ you ought to try it. The other excellent pizza is the 'Unearthly' dessert pizza - sooo good.
Use NetBeans. I use both NetBeans (by choice) and Eclipse (by necessity, for work) and find Eclipse to be powerful but it is unstable and has a truly awful interface (that only IBM could love!) from a usability point-of-view. NetBeans is much simpler and straightforward to get things done.
Actually DirectSound is deprecated and OpenAL is recommended (IRCC, by Microsoft no less). That means you are in the same boat with OpenGL as DirectX.
OpenAL is a good portable choice in the same way OpenGL is, and OpenAL has been very widely used.
Input is something DirectX is good at - although the input interface has changed over the years, so you've had as much work as with OpenGL (which can also be used with the myriad of libraries SDL/JoGL etc).
The flight simulator Il-2 has the choice of switching between OpenGL or Direct X. In fact, it is also written mostly in Java with much of the graphics in C++. This allowed it to be ported to the console in the form of Wings of Prey. The flexibility of OpenGL allowed this company to port easily, and made them money.
The flight simulator X-Plane (now taking the crown for civilian flight simulators since Microsoft has shut down the studio that produced the Flight Simulator line) uses OpenGL. It's creator says in an interview that the choice of OpenGL was the correct one since he was able to port his product to the iPhone in a matter of weeks. This meant he personally got around 3.5 million US dollars in revenue in around a month. OpenGL made sound business sense to him. Here's the interview with him if you are interested:
http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/
If you want to make money on the iPhone/iPad, Android, Windows, Linux, Mac, Unix workstation visualization, embedded electronics such as FAA approved in-cockpit instruments etc then OpenGL is the correct choice. If OpenGL didn't run on Windows then clearly it would be a bad choice, but the fact is OpenGL works well on Windows *and* just about every other platform too. This includes games.
DirectX may be just as good technically but the fact that it is not portable means it is a non-starter for many applications for both technical and commercial reasons.
Brilliant observation!
That is a problem with the pure Object Oriented style of code written by the typical Java Enterprise Programmer. Unfortunately all CompSci graduates all seem to produce this style of (crappy) code. I guess that is what the frameworks and textbooks show for pattern illustration, but it is a terrible style. However, this is not a fundamental flaw of the language itself (although it permeates most of the libraries).
It is possible to simplify your code somewhat by consciously adopting a different style, that is POJO/Bean oriented and slightly more procedural.
Also, if you take the 'simplify your code' mindeset rather than the 'purist O-O jihadi' approach (typical of Computer Scientists) you get a philosophy and code that is quite different. See BeanKeeper as an example of a library that rejects all the unnecessary constructs of man persistence frameworks. While BeanKeeper isn't perfect it is a step in the correct direction for Java.
C++ is a multi-threaded environment with shared resources is vastly harder than Java. That's what makes the garbage collector worthwhile. I agree that using the stack where possible with your scoped classes is good, but sometimes you just gotta use the heap, shared the object around between threads and synchronize your resources. Then you're told you have to make it work on the Mac, Windows and the Linux servers, but don't have time to integrate three sets of libraries. See where Java might be useful now?
Slashdot Mirror
Yep. I learnt that lesson too when recording astronomical observations for research. You must design your software to *automatically* put in *all* the relevant information - just in case you need it. Rely on a human to put it in and you get mistakes that take a huge amount of time to untangle (if at all possible, sometimes you just don't have enough information to deconflict bad human-recorded values). My general rule is, "Never lose information". Once information has been thrown away it becomes a huge effort to try reconstruct it. Better to always keep as much as you can around to begin with. This is where using database to record 'state' stuff makes sense, and then have that point to the data files that are too big to go in the database. Then you can slice-and-dice the database tables as you need to. As a researcher I avoided writing software to existing databases (I now love Postgresql) but I wished I'd used Postgresql a lot earlier.
Believe me, when you are working on image processing, or scientific software, or research software, or hardware integration, or real-time systems, or massive internet-scale software (as I have) you get *hard* problems. The run of the mill web and CRUD stuff is nothing in comparison.
My point was, if you are in a zone and *concentrating on solving **hard** problems and getting it right the first time* you simply can't do it for 20 hours. No one can can solve the really complex problems like that for twenty hours straight. Two decades ago I could code for 20 hours thinking I was being real productive in the 'zone'. It was only later I realized that such 'heroic coding' stints are a complete crock and the best coders don't need to do them, only the n00b-ish. Oh sure, you can do easier stuff (like boilerplate or routine coding) for 20 hours no sweat, but people who can do that are a dime a dozen (just ask all the willing bodies in Bangalore). Solving hard problems is non-linear in effort, just as anyone can run a marathon slow but even the greatest athletics are exhausted if they run hard (sprint) for 10 seconds.
Agree completely. I find I need two solid blocks of 4 hours coding to be most productive. Past this I produce code but I spend the next day fixing it up instead of getting it almost all right first time. If you can 'code' for 20 hour stints then you're: a) clearly not concentrating with all your might b) producing crap code c) probably producing mindless boilerplate instead of figuring out a smarter way d) missing out, there ought to be worth more to your life than work, and finally e) a fool, only other fools (poor management and other poor coders) think that long stints are 'heroic' rather than counterproductive in the long term.
Yes, the legal aspect is important. The judiciary in Chile now have a solid guideline on how they should interpret the law (which is, in the interests of Net Neutrality).
Mining the seafloor would be a local ecological disaster. A great deal of thought needs to be put in to how disrupting the sea floor would affect the entire food chain. Unfortunately the Chinese record on such things is not very good - witness the devastation caused by deforestation and flooding in areas affected by the Three Gorges Dam project.
Yes! At the point a problem is detected all the information about the problem is known and ought to be reported. After that point the relevant information that could fix the problem may be lost. Well-written (and tested) programs only die if they get bad input, since the code will be good. You can't always know that input is bad initially but as soon as it becomes a problem you must report a relevant statement of the problem, the bad value and its name (especially if there are multiple calls on the line, eg. chained method calls) and probably the limits of value values (not null, non-negative, between some range, can only be "Fred" or "Susan" etc). Coupled with a stack trace that is a lot more information than most programmers give to to those that maintain their code. Trying to fix someone else's bug is bad enough, but when they are too damned lazy to report problems properly (or even check in the first place - you should never get a NullPointerException in Java ever, good programs pretty much deal with IllegalArgumentException, IllegalStateException an resource exceptions, eg. IOException before they're transformed to application-level *unchecked* exceptions).
Agreed. Still, being headhunted beats using recruiters for jobs.
Of course I've done C# you arrogant git, as part of my 20 year software development career. I just found it had poor portability for the parts of the library I needed - and I found Java solved my problems on whatever platform I chose and whatever application domain I was in. The world is not only desktop apps on Windows, Mac and Linux you know. By and large I find it is Windows aficionados that lack the experience in other systems and problem domains.
Recruiters? If you have the right skills you get headhunted. I won't start on what those enterprise-handy skills are. Good luck with your job hunting in the future.
Meh. You're still stuck with Windows whether you (or your customer) likes it or not. C# is good, but Java on Netbeans will run wherever *you* want to be: Windows, Linux, Mac OS X, real UNIX, Android, Symbian, embedded Linux (I've developed for that and it worked well) etc etc C#s goodness doesn't mitigate the fact that it is non-portable, and portability is starting to matter again these days.
Jeffrey Dahmer was working on it..
Yeah, but who wants to work at Microsoft these days? (well, unless your looking for an entry visa to the US)
Plus Java has BeanShell and Rhino.
You forgot to mention: .... and Android, and anywhere with a C compiler (so GCJ runs).
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
With the diversity of platforms starting to increase again the one-platform pony of C# would be a more restrictive choice than Java.
Agreed. You could say, "it's all gone to hell lately".
Yeah. The Morder and Unearthly (dessert pizza!) are simply superb. Many a late night spent gaming powered by that combo - just what you need for the freshly-minted Starcraft II.
Mate, you should try a Hell pizza. They are completely awesome. The website used to have pictures of the pizzas and they not like Italian/American pizzas at all as they have a large number of ingredients on top (not just cheese, pizza sauce and peperoni). My favourite is the "Mordor" and if you ever get to NZ you ought to try it. The other excellent pizza is the 'Unearthly' dessert pizza - sooo good.
Use NetBeans. I use both NetBeans (by choice) and Eclipse (by necessity, for work) and find Eclipse to be powerful but it is unstable and has a truly awful interface (that only IBM could love!) from a usability point-of-view. NetBeans is much simpler and straightforward to get things done.
FYI: Java will run on platforms that support C. Please see GNU gcj and the Classpath project.
Actually DirectSound is deprecated and OpenAL is recommended (IRCC, by Microsoft no less). That means you are in the same boat with OpenGL as DirectX. OpenAL is a good portable choice in the same way OpenGL is, and OpenAL has been very widely used. Input is something DirectX is good at - although the input interface has changed over the years, so you've had as much work as with OpenGL (which can also be used with the myriad of libraries SDL/JoGL etc).
The flight simulator Il-2 has the choice of switching between OpenGL or Direct X. In fact, it is also written mostly in Java with much of the graphics in C++. This allowed it to be ported to the console in the form of Wings of Prey. The flexibility of OpenGL allowed this company to port easily, and made them money.
The flight simulator X-Plane (now taking the crown for civilian flight simulators since Microsoft has shut down the studio that produced the Flight Simulator line) uses OpenGL. It's creator says in an interview that the choice of OpenGL was the correct one since he was able to port his product to the iPhone in a matter of weeks. This meant he personally got around 3.5 million US dollars in revenue in around a month. OpenGL made sound business sense to him. Here's the interview with him if you are interested: http://techhaze.com/2010/03/interview-with-x-plane-creator-austin-meyer/
If you want to make money on the iPhone/iPad, Android, Windows, Linux, Mac, Unix workstation visualization, embedded electronics such as FAA approved in-cockpit instruments etc then OpenGL is the correct choice. If OpenGL didn't run on Windows then clearly it would be a bad choice, but the fact is OpenGL works well on Windows *and* just about every other platform too. This includes games.
DirectX may be just as good technically but the fact that it is not portable means it is a non-starter for many applications for both technical and commercial reasons.
Brilliant observation! That is a problem with the pure Object Oriented style of code written by the typical Java Enterprise Programmer. Unfortunately all CompSci graduates all seem to produce this style of (crappy) code. I guess that is what the frameworks and textbooks show for pattern illustration, but it is a terrible style. However, this is not a fundamental flaw of the language itself (although it permeates most of the libraries). It is possible to simplify your code somewhat by consciously adopting a different style, that is POJO/Bean oriented and slightly more procedural. Also, if you take the 'simplify your code' mindeset rather than the 'purist O-O jihadi' approach (typical of Computer Scientists) you get a philosophy and code that is quite different. See BeanKeeper as an example of a library that rejects all the unnecessary constructs of man persistence frameworks. While BeanKeeper isn't perfect it is a step in the correct direction for Java.
C++ is a multi-threaded environment with shared resources is vastly harder than Java. That's what makes the garbage collector worthwhile. I agree that using the stack where possible with your scoped classes is good, but sometimes you just gotta use the heap, shared the object around between threads and synchronize your resources. Then you're told you have to make it work on the Mac, Windows and the Linux servers, but don't have time to integrate three sets of libraries. See where Java might be useful now?