|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Choosing a Development Environment How do you choose a development tool? My History of Picking Tools
In high school, we had several computer options. Like most schools of the day we had a couple of Apple's , a TRS-80, a TI and a brand new IBM PC. I used the TI in math class, the TRS-80 in electronics class and played with the PC on occasion. My high school had a more established computer program than most. They had a Data Processing curriculum and an IBM System/34 mini computer. Unlike the smaller computers, the mini computer had multiple development platform choices. I used RPG II, though this choice was made by the Wake County Public School system. We are often faced with having to work with a system and tools that we did not select for ourselves. Though this is often not the best way to get things done, it can teach you that the wrong tool can hinder development. It can also show you that anything is possible, that even when a tool does not provide what you need, you can still do the job. In college, I "chose" Pascal as my development tool. I did have a choice, CSC 101 and 102 were taught using Pascal, so I chose that over the 300 level courses in assembly and 400 level courses in C. The study of Pascal taught me that I wanted to use a structured language over BASIC and assembly. At that time your development language was predetermined by your development tool, but Apple's new Macintosh was changing this. The graphical interface was making the API far more important than the language. API's had mattered before, but unless you were writing games or writing in assembly, you didn't have to deal with them that much. Even C, which was very API oriented, was helped by the near universal acceptance of the UNIX/POSIX API, but the GUI changed all that. Every manufacturer choose their own path. As the 80's moved into the 90's, the choices for GUI development were growing, though most of these paths were dead ends. While the OS writers and compiler companies were pushing their own API's, a new direction was being explored by a couple of companies. NeXT and Sun had both developed new cross-platform API's. NeXT had developed their NeXTStep library for their computer systems, but were forced to take it cross-platform after they had been unable to create a computer that could appeal to the mass market. NeXT had started in the early eighties with an object oriented language based on C called "Objective-C." Sun started later, after C++ had become the dominant object oriented language, so they attempted to create an interpreted version of C++, and as they strayed from C/C++, Java was born. NeXT also brought the world the concept of RAD (Rapid Application Development), this new style of programming was intended to make programmers much more productive. This was really an extension of the object oriented philosophy. The most visible aspect of this was that tools made it easy to design user interfaces. This all complicated the tools picture greatly. Through the 90's I moved from Turbo-C to Optima++/Power++ to C++ Builder as I focused on Windows development (my dark ages). When Mac OS X came out I decided to by my first Mac in over a decade and, of course, needed a development tool. I bought a book on Carbon and gave Project Builder a try. I was looking for a RAD tool on the order of C++ Builder. Though interface builder was nice for building the screens, the implementation seemed a bit closer to the primitive Visual-C than the C++ builder I was used to (Had I tried Cocoa, I am sure my search would have stopped right there, but I didn't). I did not want to learn a new language, so like most people, I started a search for what tools were available for C++. Isn't this where we always start? We go for what we know. Since I still got paid to develop Windows applications, I searched for cross-platform RAD tools, trying them all, most notably Qt. They all shared a few common traits, namely, they produced applications that looked about as native as Java looks. Qt was the best, almost good enough but it was only offered in two forms - either very expensive or free when anchored to the horribly restrictive GPL license. I eventually settled on a product called CPLAT that worked reasonably well, looked pretty good, but was supported by one person, who could only do so much so fast. It was weak on RAD, but it worked. Sometime during this process, one of my searches brought up a product called REALbasic. I downloaded the demo out of curiosity. I was surprisingly impressed, but had no real interest because it was based on BASIC, and I had given up on BASIC years earlier and was not going back to "GOTO" hell. I continued to try and use the CPLAT tool, but never really got proficient with it. I do not remember when exactly I made the decision to buy REALbasic, but I did. I considered taking the Visual BASIC approach to development, designing my UI in BASIC and doing the real work in C libraries. I had actually done this with a project in the early 90's. Someone else did the BASIC part and I wrote the DLL's. Though when I took over the whole project, I redid it in C++ (Visual BASIC was not up to the task for our uses). The REALbasic Experience As I started to use REALbasic, I began to notice something I had not expected. Every time I needed to do anything, I had to use a class, the entire library was implemented in a object oriented style. This surprised me! I soon noticed that everything in REALbasic was very well thought out. As a C++ programmer, I quickly became a REALbasic fan. I still prefer C++, but I found that I could do anything I needed to in BASIC, and I could do it cleanly. I thought that surely the performance could not be up to par, so I wrote a couple of test applications and was again surprised. There was not much difference if I used C++ strings. Sure I could get better speeds from C/C++, but usually I had to use character arrays and pointers that introduce the opportunity for pointer errors that sticking with good object oriented design principles tend to eliminate. I had been impressed with the look and feel of the applications on the Mac, but my first compile for Windows really impressed me. The first thing I noticed was how easy it was to compile for Windows. I literally had to check one check box and that was it! Now every time I clicked the build button, I generated a Windows version of my application. I did not have a single conditional compile (though these are supported, but you do not need them often unless you call native API's directly). This was pretty amazing! Next I ran the application on Windows and it looked like a Windows application. I had already noted that the Mac applications looked good. Unlike Qt and Java applications, the programs looked at home on each OS. The RAD design capabilities of REALbasic were excellent, and the graphical screen design can compare with the best out there. You can subclass any of the components and when you do your version shows up in the tool palate automatically. It does not take but a few minutes to feel like you have the ability to design even the most complete databases. If you select the code window for the form, you will see all the events available for each control, this makes learning to use REALbasic especially easy. The editor takes a little getting used to because it forces the code alignment, but it can be nice once you get used to it. The editor also has a good autocomplete feature, so you can generally figure out what to do even if you are new to the environment. REALbasic offers excellent database options through their database plugin system. REALbasic ships with many common database plugins, including ODBC so you can effectively use any database system. I have used REALbasic to create some very sophisticated database applications. At first I used REALbasic for anything that needed to be cross-platform, but then I found that I was choosing it for things that were Windows only and even Mac only. The bottom line is that what matters most in picking a development system is how productive you can be. The more I use REALbasic, the more I realize that it is the most productive way to program and the best way to do anything cross-platform. REAL Software I have used many tools over the years and they all have their issues. REALbasic is no exception. I would have to say that REALbasic has been as reliable and bug free as any tool I have ever used. I have been more impressed with REAL Software than I have any other compiler company I have dealt with. Though I have generally found that the compiler companies have worked well with me to find issues, I had never experienced anything like I found at REAL Software. The first thing you notice is that the staff really loves and believes in the product. This creates a level of pride that makes them very responsive. Nearly every issue that I have reported has been found in a matter of days. Feature requests usually take longer, but over the last five years 70-80% of my requests have been satisfied, and that's pretty incredible! Every new release brings with it a multitude of new features. Many of the staff blog about REALbasic. They also have a REAL World conference each year where you can meet the developers face-to-face and not only get some heads up on where they are heading, but also get to talk to them about what you would like to see. I have always found them to be interested in what we (their customers) want. Perhaps this customer centric approach to development is why it is such a productive product. Market Changes The decade of the 90's was the decade of Microsoft. Apple was faltering, allowing Microsoft to catch up with the decade long lead in Graphical Interfaces. Microsoft used a variety of methods to create what appeared to be an indestructible monopoly. A lot of us may not have liked it, but Microsoft knew how to build market share. They provided good development tools and built the developer force, locking people into their proprietary API. Microsoft has been trying to reign in their developers and keep them supporting only Windows with a new Proprietary API called .NET. They are using the RAD API to draw programmers from the most popular language of choice (C/C++) to C#. They hope that the RAD option can get those customers to make the jump. As the decade came to a close, Microsoft faced Apple, where Steve Jobs had stopped the bleeding, and Linux was growing in the server world. Microsoft faced something new - a shrinking market share. Throughout this decade Apple has been growing market share and has accelerated that growth to a pace of three times the industry average (9 times if you remove Macs from the PC industry total). This creates a major changing paradigm, it no longer makes sense to ignore the Mac. If the growth trend continues as it has over the last three years, Apple will hit double digits in a little more than a year and 30-40% in a decade. Linux is still growing as well, though not at the pace of Apple. Conclusion All of this adds up to a very simple fact - it does not make sense to develop for just one platform anymore. No development tool can come close to REALbasic for cross-platform development. When you combine this with the productivity of a well-designed object framework and a very good RAD design tool, it is hard to come up with a reason to use anything else. I guess it wouldn't make sense if your work address is Cupertino or Seattle, but for the rest of us ... there is REALbasic! Comparisons Here are my comparisons of REALbasic with some of the other alternatives out there: REALbasic vs. C++ (with Qt)
REALbasic vs. C#.Net
*While REALbasic only natively supports CGI development, Yuma from Inspiring Applications is a full server side development tool based on REALbasic. REALbasic vs. Objective-C/Cocoa
*While REALbasic only natively supports CGI development, Yuma from Inspiring Applications is a full server side development tool based on REALbasic. REALbasic vs. Java
*While REALbasic only natively supports CGI development, Yuma from Inspiring Applications is a full server side development tool based on REALbasic. REALbasic vs. Visual Basic 6
*While REALbasic only natively supports CGI development, Yuma from Inspiring Applications is a full server side development tool based on REALbasic. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 2008 REAL Software, Inc. | Site Map | Activation | Privacy | Contact |