« Hurts so sweet… | Main | Oldschool »
On the contrary (subtitled: Rapid Application Development)
By farseeker | July 3, 2008
In complete and utter polar opposite to Insanity’s last post, my job as a programmer does not require me to write a single line of code. Ever. I can (and my boss has, more than once) build massive enterprise systems without ever encountering a syntax error, a mis-placed semi-colon or an any sort of incompatibility.
See, I work in a tool called eDeveloper, by Magic Systems (in fact the version of the tool I use is called Magic eDeveloper, or Magic for short. In 1983 when they launched the product I’m sure it was a cool name but these days… not so much). It’s a completely code-free environment.
Now when I was at Uni, we learned about Rapid Application Development environments (or RAD for short), but nobody I knew had ever been exposed to such a thing. So I thought I would provide a short tutorial on what a RAD tool looks like.
Before I start, I should point out that this is a post-fourth-generational tool, which is about as far removed from any sort of code as you can possibly get. It’s a full-on RAD tool (an example later) that takes a lifetime to master (like any good IDE), but you can learn the ropes in a month or two of practical work.
Firstly, you start with a blank application, except in the terms of eDeveloper an application is sort of like a C++ Class. Sorta. Kinda. But not really. But that’s the easiest way to describe it. Inside the application you have programs (which are like functions… only not).
The programs can be one of three sorts (we only use two): Online, Batch and Browser. Online is a traditional GUI, and you draw your interface in a similar way to VB:
The “code” behind it (think of this in terms of a function definition) is not written by hand. Rather there are a set of different kinds of commands (Select Real – selects a column from a database table, Select Virtual – a custom variable, Link Query/Left Outer Join – retrieves data from a different table, Call Prog/Task – Calls another program/task level, etc). You select your command and then fill in any missing parameters. Virtuals and Reals (or variables and database columns) are all referenced with a letter, A-ZZZ (strings and expressions are referenced with a number from 0-999). Strange I know, but you get used to it. Coding is actually incredibly fast, because you use the keyboard heavilly, rather than mouse clicking. E.g. pressing S 2 selects the second column from the table (rather than typing “SELECT column FROM table” and then executing said command).
Batch tasks are exactly the same as above, but without the GUI. They run in the background and loop through all the records in dataset executing the same rules on every row. Batch tasks are also used for interfacing with web sites.
It’s quite a different world, and for a PHP programmer it took a lot of getting used to. In PHP your interface and your logic are wrapped up in the same place. Same with ASP. But in eDeveloper, you place a “Magic Tag” in your HTML file, then you go to eDeveloper to do your logic. Say you need to insert a persons name. In PHP you might go:
<?–PHP echo(MySQL_Result(MySql_Query(‘SELECT name FROM table WHERE id=0)) ?>
(My syntax is probably horrible, its been a while since I did any PHP) – wheras in eDeveloper you would type <!$MG_Name>, go into eDeveloper and map the “Name” tag to a field in the database. I’m trying to think of a clever analogy to make it all make more sense, but I can’t.
That’s probably about enough for the moment, without giving away any more probably confidential screenshots (I tried to keep it simple!), but if you have any questions feel free to drop in a comment.
Topics: Programming | 5 Comments »
July 3rd, 2008 at 9:59 pm
Though I can see the purpose of many RAD’s, in some ways it amuses me that one would want to code without writing code. Essentially, what is happening with your RAD environment is it is enforcing good Controller Model View isolation. And yet, I sometimes wonder if the overhead of these RAD environments is worthwhile.
I suppose in the case of your uses, the RAD is being used to develop applications in a particular area where the parameters are usually fairly well defined. Just guessing from the basic commands that you have listed, I’m guessing this is essentially catalogue/database type systems.
The fun thing is watching how large a RAD system grows before you realise its more complex than the actual languages they’re encapsulating
July 3rd, 2008 at 10:11 pm
Admittedly, no it’s not as flexible as a traditional programming language, but that just forces you to be VERY creative in solving some problems. I’ve been known to actually write my own ActiveX DLL and embed it in an application just so that I can do something that it can’t.
What overhead are we talking about? Sure it’s not as efficient as byte-code, but that said we’re not building games here. It’s an enterprise system. It needs to work and be rock solid, it doesn’t need to have low system specs.
In one day – yes, one day, my Boss and I developed a predictive dialling application to plug into our VoIP system. That’s something that normally takes a team of people
weeksmonths to do, and we did it in one day with two people.Sure, the RAD tool $10,000/engine and maybe $100/concurrent user (not including development licenses, and we have 5 engines and 150 users) but the amount that it saves in development it pays for itself within 18 months.
July 3rd, 2008 at 11:40 pm
The overhead I was referring to was mental overhead/learning curve overhead not physical execution overhead. I.e., each RAD environment seems to be quite different from the few I’ve seen.
In terms of creativity, I am assuming you are a reader of thedailywtf.com? Many of those solutions are certainly creative, but that doesn’t make them good coding. People who need to come along after to maintain it are going to be scratching their heads a lot likely. Having said that, ActiveX DLL isn’t necessarily a wtf, because I think that this kind of use is what they were intended for.
Just out of interest, the weeks/months… which language did you mean in? Python, Haskell, Lisp… a few others are all very RAD programming languages.
July 4th, 2008 at 9:04 am
Any language really, but because it’s a back-end sytem that probably eliminates PHP etc, so I’d say C/C++/VB/Python/etc.
In terms of learning curve, as a traditional progammer it took me a month or two to transist to RAD methodology. People like my boss, who have never programmed anything, (he’s a mechanical engineer with a masters in economics) pick it up even quicker. In fact you can throw yourself in the deep end with basic training on how to navigate the system and be building useful applications almost straight away (rather than Hello Word).
July 8th, 2008 at 1:12 pm
I’d strongly disagree with the multi-month estimates for any language other than C and C++. These are the primary two languages that still require entirely manual memory allocation, the area where most of the bugs and issues seem to occur.
Instead, the RAD environments you are speaking of, sound like simply another method for programming in a Very High Level Language. The thing to realise with these RAD environments, is they are essentially a pretty interface on a bunch of pre-written libraries.
I suppose, the primary point I am trying to make is that a RAD development environment works well within given bounds, the same as any other programming tool. In RAD environments you become more of an assembler (as in one who assembles ready made parts), because a lot of the tools and libraries have been created.
Ideally, any efficient programming language will provide these same benefits… not just the RAD ones.
The money you pay for RAD is being paid for someone else to give you the toolkits and frameworks you would otherwise need to develop on your own.
Oh, and the initial comparison of having no syntax errors etc., is kind of moot. RAD environments will bring in their own issues and restrictions that are unique depending on how the system is implemented etc. E.g., an app written in Visual Basic may not have syntax errors, but can still have all the major logic bugs that are the true causes of application defects and crashes.