JBulider vs. Visual Cafe
Ahmed Matar
sun's jdk 1.2.2. Anyways I'm thinking of buying either the latest version of
the JBuilder or Visual Cafe because I heard it saves you a lot of time
programming in them vs. doing it without any programming environment. What
do you suggest I use the JBuilder or the Visual Cafe? Does it require a lot
of time to understand how to use them? Do I need a book to learn how to use
it? and if so, if you have one in mind please suggest it to me.
Thanks,
Ahmed
Ray McVay
Generally speaking a good IDE will save you LOTS of time over hacking
out code with an editor and compiler. Don't forget to look at IBM's
VisualAge for Java. VAJ Pro is the same or less expensive than the
comparable JB and VC products plus you can download a full function
version from IBM for free.
--
Ray
Andrzej
> Generally speaking a good IDE will save you LOTS of time over hacking
> out code with an editor and compiler.
All my experiences have proven this to be a false statement. Good
programmers usually write better code, faster, with a good editor and the
JDK. Even if they end up marginally slower (and I have seen 10x
productivity improvements with a good editor such as JPadPro, measured in
lines of code produced), which is rare, the code is better structured,
more maintainable and more extensible, for all but the most basic of
simple applications.
Now...if you are not a "good" developer, then your statement is probably
correct. Which leads one to believe that Dev. managers should be on the
lookout for programmers that do NOT like IDE's, as it might improve their
odds at hiring "good" ones.
--
Andrzej Jan Taramina
Chaeron Consulting Corporation
Chaeron: http://www.chaeron.com
Sightings: http://www.chaeron.com/sightings/
NOTE: Remove Spamicide (tm) before replying!!!
Thomas Koschate
and...@spamicidechaeron.com says...
> Ray McVay wrote:
>
> > Generally speaking a good IDE will save you LOTS of time over hacking
> > out code with an editor and compiler.
>
> All my experiences have proven this to be a false statement. Good
> programmers usually write better code, faster, with a good editor and the
> JDK. Even if they end up marginally slower (and I have seen 10x
> productivity improvements with a good editor such as JPadPro, measured in
> lines of code produced), which is rare, the code is better structured,
> more maintainable and more extensible, for all but the most basic of
> simple applications.
I would strongly disagree with this assertion. A good IDE makes it
easier to examine your class hierarchies, allowing you to reuse code that
is already there, and making it much easier to refactor your classes. If
you're not doing this, you're spending far too much time reinventing the
wheel, as well as denying yourself the opportunity of learning from the
existing code.
--
============================================================
Thomas Koschate
koschateDEL...@bigfoot.com
For PGP Key, see
http://keys.pgp.com:11371/pks/lookup?op=get&search=0xF45280AD
Andrzej
> I would strongly disagree with this assertion. A good IDE makes it
> easier to examine your class hierarchies, allowing you to reuse code that
> is already there, and making it much easier to refactor your classes.
So does any good Java Editor (like JPadPro for example)
Vladimir Yakubovich
Andrzej <and...@spamicidechaeron.com> wrote in message
news:38400DF6...@spamicidechaeron.com...
> All my experiences have proven this to be a false statement. Good
> programmers usually write better code, faster, with a good editor and the
> JDK. Even if they end up marginally slower (and I have seen 10x
> productivity improvements with a good editor such as JPadPro, measured in
> lines of code produced), which is rare, the code is better structured,
> more maintainable and more extensible, for all but the most basic of
> simple applications.
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do not judge, and won't be judged....
Could you, please, explain us your debugging technique with bare JDK?? Is it
10x times faster that debugging in JBuilder (or other IDE)?? Or you are so
"good" that you write the code that doesn't require debugging from the first
attempt?? :)
Vladimir Yakubovich
Andrzej
> Could you, please, explain us your debugging technique with bare JDK?? Is it
> 10x times faster that debugging in JBuilder (or other IDE)?? Or you are so
> "good" that you write the code that doesn't require debugging from the first
> attempt?? :)
I do strive for the latter ;-) ...but do not always succeed ;-( . A lot
of good editors (like JPadPro) have debugging built in. I was commenting
mainly on the bloated, slow and buggy IDE's (the term seems to usually
refer to visual tools) like JBuilder, Visual Cafe, VisualAge and such.
Jon A. Cruz
> Andrzej <and...@spamicidechaeron.com> wrote in message
> news:38400DF6...@spamicidechaeron.com...
> > All my experiences have proven this to be a false statement. Good
> > programmers usually write better code, faster, with a good editor and the
> > JDK. Even if they end up marginally slower (and I have seen 10x
> > productivity improvements with a good editor such as JPadPro, measured in
> > lines of code produced), which is rare, the code is better structured,
> > more maintainable and more extensible, for all but the most basic of
> > simple applications.
> >
> > Now...if you are not a "good" developer....
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do not judge, and won't be judged....
>
> Could you, please, explain us your debugging technique with bare JDK?? Is it
> 10x times faster that debugging in JBuilder (or other IDE)?? Or you are so
> "good" that you write the code that doesn't require debugging from the first
> attempt?? :)
>
In one sense, yes, he could be.
In catching defects, the most effective single method has been shown to be code
inspections. If he was that good, then his "debugging" technique would heavily
involve inspection, unit testing, etc. and would not require nearly as much
stepping through the debugger.
Also, if he was very good, he might have conducted a simple code review with
another person before even running the code (or at least before commiting it to
source control).
(Please note that I am not saying there is no place for using a debugger, but
just that a "good" developer wouldn't be slowed as much by not having one. This
may also go to the factor where a "good" developer is usually 10 times more
productive than the "average" one)
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Andrzej
> Also, if he was very good, he might have conducted a simple code review with
> another person before even running the code (or at least before commiting it to
> source control).
And if he was very, very good, he might have instrumented the code with
testing/tracing facilities from the very beginning to help other
developers that might need to work through the code at a later time. ;-)
> may also go to the factor where a "good" developer is usually 10 times more
> productive than the "average" one)
Well put!
Jim Sculley
>
> Vladimir Yakubovich wrote:
>
> > Could you, please, explain us your debugging technique with bare JDK?? Is it
> > 10x times faster that debugging in JBuilder (or other IDE)?? Or you are so
> > "good" that you write the code that doesn't require debugging from the first
> > attempt?? :)
>
> of good editors (like JPadPro) have debugging built in. I was commenting
> mainly on the bloated, slow and buggy IDE's (the term seems to usually
> refer to visual tools) like JBuilder, Visual Cafe, VisualAge and such.
>
>
> Andrzej Jan Taramina
> Chaeron Consulting Corporation
>
> Chaeron: http://www.chaeron.com
> Sightings: http://www.chaeron.com/sightings/
>
> NOTE: Remove Spamicide (tm) before replying!!!
You'd best leave VAJ out of that statement since you've said before
you've never used it. A bit presumptuous of you. I seriously doubt
that the JPadPro debugger is even close to the power of the VAJ
debugger. Your previous comments on the unmaintainability of IDE code
is laughable.
Jim S.
--
>======= http://www.abraxis.com/niceguy =======<
Roedy Green
quoted :
>Generally speaking a good IDE will save you LOTS of time over hacking
>out code with an editor and compiler.
Over javac yes, but Smartj with jikes with a good editor like
Slickedit, no. The only time I use IDEs now is when I want to use the
debugger.
The Java glossary is at http://mindprod.com
--
Roedy Green, Canadian Mind Products
-30-
Andrzej
> You'd best leave VAJ out of that statement since you've said before
> you've never used it.
That would be very strange...since I did use it and tossed it after a
thorough
evaluation. Mind you, it was not the current release....
Jim Sculley
Right you are. My mistake. You were quoted in a message and the author
of that message stated he hadn't used it. My bad.
Andrzej
> Right you are. My mistake. You were quoted in a message and the author
> of that message stated he hadn't used it. My bad.
No problem. My take on all such tools is that they aren't bad....and can
help jr. to
medium level programmers...but that many real hard-core experts find they
just
get in the way.
John Bridges
The editor in most IDE's is a miserable failure. But then I hold Emacs and Codewright up as examples of top quality editors.
The debugger's I've tried in the big four are all fairly hopeless. JPDA with 1.3 seems to solve this problem. But till then code inspection and instrumentation work very nicely.
I'm a little perplexed by your assertion about examining class hierarchies. This is something that seems to be sorely missing from the mainstream IDE's in any sensible form. Even if it was there, none of them have team or cross team capabilities, which is where the real code reuse benefits come in.
Bottom line is, I think Integrated Development Environments fall pretty short of the mark. We need to see Software Engineering Environments instead.
John
Thomas Koschate wrote:
In article <38400DF6...@spamicidechaeron.com>,
and...@spamicidechaeron.com says...
> Ray McVay wrote:
>
> > Generally speaking a good IDE will save you LOTS of time over hacking
> > out code with an editor and compiler.
>
> All my experiences have proven this to be a false statement. Good
> programmers usually write better code, faster, with a good editor and the
> JDK. Even if they end up marginally slower (and I have seen 10x
> productivity improvements with a good editor such as JPadPro, measured in
> lines of code produced), which is rare, the code is better structured,
> more maintainable and more extensible, for all but the most basic of
> simple applications.
I would strongly disagree with this assertion. A good IDE makes it
easier to examine your class hierarchies, allowing you to reuse code that
is already there, and making it much easier to refactor your classes. If
Andrzej
>
> You hit the nail on the head with "a good IDE", there doesn't seem to be
> such a beast for Java yet.
<snip some good comments>
> Bottom line is, I think Integrated Development Environments fall pretty
> short of the mark. We need to see Software Engineering Environments
> instead.
<IMNSHO>
Part of the problem with IDE's is the same thing that has afflicted
commercial browsers and OS's. Bloatware in the extreme. Software
companies are in a rush to deliver more features faster and elegance, true
useability, stability and all the rest get thrown out in the race for
market share and quarterly results. At a certain point, the economics
make it almost impossible for management to decide to scrap their
bloatware product and redevelop a tight, useful, powerful package based on
the mistakes and knowledge they garnered from the first versions.
This sad state of affairs is compounded greatly by the shortage of
qualified developers out there, and the extreme shortage of "superstar"
programmers. When all you have (on average) is a huge team of mediocre
developers, then the few superstars you have get lost in the din...and you
end up with mediocre products.
This situation feeds upon itself, since then tools vendors try to build
tools that "automate" as much of the software design process as possible
in a flawed attempt to improve the output of the unwashed masses of
developers (don't get yer panties in a knot over the adjectives...I'm just
having fun to make a point!) and to mitigate the developer shortage
through productivity enhancement. For the moment this strategy has
failed, since good software design and development are still more black
art than engineering. Good design/dev also comes with experience....it is
not something that you can absorb from a "OO Design in 21 days" book,
though good references and mentors can help matters immensely. Sure, the
20-somethings (or even early teens) can pump out a lot of code...and do it
25 hours/day (assuming enough Jolt Cola and Pizza)....but the quality of
that code? It is typically far from what the 10/20/+ year veterans can do
(at least the good ones...all veterans are not good...just like all
youngsters are not bad).
There is hope on the horizon, however! One of the contributors to the
problem (vast armies of inexperienced developers) also may help matters,
since many of them are jumping on the Open Source bandwagon, coming up
with new and creative ideas and spinning of small startups that deliver
tight, functional and elegant tools that do the job well. The whole push
towards component engineering also will help to combat this problem in the
long run (Visual IDE's being a very rudimentary form of CBE pertaining
only to visual widgets), but not totally, since someone (preferrably
someone good/experienced) will have to create the components that can be
bolted together. The advent of the Java core libraries (AWT, SWING) and
even the hopeless MS MFT are all examples of a push in that direction,
albeit at a very low level.
It is very interesting that the veterans, who know how to design and sling
good applications, invariably use very specific and targetted tools in
their work. A favorite editor/debugger....the JDK....and not a lot else.
They are very much like code surgeons, using very subtle, delicate and
purpose-specific tools that just get the job at hand done and do not get
in the way or do much else. The ones that rave about the beauty of the
current crop of IDE's rarely are the superstar veterans (or so the
postings here and elsewhere would have me believe).
The current crop of IDE's try to do everything for everyone (witness the
so-called "Professional" editions, that are even more bloated, add very
little in the way of true productivity, but cost more...) are bound to
fail. With so many things in life, you can't be everything to everybody.
And the most productive software professionals stay away, as a rule.
Hmmmm. Very interesting. What does that lead you to believe? IDE's will
not solve the software developer shortage either, since they cannot yet
add the experience/knowledge/aptitude that the superstars evidence. They
also tend to stifle innovation, since everything is targetted at the
lowest common denominator, UI design turns into "what will the tool let me
build automatically", etc.
Despite the tools vendors marketing claims to the contrary, there is no
panacea (at least not yet and likely not for quite a few years) for good
software design and development. Experience, knowledge, dedication and
such are what is really required, at least until we get to universal CBE.
What we need to do as an industry is better leverage the expertise of the
superstars in training the juniors to become superstars. Current IDE
technology doesn't help that...and in my not so humble opinion, may
actually hurt that process.
Thoughts from over 25 years in the trenches....and STILL going strong.
</IMNSHO>
ren...@nycap.rr.com
If someone would write a small fast gui builder that
supported swing and wrote realtively compact code
and didn't try to do everything else they would be
an industry leader.
You know what... Supercede used to come rather close.
Glub glub...
>Subject: SW Engineering Environments [was: JBulider vs. Visual Cafe]
>From: Andrzej <and...@spamicidechaeron.com>
>Date: Sun, 28 Nov 1999 19:55:53 GMT
>Reply-To: Not Set
Andrzej
>
> Here Here!!!
;-)
> If someone would write a small fast gui builder that
> supported swing and wrote realtively compact code
> and didn't try to do everything else they would be
> an industry leader.
I'm not sure that you are right in this. The marketing types in the
established IDE companies would point out how it didn't have this
so-called advanced feature...and didn't have that other facility...et
cetera ad nauseum. They would also point out how many awards they paid
for...oooops....I mean won for their tool...and how any average brain-dead
monkey can generate an application with their super duper IDE pooper
scooper (we'll ignore the fact that the app is unmaintainable or
extensible except with their own tool....proprietary tie ins are the holy
grail of marketing departments). Or they would just buy out the decent
tool and it would never see the light of day again (I believe this is
called the "Gates Manoever"..<grins>).
But your idea does have merit, all humour aside! Hell...if I could find a
UI code generator like the one that you describe, that only does just
that...no code editor...no debugger...no business logic generation....but
it produced clean, understandable, documented code that could then be
plugged into your editor for fleshing out...that would be useful.
D'Arcy Smith
> ren...@nycap.rr.com wrote:
> > Here Here!!!
> > If someone would write a small fast gui builder that
> > supported swing and wrote realtively compact code
> > and didn't try to do everything else they would be
> > an industry leader.
> I'm not sure that you are right in this. The marketing types in the
> established IDE companies would point out how it didn't have this
> so-called advanced feature...and didn't have that other facility...et
> cetera ad nauseum.
Easy to take care of - make the ENTIRE IDE pluggable/scriptable.
This way all the modules could be provided but only the ones required
by the user would be loaded (or even taking up space on the hard drive).
Forte (NetBeans) is about 1/2 way there. It is not at the level where
you can say "don't include this part of feature 'X'".
> They would also point out how many awards they paid
> for...oooops....I mean won for their tool...
Awards are not paid for. I'll go with awards are a silly measure for
purchasing anything though. The companies get to show the reviewers
what the companies want to be seen. If the reviewrs controlled the
process - with no guidance from the vendor - things would probably be
different.
..darcy
Laurence V
>> for...oooops....I mean won for their tool...
>
>Awards are not paid for. I'll go with awards are a silly measure for
>purchasing anything though. The companies get to show the reviewers
>what the companies want to be seen. If the reviewrs controlled the
>process - with no guidance from the vendor - things would probably be
>different.
>
>..darcy
Awards are not paid for? Are they not, now? Explain to me then how the
crooks at Java Developer's Journal asked me to write a review of a
product, then "declined" to publish it WHEN THE COMPANY WHO MADE THE
PRODUCT WASN'T INTERESTED IN ADVERTISING in their corrupt "magazine".
JDJ robbed me of my article fee.
Don't believe me? You don't have to.
I know of *two* other authors who have been stung by Java Developer's
Journal in a similar way.
If these mafia types do business according to those rules of
engagements, I wouldn't be surprised for one femtosecond that they
select winning products according to who pays them the highest
bribe/advertising fee.
D'Arcy Smith
news:3841c174...@news.clara.net...
> >> They would also point out how many awards they paid
> >> for...oooops....I mean won for their tool...
> >Awards are not paid for. I'll go with awards are a silly measure for
> >purchasing anything though. The companies get to show the reviewers
> >what the companies want to be seen. If the reviewrs controlled the
> >process - with no guidance from the vendor - things would probably be
> >different.
> Awards are not paid for? Are they not, now? Explain to me then how the
> crooks at Java Developer's Journal asked me to write a review of a
> product, then "declined" to publish it WHEN THE COMPANY WHO MADE THE
> PRODUCT WASN'T INTERESTED IN ADVERTISING in their corrupt "magazine".
> JDJ robbed me of my article fee.
That is a problem with the JDJ. That doesn't mean that the vendor
had any say in the matter.
> Don't believe me? You don't have to.
> I know of *two* other authors who have been stung by Java Developer's
> Journal in a similar way.
Then I wouldn't suggest you write anything for JDJ.
> If these mafia types do business according to those rules of
> engagements, I wouldn't be surprised for one femtosecond that they
> select winning products according to who pays them the highest
> bribe/advertising fee.
That is NOT the same thing as vendors controlling the process.
If the magazine (and it isn't just magazines giving out awards) is
corrupt then don't blame the vendor.
Please don't forget the fact that I used to work for a vendor... so I
have seen that side of it as well.
..darcy
Andrzej
>
> Easy to take care of - make the ENTIRE IDE pluggable/scriptable.
> This way all the modules could be provided but only the ones required
> by the user would be loaded (or even taking up space on the hard drive).
Not a bad idea...IF the plugin API is publicly documented so that you can
"collect" the best of breed functionality that you might need.
> Awards are not paid for.
I was being facetious..... ;-)
Andrzej
> Please don't forget the fact that I used to work for a vendor... so I
> have seen that side of it as well.
When did you leave Symantec...and what are you up to now D'Arcy?
Just curious....private email response is fine if you don't want to
publicize it.
Ray McVay
>
> Ray McVay wrote:
>
> > Generally speaking a good IDE will save you LOTS of time over hacking
> > out code with an editor and compiler.
>
> All my experiences have proven this to be a false statement. Good
> programmers usually write better code, faster, with a good editor and the
> JDK. Even if they end up marginally slower (and I have seen 10x
It may depend on your definition of "good editor" which is probably
what I often call "a programmer's editor". The latter is quite often
the equivalent of the average IDE, especially if it comes "out of the
box" knowing about your development target. I doubt you'll find very
many programmers using the JDK with vi or notepad that can approach
the development efficiency of someone using one of the Java specific
IDEs.
--
Ray
Andrzej
> It may depend on your definition of "good editor" which is probably
> what I often call "a programmer's editor". The latter is quite often
> the equivalent of the average IDE, especially if it comes "out of the
> box" knowing about your development target. I doubt you'll find very
> many programmers using the JDK with vi or notepad that can approach
> the development efficiency of someone using one of the Java specific
> IDEs.
A good point of clarification, Ray, with which I agree. My reference
(which should have been more clear) was to IDE's that were of the visual
nature....used to drag and drop UI components, which are not near as
useful as a heads-down "programmer's editor" as you call it. I would not
recommend Notepad or vi (which is an anachronism).
Ray McVay
>
> On Sat, 27 Nov 1999 04:43:34 GMT, Ray McVay <rmc...@acm.org> wrote or
> quoted :
>
> >out code with an editor and compiler.
>
> Slickedit, no. The only time I use IDEs now is when I want to use the
> debugger.
What you describe is what I'd call a hand hacked IDE (as opposed to
an off the shelf IDE). "An editor and compiler" is Notepad or vi and
javac. Yes I know sharp programmers that think Notepad+Perl is a
RAD CGI toolkit but they are not good at participating in programming
teams and they create code that noone but them can maintain.
--
Ray
Johan Compagner
> crooks at Java Developer's Journal asked me to write a review of a
> product, then "declined" to publish it WHEN THE COMPANY WHO MADE THE
> PRODUCT WASN'T INTERESTED IN ADVERTISING in their corrupt "magazine".
> JDJ robbed me of my article fee.
how corrupt?
Details?
Review of what product if i may ask?
I find JDJ pro JBuilder but for the rest it's a nice source for java news.
Doug
Andrzej <and...@spamicidechaeron.com> wrote:
>"Jon A. Cruz" wrote:
>
>> Also, if he was very good, he might have conducted a simple code review with
>> another person before even running the code (or at least before commiting it to
>> source control).
>
>And if he was very, very good, he might have instrumented the code with
>testing/tracing facilities from the very beginning to help other
>developers that might need to work through the code at a later time. ;-)
>
>> may also go to the factor where a "good" developer is usually 10 times more
>> productive than the "average" one)
Note that these issues are orthogonal to using an IDE. No where have I
ever seen that a good developer is LESS productive using an IDE. Having
said that, it's important we remember that writing code is ~15% of the
time/effort spent developing software.
doug
Doug
Andrzej <and...@spamicidechaeron.com> wrote:
>John Bridges wrote:
>>
>> You hit the nail on the head with "a good IDE", there doesn't seem to be
>> such a beast for Java yet.
>
><snip some good comments>
>
>> Bottom line is, I think Integrated Development Environments fall pretty
>> short of the mark. We need to see Software Engineering Environments
>> instead.
>
><IMNSHO>
>
>Part of the problem with IDE's is the same thing that has afflicted
>commercial browsers and OS's. Bloatware in the extreme. Software
>companies are in a rush to deliver more features faster and elegance, true
>useability, stability and all the rest get thrown out in the race for
>market share and quarterly results.
And who is to blame? Who do you think demands all the bells and
whistles? We do. Although I don't do scientific programming, there is a
vocal group who is demanding Java support their agenda. It's neither
good nor bad, but for an IDE to gather the largest market share, they
too must support features that perhaps only 10% of the market demands.
Most vendors dislike the "check the boxes" reviews that PC mags render,
but that's life.
> At a certain point, the economics
>make it almost impossible for management to decide to scrap their
>bloatware product and redevelop a tight, useful, powerful package based on
>the mistakes and knowledge they garnered from the first versions.
Vendors have tried the 80% solution, but have been battered by everyone
who didn't get their feature request. It's easy to bemoan bloatware, but
until they market rewards small, tight products, the vendors will
continue on their current path, relying on increases in hardware
performance and decreases in hardware costs to ameliorate the increasing
size of the software. Perhaps the solution is user-configurable
software. Even that is not a pancea, as the mushrooming test
requirements may doom such an effort.
>This sad state of affairs is compounded greatly by the shortage of
>qualified developers out there, and the extreme shortage of "superstar"
>programmers. When all you have (on average) is a huge team of mediocre
>developers, then the few superstars you have get lost in the din...and you
>end up with mediocre products.
By definition, most of us are average, aka mediocre. That's true no
matter how many developers you have.
>This situation feeds upon itself, since then tools vendors try to build
>tools that "automate" as much of the software design process as possible
>in a flawed attempt to improve the output of the unwashed masses of
>developers (don't get yer panties in a knot over the adjectives...I'm just
>having fun to make a point!) and to mitigate the developer shortage
>through productivity enhancement. For the moment this strategy has
>failed, since good software design and development are still more black
>art than engineering. Good design/dev also comes with experience....it is
>not something that you can absorb from a "OO Design in 21 days" book,
>though good references and mentors can help matters immensely.
There are many techniques that can improve software productivity,
especially for us "unwashed". Too often projects are saddled with
unrealistic schedules, despite everyone understanding that
date-driven schedules are idiotic. Management demands, engineers deliver
(late), and we have the typical "late" software release. How many of us
do *real* code reviews? How many get *decent* requirements docs/specs? I
suspect many more are writing code as these are being developed than are
getting them in advance of the archectural decisions.
> Sure, the
>20-somethings (or even early teens) can pump out a lot of code...and do it
>25 hours/day (assuming enough Jolt Cola and Pizza)....but the quality of
>that code? It is typically far from what the 10/20/+ year veterans can do
>(at least the good ones...all veterans are not good...just like all
>youngsters are not bad).
>...
A *good* IDE might help, but so would code reviews, style guides, etc.
doug
Laurence V
wrote:
>> Awards are not paid for? Are they not, now? Explain to me then how the
>> crooks at Java Developer's Journal asked me to write a review of a
>> product, then "declined" to publish it WHEN THE COMPANY WHO MADE THE
>> PRODUCT WASN'T INTERESTED IN ADVERTISING in their corrupt "magazine".
>> JDJ robbed me of my article fee.
>
>how corrupt?
>Details?
>Review of what product if i may ask?
When a magazine asks an established author to write an article for
them, and then tells the author to get stuffed when the author
delivers the article... then the magazine is treating its source of
content with complete lack of respect. In addition, when the same
magazine based its decision to publish or not to publish on the basis
of whether the article can be linked to a large chunk of advertising
income or not, and not on whether the article falls below the mag's
quality standard, then that magazine's editorial/management team is
corrupt.
And before anyone comes up with the argument that JDJ possibly
declined to publish because the article fell below par, here are two
simple and final counter-arguments:
a) I've written many other articles for other magazines, and editors
and readers regularly felt they needed to compliment me with my
above-average writing quality.
2) I was luckily able to sell the article that JDJ commissioned me to
write, but refused to pay for, to another mag that did publish it
(virtually with no edits needed).
L.
John Bridges
(http://www.swingsoft.com) SwingBuilder product.
I don't think we've succeeded yet, but in some aspects we've come close, but
others we need polishing.
We decided that XML (or a binary version of it) would be an ideal way to store
the UI. We also felt that chopping the IDE into pieces would suit our needs.
If you have time to have a look we would really appreciate any feedback.
My raison d'etre for this was (apart from trying to be independent) to try and
solve a problem that I saw in the Java domain. Unfortunately sometimes you get
too close to these things to see whether you are still going in the right
direction.
Any feedback apreciated.
Regards
John
Andrzej
>
> This has been something we've been trying to do.
>
> (http://www.swingsoft.com) SwingBuilder product.
>
> I don't think we've succeeded yet, but in some aspects we've come close, but
> others we need polishing.
>
> We decided that XML (or a binary version of it) would be an ideal way to store
> the UI. We also felt that chopping the IDE into pieces would suit our needs.
>
> If you have time to have a look we would really appreciate any feedback.
An excellent concept....but I do have a few points:
1) It would be nice to have a visual tool that generates clean, well
documented Java code that you could then incorporate into your own
applications. Plugins and external data formats are not always
appropriate for UI code.
2) Your editor documentation is pretty scarce on the site (I know it's not
released yet)....however if it does not have Find/Replace In Current
Window/In Open Windows/In Files (like JPadPro has...and no-one else that I
have seen so far...) then I would not find it very useable. I am addicted
to those features. Also, the screen shot has these ugly tab markers in
it....I hope that will somehow disappear before the final version.
3) (This is an important one!). Are you going to publish your
API/Interface Documentation so that we could potentially buy other vendors
tools to plug into your IDE architecture? If I cannot pick and choose the
best of breed from many vendors, and bolt them together, then your
solution loses a lot of it's benefit. Scripting and extendability in
JPython/Java is a nice touch.....but true plug and play with other modules
is what I was getting at in my rather long dissertation on the topic of
IDE's. If you are not going public with the interface specs, then your
solution is just a more modular way of pricing a monolithic IDE and does
not carry much value with it. Your comment that chopping the IDE into
pieces suits "YOUR" needs (emphasis mine). WHat about the customer's
needs? Oh well....lets be like all the other corporate IDE vendors and
forget the customer. <sarcastic grin>
4) Speaking of pricing....to quote Harry Chapin....IT SUCKS! The total
price of the builder/editor/debugger/project modules (leaving out the
modeller for now) exceeds that of an integrated package such as VC,
JBuilder, or VA and they basically supply the same functionality. JPadPro
is $50 US and includes a great editor, project capability and a debugger
(though the debugger could use a bit more work...). Sure it doesn't have
a UI builder....but one that generated Java code would work nicely with
JPadPro (or other tools that are similar).
Hey! You asked for feedback....be careful what you ask for....you might
get it! ;-)
John Bridges
killed for a UI builder that constructed sensible code since then I have vacilated
between storing the UI in a separate format and code generation. As you can probably
tell I'm currently in favour of the separate format - Delphi and VB have lived very
nicely on this concept. I guess the crux of this matter is we have yet to see a
really intelligent code parser for reconstructing UI code - so its very difficult to
generate code that can be modified sensibly by an expert developer (tweaked and
added to etc) and still be read into the tool for further use. JBuilder makes a half
decent stab at this, but you are still restricted to the jbInit() method and making
tweaks like having arrays of controls (btw this is just an example of one thing I
can't do and there are many others!). The other thing of course, is that UI code can
be really messy - it can obscure what the program is actually doing - so a
constrained format, or language is actually a reasonable solution.
2. Yes. This is still a work in progress and there are many things that are to be
added. I'm an Emacs/CodeWright fan, so you can guess what my opinions on what an
editor should contain might be although some of the MS-Dev users on the team need
some persuading that the Emacs/Codewright level of functionality is necessary. This
is a really tough nut. The tab markers btw are optional - there is an option to
switch them off - its a pseudo-useful feature CW for example allows you to mix and
doesn't auto-convert, so sometimes its nice to be reminded that there is a mix of
tabs/spaces.
3. This has certainly been the intention. There are a number of issues here. 1.
Ensuring that there is a coherent strategy for communicating between components. 2.
Getting the tools to a stage where a coherent API can be published. 3. If true
extensibility can be achieved it really requires that the various tools on the
market use a common communications strategy. Maybe (dare I say it) MS had the right
idea with COM.
4. Pricing - always a sticky one :-) Everybody wants everything for free. This is
something to be worked on. But the comparisons with VAJ, VCafe, JBuilder may not be
accurate as you're doing it at the lowest level, whereas the idea is to undercut
these tools at their highest level so perhaps we're talking $500 for the set versus
$3000 for the comparable tools. But there is flexibility in the pricing model and
we're aware of the differentials. Basically we would like to be able to offer a
discounting scheme depending on however many components are bought. Its often
forgotten that to run a business is expensive - we're talking of the order of $400 -
$500k per annum, so pricing is always affected by this. But hey we're still working
on this. Our underlying philosophy is that software shouldn't necessarily be free,
but it should be much cheaper than it is nowadays.
All comments welcome, so any more, just fire away :-)
Regards
John
Andrzej wrote:
> John Bridges wrote:
> >
> > This has been something we've been trying to do.
> >
> > (http://www.swingsoft.com) SwingBuilder product.
> >
> > I don't think we've succeeded yet, but in some aspects we've come close, but
> > others we need polishing.
> >
> > We decided that XML (or a binary version of it) would be an ideal way to store
> > the UI. We also felt that chopping the IDE into pieces would suit our needs.
> >
> > If you have time to have a look we would really appreciate any feedback.
>
Johan Compagner
http://java.sun.com/products/jfc/tsc/articles/persistence/index.html
John Bridges <Jo...@swingsoft.com> wrote in message news:3845ACDC...@swingsoft.com...
Scott Stanchfield
> 1) It would be nice to have a visual tool that generates clean, well
> documented Java code that you could then incorporate into your own
> applications. Plugins and external data formats are not always
> appropriate for UI code.
This _always_ bothers me...
Use MVC... This provides good separation of your GUI and business logic.
If the GUI is fully generated and separate from your "real code", who
cares what the code looks like? IMHO GUIs are infinitely more
maintainable visually, no matter what the code looks like (as long as
the generated code is correct and doesn't hurt performance, of course)
I use VisualAge for Java, applying MVC when I design. I use the Visual
Composition Editor (VCE) for the GUI development and _never_ touch the
gen'd code. By creating the program logic in separate classes, the GUI
code (whether it's generated or handwritten) doesn't obscure logic.
For an example of how this works, see my MVC in VisualAge article at
http://www7.software.ibm.com/vad.nsf/Data/Document2672?OpenDocument&p=1&
BCT=1&Footer=1
--
-- Scott
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Stanchfield the...@jguru.com http://www.jGuru.com/thetick
jGuru Training by MageLang Institute http://www.jGuru.com
VisualAge for Java Tips --> http://www.jGuru.com/thetick/visualage/tips
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Stanchfield
that up if need be...)
I disagree with your statement -- I think that many of those who find
they "get in the way" just haven't taken the time to learn the tools, or
just have such a prejudice against such tools that they _won't_ really
try. I was actually in that boat.
When I first started learning Java, I tried out Visual Cafe. I dropped
it's GUI builder because I _did_ find I could write the code faster by
hand ;)
Then I joined MageLang to write a course for IBM. IBM wanted the course
to use VisualAge, so I grudgingly learned it (kicking and screaming),
and after about two weeks I swore I'd never go back to writing GUIs by
hand again.
[Note that I write GUI examples by hand in newsgroups and when teaching
Java because not everyone uses the same tools. Generally, though, I
prefer to use concepts rather than code when discuissing things like
layout management design so people can use it]
--
-- Scott
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Scott Stanchfield the...@jguru.com http://www.jGuru.com/thetick
jGuru Training by MageLang Institute http://www.jGuru.com
VisualAge for Java Tips --> http://www.jGuru.com/thetick/visualage/tips
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Andrzej <and...@spamicidechaeron.com> wrote in message
news:3840814E...@spamicidechaeron.com...
> Jim Sculley wrote:
>
> > Right you are. My mistake. You were quoted in a message and the
author
> > of that message stated he hadn't used it. My bad.
>
> No problem. My take on all such tools is that they aren't bad....and
can
> help jr. to
> medium level programmers...but that many real hard-core experts find
they
> just get in the way.
>
Scott Stanchfield
> Vladimir Yakubovich wrote:
>
> > Could you, please, explain us your debugging technique with bare
JDK?? Is it
> > 10x times faster that debugging in JBuilder (or other IDE)?? Or you
are so
> > "good" that you write the code that doesn't require debugging from
the first
> > attempt?? :)
>
> I do strive for the latter ;-) ...but do not always succeed ;-( . A
lot
> of good editors (like JPadPro) have debugging built in. I was
commenting
> mainly on the bloated, slow and buggy IDE's (the term seems to usually
> refer to visual tools) like JBuilder, Visual Cafe, VisualAge and such.
I'd include JBuilder and VCafe in "buggy", but definitely not VAJ. Very
stable product...
Not to mention excellent at bean & app development, visually and not.
Scott Stanchfield
news:3840266D...@geocities.com...
> > [ debugging better w/ JDK ? ]
> In one sense, yes, he could be.
>
> In catching defects, the most effective single method has been shown
to be code
> inspections. If he was that good, then his "debugging" technique would
heavily
> involve inspection, unit testing, etc. and would not require nearly as
much
> stepping through the debugger.
Don't get me started on inspections... oh well, too late!
My general opinion: I believe code inspections have the entirely wrong
goals. Testing should be used to catch bugs. Inspections should be used
to check _maintainability_.
Back when I worked at IBM, I'd take code to inspections and people would
nitpick misspellings in my comments. My code did the job correctly, or
the problems that were there were hard to "see" in a read of the code.
Any problems they did find were always "obvious" things that would be
caught instantly during a test.
It drove me nuts that people were trying to find bugs. The tasks were
often so simple that there either were no bugs or the bugs were just
silly things that I'd find in two minutes of testing.
_However_, the thing that was of most concern was never addressed in the
reviews. Could other people pick up and modify my code if needed? Could
they easily figure out the design and where to put new features, or if
they had to debug to find problems later, could they?
Test first. Inspect after. That ensures the inspectors have time to
think about maintenance, rather than try to find silly bugs...
Good debuggers help greatly in finding real problems that inspections
will almost always miss. Some good debuggers (like VisualAge's have
features to catch exceptions at the point they're thrown, even if your
code catches them generically.)
-- Scott
Scott Stanchfield
news:81unv1$kj0$1...@halcyon.com...
I would have to admit that due to some of the poor editors in IDEs
(VisualAge's code editor is "ok", but doesn't compare to CodeWright,
SlickEdit, emacs..) the handwritten code might be a bit less productive,
but considering the code generation possibilities (creating bean
properties and events, for example, not to mention GUI code gen) the
balance tips to IDEs as more productive overall IMHO.
Scott Stanchfield
> A good point of clarification, Ray, with which I agree. My reference
> (which should have been more clear) was to IDE's that were of the
visual
> nature....used to drag and drop UI components, which are not near as
> useful as a heads-down "programmer's editor" as you call it. I would
not
> recommend Notepad or vi (which is an anachronism).
I'd just love to go one-on-one with a programmer's editor user to
develop a JavaBean MVC app with an average GUI frontend (assuming the
same app & GUI layout design in both cases). Not just on dev time (which
I'd kick some butt using VAJ) but also for maintainability of the code.
A picture of a GUI is quite literally worth hundreds or thousands of
words...
I maintain that a good drag-n-drop GUI builder is significantly faster
than even a very fast typist coder.
Andrzej
>
> I'd just love to go one-on-one with a programmer's editor user to
> develop a JavaBean MVC app with an average GUI frontend (assuming the
> same app & GUI layout design in both cases). Not just on dev time (which
> I'd kick some butt using VAJ) but also for maintainability of the code.
Of course you would...and you would likely win too! But that is because
you have "stacked the deck" in favour of the IDE tool.
How about we develop a non-average GUI with some novel paradigms and data
models
that are not handled by normal drag and drop construction? Then you would
likely
lose the contest and using and IDE would likely end up with less
maintainable code.
Use the right tool for the job...and moreover, know WHY you are doing so
and the
compromises you have made (consciously or otherwise) by picking the tools
you use.
(This applies to IDE's, JDK + notepad and anything between).
Andrzej
> Use MVC... This provides good separation of your GUI and business logic.
I do...and recommend that everyone else does as well.
> If the GUI is fully generated and separate from your "real code", who
> cares what the code looks like? IMHO GUIs are infinitely more
> maintainable visually, no matter what the code looks like (as long as
> the generated code is correct and doesn't hurt performance, of course)
What if you change tools? Then you really care what the generated code
looks
like since you probably have to maintain it manually.
I have also found that cutting-edge UI paradigms almost always require
custom
coding...the IDE's just can't handle anything out of the ordinary it
seems.
Ooops..that means you're back to custom code again....
I'm not advocating that you never use a visual IDE to create your
UI...just that
you should be aware of the consequences of doing so.
John Bridges
I'd agree - I don't want to care how the code looks, but even in the
inimitable VAJ there is not a total separation of GUI from logic.
But we also have to look at how far the tools go - even if you don't
want to touch GUI code you still have to - generally speaking. Little touches
like being able to place controls in arrays (anonymity) would be nice.
But there are always a million and one things like this that could be done.
I believe that a good UI builder is worth its weight in gold - it principle it means I don't have to learn nuances of a control when all that grubby detail can be hidden from me. REAL programmers don't have to show their battle scarred editors ;-)
Not having the code inserted into your controller is a plus in a team - there's always a novice who pokes where they shouldn't. Anything that can distract from the actual job at hand has to be a plus. Contracts are best enforced when its impossible to break them and given that Java doesn't enforce MVC contractually you have to rely on self restraint - or a mechanism which prevents that sort of mucking around.
John
Scott Stanchfield wrote:
Andrzej <and...@spamicidechaeron.com> wrote in message
news:38449660...@spamicidechaeron.com...
> 1) It would be nice to have a visual tool that generates clean, well
> documented Java code that you could then incorporate into your own
> applications. Plugins and external data formats are not always
> appropriate for UI code.
This _always_ bothers me...
Use MVC... This provides good separation of your GUI and business logic.
If the GUI is fully generated and separate from your "real code", who
cares what the code looks like? IMHO GUIs are infinitely more
maintainable visually, no matter what the code looks like (as long as
the generated code is correct and doesn't hurt performance, of course)
I use VisualAge for Java, applying MVC when I design. I use the Visual
Composition Editor (VCE) for the GUI development and _never_ touch the
gen'd code. By creating the program logic in separate classes, the GUI
code (whether it's generated or handwritten) doesn't obscure logic.
For an example of how this works, see my MVC in VisualAge article at
http://www7.software.ibm.com/vad.nsf/Data/Document2672?OpenDocument&p=1&
BCT=1&Footer=1--
Scott Stanchfield
> Scott Stanchfield wrote:
>
> > Use MVC... This provides good separation of your GUI and business
logic.
>
> > If the GUI is fully generated and separate from your "real code",
who
> > cares what the code looks like? IMHO GUIs are infinitely more
> > maintainable visually, no matter what the code looks like (as long
as
> > the generated code is correct and doesn't hurt performance, of
course)
>
> What if you change tools?
What if you decide to switch to C++?
I always hear the tool-switch argument, and it _is_ a concern.
However:
1) how often _do_ people _really_ switch?
2) you can still maintain the GUI in the old tool (let's say VAJ) until
you convert it (if you ever do) and update the business logic in the new
tool
3) Assuming a good GUI design (pref not GridBag ;), converting to a new
IDE GUI setup isn't bad. Probably takes a couple hours to convert
(assuming someone who knows the new tool...)
NOTE: that couple hours on a "what if" is still far less than the time
it takes to maintain the code by hand... [And if need be, any decent GUI
programmer could recreate that GUI by hand within a few hours, inc even
handling. Esp if just rearranging existing code...]
4) The code generated by VAJ _is_ human readable and changeable if you
decide to go manual at some later date. You could maintain it; you just
wouldn't be able to visually design it again after manual changes.
****> But, most importantly... <****
5) Many of the IDE vendors are working with Sun on the new XML-based
bean persistence. This should eventually replace much of the proprietary
design data they store, making the visual designs more portable.
Probably not perfect, but should be pretty good compatability.
By the time you switch (if ever) this may be in place making the issue
moot
> I have also found that cutting-edge UI paradigms almost always require
> custom
> coding...the IDE's just can't handle anything out of the ordinary it
> seems. Ooops..that means you're back to custom code again....
All you should be doing with visual builders is:
* "draw" the GUI
* drop am instance or variable of a model
* connect entry fields to model properties
* connect buttons/menus to call method
There shouldn't be anything tricky going on. If there is, the visual
design gets less readable. The logic belongs in the model, not the
view/controller.
> I'm not advocating that you never use a visual IDE to create your
> UI...just that
> you should be aware of the consequences of doing so.
Of course, but one should also weigh the benefits, which IMHO always
outweigh a small-cost "what if" scenario... Maintenance is forever ;)
Scott Stanchfield
> I'll ignore the implicit assumption that I don't use MVC ;-)
Sorry -- not intended. I just like to bring up MVC whenever someone even
hints at "GUI code obscuring program logic". Doesn't have to be...
> I'd agree - I don't want to care how the code looks, but even in the
> inimitable VAJ there is not a total separation of GUI from logic.
Have you read my article (URL in the quoted text)? It's quite easy to
do... Basic idea:
1) create model interface
2) create concrete model implementing model interface
(all logic is in here)
3) create a UI
a) draw GUI
b) drop variable of model interface type in builder
c) connect fields to properties in model
d) connect buttons/menus etc to method calls in model
4) promote the variable (allow people to set it outside this UI class)
call it "model" property
5) create an application
a) drop instance of UI
b) drop instance of concrete model
c) connect them together (draw a line) to set the model property in
the UI
Once you get used to this, there is no logic at all in the UI. It is
strictly a view/controller on the model. The model does all of the
thinking.
> But we also have to look at how far the tools go - even if you don't
want to
> touch GUI code you still have to - generally speaking. Little touches
like
> being able to place controls in arrays (anonymity) would be nice. But
there
> are always a million and one things like this that could be done.
True -- GUI builders assume a fairly static interface. You _can_ do a
few things like this visually using CardLayout and Object Factories in
VAJ, but I'd generally recommend that someone create a method in the
composite bean to do the add, then draw a connection to simply call it.
Very easy to do, still no mingling of generated code with user code
(they're in separate methods)
> I believe that a good UI builder is worth its weight in gold - it
principle
> it means I don't have to learn nuances of a control when all that
grubby
> detail can be hidden from me. REAL programmers don't have to show
their
> battle scarred editors ;-)
Cool -- I argued that a few weeks ago (what a struggle that was...)
> [...] Java doesn't
> enforce MVC contractually you have to rely on self restraint - or a
> mechanism which prevents that sort of mucking around.
Sounds like a good job for a code inspection ;)
Scott Stanchfield
> Scott Stanchfield wrote:
> >
> > I'd just love to go one-on-one with a programmer's editor user to
> > develop a JavaBean MVC app with an average GUI frontend (assuming
the
> > same app & GUI layout design in both cases). Not just on dev time
(which
> > I'd kick some butt using VAJ) but also for maintainability of the
code.
>
> Of course you would...and you would likely win too! But that is
because
> you have "stacked the deck" in favour of the IDE tool.
> How about we develop a non-average GUI with some novel paradigms and
data
> models
> that are not handled by normal drag and drop construction? Then you
would
> likely
> lose the contest and using and IDE would likely end up with less
> maintainable code.
I intentionally said "average GUI frontend", meaning one that's
realistic, not intentionally non-average. Sounds like you're saying it
would take an abbie normal GUI to hurt GUI builder development, or
trying to stack the deck against GUI builders.
By definition, abbie normal wouldn't occur that often, so what's the
better choice for overall development?
My statement played the odds for the deal; yours stacks the deck with a
trey...
Still, I'd take on the task of a non-average GUI as well. But note that
I also stated both users must implement the same app/layout design...
Assuming I were familiar with the paradigm being employed I'm sure I'd
do well...
> Use the right tool for the job...
I totally agree with this principle...
> and moreover, know WHY you are doing so and the
> compromises you have made (consciously or otherwise) by picking the
tools
> you use.
> (This applies to IDE's, JDK + notepad and anything between).
As you say, applies to all -- as a generalization (with possibly some
exceptions like very dynamic GUIs, which I think are problematic from a
CHI perspective, though) I'd say:
GUIs should be drawn, logic should be written.
Simple reasoning is back to "A picture is worth hundreds/thousands of
words".
Of course I assume it's a pretty picture, not a Picasso. It's just as
easy to create horrid visual design as it is to create horrid code. You
need to know how to use the tools either way :)
Michael Kölling
>
> I'm a JAVA developer. I've been developing java applets (with swing) using
> sun's jdk 1.2.2. Anyways I'm thinking of buying either the latest version of
> the JBuilder or Visual Cafe because I heard it saves you a lot of time
> programming in them vs. doing it without any programming environment. What
> do you suggest I use the JBuilder or the Visual Cafe? Does it require a lot
> of time to understand how to use them? Do I need a book to learn how to use
> it? and if so, if you have one in mind please suggest it to me.
>
> Thanks,
>
> Ahmed
You can do applets VERY nicely in BlueJ (free environment). Have a look
at its tutorial to see how.
http://bluej.csse.monash.edu.au/
Michael
Ray McVay
> How about we develop a non-average GUI with some novel paradigms and data
> models
> that are not handled by normal drag and drop construction? Then you would
Please give me a couple of simple examples; I'm short on UI imagination
at the moment. 8-)
--
Ray
Jason M
there was no real help for the initial poster.
Can anyone recommend an IDE that meets the need without adding a lot of
bells and whistles?
Larry MacFadyen
so obviously it is somewhat personal decision. I also like Kawa, but it has no
built-in GUI builder. If you want a nice IDE with lots of goodies (like CORBA
support, database support, etc.) then JBuilder isn't hard to learn, and I'd
definitely recommend using some IDE over VI and Notepad. Kawa is lightweight
wrapper around the JDK, and allows quick switching between JDKs. JBuilder
apparently does that now too, but I used 2.0, not the latest 3.0, so you'd have
to look into it if you want that.
To just do the basics, create project, edit files, build, run, debug, etc.,
isn't hard to learn. If you want repository integration, CORBA, database,
deployment via JAR, and all kinds of additional such stuff, you'll just need to
use the tool more.
Larry
Joe62
>If someone would write a small fast gui builder that
>supported swing ...
Can you please clarify to a JAVA newbie what "supporting swing" means?
Joe
"In a mad world, to think oneself to be free of madness is itself a form of madness."