So there are hundreds of developers working on the Linux kernel? Given the non-monolithic nature of the kernel that's hardly a surprising number. The value add of the Linux kernel is that it forms the basis of an operating system, not a distro. Of course, most folks don't really understand that Linux is the kernel, not a distro.
How are you defining a contributor in the distro sense? Someone who writes an apt-get GUI for a Debian-based distro (for example)? Someone who tests the installation and operation of the distro? Someone who compiles and publishes the distro?
If you're counting the authors of the various packages (such as ethereal, ls, vim, etc.) that comprise a distro as "contributors", then your premise is invalid. That sort of fuzzy math only serves to confuse the issue rather than demonstrate any real substance and is easily debunked.
Is the distro added value that supports a value proposition? No question, but it's a different value proposition than the one offered by the Linux kernel. I'll observe that you'll have a difficult time quantifying the number of "contributors" to a distro given that distros are collections of software packages that were written without a particular distro in mind (for the most part, there are obviously exceptions). Also, creating a distro should not require hundreds of thousands of contributors given the nature of the task.
I have to disagree with you on this point. I do a lot of small one-person projects, and I can't count the number of times that setting a checkpoint before I start coding has saved me hours of rework when something unexpected happens to what I'm working on. However, I usually use a simple version control system, such as RCS for my one-person projects (CVS, et al. are overkill for that sort of thing).
I've worked on several similar projects and one of the items that bit us was when the developers made assumptions based characteristics of the development platform that were somewhat radically different than the production platform. Assumptions around the size of data (not just word size, but buffer sizes for some text retrieved from "standard" libraries) caused a number of problems on several Java projects I've worked on (not to mention the ones in other languages). Data size seems to be one of the more commonly overlooked items in design and implementation, so I'd urge you to make sure that you've done your due diligence to ensure that you don't find those after the fact.
Another area is performance. For reasons I have yet to understand, there seems to be a prevalent myth that performance can be bolted on after the fact (the "make it work, then make it work fast" mindset). The truth of the matter is that performance has to be engineered in from the beginning or you simply spend a lot of time and money rewriting code that should never have been written in the first place. Sadly, educational institutions don't appear to place any emphasis on actual performance or teach the principles of performance tuning as part of their curricula.
Wasn't there a story or three a year or so ago talking about a SimPC for distribution in India? The idea was to deploy inexpensive PCs with limited functionality (or something like that...)
Let's agree that you prefer Java and that I don't. That seems to be the only point that is coming out of this thread.
I have yet to be associated with a project written in Java where we didn't have to rewrite in another language (C or C++, usually) to fulfill the system requirements (those projects range from embedded systems to large enterprise systems).
I'm happy for you (and all the reat) that Java does what you need.
Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?
I would agree, but that was not what you were arguing, was it? You were implying that millions of downloads had no connection with the number of different applications. If you had actually researched the market, you would know that there are thousands of applications.
No, my comment was meant to point out that millions of downloads (of anything) doesn't equate to millions of applications. Ergo sum, I remain unimpressed by the use of statistics as a spin mechanism to categorically state that "anything" has arrived or has become the "dominant force" in development.
Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.
This is true, but almost ANY large application server for ANY language on ANY system will require licencing. It is not specific to Java, as you implied. If you want to write complex middleware (and not just PHP/JSP pages) you will need such a server.
You've missed my point completely. BTW, I am not in the habit of hiding my real thoughts behind subtle innuendos. If I had MEANT to say that the licensing issue was Java-specific, I would have said so. Please refrain from putting words in my mouth. My point was to comment that JBoss is not suitable for most large enterprise application needs and those needs require a commercial, licensable Java App server such as WebLogic.
J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.
With respect, I don't think it was the MIDP1.0 that fragmented the market (after all, it was a specification) - just the fact that the different handset manufacturers implementations of MIDP1.0 were different is what produced dissimilar results.
Beg to differ, MIDP 1.0 had so many holes that device manufacturers were "free" to fill in the gaps for their devices in any way that they could to make it work.
If anything, MIDP1.0 united the market (nowadays, nearly all handsets come with a MIDP implementation) because it had a broad enough scope and was small enough that handset manufacturers would include it with little hassle - remember that in the world of handset manufacturers, development support is way down the list of priorities.
Not to mention that it makes the handsets buzzword compliant for marketing purposes. The sadder part is that an even better approach would be an environment that you modeled the problem in a platform independent way, then generated the platform specific code for the platforms you're interested in to ensure that the generated application was optimal for the platform rather than settle for the least commond denominator.
Re: Resources and performance, that's down to the manufacturers implementation. You can't just make a sweeping statement like that and expect it to be the same for all handsets!
I disagree. A poorly performing application, regardless of the platform, will not win over customers. A well performing application that makes the best use of the available resources, regardless of the platform, will take more market share. Java is the lazy way out IMHO.
J2ME MIDP 2.0 was better in terms of features, but little else.
The features that were implemented in MIDP2.0 covered pretty much all the gaps that MIDP1.0 highlighted. The great thing about it was that it was all the right gaps without bloating it!
OK, so if I do a size comparison then you're saying that the MIDP 2.0 JVM is the same size and the MIDP 1.0 JVM. Correct? And that it takes exactly the same amount of resources or less?
If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?... Which are handset-specific. SymbianOS handsets don't account for a large piece of the market at all. Java works because you can write an app and port it to 90% of handsets.
Um, sorry to disagree but Nokia handsets are a significant part of the market, and most of them are Symbian-based (since Nokia practically owns Symbian). I'm pretty sure that you'll find Symbian on a lot of Ericsson phones too.
Put down the SUN cup with MicroJava and get into rehab.
I don't really evangelise about languages, or have my favourites. It's a case of using the best tool for the job, which IMHO is java. Your whole argument seems to be based on performance alone - while that is fair and good for performance-critical apps, java performance isn't that bad, and performance is only an issue for certain applications.
Re: get into rehab. Why resort to flamebait? It's only a choice of language.
Flamebait? Wow, I wasn't even intending to be inflammatory with my last comment, merely registering an opinion on yet another has finally arrived story. For what it's worth, Java is not the only thing that I register that comment on. If I wanted to start a flamewar I can do much better than that little piece of sarcasm.:-)
You know, the word evangelise carries a reference to a religious belief associated with "converting the unbelievers". That is the single most offensive thing that I can think of that came out of the dot-com era (and before) because I do NOT view technology as a religion. However, you hit the nail on the head. Java is just a language and there are other choices that accomplish the same ends.
Ah, so those millions of Java games that were downloaded last year were all the same program.
Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?
Licensing fees? What licensing fees? Use any free VM and an open source J2EE server like JBoss and there are no fees at all.
Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.
Keep trying though, you'll no doubt find a way to rationalize a way around my comments.:-)
Interesting that the last numbers I saw had C/C++ being the #1 language in demand for actual job postings. Java was #2, closely followed by C# and PHP.
I also seem to recall that one application being distributed on 100+ million devices still only equals a single application, not 100+ million applications (must be that new math that I keep hearing about).
Funnier still that Java is still an interpreted language and that language bigots like yourself look down your nose at any other language that threatens your perception of reality.
BTW, I work in a number of languages (60+ last time I counted) to create enterprise apps and for what it's worth Java brings nothing to my table except additional overhead in terms of resources and licensing fees.
Aw, come on. That's like asking if people still use Visual Basic, Object Pascal, COBOL, or Fortran. Of course they do because it's probably the only language that they know and therefore it's the correct choice for implementing all solutions because it was hard to learn and therefore any other language must be equally difficult so it can't bring any real value.
But the real question is why do the cell phone manufacturers write most of their apps in C++?
J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.
J2ME MIDP 2.0 was better in terms of features, but little else.
If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?
Put down the SUN cup with MicroJava and get into rehab.
UML is a great tool for providing a common notation (what it was originally intended for from what I understand). Using it pragmatically takes experience. Programmers tend to model their implementation a little at a time and miss the point of system or application modeling. Where UML can be used successfully to generate code (overcoming the problem of keeping the diagrams and documentation current, a common problem cited by programmers who want to code, not design or document) using tools such as those from Kabira (www.kabira.com) or Accelerated Technologies Bridgepoint (http://www.projtech.com/). I would recommend spending some time at the OMG sight (www.omg.org) and read up on MDA and Executable UML. Oh, and sprinkle your use of UML with a healthy does of pragmatism, i.e., if it doesn't bring any value, then don't do it based on the modeling methodology you choose to use (UML != Methodology; RUP, OMT, OOSE, Booch, Fusion, et al. would be methodologies).
But your mileage may vary......
P.S. In my experience, the rush to code can be characterized as always having time to do it over, but never having time to do it right the first time.
Given that you have stated that this is a new market for your company and that there is no pre-existing knowledge or experience in this markte, I think you're jumping the gun by trying to select a platform. You can successfully implement the new system in any of the available platforms. The best advice I can offer is:
Forget about the platform right now unless it's a constraint.
Focus on gathering and refining the requirements for the system you propose to build based on your customer's needs.
Work out the design for the system and downselect to the platform you choose to develop in based on a clear understanding of the available choices and guidance from your customer base
If you don't have requirements or a system design and you're worried about the implementation platform, you've already lost the race. Your system will end up being an ad hoc, organically grown, maintenance nightmare. Your best chance for success is to follow some sort of software development lifecycle instead of what appears to be the rush to select a platform and start coding. Factor in the learning curve for the selected platform to your project timeline, but jumping straight into coding before you know the requirements for the system and have a design to fulfill those requirements just leads to a waste of time, money, and resources that culminates in a failed project or worse, a badly hacked up product that results in bad customer relations.
That's my experience, but your mileage may vary....
I never really considered myself bound to TomCat or any other servlet engine or application server (not to mention Java). There are too many options for Java and other languages for anyone with any sense to feel that way. JBoss, Apache Geronimo, sort of leap to mind as alternative J2EE app servers, likewise PHP, Python, and Perl all have quite workable (and scalable) application server capabilities behind a web server (just ask, er, Slashdot).
These days I'm more interested in looking for ways to insulate myself and my customers from disruptive technologies rather than tie myself to a single solution. The OMG's MDA has promise, but to realize that approach requires tools to support it. AndroMDA will kick out Java, but little else. I'm just wondering when a group of software engineers will get together and create an Open Source MDA suite that allows language generators to be plugged in. Once those tools are in place and support any language (or have the capability to do so), the promise of MDA can be realized. Until then, I guess we have to type code the old fashioned way.:-(
Remember the tired old adage, when the only tool you have in your toolbelt is a hammer, the whole world looks like a nail. Master craftsmen have a number of tools and techniques at their disposal and don't have to settle for a single approach.
No real evidence to back up the belief, only lies, damn lies, and statistical probability.
2) That life out there is looking for us
What makes us special?
3) That life out there doesn't already know about us
Maybe nobody wants to talk to us.
4) That life out there is friendly
Not to be overly paranoid, but what basis for friendship can we really have with extraterrestrial beings? How do we know that we won't be simply wiped out as an infection or treated as a food source?
Interesting post. My observation is similar, in that management has been trying to do away with the need for developers for at least the last 20 years or at least commoditize them (see tools like PowerBuilder or Visual Basic). Is this a bad thing? Well, as you note, it allows less-skilled workers to be successful (to a degree). However, you often get what you pay for (see another "rant" on my part in this chain).
Realistically, hackers like to think of themselves as outsiders to a degree because that's how they measure their "coolness", i.e., by their code kung fu. Well-established languages with visual paradigms, such as VB and now Java, become increasingly looked upon as children's toys.
To balance things, Java is a very clean language that builds on the footsteps of its predecessors. However, the frequency of change and the size of the required virtual machine (and its resource demands) may make it less desirable for some projects.
For most of the things I do, Perl, Python, PHP, and occasionally Tcl/Tk are more than adequate. I'll go to C or C++ if I need more speed and FORTRAN 77 if I need all the speed I can get. But I guess being multi-lingual is too much of a strain for what you characterize as "B" coders.;-)
The saddest statement is that great code [in whatever language] still ends up being crap if it's based on bad (or missing) requirements and a lousy design. Unfortunately, most coders are not good are requirements or design because they want to focus on the code for the instant gratification. It's even more poignant when application developers suddenly think that they are enterprise application developers by virtue of using a toolkit or spec that has the word "enterprise" in it. Far too often the desktop application programmer mentality becomes apparent when so-called enterprise applications require the resources of an entire server for a single application (and frequently a cluster of those servers).
I've sort of given up on common sense coming to bear because of the "just buy more/larger servers" or "drop in more RAM" mentality that is far too common in the industry these days. So let's hope that Moore's Law doesn't slow down any time soon because all of these "advanced" enterprise applications will need all the help they can get.
Sheesh! I can't believe nobody else saw the point of the gentleman's article. After all, it's not about improving efficiency of the programmer or the system. It's all about empowering authors to write more books about new programming languages that rely on Moore's Law to make them semi-viable (oh, and to draw in more royalties from the panoply of books about the new programming languages). It's sort of like the fad of patterns, eXtreme Programming, etc. Few places really use the principles promulgated in the all-too-many books on the subject and those that do eventually (d)evolve back into more conventional practices. Who benefits most? The authors do (not that I'm against authors making a buck).
Unfortunately, the days of graduating from college and walking into an upper 5/lower 6 figure salary are long gone. Coupled with the growing trend towards overseas outsourcing to take advantage of lower labor rates and the glut of experienced developers on the market, you're coming out of school with a lot of competition for an increasingly small number of positions. If you have two offers, not interviews, but offers then you should really consider yourself lucky. Take the best one and work there for a year or two so that your resume will reflect that somebody thought you were skilled enough to hire you and keep you. From that point, continue building your experience and you'll see your salary go up.
Slashdot Mirror
So there are hundreds of developers working on the Linux kernel? Given the non-monolithic nature of the kernel that's hardly a surprising number. The value add of the Linux kernel is that it forms the basis of an operating system, not a distro. Of course, most folks don't really understand that Linux is the kernel, not a distro.
How are you defining a contributor in the distro sense? Someone who writes an apt-get GUI for a Debian-based distro (for example)? Someone who tests the installation and operation of the distro? Someone who compiles and publishes the distro?
If you're counting the authors of the various packages (such as ethereal, ls, vim, etc.) that comprise a distro as "contributors", then your premise is invalid. That sort of fuzzy math only serves to confuse the issue rather than demonstrate any real substance and is easily debunked.
Is the distro added value that supports a value proposition? No question, but it's a different value proposition than the one offered by the Linux kernel. I'll observe that you'll have a difficult time quantifying the number of "contributors" to a distro given that distros are collections of software packages that were written without a particular distro in mind (for the most part, there are obviously exceptions). Also, creating a distro should not require hundreds of thousands of contributors given the nature of the task.
But your mileage may vary....
I have to disagree with you on this point. I do a lot of small one-person projects, and I can't count the number of times that setting a checkpoint before I start coding has saved me hours of rework when something unexpected happens to what I'm working on. However, I usually use a simple version control system, such as RCS for my one-person projects (CVS, et al. are overkill for that sort of thing).
I've worked on several similar projects and one of the items that bit us was when the developers made assumptions based characteristics of the development platform that were somewhat radically different than the production platform. Assumptions around the size of data (not just word size, but buffer sizes for some text retrieved from "standard" libraries) caused a number of problems on several Java projects I've worked on (not to mention the ones in other languages). Data size seems to be one of the more commonly overlooked items in design and implementation, so I'd urge you to make sure that you've done your due diligence to ensure that you don't find those after the fact.
Another area is performance. For reasons I have yet to understand, there seems to be a prevalent myth that performance can be bolted on after the fact (the "make it work, then make it work fast" mindset). The truth of the matter is that performance has to be engineered in from the beginning or you simply spend a lot of time and money rewriting code that should never have been written in the first place. Sadly, educational institutions don't appear to place any emphasis on actual performance or teach the principles of performance tuning as part of their curricula.
So the editorial I read i Dr. Dobbs journal regarding Computer Science degrees becoming little more than Java certifications is true?
Sigh.........
Wasn't there a story or three a year or so ago talking about a SimPC for distribution in India? The idea was to deploy inexpensive PCs with limited functionality (or something like that...)
a WiFi access point, WiFi card, VNC server software on the servers, and a VNC client on the laptop?
Let's agree that you prefer Java and that I don't. That seems to be the only point that is coming out of this thread.
I have yet to be associated with a project written in Java where we didn't have to rewrite in another language (C or C++, usually) to fulfill the system requirements (those projects range from embedded systems to large enterprise systems).
I'm happy for you (and all the reat) that Java does what you need.
Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?
I would agree, but that was not what you were arguing, was it? You were implying that millions of downloads had no connection with the number of different applications. If you had actually researched the market, you would know that there are thousands of applications.
No, my comment was meant to point out that millions of downloads (of anything) doesn't equate to millions of applications. Ergo sum, I remain unimpressed by the use of statistics as a spin mechanism to categorically state that "anything" has arrived or has become the "dominant force" in development.
Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.
This is true, but almost ANY large application server for ANY language on ANY system will require licencing. It is not specific to Java, as you implied. If you want to write complex middleware (and not just PHP/JSP pages) you will need such a server.
You've missed my point completely. BTW, I am not in the habit of hiding my real thoughts behind subtle innuendos. If I had MEANT to say that the licensing issue was Java-specific, I would have said so. Please refrain from putting words in my mouth. My point was to comment that JBoss is not suitable for most large enterprise application needs and those needs require a commercial, licensable Java App server such as WebLogic.
J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.
... Which are handset-specific. SymbianOS handsets don't account for a large piece of the market at all. Java works because you can write an app and port it to 90% of handsets.
:-)
With respect, I don't think it was the MIDP1.0 that fragmented the market (after all, it was a specification) - just the fact that the different handset manufacturers implementations of MIDP1.0 were different is what produced dissimilar results.
Beg to differ, MIDP 1.0 had so many holes that device manufacturers were "free" to fill in the gaps for their devices in any way that they could to make it work.
If anything, MIDP1.0 united the market (nowadays, nearly all handsets come with a MIDP implementation) because it had a broad enough scope and was small enough that handset manufacturers would include it with little hassle - remember that in the world of handset manufacturers, development support is way down the list of priorities.
Not to mention that it makes the handsets buzzword compliant for marketing purposes. The sadder part is that an even better approach would be an environment that you modeled the problem in a platform independent way, then generated the platform specific code for the platforms you're interested in to ensure that the generated application was optimal for the platform rather than settle for the least commond denominator.
Re: Resources and performance, that's down to the manufacturers implementation. You can't just make a sweeping statement like that and expect it to be the same for all handsets!
I disagree. A poorly performing application, regardless of the platform, will not win over customers. A well performing application that makes the best use of the available resources, regardless of the platform, will take more market share. Java is the lazy way out IMHO.
J2ME MIDP 2.0 was better in terms of features, but little else.
The features that were implemented in MIDP2.0 covered pretty much all the gaps that MIDP1.0 highlighted. The great thing about it was that it was all the right gaps without bloating it!
OK, so if I do a size comparison then you're saying that the MIDP 2.0 JVM is the same size and the MIDP 1.0 JVM. Correct? And that it takes exactly the same amount of resources or less?
If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?
Um, sorry to disagree but Nokia handsets are a significant part of the market, and most of them are Symbian-based (since Nokia practically owns Symbian). I'm pretty sure that you'll find Symbian on a lot of Ericsson phones too.
Put down the SUN cup with MicroJava and get into rehab.
I don't really evangelise about languages, or have my favourites. It's a case of using the best tool for the job, which IMHO is java. Your whole argument seems to be based on performance alone - while that is fair and good for performance-critical apps, java performance isn't that bad, and performance is only an issue for certain applications.
Re: get into rehab. Why resort to flamebait? It's only a choice of language.
Flamebait? Wow, I wasn't even intending to be inflammatory with my last comment, merely registering an opinion on yet another has finally arrived story. For what it's worth, Java is not the only thing that I register that comment on. If I wanted to start a flamewar I can do much better than that little piece of sarcasm.
You know, the word evangelise carries a reference to a religious belief associated with "converting the unbelievers". That is the single most offensive thing that I can think of that came out of the dot-com era (and before) because I do NOT view technology as a religion. However, you hit the nail on the head. Java is just a language and there are other choices that accomplish the same ends.
Not for a long time. Almost all Java implementations translate to optimised machine code at run time.
.........
Oh, so then I don't need to invoke the JVM with:
java
Still looks like semi-interpreted code to me, just cuts out part of the parsing/translation work. Try again.
Ah, so those millions of Java games that were downloaded last year were all the same program.
:-)
Hmm, I'll put hard money on the table that there aren't "millions" of Java games. How about you?
Licensing fees? What licensing fees? Use any free VM and an open source J2EE server like JBoss and there are no fees at all.
Hmm, from your comment you must not work on really large enterprise systems. JBoss is great for small-to-medium sized systems, but I'm betting there's a reason that WebLogic is at the top of the heap.
Keep trying though, you'll no doubt find a way to rationalize a way around my comments.
Interesting that the last numbers I saw had C/C++ being the #1 language in demand for actual job postings. Java was #2, closely followed by C# and PHP.
I also seem to recall that one application being distributed on 100+ million devices still only equals a single application, not 100+ million applications (must be that new math that I keep hearing about).
Funnier still that Java is still an interpreted language and that language bigots like yourself look down your nose at any other language that threatens your perception of reality.
BTW, I work in a number of languages (60+ last time I counted) to create enterprise apps and for what it's worth Java brings nothing to my table except additional overhead in terms of resources and licensing fees.
Have a nice dot-com dream..........
Aw, come on. That's like asking if people still use Visual Basic, Object Pascal, COBOL, or Fortran. Of course they do because it's probably the only language that they know and therefore it's the correct choice for implementing all solutions because it was hard to learn and therefore any other language must be equally difficult so it can't bring any real value.
But the real question is why do the cell phone manufacturers write most of their apps in C++?
J2ME MIDP 1.0 fragmented the embedded market, takes too many precious resources, and is an underperformer.
J2ME MIDP 2.0 was better in terms of features, but little else.
If J2ME MIDP is so wonderful, why do the cellphone manufacturers write their applications in C++ (especially for the Symbian OS)? Perhaps it's because they know those dirty little secrets?
Put down the SUN cup with MicroJava and get into rehab.
UML is a great tool for providing a common notation (what it was originally intended for from what I understand). Using it pragmatically takes experience. Programmers tend to model their implementation a little at a time and miss the point of system or application modeling. Where UML can be used successfully to generate code (overcoming the problem of keeping the diagrams and documentation current, a common problem cited by programmers who want to code, not design or document) using tools such as those from Kabira (www.kabira.com) or Accelerated Technologies Bridgepoint (http://www.projtech.com/). I would recommend spending some time at the OMG sight (www.omg.org) and read up on MDA and Executable UML. Oh, and sprinkle your use of UML with a healthy does of pragmatism, i.e., if it doesn't bring any value, then don't do it based on the modeling methodology you choose to use (UML != Methodology; RUP, OMT, OOSE, Booch, Fusion, et al. would be methodologies).
But your mileage may vary......
P.S. In my experience, the rush to code can be characterized as always having time to do it over, but never having time to do it right the first time.
Given that you have stated that this is a new market for your company and that there is no pre-existing knowledge or experience in this markte, I think you're jumping the gun by trying to select a platform. You can successfully implement the new system in any of the available platforms. The best advice I can offer is:
If you don't have requirements or a system design and you're worried about the implementation platform, you've already lost the race. Your system will end up being an ad hoc, organically grown, maintenance nightmare. Your best chance for success is to follow some sort of software development lifecycle instead of what appears to be the rush to select a platform and start coding. Factor in the learning curve for the selected platform to your project timeline, but jumping straight into coding before you know the requirements for the system and have a design to fulfill those requirements just leads to a waste of time, money, and resources that culminates in a failed project or worse, a badly hacked up product that results in bad customer relations.
That's my experience, but your mileage may vary....
I never really considered myself bound to TomCat or any other servlet engine or application server (not to mention Java). There are too many options for Java and other languages for anyone with any sense to feel that way. JBoss, Apache Geronimo, sort of leap to mind as alternative J2EE app servers, likewise PHP, Python, and Perl all have quite workable (and scalable) application server capabilities behind a web server (just ask, er, Slashdot).
:-(
These days I'm more interested in looking for ways to insulate myself and my customers from disruptive technologies rather than tie myself to a single solution. The OMG's MDA has promise, but to realize that approach requires tools to support it. AndroMDA will kick out Java, but little else. I'm just wondering when a group of software engineers will get together and create an Open Source MDA suite that allows language generators to be plugged in. Once those tools are in place and support any language (or have the capability to do so), the promise of MDA can be realized. Until then, I guess we have to type code the old fashioned way.
Remember the tired old adage, when the only tool you have in your toolbelt is a hammer, the whole world looks like a nail. Master craftsmen have a number of tools and techniques at their disposal and don't have to settle for a single approach.
1) That there is life out there besides our own
No real evidence to back up the belief, only lies, damn lies, and statistical probability.
2) That life out there is looking for us
What makes us special?
3) That life out there doesn't already know about us
Maybe nobody wants to talk to us.
4) That life out there is friendly
Not to be overly paranoid, but what basis for friendship can we really have with extraterrestrial beings? How do we know that we won't be simply wiped out as an infection or treated as a food source?
Interesting post. My observation is similar, in that management has been trying to do away with the need for developers for at least the last 20 years or at least commoditize them (see tools like PowerBuilder or Visual Basic). Is this a bad thing? Well, as you note, it allows less-skilled workers to be successful (to a degree). However, you often get what you pay for (see another "rant" on my part in this chain).
;-)
Realistically, hackers like to think of themselves as outsiders to a degree because that's how they measure their "coolness", i.e., by their code kung fu. Well-established languages with visual paradigms, such as VB and now Java, become increasingly looked upon as children's toys.
To balance things, Java is a very clean language that builds on the footsteps of its predecessors. However, the frequency of change and the size of the required virtual machine (and its resource demands) may make it less desirable for some projects.
For most of the things I do, Perl, Python, PHP, and occasionally Tcl/Tk are more than adequate. I'll go to C or C++ if I need more speed and FORTRAN 77 if I need all the speed I can get. But I guess being multi-lingual is too much of a strain for what you characterize as "B" coders.
The saddest statement is that great code [in whatever language] still ends up being crap if it's based on bad (or missing) requirements and a lousy design. Unfortunately, most coders are not good are requirements or design because they want to focus on the code for the instant gratification. It's even more poignant when application developers suddenly think that they are enterprise application developers by virtue of using a toolkit or spec that has the word "enterprise" in it. Far too often the desktop application programmer mentality becomes apparent when so-called enterprise applications require the resources of an entire server for a single application (and frequently a cluster of those servers).
I've sort of given up on common sense coming to bear because of the "just buy more/larger servers" or "drop in more RAM" mentality that is far too common in the industry these days. So let's hope that Moore's Law doesn't slow down any time soon because all of these "advanced" enterprise applications will need all the help they can get.
Wow, George Takei really saw this one coming (the sneak suit).
A proper design can be coded in any decent OO language and come out just fine.
I agree with your sentiment, although I'd go so far as to say that a proper design can be coded in any language, not just an OO one.
Sheesh! I can't believe nobody else saw the point of the gentleman's article. After all, it's not about improving efficiency of the programmer or the system. It's all about empowering authors to write more books about new programming languages that rely on Moore's Law to make them semi-viable (oh, and to draw in more royalties from the panoply of books about the new programming languages). It's sort of like the fad of patterns, eXtreme Programming, etc. Few places really use the principles promulgated in the all-too-many books on the subject and those that do eventually (d)evolve back into more conventional practices. Who benefits most? The authors do (not that I'm against authors making a buck).
Unfortunately, the days of graduating from college and walking into an upper 5/lower 6 figure salary are long gone. Coupled with the growing trend towards overseas outsourcing to take advantage of lower labor rates and the glut of experienced developers on the market, you're coming out of school with a lot of competition for an increasingly small number of positions. If you have two offers, not interviews, but offers then you should really consider yourself lucky. Take the best one and work there for a year or two so that your resume will reflect that somebody thought you were skilled enough to hire you and keep you. From that point, continue building your experience and you'll see your salary go up.
/me makes a bowl of popcorn and sits back to enjoy the show.. (as an aside, does anyone know what compiler SCO uses to generate their binaries?)
;-)
It used to be a variant of the Microsoft C compiler if I recall correctly.......