chooses not to generate code at all

[Henk Verhoeven]

We are not alone! "Where other MDA tools are generating programmingcode ,
Codeless chooses not to generate code at all".

OK, phpPeanuts is not an MDA tool (it has no fancy modeling GUI). But it
does generate application behavior straight from the metamodel, without
generating code. And we did not need "a decade of know-how in
maintaining systems with more than 30 million lines of generated code"
to understand that it is not necessary to generate code, that generating
code is only generating a maintenance problem.

Though free for download, Codeless does not seem to be open source.
Nevertheless, it is good to have other advocates of "no code generation"
MDA/D. Let's hope they are successfull!

Henk Verhoeven,
www.phpPeanuts.org.

For more info on Codeless google for "chooses not to generate code at all"

[Colin McKinnon]

Re: chooses not to generate code at all

Henk Verhoeven wrote:
[color=blue]
> We are not alone! "Where other MDA tools are generating programmingcode ,
> Codeless chooses not to generate code at all".
>[/color]

(but on http://www.codeless.com/lib/img/builder.jpg the final stage seems
to be 'saving scripts')

I think the idea of codeless programming is interesting. The problem is
doing it in a way that actualy simplifies/streamlines the task while at the
same time limiting the trade-off of functionality. Most of those 'million
lines of code' in a ERP type application are doing the same thing -
validation. It's easy to find out if the data fits the relational model -
the problem is ensuring that it fits the business model (has the order been
fully paid before delivery occurs, is the delivery address the same as the
billing address). That takes more than just a regex mask. OTOH the thing I
like about PHP is that its easy to learn but very efficient in terms of
programmer time for producing solutions
(http://shootout.alioth.debian.org/). Does PHP really need RAD tools?
Certainly I found myself spending too much time maintaining very similar
code (fetch data, draw form, validate, insert/update/delete) and looked for
something to make my life easier.

Prado has an interesting take on this, but requires learning of a new
programming syntax. PhpPeanuts seems make provision here too.

I chose to take a more traditional approach with PfP
(http://pfp-studio.sourceforge.net - "a WYSIWYG editor that allows you to
place user interface components on a window"). And provide direct access to
the underlying PHP/Javscript/CSS. It's not yet as complete/polished as the
other offerings, but it is getting there (new release expected in a month
or so).

C.

[topmind]

Re: chooses not to generate code at all


Henk Verhoeven wrote:[color=blue]
> We are not alone! "Where other MDA tools are generating programmingcode ,
> Codeless chooses not to generate code at all".
>
> OK, phpPeanuts is not an MDA tool (it has no fancy modeling GUI). But it
> does generate application behavior straight from the metamodel, without
> generating code. And we did not need "a decade of know-how in
> maintaining systems with more than 30 million lines of generated code"
> to understand that it is not necessary to generate code, that generating
> code is only generating a maintenance problem.
>
> Though free for download, Codeless does not seem to be open source.
> Nevertheless, it is good to have other advocates of "no code generation"
> MDA/D. Let's hope they are successfull!
>
> Henk Verhoeven,
> www.phpPeanuts.org.
>
> For more info on Codeless google for "chooses not to generate code at all"[/color]

I have been experimenting with the generation of CRUD screens (biz data
edit and display forms) using data dictionaries, which are basically
tables filled in with attributes about the fields or columns. Although
I originally agreed with no-code-generation, I have since softened
somewhat.

One possible reason to generate code is for speed. Acting on meta data
can be slow and Moores Law hasn't quite caught up just yet on some
platforms/tools.

Second, code is more elastic than the meta model. If there are things
that the model driver cannot handle, diddling code is often the only
alternative. In the end I think if there are enough "override events"
avialable in enough places, then such diddling wouldn't be necessary.
Event-driven programming would take care of stuff not expected in the
meta model design. However, such a framework would be non-trivial to
construct because it would probably need many event override points.

Someday in the future it may work, but we are not there yet.

-T-

[JXStern]

Re: chooses not to generate code at all

On 20 Aug 2005 21:02:55 -0700, "topmind" <topmind@techno logist.com>
wrote:[color=blue]
>I have been experimenting with the generation of CRUD screens (biz data
>edit and display forms) using data dictionaries, which are basically
>tables filled in with attributes about the fields or columns. Although
>I originally agreed with no-code-generation, I have since softened
>somewhat.
>
>One possible reason to generate code is for speed. Acting on meta data
>can be slow and Moores Law hasn't quite caught up just yet on some
>platforms/tools.[/color]

Aaaaaaaaaaaarrr rggghhhhhh!

My current home workstation is about 4,000 times faster than were
typical minicomputers when I first discussed the automagic discussion
of CRUD screens, and CPU speed wasn't even an issue back then.

J.

[topmind]

Re: chooses not to generate code at all

[color=blue][color=green]
> >One possible reason to generate code is for speed. Acting on meta data
> >can be slow and Moores Law hasn't quite caught up just yet on some
> >platforms/tools.[/color]
>
> Aaaaaaaaaaaarrr rggghhhhhh!
>
> My current home workstation is about 4,000 times faster than were
> typical minicomputers when I first discussed the automagic discussion
> of CRUD screens, and CPU speed wasn't even an issue back then.
>[/color]

But UI techniques and user expectations have also changed. For example,
Query-By-Example was rare or limited back then, but almost always
expected now.

-T-

[JXStern]

Re: chooses not to generate code at all

On 21 Aug 2005 12:23:18 -0700, "topmind" <topmind@techno logist.com>
wrote:[color=blue][color=green][color=darkred]
>> >One possible reason to generate code is for speed. Acting on meta data
>> >can be slow and Moores Law hasn't quite caught up just yet on some
>> >platforms/tools.[/color]
>>
>> Aaaaaaaaaaaarrr rggghhhhhh!
>>
>> My current home workstation is about 4,000 times faster than were
>> typical minicomputers when I first discussed the automagic discussion
>> of CRUD screens, and CPU speed wasn't even an issue back then.[/color]
>
>But UI techniques and user expectations have also changed. For example,
>Query-By-Example was rare or limited back then, but almost always
>expected now.[/color]

Humbug. Dbase II did QBE on 4.77mhz, 64kb PCs.

Of course the databases weren't very big, had to fit on a 360kb
floppy, or at most a 10megabyte XT disk!

GUI? So what. My workstation isn't exactly busting a gut doing GUI
things for other programs.

If your Java Swing interface is doggy, it's doggy plus or minus any
metadata-driven considerations.

J.

[Henk Verhoeven]

Re: chooses not to generate code at all

topmind wrote:[color=blue]
> I have been experimenting with the generation of CRUD screens (biz data
> edit and display forms) using data dictionaries, which are basically
> tables filled in with attributes about the fields or columns. Although
> I originally agreed with no-code-generation, I have since softened
> somewhat.
>
> One possible reason to generate code is for speed. Acting on meta data
> can be slow and Moores Law hasn't quite caught up just yet on some
> platforms/tools.
>
> Second, code is more elastic than the meta model. If there are things
> that the model driver cannot handle, diddling code is often the only
> alternative.[/color]

Well, maybe data dictionaries are somewhat limited as a means for
expressing a model. If you use objects and classes, you can have
subclasses where you can override code. If you use literals in methods
as you declarations, you can override the declarations with different
values but you can also decide to do some calculation to produce the
methods' result. You can also override a method that instantiates a
class and let it instantiate a different one. Then when the model
delegates to that object, you have yet more opportunities to make
overrides.
[color=blue]
> In the end I think if there are enough "override events"
> avialable in enough places, then such diddling wouldn't be necessary.[/color]

Isn't making an OO desing and writing proper OO code exactly that:
making enough override events? (No, it's also choosing/shaping the right
ones)
[color=blue]
> Event-driven programming would take care of stuff not expected in the
> meta model design. However, such a framework would be non-trivial to
> construct because it would probably need many event override points.
>
> Someday in the future it may work, but we are not there yet.[/color]

I agree that buiding a VM for an OO language like Java, Smalltalk or php
is a non-trivial event. But so is building real life applications. My
point is: I do not agree with your distinction between the framework and
the model it is executing. The model can express simple 3GL style
commands or more sophisticated ones, like with QBE. There is no
fundamental disctinction between semantically more rich objects and
objects modeling 3GL statements: as soon as there is delegation to
objects that are created and configured by the model, the model has been
'programming itself'. At the same time the model can be partly expressed
in the same language as the framework itself. Building an application is
both overriding AND extending the framework. Refactoring of the
application can lead to those extensions being drawn into the framework
itself, or the framework to be refactored to add some very usefull new
override events needed by the application. Waiting until someone builds
this fantastic silver bullet framework or MDA tool is limiting yourself.
Your only limit should be your imagination.

(Nice PR talk huh? In practice our time is limited, and all framework
development is a balancing act between expressive power, simplicity and
flexibility of the framework at one side and getting real life
application(s) to work at the other. ;-) )

Greetings,

Henk Verhoeven,
www.phppeanuts.org.

(BTW, forgive me my remark about data dictionaries for expressing a
model, LISP expresses everything as linked lists, but that does not seem
to limit its expressive power. I guess it's making a distinction between
data and code that is limiting)

[topmind]

Re: chooses not to generate code at all


Henk Verhoeven wrote:[color=blue]
> topmind wrote:[color=green]
> > I have been experimenting with the generation of CRUD screens (biz data
> > edit and display forms) using data dictionaries, which are basically
> > tables filled in with attributes about the fields or columns. Although
> > I originally agreed with no-code-generation, I have since softened
> > somewhat.
> >
> > One possible reason to generate code is for speed. Acting on meta data
> > can be slow and Moores Law hasn't quite caught up just yet on some
> > platforms/tools.
> >
> > Second, code is more elastic than the meta model. If there are things
> > that the model driver cannot handle, diddling code is often the only
> > alternative.[/color]
>
> Well, maybe data dictionaries are somewhat limited as a means for
> expressing a model. If you use objects and classes, you can have
> subclasses where you can override code. If you use literals in methods
> as you declarations, you can override the declarations with different
> values but you can also decide to do some calculation to produce the
> methods' result. You can also override a method that instantiates a
> class and let it instantiate a different one. Then when the model
> delegates to that object, you have yet more opportunities to make
> overrides.[/color]


Data dictionaries can have defaults also. The problem with polymorphism
is that it tends to assume too much grouping or coupling by "type" or
"kind of". In reality a more a-la-carte approach is needed in my
experience, and poly is just not good at a-la-carte. (We just had a
long-running battle about this under the "Polymorphi sm Sucks" topic. No
need to rekindle that here.)

Further, OO tends to marry you to one language. A DD-based approach
(declarative) can be more language independant. (I don't pretend it is
always 100% possible, but declarative usually helps.)

[snip...]

-T-

[topmind]

Re: chooses not to generate code at all

[color=blue][color=green]
> >But UI techniques and user expectations have also changed. For example,
> >Query-By-Example was rare or limited back then, but almost always
> >expected now.[/color]
>
> Humbug. Dbase II did QBE on 4.77mhz, 64kb PCs.[/color]

Yes, but it did not have ranges, non-template validation, picklists,
etc.

-T-

[JXStern]

Re: chooses not to generate code at all

On 26 Aug 2005 21:54:03 -0700, "topmind" <topmind@techno logist.com>
wrote:[color=blue][color=green][color=darkred]
>> >But UI techniques and user expectations have also changed. For example,
>> >Query-By-Example was rare or limited back then, but almost always
>> >expected now.[/color]
>>
>> Humbug. Dbase II did QBE on 4.77mhz, 64kb PCs.[/color]
>
>Yes, but it did not have ranges, non-template validation, picklists,
>etc.[/color]

Buggers if I recall, maybe that took dBase III and a 12mhz 286 with
256kb.

What on earth is non-template validation anyway?

J.