Linked by Thom Holwerda on Sun 20th Apr 2008 15:43 UTC
Thread beginning with comment 310563
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
RE: Right Tool for the task
by kaiwai on Sun 20th Apr 2008 16:56
in reply to "Right Tool for the task"
I hope I don't sound like a broken record here, but I think developers should use the best tool for the task. Contrary to what Microsoft or Sun want you to believe, neither .Net or Java is the be-all end-all of programming languages.
True, but at the same time, I do think that the one thing .NET has as its advantage is the ability to for C++ (and others) to move their code over to .NET and retain their skills - without needing to re-learn everything. That is the one problem with Java, it requires you throw all your existing skills out the window. Its just not viable to take that approach.
One also has to acknowledge that .NET is more than just a competitor to Java, it is also a competitor to win32, it is ultimately going to be the future of development on Windows.
I think there needs to be a balance between programming ease and efficiency, were the most processor intensive tasks are coded in C or C++, where simpler features are implemented in higher level languages. A good example of this is Amarok where most of the application is coded in C++, but the lyrics engine was changed from C++ to Ruby. Does that make Amarok slower? I very much doubt it. But it does make it tons easier to develop, maintain and expand.
True; personally, I think that programmer ease should be at the top though; if something can be better implemented, better maintained and less issues crop up (memory management), it should result in more reliable products. When it is easier for the programmer to do his or her work, the less likely they are to make mistakes. I'd sooner have less 'teh snappy' in favour of more stability and security.
On a side note, while the argument made against the recent versions of office/windows being slow compared to older version is valid, the blame may not entirely be due to coding inefficiency. The extra features and backwards compatibility have something to do with it as well.
Well, for me, I think, if Microsoft ported the whole Office suite to .NET, and made .NET available on Windows and Mac OS X - then I think that the performance price would be worth paying. Although one would want to be optimistic, personally, I think that Microsoft is running out of things to add and/or change to Office to make it worth while upgrading to the next version.
RE[2]: Right Tool for the task
by renhoek on Sun 20th Apr 2008 21:39
in reply to "RE: Right Tool for the task"
True, but at the same time, I do think that the one thing .NET has as its advantage is the ability to for C++ (and others) to move their code over to .NET and retain their skills - without needing to re-learn everything.
This is NOT an advantage, different platforms require different approaches and therefore different skills. I am currently maintaining a asp.net website which is coded by a guy who obviously loves cgi (everything is writelined and no inheritance was used, ever.). This is horror for me, and everyone after me. I'm rewriting the code now so it uses controls like asp.net was designed to do. Use the right tool for the job and use it right (most people forget that last part).
RE[2]: Right Tool for the task
by Matt Giacomini on Mon 21st Apr 2008 04:48
in reply to "RE: Right Tool for the task"







Member since:
2007-10-26
I hope I don't sound like a broken record here, but I think developers should use the best tool for the task. Contrary to what Microsoft or Sun want you to believe, neither .Net or Java is the be-all end-all of programming languages.
I think there needs to be a balance between programming ease and efficiency, were the most processor intensive tasks are coded in C or C++, where simpler features are implemented in higher level languages. A good example of this is Amarok where most of the application is coded in C++, but the lyrics engine was changed from C++ to Ruby. Does that make Amarok slower? I very much doubt it. But it does make it tons easier to develop, maintain and expand.
On a side note, while the argument made against the recent versions of office/windows being slow compared to older version is valid, the blame may not entirely be due to coding inefficiency. The extra features and backwards compatibility have something to do with it as well.