GeneralThis forum is for non-technical general discussion which can include both Linux and non-Linux topics. Have fun!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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.
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.
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".
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.
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.
However I would contest (...) "without too many contortions".
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.
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.
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"
Neither do I--but some people do say that.
my argument was that it doesn't support it. If I did said the former then I retract it.
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).
Last edited by jonaskoelker; 06-04-2006 at 01:46 PM.
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.
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.
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%
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.
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).
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.