2010. július 14., szerda
.Net, Java or Delphi
Problem/Question/Abstract:
.Net, Java or Delphi?
Answer:
This is a response I gave to Mr. Angel Rosario, Jr. on borland.public.delphi.non-technical in regards of his concerns about the "best tool for the job". I wanted to include it in here for further reference.
"I will give you my personal point of view on the matter based on my history and the things I have seen around me. It is a difficult time but is possible to make technological decisions *today*, that may turn good regardless of what is gonna happen. I made mine and I will try to explain the whats and whys.
It's not easy to decide where to go and which boat to jump on. Neither one of the two parties, Microsoft or Linux (let's put the others aside for a second) are sure winners and I am not sure we should even attempt to predict
who will be the one at this point.
On this newsgroup the merits and the pitfalls of both have been discussed to the extreme. Stability, scalability, speed, cost, etc etc etc have been the heart of discussions for months in the non-tech. Problem is that where the market will go is not about the most scalable or stable system. It is about the perception the community has about that and the services that it offers. The one that will dominate in this two matters, will probably be the real winner but this won't mean the other will disappear.
The first concept (perception) is the heart of publicity and propaganda and is the most important. The second (services) backs the first up but is not a lead factor.
Consider what happened around us in our field in the past few years, and then look at history. Windows 95 has taken the desktop, Office has become the fact the business application suite everybody uses and finally Internet Explorer has won the browser war with the 85% of installed and used browsers. Has those products been an example of quality? I wouldn't say so, definitely at the beginning. But even if they weren't, they had something to offer and for sure they are not as bad as today's arguments make them appear. At least they delivered a service and in order to do that, they took advantage of a favorable perception that Microsoft generated around them.
There are many reasons behind what happened but the dominant is the perception users have. AOL has become what it is for the same reasons. Napster is not a real piece of art either but still, through perception and services has became so strong to deserve to be world wide news when things started to go bad. History is made by 2000 years of examples of this pattern that drove masses to any kind of things, good and bad.
This really took more lines than what I was originally thinking and I probably have gone tangents... Why I said what I said? Because at the end, no tool is gonna be so unique and revolutionary to be the one and only one. Is not like the movie Highlander. At the end, there will be more than one <G>
You mentioned Design Patterns and UML... That made me smile, because the selling reasons behind VB, .Net and Delphi are everything but things like that. The promise is about a RAD tool trough which you can develop your applications in less than 15 minutes, not a tool that allows you to apply design patterns, object oriented architectures and things like that. Is all about the perception of faster time to market, which is wrongfully associated with OnClicks.
Now, having RAD environments is a great thing. No questions about it. The problem is that this allowed the spread of all kind of bad results around us. This is not Delphi's fault but the user's. In the case of VB is a little different but still the concept applies to some degree. Many people wouldn't have that much of a problem moving their code if they would have followed the rules.
A few months ago we had to decide if we wanted to use Delphi or Visual Basic for our development. The main reason behind this question was that since we are almost 90% Microsoft based, then why shouldn't we go all the way? Well, I tell you what: at the time .Net was one of the decisional points of sticking to Delphi.
VB changed a lot in version 7. The kind of changes that have been made are more important than abandoning a set of components or introducing new ones. The changes affected the language in itself: things that are today present in every OO language such as real inheritance and OO capabilities, were not present in VB6 and would have led to a corrupted design. Code is easy to change, if things are done properly. Architectures are not.
In an ideal world, design would probably take 70% of the time while implementation is just a mundane and repetitive task. Changing the second should be easy, changing the first, most likely leads to disasters.
So we choose to Delphi because everything we do today (architecture wise) are portable to .Net, Java or whatever in the future, in case we need to. I will probably embrace .Net in the future. It has a lot to offer and I can guarantee that I'd love to do that having Delphi as underlying language. But this really doesn't matter much. Doesn't matter if it is called ADO, JDBC, ODBC or BDE... The principles behind them are the same.
I use SOAP today. I have webservices regardless of Microsoft (although I use their SOAP toolkit since mine is not finished yet <G>). We are developing a system that is scalable, well designed and efficient in Delphi using Microsoft technologies and I can assure you that the majority of the things we are doing, are gonna stay the same even if we move to .Net. The architecture is what really matters, not the tool you use to achieve the result (take out from this VB6 and previous, PowerBuilder and a few other languages).
Don't get fooled by perception, in either way. There's a lot of good stuff in .Net as well in Delphi or Java and there are things that should be done better in all of them. Focus on the services they offer. See how you can improve on what they offer if you need to. Borrow ideas from the others because even if they are very similar, they are not the same.
Good luck"
Feliratkozás:
Megjegyzések küldése (Atom)
Nincsenek megjegyzések:
Megjegyzés küldése