The replies to this post has given my team a lot of food for thought. As usual, the slashdot community replied with a lot of intelligent feedback and added a dash of humor too.
I especially appreciated the discussions on features. Many had been on our wish list, but others had been overlooked.
Few things not stated in my original post:
While I do support the choice, I have no control over the language choice for in-house development. Having done large enterprise programming for many years and in many languages, it is my opinion that pure performance is rarely the sole reason a programming language is chosen. The decision usually considers the size of the talent pool, including in-house, available & reputable contractors, as well as job-seekers.
Doesn't matter how good a language is if you can't easily hire programmers. I am not saying this is the sole consideration and definately not the primary one, but it is a big one. Others factors were open-source projects that could be used in conjunction with our developement, costs (IDE's and other tools), available quality education for existing staff, and a raft of others.
Point is that the language choice is effected by the total cost of using it.
We have also been sucessfully doing many smaller projects in java for several years. Fairly easy to track down any issues that come up. We are now laying the foundation for a massive multi-year project using contract programmers and new hires. We may not have any performance tuning issues early in the project, but what about in a year or two or five? Any experienced developer knows, you try to anticpate issues like that and lay the foundation for discovery and tuning BEFORE the coding starts. A profiling tool makes a lot of sense under these circumstances.
One thing I learned a long time ago, doesn't matter how good and/or detailed the design process is, when the coding starts, stuff happens. The larger the team on the project, the higher the stuff factor.
I don't know you or your professional background, so I may be merely reminding you of something you (should) already know.
The replies to this post has given my team a lot of food for thought. As usual, the slashdot community replied with a lot of intelligent feedback and added a dash of humor too.
I especially appreciated the discussions on features. Many had been on our wish list, but others had been overlooked.
Thanks Again!
Few things not stated in my original post: While I do support the choice, I have no control over the language choice for in-house development. Having done large enterprise programming for many years and in many languages, it is my opinion that pure performance is rarely the sole reason a programming language is chosen. The decision usually considers the size of the talent pool, including in-house, available & reputable contractors, as well as job-seekers. Doesn't matter how good a language is if you can't easily hire programmers. I am not saying this is the sole consideration and definately not the primary one, but it is a big one. Others factors were open-source projects that could be used in conjunction with our developement, costs (IDE's and other tools), available quality education for existing staff, and a raft of others. Point is that the language choice is effected by the total cost of using it. We have also been sucessfully doing many smaller projects in java for several years. Fairly easy to track down any issues that come up. We are now laying the foundation for a massive multi-year project using contract programmers and new hires. We may not have any performance tuning issues early in the project, but what about in a year or two or five? Any experienced developer knows, you try to anticpate issues like that and lay the foundation for discovery and tuning BEFORE the coding starts. A profiling tool makes a lot of sense under these circumstances. One thing I learned a long time ago, doesn't matter how good and/or detailed the design process is, when the coding starts, stuff happens. The larger the team on the project, the higher the stuff factor. I don't know you or your professional background, so I may be merely reminding you of something you (should) already know.