From: mdj on
Paul Schlyter wrote:

> > !!! There's nothing unfortunate about it improving with age :) There
> > were a few examples of backwards compatibility being broken in the
> > early editions, but these issues are well and truly behind us.
> > Obviously if you write code that depends on new features, you break
> > compatibility old editions.
>
> .... I'm more annoyed with old code whith ceases to work with new JVM versions...
>
> Actually, I keep a copy of Nescape 4.7 in working condition (with its
> own, quite old, JVM), mostly to be able to browse web sites with
> applets which no longer run properly on modern web browsers.

There was a very deliberate fractioning introduced between Java 1.1 and
1.2 (which marks the beginning of the Java 2 plaftorm)

The primary reason for this was to divorce 1.2 onwards from the
compatibility issues introduced by Microsofts J++ virtual machine - it
became a serious problem that a web browser running standard Java 1.1
couldn't run many applets out there, as those applets relied on Win32
API calls via the Microsoft extensions. This, coupled with the fact
that it was extremely difficult to switch the VM in Internet Explorer
caused Sun to draw a compatbility line between the two versions, and
implement a different applet plugin mechansim so both could co-exist.

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.

> >> The qsort() function is *quite* portable ---- as are most other ANSI C
> >> library functions which do not access external hardware or OS services.
> >
> > Indeed C programs that do no I/O are more portable that those that do,
> > but they're also completely useless :-)
>
> I was talking about portable code, not necessarily about complete applications.
> Code doing no I/O can still be useful, as a library called by your own program.

Indeed. The language level portability issues remain, however, but yes
when developing libraries it is sometimes possible to avoid platform
specific API's. More often, you need to handle multiple cases when
developing portable C libraries.

> Btw in C you cannot write a program which do no output whatsoever. Even the
> minimal C program:
>
> int main()
> {
> return 42;
> }
>
> outputs a return code to the OS, which can be tested in shell scripts/etc.
> And if you remove the return statement, the required output will be garbage.

Hmm, I wasn't aware the standard actually required that an
implementation honour the return code, or program arguments for that
matter. Perhaps an implementation is required to provide a harness for
code conforming to the API. Admittedly though it's useless on systems
that don't implement such codes, but then platforms that don't do that
are pretty much now all obsolete.

In any case, we're talking about a value left on the stack at end of
program execution, which in my book doesn't constitute I/O

> One good thing about standards is that there are so many to choose among... :-/

And so many non-comforming implementations of those standards :-)

> ...but if I want to output the value to some terminal or file, I'd
> like the output to be A0 rather than FFFFFFA0 .... :-)

Of course, but formatted output is the responsibility of the API. Java
provides both C style (admittedly recently) and it's own 'OO' style I/O
facilities which can both accomplish that task very easily. If you're
relying on the default behavior to output things the way you want it,
then you're asking for trouble.

Ironically, a lot of features have been added in recent editions to
appease C programmers who wanted to do things the 'old' way. Most
notably was the addition of variable argument lists, which allows the
implementation of System.out.printf() :-)

> > I've actually implemented a C compatible expression parser. Leaving out
> > the unsigned types dramatically simplifies things.
>
> I believe you! Leaving out most operators too will make the parser even
> simpler.... :-)

:-) The operators are relatively easy. dealing with implicit conversion
between data types is much more frustrating, and a source of
inefficiency, as there's always more than one way to handle the
conversions, with one being more efficient than the other...

> ...or constants! In C++ a 'const' declared int (or float, or....) is
> really a constant and not merely a write protected variable. So you can
> do things like:
>
> const int arraysize = 1234;
> int array[arraysize];
>
> Doing this is illegal in C - there you *must* use a macro (or a literal
> integer constant).

Works fine in Java, though.

> > The compiler will inline the method for you.
> > The same rule applies to C++, where use of the preprocessor is
> > generally frowned upon. It's there for backwards compatibility.
>
> Even in C++, the preprocessor is useful for conditional compilation. You
> can't do that with methods..... The #pragma directove (an idea borrowed
> from Ada) can be quite handy too.

It's still frowned upon, in favour of using a constant plus
if/else/switch constructs to do conditional compilation. One big
advantage of this approach is that if you compile with debug turned on,
the optimiser won't remove the conditional code, which makes source
level debugging simpler.

Such preprocessor techniques are unnecessary in modern languages. One
frustrating side effect of using it in C++ is that it still has global
namespace.

> And C/C++ macros contain the # (stringize) operator, which converts a
> symbolic name to a string containing that name. You can't do that with
> methods either....

Facilities like this one are commonplace in languages that don't retain
type information at runtime. In Java, the .getName() class method
provides the same behavior, but better since it's evaluated at runtime
rather than compile time.

But then, many people want to treat Java as if it's C++ minus features,
rather than the very different language that it is.

Matt

From: Paul Schlyter on
In article <NtqdnZgXoZJereLZnZ2dnUVZ_vadnZ2d(a)comcast.com>,
Michael J. Mahon <mjmahon(a)aol.com> wrote:

> Paul Schlyter wrote:
>
> <snip>
>
>> The #pragma directove (an idea borrowed
>> from Ada) can be quite handy too.
>
> Actually, I believe that _pragma_ was borrowed from Algol 68,
> which must be the most influential least implemented language. ;-)

.....yep, the "latin" among programming languages: now dead but still
having a lot of influence on other, non-dead, languages.

> -michael
>
> Parallel computing for 8-bit Apple II's!
> Home page: http://members.aol.com/MJMahon/
>
> "The wastebasket is our most important design
> tool--and it is seriously underused."

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/
From: Linards Ticmanis on
Michael J. Mahon wrote:

> Actually, I believe that _pragma_ was borrowed from Algol 68,
> which must be the most influential least implemented language. ;-)

As they say, Algol was a great improvement on its successors. ;-)

--
Linards Ticmanis
From: Michael J. Mahon on
Linards Ticmanis wrote:
> Michael J. Mahon wrote:
>
>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>> which must be the most influential least implemented language. ;-)
>
>
> As they say, Algol was a great improvement on its successors. ;-)

Algol 60 introduced many great ideas, like block structure and
BNF syntax description.

Algol 68, with its meta-syntactic definition, served to clarify
a number of issues in language design, but ultimately confused
its non-theorist "market". I really liked the palindromic block
delimiters though ("do"-"od", "if"-"fi", etc.), and I used them
for a system implementation language ("proc"-"corp", "case"-"esac",
"struc"-"curts", etc.).

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?

So the following would be properly "bracketed" by the offside
rule:

if condition1
or condition2
then foo
blah
blah
else bar
blah
nextstatement
....


-michael

Parallel computing for 8-bit Apple II's!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."
From: Lyrical Nanoha on
On Fri, 2 Jun 2006, Michael J. Mahon wrote:

> Linards Ticmanis wrote:
>> Michael J. Mahon wrote:
>>
>>> Actually, I believe that _pragma_ was borrowed from Algol 68,
>>> which must be the most influential least implemented language. ;-)
>>
>>
>> As they say, Algol was a great improvement on its successors. ;-)
>
> Algol 60 introduced many great ideas, like block structure and
> BNF syntax description.
>
> Algol 68, with its meta-syntactic definition, served to clarify
> a number of issues in language design, but ultimately confused
> its non-theorist "market". I really liked the palindromic block
> delimiters though ("do"-"od", "if"-"fi", etc.), and I used them
> for a system implementation language ("proc"-"corp", "case"-"esac",
> "struc"-"curts", etc.).

You have if/fi and case/esac in the Bourne shell too. :) Looks weird
though.

> 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?

You'd like Python.

-uso.