Re: GoTo in Java
"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:droi6h02jb4@xxxxxxxxxxxxxxxxxxxx
>
> In article <43vp1uF1pnsa5U1@xxxxxxxxxxxxxx>, "Pete Dashwood"
> <dashwood@xxxxxxxxxxxxxx> writes:
>>
>> The point that is being missed entirely here is that the real solution is
>> to
>> NOT maintain source code. (In any language...) ...
>>
>> Component based development means you write code once and do NOT maintain
>> it. (I know there are many places that don't adhere to this and they try
>> and
>> maintain the components. There is only marginal gain over a normal source
>> code maintaining shop if you do this.)
>
> I'm dubious of the prospects of writing bug-free nontrivial components.
So am I; that's NOT what I'm advocating... :-)
My experience over the last 5 or 6 years is that the simpler the components
are, the more reuse they get. 'Nontrivial' functionality is comprised of
smaller, decomposed, functionality. It's like building with Lego. You don't
change the bricks.
>
>> The rule of source code is over. The future belongs to object code.
>
> As component-composition systems get more powerful, they become source
> development environments; the "source" is simply composed of components
> and their connections.
Well, that's an interesting argument. Would you say that 'scripting' and
maintaining script, is the same as 'programming'? It is certainly arguable.
But I think you would agree that the script required to glue a bunch of
components into an application has nothing like the volume, verbosity or
complexity of the all the lines making up those components, irrespective of
the language(s) they're written in. I posted an example here a long time ago
(some years back) of a scripted application that required something like 60
lines to do what would have taken several thousand lines of procedural code.
There is no comparison.
>
> When I was at IBM one of the products I worked on was Data Explorer,
> IBM's scientific data visualization system. It was a package for
> examining large data sets graphically, with support for all sorts of
> 2D and 3D representations (loop-faces, isobars and isosurfaces,
> voxels, hedgehogs, etc). It could import, combine, and filter data
> from a wide array of sources; it supported various devices for
> dynamic data manipulations (flyovers and so forth); it could perform
> many data manipulations; and it could be extended by its users.
>
> It used a component programming model and provided a visual development
> and execution interface: a canvas and a component palette. The user
> dragged components onto the canvas and wired them up, producing a
> graph that was executed in data-flow fashion. Users could write new
> components in any language that could call the API, and they could
> package graphs as macros for use in other graphs.
>
> At the time that was fairly unusual for a commercial product, but
> since then the idea's been used extensively for things like JavaBeans.
>
I have seen a similar product form MicroSoft that was used for building RDB
procedures and triggers. Most impressive. Finished, working, bug free,
application in minutes from a graphic IDE without a single line of code
(script or procedural) in sight. Just drag and drop components. I believe
that is the future.
> What we saw during testing was that users would start off with simple
> graphs, then elaborate them to add new function, refactor common tasks
> into small graphs that they would package as macros, and so forth.
> They were writing source code - it was just source code where each
> "statement" was in fact a component.
Users who use graphs are likely to do that.
>
> I believe components will continue to be important in software
> development, and that component systems will continue to improve, and
> that we will indeed see components becoming ever more dominant, just
> as higher-level languages have gradually displaced assembly as a
> language of choice. (But just as assembly is still used for niche
> applications, so too will non-component development.)
>
I agree.
> However, I think the component "revolution" has been oversold. To my
> mind, it's nothing more than the continuing evolution of programming
> toward greater abstraction and interoperation. It's often very
> useful (we have customers that have made very good use of combining
> third-party components with COBOL programs, and of course we're
> selling component facilities too), but I don't believe it marks a
> radical change.
>
There we have to differ. I believe it does. It has certainly changed the way
I develop systems. Radically.
I don't agree about it being oversold; if anything, it is undersold. Just as
OO was undersold to traditional programmers.
I embraced OO because I saw it as enabling a true reusable, transportable,
encapsulated, component based solution. And I believe components are the
Keys to the Kingdom. I arrived at this opinion based almost entirely on my
own experience because none of the places I worked even implemented OO,
never mind components. Very few wanted to talk about ActiveX or COM or even
Beans and CORBA.
>From the day I first got remote procedure calls working in a DCOM+
environment that 'everyone knew' was unsafe and unstable and vulnerabe to
attack and could never work, and I had to be crazy to even think of
developing in it, I was sold.
(No-one has ever successfully hacked it. There are safeguards in place, both
hardware and software. Of course there is always a risk, but all risks have
mitigations.)
Suddenly my applications could be distributed around the network, could load
level themselves, and could reach across vast distances (this app. ran in
Australia... it's a big place) just as if they were running on a standalone
desktop. One copy of encapsulated functionality, running anywhere you want
it. I was sold then and I'm sold now.
Today I see millions of dollars being spent (I just finished costing my
project :-)) on OO Java Bean component based software that is easy to
maintain (extend it with some more Lego blocks), flexible, responsive and
ready for the future, not stuck in the rule of maintainable source code that
has governed this industry since the 1960s.
I see bright young people enthusiastically working together in Joint
Application Development workshops that bring the functionality needed right
now to our business; people who are shooting the Rapids, not going over the
Waterfall. Goal oriented, timeboxed, RAD development. The atmosphere is
energetic and excited. I have to make people go home... :-)
It is a far cry from the days of sitting at a green screen writing COBOL
with SPF. (I enjoyed that too, and I wouldn't knock it because it fed me for
many years, but I wouldn't go back to it now...)
>> Maintining source code is yesterday's technology.
>
> Component authors will still have to maintain the source to those
> components. I don't see anything obviating that need.
Again that's where we differ. If you maintain a component, you shouldn't
have written it as a component. I have components that I wrote years ago,
they are successfully deployed in live appplications and I have NEVER
TOUCHED THEM since they were written. The only time I would consider
modifying component code is while it is being tested and debugged. Once it
does what it is specified to do, its methods, properties, and events are
documented and that's what it does. Nothing more, nothing less. If you want
to modify the way a certain method works you wrap the component and either
override the method.via an interface, or write a new method in the wrapper.
Encapsulated functionality is exactly that...encapsulated.
Most people used to traditional environments have trouble with this and I
understand why they do. Again, I reached this conclusion based on my own
experience and finding what works for me.
And people
> building applications from components will discover that they need to
> maintain their component arrangements - which is just source
> maintenance in a different guise.
>
Yes, it is certainly useful to experiment with different arrangements and
that's where a GUI IDE comes in handy. This is the same argument as above;
is script actually source? I don't think so, but I would agree it is
arguable. I predicate my argument on the fact that glue is not considered to
be timber, and, so far as I know, no one has ever built a house (or anything
else) from glue. The material used to stick a construction together is not
the same as the construction itself, although it is certainly part of it.
You can hardly call it 'source maintenance' if you have machinery that
allows you to experiment with different positions and combinations of
building blocks, and then, when you are satisfied with the final
arrangement, injects the necessary glue for you at the right places...
>> But I also think people need to start thinking 'beyond the square'.
>> Todays
>> kids are doing it. In 50 years the idea of sitting down and 'programming'
>> a
>> computer line by line, will be a quaint curiosity, like us using flint
>> tools
>> or speaking Latin in the Supermarket.
>
> I'm not so sure about that, either. Many old technologies have a way
> of remaining relevant to specialized practitioners even after they've
> left the mainstream.
OK, I grant that. There are still people who make flint tools and speak
Latin. Most of them do it for fun or because their profession requires them
to investigate and understand these things. They are, as you say,
'specialized practitioners'. Could we exclude these from the argument,
having agreed this point? My statement was referring to the world at large.
> But speculating about this industry fifty years
> from now, while entertaining, isn't likely to be very convincing; we
> don't have enough history to meaningfully extrapolate for a quarter
> of that time.
12 and a half years from now? Sure...step right up and meet August, 2018...
1. Wireless internet will be the norm and will pervade our lives. Most
people will carry a device or accessory that connects them to it instantly.
'Intelligent jewellery' will be a sought after accessory; brooches,
cufflinks, spectacles that all talk to you using their internet connection
to keep you informed instantly..
2. Roads will be tolled, cars will be made of non-metallic substances, run
on hydrogen (or water) and everyone in China will want one. (they will be
allowed one small car per family, just as they are allowed one small child
per family...)
3. Gorillas will be extinct in the wild.
4. Large scale supersonic air transport will be available. London to Los
Angeles in 4 hours.
5. The 2002 COBOL standard will be implemented by a consortium comprised of
the remnants of MicroFocus, AcuCOBOL, and Bendix (all the other vendors will
have moved away from it long before. Bendix decided there was no money in
washing machines because everybody has one, and COBOL sounds like an
interesting place...wasn't Adama in Battlestar Galactica one of the Lords of
COBOL...? Anyway, might as well spend what's left of the company on
something that might be fun...
See, this pyschic stuff is easy... :-)
Pete.
.
Relevant Pages
- Re: Problem with a script
... I don't mean to offend you or discourage you from working with PHP, ... Reworking your huge script into something concise, ... that I have no understanding of loops is completely asinine. ... throw that in while I am on the subject of programming. ...
(comp.lang.php) - Re: [regexp] Speaking of the /s modifier...
... should be sanitizes before, and to be on the secure side, the ... transformation script should do that too... ... I'm relatively new to programming in general (perl is my first ...
(perl.beginners) - Re: Where does programming begin?
... If it is, then you're programming. ... But if you *are* generating your own control ... consider a script like this: ... programming, but per your explicit-decision-making criterion, none ...
(comp.programming) - Re: What is .net
... Jolly damnd good questions. ... Other solutions are more along the lines of learning VB to script things. ... In combination with a simple script and a bit of programming (which, ... You asked me what my "personal IT interests and goals" are which I can ...
(microsoft.public.dotnet.academic) - Re: What is .net
... Jolly damnd good questions. ... Other solutions are more along the lines of learning VB to script things. ... In combination with a simple script and a bit of programming (which, ... You asked me what my "personal IT interests and goals" are which I can ...
(microsoft.public.dotnet.faqs) |
|
