Re: [EVALUATION] - E01: The Java Failure - May Ruby Helps?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Austin Ziegler wrote:
| On Thu, 17 Feb 2005 02:04:51 +0900, Markus Pilzecker
| <[e-mail]> wrote:
|
|>Austin Ziegler wrote:
|>| Actually, Ilias, it is 100% accurate. There is no system in
....
|
| A "generic" model transformer and generator, yes. A framework,
| maybe. It depends on the capabilities. However, properly stated,
| code generation is a toolbox, not a tool.
|
Agreed.  It only makes sense, if the transformer|generator framework
is to such an extreme degree customisable, that you can call this
programming.

....
|
| Yes, but a generator isn't necessarily the same as what was being
| talked about. All of the generators that I've ever used have been
| domain and application specific.

At least those modern ones like AndroMDA or ArcStyler are quite
independent of the practical domain.  They are of course to some
extent specific to the target technology -- but only in one aspect:
you get delivered object technology for the transformer|generator
framework plus some ``library'' transformers, you can start with.
These latter are partially quite generic like an EJB generator, you
can derive your own specific, lets say Jonas-, generator from.
Partially, you get e.g. a concrete product-specific WLS8 generator.
And for this, of course, it's quite right to speak of specificity
wrt. the target technology.


| Additionally, proper generation
| techniques indicate that you should know how to implement at least
| one of the items you're generating (e.g., if you're developing a
| generated GUI, you should develop at least one screen by hand; the
| same applies to web interfaces, etc.)
|
Well, frankly, I'm not such an expert in EJB-technology, but I'm able
to set up my own hello-world application with a handful of classes
with a running Weblogic Server in a day or so.  I do not even have
to have seen the interior of a deployment descriptor[, as long as
things work about as expected ;-) ].  Of course, if it comes to
debugging, while trying to understand, what's going wrong, I
certainly don't get around digging deeper into EJB-technology.


....
|
| Not at all. Code generation is a technique -- a toolbox -- and not a
| silver bullet. It's a very valuable technique, and various tools can
| help with the technique, but there's still *no such (singular) tool*
| to generate an application and make it run everywhere in every way
| that makes it feel right for those platforms. It's a non-soluble
| problem, especially when you get to user interaction and platform
| look-and-feel.
|
Of course, at least one person [or company or whatever] has to perform
this technology [+user interaction, ...] -projection at least once.
It's as at least one person has to write the gcc-backend for the
(n+1)st CPU-type.


| To take a simple example, there's a development tool for mobile
| development called "AppForge". This plugs into a Visual Basic
| development environment and allows you to generate mobile apps for
| the PocketPC, PalmOS, Symbian, Windows Mobile, Windows SmartPhone,
| and a few other targets, I think. The application thus generated
| requires a massive runtime (300Kb on PalmOS systems)

Then, the generator does not [completely] map to the target platform.
The problem probably is, that it is more expensive to implement a
reasonably complete technology projection into a generator than to
implement an emulation layer.


| and doesn't
| look like native applications. Similarly, Java's Swing doesn't look
| or act like any other application on a platform.
|
This is a phenomenon inherent to a portability scenario.  Would you
want to overcome this, had you to invest much into flavor-mapping.
Most of the time, it is decided, that it's not worth it.
And you cannot even say, that it is bad, if it does not look as
PalmOS.  Me, not knowing PalmOS, may make it feel at home, when I
find something looking like Swing.


| If a developer for the platforms in question can't do it, what makes
| you think that a transformer/generator will be able to do it?
|
I don't think that.  A generator will not produce better code than
a good informatician.  But since it has the ability to gather some
structural knowledge, it can produce much more code of about the same
quality as that of a good informatician.  In the long run, a generator
may gather optimisation knowledge, like peep-hole optimisation, loop
unroling, design patterns, ..., which a programmer can not apply
alltogether in a short enough time.


|
|>| Because such a tool would SUCK. As every single CASE tool in
|>| existence has ever done. CASE tools generally require that you
|>| run a very large runtime, program *their* way, often in *their*
|>| language (which isn't related to anyone else's), and then tend to
|>| fall behind both operating system releases and the technology
|>| curve.
|>Transformer|generator frameworks concentrate the knowledge of the
|>target technology in the transformation engine. At least for
|>simpler scenarios, this does not at all imply generation or use of
|>a runtime system:  e.g., if you have modelled your system in
|>ArcStyler and use its Java2-cartridge to generate code of it,
|>there is nothing near to a runtime system, which comes into the
|>game. And the result is [at least beyond javac] as slim as what
|>you could code by hand.
|
|
| Maybe. I'm very skeptical of claims in this direction. Indeed, what
| the OP wanted was something that could be run on an embedded device,
| a workstation, or a cluster of servers. I'm sorry, but I stand by my
| original statement: there's no such tool -- not even ArcStyler --
| which can do that.

Of course, not out of the box.  Because this required, that the
transformer|generator knew all _your_ requirements, constraints and
trade-offs in advance.  But a good transformer framework can make it
acceptably easy to articulate these specifities.


| (And I'm unsurprised that UML is being pushed
| this way. UML is good for very few things, and the most important
| part of making an n-tier database applications is one of the things
| that UML is worst at: data modeling.

I'm not sure, if it is that bad: define the datatypes of your database
and store that in a profile.  Every table is a class with attributes
/*the columns*/ of one the available types.  May be, I oversimplified
a bit -- but did I too much?

The other question is, if it _should_ be good at that.  At least the
a-priori assumption was[ according to some human judgement of a certain
community], that OO is superior to ER.  And if you have legacy RDBMSs,
you have specify some OR-mapping -- most probably somewhere in your
transformer model.  If you don't have that legacy, you could have that
mapping undercover -- or you use an object database anyway.  In these
latter cases, you won't have to model any ER part.


| It's too based on OO
| technologies to even remotely come close to properly modeling data
| relationships other than hierarchical.)
|
Where is the restriction to hierarchies?  I think, I'm able to draw
general graphs...

| [major snippage]
|

|
| Again, maybe. ArcStyler and other OMG-driven insanities won't help.

If you criticised, that abstraction requirements on those, who have
to program the transformers, misses market availability, you may have
got me to agree.  And of course, commitee compromises tend to be far
from satisfying.  But using transformers to convert graphs, be it
on MOF-level-1 or on MOF-level-0[, which is the usual case in ``normal
programming'',] or between level 1 and level 0 [or between 2 an 1]
is a paradigm, I won't easily give up.


| Being able to state requirements clearly will.
|
Ack.


A+,  Markus


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFKX90sM4x4ItYcQRAmH7AJ9o/yZQ4hST16qJvwRwqfkEup0uXACfUWle
nEZ3yXqJ6GWyVIBmi9W95eU=
=VTmZ
-----END PGP SIGNATURE-----