Red Hat Diaries/003b

RandomApp II

>But doesn't this 'visual' stuff create a lot of junk in the code?

Nope. And I think the Next engineers would have thought about that a 
long time ago.

Look at it this way:

In Windows you just have a naked dialog, that's that. You have a 
script which says 'this dialog will appear here and here and have a 
width and height of... And it will have a caption, a system menu, 
blah blah. And in this dialog you will have a push button with the 
value 1 and the text 'OK' and you will have another push button with 
the value 2 and the text 'Cancel' etc.

The NS way you have the same thing, but each dialog control is half 
of a conduit and has attributes the program can see when the dialog 
is loaded. All controls have attributes now. You say, as in this 
example, the 'Generate random seed' button goes to class Foo's 
action seed:. You say, again as in this example, the 'Generate 
random number' button goes to class Foo's action generate:.

When you click a button in Windows, your dialog procedure has to 
catch it. You parse the second argument to verify it's a WM_COMMAND, 
then you look at the third argument to pick up the button ID (button 
ID is in the lower half, the upper half is actually the message 
'button clicked' which has a value of 0, so you can disregard it and 
just take the whole third argument as is), then you figure 'oh ok, 
he wants a random seed' or 'oh ok, he wants a random number' and you 
put it out in a third static text control. That's it. And as in this 
example, you can catch the WM_INITDIALOG message to, for example, 
just display the current time for the heck of it.

In the NS way, the logic is already in place. You don't have to 
single out your static text field - the pipeline has already been 
drawn for you. You don't have to catch incoming messages - that's 
all done for you. You write the incredibly simple (one line) 
functions to seed the random generator and generate random numbers 
and then you don't do ZIP after that - you just run it, and it works.

And although it _might_ average out to just about the same amount of 
code, the NS way is so much faster to develop. You don't have to 
keep track of control IDs (frankly I don't even know what IDs the 
program chose) - you just 'literally' hook it all up together.

This is _exactly_ what I saw Andreas do for Agneta ten years ago at 
the 1992 Unix Expo in Stockholm when he built her an entire 'black 
book' phone book app in five minutes without ever writing a single 
line of code. These 'lines' come out of nowhere and you see how the 
different parts are being hooked together - and that's it.

Total size on disk is 8097 bytes.

Click here »