Journey into SuperWaba

Ever wonder what it takes to write programs for your PDA? I did, and so now I am beginning a journey to try my hand at writing something for the PalmOS. SuperWaba, a variation of Java for the PDA, is my language of choice. And I'm a novice, which makes it all the more unpredictable. Hope you'll come along for the ride! Note: You can read multiple posts on one page if you click on an archive link.

Saturday, August 14, 2004

Ed: Is So Much Programming Complexity Necessary?

Well, it's time for an update. Unfortunately, it's not going to be the update I hoped for.
Granted, I haven't had a lot of time to spend on this. But, still, I thought I was going to proudly announce this week that I have written a simple HiLo guessing game on my Palm in SuperWaba. Instead I'm writing this additional editorial, and the next post will describe some of my issues.

In less than an hour, and right on my Palm device, I was able to write something of about the same complexity as a HiLo game in iziBasic, and using part of the GUI interface to do it (as opposed to doing it as a command line program).

One conclusion... something like NSBasic must be much easier than what I'm trying to do with SuperWaba. And with NSBasic, it would be a commercial product so I could get support. When I come up with all kinds of problems with SuperWaba, there's really not a lot I can do. I am reluctant to post to the bulletin board unless I've really worked on it and it's a "significant" and well-thought out question. They seem a bit stuffy on the whole. Probably because everyone is treating it like "serious" business and they don't have time for beginners. I think they need to consider a seperate group for beginners. I know it can lead to a lot of stupid questions, some of which will still get ignored. But at least it would provide a place for someone like me to have a shot at making things work without too much frustration, because others that have been through it before can help out. And, btw, if you take a look at support prices, you'll find that it's not exactly the sort of thing a hobbiest can afford.

One more negative feature of SuperWaba is that the GUI seems to be generally a little messy in appearance. I haven't looked at all the sample programs, and there are some elements of the GUI that do seem to look pretty nice. But my first impressions are that programs tend to look, well, really ugly.

So why do I want to continue this journey if it seems like the hard way? Well, for one thing, I want to get "over the hump" so I know how to do it even if I don't continue. For another thing, I like Java. I'm starting to wonder more every day why that's true, but there's something "clean" or "pure" about Java code compared to variations of C, Basic, Pascal, etc. What I'm starting to get tired of in Java is nagging SW difficulties in getting started, and the enormous overhead and complexity to do simple things.

Before I go on, let me indicate that I'm not so naive as to think programming is simple and it's only the technology that makes it hard. No. In fact I know that even defining the requirements is a tremendously challenging exercise. And I also have dug in to "hard" and "complex" items in coding. Including writing cross-assemblers, writing machine language code without an assembler, writing routines in Pascal on one of the early Macs to handle abstract algebraic manipuations of things you only see in advanced graduate mathematics. Etc. Etc. I know that things sometimes take work.

So what do I mean by this? Well, consider what it takes just to have a program shell that can be used to handle opening a main window, a menu bar and process events. I don't mean actually putting all the items in the menu and populating the window and capturing and handling all the specific events. I just mean the shell that has a place to do that stuff. Kind of like a scaffolding for your code. In my mind, it's not all that much more advanced than my old machine language and Fortran coding days. The syntax is simpler and the editors are better, and we now have an incredible advance with OO, but some things still seem to work in similar ways.

Now, granted, an IDE can do some of the work for you with wizards and tools. And if you are the organized type, you can even create a library of program shells. (If you are less organized, like me, you just keep a folder with some examples you previously worked with, and you do surgery on them until they look like what you are trying to do.)

But what a nuisance to keep having to place code in multiple places to add a menu item. Or to do a standard pop-up window. Or just about everything you do in Java! (Not too unlike most languages, I'm forced to admit.)

Is the technology of software development and programming languages/environments so immature that we haven't been able to handle something simpler? Or are the tool developers so used to doing this that they don't see it as something worth eliminating?

I saw a new technology the other day that started with an "A" I believe. It was a new way of creating software, supposedly. But you know how big claims are put on incremental technologies. Someone takes a very simple idea and all of a sudden they believe they have changed the fundamental nature of programming.

Well, as best I can tell, this technology, as it is currently implemented, is really a wrapper around every method in Java. As a result, it gives the coder the ability to change specs in those wrappers to do interesting things. For example, if you want to audit the flow of the program you can just change the wrapper once and it affects everything. Now you can see that with a little thought, there are other things that can be managed in more global way by handling it at the point of entry/exit from other code.

That's what comes to mind when I think of how you have to define a variable, create an object, look for certain events, etc. etc when adding a simple control to a Java program. You are doing a very specific thing with your program in terms of requrements and functionality, but Java forces the coder to artificially patch code into multiple places in the program. Yes, it gives a sense of flexibility -- you can create just about anything it seems like -- but what about the 80/20 rule. If you look at programs, I bet that the typical features of 80% of Java programs have very similar kinds of code and requirements. Shouldn't that be handled better?

Two approaches seem to have made some headway in this area. One is code generators that use UML class diagrams to get the code started. But realistically, I'm not sure how much time this saves. Another, which is much more effective, is the GUI builders in IDEs. But isn't it kind of rediculous to have all that translation work going on in the IDE? Why not let the programming language support the typical kinds of things a GUI builder has to handle. No, I don't mean the layout part. That's natural to keep that distinct from the language (I think). But what about all the other specifications. Once the GUI builder gets the layout, look at the messy code that has to be scattered all over once it's translated.

That's not very efficient in my mind, and it seems like there's a big gap between programming languages and the actual things we are usually trying to get programs to do. Languages should support the basic things better, and it shouldn't have to spread code all over to implement ONE concept. Why is the IDE doing all the work to simplify programming. Java took some small steps, and people jumped on board even though there wasn't really much help from IDEs in the early days for programmers in Java. Now the IDEs are catching up. If Fortran and COBOL were like Vodka, then maybe it's time to move from Java to Coke and find a simple way to program that can handle both the scattered code required now and helpful sometimes maybe for flexibility, and also handle translation of real requirements for simple functionality into ONE single change to the program! Back to the GUI thing... why is it so cryptic to do event handling? It's way too much work for simple tasks. Even adding a menu item and setting up a place to handle it. Experienced programmers probably don't care because the IDE does it or because they can do it in their sleep. But if you add up all the work and mind processing cycles spent on that same kind of artificial work across the whole development process, isn't that crazy? Kind of like how it makes you wonder why refactoring, as in changing a method name, has to be such a chore. Whether done by hand or by a tool, there's a lot of work and things to keep track of. Is it hard because it's just a hard concept, or because we haven't figured out how to reflect the simplicity in a development language and environment?

Okay, that's as far as I'm going to go with that. But to summarize... I don't think the simple programming tasks common to most programs should be so difficult and require code to be touched in so many places for a simple program element. But until I am a better programmer, and can come up with some answers, I guess it's just another complaint.

I'd also say, I'm losing my appreciation for SuperWaba in the sense it seems like it may not be a great choice for a hobbiest due to some of the complexity and issues and lack of support options. But I will press on and study some more examples and try some more smaller pieces of sample code and try to get things working. I may change my mind after I know more about this whole thing.

But in the back of my mind right now, I'm thinking... Just work on this enough to feel like you can do some basic stuff and write a hilo guessing game, and then try something a little more fun like NSBasic. Only time will tell!


Post a Comment

<< Home