eerie Java-BASIC (partially OT)

[Stefan Ram]

BASIC was the first programming language I learned and the
second programming language I was giving classes for (the
first one being Pascal).

In the next week, I will give my first VB class. So - for
preparation - I did have a look at some VB source code.
And I had an eerie feeling when reading the following part,
thinking: This is actually Java, just with a BASIC syntax!

If ret.StartsWith("-") Or ret.StartsWith("/") Then Throw New Exception(...)

I mean, »String#startsWith« and »throw new Exception ...« are
not part of the classic BASIC, but surely are part of Java!

(But then, one can also dispute that VB actually /has/ a BASIC
syntax: There are no line numbers, it does not understand
LET, GOSUB nor »PRINT 1,2;3«. And of course, there is no
»MAT«, »DEF FN...« or READ/DATA. So it's Java with a made-up
syntax, which possibly partially resembles BASIC.)

Well, Java surely is influential. Maybe the
programming-language landscape will slowly converge to some
set of common features/classes and syntax.

 

[Arne Vajhøj]

BASIC was the first programming language I learned and the
second programming language I was giving classes for (the
first one being Pascal).

In the next week, I will give my first VB class. So - for
preparation - I did have a look at some VB source code.
And I had an eerie feeling when reading the following part,
thinking: This is actually Java, just with a BASIC syntax!

If ret.StartsWith("-") Or ret.StartsWith("/") Then Throw New Exception(...)

I mean, »String#startsWith« and »throw new Exception ...« are
not part of the classic BASIC, but surely are part of Java!

(But then, one can also dispute that VB actually /has/ a BASIC
syntax: There are no line numbers, it does not understand
LET, GOSUB nor »PRINT 1,2;3«. And of course, there is no
»MAT«, »DEF FN...« or READ/DATA. So it's Java with a made-up
syntax, which possibly partially resembles BASIC.)

Well, Java surely is influential. Maybe the
programming-language landscape will slowly converge to some
set of common features/classes and syntax.

If you with VB means VB.NET then you are absolutely correct.

VB.NET is C# with VB syntax and C# is close to a superset of Java.

And the .NET library is also rather close to the Java library.

Anders Hejlsberg worked on MS Java before he started working
on .NET and C#.

Arne

 

[Arne Vajhøj]

If you with VB means VB.NET then you are absolutely correct.

VB.NET is C# with VB syntax and C# is close to a superset of Java.

And the .NET library is also rather close to the Java library.

Anders Hejlsberg worked on MS Java before he started working
on .NET and C#.

Note that this also somewhat imply that you should not
expect a general convergence in languages/libraries as
these similarities have a very specific explanation.

Arne

 

[Lew]

Note that this also somewhat imply that you should not
expect a general convergence in languages/libraries as
these similarities have a very specific explanation.

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

But the designer and ecosystem stemming from C# does go a long way to explain
such close similarities.

 

[Roedy Green]

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

Long time ago at Univac they decided they wanted to redo all their
compilers with a common core and common optimiser.

Microsoft did the same thing. The low level convergence means it is
cheap to add features to a language that are already supported in the
core. So it looks from the high level like languages are converging.
It also tends to make it expensive for a language to have a quirky way
of implementing some feature. It tends to shed those.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

 

[Arne Vajhøj]

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

It is obviously a good name.

But there are other good names.

begin with
start is
first is
has prefix

etc.

But the designer and ecosystem stemming from C# does go a long way to
explain such close similarities.

Difficult not to assume some inspiration.

Arne

 

[Arne Vajhøj]

Long time ago at Univac they decided they wanted to redo all their
compilers with a common core and common optimiser.

Microsoft did the same thing. The low level convergence means it is
cheap to add features to a language that are already supported in the
core. So it looks from the high level like languages are converging.
It also tends to make it expensive for a language to have a quirky way
of implementing some feature. It tends to shed those.

I know that Digital did this.

But MS?

I can only think of 2 widely used MS compilers that generates
native code: C/C++ and VB. And I have never heard that they use
the same backend.

For .NET languages then there should not be much backend as most of the
backend work has been delegated to the CLR JIT.

Arne

 

[BGB]

If you with VB means VB.NET then you are absolutely correct.

VB.NET is C# with VB syntax and C# is close to a superset of Java.

generally, yes.

but, a person could try to argue that they are "totally different", say
because of using "namespace" and "using" rather than "package" and
"import", and ":" in class definitions instead of "extends" and
"implements", ...

however, these are likely minor differences (many are primarily
cosmetic, and some others could conceivably be made to work on the JVM
as well).

And the .NET library is also rather close to the Java library.

Anders Hejlsberg worked on MS Java before he started working
on .NET and C#.

yeah, pretty much.

there is a lot of overlap, although to me it looks like in some cases
things were simplified and merged vs Java, for example, in Java there
are a lot of classes for file IO with only minor variations, whereas in
..NET a smaller number of classes fill a similar role.

there are also many cases where the classes have the same names, and
many methods with the same names and arguments (although using
FirstLetterCaps rather than camelCase, ...).


but, there are many differences as well.

 

[BGB]

It is obviously a good name.

But there are other good names.

begin with
start is
first is
has prefix

Prefix Compare
....


or, hell, they could have just mapped a bunch of C like or C++ like APIs
onto .NET instead.

"fopen"/"fread"/"printf"/... anyone?

"if(s1.strcmp(s2)==0)"?

....

etc.


Difficult not to assume some inspiration.

especially when many of the other library classes and methods are
considered as well.

it seems unlikely that MS would independently reinvent many "nearly
identical" classes, with the primary difference often being mostly that
"java" and "java.lang" were replaced by "System", ...

 

[Lew]

generally, yes.

but, a person could try to argue that they are "totally different", say
because of using "namespace" and "using" rather than "package" and "import",
and ":" in class definitions instead of "extends" and "implements", ...

however, these are likely minor differences (many are primarily cosmetic, and
some others could conceivably be made to work on the JVM as well).

"namespace" and "using" are significantly different from 'package' and
'import' in semantics.

yeah, pretty much.

there is a lot of overlap, although to me it looks like in some cases things
were simplified and merged vs Java, for example, in Java there are a lot of
classes for file IO with only minor variations, whereas in .NET a smaller
number of classes fill a similar role.

..Net emanated from J++ back when.

J++ got Microsoft slapped in court for violating Java trademark rules.

They rebranded it and changed certain things, improving them with some of the
non-compliant enhancements they'd given J++, and more.

So the lineage is direct.

there are also many cases where the classes have the same names, and many
methods with the same names and arguments (although using FirstLetterCaps
rather than camelCase, ...).

That is still camel case.

but, there are many differences as well.

"If I have seen farther than other men, it is because I have stood on the
shoulders of giants."
- Sir Isaac Newton

 

[BGB]

"namespace" and "using" are significantly different from 'package' and
'import' in semantics.

well, hence the comment "some others could be made to work on the JVM":
unlike the differences in class syntax, "namespace" and "using" also
differ some in terms of how they work, so would be a little harder to
fit onto the JVM as it exists, but could probably be done via a little
compiler trickery.

the main difference would likely be the potential loss of a 1:1 mapping
between source-files and output class files.


I am not really intending to argue here about how similar or different
"namespace" and "using" are from "package" and "import" though.

.Net emanated from J++ back when.

J++ got Microsoft slapped in court for violating Java trademark rules.

They rebranded it and changed certain things, improving them with some
of the non-compliant enhancements they'd given J++, and more.

So the lineage is direct.

pretty much.

in many places, there are similarities, but also a lot of differences.

That is still camel case.

fair enough.

"If I have seen farther than other men, it is because I have stood on
the shoulders of giants."
- Sir Isaac Newton

yep.

 

[Lew]

well, hence the comment "some others could be made to work on the JVM":
unlike the differences in class syntax, "namespace" and "using" also differ
some in terms of how they work, so would be a little harder to fit onto the
JVM as it exists, but could probably be done via a little compiler trickery.

the main difference would likely be the potential loss of a 1:1 mapping
between source-files and output class files.

You cannot lose what doesn't exist to start with. Source files in the usual
Java implementation (i.e., one that uses files) have a 1-to-many relationship
with classes (and therefore with class files in file-based implementations).
This applies for both nested classes and top-level classes. (In a certain very
loose sense, an inner class exists separately for each instance of its
containing class.)

I am not really intending to argue here about how similar or different
"namespace" and "using" are from "package" and "import" though.

There's no room for argument. They are exactly as similar and different as
they are. The degree of similarity and difference is objectively verifiable,
as the terms are publicly and transparently defined.

I took exception to your characterization of the differences between keywords
"namespace" and 'package' and between "using" (the statement, not the
directive) and 'import' as "likely minor". Definitions of "minor" vary, but in
my world, "nearly completely different" is not minor. (To be fair, the C#
"using" directive is rather similar to the Java 'import', but the "using"
statement is quite different. The "using" statement is similar to Java's new
try-with-resources.)

There is no doubt that "namespace" and "using" could be made to work on the
JVM, for a language that uses those constructs. Java might move in the
"namespace" direction itself with the proposed module semantics. As for
"using", I don't see that coming to Java soon, but maybe. It might even be
part of modules, too; I haven't read up on those yet. (I don't see anything
recent coming out of this effort.)

<http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html>
<http://openjdk.java.net/projects/modules/>

 

[Lew]

As for "using", I don't see that coming to Java soon,

Oops. As a matter of fact, I see it coming to Java in the past.

 

[Gene Wirchenko]

On 6/2/2012 12:41 PM, Lew wrote:
[snip]

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

It is obviously a good name.

But there are other good names.

begin with
start is
first is
has prefix

etc.

Or for that matter, left().

[snip]

Sincerely,

Gene Wirchenko

 

[BGB]

You cannot lose what doesn't exist to start with. Source files in the
usual Java implementation (i.e., one that uses files) have a 1-to-many
relationship with classes (and therefore with class files in file-based
implementations). This applies for both nested classes and top-level
classes. (In a certain very loose sense, an inner class exists
separately for each instance of its containing class.)

fair enough.

what I meant was more like:
you have Java source file in a given path with a given base name;
it is compiled;
it results in a class file in the same path with the same base name
representing the contained class (except in cases where there may also
be additional output files).

if the language were using a different structure, then the compiler
output would more often be in different paths with different names from
the source files.

There's no room for argument. They are exactly as similar and different
as they are. The degree of similarity and difference is objectively
verifiable, as the terms are publicly and transparently defined.

I took exception to your characterization of the differences between
keywords "namespace" and 'package' and between "using" (the statement,
not the directive) and 'import' as "likely minor". Definitions of
"minor" vary, but in my world, "nearly completely different" is not
minor. (To be fair, the C# "using" directive is rather similar to the
Java 'import', but the "using" statement is quite different. The "using"
statement is similar to Java's new try-with-resources.)

I was never talking about:
"using(object)" or similar.
yes, this is "almost completely different" from import.


I meant solely the "using", as in:
namespace foo {
using bar;
...
}

where, functionally:
package foo;
import bar.*;

is at least vaguely similar to the above (apart from their relations to
compiler and loader behavior, ...).

There is no doubt that "namespace" and "using" could be made to work on
the JVM, for a language that uses those constructs. Java might move in
the "namespace" direction itself with the proposed module semantics. As
for "using", I don't see that coming to Java soon, but maybe. It might
even be part of modules, too; I haven't read up on those yet. (I don't
see anything recent coming out of this effort.)

<http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html>

<http://openjdk.java.net/projects/modules/>

dunno really...

would have to look into it all a bit more to be more certain.
(quick skim of "modules", seems like it is dealing with an altogether
different problem).


but, there is ActionScript3 which does things like this:
package foo.bar {
import baz;
...
}

so, it is sort of like a hybrid...

 

[Lew]

fair enough.

what I meant was more like:
you have Java source file in a given path with a given base name;
it is compiled;
it results in a class file in the same path with the same base name
representing the contained class (except in cases where there may also
be additional output files).

if the language were using a different structure, then the compiler

Well, that's not actually part of the Java language. It exists only in current file-
based implementations of it like the Reference Implementation.

There is nothing in the Java Language Specification that requires that file-
based scheme, or any file-based scheme. Read the introduction of Chapter 7.
It's barely mentioned, only to say that Java bytecode can live in files or databases,
and that tools might require some conventions.

I suspect if we find a way to store bytecode in other than files or databases
that the stewards of Java wouldn't blink.

output would more often be in different paths with different names from
the source files.

That's not an aspect of other languages, either, but of their tools.

Regardless, in Java there is no requirement that file names match class
names, nor even that files be used at all.

I was never talking about:
"using(object)" or similar.

Fair enough.

yes, this is "almost completely different" from import.


I meant solely the "using", as in:
namespace foo {
using bar;
...
}

where, functionally:
package foo;
import bar.*;

is at least vaguely similar to the above (apart from their relations to
compiler and loader behavior, ...).
True.


dunno really...

would have to look into it all a bit more to be more certain.
(quick skim of "modules", seems like it is dealing with an altogether
different problem).


but, there is ActionScript3 which does things like this:
package foo.bar {
import baz;
...
}

so, it is sort of like a hybrid...

The current Java ecosystem of packages, JARs, WARs and EARs
works well enough, apparently, or the modules proposal would
have shown some life in the last five or more years. They're
saying it is in the hopper for Java 8, but they used to say it'd
be in Java 7. Apparently demand hasn't been high enough to
accelerate it.

 

[Arne Vajhøj]

generally, yes.

but, a person could try to argue that they are "totally different", say
because of using "namespace" and "using" rather than "package" and
"import", and ":" in class definitions instead of "extends" and
"implements", ...

however, these are likely minor differences (many are primarily
cosmetic, and some others could conceivably be made to work on the JVM
as well).

The other way is easier. J# proved that.

Arne

 

[Arne Vajhøj]

"namespace" and "using" are significantly different from 'package' and
'import' in semantics.

I would consider them very similar.

What are the difference in semantics you think of?

.Net emanated from J++ back when.

J++ got Microsoft slapped in court for violating Java trademark rules.

They rebranded it and changed certain things, improving them with some
of the non-compliant enhancements they'd given J++, and more.

So the lineage is direct.

I don't think rebranded is accurate.

I don't think J++ and .NET share any code and should be considered
two very distinct projects.

But obviously a MS "Java" and a MS Java-like language like C#
must have shared some IP.

Arne

 

[Arne Vajhøj]

On 6/2/2012 12:41 PM, Lew wrote:
[snip]

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

It is obviously a good name.

But there are other good names.

begin with
start is
first is
has prefix

etc.

Or for that matter, left().

[snip]

left is

Just left will give associations to extracting the left most
n characters.

Arne

 

[Lew]

Lew wrote: [snip]

Yes, like that library designers tend to see a need for the same
functionality, e.g., eliciting String prefixes, and they tend to use the
obvious English-like names, e.g., "starts with".

It is obviously a good name.

But there are other good names.

begin with
start is
first is
has prefix

etc.

Or for that matter, left().

[snip]

left is

Just left will give associations to extracting the left most
n characters.

"left[most]" and "startWith" are not the same across all locales.

So while "prefix" is semantically equivalent to the proposed "startsWith"
(assuming the natural-language meaning), "left" would have to be a different
method.