I prefer C++, or just plain C if you don't need objects. Personally, I've never tried C# because of various reasons, but I have heard it's easier for beginners.
Main reasons I prefer C++ are because I've used it for quite a while now, I like the syntax and like using GNU compilers and tools and stuff. (make <3)
The reasons I haven't tried C# mostly consist of me disliking parts of the syntax and the fact that I hate the interface of Visual Studio and all the express editions. And can't be bothered to figure out how to use Microsoft compilers from a terminal emulator / command prompt.
[QUOTE=esalaka;22024961]I prefer C++, or just plain C if you don't need objects. Personally, I've never tried C# because of various reasons, but I have heard it's easier for beginners.
Main reasons I prefer C++ are because I've used it for quite a while now, I like the syntax and like using GNU compilers and tools and stuff. (make <3)
The reasons I haven't tried C# mostly consist of me disliking parts of the syntax and the fact that I hate the interface of Visual Studio and all the express editions. And can't be bothered to figure out how to use Microsoft compilers from a terminal emulator / command prompt.[/QUOTE]
1. Look up the name of the compiler
2. You'll probably find a use guide along with it
3. Stop worrying! Having a variety of options is at once painful and fun, so embrace the fun while you can. Before you get tired of writing boilerplate build scripts...
[QUOTE=ZeekyHBomb;22022153]C# and C++ are C-style languages, which simply means that their syntax is roughly the same.
That'd be like saying that Half-Life 2 is made out of Doom.[/QUOTE]
actually the source engine still has snippets of code from the Quake engine. :B
[QUOTE=Chandler;22026225]actually the source engine still has snippets of code from the Quake engine. :B[/QUOTE]
not much more then sv_gravity
C# is easy and very fun to do with stuf like XNA. And very good for beginners. C++ is the most advanced but also the strongest programming language as beginner you should really go for C# (blah blah blah C is powerful i know don't comment) .
BTW and don't let the boring hello world programs get you down
[QUOTE=Chandler;22026225]actually the source engine still has snippets of code from the Quake engine. :B[/QUOTE]
Yeah, Source is like a port of the QuakeWorlds engine to C with classes (with some updates of course), but Half-Life 2 actually doesn't contain much of Dooms code. I think.
[QUOTE=esalaka;22024961]I prefer C++, or just plain C if you don't need objects.[/QUOTE]
Just a note, there is no reason you can't do OOP in C. I do it all the time.
[QUOTE=blankthemuffin;22032230]Just a note, there is no reason you can't do OOP in C. I do it all the time.[/QUOTE]
I have too, using [url=http://library.gnome.org/devel/gobject/stable/]GObject[/url]. But even with the help of a library, one has to manually write lots of boilerplate code for each class (things like initializing virtual tables in the constructor, and the equivalent of an "instanceof" or "dynamic_cast" operation) that would've been generated by the compiler in a language with built-in OOP support.
If you need objects, C is not the best choice.
You don't need a heavy-weight framework like GObject to write object-oriented code in C. You can do inheritance, information hiding and all that with just plain old structs and other features of C. GObject is nice and has a whole bunch of OO features, but it's not necessary.
Depends on what you think OOP is.
I've done dynamic single-dispatch Smalltalk-like (no metaclasses, though) systems for the heck of it but if you're going through the path of generic functions and hotpluggable multiple dispatch foundation becomes incredibly shaky and collapsible... not without drowning in boilerplate. Never the structs-are-classes type thing, though. I've never enjoyed languages like that.
[editline]01:55PM[/editline]
I've never really had fun trying to do so until Blocks and as a result closures came out.
Object-orientation is a programming paradigm. How you go about it, with either messages, methods, whatever; is irrelevant.
There is a lot of boilerplate needed to emulate higher-level language features when doing it in C, but it doesn't mean you can't do it or that it necessarily isn't worth doing.
I disagree in the context of this discussion. These are not implementation oddities but design decisions that will affect we end up using the language - OOP is more of a conceptual umbrella than a single "metaphor".
One doesn't go in an expert in C++ and immediately set to work on a language which implements CLOS and the MOP. In a language with generic functions you end up preferring higher-order functions over iterators. In a language with dynamic dispatch you end up experimenting with things like state machines without having to deal with the cruft of your current language. With sufficient introcession and introspection you can then add things like interfaces - traits - whatever you want to call them, whatever they mean to you. In single-dispatch languages this limitation (whether you call it a limitation or not) is especially worked over. In a language which relies more on values and bindings rather than variables ownership is more liberally dealt with - pointers vanish and objects are talked about as "owned" rather than simply existing within a class at that point in time. In a language with true metaclasses you're more likely to end up going meta; this usually means more in the way of introspection as the notion of factories vanish - rightfully relegated to the objects that are classes. But that notion also causes an issue - when do we instantiate successive metas? This means that the normal notion of the lifecycle of an object vanishes. Some patterns go along with that. This is an important distinction between Smalltalk and Objective-C. In prototype-based languages the point of metaclasses are moot. In a pure language with actors the notion of a metaclass is muddy because you end up with closures anyway. In Clojure there isn't a point either - mutability doesn't exist. Design patterns vary between languages: some as a result of how horribly static dispatch is, some a result of static typing, some simply a result of insufficient abstraction facilities. But once you've solved them you've lost a powerful way to talk about things!
[QUOTE=HubmaN;22042363]I disagree in the context of this discussion. These are not implementation oddities but design decisions that will affect we end up using the language - OOP is more of a conceptual umbrella than a single "metaphor".
One doesn't go in an expert in C++ and immediately set to work on a language which implements CLOS and the MOP. In a language with generic functions you end up preferring higher-order functions over iterators. In a language with dynamic dispatch you end up experimenting with things like state machines without having to deal with the cruft of your current language. With sufficient introcession and introspection you can then add things like interfaces - traits - whatever you want to call them, whatever they mean to you. In single-dispatch languages this limitation (whether you call it a limitation or not) is especially worked over. In a language which relies more on values and bindings rather than variables ownership is more liberally dealt with - pointers vanish and objects are talked about as "owned" rather than simply existing within a class at that point in time. In a language with true metaclasses you're more likely to end up going meta; this usually means more in the way of introspection as the notion of factories vanish - rightfully relegated to the objects that are classes. But that notion also causes an issue - when do we instantiate successive metas? This means that the normal notion of the lifecycle of an object vanishes. Some patterns go along with that. This is an important distinction between Smalltalk and Objective-C. In prototype-based languages the point of metaclasses are moot. In a pure language with actors the notion of a metaclass is muddy because you end up with closures anyway. In Clojure there isn't a point either - mutability doesn't exist. Design patterns vary between languages: some as a result of how horribly static dispatch is, some a result of static typing, some simply a result of insufficient abstraction facilities. But once you've solved them you've lost a powerful way to talk about things![/QUOTE]
:psyboom:
HubmaN are you PhD???
No, I just like languages and happen to be shit at quite a lot of the mathsy stuff and organizational stuff. It's rather depressing - I learn them but can't be bothered to do anything that massive before it breaks apart.
I went around rambling a bit too.
[QUOTE=HubmaN;22042363]I disagree in the context of this discussion. These are not implementation oddities but design decisions that will affect we end up using the language - OOP is more of a conceptual umbrella than a single "metaphor".
One doesn't go in an expert in C++ and immediately set to work on a language which implements CLOS and the MOP. In a language with generic functions you end up preferring higher-order functions over iterators. In a language with dynamic dispatch you end up experimenting with things like state machines without having to deal with the cruft of your current language. With sufficient introcession and introspection you can then add things like interfaces - traits - whatever you want to call them, whatever they mean to you. In single-dispatch languages this limitation (whether you call it a limitation or not) is especially worked over. In a language which relies more on values and bindings rather than variables ownership is more liberally dealt with - pointers vanish and objects are talked about as "owned" rather than simply existing within a class at that point in time. In a language with true metaclasses you're more likely to end up going meta; this usually means more in the way of introspection as the notion of factories vanish - rightfully relegated to the objects that are classes. But that notion also causes an issue - when do we instantiate successive metas? This means that the normal notion of the lifecycle of an object vanishes. Some patterns go along with that. This is an important distinction between Smalltalk and Objective-C. In prototype-based languages the point of metaclasses are moot. In a pure language with actors the notion of a metaclass is muddy because you end up with closures anyway. In Clojure there isn't a point either - mutability doesn't exist. Design patterns vary between languages: some as a result of how horribly static dispatch is, some a result of static typing, some simply a result of insufficient abstraction facilities. But once you've solved them you've lost a powerful way to talk about things![/QUOTE]
There is a reason C has so many supersets and near supersets. Having to deal with the 'cruft' of the language, as you would say, could indeed indicate a programmer trying to force a language into his own habits and designs. But C is by all means a relatively low-level language, and to do anything interesting at all you will eventually want to start emulating common higher-level features wherever practical. Inheritance and information-hiding in C is indeed very practical, and thus common. Dynamic dispatch is not very practical in C, and is thus usually worked around, but you can still deal with the low-level stuff if you absolutely want it. For example, GObject deals with both introspection and metaclasses in C while still sticking to class-based object-orientation; anything is possible.
The inherent C paradigm is procedures-and-data, which can only take your program so far. I too would advocate using a higher-level C variant when you expect to be using such features, but it doesn't mean that you can't righteously write object-oriented code in C to the extent where it's practical.
I'm not sure what you mean by 'context of this discussion', and I wish you had used paragraphs and paid a bit more attention to your sentences; I might have missed your point entirely.
[QUOTE=jA_cOp;22044482]There is a reason C has so many supersets and near supersets. Having to deal with the 'cruft' of the language, as you would say, could indeed indicate a programmer trying to force a language into his own habits and designs. But C is by all means a relatively low-level language, and to do anything interesting at all you will eventually want to start emulating common higher-level features wherever practical. Inheritance and information-hiding in C is indeed very practical, and thus common. Dynamic dispatch is not very practical in C, and is thus usually worked around, but you can still deal with the low-level stuff if you absolutely want it. For example, GObject deals with both introspection and metaclasses in C while still sticking to class-based object-orientation; anything is possible.
The inherent C paradigm is procedures-and-data, which can only take your program so far. I too would advocate using a higher-level C variant when you expect to be using such features, but it doesn't mean that you can't righteously write object-oriented code in C to the extent where it's practical.
I'm not sure what you mean by 'context of this discussion', and I wish you had used paragraphs and paid a bit more attention to your sentences; I might have missed your point entirely.[/QUOTE]
We were talking about going around implementing various forms of object-orientation in C (the context of our discussion) when you said "but it doesn't matter because object orientation is object orientation", I replied with "I disagree, object orientation has many flavors and they do have an impact (examples follow)", you then said "yes, C is limiting if you want to do that but anything is possible with boilerplate - and there is a reason why we sometimes do it and why we sometimes can't do what we want in it - and it is sometimes practical and why are you using it anyway if you talk about variety".
To which I can't argue against mainly because your post goes everywhere without hitting the nail on the head.
C has served me very well for quite a bit and I don't think there's anything wrong with trying to shoot the moon in it either, though. It's amazing what you can do without much abstraction - and then how quickly you jump up once you get that down.
The point is, you can do OOP in C without extra abstractions (and with almost no boilerplate code), but the higher level you go the more boilerplate it includes.
Blankthemuffin and I stated; OOP is very possible and indeed also practical in C, to which you replied "I disagree". I'm simply saying how it [I]is[/I] indeed practical and purposeful even within the limits of the language, without having to stretch it (which something like GObject very much does).
For example, single inheritance:
[cpp]
typedef struct
{
/*data*/
} A;
void A_foo(A* a)
{
/*operate on a*/
}
typedef struct
{
A base;
/*more data*/
} B;
B* B_new()
{
B* b = malloc(sizeof(B));
/*construct b*/
return b;
}
int main()
{
A* a = (A*)B_new();
A_foo(a);
return 0;
}
[/cpp]
The only thing here that could count as "boilerplate" is the explicit cast.
Information-hiding:
[cpp]
/* A.h */
typedef struct A_t A;
A* A_new();
void A_foo(A* a);
/* A.c */
#include "A.h"
struct A_t
{
int data;
};
A* A_new()
{
A* a = malloc(sizeof(A))
a->data = 1;
return a;
}
void A_foo(A* a)
{
a->data += 2;
}
/* main.c */
#include "A.h"
int main()
{
A* a = A_new();
A_foo(a);
return 0;
}
[/cpp]
(Can also be done with the pointer-to-implementation pattern for more idiomatic mixing of both public and private data)
These are just two examples, but two very common things closely associated with object-oriented programming, that are also very possible and very practical in C. Ergo, OOP [I]is[/I] possible and even common in C.
No, I said I didn't like going down the human cfront path.
[QUOTE=HubmaN;22045111]No, I said I didn't like going down the "structs-are-classes" - a la C++ - path.[/QUOTE]
It doesn't matter what [I]you[/I] like. I'm not telling you to like it. I'm suggesting you accept that OOP isn't impossible and not even impractical in C.
You're basically saying OOP in C++ isn't "true" OOP, which would be nothing more than the typical functional-programmer elitism.
Read above, I edited post.
I never said it wasn't impossible - I said it was hard to implement a system like CLOS in C. I said I *have* done it before. I never said anything about practicality. I never said C++ wasn't OOP either - I simply said I didn't like going down that path - why I didn't like it was never stated.
[editline]05:57PM[/editline]
And then of course comes the title of functional programmer elitist...
[QUOTE=HubmaN;22045181]Read above, I edited post.
I never said it wasn't impossible - I said it was hard to implement a system like CLOS in C. I said I *have* done it before.[/QUOTE]
Again, you are suggesting CLOS would be the only "true" OOP in C. If you're no longer talking about OOP in C, say so.
[QUOTE=HubmaN;22045181]I never said anything about practicality. I never said C++ wasn't OOP either - I simply said I didn't like going down that path - why I didn't like it was never stated.[/QUOTE]
Why are your likes and dislikes even remotely relevant?
[QUOTE=HubmaN;22045181]And then of course comes the title of functional programmer elitist...[/QUOTE]
Well you already admitted not to actually disagree with my post by admitting it's both possible and plausibly also practical. I can only make certain assumptions as to why you're still arguing.
Read above, I edited post again.
I replied to your post not as a reply to my post but as an argument in its own right. No connection between them whatsoever.
I believe you misunderstood my post and I stand by that. And I want to get over it thank-you-very-much because it ends up with how it always ends here.
[editline]06:02PM[/editline]
[QUOTE=jA_cOp;22045227]Again, you are suggesting CLOS would be the only "true" OOP in C. If you're no longer talking about OOP in C, say so.
[/QUOTE]
No I'm not, I'm saying it's merely difficult to implement such a system because it would require another layer of OOP - the metaobject protocol. I was embracing multiple takes on OOP on my jumbopost above.
[QUOTE]
Why are your likes and dislikes even remotely relevant?
[/QUOTE]
Because I was talking about it in my original post and because you have referenced it I have to say it was what I did. Of course it doesn't matter to the tangent you went on - but I have to defend it here.
[QUOTE]
Well you already admitted not to actually disagree with my post by admitting it's both possible and plausibly also practical. I can only make certain assumptions as to why you're still arguing.[/QUOTE]
Because you are. I am currently in the role of clarifying what I write - I did not suddenly admit everything; it was stated in my original post albeit indirectly because those were not my points.
For the love of jeebus stop picking an argument, though. Stop assuming I want an argument with you. I don't go on much on Programming for the very reason.
I don't mind you putting down the argument, but don't make it look I'm the one picking it. "I disagree in the context of this discussion" is just asking for a "misunderstanding" if you're now actually claiming that your post wasn't really a response at all.
And there are no victims here. I never called you a "functional programmer elitist". And perhaps it's not our fault that "it ends up with how it always ends here".
(I gave up quoting as you keep editing your posts)
I believe you are the one picking it - especially if you are claiming I deliberately set you up for an argument. It is my fault if I didn't say "but that wasn't my point!" earlier but I would like you to accept it. I was originally talking about what I've done and what I've found hard. You reply by telling me "object-orientation is object-orientation" (you think I'm being rather elitist about this from the start, no connection with later one) and then saying "but it is practical". There is a disconnect between the two. In that disconnect you pursued an argument.
I explicitly stated what I though the context of the argument was in a reply, though. You do very well know what it was. I also never said that the title would apply to me, though.
[QUOTE=HubmaN;22044464]No, I just like languages and happen to be shit at quite a lot of the mathsy stuff and organizational stuff. It's rather depressing - I learn them but can't be bothered to do anything that massive before it breaks apart.
I went around rambling a bit too.[/QUOTE]
If you don't already, you should be reading Lambda the Ultimate
C# is awesome
[QUOTE=Chandler;22047771]If you don't already, you should be reading Lambda the Ultimate[/QUOTE]
Thank you, I think I shall.
[QUOTE=HubmaN;22041671]Depends on what you think OOP is.[/QUOTE]
That's not really the (or even an) argument at all, you can do very practical (and very impractical if that floats your boat) OOP in C. Other languages can add features that make it nicer syntactically but in the end all the fundamentals are available.
My OOP work in C is mostly towards the purely practical end of the scale. In order to keep myself sane I tend to keep my work on top of C as succinct as possible, mostly in order to avoid the problems one gathers by injecting complexity when it isn't needed, which is one of the main reasons for me even using C in the first place.
[editline]03:56PM[/editline]
And arguments are fun, disagreements are healthy and encourage development. Don't be too quick to point the finger at who started it, since in the end this is a discussion forum not an everybody agree and suck each other's dicks forum.
[QUOTE=blankthemuffin;22057691]That's not really the (or even an) argument at all, you can do very practical (and very impractical if that floats your boat) OOP in C. Other languages can add features that make it nicer syntactically but in the end all the fundamentals are available.
My OOP work in C is mostly towards the purely practical end of the scale. In order to keep myself sane I tend to keep my work on top of C as succinct as possible, mostly in order to avoid the problems one gathers by injecting complexity when it isn't needed, which is one of the main reasons for me even using C in the first place.
[editline]03:56PM[/editline]
And arguments are fun, disagreements are healthy and encourage development. Don't be too quick to point the finger at who started it, since in the end this is a discussion forum not an everybody agree and suck each other's dicks forum.[/QUOTE]
I understand people are going to interpret that as it applies to me. When I said "depends on what you think X is" I was trying to point out variety. I said "you started it" because he said "but I'm assuming this because it's the only reason you should be arguing with me". There's a difference between arguing and hashing out the point and clarifying in circles and going nowhere, though, and this was the latter.
But have you ever tried playing with preprocessors before? Do you know of any good out-of-the-box solutions to programmatically produce C? I *have* been thinking of trying to create my own cfront one day.... and as it is I've got plenty of time right now.
[QUOTE=HubmaN;22058926]I understand people are going to interpret that as it applies to me. When I said "depends on what you think X is" I was trying to point out variety. I said "you started it" because he said "but I'm assuming this because it's the only reason you should be arguing with me".[/QUOTE]
You really should go easy on the quotation marks when you're not quoting something.
Sorry, you need to Log In to post a reply to this thread.
