|
Programs that write programs
My current project includes a number of functions which write programs based in part on the user's input, although it is not actually intended for use by programmers.
Frankly this has been like wading thru glue even though I am not actually generating that much code.
It got me thinking about programs that write programs more generally.
Many years ago, there was some program (for the PET or Apple ][ or something) called "The Last One". It was advertised widely to business users (not programmers) as being the last program that they needed to buy. I never used the program, but the idea was, at least for certain kind of programs, the user filled out menus and stuff, and the program was written for him. I do not know how well it worked. Obviously it can not really have been the Last One literally, as people still write and buy other programs.
Another very loosely similar think I remember was some kind of Borland tool (Object something for Windows 3) which allowed the user to sort of drag out a flow chart, connect the boxes, and enter actions for the final program to do. I do not think this can have been that successful, as it isn't still on the market as far as I know
I do realize that there are many RAD and CASE type tools which generate code, but they seem to be largely aimed at programmers rather than users. VB may be relatively easy, but give it too somebody with no interest in programming and no desire to write code ... and see how far they get.
So my question is why are end-user development tools so rare (or if not rare, rarely used by typical PC users)
- Is there no market for them? I find that a little hard to believe, talk to almost any computer user and there is nearly always some little utility or something they wish they could knock up, but they don't have the skills or time.
- Is it that the theory or technological obstacles are too hard?
- Is it an insoluble task because programs do something that software can not hope to emulate even with user guidance?
S. Tanna
Friday, January 30, 2004
To use the local vernacular, I'd say "Leaky Abstractions".
Or, "Make something easy enough for a fool to use, and only a fool will use it".
To make a complicated algorithm simple, you have to make some assumptions. Any assumption has the potential to make the process unusable for a programmer. Enough assumptions, and you've eliminated all programmers.
Nigel
Friday, January 30, 2004
I've been having this discussion at work lately. We recently added a scripting API to our desktop application. Another developer thought it would be cool to write a program that generated code to call the API, because "our users don't want to write code."
My argument was if our users don't want to write code, why have a scripting API at all? If most users will just use "script wizard" why not just implement the features that in script wizard, rather than generating a script to do it? An example would be to generate a script to email workbooks. Again, why generate a script? Just add the feature to the program.
christopher baus (www.baus.net)
Friday, January 30, 2004
So, what's the input to the program that writes programs? If there are a limited number of options, you won't be able to do that much. If there's lots of flexibility, the input is basically programming language in its own right, though it still might be helpful.
For example, a spreadsheet is a program lets it non-programmer do all kinds of nifty thing. However, Excel, with all its functionality, is a programming language, whether or not you think of it as one.
It's often helpful for a more powerful language (like Java) to generate code in a less powerful language (like HTML). However, I haven't tried to write a code generator that creates Java; writing an interpreter is generally easier.
Of course, code that generates code is what gives LISP its power.
Julian
Friday, January 30, 2004
> So my question is why are end-user development tools so rare (or if not rare, rarely used by typical PC users)
I've recently been exposed to National Intruments' LabVIEW product. People ('end-users') write some big programs with it, mostly to work with signals (for example, temperature and motion-control sensors, biomedical signals, ...). Interestingly its 'language' or IDE is completely graphical, not text-based: 'source code' looks like a circuit diagram (its target market might be electrical engineers).
Christopher Wells
Friday, January 30, 2004
Wow, how rare is it for someone to remember the Commodore PET. I actually went to school at Commodore in Chicago to work on those. ( whoops, I think I just got pegged as a old dude).
moses whitecotton
Friday, January 30, 2004
We used PETs at school as well. At the time (~1980-81) we had 2 for the whole school.
The only coherent thing I remember about using the things was that "poke 144,36" disabled the keyboard. Slipping it into someone else's program was considered hilarious.
a cynic writes...
Friday, January 30, 2004
That comment about LabView reminded me of something
Years ago, I did a port [although it was actually a rewrite, given 2 very different 8-bit machines] of some kind of "programming" tool for Robots (arms and stuff). I remember there was some kind of menu driven interface for setting up a "program". I think it may even have had loops and conditions, but I could be imagining that.
When I subsequently read an article about Labview, it sounded surprisingly similar (although Labview sounds like a 1000X more sophisticated than my little project)
Anway, going back to original topic
- I don't know what the interface is for a program-to-write-programs - menus, free text, draw a flow chart, something else?
What I still don't know for sure, is whether the problem is
Either, Too much input is required, i.e. specifying the program properly is the same as writing it
or, Something Else
P.S.
To the person with that macro wizard, code-generating debate for his app...
If you are going to do this type of customization often, and want end-users (okay techie end-users) and VARs (if you have any) to be able to customize your app, go with the macro language. A recorder can be cool too - e.g. see WinWord recording VBScript.
S. Tanna
Friday, January 30, 2004
A blast from the past. I remember seeing "The Last One" being blazened all over the front cover of the UK's "Practical Computing" magazine around 1981. I also remember being teased by friends that my chosen profession had just been rendered obsolete...
Some obsolescence.
Ultimately, all these things are just DSLs, "Domain Specific Languages". They are very useful, but they are specifically *not* general purpose languages, unless they have been embedded in one such as Lisp, Rebol, Haskell or the like.
David B. Wildgoose
Friday, January 30, 2004
That's my point
We don't seem to significantly advanced in this field in 23 years. I don't really understand why not?
S. Tanna
Friday, January 30, 2004
The code generator systems are generally what we refer to as 4th GL systems.
And, those so called “early” code generators for the Apple II and the PET were very much template type driven system. You fill what fields you want to display on the screen, and then the code to “edit” those fields was generated.
You see, way back then, to make one those simple screens to edit a database, you had to write your own code. Quite a bit of code in fact. Anyone write one, or many of those CRUD screens (too quote a recent post here CRUD = create, read, Update, Delete) screens. In fact, I wrote quite a few of those systems, some even in Apple II basic (AppleSoft). At that time, it was common to see those program generators to “make” those edit screens. After all, a HUGE number of applications simply needed some fields, a screen to edit those fields, and then a means to print out what you typed into the system.
This is the classic initial computer boom. You could make good money writing code to simply edit address fields for a SIMPLE customer mailing list. The ONLY functionality the mailing list had was edit, add, and print out the mailing labels. This kind of software was a real cool thing, and a big boom to the early adopter business that used this way cool technology.
I am not kidding when I say way cool technology for simple editing of a list in a computer. This was a BIG deal back then. In fact, I know some business that grew by huge amounts back in the AppleII days SIMPLY BECAUSE they starting doing mailings to their customers! Often, a similar business down the street was NOT using a computer for mailing lists. When I look back, it is amazing the difference some simple technology could make (that small company grew way faster then their competitors). I saw the same thing happen when some business started using Fax machine.
After a good many years...all business use these basic technology, and the playing field is now level.
Of course, then programs like DbaseII and the flood of pc based database programs began to appear. This programs overnight caused a real sensation, as now we developers did NOT have to write those CRUD screens. All of a sudden, in stead simply writing mailing list software, I was writing stuff like Reservation software, or job costing stuff. In other words, all of a sudden, the cost of developing software for small business because affordable. Without the cost coming down, the small business software market would NOT exist.
So, the questin in this thread is why not more code generators today?
Well, in fact, the template systems kind of won the day. What do I mean by template systems? Well, of course I mean systems like VB, ms-access, or FileMaker or Alpha5. The only exception to a non template driven system in the early 90’s was FoxPro 2.6 and the included “power tools”. Virtually every other popular database system that was coming out went with the Template system, and did NOT generate code. However, many of the code generating systems were quite good, but it seems to me that a template system was a better approach.
By template system, I simply mean you design your screen, and then the “structure” of the screen is saved. When you run the application that screen structure is loaded/interpreted and you see a screen. That screen information can be just a bunch of x,y values, and the type of control that will be seen on the screen. This structure was usually just a bunch of arrays of info. The runtime system simply interprets that structure. Anyone who has looked at a VB6 .frm file will see that in fact, they did not just store the structure. In fact, the VB approach was little more complex, as instead of storing a bunch of x,y values and the type of control, MS actually came up with a meta language that they do interpret. So, VB6, and ms-access are kind quasi code generators. (actually, I would love for someone to clarify if that frm code is compiled in VB6).
Further, a few people have pointed out that in .net, the actually form language is NOT interpreted, but actually creates real executable .net code! (in this vb.net code). (I always wondered why VB6 did not just create real VB code, as that VB6 frm meta code sure looks close to VB...but is different). Apparently in .net, it is actually code now.
FoxPro also generated code after you make the screen, where products like ms-access and DataEase etc simply interpreted that structure, and code was NOT generated (as mentioned, VB/ms-access does crank out code, but that code is interpreted into a screen structure at run time anyway).
Anyway, the LARGEST reason why we don’t need to generate code is that modern programming languages has things like objects, and collections. BOTH objects and collections can USUALLY be reference by a value in a variable. In the old systems you count not resolve a string value to a stored variable. In fact, you can’t in most modern languages today. You can in FoxPro resolve this via:
Input “what variable to display “, strUserInput
Display “the value of “ + strUserInput + “ is = “ + (&strUserInput)
The above is just air code, but the point is that you can have a string value used in place of an actual variable name to reference a variable value. If you enter “a” in the above, then the contents of variable “a” will be displayed. In products like VB or ms-access, you can can’t do this for code variables, but you certainly can reference any member of a collection. Since everything is a collection in these modern languages, then you can also get at any object value by using a string value:
Input what Form to displasy: strForm
Input What Control value to display: strField
Msgbox “the value is “ & forms(strFrm)(strField)
Since you can now use a string value, you don’t have to generate code like in the old days (that was the ONLY way to take a given input, and resolve to a given value). So, today with the adoption of objects in modern languages, this problem is gone.
Back then, you need to store what you are going to prompt for, and WHERE this value is going to be saved/retrieved. Back then, with no objects, the value had to be resolved in code, and NOT at runtime.
I have writing a number of template systems. In fact, I still write template systems today. For example, I need a search screen. That screen will prompt the user for what they are looking for, show the user a list to choose from, and then when the user clicks on one of the displayed results, then a form is opened to edit that choice.
I sincerely hope that you as developer does NOT write that same above process over and over. I am absolute stunned when I see developer sitting down to code that above problem OVER AND OVER.
In fact, the quote I am doing today for a old customer is for a re-write of a system I wrote in 1986. They still run, and use this system every day (not bad, a that is a 18 year run!). I am promising them that the next re-write will last at least another 10 years. However, even back then, looking at my software, the process of prompting the user for a customer, displaying the results, and then launching a form to edit that customer was template driven. In other words, I did NOT write code to accomplish this task over and over.
In fact, the EXACT process of searching used in that application is outlined here:
http://www.attcanada.net/~kallal.msn/Search/index.html
That above screen shot is in ms-access, but again, I use a template system. You see, you might not be looking for a customer, but in fact looking up a part number, or whatever. To sit down each time, and start coding a search screen is plain silly. People don’t do that anymore...do they?
So, while we don’t see very many code generators anymore. I do know that most developers for re-occurring tasks like stupid search and pick from the results screen do write a template system.
In my ms-access example, it is a class object, and a entry in a table that stores stuff like what fields to display in the results, what field to prompt for, and even the headings etc is stored in a table. I also save what sql to use to etc. I have likely about 8 or 9 of those search screens to make in the re-write of that old software. In stead that taking 2 or 3 hours of development per search screen, it likely will take 5, or 10 minutes max per search screen. So, once again, this type of coding makes the resulting software affordable for small business. We are talking about reducing 20, or 30 hours of work down to less then 2 hours of work! Most amazing here is that the old way of searching is still how I do this to this day. Hum,....it seems some things don’t change that much!
So, code generators are not much used, since the development languages are very flexible to day. Way back then, often you could not even use a variable name to reference a field in a data table. Most modern languages allow you to reference a member of a collection object with a variable at run time.
So, as a result of being able to resolve references at a runtime, there is little need to generate code to build template systems.
Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn
Albert D. Kallal
Friday, January 30, 2004
Programs that write programs are the happiest programs in the world.
-Tom Christiansen
fool for python
Friday, January 30, 2004
two words .... Microsoft Access
Tapiwa
Monday, February 2, 2004
 Recent Topics
Fog Creek Home
|
