Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.) 
Author Message
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)



Quote:

> How many vendor's VMs does ObjectShare's Smalltalk stuff run on?

How many does it need to run on? If ObjectShare's Smalltalk runs on its VM
and that VM is available for every platform you care about (and a dozen
more that you don't care about), why do you care?

Quote:
> How much effort is it to port from your dialect to another vendor's?

Why do you want to if it works in the dialect you have chosen? Most non-GUI
Smalltalk code ports with little effort (we do have a real ANSI standard,
you know). GUI code can present a problem, but several automated tools
exist to make this easy. For example, I can run ObjectShare VisualSmalltalk
GUI code *unmodified* in IBM's VisualAge. I can even re-edit the code using
a VisualAge GUI builder and carry my VSE GUI design forward in VA
(something that is presently very hard to accomplish in the Java world).

How much effort is it to port GUI code from one Java IDE to another such
that GUI designs generated on the first IDE can be carried forward on the
second IDE? Ever tried it? It's a {*filter*}.

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:



> > How many vendor's VMs does ObjectShare's smalltalk stuff run on?

> How many does it need to run on? If ObjectShare's Smalltalk runs on its VM
> and that VM is available for every platform you care about (and a dozen
> more that you don't care about), why do you care?

The ability to switch VMs on the fly means you're not at the mercy of a
single company's bugs and policies.  You have freedom to move if that
becomes necessrary.  In Java, that move generally means changing your
executable path and CLASSPATH.  In Smalltalk, this means typically
buying a new tool and getting involved in a porting effort.

On the development side, my company routinely mixes different IDEs
and development environments without a hitch from multiple vendors.

Quote:
> > How much effort is it to port from your dialect to another vendor's?

> Why do you want to if it works in the dialect you have chosen?

If everything from pricing to bugs to performance to feature-lists is
perfect, than indeed why would you change?  Are you claiming there
exists a Smalltalk implementation so much better than the competition's
that no one would ever wish to switch?

Quote:
> Most non-GUI Smalltalk code ports with little effort (we do have a
> real ANSI standard,  you know).

If the standard had teeth, you wouldn't have to "port", you'd just
switch and go.  I've observed support personnel with no knowledge
of Java switch JVMs for a server product without a hitch.

Quote:
> GUI code can present a problem, but
> several automated tools exist to make this easy. For example, I can run
> ObjectShare VisualSmalltalk
> GUI code *unmodified* in IBM's VisualAge. I can even re-edit the code using
> a VisualAge GUI builder and carry my VSE GUI design forward in VA
> (something that is presently very hard to accomplish in the Java world).

> How much effort is it to port GUI code from one Java IDE to another such
> that GUI designs generated on the first IDE can be carried forward on the
> second IDE? Ever tried it? It's a {*filter*}.

Yes, it is a {*filter*}, which I why I don't do alot of GUI design using
properietary IDEs (I use them for prototyping, but not final code
generation).  IDEs are, IMHO, the most common point of vendor lock-in
in a system, so I avoid using non-standard features or code-generators
whenever possible.

Quote:
> -Eric

        -Mike


Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:

>The ability to switch VMs on the fly means you're not at the mercy of a
>single company's bugs and policies.  You have freedom to move if that
>becomes necessrary.  In Java, that move generally means changing your
>executable path and CLASSPATH.  In Smalltalk, this means typically
>buying a new tool and getting involved in a porting effort.

OK.  This makes sense.  But I doubt that many companies would need
(and can afford) having multiple licenses of different Java IDEs for
mix and match (at least in our shop we stick with VA Java) purpose.

Quote:
>If everything from pricing to bugs to performance to feature-lists is
>perfect, than indeed why would you change?  Are you claiming there
>exists a Smalltalk implementation so much better than the competition's
>that no one would ever wish to switch?

The decision of which IDE to use, based on my own experience, is done
before the project is started.  It doesn't matter what languages that
you are talking about.  Once the project is started, we will stick
with it.  Typical commerical projects (as least the ones that I have
involved in) would not easily afford switching to different IDEs since
this involves cost, time, training and risk.  In addition, at least in
the Smalltalk world, you really won't be that far off if you choose
either VW or VA since they are both very robust, have been around for
a long long  time and have been deployed in many mission critical
projects.  You don't really need to worry about switch IDE for tool
set that is extremely mature.

The only time that we did switch IDE recently was from Java Workshop
to VA Java.  But we don't forsee we will want to switch to other Java
IDE anytime soon because we like what we see in VA Java.

--
Mark Wai
Wator InnoVision



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)


Quote:

> The ability to switch VMs on the fly means you're not at the mercy of a
> single company's bugs and policies.  You have freedom to move if that
> becomes necessrary.

The same freedom exists in Smalltalk as well (if necessary - which is
rarely the case).

Quote:
> In Java, that move generally means changing your
> executable path and CLASSPATH.  In Smalltalk, this means typically
> buying a new tool and getting involved in a porting effort.

In Java, that often means buying a new IDE as well. If you have made the
mistake of using any of the first Java IDE's special features (like its GUI
or DB tools), then a porting effort is required. Unless the two Java IDEs
used the exact same version of the JDK (and when is that ever the case?),
you will also be faced with a porting effort.

We recently moved a major Java app from JBuilder to VA Java. It was neither
straightforward nor easy. We had to throw out the GUI (including several
nice extensions that Borland had made), backport several Java classes that
did not exist in VAJ (we were using a latter version of the JDK under
JBuilder) and "fix" dozens of inconsistencies based on JDK differences. We
found the effort to be no more taxing than porting an app from
VisualSmalltalk to VisualAge Smalltalk using one of the commercial
conversion tools.

Quote:
> On the development side, my company routinely mixes different IDEs
> and development environments without a hitch from multiple vendors.

I'm curious as to which IDE's you so freely mix. Do you use any special
features of these IDEs (e.g., GUI or DB tools)? Do all of them use the
exact same version of the JDK?

Quote:
> If everything from pricing to bugs to performance to feature-lists is
> perfect, than indeed why would you change?

Indeed. Why would you?

Quote:
> Are you claiming there exists a Smalltalk implementation so much
> better than the competition's that no one would ever wish to switch?

There are at least two (VisualWorks and VisualAge) that come awfully close
to that (it would be a stretch to say that "no one" would ever want to
switch). Most Smalltalk developers have a favorite dialect. Some even have
a favorite two or three dialects. If forced to switch, most Smalltalk
developers would switch to another Smalltalk dialect long before they
switch languages.

Quote:
> > Most non-GUI Smalltalk code ports with little effort (we do have a
> > real ANSI standard,  you know).

> If the standard had teeth, you wouldn't have to "port", you'd just
> switch and go.

By your definition, no ANSI standard has "teeth". The Java "standard" (such
as it is) also has no teeth either.

Quote:
> I've observed support personnel with no knowledge
> of Java switch JVMs for a server product without a hitch.

And I've observed Java developers with deep knowledge of Java take a week
or more to port from one IDE to another.

Quote:
> > How much effort is it to port GUI code from one Java IDE to another
such
> > that GUI designs generated on the first IDE can be carried forward on
the
> > second IDE? Ever tried it? It's a {*filter*}.

> Yes, it is a {*filter*}, which I why I don't do alot of GUI design using
> properietary IDEs (I use them for prototyping, but not final code
> generation).

Ah. That helps to explain your "freely mixing" comments above. You use then
in a least common denominator manner.

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:



> > The ability to switch VMs on the fly means you're not at the mercy of a
> > single company's bugs and policies.  You have freedom to move if that
> > becomes necessrary.

> The same freedom exists in Smalltalk as well (if necessary - which is
> rarely the case).

I was speaking in this case to client runtime-environment, not development
environments.  I might happen to develop in JBuilder 2 on an NT box,
but this doesn't stop a client from running the final app on a Solaris
box using a Sun JVM, or an AIX box using an IBM JVM.  The development
environment has nothing to do with the target execution environment.

Can a Smalltalker develop in, say, ObjectWorks, and have his client
execute in another vendor's Smalltalk VM?

Quote:
> > In Java, that move generally means changing your
> > executable path and CLASSPATH.  In Smalltalk, this means typically
> > buying a new tool and getting involved in a porting effort.

> In Java, that often means buying a new IDE as well. If you have made the
> mistake of using any of the first Java IDE's special features (like its GUI
> or DB tools), then a porting effort is required. Unless the two Java IDEs
> used the exact same version of the JDK (and when is that ever the case?),
> you will also be faced with a porting effort.

> We recently moved a major Java app from JBuilder to VA Java. It was neither
> straightforward nor easy. We had to throw out the GUI (including several
> nice extensions that Borland had made), backport several Java classes that
> did not exist in VAJ (we were using a latter version of the JDK under
> JBuilder) and "fix" dozens of inconsistencies based on JDK differences. We
> found the effort to be no more taxing than porting an app from
> VisualSmalltalk to VisualAge Smalltalk using one of the commercial
> conversion tools.

You seem to be arguing my points for me :-)  Using proprietary IDE
extensions is the road to vendor lock in.  I don't use them, and so
don't suffer from this problem.  This is the point I'm trying to make,
and it's similar to Joern's in many respects.  By coding to the spec,
and not relying on proprietary tools and extensions, you get guarantees.
If you rely on a proprietary tool, you get lock-in, and big surprises
when you move to another proprietary tool.

Quote:
> > On the development side, my company routinely mixes different IDEs
> > and development environments without a hitch from multiple vendors.

> I'm curious as to which IDE's you so freely mix. Do you use any special
> features of these IDEs (e.g., GUI or DB tools)? Do all of them use the
> exact same version of the JDK?

No, and no.  For the most part, I'm committed to having my code run on
all JDKs reasonably possible within a given major release (in this case,
Java 1.1).  And it does - we manage to run on everything from Netscape
4.02 to IE 4.0 SP1 to SGI 1.3 (I think :-) to Java 2 on a SPARC.

Quote:
> > If everything from pricing to bugs to performance to feature-lists is
> > perfect, than indeed why would you change?

> Indeed. Why would you?

So: your Smalltalk of choice is better in all respects than the others
out there, for you and your customers?  That's stretching my imagination
quite far.

Quote:
> > Are you claiming there exists a Smalltalk implementation so much
> > better than the competition's that no one would ever wish to switch?

> There are at least two (VisualWorks and VisualAge) that come awfully close
> to that (it would be a stretch to say that "no one" would ever want to
> switch). Most Smalltalk developers have a favorite dialect. Some even have
> a favorite two or three dialects. If forced to switch, most Smalltalk
> developers would switch to another Smalltalk dialect long before they
> switch languages.

And how much effort is involved in switching from one dialect to the
other?  For me, the effort so far has been close to zero.

Quote:
> > > Most non-GUI Smalltalk code ports with little effort (we do have a
> > > real ANSI standard,  you know).

> > If the standard had teeth, you wouldn't have to "port", you'd just
> > switch and go.

> By your definition, no ANSI standard has "teeth". The Java "standard" (such
> as it is) also has no teeth either.

My experience differs.  Java vendors strive very hard to match the language
spec.  The fact that you relied on obvious, proprietary IDE extensions does
not alter that point.

Quote:
> > I've observed support personnel with no knowledge
> > of Java switch JVMs for a server product without a hitch.

> And I've observed Java developers with deep knowledge of Java take a week
> or more to port from one IDE to another.

Again, a mismatch.  You're talking IDEs, I'm talking client execution
environments.  There is no "port"ing involved, period.

Quote:
> > > How much effort is it to port GUI code from one Java IDE to another
> such
> > > that GUI designs generated on the first IDE can be carried forward on
> the
> > > second IDE? Ever tried it? It's a {*filter*}.

> > Yes, it is a {*filter*}, which I why I don't do alot of GUI design using
> > properietary IDEs (I use them for prototyping, but not final code
> > generation).

> Ah. That helps to explain your "freely mixing" comments above. You use then
> in a least common denominator manner.

More precisely, I ensure all important aspects of my development effort
(basically, the code and possibly supporting data) are expressed in a
common, well defined format that's supported by every major tool.  That
"format" is the Java language spec and bytecode format.

Quote:
> -Eric

        -Mike


Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:

>More precisely, I ensure all important aspects of my development effort
>(basically, the code and possibly supporting data) are expressed in a
>common, well defined format that's supported by every major tool.  That
>"format" is the Java language spec and bytecode format.

I doubt if the hardline Smalltalk crowd will even understand your point.
The mindset they use (effective, I don't dispute) is IDE based, and I've yet
to see any evidence (posted here, I mean) that the *language* by itself is
accorded the same kind of iconic respect that the C/C++/Java people give to
their languages.

For instance, I have recently seen claims that:
    - the reflexive
    - the immediately responsive
    - the image-based
    [-perhaps threading too]
nature of the language is/are central to Smalltalk.  I agree with these
judgements, very much so.   However *not one* of these aspects is touched by
the ANSI language standard...

    -- chris



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:

>In Java, that often means buying a new IDE as well. If you have made the
>mistake of using any of the first Java IDE's special features (like its GUI
>or DB tools), then a porting effort is required.

But it *is* a mistake.  And one that you learn from, surely?  Unless and
until the Java standards and implementations have matured to the point of --
say --VW (not that *I* think VW's anywhere near perfect, or even acceptable,
in it's GUI, but it's for you to decide what's acceptable for you) then you
*have* to assume that you'll be shifting from IDE to IDE (not to mention
from JVM to JVM).   Given that, *why not* stick to the defined common
denominator.  That -- after all -- is what it is for.  It isn't as if it's
difficult to do...

I should qualify the previous paragraph.  On one hand there are different
bugs in JVMs etc. which can be a real PITA to code around (e.g. almost
anything to do with scrollbars), on the other hand there are Beans which
show promise (I say no more than that) of allowing useful cross-IDE "RAD".

Quote:
>We recently moved a major Java app from JBuilder to VA Java. It was neither
>straightforward nor easy. We had to throw out the GUI (including several
>nice extensions that Borland had made), backport several Java classes that
>did not exist in VAJ (we were using a latter version of the JDK under
>JBuilder) and "fix" dozens of inconsistencies based on JDK differences. We
>found the effort to be no more taxing than porting an app from
>VisualSmalltalk to VisualAge Smalltalk using one of the commercial
>conversion tools.

I appreciate your difficulties.  Some of them (NB: *some*) sound self-made,
as if you hadn't made best use of the leverage the language provided you --
in this case standardisation.  Java isn't Smalltalk.  In much the same way
that The De{*filter*} Is Your Friend (tm) in Smalltalk, the standard (or the
type checker, or...) is your friend in Java.

Quote:
>> On the development side, my company routinely mixes different IDEs
>> and development environments without a hitch from multiple vendors.

>I'm curious as to which IDE's you so freely mix. Do you use any special
>features of these IDEs (e.g., GUI or DB tools)? Do all of them use the
>exact same version of the JDK?

For me, no (in fact: "of course not!"), to the latter two questions.  As a
result the only noticeable difficulties I've had have been caused by
scrollbars.  For the record, on question 1: I found JBuilder and Cafe
irritating and VAJ unbearable; the JDK would be fine except that it's
"make"-unfriendly and lacks a decent de{*filter*}.  The best -- for me -- was
Supercede, which has just been bought by Instantiations (your co. Eric?),
and who (apparently, but I'd welcome correction) don't intend to continue
the IDE.

Quote:
>> > Most non-GUI Smalltalk code ports with little effort (we do have a
>> > real ANSI standard,  you know).

>> If the standard had teeth, you wouldn't have to "port", you'd just
>> switch and go.

>By your definition, no ANSI standard has "teeth". The Java "standard" (such

It depends what either of you mean by "teeth"; the Java "standard" (such as
it is) is considerably wider-ranging than the ST one.

Quote:
>> Yes, it is a {*filter*}, which I why I don't do alot of GUI design using
>> properietary IDEs (I use them for prototyping, but not final code
>> generation).

>Ah. That helps to explain your "freely mixing" comments above. You use then
>in a least common denominator manner.

Damn right!

(Again, I should qualify.  I've pretty much given up on Java at the
front-end because I find the GUI classes so pathetic: the AWT was deficient
in many ways, but Swing learned too much from the mistakes and ended up with
something which is, beyond belief, crap.  Still, that's class design, not
language design.  Such is life...)

     -- chris



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)


Quote:

> I should qualify the previous paragraph.  On one hand there are different
> bugs in JVMs etc. which can be a real PITA to code around (e.g. almost
> anything to do with scrollbars)

No kidding. We have had (and still have) lots of fun getting scrollbars to
work in our various Java products. Getting any add-on GUI library to work
across the many dozen JDK, VM, OS, browser and IDE variations in a
nightmare. It really can't be done. The best you can hope for is to get it
working under the major combinations and damn the rest.

Quote:
> >We recently moved a major Java app from JBuilder to VA Java. It was
neither
> >straightforward nor easy. We had to throw out the GUI (including several
> >nice extensions that Borland had made), backport several Java classes
that
> >did not exist in VAJ (we were using a latter version of the JDK under
> >JBuilder) and "fix" dozens of inconsistencies based on JDK differences.
We
> >found the effort to be no more taxing than porting an app from
> >VisualSmalltalk to VisualAge Smalltalk using one of the commercial
> >conversion tools.

> I appreciate your difficulties.  Some of them (NB: *some*) sound
self-made,
> as if you hadn't made best use of the leverage the language provided you
--
> in this case standardisation.  Java isn't Smalltalk.  In much the same
way
> that The De{*filter*} Is Your Friend (tm) in Smalltalk, the standard (or the
> type checker, or...) is your friend in Java.

Many of them were self made. We made the mistake of assuming that WORA
meant WODA (write once, develop anywhere). The thought of building a large,
complex form-based (e.g., lots of windows and widgets) system by hand
without a GUI builder scares the {*filter*}out of me. I haven't done that since
my earliest Smalltalk days. I guess we'll just have to create our own Java
GUI builder... :-)

Quote:
> For the record, on question 1: I found JBuilder and Cafe
> irritating and VAJ unbearable; the JDK would be fine except that it's
> "make"-unfriendly and lacks a decent de{*filter*}.  The best -- for me -- was
> Supercede, which has just been bought by Instantiations (your co. Eric?)

The one and the same (pretty interesting development, eh?). It's a pretty
nice tool (I have used it as well), but it suffers from the same vendor
lock in problem that the others do.

Quote:
> and who (apparently, but I'd welcome correction) don't intend to continue
> the IDE.

At this stage, probably not (not exactly my department though <g>). The
Java IDE business is not a business that we want to be in (especially since
we partner directly with several of the other IDE vendors). Even if we did,
we can't afford to give our products away for years on end in the hopes of
gaining market share and eventually making money. The only folks that can
do that are IBM, Microsoft, Imprise and Symantec (the smaller IDE vendors
are all screwed in the long run).

Our Java business is primarily directed at Java performance issues (high
performance native compilers and deployment tools - thus our interest in
SuperCede's compiler technology) with a secondary business in Java add-on
class libraries (our jKit products) and tools (our forthcoming
WindowBuilder/J product - a cross IDE GUI builder/conversion tool).
SuperCede does contain some interesting class libraries that we may be able
to extract into new jKit products (that's just speculation at this point
though).

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:

> I doubt if the hardline Smalltalk crowd will even understand your point.
> The mindset they use (effective, I don't dispute) is IDE based, and I've yet
> to see any evidence (posted here, I mean) that the *language* by itself is
> accorded the same kind of iconic respect that the C/C++/Java people give to
> their languages.

The language is trivial; there are only 5 reserved words and the syntax fits on
a 3x5 card.
How much is there to talk about ?  The development environment is where the
action is; working
in a text editor is perhaps the least efficient way of developing that I can
think of.

Quote:

> For instance, I have recently seen claims that:
>     - the reflexive
>     - the immediately responsive
>     - the image-based
>     [-perhaps threading too]
> nature of the language is/are central to Smalltalk.  I agree with these
> judgements, very much so.   However *not one* of these aspects is touched by
> the ANSI language standard...

So what ?  They aren't parts of the language.
Quote:

>     -- chris

  jamesr.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)


Quote:

> I was speaking in this case to client runtime-environment, not
development
> environments.  I might happen to develop in JBuilder 2 on an NT box,
> but this doesn't stop a client from running the final app on a Solaris
> box using a Sun JVM, or an AIX box using an IBM JVM.  The development
> environment has nothing to do with the target execution environment.

> Can a Smalltalker develop in, say, ObjectWorks, and have his client
> execute in another vendor's Smalltalk VM?

There would never be a need for that because ObjectShare makes VMs for
almost every conceivable platform. You only need cross vendor VMs in the
event that your vendor does not supply them for the platforms you care
about. VisualWorks (ObjectWorks descendent) has the most platform options
available (although Squeak might have more - I don't know). VisualAge users
can choose between Windows, OS/2 and several UNIX flavors (and Mac if IBM
every lets it out of the lab). If wide platform support is an issue (and it
only seems to be an issue in a fraction of the Smalltalk efforts I have
seen), that will dictate the Smalltalk dialect decision up front.

Quote:
> You seem to be arguing my points for me :-)  Using proprietary IDE
> extensions is the road to vendor lock in.  I don't use them, and so
> don't suffer from this problem.  This is the point I'm trying to make,
> and it's similar to Joern's in many respects.  By coding to the spec,
> and not relying on proprietary tools and extensions, you get guarantees.
> If you rely on a proprietary tool, you get lock-in, and big surprises
> when you move to another proprietary tool.

Very, very true.

Quote:
> > I'm curious as to which IDE's you so freely mix. Do you use any special
> > features of these IDEs (e.g., GUI or DB tools)? Do all of them use the
> > exact same version of the JDK?

> No, and no.  For the most part, I'm committed to having my code run on
> all JDKs reasonably possible within a given major release (in this case,
> Java 1.1).

What does "reasonably possible" mean? We have the same issue/desire with
our Java products as well. Our jKit products run under a wide variety of
JDK versions, OSes, browsers and IDEs. Getting them to work that way was
*not* easy. It involved countless minor workarounds to bypass aberrant
behavior on various platforms. We constantly get bug reports concerning
weird incompatibilities on various JDK/OS combinations (which is one of the
reasons I am most annoyed at Sun's WORA claims). I *hate* scrollbars!

Quote:
> So: your Smalltalk of choice is better in all respects than the others
> out there, for you and your customers?

In all the respects that we care about, yes. Users of other Smalltalk
dialects will have a different set of criteria and may select a different
Smalltalk dialect as their best choice. Any of the major Smalltalk dialects
can be used to build almost anything you can imagine (at least in the
corporate MIS world). On the margin, different dialects may be better for
different tasks.

Quote:
> > There are at least two (VisualWorks and VisualAge) that come awfully
close
> > to that (it would be a stretch to say that "no one" would ever want to
> > switch). Most Smalltalk developers have a favorite dialect. Some even
have
> > a favorite two or three dialects. If forced to switch, most Smalltalk
> > developers would switch to another Smalltalk dialect long before they
> > switch languages.

> And how much effort is involved in switching from one dialect to the
> other?  For me, the effort so far has been close to zero.

Moving non-GUI (domain model) code usually requires little or no effort. DB
code can also port easily due to the existence of several cross dialect DB
libraries (like TOPLink). The area where pain occurs is in moving GUI code.
Fortunately, several commercial Smalltalk dialect conversion tools exist.
For example, I can run ObjectShare VisualSmalltalk GUI code *unmodified* in
IBM's VisualAge by using a compatibility library (we sell one, BTW). I have
been involved with quite a few VisualSmalltalk to VisualAge conversion
efforts. Most of them were very straightforward. Moving from one Java IDE
to another may be easier, but it is not unreasonable to do the same in
Smalltalk (when and if the need arises).

Quote:
> My experience differs.  Java vendors strive very hard to match the
language
> spec.

They also strive to lock you into their IDEs through a variety of means.

Quote:
> The fact that you relied on obvious, proprietary IDE extensions does
> not alter that point.

Would you consider the GUI code generations to be obvious proprietary
extensions? What if the code is 100% pure Java with no vendor library
extensions? There is no standard for what a Java window definition should
look like. All of the major IDEs can generate GUI code with no proprietary
library references (although some of them make this difficult). None of
them (that I know of) can make any sense out of code gen formats used by
the other tools.

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)
Thank you for illustrating so nicely the point I was trying to make.

(Not being sarcastic, nor intending any offence)

    -- chris

Quote:


>> I doubt if the hardline Smalltalk crowd will even understand your point.
>> The mindset they use (effective, I don't dispute) is IDE based, and I've
yet
>> to see any evidence (posted here, I mean) that the *language* by itself
is
>> accorded the same kind of iconic respect that the C/C++/Java people give
to
>> their languages.

>The language is trivial; there are only 5 reserved words and the syntax
fits on
>a 3x5 card.
>How much is there to talk about ?  The development environment is where the
>action is; working
>in a text editor is perhaps the least efficient way of developing that I
can
>think of.

>> For instance, I have recently seen claims that:
>>     - the reflexive
>>     - the immediately responsive
>>     - the image-based
>>     [-perhaps threading too]
>> nature of the language is/are central to Smalltalk.  I agree with these
>> judgements, very much so.   However *not one* of these aspects is touched
by
>> the ANSI language standard...

>So what ?  They aren't parts of the language.

>>     -- chris



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:



> > I was speaking in this case to client runtime-environment, not
> development
> > environments.  I might happen to develop in JBuilder 2 on an NT box,
> > but this doesn't stop a client from running the final app on a Solaris
> > box using a Sun JVM, or an AIX box using an IBM JVM.  The development
> > environment has nothing to do with the target execution environment.

> > Can a Smalltalker develop in, say, ObjectWorks, and have his client
> > execute in another vendor's Smalltalk VM?

> There would never be a need for that because ObjectShare makes VMs for
> almost every conceivable platform. You only need cross vendor VMs in the
> event that your vendor does not supply them for the platforms you care
> about. VisualWorks (ObjectWorks descendent) has the most platform options
> available (although Squeak might have more - I don't know). VisualAge users
> can choose between Windows, OS/2 and several UNIX flavors (and Mac if IBM
> every lets it out of the lab). If wide platform support is an issue (and it
> only seems to be an issue in a fraction of the Smalltalk efforts I have
> seen), that will dictate the Smalltalk dialect decision up front.

My point wasn't precisely about multi-platform capabilities but to
multiple vendor (multi-platform is a nice extra plus :-)

It is common (in my experience at least) during development to find
that your chosen vendor doesn't implement things optimally in certain
areas.  Their threading model may be slow, their socket implementation
might be, ahem, weird on a given platform, etc.  This sort of issue
often comes up when you're trying to deploy at a new customer
site - all of a sudden your hot software doesn't look so hot in
the client's environment due to an obscure vendor bug (or sub-optimal
runtime).  Complaining to the vendor won't necessarily yield a timely
fix.

Meanwhile...this bug/bad performance may be a non-issue in a competitor's
VM.  In the Java world, moving to such a VM is a trivial issue, usually
involving just switching your path/classpath around.  In the Smalltalk
world, it seems you are strongly beholden to your vendor or face a
port of your code.

- Show quoted text -

Quote:
> > You seem to be arguing my points for me :-)  Using proprietary IDE
> > extensions is the road to vendor lock in.  I don't use them, and so
> > don't suffer from this problem.  This is the point I'm trying to make,
> > and it's similar to Joern's in many respects.  By coding to the spec,
> > and not relying on proprietary tools and extensions, you get guarantees.
> > If you rely on a proprietary tool, you get lock-in, and big surprises
> > when you move to another proprietary tool.

> Very, very true.

> > > I'm curious as to which IDE's you so freely mix. Do you use any special
> > > features of these IDEs (e.g., GUI or DB tools)? Do all of them use the
> > > exact same version of the JDK?

> > No, and no.  For the most part, I'm committed to having my code run on
> > all JDKs reasonably possible within a given major release (in this case,
> > Java 1.1).

> What does "reasonably possible" mean? We have the same issue/desire with
> our Java products as well. Our jKit products run under a wide variety of
> JDK versions, OSes, browsers and IDEs. Getting them to work that way was
> *not* easy. It involved countless minor workarounds to bypass aberrant
> behavior on various platforms. We constantly get bug reports concerning
> weird incompatibilities on various JDK/OS combinations (which is one of the
> reasons I am most annoyed at Sun's WORA claims). I *hate* scrollbars!

The toughest area in Java compatibilty is the GUI side, I agree.  But
I think, perhaps, that you're exagerrating just how bad compatabilty
is.  I run into problems occasionally (and I think Scrollbars are
on everyone's hit-list), but it's the exception, not the rule.  Outside
of GUIs compatability is _extremely_ high.

Quote:
> > So: your Smalltalk of choice is better in all respects than the others
> > out there, for you and your customers?

> In all the respects that we care about, yes. Users of other Smalltalk
> dialects will have a different set of criteria and may select a different
> Smalltalk dialect as their best choice. Any of the major Smalltalk dialects
> can be used to build almost anything you can imagine (at least in the
> corporate MIS world). On the margin, different dialects may be better for
> different tasks.

Do you see this as continuing indefinitely?

- Show quoted text -

Quote:
> > > There are at least two (VisualWorks and VisualAge) that come awfully
> close
> > > to that (it would be a stretch to say that "no one" would ever want to
> > > switch). Most Smalltalk developers have a favorite dialect. Some even
> have
> > > a favorite two or three dialects. If forced to switch, most Smalltalk
> > > developers would switch to another Smalltalk dialect long before they
> > > switch languages.

> > And how much effort is involved in switching from one dialect to the
> > other?  For me, the effort so far has been close to zero.

> Moving non-GUI (domain model) code usually requires little or no effort. DB
> code can also port easily due to the existence of several cross dialect DB
> libraries (like TOPLink). The area where pain occurs is in moving GUI code.
> Fortunately, several commercial Smalltalk dialect conversion tools exist.
> For example, I can run ObjectShare VisualSmalltalk GUI code *unmodified* in
> IBM's VisualAge by using a compatibility library (we sell one, BTW). I have
> been involved with quite a few VisualSmalltalk to VisualAge conversion
> efforts. Most of them were very straightforward. Moving from one Java IDE
> to another may be easier, but it is not unreasonable to do the same in
> Smalltalk (when and if the need arises).

This is reassuring.  But...it's still not clear to me how much developer
effort is involved going Smalltalk->Smalltalk.  After scanning c.o.s
for several months, based on posts there the effort doesn't seem as
seamless as you're asserting (I'm not claiming it is more difficult;
it's an honest inquiry).

Quote:
> > My experience differs.  Java vendors strive very hard to match the
> language
> > spec.

> They also strive to lock you into their IDEs through a variety of means.

Yes :-(

Quote:
> > The fact that you relied on obvious, proprietary IDE extensions does
> > not alter that point.

> Would you consider the GUI code generations to be obvious proprietary
> extensions? What if the code is 100% pure Java with no vendor library
> extensions? There is no standard for what a Java window definition should
> look like. All of the major IDEs can generate GUI code with no proprietary
> library references (although some of them make this difficult). None of
> them (that I know of) can make any sense out of code gen formats used by
> the other tools.

Your points are well-taken.  My personal philosophy is that GUI generators
are wildly overrated, and that in the end you pay a high price for perceived
ease of use up-front.  The "price" is usually obscure code-generator bugs,
incompatabilies across language upgrades, and vendor lock-in.  I don't
think this is unique to any given language.

Quote:
> -Eric

        -Mike


Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)


Quote:

> The toughest area in Java compatibilty is the GUI side, I agree.  But
> I think, perhaps, that you're exagerrating just how bad compatabilty
> is.  I run into problems occasionally (and I think Scrollbars are
> on everyone's hit-list), but it's the exception, not the rule.

I suspect that you are doing end-user Java GUI development and not trying
to create portable GUI class libraries (correct me if I'm wrong). We are
doing the latter or so our perspective is quite different. A huge amount of
our support/development effort is directed at fighting compatibility
exceptions in the Java GUI layer across various platforms, JDK levels and
browsers. When we put out a new release, we have *dozens* of combinations
that we have to test because all of them are subtly different. If you are
interested in the sorts of problems we have run into, feel free to scan
either or our support newsgroups at:

        news//nt1.netsmart.com/instantiations.go
        news//nt1.netsmart.com/instantiations.grid

Archives of older messages are available at:

        http//www.instantiations.com/go/gonews.zip

I would be happy to let you talk directly to one of our support folks if
you would like to hear about some of our "fun" first hand.

Quote:
> Outside of GUIs compatability is _extremely_ high.

I would generally agree.

Quote:
> > In all the respects that we care about, yes. Users of other Smalltalk
> > dialects will have a different set of criteria and may select a
different
> > Smalltalk dialect as their best choice. Any of the major Smalltalk
dialects
> > can be used to build almost anything you can imagine (at least in the
> > corporate MIS world). On the margin, different dialects may be better
for
> > different tasks.

> Do you see this as continuing indefinitely?

That different dialects may be better for different tasks? Yes.

Quote:
> This is reassuring.  But...it's still not clear to me how much developer
> effort is involved going Smalltalk->Smalltalk.  After scanning c.o.s
> for several months, based on posts there the effort doesn't seem as
> seamless as you're asserting (I'm not claiming it is more difficult;
> it's an honest inquiry).

Porting non-GUI code is generally considered to be easy. Porting GUI code
without an automated conversion tool would be quite painful. Porting GUI
code using an automated conversion tool is generally pretty easy. I don't
recall having seen many (any?) posts from folks complaining about problems
doing conversions using automated tools. The folks who have used our
automated tools have been quite happy with the results (references are
available <g>).

Quote:
> Your points are well-taken.  My personal philosophy is that GUI
generators
> are wildly overrated, and that in the end you pay a high price for
perceived
> ease of use up-front.  The "price" is usually obscure code-generator
bugs,
> incompatabilies across language upgrades, and vendor lock-in.  I don't
> think this is unique to any given language.

For a Java GUI builder to be truly useful, it needs to be flexible (e.g.,
adapt to different code gen styles and allow subclassing of Object, JFrame,
JPanel or any other suitable superclass), current (e.g., use up-to-date
language constructs - no JDK 1.02 style event models, thank you), IDE
neutral (e.g., be useable with any Java IDE and read/write their code gen
models as well as its own), bi-directional (e.g., allow the user to modify
the code by hand and have the changes reflected in the GUI editor),
extensible (e.g., use any beans or custom layout managers), intuitive
(e.g., it has to be easy to use), and powerful (e.g., include features like
morphing). As far as I know, none of the current crop of Java GUI builders
even comes close to this ideal. I guess we'll just have to build one... ;-)

-Eric



Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:



> > The toughest area in Java compatibilty is the GUI side, I agree.  But
> > I think, perhaps, that you're exagerrating just how bad compatabilty
> > is.  I run into problems occasionally (and I think Scrollbars are
> > on everyone's hit-list), but it's the exception, not the rule.

> I suspect that you are doing end-user Java GUI development and not trying
> to create portable GUI class libraries (correct me if I'm wrong). We are
> doing the latter or so our perspective is quite different. A huge amount of
> our support/development effort is directed at fighting compatibility
> exceptions in the Java GUI layer across various platforms, JDK levels and
> browsers. When we put out a new release, we have *dozens* of combinations
> that we have to test because all of them are subtly different. If you are
> interested in the sorts of problems we have run into, feel free to scan
> either or our support newsgroups at:

>         news//nt1.netsmart.com/instantiations.go
>         news//nt1.netsmart.com/instantiations.grid

> Archives of older messages are available at:

>         http//www.instantiations.com/go/gonews.zip

I'll check it out.

I have done some limited work in higher-level portable GUI libraries, but
nothing expansive.  The vast bulk of the problems I've seen have been
browser-related, most often in Netscape.  IMNSHO Netscape never even
came close to providing decent Java support, and alot of the bad rep
Java has gotten is attributable directly to them.  IE didn't go very
far with their support, either, but there at least seemed to be fewer
bugs.

I've never had serious problems outside of browsers (with Scrollbars
being a well known and damnable exception).

- Show quoted text -

Quote:
> I would be happy to let you talk directly to one of our support folks if
> you would like to hear about some of our "fun" first hand.

> > Outside of GUIs compatability is _extremely_ high.

> I would generally agree.

> > > In all the respects that we care about, yes. Users of other Smalltalk
> > > dialects will have a different set of criteria and may select a
> different
> > > Smalltalk dialect as their best choice. Any of the major Smalltalk
> dialects
> > > can be used to build almost anything you can imagine (at least in the
> > > corporate MIS world). On the margin, different dialects may be better
> for
> > > different tasks.

> > Do you see this as continuing indefinitely?

> That different dialects may be better for different tasks? Yes.

> > This is reassuring.  But...it's still not clear to me how much developer
> > effort is involved going Smalltalk->Smalltalk.  After scanning c.o.s
> > for several months, based on posts there the effort doesn't seem as
> > seamless as you're asserting (I'm not claiming it is more difficult;
> > it's an honest inquiry).

> Porting non-GUI code is generally considered to be easy. Porting GUI code
> without an automated conversion tool would be quite painful. Porting GUI
> code using an automated conversion tool is generally pretty easy. I don't
> recall having seen many (any?) posts from folks complaining about problems
> doing conversions using automated tools. The folks who have used our
> automated tools have been quite happy with the results (references are
> available <g>).

I feel it's unfortunate that any work needs to be done at all.  Particuarly
in the Smalltalk world, it's surprising to me that the market is fragmented
in this area.  

- Show quoted text -

Quote:
> > Your points are well-taken.  My personal philosophy is that GUI
> generators
> > are wildly overrated, and that in the end you pay a high price for
> perceived
> > ease of use up-front.  The "price" is usually obscure code-generator
> bugs,
> > incompatabilies across language upgrades, and vendor lock-in.  I don't
> > think this is unique to any given language.

> For a Java GUI builder to be truly useful, it needs to be flexible (e.g.,
> adapt to different code gen styles and allow subclassing of Object, JFrame,
> JPanel or any other suitable superclass), current (e.g., use up-to-date
> language constructs - no JDK 1.02 style event models, thank you), IDE
> neutral (e.g., be useable with any Java IDE and read/write their code gen
> models as well as its own), bi-directional (e.g., allow the user to modify
> the code by hand and have the changes reflected in the GUI editor),
> extensible (e.g., use any beans or custom layout managers), intuitive
> (e.g., it has to be easy to use), and powerful (e.g., include features like
> morphing). As far as I know, none of the current crop of Java GUI builders
> even comes close to this ideal. I guess we'll just have to build one... ;-)

Sounds fabulous to me.  And I agree - none of the Java GUI builders are
nearly flexible enough and open enough for hard-core work.

Quote:
> -Eric

        -Mike


Wed, 18 Jun 1902 08:00:00 GMT  
 Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

Quote:



> > The toughest area in Java compatibilty is the GUI side, I agree.  But
> > I think, perhaps, that you're exagerrating just how bad compatabilty
> > is.  I run into problems occasionally (and I think Scrollbars are
> > on everyone's hit-list), but it's the exception, not the rule.

> I suspect that you are doing end-user Java GUI development and not trying
> to create portable GUI class libraries (correct me if I'm wrong).

My impression is that the biggest problems involve heavyweight
components -- i.e. components that have a native peer. The java object
is a wrapper around a native object that has to be implemented in each
platform -- usually in C/C++ and that's why you get such differences in
behavior. Also, attempts to mix-and-match heavyweight and lightweight
basically just don't work, forget it... Anyway, if you avoid heavyweight
AWT, my sense of things is that java portability really does work pretty
well.

Or at least (anticipating niggling) lightweight components are MUCH MUCH
better in this respect than heavyweight and the distinction should be
clearly made in any discussion. Moreover, though it's not officially
stated, I think the use of the AWT heavyweight stuff is de facto
deprecated in new projects (aside from things like java.awt.Frame which
are unavoidable...).

Jonathan Revusky
--
Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 17 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Advanced C++ Programmer can't tolerate JAVA.

2. contracts, MI in Java (Re: Advanced C++ Programmer can't tolerate

3. Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

4. Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

5. Eiffel features in Java? (Re: Advanced C++ Programmer can't tolerate JAVA.)

6. contracts, MI in Java (Re: Advanced C++ Programmer can't tolerate JAVA.)

7. Cowboy Coders Wrongly Downplay Methodology (was: Advanced C++ Programmer can't tolerate JAVA.)

8. A C++/Java programmer's introduction to Objective Caml

9. Cellular automata benchmarks: Java vs C++ vs Java vs C++

10. Eiffel features in Java?

11. Eiffel features in Java?

12. Eiffel features in Java?

 

 
Powered by phpBB® Forum Software