From: mdj on

Paul Schlyter wrote:

> > Still, this didn't solve the whole problem, as many standard 1.1
> > Applets wouldn't run on Microsofts VM, which unfortunately shipped
> > standard with Windows, making Java look a lot worse than it actually
> > was.
> Which explains why Sun later prohibited Microsoft to implement its own JVM.
> That's when Microsoft switched to C#.

Yes. Things have been a lot better since then.

> That's nice! But it's also a hole in the fairly strict type checking
> in Java.

How so?

> ...well then the choice is easy: do it the most efficient way... :-)
> Of course there's some work in ensureing that they way you chose really
> was the most efficient.

There's yet to be any evidence that it's less efficient, and perhaps
some to indicate it's more so.

Anyway when faced with choice these days I go with the most
maintainable way. CPU power is cheap and plentiful.

> > It's still frowned upon, in favour of using a constant plus
> > if/else/switch constructs to do conditional compilation.
> That causes a problem: a source line which shouldn't be used in some
> particular environment can also be a syntax error in such an environment.

Exactly. The point is to avoid these situations by design. There's no
good reason to have machine dependencies within the same class in a OO
language. That's poor design.

> I dondt think one can talk about namespaces at all regarding macros in
> preprocessors. The preprocessor does not know what a namespace is. It
> hardly knows anything about the underlying source language. Heck, you
> can even replace reserved words with macros -- try to do THAT using
> the global namespace in a normal way.....

Why? Namespaces are a natural extension present in most modern
languages to avoid collisions that occur frequently in larger programs.
Macro's being redefined by included headers from an unrelated piece of
code is a real problem in C/C++ programs.

Of course, most good programmers utilise some form of poor-mans
namespacing by prefixing their preprocessor names with something that's
likely to be unique. This illustrates the point that the feature would
be useful.

> Is there a .setName() method too? If there is, one might be able to
> do quite interesting things with it.... :-)

Heh. Some OO languages implement a 'Pose' facility to allow you to do
this. It's possible to get the same effect in Java, but constructors
make it difficult. Don't get me started on constructors ;-)

> > But then, many people want to treat Java as if it's C++ minus features,
> > rather than the very different language that it is.
> These peope are wrong of course. Java resembles C++ only
> superficially, mostly by having similar syntax. But the semantics
> under that syntax is quite different, and more resembles
> "strait-jacket languages" like Pascal --- of course with a lot of
> features not available in Pascal. I usually think of Java as "the
> UCSD Pascal of our times": it has portable object code which must be
> run on a virtual machine. However, it is object oriented, it is net
> aware, and it is 32-bit rather than 16-bit. And Java is also a
> subsystem, not a whole OS like UCSD Pascal was.

Straightjacket is a little harsh :-) If we're comparing Java to C++,
it's really C++ that's the straightjacket language, by forcing you to
make all binding decisions at compile time.

Semantically speaking Java is a lot more like Smalltalk than C++. It's
a nice bridge between the dynamic world and the static world.

To me it's more like this: C++ is C, but with stricter type checking,
and object oriented like extensions, staying within the realm of a
static language with no runtime system or typing.

Java is C++ like in syntax, but is underneath a 'real' OO language,
allowing dynamic binding, loading, etc, within a C++ like typing
system. It's actually far more flexible than it first appears, but you
have to think like an OO programmer.

The only time the typing system annoys me is when I want to do
something REALLY OO, with some fairly heavy reflection. The lack of
syntactic sugar in the reflection API is at times most tedious, and
results in code being very hard to read where it should be simple and

To this day, I don't miss the implicit conversion between integer and
boolean type that C/C++ programs use. This is the only area where
Java's type checking is stricter. Other differences are feature
removals as mentioned previously


From: mdj on

> Just like certain Java-programmers who consider Interface and Class
> synonymous... (That's what the I in API means - Interface).

:-) I've not met anyone who misses that distinction yet. Although one
must be careful when using the word Interface within Java as it can be
easily misconstrued - a libraries interface need not use interfaces.

From: mdj on

Paul Schlyter wrote:

> I fully agree with that! The API is the specification, not the
> implementation. There might be some parts of the library which
> can be called by outside code but wasn't intended to be called in
> that way - they're not part of the API, even though they're part of
> the library!

Of course, if you use features of a library that aren't part of it's
documented interface you'll eventually be cursed by almost everybody.

Hey, we're almost back on topic, considering this was supposed to be
about 'undocumented opcodes' :-) Of course, my feelings on using
undocumented library calls is much the same as my feelings on
undocumented opcodes. They are very similar problems.


From: mdj on

Michael J. Mahon wrote:

> Many years later, I think that the "offside rule" for delimiting
> blocks simply by indentation is a very nice approach. Why on
> earth should white space, the most significant characteristic of
> text to the human eye, be ignored by most programming languages?

Once you bed down the definition of white space, you've committed the
language to a certain aesthetic form quite unnecessarily. People have
been arguing for *years* over such aestheic issues in most programming
languages without any clear consensus. Perhaps one day we'll reach one,
but beauty being in the eye of the beholder I somewhat doubt it :-)

An interesting language in this regard is Ruby, who's syntax is such
that BOTH whitespace or statement delimiters may be used, depending on
what is felt most appropriate to the developer.

Actually the first language I've used seriously where carriage returns
are considered statement terminators and I've not immediately disliked
the language. In fact, Ruby allows some beautifully concise code. The
language is so flexible in fact, that you can override almost any facet
of it, in effect making it very simple to construct domain-specific
languages, or sublanguages, to better suit the problem domain. Lots of


From: Michael J. Mahon on
Kent Friis wrote:
> Den Fri, 02 Jun 2006 21:53:25 -0700 skrev Michael J. Mahon:
>>Many years later, I think that the "offside rule" for delimiting
>>blocks simply by indentation is a very nice approach. Why on
>>earth should white space, the most significant characteristic of
>>text to the human eye, be ignored by most programming languages?
> For the same reason that comments, the most human readable text found
> in a program, are ignored by the programming language. Whitespace is
> an important part of making the program more readable.
> A programming language that prevents me to use white space to make
> code readable (because that would change what the code does) is just
> as bad as one that prevents me from writing a comment where needed
> (Actually, Visual Basic .NET does that in certain places. Yuck).

If you think about it, the same things that make it more readable
to a human can make it more "parsable" by a computer--and you'll
be much less likely to have a piece of code look different from
what it means.

Comments are still fine, and can also be delimited by the off-side
rule in many cases (though that isn't necessary). A comment should
never repeat the meaning of a statement at the level of the language,
but should, generally, give the meaning of a statement or group of
statements at a higher level of abstraction.


Parallel computing for 8-bit Apple II's!
Home page:

"The wastebasket is our most important design
tool--and it is seriously underused."