The argument that you present is flawed which you admit, because following the same line of thought C is a relational database language because it is possible to build a RDBMS in C. Similarly Java is a RDBMS because it can be used to develop one, or it is a logical programming language because it would be possible to write an implementation of Prolog in Java. Obviously what is possible with a programming languages is not how they are categorised, but it is their syntax that defines the language. The syntax of C doesn't support the OO paradigm and so it can't be called an OO language.

Yes I fully agree with you that it is wrong to suggest that Java supports multiple inheritance, although it does provide some features that are useful from a program design perspective, namely the implements, but because the code needs to be written for each implementation it is not multiple inheritance.

Okay, granted. If you define object oriented-ness in terms of syntactical support, you're right: C doesn't have syntax for classes, inheritance and the like (whereas C++ does).

The thing I was claiming is that you can still write programs in the OO paradigm without too many contortions. I recall Paul Graham writing something interesting about this; as far as I recall, he claims that a language supports a feature if you can achieve the same effects without implementing an interpreter for a different language. As an example of a feature unsupported by most languages (using this definition) is defining new syntax, something lisp and ML-based languages does let you do (most languages let you do operator overloading, but not defining new operators).

Using this definition, C does support the OO paradigm. As an example of languages which doesn't support OO (again using this definition), I would look at the completely stateless functional languages (I think Haskell falls into this category)--because an object is basically defined as "some state (called members), with methods (mainly) operating on that state".

I would say that is a very very loose definition of support, but without seeing his argument it is difficult to understand where he is coming from. However I would contest your statement that "without too many contortions".
Trying to write a program using standard OO features in C, would result in code that is very difficult to maintain and I'm not even certain that much would be gain by such a venture. The data and logic would still be separated resulting in a pseudo class, protecting the data from direct access (encapsulation) outside of this pseudo class would not be possible, inheritance could really only be done via a form of association and polymorphism would probably require mammoth switch statements that would be a nightmare to maintain. So whilst I agree that using C to mimic some OO features would be possible I would contend that it is too cumbersome to write programs using the OO paradigm, and thus misleading to suggest that it supports OO.

Depends on how complex a program you're writing. If you have a handful of interfaces, and a handful of classes implementing those interfaces, it's probably not going to be a problem--you just need to ship a vtable pointer whenever you want to invoke a method.

I slightly disagree--I think it's too cumbersome to write programs heavily using the OO paradigm, which might be what you meant. If you have a java program, it's probably going to be easier to rewrite it in C++ than in C, I acknowledge that.

However, what I object to is the view that "C can't do OO at all"

I don't think that I said that "C can't do OO at all" my argument was that it doesn't support it. If I did said the former then I retract it.

Also I would like to thank you for this debate because it has given me plenty to mull over, I suspect that we will never totally agree on this specific issue but I'm comfortable with that.

Neither do I--but some people do say that.

You saying that actually gives me a better understanding of what you mean by `support'. Given that, I think we're actually in agreement, we've just been talking a bit past each other (at least initially).

Yeah, my first response was based on me thinking you thinking that OOP could not be done it C at all. I agree that the more complicated elements of OOP is gonna hurt in C, but the basic stuff can be done with a bit more self-discipline. There is actually a proof-of-concept project called "Extended C" that uses macros to support basic OOP without the requisite self-discipline and informal interfaces.

Java is crap it crashes my mechine almost every time I try to do something with infinate loops. I lose my work and its very sad. APPLETs load very slow. I agree with jonaskoelker 100%

I'll say upfront that I haven't read every post in thread (its already at 7 pages) and this is just my experiences with Java. I work at a company that has an enterprise level web application with a LOT of users...and its all written in Java. There is a lot of number crunching and database interaction involved. And Java has never been a bottleneck. If a programmer believes that Java can't handle regular programming (I'm not saying system-level or embedded things, just regular business logic), that programmer should be canned. The biggest problem is optimizing SQL so the database doesn't choke pulling out all the data.

There are a lot of good frameworks supporting Java that make life pretty good especially for the web and web services.

That being said, its a not perfect language, but as we can see from this thread, none of them are. Use whatever tool is right for the job.

But Java applets still suck.

Java applets are a little different than regular Java apps - how well they work depends on how well your browser supports them. Also, there's a good reason why they load slow - they're an entire program! Everything needs to be downloaded for them to work so if the site you're on is slow it'll take quite a while.

Maybe, just maybe the problem is with your machine?

I've certainly not experienced a Java app, or a program coded in any other language, to be the root cause of a system crash, rather core instability in the system itself.

I work on a Java web application that uses Hibernate for the data modeling. This seems to be our biggest bottleneck too. The code is littered with references like this:

foo = SiteManager.getSiteProduct(user.getSite(), user.getProductTrack().getProduct()).getSiteProductParams().getFoo();

That was standard code when I got there, and since I didn't understand the data model until recently I followed its example when writing new code. The problem is, that particular line results in about 5 seperate SQL queries against the database, and 4 of those queries are returning a row of data when the code only needs the primary key.

Even with that big design flaw, performance is fine. But the application rarely has more than 10 concurrent users. I've been going through and replacing as many of those queries as I can find with straight SQL (stored in XML properties files) so that there's only one transaction with the PostgreSQL database.

You should have put the SQL in a PostgreSQL function/stored-proc IMHO. Allows the server to cache the query plan and reuse it, dramatically improving performance. Also hides the actual SQL making injection attacks almost impossible (unless you use dynamic SQL withing the function/proc itself).

The input data should be checked and validated as well before being passed as a parameter. Security should be thought out in the design process and sql injection *should not* be a major problem nowadays.

Aha. I see. Much in the same way that windows 95 *should not* bluescreen, yeah?