Example where static variables are unavoidable... does it exist?

[TGOS]

I tend to look at this proposal as similar to "If all the chairs in
the world were abducted by aliens, would we survive?"

Yes, we would. So Java would survive without static, right? ;-)

I don't think you have convinced anyone there would be any benefit to
doing away with statics.

I don't plan to remove statics of Java. Statics are a fundamental part
of Java. But I'm currently creating my own OO programming language. It's
just a mind game of my own.

I want to create a VM based OO language. First I define what the VM can
do and later on the language, whereby multiple languages could generate
bytecode for the same VM (the language will not be tied to the VM as
strongly as in case of Java). The language has to be pure OO (no
primitive types for example) and limited to the minimal functionality
necessary for an OO language. Kinda like creating objects, send messages
between objects, store objects to variables.

Also, unlike the JVM, the compiler must be object aware. That means a
compiler (not byte, but bytecode to native code) knows what certain
methods of an object actually do. Since there are no primitives, the
class named Integer can't have a private variable to store an int for
example.

The following code:

int a = 5;
int b = 8;
int c = a + b;

should become

Integer a = new Integer(5);
Integer b = new Integer(8);
Integer c = a.add(b);

through the bytecode compiler. However, Integer has no real
implementation (as least not within the language itself). The native
compiler just knows that it has to reserve enough space for an int value
for ever Integer object and it knows that a.add(b) means that the int
values stored in the reserved space of a and b have to be added and the
result is put into another reserved space.

That way the language is not limited in functionality. It's always
possible to make the native code compiler aware of more classes (that
have no real implementation) and that way add new functionality to the
VM. The bytecode assembler of the VM will maybe consist out of 16
opcodes only (not 256 like in case of the JVM).

The JVM has no clean design here. +, -, *, / operations, as well as
shift operations of primitives are done directly within the assembler
bytecode (there is an opcode for these), while other math stuff, like
log, power, abs has to be done via static methods (which have no
implementation either, they are native).

And right now I'm trying to find out which functionality is really vital
for a OO VM. And I came across static parts and whether they are really
part of the OO concept and whether they are really necessary.

 

[Wojtek]

This is not a constant.
It is a macro for the pre-compiler.
Before the compiler actually ever sees the source code, all occurances
of HTML_NAME_PASSWORD are replaced by "pass".

A constant in C and C++ would be:

const int MAX_LENGTH = 255;

You are right of course. It's been too many years since I did any
serious work in C.

BTW, maximum length of what?

Because I dislike public variables.
Going by strict OO principles, all variables of an object are supposed
to be private (or protected) IMHO.

Well, going by strict definition, an identifier marked "final" in java
is not really a variable, since it cannot be changed (varied) during
runtime. So it is protected in a fashion.

Ok, I think I have made a case for some method of holding imutable
information which is potentially available to other code. Can we agree
on that?

The method of allowing access to that information is what you are
exploring.

In Java that method is "public final static" where, by convention, the
identifier is all upper case.

A smart compiler will take all references to the variable and replace
them with the actual value (or a direct reference to the variable,
similar to String literals as discussed above). This compiler
behaviour has been demonstrated by a lot of frustrated developers when
they make a change to their final variables which are not picked up in
other classes, UNTIL a full recompile has been done (see note at end).

Using the C example (const int MAX_LENGTH = 255 the variable
MAX_LENGTH must be globally accessable. So it must be declared in a
file which is included by every file which makes a reference to it.
Where you hate public variables, I hate global scope variables.

So you have the choice of using the common language method, or having
your code sprinkled with "magic values". Yes you can comment the
meaning of the values, but what if they change? Then you are forced to
either manually go though your code to find them, or using search to
locate your comment, then manually changing the value.

All this leads to potential errors through mis-keying, mis-spelling,
or otherwise getting the value wrong. And then you have a subtle bug
which is hard to track down.

 

[Michiel Konstapel]

I don't plan to remove statics of Java. Statics are a fundamental part

of Java. But I'm currently creating my own OO programming language. It's
just a mind game of my own.

I think you've sparked an interesting discussion. Keep asking questions!
HAND,
Michiel

 

[Dale King]

What I'm looking for is someone providing me with a problem, that I
can't solve without the usage of a static variable in Java, but that he
can solve using a static variable. If no such example exists, static
variables (useful or not) are no necessity, as they don't allow
programmers to do something that wouldn't also work without static
variables.

No, one can show you a problem that requires static variables and that
cannot be done without static variables. Static variables are not a
*necessity*. Object-oriented programming and even structured programming
languages like C are not a *necessity*. There is nothing I cannot do in
either of these that could not be done in basic assembly language.

I suggest you go read the first chapter of Thinking in Java (available for
download at bruceeckel.com). Here is one of the first chapters:

"All programming languages provide abstractions. It can be argued that the
complexity of the problems you're able to solve is directly related to the
kind and quality of abstraction. By "kind" I mean, "What is it that you are
abstracting?" Assembly language is a small abstraction of the underlying
machine. Many so-called "imperative" languages that followed (such as
FORTRAN, BASIC, and C) were abstractions of assembly language. These
languages are big improvements over assembly language, but their primary
abstraction still requires you to think in terms of the structure of the
computer rather than the structure of the problem you are trying to solve.
The programmer must establish the association between the machine model (in
the "solution space," which is the place where you're modeling that problem,
such as a computer) and the model of the problem that is actually being
solved (in the "problem space," which is the place where the problem
exists). The effort required to perform this mapping, and the fact that it
is extrinsic to the programming language, produces programs that are
difficult to write and expensive to maintain, and as a side effect created
the entire "programming methods" industry."

The issue is not whether some programming feature is necesssary, but whether
there value in the abstraction it provides. It has been proven that there is
no problem that you can do on a modern computer that cannot be done on a
Turing machine. The improvement over the history of programming is not in
providing new features that allow you to solve new problems that could not
be solved before (no one has found any yet), but in creating better and
better abstractions.

I think it is easy to show that there is value in the abstraction of having
data associated with a class of objects. It is not strictly necessary since
they are essentially global variables. But they allow more encapsulation and
lifetime control.

 

[TGOS]

You are right of course. It's been too many years since I did any
serious work in C.

Well, I recently had to. Don't do it. C sucks! ^_^;
Compare:

String s1 = "ABC";
String s2 = "DEF";
int i = 32;
String s3 = s1 + s2 + i;

To:

char *s1 = "ABC";
char *s2 = "DEF";
int i = 32;
char *s3;
asprintf(s3, "%s%s%d", s1, s2, i);
// ...
free(s3);

And that was still the easy way using asprintf (which is very slow). If
you just concat two strings, compare:

String s = s1 + s2;

to:

char *s = malloc(sizeof(char)
* (strlen(s1) + strlen(s2) + 1));
strcat(s, s1);
strcat(s, s2);
// ...
free(s);

And what I hates most about C is that you can't do that:

String s = new String("Whatever");
s = doSomethingWithAString(s);

As the following code doesn't work:

char *s = strdup("Whatever");
// strdup as replacement for dynamically created string
s = doSomethingWithAString(s);

As then you lose the reference to the first pointer stored in s and you
have a memory hole! Instead you must do something like that:

char *temp;
char *s = strdup("Whatever");
temp = s;
s = doSomethingWithAString(s);
free(temp);

BTW, maximum length of what?

Just an example.

Well, going by strict definition, an identifier marked "final" in java
is not really a variable, since it cannot be changed (varied) during
runtime. So it is protected in a fashion.

Well, it's an "unchangeable variable". I mean, in reality it could
change, but the bytecompiler as well as the JVM will both refuse to
compile/run code which does try to change it.

A smart compiler will take all references to the variable and replace
them with the actual value (or a direct reference to the variable,
similar to String literals as discussed above). This compiler
behaviour has been demonstrated by a lot of frustrated developers when
they make a change to their final variables which are not picked up in
other classes, UNTIL a full recompile has been done (see note at end).

Really? Sun's Javac does replace references to "public static final int"
with the actual value? I didn't know that. I thought this only happens
within the same class.

public class A {
public static final int VALUE = 32;

public void someMethod() {
int i = VALUE;
// VALUE is replaced with 32
}
}

public class B {
public void someMethod() {
int i = A.VALUE;
// VALUE is only reference to VALUE field of class A
}
}

Using the C example (const int MAX_LENGTH = 255 the variable
MAX_LENGTH must be globally accessable

Yes, but that's because C is no OO language and hence not a good example
methinks. C++ is OO, but most C++ code is full of "C code", as 90% of
all C code is also valid C++ code. This mixture of OO and non-OO code is
very error prone (as you people are mixing two completely different
programming concepts) and leads to many bugs in C++ programs.

Where you hate public variables, I hate global scope variables.

I hate global scope as well, but I can't avoid them in my C programs.
Otherwise every function would need to get 10 to 15 parameters and more,
which is a "calling overkill". Or I have to pack everything into
structures and pass these as arguments around, but dealing with
structures can make things even more complicated.

Honestly, without insulting anybody, but C is just a better assembler
(which is less bound to a specific CPU and offers advance structures
like different loops, switch and if statements; but still on the lowest
level) and C++ has no right to exist, as it's the cheap try to implement
an OO system on top of this assembler (basically you could emulate C++
using plain C only), it's not really fast (3 times slower than C, as OO
is more complex leads to more management overhead) and most software is
in fact still written in C, since when you plan to use pure C++, you
could as well choose a real OO language. C will survive for as long as
computer will survive (as software running on the lowest level either
have to be coded in C or directly in assembler), but C++ should get
replaced ASAP.

------------------
Note: This compiler behaviour only becomes evident when you are
compiling by hand, that is compiling the classes on the command line.
Any developmemt environment (IDE, such as Eclipse) which tracks
dependancies will automatically compile all the affected classes.
------------------------

Oh, I only compile by hand. I use IDE's just for code writing, meaning I
open single Java files and write their code, but I hate managing whole
projects via IDE's. And while JBuilder or Forte4Java are nice IDE's for
huge projects, they are plain overkill for what I'm writing.


So far this discussion can be summarized as:
Static fields or methods are not vital for an OO VM, you live without
them and easily code around them, but there are situations where they
are very useful. AFAIK (and I know very, very little about Smalltalk)
Smalltalk lacks the concept of static fields/methods, so I started a
thread in a Smalltalk programmer NG to see how they would be coding
around certain issues raised in this thread.


Thank you for your input!

 

[TGOS]

Then, I can break that by doing:

Table table = new Table();
Table tableClone = table.clone();
MyObject o1 = new MyObject(table);
MyObject o2 = new MyObject(table);

tableClone.modify(...);

Wouldn't break it.
o1 has a clone and o2 has a clone. tableClone is a clone as well and
table is the original. They all share the same buffer. Once you modify
tableClone, it will copy its internal data storage and the copy is
modified, the original data storage is still shared between table and
the o1 and o2 clone and stays unmodified.

String and StringBuffer work that way as well.
If you create a StringBuffer and call the toString() method, the
resulting String shares the same char[] buffer as your StringBuffer
(that's why calling toString() on a StringBuffer happens in almost no
time). Multiple Strings can be created that way, that all share the same
char[] buffer of your StringBuffer. But the second you modify the
StringBuffer, it will internally copy the char[] buffer (as it has
noted, that this buffer is shared with strings) and then modify the copy
only.

 

[TGOS]

I think you've sparked an interesting discussion. Keep asking questions!

ASA I got new questions, I'm going to ask them.
Right now I moved over to a Smalltalk NG to see what programmers have to
say there (as Smalltalk lacks the concept of static fields/methods).

 

[Wojtek]

Just an example.

Yes )

Really? Sun's Javac does replace references to "public static final int"
with the actual value? I didn't know that. I thought this only happens
within the same class.

public class A {
public static final int VALUE = 32;

public void someMethod() {
int i = VALUE;
// VALUE is replaced with 32
}
}

public class B {
public void someMethod() {
int i = A.VALUE;
// VALUE is only reference to VALUE field of class A
}
}

AFAIK it does. I read in another place and time a problem that someone
had when they changed the values of their statics and broke the
program. When they did a re-compile of the calling class it worked
again.

Honestly, without insulting anybody, but C is just a better assembler
(which is less bound to a specific CPU and offers advance structures
like different loops, switch and if statements; but still on the lowest
level) and C++ has no right to exist, as it's the cheap try to implement
an OO system on top of this assembler (basically you could emulate C++
using plain C only), it's not really fast (3 times slower than C, as OO
is more complex leads to more management overhead) and most software is
in fact still written in C, since when you plan to use pure C++, you
could as well choose a real OO language. C will survive for as long as
computer will survive (as software running on the lowest level either
have to be coded in C or directly in assembler), but C++ should get
replaced ASAP.

Amen to that. The language designed by a committee.

So far this discussion can be summarized as:
Static fields or methods are not vital for an OO VM, you live without
them and easily code around them, but there are situations where they
are very useful.

But, they are not really type safe as they rely on primitives. An int
is an int is an int.

It is a little heavy, but maybe replacing the static finals in a
single class with some sort of static class which only contains a
single immutable value:

public staticClassHolder MyChoices
{
public staticClassValue ChoiceA
{
value = 1;
}

public staticClassValue ChoiceB
{
value = 2;
}
}

So when the static is required to be used as a passed parameter, the
old way:
public String getValue( int a, int b )

Would look like:
public String getValue( MyChoices choice1,
MyChoices choice2 )

used like:
String s = getValue( MyChoices.ChoiceA,
MyChoices.ChoiceB );

With the test looking like:

if ( choice1.is(MyChoices.ChoiceA) )
// do something

This has two benefits:
- it is strongly typed. You CANNOT use any other type other than one
contained in MyChoices.
- you can change the value from an apperant int (value = 1) to a
String (value = "abc"), or you could mix value types. This _should_
required no more than a re-compile. So if you use the static value in
one of your own methods, and the type changes, you do not need to
change your code. Just re-compile.

AFAIK (and I know very, very little about Smalltalk)
Smalltalk lacks the concept of static fields/methods, so I started a
thread in a Smalltalk programmer NG to see how they would be coding
around certain issues raised in this thread.

If you can, could you summarize the replies here?

Thank you for your input!

I like to stretch my mind )

 

[Chris Uppal]

Really? Sun's Javac does replace references to "public static final
int" with the actual value? I didn't know that. I thought this only
happens within the same class.

In fact *all* references to final fields with values set by a compile-time
constant expression are *required* to be replaced by the constant value. From
the spec, section 13.1 "The Form of a Binary", page 253:

References to fields that are final and initialized
with compile-time constant expressions are resolved at
compile time to the constant value that is denoted.
No reference to such a constant field should be present
in the code in a binary file (except in the class or
interface containing the constant field, which will
have code to initialize it) [...]

Which, BTW, is not limited to *static* final variables (I admit, I'd thought it
was). But then, there'd be little point in a non-static final field with a
compile-time constant value (unless you are trying to eliminate statics, of
course ;-)

-- chris

 

[Timo Kinnunen]

Wouldn't break it.
o1 has a clone and o2 has a clone. tableClone is a clone as well
and table is the original. They all share the same buffer. Once you
modify tableClone, it will copy its internal data storage and the
copy is modified, the original data storage is still shared between
table and the o1 and o2 clone and stays unmodified.

I was thinking about your original example, in which the two objects
sharing a counter both wanted to modify it, without it being cloned.
This technique doesn't work there, because there, the objects need to
share a mutable object, whereas here, the objects share an immutable
object, which turns into a non-shared mutable object on modification.

 

[TGOS]

If you can, could you summarize the replies here?

I will.

I like to stretch my mind )

Me, too. That's why I'm doing this mind game in the first place.

 

[TGOS]

Which, BTW, is not limited to *static* final variables (I admit, I'd thought it
was).

This is interesting to know!
I never ran into that problem so far, so I didn't even know it exists.

 

[Randall R Schulz]

Invalid.Invalid,

I don't plan to remove statics of Java. Statics are a fundamental
part of Java. But I'm currently creating my own OO programming
language. It's just a mind game of my own.

First of all, if you want to create a new language, don't create a
language for a paradigm that's becoming mature, create one for a new
paradigm the for which best precepts are not yet so settled. E.g.,
look into aspect-oriented programming. Doing so will stand a better
chance of contributing both to the art and science of programming and
to your understanding of these fields.

It shounds like you've got some sort of dogmatic notion of
object-oriented "purity." Designing a language with such a religious
fervor is a sure way to produce something that at most one person
(you) will want to use.

Programming languages are engineering concepts--they need to satisfy
pragmatic concerns as much as principled ones.

I want to create a VM based OO language. First I define what the VM
can do and later on the language, whereby multiple languages could
generate bytecode for the same VM (the language will not be tied to
the VM as strongly as in case of Java). The language has to be pure
OO (no primitive types for example) and limited to the minimal
functionality necessary for an OO language. Kinda like creating
objects, send messages between objects, store objects to variables.

That is particularly backwards. Programming languages must serve the
needs of programmers (at least if humans are going to write programs
in this putative language). It's foolish to design a virtual machine
and let that dictate the language. You should design a language that
facilitates programming and then look for good ways of efficiently
realizing the execution mechanisms that can support what that language
promises to its programmers.

Also, unlike the JVM, the compiler must be object aware. That means
a compiler (not byte, but bytecode to native code) knows what
certain methods of an object actually do. Since there are no
primitives, the class named Integer can't have a private variable
to store an int for example.

It sounds like your language cannot be grounded in a real machine if
it cannot make use of object state.

It also sounds like you're conflating the compiler with the virtual
machine for which the compiler will generate code.

Perhaps you need to look into the principles of functional languages,
too, before embarking on your windmill-tilging.

The following code:

int a = 5; int b = 8; int c = a + b;

should become

Integer a = new Integer(5); Integer b = new Integer(8); Integer c =
a.add(b);

through the bytecode compiler. However, Integer has no real
implementation (as least not within the language itself). The
native compiler just knows that it has to reserve enough space for
an int value for ever Integer object and it knows that a.add(b)
means that the int values stored in the reserved space of a and b
have to be added and the result is put into another reserved space.

Integer (as in java.lang.Integer) is not a part of the Java language
per se, it's a part of the Java standard libraries. Java compilers
need not know anything about Integer that they don't need to know
about any other class. All they need is its (Java) source code.

That way the language is not limited in functionality. It's always
possible to make the native code compiler aware of more classes
(that have no real implementation) and that way add new
functionality to the VM. The bytecode assembler of the VM will
maybe consist out of 16 opcodes only (not 256 like in case of the
JVM).

Again, it sounds like you confuse what a virtual machine's role is in
the definition of a language vis. a vis. the roles of compilers and
libraries.

Also, extreme minimization of VM opcode counts is not a meaningful
criteria--it's more arbitrary dogma that appeals to you from some
entirely subjective reason.

The JVM has no clean design here. +, -, *, / operations, as well as
shift operations of primitives are done directly within the
assembler bytecode (there is an opcode for these), while other math
stuff, like log, power, abs has to be done via static methods
(which have no implementation either, they are native).

Correction: The JVM has no clean design here _that you understand_.

Java and its virtual machine are designed for real, stack-based,
register transfer architectures we use today. Modern CPUs provide
direct abstractions in their programming models for integers,
characters and floating point numbers. To ignore the special nature of
those data types would be foolish.

Perhaps some day computer architectures will be very different than
they are today and these observations will no longer hold. Then it it
might make sense to design virtual machines that don't afford a
special status for these primitive data types.

And right now I'm trying to find out which functionality is really
vital for a OO VM. And I came across static parts and whether they
are really part of the OO concept and whether they are really
necessary.

If you don't know the answer to that question, you need to write a lot
more programs before you start designing any programming langauges.

You've already gotten a very good explanation of necessity vs.
utility. Static fields are not necessary (objects are not necessary,
C-like structs are not necessary, only a stack, a tape and a
read/write head are necessary). Staic fields have distinct utility,
and are justified in a language design on that basis.


Randall Schulz

 

[TGOS]

First of all, if you want to create a new language, don't create a
language for a paradigm that's becoming mature, create one for a new
paradigm the for which best precepts are not yet so settled.

OO programming is far from being mature.

C++ is a mess (sorry, it just is, like any other pseudo-OO language,
e.g. PHP supports objects, but you can't really see PHP as an OO
language), Smalltalk is not useful for current application development
out of various reasons (it's rather rapid high level programming like a
macro in MS Word) and has a very programmer unfriendly syntax (compared
to BASIC, Pascal and C) and Java... well...

<RANT>

- Java is too slow! Java is a fast language, it certainly scores in the
top 10 of 100 languages and I guess it has the fastest VM of all
languages that are VM based and not statically compiled; but it could do
much faster most of the time, the CPUs offer more power than Java really
utilizes.

- Java wastes memory like hell! Re-code your Java code in another
language and save up to 90% memory. There is no logical reason why an OO
language must wastes so much more memory compared to non-OO languages.

- Java has no clean design! Everything is an object, except a
primitives. This leads to many problems of inconsistency throughout the
language and the Java API.

- The Java API offers code for almost everything you can think of... and
most of the time you don't need 90% of it! It's plain overkill and
wastes resources. It makes JVM downloads huge to receive unnecessary
code. Also there are strange relationships between packages (java.lang
needs classes from java.security, which needs classes form java.util and
so on; so you can't simply remove uneeded packages).

- The Bytecode language is inflexible! It has many unecessary opcodes
(256 are too many, Java could easily do with less than half of these)
and important opcodes are missing (to make use of raw CPU power). But
it's not easily possible to alter it, to replace it or to extend it.

- The native interface (JNI) sucks! It's slow, poor and there must be a
better way to connect a VM based language to the rest of the world.
Being able to easily access library functions, for example, of libraries
written in C is very important in some cases (even though it's not cross
platform compatbile, but see below). With JNI, you must write a C
library wrapper yourself, you can't just call functions of a library
directly from within Java.

- Java is not really platform independent! "Write once, run everywhere"
is a dream, an illusion. It doesn't work. Java code written for my
mobile phone won't run on my PC in a normal JVM. Why not? There is no
reason why it shouldn't! All this stupid editions stuff like J2SE, J2ME,
J2EE is completely unnecessary and all this stupid profile stuff, like
Set-Top-Box profiles and so on are a lot of talking about nothing. A
single VM could handle everything with an API that covers all devices
and situations, however no device has to support all of the API and not
the full API has to be present.

I do understand that nearly all of these limitations have nothing to do
with Java itself, they come from the JVM, not from the language. But so
far nobody has made an attempt to write a better JVM without all these
limitations. Especially the fact that they all try to be compatible to
Sun's JVM prevent that there is some real progress on these issues.

</RANT>


Everyone says "Can you do it any better?". Yes, I honestly think I can.
I think you can as well. Probably 10% of all regular posters in this
group could do it better. But there is no point in touching a running
system! Java works. It does its job (good or bad). Java left its traces
all over the place (not just in the real world, but also in the mind of
people). So I see no point in trying to improve Java (that's Sun's
task), Java wouldn't be Java anymore if I'd be trying to change it. Java
will survive, everything I criticized above will become better over the
years, one way or another, and my dream language may never even get
written in the first place.

E.g., look into aspect-oriented programming.

I did already. It's a lot of BLAH and very little behind it. Everything
AspectJ can do for example (aspect extension to Java) could be done in
Java directly, if Java would be designed more intelligent.

It shounds like you've got some sort of dogmatic notion of
object-oriented "purity."

Because it makes everything easier. It means the language has less
opcodes (that means less keywords or structures that programmers have to
memorize), the language is more flexible and can easily get extended on
the lowest (bytecode!) level.

That is particularly backwards. Programming languages must serve the
needs of programmers (at least if humans are going to write programs
in this putative language).

And that's what my language would do. It would offer programmers
possebilities unthinkable in Java. There is no need for a programmer to
look behind the scenes.

You still write:

int a = 10;
int b = 20;
int c = ((a + b) * (a | b)) >> 3;

That this will be all objects and methods after running through the
bytecode compiler is nothing you as programmer had to worry about! And
it won't slow down execution speed either, as the JNI compiler can
easily transform it back to native (NON-OO) machine code (so after JIT
no objects are involved anymore).

It sounds like your language cannot be grounded in a real machine if
it cannot make use of object state.

Sorry, I don't understand what you are trying to say here.

It also sounds like you're conflating the compiler with the virtual
machine for which the compiler will generate code.

I'm currently designing the VM, not the language. The workflow is:

Source-Code ==Bytecode-Compiler==> Bytecode ==Compiler==> Machine-Code

I only define the Bytecode and how classes, methods and so on are stored
and referenced right now. Later on I will define certain classes and how
the compiler makes machine code out of them. The bytecode compiler can
stay undefined, because what language is actually used to write the
source-code doesn't matter to the VM.

Here is how it could look:

Source-Code:
int a = 10;
int b = 20;
int c = a + b;

Bytecode:
load_const 10
new Integer
pop_object 1
load_const 20
new Integer
store_object 2
push_object 1
call_method add(Integer, Integer)
push_object 3

Machine code:
mov ax, [dx + 4]
mov 10, [ax]
mov bx, [dx + 8]
mov 20, [bx]
add cx, [ax]
add cx, [bx]
mov cx, [dx + 12]


Since the Compiler knows that Integer is just a wrapper Object for an
"int" value (which does not exist, as there are only objects, no
primitives) and because it knows how to express every method of Integer
directly in assembler, it an switch back from OO and eliminate all
object creation/cleanup and method calls.

Integer (as in java.lang.Integer) is not a part of the Java language
per se, it's a part of the Java standard libraries.

And that's how my language will work.
Per default, the language can't do any more than creating objects,
calling methods and accessing variables. All functionality comes only
from the standard classes "known" to the compiler.

Different companies could all use the same language, teach their native
compiler other classes and that way add whatever "functionality" to the
language they would like to have. I would just define some standard sets
of behaviors, which implement everything Java "knows" (as you wrote).
This is how to handle numbers, arrays (which are objects, too) and so
on.

Again, it sounds like you confuse what a virtual machine's role is in
the definition of a language vis. a vis. the roles of compilers and
libraries.

No, I don't. I just break the classic concepts of these. For me, the
language is the Bytecode assembler, not the source code transformed into
the bytecode assembler.

Java and its virtual machine are designed for real, stack-based,
register transfer architectures we use today.

1st) Java is all stack based, which is exactly how CPUs don't work, they
are register based. JIT has to transfer between both worlds.

2nd) Look at Smalltalk! You may learn something new.

Modern CPUs provide
direct abstractions in their programming models for integers,
characters and floating point numbers.

Fine for them. But the Bytecode language doesn't have to. After all CPUs
don't run bytecode directly, there's still a layer of abstraction that
can transform objects into primitve types. See my example code above.

 

[Roedy Green]

- The Java API offers code for almost everything you can think of... and
most of the time you don't need 90% of it! It's plain overkill and
wastes resources. It makes JVM downloads huge to receive unnecessary
code.

I think you are wrong here. There is no way it could contain only what
YOU need and nothing else. Downloading is not a major penalty. Class
files are tiny. So long as classes are small enough that you don't
have to LOAD code you don't need, it does not hurt to have the kitchen
sink available.

One of the big advantages of the kitchen sink approach is that code is
easier to read. Everyone uses the same standard classes rather than
reinventing the wheel a million different ways.

 

[Randall R Schulz]

On Wed, 10 Sep 2003 00:40:01 GMT Randall R Schulz

...

2nd) Look at Smalltalk! You may learn something new.

Smalltalk is the first object-oriented language I encountered.
Probably when you were still in kindergarten.

Get back to us when your grand, smarter-than-thosu schemes are a reality.

By then we'll probably have Java 3.0. Or possibly a next-generation
language for you to criticize.


Randall Schulz

 

[Roedy Green]

The native interface (JNI) sucks! It's slow, poor and there must be a
better way to connect a VM based language to the rest of the world.
Being able to easily access library functions, for example, of libraries
written in C is very important in some cases (even though it's not cross
platform compatbile, but see below). With JNI, you must write a C
library wrapper yourself, you can't just call functions of a library
directly from within Java.

JNI is too low level an interface for most purposes. There is a major
impedance mismatch in the two languages, so all that complexity is
necessary. Some people have been working to rectify the ease of use
problem by creating schemes to generate all the JNI bubblegum for you.
See http://mindprod.com/jgloss/jni.html

A native library to get at the native OS API would cover most of the
need for JNI. That would leave just the sliver who use it for raw
speed. The JNI interface adds so much overhead, you really have to
make up for it to make the game worth the candle.

 

[Roedy Green]

There is no
reason why it shouldn't! All this stupid editions stuff like J2SE, J2ME,
J2EE is completely unnecessary

If you don't define various core subsets, how have you any hope of
WORA when everything is optional? It would be like writing SQL.

 

[Roedy Green]

Everyone says "Can you do it any better?". Yes,

Don't use the JVM. Use a native compiler. See
http://mindprod.com/jgloss/nativecompiler.html

 

[Chris Uppal]

TGOS,

I disagree with virtually everything Randall Schulz said, and on the whole
agree with your point of view (with some reservations). One way to think of
what you are trying to do is to design a object engine, where the objects and
the engine between them define the runtime semantics of *any* language that is
implemented on top of those objects. I.e. the syntax of the language is
largely unimportant, but the behaviour of the objects is key.

If that's the route that you are going then you are at some risk of
re-inventing* Smalltalk. On which subject:

Smalltalk is not useful for current application development
out of various reasons (it's rather rapid high level programming like
a macro in MS Word) and has a very programmer unfriendly syntax
(compared to BASIC, Pascal and C)

Bullshit like this -- I'm sorry, I can think of no more accurate term -- is a
poor way to repay the people (myself included) over on comp.lang.Smalltalk who
are trying to help you understand the language.

Anyway, I'd advise you to read up more on the implementation techniques behind
modern Smalltalk (and similar languages such as Self and S# ), some of which
have been "borrowed" by fast JVM implementers, otherwise you are liable to skew
your design simply by not realising the options available to you, and the
state-of-the art in the clean vs. efficient trade-off.

-- chris

[*] not that "re-inventing" is a criticism in this context -- you have said
that your aim is personal learning, not the creation of a new system for
everyone else to use.