**FIRST EMAIL**/Java and Orbit Balls *****JAVA DISCUSSION***

[Pjohn1959]

Greetings Teams:

In the 2010 season, FRC teams will have the option of programming their robot in Java. The addition of Java as a programming language option is the culmination of work by Worcester Polytechnic Institute (WPI) and researchers from the Sun SPOT project at Sun Microsystems Laboratories. To learn more as you wait for the 2010 season to begin visit [ http://www.sunspotworld.com/frc/Welcome.html ]http://www.sunspotworld.com/frc/Welcome.html and [ http://first.wpi.edu/FRC/frc-programming.html ]http://first.wpi.edu/FRC/frc-programming.html.$@# We’ll be updating both locations as details are finalized.

If you are planning to hold an off season event or host a demonstration of your robot over the summer, you might want some extra game pieces. Used orbit balls (the ones that survived championship) are available for purchase starting today here [ http://logoloc.com/first/ ]http://logoloc.com/first/ Quantities are limited. If you are borrowing a FIRST field for your off season event, please remember that game pieces are not included in the loan.

Go Teams!

[Pjohn1959]

How much better is JAVA going to be than Lab view?

Is it easier to use?

[EricVanWyk]

How much better is JAVA going to be than Lab view?

Is it easier to use?

I think it is easier to make a fair comparison between C++ and Java than LabVIEW and Java. LabVIEW/[Java or C++] arguments are really more a matter of preference.

For FRC robotics, I prefer LabVIEW. For my neural-networks research, Java was the clear choice.

[Uberbots]

Yuck, java. The lack of pointers is a major turn-away for me.

However, for those high schools that offer AP computer science, the fact that the robot can now be programmed in java sorta bridges the learning gap a bit.

[Jared Russell]

Yuck, java. The lack of pointers is a major turn-away for me.

However, for those high schools that offer AP computer science, the fact that the robot can now be programmed in java sorta bridges the learning gap a bit.

What is it that you want to do with pointers that Java's pass by reference system can't do exactly?

[The Lucas]

What is it that you want to do with pointers that Java's pass by reference system can't do exactly?

Pointer arithmetic. It can be useful if used properly. However, I wouldn't encourage students new to C++ to use pointer arithmetic on the robot, unless of course, you want them to experience the frustration of the dreaded "Seg Fault".

[Jared Russell]

Pointer arithmetic. It can be useful if used properly. However, I wouldn't encourage students new to C++ to use pointer arithmetic on the robot, unless of course, you want them to experience the frustration of the dreaded "Seg Fault".

Proper pointer arithmetic can result in small and efficient implementations of some data structures and algorithms, but given (a) the scope of a typical FIRST program and (b) the fact that we now have hardware and compilers that often get the job done just as fast and without the difficult-to-debug errors, I would probably expand "students new to C++" to "just about anyone without a really convincing reason". ::ouch:: :yikes:

[Chris27]

Pointer arithmetic. It can be useful if used properly. However, I wouldn't encourage students new to C++ to use pointer arithmetic on the robot, unless of course, you want them to experience the frustration of the dreaded "Seg Fault".


char *ptr = malloc(SIZE);


ptr + i is equivalent to &ptr[i]. Both cases boil down to just a load effective address instruction. Besides the obvious that Java hides the virtual address of all values in the symbol table, I don't see how you are missing anything by not being able to explicitly use pointer arithmetic. The point of pointer arithmetic is to compute the address of an element in an array. the "[]" operator retrieves that element and many people find this interface more intuitive. There is no performance advantage of using pointer arithmetic and there is nothing you can't do with the "[]" that you can do with pointer arithmetic (as the "[]" operator just encapsulates pointer arithmetic).

[The Lucas]

char *ptr = malloc(SIZE);


ptr + i is equivalent to &ptr[i]. Both cases boil down to just a load effective address instruction. Besides the obvious that Java hides the virtual address of all values in the symbol table, I don't see how you are missing anything by not being able to explicitly use pointer arithmetic. in an array. the "[]" operator retrieves that element and many people find this interface more intuitive. There is no performance advantage of using pointer arithmetic and there is nothing you can't do with the "[]" that you can do with pointer arithmetic (as the "[]" operator just encapsulates pointer arithmetic).

[SIDE RANT] I think you are missing the point :D (sorry for the pun). The point of pointer arithmetic is to compute the address of an element (the array data structure is optional). If you can get that address by simply adding to a pointer (stored in a register) that is more efficient than computing that address by loading a symbol and adding the result of a multiplication (indexing an array using a variable).[/SIDE RANT]

I actually used a bit of pointer arithmetic this year to make a simple circular buffer for Camera Report Structures. Of course I could make a circular buffer class in Java too. Again, I am not recommending pointer arithmetic or saying it's vital, I am just saying it can be useful, simple and intuitive.

My real concern with Java is not the pointer stuff but rather the runtime performance. Java uses just in time (JIT) compilation and garbage collection which should add additional (non deterministic) load to the programs run (of course I need to read more about how theses features are implemented). That being said, I think additional language options are a good thing and all of my programing students are taught Java (not C) in high school for the AP exam.

[Alan Anderson]

[SIDE RANT] I think you are missing the point :D (sorry for the pun). The point of pointer arithmetic is to compute the address of an element (the array data structure is optional). If you can get that address by simply adding to a pointer (stored in a register) that is more efficient than computing that address by loading a symbol and adding the result of a multiplication (indexing an array using a variable).[/SIDE RANT]

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

[AustinSchuh]

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

But, at least in C, the size of the structure is a known quantity at compile time, so I would imagine that most of the time that multiplication can be eliminated by the compiler. And then on top of that, sometimes the multiplication will be by a power of 2, so the compiler will use a cheap shift operation.

[Chris27]

[SIDE RANT] I think you are missing the point :D (sorry for the pun). The point of pointer arithmetic is to compute the address of an element (the array data structure is optional). If you can get that address by simply adding to a pointer (stored in a register) that is more efficient than computing that address by loading a symbol and adding the result of a multiplication (indexing an array using a variable).[/SIDE RANT]


And as I stated in my earlier post, both cases boil down to a simple lea instruction in assembly

See, here is a small piece of code I just wrote.


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr = array + i;
11
12 return 0;
13 }


and its assembly


0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 20 sub $0x20,%rsp
8: bf 28 00 00 00 mov $0x28,%edi
d: e8 00 00 00 00 callq 12 <main+0x12>
12: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
16: c7 45 ec 00 00 00 00 movl $0x0,0xffffffffffffffec(%rbp)
1d: 83 7d ec 09 cmpl $0x9,0xffffffffffffffec(%rbp)
21: 7f 19 jg 3c <main+0x3c>
23: 8b 45 ec mov 0xffffffffffffffec(%rbp),%eax
26: 48 98 cltq
28: 48 c1 e0 02 shl $0x2,%rax
2c: 48 03 45 f8 add 0xfffffffffffffff8(%rbp),%rax
30: 48 89 45 f0 mov %rax,0xfffffffffffffff0(%rbp)
34: 48 8d 45 ec lea 0xffffffffffffffec(%rbp),%rax
38: ff 00 incl (%rax)
3a: eb e1 jmp 1d <main+0x1d>
3c: b8 00 00 00 00 mov $0x0,%eax
41: c9 leaveq
42: c3 retq


Alternate code


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr = &array[i];
11
12 return 0;
13 }


its assembly


0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 20 sub $0x20,%rsp
8: bf 28 00 00 00 mov $0x28,%edi
d: e8 00 00 00 00 callq 12 <main+0x12>
12: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
16: c7 45 ec 00 00 00 00 movl $0x0,0xffffffffffffffec(%rbp)
1d: 83 7d ec 09 cmpl $0x9,0xffffffffffffffec(%rbp)
21: 7f 19 jg 3c <main+0x3c>
23: 8b 45 ec mov 0xffffffffffffffec(%rbp),%eax
26: 48 98 cltq
28: 48 c1 e0 02 shl $0x2,%rax
2c: 48 03 45 f8 add 0xfffffffffffffff8(%rbp),%rax
30: 48 89 45 f0 mov %rax,0xfffffffffffffff0(%rbp)
34: 48 8d 45 ec lea 0xffffffffffffffec(%rbp),%rax
38: ff 00 incl (%rax)
3a: eb e1 jmp 1d <main+0x1d>
3c: b8 00 00 00 00 mov $0x0,%eax
41: c9 leaveq
42: c3 retq



Absolutely no difference whatsoever.

[Alan Anderson]

But, at least in C, the size of the structure is a known quantity at compile time, so I would imagine that most of the time that multiplication can be eliminated by the compiler. And then on top of that, sometimes the multiplication will be by a power of 2, so the compiler will use a cheap shift operation.

This does not describe a difference between array indexing in Java and pointer arithmetic in C.

[The Lucas]

The efficiency is not what you suggest it is. Pointer arithmetic adds the result of a multiplication too: addition and subtraction are scaled by the size of the structure pointed to.

But, at least in C, the size of the structure is a known quantity at compile time, so I would imagine that most of the time that multiplication can be eliminated by the compiler. And then on top of that, sometimes the multiplication will be by a power of 2, so the compiler will use a cheap shift operation.

And as I stated in my earlier post, both cases boil down to a simple lea instruction in assembly

See, here is a small piece of code I just wrote.


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr = array + i;
11
12 return 0;
13 }


and its assembly


0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 20 sub $0x20,%rsp
8: bf 28 00 00 00 mov $0x28,%edi
d: e8 00 00 00 00 callq 12 <main+0x12>
12: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
16: c7 45 ec 00 00 00 00 movl $0x0,0xffffffffffffffec(%rbp)
1d: 83 7d ec 09 cmpl $0x9,0xffffffffffffffec(%rbp)
21: 7f 19 jg 3c <main+0x3c>
23: 8b 45 ec mov 0xffffffffffffffec(%rbp),%eax
26: 48 98 cltq
28: 48 c1 e0 02 shl $0x2,%rax
2c: 48 03 45 f8 add 0xfffffffffffffff8(%rbp),%rax
30: 48 89 45 f0 mov %rax,0xfffffffffffffff0(%rbp)
34: 48 8d 45 ec lea 0xffffffffffffffec(%rbp),%rax
38: ff 00 incl (%rax)
3a: eb e1 jmp 1d <main+0x1d>
3c: b8 00 00 00 00 mov $0x0,%eax
41: c9 leaveq
42: c3 retq


Alternate code


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr = &array[i];
11
12 return 0;
13 }


its assembly


0000000000000000 <main>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 48 83 ec 20 sub $0x20,%rsp
8: bf 28 00 00 00 mov $0x28,%edi
d: e8 00 00 00 00 callq 12 <main+0x12>
12: 48 89 45 f8 mov %rax,0xfffffffffffffff8(%rbp)
16: c7 45 ec 00 00 00 00 movl $0x0,0xffffffffffffffec(%rbp)
1d: 83 7d ec 09 cmpl $0x9,0xffffffffffffffec(%rbp)
21: 7f 19 jg 3c <main+0x3c>
23: 8b 45 ec mov 0xffffffffffffffec(%rbp),%eax
26: 48 98 cltq
28: 48 c1 e0 02 shl $0x2,%rax
2c: 48 03 45 f8 add 0xfffffffffffffff8(%rbp),%rax
30: 48 89 45 f0 mov %rax,0xfffffffffffffff0(%rbp)
34: 48 8d 45 ec lea 0xffffffffffffffec(%rbp),%rax
38: ff 00 incl (%rax)
3a: eb e1 jmp 1d <main+0x1d>
3c: b8 00 00 00 00 mov $0x0,%eax
41: c9 leaveq
42: c3 retq



Absolutely no difference whatsoever.

Since I'm done my work for the day, I'll continue this rant. What I (and I think Austin too) am getting at is this example (in same style as Chris' examples):


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr = array;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr++;
11
12 return 0;
13 }


That is different and removes the need for the shift left op (since as Austin said the sizeof(int) is known at compile time and can just be added). Cant do that without explicit pointers. If the multiplication by type size is bothersome you can use an unsigned int and typecast it to a pointer. Also useful if you have an array of structs and are only working with same element in each struct (you can just add the size of the struct to the pointer).

Plus explicit pointers make functions like swap (commonly used in bubblesort simple) simpler using C pass by reference. Again not vital, just something that gets abstracted away in a higher level language.

[Alan Anderson]

Since I'm done my work for the day, I'll continue this rant. What I (and I think Austin too) am getting at is this example (in same style as Chris' examples):


1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr = array;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr++;
11
12 return 0;
13 }


That is different and removes the need for the shift left op (since as Austin said the sizeof(int) is known at compile time and can just be added). Cant do that without explicit pointers. If the multiplication by type size is bothersome you can use an unsigned int and typecast it to a pointer. Also useful if you have an array of structs and are only working with same element in each struct (you can just add the size of the struct to the pointer).

I don't understand the point (!) of your example. What part of it should I focus on? None of it appears to show me a reason for preferring to use explicit pointers.

Plus explicit pointers make functions like swap (commonly used in bubblesort simple) simpler using C pass by reference...

Isn't pass by reference exactly what Java lets you do in such cases? I guess I'm completely failing to understand what you're trying to explain here.

[The Lucas]

I don't understand the point (!) of your example. What part of it should I focus on? None of it appears to show me a reason for preferring to use explicit pointers.


I generated assembly for both of the examples with the relevant instructions bolded



1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr = array + i;
11
12 return 0;
13 }




.L2:
cmpl $9, -12(%ebp)
jg .L3
movl -12(%ebp), %eax
sall $2, %eax
addl -4(%ebp), %eax
movl %eax, -8(%ebp)
leal -12(%ebp), %eax
incl (%eax)
jmp .L2
.L3:



1 #include <stdlib.h>
2
3 int main()
4 {
5 int *array = malloc(10 * sizeof(int));
6 int *ptr = array;
7 int i;
8
9 for(i = 0; i < 10; i++)
10 ptr++;
11
12 return 0;
13 }




.L2:
cmpl $9, -12(%ebp)
jg .L3
leal -8(%ebp), %eax
addl $4, (%eax)
leal -12(%ebp), %eax
incl (%eax)
jmp .L2
.L3:

So 4 instructions are necessary for ptr = array + i; and only 2 instructions for ptr++; in this assembly language.


Isn't pass by reference exactly what Java lets you do in such cases? I guess I'm completely failing to understand what you're trying to explain here.

I Googled "java swap" and this site (http://www.cs.utsa.edu/~wagner/CS2213/swap/swap.html) explains it pretty well. Basically when you pass by reference to a function in Java it gives the function a new (different) reference to the object and there is no way to change the original reference in the passing function. In C++, the pointer is like an absolute reference (memory location) that is the same everywhere and you can even use pointers to pointers (no references to references in Java).

[Chris27]

ptr = array + i;[/B] and only 2 instructions for ptr++; in this assembly language.

So what's your point? Of course an expression that contains multiple variables will generally be more complex then an expression that contains a single variable. ptr = (&(ptr[0])) + 1 will again compile to the same assembly. Array indexing is just an encapsulation for pointer arithmetic as I explained earlier. Any pointer arithmetic expression will have a matching array index expression and both of these expressions will compile to the exact same instructions.


I Googled "java swap" and this site (http://www.cs.utsa.edu/~wagner/CS2213/swap/swap.html) explains it pretty well. Basically when you pass by reference to a function in Java it gives the function a new (different) reference to the object and there is no way to change the original reference in the passing function. In C++, the pointer is like an absolute reference (memory location) that is the same everywhere and you can even use pointers to pointers (no references to references in Java).

If you want to change a reference to an object, just have the method return a new reference. If you want a series of references, just encapsulate the references in objects. If you absolutely need to have access to the virtual address of an object, then Java just isn't the right language for the job.

Here is swap with references:


public class MyInt {

int data;
public MyInt(int x)
{
this.data = x;
}

public static void swap(MyInt a, MyInt b)
{
a.data ^= b.data;
b.data ^= a.data;
a.data ^= b.data;
}

}

[The Lucas]

ptr = (&(ptr[0])) + 1 will again compile to the same assembly.

You can't dereference (&) and do pointer arithmetic like that in Java.


Array indexing is just an encapsulation for pointer arithmetic as I explained earlier. Any pointer arithmetic expression will have a matching array index expression and both of these expressions will compile to the exact same instructions.

There is no matching array index expression for this:

ptr = 365;


Array indexing requires a symbol (base of array) and a type (size of element). When an integer can be cast to a pointer, pointer arithmetic can be done without an array.


If you want to change a reference to an object, just have the method return a new reference. If you want a series of references, just encapsulate the references in objects. If you absolutely need to have access to the virtual address of an object, then Java just isn't the right language for the job.

Here is swap with references:


public class MyInt {

int data;
public MyInt(int x)
{
this.data = x;
}

public static void swap(MyInt a, MyInt b)
{
a.data ^= b.data;
b.data ^= a.data;
a.data ^= b.data;
}

}


I know you can create a new class, a similar example was on the page I linked. I just said it was simpler in C. Creating new classes or returning multiple references doesn't sound simple to me.

Again, I understand both languages and the reasons why Java doesn't allow explicit pointers (source of bugs, reference counting for garbage collecting, sercurity, etc..).

Lets revisit how this whole conversion happened (with me paraphrasing)
Billy: Yuck Java. Pointers ftw :D
Jared: What cant you do with Java references?
Me: Pointer Arithmetic.
Jared: Granted, but you better have a good reason.
<Long posts involving example code by Chris, me and Alan>
I thought twice before pressing Submit Reply on my first post because I knew it wouldn't be my last on this thread;) Programming debates are interesting (for me atleast) but time consuming. Maybe I should have just let Billy reply or learned from C++ vs LV threads.

[Alan Anderson]

You can't dereference (&) and do pointer arithmetic like that in Java.
Right. The whole discussion here is based on the lack of pointer arithmetic in Java. But I'm still trying to find out why some think that pointer arithmetic is more efficient than using arrays. My understanding is that they compile to exactly the same thing, since in C a[i] is just syntactical sugar for *(a+i). I used to confuse people by writing i[a] instead, which gives exactly the same result.
There is no matching array index expression for this:
ptr = 365;

Without significant context, I'm at a loss to understand why you'd want to write it. With the exception of using memory-mapped I/O, I have yet to see any examples anywhere where using absolute pointers gives any improvement in efficiency over using arrays.

[Bharat Nain]

Right. The whole discussion here is based on the lack of pointer arithmetic in Java. But I'm still trying to find out why some think that pointer arithmetic is more efficient than using arrays.


More importantly, how much does it matter in our application? What difference will it make?

[Jared Russell]

More importantly, how much does it matter in our application? What difference will it make?

Because if you don't use pointer arithmetic, you can't be a real programmer (http://www.pbm.com/~lindahl/mel.html). :cool:

(I know that's not Brian's argument, but it is a good excuse to post one of my all time favorite programming urban legends)

[Greg Needel]

I split this conversation into 2 threads into a java discussion and an orbit ball one.

[The Lucas]

I split this conversation into 2 threads into a java discussion and an orbit ball one.

Sorry for the extra work Greg but it was bound to happen.

Right. The whole discussion here is based on the lack of pointer arithmetic in Java. But I'm still trying to find out why some think that pointer arithmetic is more efficient than using arrays.

It is clear I haven't been a targeting my statements well.

Alan, to show that pointer arithmetic can be more efficient than array indexing, I used ptr++ (cant use in Java) instead of array indexing in Chris' example loop. The generated assembly showed:

So 4 instructions are necessary for ptr = array + i; and only 2 instructions for ptr++; in this assembly language.

Basically when stepping though an array, you can avoid a multiply(or shift left) op that is need to multiply the index variable by the sizeof that type by simply adding the sizeof to a pointer each time. Incrementing a pointer in a loop is the only pointer arithmetic that I regularly use and the ptr can be even be used as the loop control variable eliminating i.

So basically I am saying (since my first post here) is pointer arithmetic (that can be done in C not Java) can be slightly more efficient in some situations. Nothing major that will make a significant difference in our robot code. Can we agree on that?


My understanding is that they compile to exactly the same thing, since in C a[i] is just syntactical sugar for *(a+i). I used to confuse people by writing i[a] instead, which gives exactly the same result.


Exactly all array indexing is pointer arithmetic. However, not all pointer arithmetic is array indexing. More on that next



Without significant context, I'm at a loss to understand why you'd want to write it. With the exception of using memory-mapped I/O, I have yet to see any examples anywhere where using absolute pointers gives any improvement in efficiency over using arrays.

I accidentally stuck my explanation in the next Chris quote, I fixed it, this is how it should have read

ptr = 365;

Array indexing requires a symbol (base of array) and a type (size of element). When an integer can be cast to a pointer, pointer arithmetic can be done without an array.


As you said, memory map I/O is the only use I can think of for that expression. However, that wasn't even meant to be a practical example. It was just meant provide an simple example of pointer arithmetic that didn't have a matching array index expression to refute Chris' statement:

Array indexing is just an encapsulation for pointer arithmetic as I explained earlier. Any pointer arithmetic expression will have a matching array index expression and both of these expressions will compile to the exact same instructions.



Because if you don't use pointer arithmetic, you can't be a real programmer (http://www.pbm.com/~lindahl/mel.html). :cool:

(I know that's not Brian's argument, but it is a good excuse to post one of my all time favorite programming urban legends)

Great story :cool:

[EricVanWyk]

More importantly, how much does it matter in our application? What difference will it make?

Bharat just won this thread.

An instruction cycle here or there makes zero difference in the face of the larger picture. If you want to have a truly useless argument, just remember that our new processor is pipelined AND has a double dispatch with multiple ALU elements.

So while you are all optimizing the instructions, I'll be working on what I want the code to do.


As a point of interest, I know someone who wrote his own graphical programming language that compiles to something that is on average twice as fast as C for embedded power and motion control applications.

[Foster]

An instruction cycle here or there makes zero difference in the face of the larger picture. If you want to have a truly useless argument, just remember that our new processor is pipelined AND has a double dispatch with multiple ALU elements.

Right. We now have CPU cycles and memory space to burn, so a cycle here and a cycle there does not make that much difference.

So while you are all optimizing the instructions, I'll be working on what I want the code to do.
I get calls on a regular basis to "make it run faster." I always ask "Does it run correctly now?" since there is no reason to optimize a program that does not work.

As a point of interest, I know someone who wrote his own graphical programming language that compiles to something that is on average twice as fast as C for embedded power and motion control applications.
There are two optimizations here. The custom language is focused to help solve motion control applications. C is a general purpose language, an electronic "hammer" so to speak.

The second is that there is most likely a set of libraries that he uses for the down and dirty interfaces. He optimized them to work with his target platform.

Speed in Java the last few years has come from:

Improved VM processing - the actual runtime environment of the system
Improved "code generation" by the compiler
Improved library functions. By far the biggest speed pickups has been in the optimization of data structures in the system. Sorted lists are about 150% faster due to algorithm improvements (no longer the bumble sort) which then reflects back into the application.

You saw the same things with C and the IFI controller. You could roll your own code to do all the functions, but most of us took Kevin Watson's or the WPI library. Those key functions had been optimized first for "they work" then for "make them fast."

If you optimize the algorithm you seldom have to bit fiddle to make it faster.

[Uberbots]

What is it that you want to do with pointers that Java's pass by reference system can't do exactly?

Before i answer this, wow what a discussion this simple pointer thing turned into.

Anyway, it just bothers me that java turns the idea of pointers from a more numerical approach to an object-oriented approach. I like knowing that the variable i am passing into a function is explicitly a pointer, not something determined by java. Its also bothersome that for primitive datatypes such as int's an entirely different datatype (Integer) is required if you want to pass it by reference into a function (i know there is a system to go around this but god knows how much overhead it incurs, along with the garbage collection of the implicit object).

I'm a C man. i need to know what is happening with my code at all times. It helps (me) with debugging and low-level optimizing a lot. :]

also: double/triple/quad/etc pointers.

[Wetzel]

Our programming mentor is excited, because his AP classes use Java. It never hurts to give the school a really obvious reason why the time commitment is beneficial now.


Wetzel

[GeorgeTheEng]

I'm a C man. i need to know what is happening with my code at all times. It helps (me) with debugging and low-level optimizing a lot. :]


In my experience, when pointers are no longer part of the equation... There is a LOT less debugging that ever needs to be done. And the debugging that does need to be done is usually simplier. When code crashes there is a traceable route to it rather then having a line of code in a random unrelated location in a separate thread give unidentifiable errors in the code running at this moment.

Granted the rules with Java references can get odd at times as well.

Honestly, working on a team where the school has no programming courses at all, I welcome being able to work with the kids using an industry standard language that does not involve having to address pointers and pointer arithmetic. Labview is not bad, but I see it as a niche product. C++ and Java have a much wider user base.

[Alan Anderson]

I'm a C man. i need to know what is happening with my code at all times.

This is a truism. When you use C, particularly when you use pointers, you must have a constant deep understanding of exactly what your code is doing. A whole category of bugs is possible that only the programmer is capable of tracking down and dealing with.

When you don't have the option of using pointers, you can usually trust that the compiler is keeping track of things for you appropriately. Debugging is a lot easier when your tools can show you how things are going wrong.

[Uberbots]

When you use C, particularly when you use pointers, you must have a constant deep understanding of exactly what your code is doing.

And i do. So whats the problem?

[Jared Russell]

And i do. So whats the problem?

The problem is that far fewer people have the deep understanding of what the code is really doing than write C code. An expert C programmer is a formidable force. But a novice C programmer can really make a mess. High level languages and compilers help to limit the damage of the novice while approaching the same "performance" marks of carefully crafted C code.

This is one of many reasons why I would much rather do robot programming in Java, as very few high school students are experts in any language.

[Uberbots]

The problem is that far fewer people have the deep understanding of what the code is really doing than write C code. An expert C programmer is a formidable force. But a novice C programmer can really make a mess. High level languages and compilers help to limit the damage of the novice while approaching the same "performance" marks of carefully crafted C code.

This is one of many reasons why I would much rather do robot programming in Java, as very few high school students are experts in any language.

Point taken.

I still believe that its better to teach from the low level up to give the kids an understanding of why the segfault happens or what that mysterious null pointer was supposed to be, rather than being totally unaware of the problem at all. Then again, that may be too much for a 6 week FIRST season in which case i would agree that java (or labview) is the better option.

[Jared Russell]

Point taken.

I still believe that its better to teach from the low level up to give the kids an understanding of why the segfault happens or what that mysterious null pointer was supposed to be, rather than being totally unaware of the problem at all. Then again, that may be too much for a 6 week FIRST season in which case i would agree that java (or labview) is the better option.

I agree on all counts.

[Bharat Nain]

While it is great to have the programmers learn low level everything and get accustomed with all this, it is simply not as practical. There are those students who are very interested and will take the effort to learn it all during their 4 years in high school. Then there are those teams who can barely find a programmer and if someone can figure out how to write code in java, they can have a working robot. We have the options to suit the needs of different people and teams. You should also consider that there are those who will join a team in their senior year of high school and like programming in Java. Based on that, they will decide to take up CS/IT as their degree. Most students are clueless about their future coming out of high school. THAT is the point. We are not here to graduate engineers and scientists from high school. That's what college is for.

[Adam Y.]

This discussion just reminded me of this:
http://sourceforge.net/projects/robocode
Enjoy.

[RoboMaster]

I have learned a lot about LabVIEW through FRC and through use with my Mindstorms NXT kit at home and I absolutely love it for many reasons that I don't want to write a 5000 character essay on. The other two programmers on my team gripe and complain and say it's "ok" and they still use it. They say it can't make games, do everything, and it's not something they're used to (one is an avid C programmer, the other has had experience with Java). I agree that LabVIEW seems to be designed for hardware interaction (exactly what we are doing) and not so much making software, but it does an extremely good job at it in my opinion.

But the one thing that we all agree on is that Java stinks. I haven't had much experience with programming as much as the other programmers on my team, but they say they've had bad experiences with Java, calling it "the worst programming language ever". From what they've told me, I can see where they're going. But I'd stick with LabVIEW no matter what, anyway. :)

[Guy Davidson]

But the one thing that we all agree on is that Java stinks. I haven't had much experience with programming as much as the other programmers on my team, but they say they've had bad experiences with Java, calling it "the worst programming language ever"

Really? I guess we weren't reading the same thread then. I could go back and start quoting other opinions, but what you're saying here is flat-out wrong.

I could start listing reasons as to why Java is a great alternative to C/C++ and LabVIEW, but most of those arguments have already been listed. From my own experience, Java is fun to write with, easy to debug (especially with a nice IDE), and is very versatile.

Please don't come out bashing and making mindless statements, especially when they're based on inaccurate summaries and third-hand stories.

I'd also suggest you try to write anything serious in assembly language before you bash Java as the "worst programming language ever." In the end it was loads of fun, and a great challenge, but oh what a pain :)

(Note: I currently program in Java for a living, and have spent time in the past writing in C/C++, python, and have experimented with assembly and ruby)

[RoboMaster]

Someone gave me a "negative reputation mark" or whatever for my post above, and when I checked up on the thread, I saw that someone else had posted in complaint against my overly negative attitude towards Java. Well, even though this thread is old, I'd like to say I'm sorry and that you two are totally correct. I didn't mean to post a slam against Java, but I should have thought twice before posting that. Especially since Java is widely used and I don't even have much experience with it. All I know is what those other two programmers have told me, which is of Java's weak points and their bad experiences.
So sorry to anybody who thought I was being a snob; I sure had it coming, didn't I.