SRB2... Based on Java?

[Gemini Spark]

I've been taking a programming class lately, and I'm starting to notice that most of the programming techniques I have been learning could replicate some feature in SRB2. For example, the Scanner class is mainly about user input, which is similar to the talk feature in SRB2 netgames. So, does SRB2 use object-oriented programming provided by Java?

 

[Fawfulfan]

Well, SRB2 was programmed in C, so, uh...no?

Java and many other programs are based heavily on C and C++, so it's common to see similarities between programs made with C and programs made with a lot of other languages.

 

[Liliam]

Everything you can do in C, you can do in Java... except muck around with pointers.

Everything you can do in Java, you can do in C... except objects. Closest thing you have are structures, and methods which take one of those structures as an argument. Which... is basically a DIY object.

Java runs on a closed virtual machine, though, while C has direct access to the machine. Java hides everything low-level to the programmer. It's essentially a lot easier and promotes better programming overall, but you can't cut any corners to save time and space as you'd be able to in C.

But Java is platform-indepentent, unlike C... however Java is an interpreted language, while C is compiled into machine code.

In essence, most large scale projects that require optimal performance and great optimization are programmed in C or C++, but Java is a "tidier" language that's good for setting newbies on the right path. If only most C programmers learned to be as neat and organised as you have to be in Java...

But I digress. SRB2 is programmed in C because it's based off Doom, which was programmed in C. Which in turn was probably programmed in C because Java didn't even exist at the time. That's how old the game is. :)

 

[SSNTails]

Java requires you to be tidy?

You can write code in Java that's just as nasty.

 

[Liliam]

Sure, you can be as spaghetti as you can be in C, but at least Java doesn't allow you to do weird pointer aritmethic (Element y in the array x is accessed by x[y], damn it!) or throw around primitive data types without caring about proper casting. If anything, it enforces a couple of strict rules that every programmer should take into consideration, even though it doesn't come close to solving the whole mess.

 

[SSNTails]

Actually, pointer arithmetic is significantly faster than array index access. This is one of the major things that really cheeses me off in managed languages.

example:

int x[256];

int i;
for (i = 0; i < 256; i++)
     printf("%d", x[i]);

is way slower than

int *i = x;
int c = 0;
while (c++ < 256)
{
    printf("%d", *i);
    i++;
}

The above is a very poor example, boys and girls.

 

[Liliam]

I wouldn't doubt that. In the first example, what you're doing is multiplying i by the size of an element of x, then adding the result to x's pointer. In the second example, you're simply adding the size of an element of x to i. An addition and a multiplication is always slower than an addition alone.

But what you're doing is iterating over all the elements in an array. When you want to fetch a single solitary element, x[y] and *(x + y) should take exactly the same processing time.

You have, however, brought up a glaring fault I hadn't noticed before. I wonder if there's really no faster way to iterate over an array in Java.

 

[Sappharad]

You have, however, brought up a glaring fault I hadn't noticed before. I wonder if there's really no faster way to iterate over an array in Java.

I believe that Java's foreach loop would probably be the faster way you're looking for.

int[] numbers = new int[256];
for(int i : numbers){
//Do something...
}

(Pardon me if the syntax is off, I've been doing C# at work for the past year+ and haven't had a lot of time to use Java lately.) This example also works on any List that provides an iterator.

I've seen a lot of people on other forums (usually non-developers) complain about Java, which always irritates me because most of the reasons can't really be justified. If a program is well written, you shouldn't be able to know or care what language it's written in just because some of the others programs written in that language are lousy. For example, I used the FTP client CyberDuck for almost 2 years before I found out it was written in Java and was fairly impressed to find out.

In the scope of Object Oriented languages, I definitely believe that Java is significantly better than C++ just because of all of the things it does to make things easier for developers. The biggest thing of course is all of the standard classes that are officially part of the language. Having easy access to use Threads, Sockets, Queues, File IO, and UI elements really makes things much easier. Sure, .NET gives C++ those thing like that too, but only on Windows. Otherwise I'm stuck finding third party libraries, manually fussing around to link to them, and then I need to deal with documentation that isn't consistent across the board. I know they're supposedly working on an updated C++ standard that includes more standard classes out of the box, but this is something that they should have been doing for years. Also the fact that you need to prefix every single method in a C++ class with it's class name is just unnecessary extra typing.
I was a bit surprised when I learned Objective C how much more I like it than C++, and considering it's been around longer I wonder why it never gained any popularity. It has a huge standard class library (GNUstep) comparable to .NET and Java, and classes are surrounded by {} like in Java so you don't need to declare the class name for every single method in the class. Yet it still is 100% compatible with existing C code.

I guess this kind of turned into a big long rant about how I don't like when people complain about Java, but oh well. This really doesn't have much to do with performance either. I do wonder though how performance of compiled C would be versus Java code complied with GCJ. I would assume that given the structure of the language is much closer to what you can do in assembly that it would always be possible for C to win, but it probably doesn't matter in the long run.

 

[Liliam]

I believe that Java's foreach loop would probably be the faster way you're looking for.

int[] numbers = new int[256];
for(int i : numbers){
//Do something...
}

Does that work with primitive data types? I always assumed it only worked on collections which implemented an Iterator.

If it's the equivalent of pointer arithmetic then, sure, that works nicely!

 

[SSNTails]

I don't think Java is a good teaching language though, because it misses a lot of concepts that you really need to know about. This is from my own experience watching others in college. After all, what do you think the Java VM is written in? Most likely C with parts of assembler.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

 

[Liliam]

Yes, of course. What separates a good programmer from a poor programmer is the ability to see how things work in the different layers of abstraction. I can totally understand that. But I don't think you should need to be able to understand C's horrible pointer notation to call yourself either one.

Recursion and pointers are obviously important concepts and their workings should be known by any decent programmer. But there's a fine line between understanding said concepts and being able to figure out their implementation in a given language.

I do concede that Java courses tend to oversimplify things. A lot of students come out not knowing how anything works behind the curtains, and that proves to be a large barrier when they need to cross over to different environments. But I can assure you (hell, I'm living proof of it) that the would-be "good" programmers that would not have been weeded out in tougher courses still learn the inner workings and end up just as competent as they did in the past, with a much lesser dose of trauma over segfault errors.

In the end, it kind of works... the good programmers still learn everything they should, and have the same competence as they would a few years back, and the ones that couldn't quite make it all the way through get a little big push into the industry and do an okay job. Universities crank out more people, and more positions are filled. Sure, there's bound to be more duds, but that's true for any field.