There is a pretty odd article in the online edition of the german
newspaper "Der Spiegel". It seems that some folks came up with a way
to compile UML (or something like that) to .net, java, and
.whatnot++. The claim is that with this, the businessmen set up the
logic, and p00f, out comes the program. No need for developers.
The whole thing is called the "olivanova model execution". Using
google, I have not found any resonable info that is beyond hype. Does
anyone know more about this? Is such a thing feasable?
"Mario S. Mommer" <········@yahoo.com> wrote in message
···················@germany.igpm.rwth-aachen.de...
>
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
There are lots of folks working hard to do such a thing, the main stumbling
block is the complexity of UML needed for non-trivial programs. But for a
survey for state-of-the-art in various offerings, look here:
http://www.codegeneration.net/generators-by-platform.php
Mario S. Mommer <········@yahoo.com> writes:
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
We could perhaps say the wheel has turned. For what it's worth, my
consultant friends tell me the OMG is standardizing something along
those lines: Model-Driven Architecture (MDA). There is also executable
UML (xUML), which probably is related to MDA.
<http://www.omg.org/mda/>
I guess the developers will be let back in when it's debugging time,
as David Golden alluded. And when there are performance problems, of
course. Will it work? Who knows.
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin
Thomas Lindgren wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>
>
>>There is a pretty odd article in the online edition of the german
>>newspaper "Der Spiegel". It seems that some folks came up with a way
>>to compile UML (or something like that) to .net, java, and
>>.whatnot++. The claim is that with this, the businessmen set up the
>>logic, and p00f, out comes the program. No need for developers.
>>
>>The whole thing is called the "olivanova model execution". Using
>>google, I have not found any resonable info that is beyond hype. Does
>>anyone know more about this? Is such a thing feasable?
>
>
> We could perhaps say the wheel has turned. For what it's worth, my
> consultant friends tell me the OMG is standardizing something along
> those lines: Model-Driven Architecture (MDA). There is also executable
> UML (xUML), which probably is related to MDA.
>
> <http://www.omg.org/mda/>
>
> I guess the developers will be let back in when it's debugging time,
> as David Golden alluded. And when there are performance problems, of
> course. Will it work? Who knows.
Don't forget those times when a diagram cannot fully describe the
program logic. Some things just can't be done well like that. In fact,
I submit that even if such a diagrammatic language is Turing complete,
nobody using it by their own choice will know what that means or know
how to make it do anything but the basics of what the language intends
to provide.
All this can effectively do is create an even greater gap between the
low-level coders and the creativity-blessed programmers.
Thomas Lindgren wrote:
> Mario S. Mommer <········@yahoo.com> writes:
>
>
>>There is a pretty odd article in the online edition of the german
>>newspaper "Der Spiegel". It seems that some folks came up with a way
>>to compile UML (or something like that) to .net, java, and
>>.whatnot++. The claim is that with this, the businessmen set up the
>>logic, and p00f, out comes the program. No need for developers.
>>
>>The whole thing is called the "olivanova model execution". Using
>>google, I have not found any resonable info that is beyond hype. Does
>>anyone know more about this? Is such a thing feasable?
>
>
> We could perhaps say the wheel has turned. For what it's worth, my
> consultant friends tell me the OMG is standardizing something along
> those lines: Model-Driven Architecture (MDA). There is also executable
> UML (xUML), which probably is related to MDA.
>
> <http://www.omg.org/mda/>
>
> I guess the developers will be let back in when it's debugging time,
> as David Golden alluded. And when there are performance problems, of
> course. Will it work? Who knows.
In the gazillion times it's been tried before, the ultimate sticking
points have been performance and the quality of the initial
spec/model/whatever. Reasoning Systems and Higher Order Software come to
mind, as do all of the "Fourth-generation languages". Moore's law may
have made performance somewhat less of an issue (your PDA probably has
more hardware power than the first couple generations of lisp machines)
but getting the model right (in a semantic rather than syntactic sense
is very difficult, and making the model executable really helps on the
development side only if you have an accurate executable model of your
employees and the world at large to run your software against.
That the hype only claims an improvement of 12-47x, and on relatively
small software projects (where the getting-the-spec-right part will be
nominal) is a strong sign of the limits here.
(And of course it would be nice if coders didn't have to do modest
variations of the same old things time without end; maybe then people
could start writing more real software)
paul
Mario S. Mommer wrote:
>
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
It's kinda feasible if you ask me, at least certainly transforming diagrams
to executable code is feasible (it's been done, years ago).
The main problem would be that businessmen, in my experience, are crap
"programmers" if left to their own devices, even if they're drawing
diagrammatic, declarative, business process and rule descriptions. I don't
mean just crap programmers in the way a five-year-old child is a "blank
slate" (I believe nearly all children can be competent programmers if
taught early enough), I mean crap programmers as in actively bad, out to
complexify and obfuscate, including from other members of the programming
team ^W^W SME* committee if multiple people are involved.
[*Subject Matter Expert. Hear that, and RUN!]
I was briefly an "IT Consultant" who "helped" them draw such diagrams,
though not for later automatic machine translation. i.e. I listened to what
they said, ignored it, except (maybe) for inputs and outputs, and drew
something different that actually made sense, while carefully making them
think they thought of it. This paid better than previous programming jobs,
BTW, but was pretty much brain-rotting and slimy hell.
So they're still going to have to employ "programmers". But - they'll call
them "Junior IT Consultants" and pay them more. But consultancy services
show up on a different part of the balance sheet to in-house technical
staff, and so they'll have "saved money" in the tech dept.
If you're a consultancy firm, the trick would be: use the promise of easy
diagrammatic programming to "hook" businessmen, and offer "initial training
and consultancy services" for the "implementation phase", which stretches
on and on... Then, you've got a business (a) dependent like a crack
addict on your consultancy services, because they've fired half their
developers, and their technically best and brightest have resigned in
disgust anyway, and (b) dependent on your proprietary
language-of-the-damned. And because it's diagrammatic, the businessmen
won't admit they don't comprehend it, because that would make them
"stupid".
Changing the syntax of a programming language to be diagrams might help some
people, especially for the initial simple stuff. And a general language
with the facility, but not the necessity for diagrammatic programming might
be nice (CLIM??? Squeak???). But it just won't make people magically good
at programming. Spaghetti code is still spaghetti code even if it's got
little stick men and arrows and lozenge-shaped boxes...
I would also expect, based on experience, that to get anything real done,
such a diagrammatic language would have an "advanced" feature of some
half-assed textual programming language (here "half-assed" includes Java
and VB...*) tacked on for when people want to do real stuff but aren't
allowed officially escape the diagrammatic language straightjacket because
businessmen have mandated its use because "they can understand it" (no,
they can't, all they're good at is schmoozing...).
* See also "SeeBeyond" which had Scheme as its not-quite-so-half-assed
textual language and was probably the best of the bunch, though I think
they were moving to Java for full marketing-compliance.
[RANT COMPLETE. VENTING SUCCESSFUL.]
David Golden <············@oceanfree.net> writes:
> Mario S. Mommer wrote:
>
>>
>> There is a pretty odd article in the online edition of the german
>> newspaper "Der Spiegel". It seems that some folks came up with a way
>> to compile UML (or something like that) to .net, java, and
>> .whatnot++.
>>
>> Is such a thing feasable?
>
> It's kinda feasible if you ask me, at least certainly transforming diagrams
> to executable code is feasible (it's been done, years ago).
>
> The main problem would be that businessmen, in my experience, are crap
> "programmers" if left to their own devices, even if they're drawing
> diagrammatic, declarative, business process and rule descriptions.
Programs are formal descriptions of processes, and people have been
describing processes since pre-historic times. Describing a process
to a human is less formal and can take advantage of the extraordinary
symbolic processing power of our wetware. Over the past several
thousand years humans have experimented with all sorts of ways of
describing processes, and except for a handful of cases the best way
has always been simple linear text. This has been shown over and over
and over again. Sure, there are a lot of cases where pictures and
icons and diagrams convey the information more concisely or clearer,
but when you need to describe something complex you turn to prose.
On Mon, 07 Jun 2004 11:50:21 -0400, Joe Marshall <···@ccs.neu.edu>
wrote:
>David Golden <············@oceanfree.net> writes:
>
>> Mario S. Mommer wrote:
>>
>>>
>>> There is a pretty odd article in the online edition of the german
>>> newspaper "Der Spiegel". It seems that some folks came up with a way
>>> to compile UML (or something like that) to .net, java, and
>>> .whatnot++.
>>>
>>> Is such a thing feasable?
>>
>> It's kinda feasible if you ask me, at least certainly transforming diagrams
>> to executable code is feasible (it's been done, years ago).
>>
>> The main problem would be that businessmen, in my experience, are crap
>> "programmers" if left to their own devices, even if they're drawing
>> diagrammatic, declarative, business process and rule descriptions.
>
>Programs are formal descriptions of processes, and people have been
>describing processes since pre-historic times. Describing a process
>to a human is less formal and can take advantage of the extraordinary
>symbolic processing power of our wetware. Over the past several
>thousand years humans have experimented with all sorts of ways of
>describing processes, and except for a handful of cases the best way
>has always been simple linear text. This has been shown over and over
>and over again. Sure, there are a lot of cases where pictures and
>icons and diagrams convey the information more concisely or clearer,
>but when you need to describe something complex you turn to prose.
These types of generators work reasonably well for non technical
people to create business forms, database views and other simple
programs that are basically linear, rule driven and can be described
in simple terms.
I remain unconvinced that application generators have sufficent power
to handle complex problems and that lay people have the ability to
logically specify the solution well enough for it to be automatically
coded. If it were easy to extract problem domain information from non
techical people, business applications would be written in Prolog (or
your favorite constraint logic language).
George
--
Send real email to GNEUNER2 at COMCAST o NET
Joe Marshall wrote:
> Programs are formal descriptions of processes, and people have been
> describing processes since pre-historic times. Describing a process
> to a human is less formal and can take advantage of the extraordinary
> symbolic processing power of our wetware. Over the past several
> thousand years humans have experimented with all sorts of ways of
> describing processes, and except for a handful of cases the best way
> has always been simple linear text. This has been shown over and over
> and over again. Sure, there are a lot of cases where pictures and
> icons and diagrams convey the information more concisely or clearer,
> but when you need to describe something complex you turn to prose.
I think that I agree in the main, but that limits the set of
"constants" you can directly mention in your program to
numbers, strings, characters, and other things that have a
written representation.
I would have no problem with code that needed an icon or graphic
having it inline in the program text, just like any written
representation, provided that the tools and editors understood
it as part of program syntax. I'd probably stop short of using
any kind of graphics for control structure or notation to
denote information flow though; and these are the "typical"
usages to which so-called graphical languages put them.
Graphical languages always remind me of people who write neat
rows and columns of things in spreadsheets, without making a
clear delineation of what ideas are separate from which others
and in what ways, let alone a formal map of how their layout
is organized; they think that because the spreadsheet makes
their unorganized thoughts appear in neat rows and columns,
that grants them the power of organized thinking. It doesn't.
Similarly, graphical languages do not reduce the complexity
or organization of thought required to program; they only
show it in a way that makes it less obvious.
Bear
Ray Dillinger <····@sonic.net> writes:
> Joe Marshall wrote:
>
>> Programs are formal descriptions of processes, and people have been
>> describing processes since pre-historic times. Describing a process
>> to a human is less formal and can take advantage of the extraordinary
>> symbolic processing power of our wetware. Over the past several
>> thousand years humans have experimented with all sorts of ways of
>> describing processes, and except for a handful of cases the best way
>> has always been simple linear text. This has been shown over and over
>> and over again. Sure, there are a lot of cases where pictures and
>> icons and diagrams convey the information more concisely or clearer,
>> but when you need to describe something complex you turn to prose.
>
> I think that I agree in the main, but that limits the set of
> "constants" you can directly mention in your program to
> numbers, strings, characters, and other things that have a
> written representation.
>
> I would have no problem with code that needed an icon or graphic
> having it inline in the program text, just like any written
> representation, provided that the tools and editors understood
> it as part of program syntax. I'd probably stop short of using
> any kind of graphics for control structure or notation to
> denote information flow though; and these are the "typical"
> usages to which so-called graphical languages put them.
Sure. It seems more than reasonable to be able to include or refer to
pictures, but as an adjunct to the text, not a replacement. Even
Edward Tufte uses prose to discuss his graphics.
--
~jrm
Ray Dillinger <····@sonic.net> wrote:
+---------------
| Similarly, graphical languages do not reduce the complexity
| or organization of thought required to program; they only
| show it in a way that makes it less obvious.
+---------------
Heh-heh! Also see the fine rant by Edward Tufte[1] against PowerPoint:
<URL:http://www.wired.com/wired/archive/11.09/ppt2.html>
"PowerPoint Is Evil"
Power Corrupts. PowerPoint Corrupts Absolutely.
See also:
<URL:http://www.edwardtufte.com/tufte/powerpoint>
<URL:http://catless.ncl.ac.uk/Risks/23.07.html#subj2>
<URL:http://www.ronscheer.com/html/readingroom25.html>
<URL:http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?
usca_p=t&msg_id=0000Rs&topic_id=1&topic=Ask%20E%2eT%2e>
<URL:http://en.wikipedia.org/wiki/PowerPoint> ["Cultural Effects" section]
-Rob
[1] Author of the classic text "The Visual Display of Quantitative
Information".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
David Golden wrote:
> It's kinda feasible if you ask me, at least certainly transforming diagrams
> to executable code is feasible (it's been done, years ago).
More recently, much of the code for the Trent 7xx engine control (used
on Airbus 3xx), and a lot of the flight control systems on Joint Strike
Fighter and other aircraft has been autocoded. The difference is that
those systems were generated from a custom hard real time notation and a
state machine + Matlab model respectively, rather than UML, and the
models were created by domain expert engineers, with software
specialists backing them up.
But if you fly regularly, you're already trusting code generation systems.
> [*Subject Matter Expert. Hear that, and RUN!]
I guess you'll be taking the train from now on.
Pete
Pete Kirkham wrote:
> created by domain expert engineers, with software
> specialists backing them up.
> I guess you'll be taking the train from now on.
>
I doubt it. I'm an engineer, at least by original degree qualification.
Engineers tend to be reasonable if pedestrain programmers (and I include
myself in that description).
I have real-world experience of engineers and scientists using partially
diagrammatic programming languages (IDL, OpenDX). They tend not to suck
in quite the same way, as engineers tend to understand the limitations of
their tools (a goodly part of my course was devoted to developing such
understanding, anyway). I would guess a good programmer is still a good
programmer in a diagrammatic language.
My point was about using diagramming for business stuff under the assumption
the exalted CxOs and Masters of Bugger All can then fire all their tech
staff because "its diagrams, its easy".
The situation would be more like Airbus business majors deciding they didn't
need the engineers because they could draw a stick-figure aeroplane on
their Microsoft Tablet PC (tm) and some magic panacea software would make
the next A320. It doesn't quite work like that (maybe it will one day, but
probably not until AI is officially "solved".).
Now imagine some limited aeroplane-drawing software existed and was pushed
by consultancy companies. Businessmen could scrawl their crappy aeroplane
designs, then have consultants come in to "just, you know, clean them up a
little" (i.e. redo them from scratch). If those consultants then charged
exorbitantly more than hiring a team of actual in-house engineers to design
the aeroplane from scratch, the consultants could make a tidy profit, and
businessmen could be kidding themselves that they saved money by reducing
their engineering department, while pouring vast lakes of funds into the
consultancy blackhole.
Mario S. Mommer wrote:
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
There is flash animated demo at http://www.care-t.de/ that will calm you
down. ;)
Click on "Software Demonstration", and then on "Clicken Sie hier".
Pascal
--
ECOOP 2004 Workshops - Oslo, Norway
*1st European Lisp and Scheme Workshop, June 13*
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
*2nd Post-Java Workshop, June 14*
http://prog.vub.ac.be/~wdmeuter/PostJava04/
Pascal Costanza wrote:
> Mario S. Mommer wrote:
>
>> There is a pretty odd article in the online edition of the german
>> newspaper "Der Spiegel". It seems that some folks came up with a way
>> to compile UML (or something like that) to .net, java, and
>> .whatnot++. The claim is that with this, the businessmen set up the
>> logic, and p00f, out comes the program. No need for developers.
>>
>> The whole thing is called the "olivanova model execution". Using
>> google, I have not found any resonable info that is beyond hype. Does
>> anyone know more about this? Is such a thing feasable?
>
> There is flash animated demo at http://www.care-t.de/ that will calm you
> down. ;)
>
> Click on "Software Demonstration", and then on "Clicken Sie hier".
>
Well, I've seen it. Very... pointless.
Maybe it's a failure of imagination, but I don't understand what it does.
It looks like a DB interface builder with the ability to put a few simple
rules on top.
Svein Ove Aas <··············@brage.info> writes:
> Well, I've seen it. Very... pointless.
>
> Maybe it's a failure of imagination, but I don't understand what it does.
> It looks like a DB interface builder with the ability to put a few simple
> rules on top.
nothing new under the sun, it seems.
anyone remember a flopped Borland product from 15 (or so) years ago,
the name of which I just can't recall? it did not work from UML, but
the overall principle was very similar: generating code from
diagrams, "look ma, no coding!", etc.
--
It's tough being a bug: You screech in a tree all night, trying to get
laid, and then freeze to death. It's kind of how teenagers look at
life.
-- Fred Reed (<URL:http://www.fredoneverything.net>)
* Michael Livshin <······@cmm.kakpryg.net>:
> anyone remember a flopped Borland product from 15 (or so) years ago, the
> name of which I just can't recall? it did not work from UML, but the
> overall principle was very similar: generating code from diagrams, "look
> ma, no coding!", etc.
The name "Object Builder" springs to mind; I do remember having a play with
it at the time. Annoyingly Google doesn't seem to turn up anything
significant. It did actually require some coding.
I'm also reminded of TLO <URL:http://www.presshere.com/html/pw8102.htm>.
--
Dave Pearson
http://www.davep.org/lisp/
"Michael Livshin" <······@cmm.kakpryg.net> wrote in message
···················@boss.verisity.com.cmm...
> anyone remember a flopped Borland product from 15 (or so) years ago,
> the name of which I just can't recall? it did not work from UML, but
> the overall principle was very similar: generating code from
> diagrams, "look ma, no coding!", etc.
There seems to be this recurrent wave against "coding".
Somehow, XML specifications is not "code". Boxes with lines etched together
on a napkin in GML (http://c2.com/cgi/wiki?GalacticModelingLanguage) is not
code.
Earth to Users: It's All Code.
That label on the back of that 25 cent frozen burrito? The text that reads:
"Frozen Burrito: 1 1/2 to 2 minutes in microwave on High. Thawed Burrito: 1
minute on High"? That's Code.
"Oh, but that's easy. I understand that."
Really? Ever been successful with it?
"Sure, all the time."
Ever throw the burrito in and have it come back as liquid lava on the
outside and cold in the center?
"Oh, I have a turntable in my microwave to prevent that"
Oh? Doesn't say it needs one in the instructions. Just says a microwave.
"Well, then cook it longer."
I put it in for 10 minutes and I got an exploded, seared mess.
"No, that's too much."
Ok, 3 seconds then.
"No, that's too short."
How much longer?
"Until it's done!"
When is it done?
"When it's HOT!!"
How hot?
"Hot to the touch."
Now it burns my mouth.
"So let it cool."
But I just heated it up.
"AAIIEE!! Just read the instructions!"
I did, that's what started this. Apparently, they're wrong.
So, it boils down to (with a sufficiently sugary macro):
(while (not (perfect burrito))
(cook burrito))
So, why is that so hard to write? I mean, that took 2 seconds to code. How
does a GUI make that ANY simpler?
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> So, it boils down to (with a sufficiently sugary macro):
>
> (while (not (perfect burrito))
> (cook burrito))
>
(while (improving-p burrito) (cook burrito))
This handles the case of substandard, but edible burritos.
(while (< (desire-to-eat-now burrito)
(desire-to-eat-after-more-cooking burrito))
(cook burrito))
This one will keep you from starving.
Joe Marshall <···@ccs.neu.edu> wrote:
+---------------
| "Will Hartung" <·····@msoft.com> writes:
| > So, it boils down to (with a sufficiently sugary macro):
| > (while (not (perfect burrito))
| > (cook burrito))
...
| (while (< (desire-to-eat-now burrito)
| (desire-to-eat-after-more-cooking burrito))
| (cook burrito))
+---------------
You guys forgot to protect against a single shot of COOK being
too much (or too little). Try this (which was what I used back
when I ate burritos, before being stricken by low-carb-ness):
(let ((cook-time 60))
(while (< (desire-to-eat-now burrito)
(desire-to-eat-after-more-cooking burrito))
(cook burrito :power :high :seconds cook-time)
(setf cook-time 15)))
Or on a puny microwave, perhaps even this: ;-} ;-}
(loop for cook-time in '(60 30 15 . #1=(10 . #1#))
while (< (desire-to-eat-now burrito)
(desire-to-eat-after-more-cooking burrito))
do (cook burrito :power :high :seconds cook-time))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Christian Hofer
Subject: Re: Programming machine
Date:
Message-ID: <ca1ubn$4f7$1@online.de>
Pascal Costanza wrote:
> There is flash animated demo at http://www.care-t.de/ that will calm you
> down. ;)
>
> Click on "Software Demonstration", and then on "Clicken Sie hier".
Is this Microsoft Access going .NET (adding OO, like VB.NET)?
Oh no, they are using EJB for a simple DB application... What an
overkill! Are managers really considered to be that stupid?
Chris
Mario S. Mommer <········@yahoo.com> wrote in message news:<··············@germany.igpm.rwth-aachen.de>...
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
I looked through an Olivanova whitepaper, and can now write
marketingspeak until it wears off in a few minutes:
SLIPWorks features code-is-picture equivalence. Instead of complex
iteration and data transformation, one simply draws maps and attaches
filters. For legacy system compatibility, labels can be used for
defining functions.
Supports XML, CDADR, and the OMFG Group's recommended extensions, plus
is used by thousands of companies in the worldwide distributed
····@Home project.
Just like MSWord it has macros, so secretaries can automate many
common tasks to offload menial burdens from domain architects.
Performing complicated "static nonlocal exits" is now simply a matter
of returning some blocks to their right place, an interface learned
during childhood.
Saving the best for last, SLIPWorks has replaced the aging and
discredited OO paradigm with Flavors, a proprietary opensource
technology. (Patent pending.)
Mario S. Mommer wrote:
> There is a pretty odd article in the online edition of the german
> newspaper "Der Spiegel". It seems that some folks came up with a way
> to compile UML (or something like that) to .net, java, and
> .whatnot++. The claim is that with this, the businessmen set up the
> logic, and p00f, out comes the program. No need for developers.
>
> The whole thing is called the "olivanova model execution". Using
> google, I have not found any resonable info that is beyond hype. Does
> anyone know more about this? Is such a thing feasable?
This is a recorded message:
No matter how many executives are jumping up and down about
the idea, programmers can NOT be made obsolete by user-friendly software
like SOME accountants have been made obsolete by EXCEL. The
observation that the steam engine has made obsolete the galley slave
is correct; the reasoning that a cleverly built steam engine can make
programmers obsolete is deeply flawed.
Programming is NOT a fancy form of typing but a fancy form
of thinking. I sense that in this age of visual literacy, emotional
literacy, hedonistic literacy and power-point-literacy, PROGRAMMING
looks a little pathetic for the money if you are the type
with bold ambition and aggressive dedication to the bottom-line.
I agree that from two or three steps away a programmer working on
a subroutine looks just like a lowly secretary copying a letter. What
does not meet the eye is the fact that programming, especially GOOD
programming, takes a surprising amount of sophistication, talent,
skill and years of practice. A computer program is something like
a factory, a bureaucracy, or an organism with millions of interacting
parts. Every detail must be taken care of. The programmer builds
such an organism by DESCRIBING it, by creating COMPONENTS and
INSTRUCTING them how to behave in certain situations and in cooperation
with other components. So why not just draw a factory and have a
computer build it automatically, you ask?
Well, contrary to popular belief in marketing circles, IMAGES are NOT
the best way to describe things in detail and in a precise way. Showing
IMAGES is a very good way of selling things to people or cheat oneself
around lack of substance in power-point-presentations. But if IMAGES
were a good way of expressing complex ideas, structures or
interdependencies, philosophers would draw comics. Instead they write
books, some of them in very elaborate
language. Some philosophers and thinkers even have to invent a new
vocabulary because the conventional one was not expressive or precise
enough for their complex ideas. [Important note: Making up new terms
like "collaborative content channeling" does NOT make you a
philosopher or a thinker. Communicating complex novel ideas makes
you a philosopher or a thinker. Peppering your power-point-presentation
with meaningsless junk next to your bullets makes you a VISIONARY or
STRATEGIST.]
Trying to instruct a computer with diagrams about structures and
imaginary machines that do something useful is like the idea of
communicating the concept of "supply-side macroeconomics" to an
immigrant with only rudimentary command of English. It is even a pain in
the neck to communicate to such an individual that it is supposed
to carry the red sack with lime down into the basement and drop half of
the lime into the green bucket with the fresh water. "Uga... you...
grab... sack... THIS sack [Pointing, clicking]... carry sack...
upstairs [gesturing]... then... bucket... you know what a bucket
is? BUCKET!!! Sigh... I'll show you, grab sack, let's go... [Walking,
pointing, gesturing]."
Fortunately most programming languages are much more expressive than
that. Pointing and clicking, however, are a pretty pathetic form of
communication. And so is drawing diagrams with bubbles and arrows.
Pointing, clicking and drawing might be good enough for ideas and
concepts that concenrn the power-point-literate elite, but computers
require a little more articulation than that. The day programmers are
obsolete is the day when EVERYBODY will be obsolete.
Even if there was a tool that could transform a graphic representation
of a computer program into a WORKING computer program it would do little
good to the bottom line. The fact that most people can not work as
programmers is NOT owed to the fact that most people are not proficient
in a programming language. Most of the 1 billion people who speak
English as their mother tongue can not work as poets, copywriters,
authors or journalists. Clearly, proficiency in a language is not the
only requirement for being a productive user of the language.
Being gullible for quackery like this sort of "just point and click" is
dangerous in that you are outing yourself as a complete sucker. To
anyone who actually has the competence needed for your job even
DISCUSSING automatizing programming by drawing arrows and bubbles is as
embarrassing as discussing the feasibility of penis enlargement pills.
Exercise for the reader: Next time you see an ad about "no
need for developers" think if you would take an ad about
"no need for executives" at face value. ["You just enumerate the
issues as you see them on your power-point slides. You enter
the numbers. Just press the button and get a decision within
split seconds! No MBAs required!"]
gantar <······@evolver.at> writes:
> This is a recorded message:
> Programming is NOT a fancy form of typing but a fancy form of
> thinking.
[diatribe snipped]
This is why I am unconcerned about outsourcing to other countries.
(For *my* job, that is. There are other reasons to dislike
outsourcing.)
> Exercise for the reader: Next time you see an ad about "no
> need for developers" think if you would take an ad about
> "no need for executives" at face value. ["You just enumerate the
> issues as you see them on your power-point slides. You enter
> the numbers. Just press the button and get a decision within
> split seconds! No MBAs required!"]
Now we're talking! Where can I sign up for this!
--
~jrm
* Joe Marshall wrote:
> (For *my* job, that is. There are other reasons to dislike
> outsourcing.)
For instance that it helps poor countries get less poor?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Joe Marshall wrote:
>
>> (For *my* job, that is. There are other reasons to dislike
>> outsourcing.)
>
> For instance that it helps poor countries get less poor?
Well, we can't have *that*.