Lately I've had my programming project on the backburner while I worked on the story I had blogged about previously. The road that led to me dipping my toes into the programming waters has been a rather long and winding one and I'm by no means a professional programmer. I'm a painfully green beginner at programming.
When I was thinking about trying to start a new programming project, one of the things I really wanted to address was the question about platform. "Platform" here means what operating system the program runs on...Windows, Linux, OS X, or maybe even the iPhone.
What I really wanted was an application that works on multiple platforms. There are a couple ways to address it.
One, you create the program in a language that is relatively portable, like C/C++. You'd still end up having to maintain two or more code bases, though. This also increases maintenance chores since you can have bugs in one set of code that don't exist in the other and you're probably going to have workarounds for quirks on one platform that aren't in the other. It would be a maintenance headache at best, a nightmare at worst.
Two, find a language and toolset that is cross platform to begin with. This means that you have one codebase to maintain and one IDE in which to program, but the resulting program can target multiple platforms. One of the benchmark IDE's for this type of task was Metrowerks Codewarrior. It used to be a really cool C/C++ best known for running on the Macintosh but was also available on Linux and Windows and it could compile programs to run on Windows, MacOS, and Linux. This was the compiler I was using while in college and I loved it. Through a wonderful series of missteps it ended up turning into an embedded systems tool only, meaning it was...is...used to create programs for microprocessors in things like phones and microcontrollers. In other words
Another cross-platform compiler is REALbasic from REALsoftware. It closely resembles Visual Basic in many aspects but it, like Codewarrior, compile the application for Windows, the current generation of Macs, and certain distros of Linux.
There really aren't too many alternatives for cross-platform development. There are a few tools being worked on like Lazarus, a cross-platform comipler based on the Pascal language, but it's still under development and getting certain features to work properly means playing with add-on libraries or packages.
My biggest issue with this solution is that it requires learning this dialect of the language and then becoming slave to the company the produces the language. For example, I liked CodeWarrior. It used a more-or-less standard language (yes, it had a couple quirks, but no more than expected) and the Standard Template Library for C++. Adapting my coursework to work with that compiler was usually not a problem. Then the company basically dropped all support for it and discontinued the product. As the platforms were updated the code generated by the compiler also fell behind until it just wasn't practical to use anymore.
It also means that these tools have smaller user bases, which means less support and help. REALbasic is really neat; except I'm paying for a product that when I need a code sample I have to turn to a mailing list or forum with a relatively small base of people who spend their time coding and are more or less experts compared to me, and when they are asked for a lot of help with coding they are usually paid as consultants.
They're helpful, but it's just wrong to take advantage of them like that.
Single-platform environments like Microsoft's Visual Studio have books out the wazoo for beginners and experts alike. There are code snippets available for the taking online as well as blogs and sites dedicated to explaining how to approach various programming projects. While REALbasic is close to Visual Basic, it is just different enough that it can be a pain in the arse for someone who isn't already a prolific programmer to port between the two platforms.
Three...you can use a cross-platform VM. This is learning something like Java where you write the source code, compile to bytecode, then it runs on an installed virtual machine (the VM). I hate this type of solution because it means your target must have an installed VM and you're kind of dependent on changes to the VM. In other words, if you create a Java application, you need your client to have the Java software installed, and there's a chance that the next update to Java could break your software. The same goes for Microsoft's .NET-based software.
Four...you use a scripting language like Python to run on multiple platforms. I personally shy away from this option because, like option three, it required your client to have the language support installed (distribute a Python program means you need to have Python installed), and if it's an interpreted language then you probably have the source code being distributed for your client to go through or alter without your control. I'm not a huge advocate of digital rights management, but I am afraid of someone taking advantage of the easy access to the source code to alter something they're not supposed to and breaking the application. There is also some hesitation because interpreted languages tend to have a reputation for being slower and/or more of a memory hog. Some developers dispute this though.
Five, write the application as a web application. If you create the application and test to a certain set of standards then most web browsers should be able to run it. Problems? New web browsers may break the application, you have to deal with issues resulting from proxies and caches and such, and you can't "install" the application; the client must have a usable network application. Also your app probably can't have direct access to much of the user's computer because browsers are sandboxed from the computer for security reasons. There are popular frameworks for developing web application such as Ruby on Rails and Django to simplify the task, however, and for some applications this approach works rather well.
Tether: The Story So Far
5 years ago
No comments:
Post a Comment