[Embedlets-developer] Re: Visual Age....

[Andrzej J. T. <an...@ch...>]

James said:

> So what do you want.. a medal ;-) 

OK...that would be nice, but pots full of money would be even better. ;-)

> We don't all have 30 years of experience
> that dates back to beginning of computing eternia. Visual Development
> environments are popular for a reason, let me see.. what this is the most
> used dev environment on the planet.. Hmmm Visual Basic.

And how many Enterprise level systems are written using it?  Very few and yet 
again, too many! ;-)

Very few VD's (interesting acronym....apropos I would say. <grins>) end up as 
the oft-talked about 10x productivity types (of which I have worked and 
inspired many, and am considered one as well)...at least not till they leave the 
VD tools behind.

Then again, why listen to me?  I only have aeons of experience and the results 
to back up my thinking. I stopped using Basic (and it's derivatives, visual or 
otherwise) about 25 years ago. <grins>

> BTW - its' an Australian thing to 'pay people out' so don't take offence.

No offense taken....my reply was partly tongue in cheek so a response in kind 
was expected.  Just my opinion is all.....and those are like sphincters, right?  
Everyone has one... 

> I am just saying don't write off Visual Development just because YOU* can
> do it better another way. It doesn't mean others who don't have your
> background can do it better another YOUR* way. When starting from scratch
> (experience wise) the Visual Developer gets results faster and I think
> this is what we are talking about here.

But the quality of the code VD's produce is not very good, primarily due to lack 
of understanding of the underlying archetypes and models that are hidden by 
the visual metaphor.  Beginners would be better off by using an editor and 
debugger along with a mentor and some design patterns (VB programmers 
have heard of design patterns, haven't they ;-)  )....they may take a bit longer 
to get up to speed that way, but then they will be more productive in the longer 
term, and produce much better quality code too. Joel Spolsky has a great 
article on this syndrome:

http://www.joelonsoftware.com/articles/LeakyAbstractions.html

IDE's, especially visual ones promote the leaky abstraction problem.  They are 
also, in my estimation, a futile attempt on the part of pointy-haired managers to 
turn jrs/intermediates into experts through the use of a tool.  Unfortunately, it 
doesn't work, in part due to the reasons Joel mentions.

Hotshot programmers typically find that IDE's get in the way and VD tools slow 
them down.  One might infer that if you want to be a hotshot developer, then 
maybe throwing away the IDE/VD tools is a good way to get there? ;-)

Anyway....I don't intend to discuss dev tools in public on this list any more...it's 
not germaine to the task at hand.  Use what tools you will, so long as you can 
check in/out of CVS, it really doesn't matter to me.

> I happen to totally agree that wiring diagrams quickly become like 'rat's
> nests' look at any PCB schematic! They really only have logic value for a
> very small number ~7 (magic number) elements wired together. After that a
> language takes over. But the thing is.. a wiring connectivity "language"
> is difficult to read actually - you have A connects to B Connects to A -
> The visual Representation makes more sense. (Does this look like UML yet?)

I agree with you there.....at a certain point the complexity of the diagram loses 
it's intuitive meaning.  Mind you, code can be no better either, but if well 
structured can be more maintainable.  The trick with diagrams is to use 
layered/encapsulated heirarchies where you can drill down into more detail as 
needed....so you only ever see 7 items at any "zoom" level....but I have yet to 
see a good VD IDE that can do this intelligently (some UML modelling tools 
are close though).

> Its becoming clear enough that embedlets themselves are java code written
> in language, and embedlet applications are XML connectivity schema with a
> visualisation viewer/editor over the top.

Exactly my vision of what they should look like! ;-)

I'm thinking about the specs/standards for how the embedlet component and 
container looks (interfaces, lifecycles, contracts, etc.) and the XML 
connectivity and configuration schema.  I'm hoping that others (Ted and you 
for instance) will build the visualization/editor on top of that framework.  

Brill then pipes up:

> Frankly, I loved it when I first tried it... and it did
> have some "cool" features, but in the end I found I had to switch back.

Sounds like most IDE experiences I have heard of......they're like chinese 
food....satisfying initially, but soon you're hungry again.  

Eclipse is not bad though.....except that it will probably get stuffed full of all 
sorts of extensions that will eventually raise the complexity/footprint/learning 
curve to the point that it may become unuseable.  Hopefully not.  Editors and 
wimmin.....everyone has different tastes. Vive la difference.

> Umm... what do you use by the way?

Primarily JPadPro as my editor, Together for UML modelling, JSwat for 
debugging and Ant for builds. Most of my teams have used EMACS as their 
editor (on the 500K project....that was just an example to show that IDE's are 
not necessary for productivity...). But have been evaluating Eclipse as well.


But, to misquote JRRT in Lord of the Embedlets:

"One Outpost Container to rule them all, One Container to find them, One
Container to bring them all and in the embedded darkness bind them"

Let's get on with the quest, shall we?


Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com