Would the community support a C implementation?

[Admiral Refuge]

@reggin:

> You make it sound like I'm the fanboy here. I'm simply clearing up a few misconceptions/misleading statements.

My apologies, it is hard to say if you're a fanboy, shill, etc., since you signed up just to defend Java in a C topic in a VB6 forum.

@reggin:

> Can I just say that C can be object-oriented. Using structs is object-oriented. I hope to god you don't simply use global variables when programming state. OOP is very applicable. Maybe you are talking about polymorphism. I have to agree, many novice programmers simply cannot write effective code because they over-do it with tons of layers of abstraction. Still, polymorphism can make code more robust.

I would not say that using structures are object oriented design.  OOP is – by definition -- a design focused around objects.  Your functions are stored in objects, the very existence of the program relies on objects.  Java is an example of a completely object-oriented language, every procedure is implemented in an object and the objects themselves are executed and manipulated.

You cannot have OOP without polymorphism, encapsulated methods, inheritance, et. al. simply because those are fundamental concepts of object-oriented programming.  And that's where the overhead comes in.  As I said many times, go look at wxWidgets's [wxRearrangeList](http://docs.wxwidgets.org/trunk/classwx_rearrange_list.html).
When someone does something like:
wxRearrangeList listController;
It calls the Default constructor (wxRearrangeList()), then, it creates (and calls their constructor) the following objects: wxCheckListBox which calls wxListBox, which calls wxControllerWithItems, which calls both wxItemContainer (which calls wxItemContainerImmutable) and wxControl, which calls wxWindow, which calls wxEventHandler, which calls both wbObject and wxTrackable.
No, not only are these taking up memory as you were pointing out, but they also are having their constructors called!  The program is creating 10 additional objects, allocating memory for their functions, data members, this is object-oriented programming.

It is possible to have object-oriented programming in C (I've done it before), but what we're doing is not object-oriented programming.

We're not having global variables everywhere either, as there is something called "_Structured Programming_" – it's not the same as OOP.

As far as what else you were saying with the networking, etc., I can't comment on much of that, it's more of Stephan's field.

[Carim123]

Why are people still opposing?

Hasn't the question already been answered and defined ten times over, saying that C is definitely being used?

[reggin]

@Admiral Refuge

Touché. Saying structs are "object-oriented" is a bit of a stretch. I was trying to say that, when creating structs, you are creating instances. Anyway, the overhead is not significant in the majority of cases. Also, expect optimizations to be performed by the JVM such as inlining. Things like virtual calls and interface calls… they sound pretty nasty but are not that bad in the long run. Java isn't actually a bad place to start. If performance was my utmost priority, I would be writing hand-tuned assembly for my specific platform.

About the layers of constructors. In C++, it's worse than it is in Java. Creating objects in Java is extremely cheap. Calling several constructors in Java is trivial and should not be of concern to the programmer unless they are creating a considerable amount (I'm talking millions).

@Hamster Boy: I'm just saying that you shouldn't count Java out. I'm not saying it's "better" than C or that you should be using it instead. By all means write it in C. It's not like I wouldn't.

[Tazuko]

Lol I'm already done arguing so don't accuse me of anything… kind of childish?

[Godlord]

@reggin:

> Can I just say that C can be object-oriented. Using structs is object-oriented.

Ironically, they are not object-oriented. In fact, structures are part of the data-oriented design, which is way more beneficial than object-oriented design is. Here's the simple image: structures can be inherited by other structures, you can cast them to other structures, you can store function pointers inside structures, but they are not part of the object-oriented paradigm. In fact, they are just ways of telling the compiler how to interpret a block of data, therefore they are data-oriented by nature, unlike object-oriented programming.

Structured programming allows me to optimise for data, which is important. I can resort the entries inside the structures any way I want, I can add or remove entries (depending on how useful they are), and I can group several entries in yet another entry where applicable. The result is quite simple: I can manage data properly and write applications that are effectively data-oriented.

@reggin:

> Maybe you are talking about polymorphism. I have to agree, many novice programmers simply cannot write effective code because they over-do it with tons of layers of abstraction. Still, polymorphism can make code more robust.

That's merely another problem with object-oriented programming: the need to abstract _everything_ and see _everything_ as objects.

@reggin:

> An engine written in Java could indeed be viable. The only problem I can think of is the memory overhead. However, memory these days is relatively cheap.

Do you think memory is cheap? I don't think so. And here we get to the reason why data-oriented design is so important: memory is slow. To fetch a line in 1980, it only costed you almost a single cycle. In 2011 it may cost you between 400 and 600 cycles. This is why processors are nowadays equipped with caches. The first time you access an address, there will be a cache miss: the cache will load in a line and that costs you 400 to 600 cycles. The second time, the third time, etc. it will only cost you a few cycles, since it is inside the cache. Many applications, especially Java applications, are _not_ cache-oblivious. That means that they don't even care how many cache misses occur, and a programme's performance might be downed by an enormous factor.

The second step is having code that is _cache-aware_. The code scales to your processor in the sense that it knows how to use your cache better on an individual base instead of the general base. The majority of performance is lost due memory. Memory is simply not cheap.

@reggin:

> What are you talking about? What do you mean "in C"? It's only a language. Java uses those functions as its underlying implementation. epoll, at least. I don't think IOCP is used because of its polling approach, although NIO.2 will support it. I'm sure kqueue is supported as well but have not looked. Because of how I/O is performed in Java (there is quite a bit of synchronization involved), it is perhaps considerably slower, and JNI calls aren't exactly cheap. However, don't be mistaken, you could scale hundreds of thousands of connections using Java.

It has to support them all three to offer the same performance on a cross-platform base, which I thought was the buzz word for Java programmers in general.

I am quite disappointed in a few things when I have to look at how the real-world thinks about server programming. The majority of people seem to think TCP is an acceptable solution. It only is when performance isn't an issue, where the amount of applications is negligible, and where the amount of applications using reliable and ordered sending properly is almost zero (There is no need for ordering to occur in most circumstances). Here's the second issue with people who use TCP: they think IOCP, epoll and kqueue are going to help them. I agree with the fact that they definitely do help (100K TCP connections sounds very nice), but they'll be your limit. In fact, bandwidth and such will still be an issue.

And this is where I get to UDP. With UDP you can introduce your own protocol with five ways of sending data: unreliable, unreliable & sequenced, reliable, reliable & sequenced, reliable & ordered. You can manage RTT, you can manage connections, etc. The flexibility of UDP is very useful here, and I greatly respect the game developers who have used it over the past decades (e.g. Age of Empires et al. and Quake et al.). Don't get me wrong: if it isn't worth your time, or you can only use TCP properly, then you shouldn't bother, but I, myself, will definitely use UDP.

Then most people also forget to realise that the server market is in between the embedded market and the desktop market whilst programming. Here's why: memory fragmentation should hardly ever occur, or it might take down the entire server. Servers have an uptime, if memory fragmentation occurs frequently, then the server will have to reboot (which is not nice). Obviously Java has another manner of dealing with this, perhaps a more memory intense manner, which brings me to why I don't use Java for servers in general.

Java is made for cross-platform RAD-programming, not for performance-related programming, and therefore neither for server programming.

@reggin:

> I was trying to say that, when creating structs, you are creating instances.

Actually, all you're doing is allocating memory and interpreting that exact block of memory the way your structure is laid out. Classes are somewhat similar, but more abstract.

@reggin:

> Anyway, the overhead is not significant in the majority of cases.

From a C++-perspective it is, but that's not really what this is about. We are talking about Java, right. The cool thing about Java is that it does all these optimisations for you, it even has an object pool! But then the question should arise asking what you actually had paid for that kind optimisations the JVM provided you.

@reggin:

> If performance was my utmost priority, I would be writing hand-tuned assembly for my specific platform.

Hand-tuned Assembly isn't going to be exactly useful and should be your last resort, before that there are so many other ways of dealing with performance that I could actually write several books about them. The majority of performance is lost due data processing, not code processing. This is exactly noticeable in a data-oriented approach: first optimise the data, then the code.

@reggin:

> @Hamster Boy: I'm just saying that you shouldn't count Java out. I'm not saying it's "better" than C or that you should be using it instead. By all means write it in C. It's not like I wouldn't.

How am I supposed to count Java in when I clearly stated that the engine will be in C, various times? If someone wants to use Java for whatever they want it to use for, then they should go ahead. It's nothing to do with my work, honestly.

Regards,
  Stephan.

[reggin]

> Do you think memory is cheap? I don't think so. And here we get to the reason why data-oriented design is so important: memory is slow. To fetch a line in 1980, it only costed you almost a single cycle. In 2011 it may cost you between 400 and 600 cycles. This is why processors are nowadays equipped with caches. The first time you access an address, there will be a cache miss: the cache will load in a line and that costs you 400 to 600 cycles. The second time, the third time, etc. it will only cost you a few cycles, since it is inside the cache. Many applications, especially Java applications, are not cache-oblivious. That means that they don't even care how many cache misses occur, and a programme's performance might be downed by an enormous factor.
>
> The second step is having code that is cache-aware. The code scales to your processor in the sense that it knows how to use your cache better on an individual base instead of the general base. The majority of performance is lost due memory. Memory is simply not cheap.

You make it sound worse than it actually is. Why don't you actually do some real-world benchmarks?

Also, when I said "memory is cheap", I meant most systems nowadays have at least 2GB of RAM, for example, making the memory overhead of Java negligible.

> It has to support them all three to offer the same performance on a cross-platform base, which I thought was the buzz word for Java programmers in general.

IOCP polls based on completion events, rather than readiness events, which does not fit with the "Selector" model in NIO. I'm sure implementations will try to use the best functions available. I only said I wasn't sure about kqueue because I haven't physically checked.

Yes, I also suggest using UDP.

> Java is made for cross-platform RAD-programming, not for performance-related programming, and therefore neither for server programming.

That's a bit of a misconception. Read below.

> Hand-tuned Assembly isn't going to be exactly useful and should be your last resort, before that there are so many other ways of dealing with performance that I could actually write several books about them. The majority of performance is lost due data processing, not code processing. This is exactly noticeable in a data-oriented approach: first optimise the data, then the code.

Yep, I was just emphasising the point that performance shouldn't be your first priority. Don't for a second think that Java is incapable of performing well. It does perform well in most cases, just maybe not as well as native code.

> But then the question should arise asking what you actually had paid for that kind optimisations the JVM provided you.

What do you mean by that?

> Actually, all you're doing is allocating memory and interpreting that exact block of memory the way your structure is laid out. Classes are somewhat similar, but more abstract.

I know structs are more low-level, but you are effectively creating instances.

> How am I supposed to count Java in when I clearly stated that the engine will be in C, various times? If someone wants to use Java for whatever they want it to use for, then they should go ahead. It's nothing to do with my work, honestly.

I meant in general, if Java was an option. Chill :P.

[ToshiroHayate]

Let's definitely, just drop our C project, for somebody who is randomly defending Java in a community C project. Who doesn't even have the audacity to make an account. Java has a bright future!


[Admiral Refuge]

On the subject of benchmarks, we actually are doing one here: http://www.touchofdeathforums.com/smf/index.php/topic,72622.0.html

Stephan's latest C benchmark just killed my FORTRAN's record with the big numbers ;~;
(still generating between 2 and 1,000,000,000 and hoping I don't run out of memory, and it's taking much longer than 102 seconds).

[reggin]

@Jon:

> Let's definitely, just drop our C project, for somebody who is randomly defending Java in a community C project. Who doesn't even have the audacity to make an account. Java has a bright future!
>
> 

Jon, please read the following:

> I'm just saying that you shouldn't count Java out. I'm not saying it's "better" than C or that you should be using it instead. By all means write it in C. It's not like I wouldn't.

I think I have said this more than once. In the future, please read everything before making ignorant assumptions. Also, saying I don't "even have the audacity to make an account" makes no sense and is immature to say the least.

Thank you for your time.

Your friend,
reggin

[reggin]

Admiral Refuge, I meant relevant benchmarks.

[ToshiroHayate]

Reggin, please view over your current actions.

1) You enter a community.
2) Your first action is to debate, under a guest account.
3) You enter a COMMUNITY'S project, to start yapping about Java, when the project is obviously VOTED to be C, and has absolutely no chance of changing. Seeing as you're not even part of the actual community, that makes you very disrespectful.

So, please, next time read the title, because not making an account and jumping into something that has to do with the community, is very immature and disrespectful. If you can't see that, then that's just sad.

Thank you! :D

-Jon.

Warning - while you were typing a new reply has been posted. You may wish to review your post.

Nice double post.

[reggin]

> 2) Your first action is to debate, under a guest account.

What do you mean by "guest account"?

> 3) You enter a COMMUNITY'S project, to start yapping about Java, when the project is obviously VOTED to be C, and has absolutely no chance of changing. Seeing as you're not even part of the actual community, that makes you very disrespectful.

*sigh* Did you not read my post(s)? I'm not suggesting anything - only clearing up a few misconceptions/misleading statements. Here's another quote:
@reggin:

> You make it sound like I'm the fanboy here. **I'm simply clearing up a few misconceptions/misleading statements**.

If you still feel that my actions were disrespectful, I do apologize.

[ToshiroHayate]

@reggin:

> What do you mean by "guest account"?

You have 0 posts, to me it seems you "signed" up solely to debate. Which I guess isn't a big deal. I'd just hate to see a flame war break out, over something stupid like languages, under a C topic.

> *sigh* Did you not read my post(s)? I'm not suggesting anything - only clearing up a few misconceptions/misleading statements.

Fair enough. You do seem mature enough, and you do know what you're talking about. Probably alot more than I do about Java.

> If you still feel that my actions were disrespectful, I do apologize.

It wasn't really your posts in specific that was disrespectful, because it's not like you were flaming or anything. I just felt miss placed, when somebody with 0 posts is running around a community topic for 2 pages about Java, when the title says "In C".

[reggin]

I may be following this project. It would be interesting to see how this is implemented. S.J.R. van Schaik, or Stephan, seems like a very capable guy :).

[Admiral Refuge]

This topic has pretty much degenerated from it's original goal at this point, so I'm going to lock it.  If you guys want to continue the java conversation, do so [here](http://www.touchofdeathforums.com/smf/index.php/topic,350.0.html).