Some hints to the devteam

[Entropy]

Ok.

Some people like C, some people like C++, some people like Java, and some like other languages.

I happen to LIKE C, it's a matter of TASTE. you know, like liking some foods. I like the simplicity of C, I like the control of C, and I like the fact that C is the most portable language ever. Plus, C is faster than C++. That's the reason kernels are not written in C++.

Furthermore, all the developers here know C, but some don't know C++. I can read C++ code, but I don't like it, and I don't like the strict OOP paradigm.

If you feel like porting the client to C++, for whatever reasons, then go ahead, split it and port it. That's the beauty of open source.

 

In addition to what I said, I do not find any useful (FOR ME) features in C++, as C gives me all I need. I don't find overloading useful, I don't find STL useful, I don't find OOP useful, I don't like templates, etc.

[Grum]

As for OO, first of all, everyone thinks in terms of objects. "swimming" is not an object, but it just can't stand alone.

It most certainly can in a functional programming language. At least the equivalent of "to swim" can.

 

swim = \player -> {player & is_swimming = True}
map swim [Leeloo, mikeman, Grum]

Edited January 26, 2005 by Grum

[Malaclypse]

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

Well, I'd be in no way forced to think in terms of objects. If theres something I'd have been forced into it'll be functions and functional languages. I think in terms of objects as long as I can remember. What you are talking of are actions, like placid said sets of behaviors for objects. And in any of these actions you told, there is at least one object involved, be it the meal you are eating, the person which sleeps, the person who is cleaning and all the things she uses to clean and to get cleaned are objects. The actions are there to connect different objects and are messages the objects sent to each other. If you want to eat, you are going to send yourself the message to grab up the meal and pull it in your mouth

[Wytter]

You can also do this in C by using structs and function pointers, but that's basically OO again. But how could you do this by sticking to the procedural paradigm? You would basically need to make multiple case statements, and call the proper functions according to the model type.

True, the multiple case statements is how I've been solving this problem. Of course it's a minor hack, but it still gives you advantages over a pure procedural approach.

[Entropy]

What about the good old if?

if(md2)do_md2_stuff()

else do_skeleton_stuff()

[Grum]

Or even older if

IF (3*i-7) 10, 20, 30

 

Or make a function pointer table, and adress in that.

[Wytter]

What about the good old if?

if(md2)do_md2_stuff()

else do_skeleton_stuff()

object->render((void*)object);

object->animate((void*)object);

 

Is a bit cleaner

[mikeman]

What about the good old if?

if(md2)do_md2_stuff()

else do_skeleton_stuff()

Well, look at what this code actually means. You're basically acknowledging the fact that MD2 and skeleton models are of the same "type", have the same interface, but just differ in the implementation. Even if you don't accept it, you're basically thinking in object terms.

 

But I can understand if you just don't like C++ syntax. For instance, I would be mad if the ARB ever decided to make OpenGL object-oriented. I like using C++ when I want to, and not being forced into my throat. Hell, even Carmack didn't use C++ until Doom3.

 

 

Or make a function pointer table, and adress in that.

 

That's basically OO, only it is done in C. We already said that it can be done.

Edited January 26, 2005 by mikeman

[Entropy]

If my code that I posted is OOP, then so be it, I don't mind that

But I don't like the C++ syntax, I guess.

[Leeloo]

You forgot something... "OO-people are". Those of use who weren't forced to think in terms of objects by some restrictive language think of programming in the same way as we think about everything else... eating, sleeping, cleaning, cooking, working, playing, swimming - none of those are objects.

Well, I'd be in no way forced to think in terms of objects. If theres something I'd have been forced into it'll be functions and functional languages. I think in terms of objects as long as I can remember. What you are talking of are actions, like placid said sets of behaviors for objects. And in any of these actions you told, there is at least one object involved, be it the meal you are eating, the person which sleeps, the person who is cleaning and all the things she uses to clean and to get cleaned are objects. The actions are there to connect different objects and are messages the objects sent to each other. If you want to eat, you are going to send yourself the message to grab up the meal and pull it in your mouth

There are objects involved, but they are not the important parts. I get paid for working, not for the PC or the chair. The dishes get clean by cleaning them, not by being dishes. And the food won't give me fresh energy until I eat it.

 

It's the verbs that make the difference between a living world and a dead one, between a living person and a dead one. The objects are not important. Believing otherwise only proves that you have read too many books about OO programming.

[roothorick]

There are objects involved, but they are not the important parts. I get paid for working, not for the PC or the chair. The dishes get clean by cleaning them, not by being dishes. And the food won't give me fresh energy until I eat it.

 

It's the verbs that make the difference between a living world and a dead one, between a living person and a dead one. The objects are not important. Believing otherwise only proves that you have read too many books about OO programming.

Actually, I partially agree.

 

My one largest gripe about most modern OO languages is that they refer to methods performed on the object as if the object is performing the method on something else (possibly nothing). While after some OO conditioning this makes sense, it's counterintuitive -- in fact, it's In Soviet Russia syndrome at its most widespread. Instead of lifting weights, I tell the weights to exercise my muscles, and expect them to do it. Furthermore, OO calls for the actions of an object to be its "members" -- that somehow, what you do is part of what you are comprised of. I think a language needs to clearly distinguish between object and action.

 

I don't like C++ (and OO in general) purely for the "OO way". Actually, I've been indifferent to resentful over many of the philosophies and practices in OO design. However, I like OO languages for one big reason: the semantics and syntax are specifically suited for the driving concept behind OO, which is the meat of said artichoke -- expressing concepts relatively natural to human thought processes in a format the machine can understand quite easily.

 

On the topic of inlines, they already said that they've restricted themselves to C89/90 for GCC 2.9x compatibility *sic*, which means inlining is nonexistant at the language level. Of course, that raises another facet of the question -- if you want inlining, to you move to C++ or to C99?

 

-EDIT- I noticed a lot of people commented that C++ is "slower" but didn't say anything more on that front. Would anyone mind elaborating?

Edited January 26, 2005 by roothorick

[Wytter]

On the topic of inlines, they already said that they've restricted themselves to C89/90 for GCC 2.9x compatibility *sic*, which means inlining is nonexistant at the language level. Of course, that raises another facet of the question -- if you want inlining, to you move to C++ or to C99?

This is how you can do it:

 

#ifdef C99
#define Inline inline
#else 
#define Inline
#endif

Inline
int function (int yay)
{
for(yay=0;yay<1000;yay++);
return yay;
}

 

That way you can maintain compatibility with old compilers while still using this, admittively good feature in C99.

 

-EDIT- I noticed a lot of people commented that C++ is "slower" but didn't say anything more on that front. Would anyone mind elaborating?

GOOD C++ code can be as fast or even faster than C (if you use templates correctly for instance the compiler will be capable of doing better optimizations). However BAD C++ code can be a lot worse than mediocre C code

[Entropy]

-EDIT- I noticed a lot of people commented that C++ is "slower" but didn't say anything more on that front. Would anyone mind elaborating?

It is slower because there is more abstraction, which means the language is further away from the CPU. That's why the kernels are written in C, and many servers, such as apache, etc. are also written in C.

[Wytter]

-EDIT- I noticed a lot of people commented that C++ is "slower" but didn't say anything more on that front. Would anyone mind elaborating?

It is slower because there is more abstraction, which means the language is further away from the CPU. That's why the kernels are written in C, and many servers, such as apache, etc. are also written in C.

C++ is definately a NO for kernels. You have less control of the end result (how the compiler optimizes the code) when writing C++ code than when it's written in C. For a kernel developer it is very important that the code you end up writing behaves exactly what you wanted it to. It's about control, and you have more control in C than you do in C++.

[Malaclypse]

It's the verbs that make the difference between a living world and a dead one, between a living person and a dead one. The objects are not important. Believing otherwise only proves that you have read too many books about OO programming.

Not only the verbs, the objects are as important as the verbs. Without any fruit you can't eat, so there will be no action and no verbs to describe or name the action. Both belong to each other, and as you can't strictly separate them in natural languages (and thus thinking) it also make sense to not separate them (at least not strictly) in programming languages. There is no action without any object and vice versa.

 

I noticed a lot of people commented that C++ is "slower" but didn't say anything more on that front. Would anyone mind elaborating?

Although, I didn't commented this before, I think, the permanent lookup in the virtual table and the runtime check for the types used in virtual/abstract functions is a big slowdown compared to C.

[roothorick]

Not only the verbs, the objects are as important as the verbs. Without any fruit you can't eat, so there will be no action and no verbs to describe or name the action. Both belong to each other, and as you can't strictly separate them in natural languages (and thus thinking) it also make sense to not separate them (at least not strictly) in programming languages. There is no action without any object and vice versa.

Except that natural languages DO separate them (on a 1-on-1 basis anyway). You can eat fruit, but you can also eat meat, veggies, a TV dinner, or even small plastic balls. And honestly, I couldn't fathom the OOish approach of saying they're all "food" or "edibles" purely because you can eat things that are considered decidedly non-edible. Really, you can stick anything you want down your throat. (I'm not going to list more examples, and people PLEASE DON'T! Let's not jump off the decency cliff here!) Of course, you're going eat different things in different ways. At this point the traditional OO approach begins to look extremely abstract -- the "You" object, the "Edible" *sic* base class from which pretty much everything is derived, and all these cute little things. And the In Soviet Russia semantics rear their ugly head yet again -- you don't eat the food, you tell the food to get eaten by you. What!?

 

I went into this debate having been more or less brainwashed by OO zealots. Now? I don't know what to think anymore.

[duran]

this is why its damn hard to write legal texts that cover all the bases, and create a programming language based on natural language (or for that matter create a natural language prosessor).

 

it gets even more funny when you walk into the social structure that is sarcasm...

[roothorick]

this is why its damn hard to write legal texts that cover all the bases, and create a programming language based on natural language (or for that matter create a natural language prosessor).

Natural language processor? Yes. Programming language based on natural language? If it's hard, you're not approaching it the right way. The key is to recognize the parallels between programming concepts and natural language concepts -- particularly: noun <-> variable, verb <-> function/method. From there, the rest is pretty much just syntax, besides the builtins (which while they can be a headache they aren't too much of a challenge.)

 

In fact, as an academic exercise in my quest to find the right (for me anyway) programming style and language design, I'm going to do just that -- design a programming language with syntax and semantics almost exactly identical to English. (I'd use something more consistent like Spanish, French, etc. if I actually knew such a language... it is just an academic exercise after all.)

Edited January 27, 2005 by roothorick

[Grum]

this is why its damn hard to write legal texts that cover all the bases, and create a programming language based on natural language (or for that matter create a natural language prosessor).

Natural language processor? Yes. Programming language based on natural language? If it's hard, you're not approaching it the right way. The key is to recognize the parallels between programming concepts and natural language concepts -- particularly: noun <-> variable, verb <-> function/method. From there, the rest is pretty much just syntax, besides the builtins (which while they can be a headache they aren't too much of a challenge.)

 

In fact, as an academic exercise in my quest to find the right (for me anyway) programming style and language design, I'm going to do just that -- design a programming language with syntax and semantics almost exactly identical to English. (I'd use something more consistent like Spanish, French, etc. if I actually knew such a language... it is just an academic exercise after all.)

COBOL...

[Leeloo]

This is how you can do it:

 

#ifdef C99
#define Inline inline
#else 
#define Inline
#endif

Arghh... How about just

 

#ifndef C99
#define inline
#endif

 

Besides... Even this old egcs-2.91.66 at work supports inline. C89 may not, but it has been a gcc extension for a long time.

[roothorick]

COBOL...

Well, yeah, that's one failed attempt... English is a hell of a lot more concise than people even realize. You just have to take a hint from OO to see what I'm talking about.

 

For example, I already have a rudimentary idea of syntax for my academic experiment:

 

System include "stdfiles.txt" explains stdout.

Print "Hello World!" to stdout.

 

In case part or all of it isn't obvious: "System include" is a builtin class (although classes in this language will be more like C structs with a couple inclusion hints than actual OO classes), and "explains" is a function with "object-performs-action" syntax that takes a system include and an undefined name. Stdout and print are defined in stdfiles.txt, and including stdout implicitly includes the print function because stdout's definition in stdfiles.txt contains a hint to include that function as well as the object. (There's a lot more logic to it that makes this a hell of a lot faster and more efficient than it sounds here; I'm just using it as an example.)

 

So, even the most complex programs will be essentially a few thousand or so lines of explanation building the understanding needed to perform the task at hand, and then maybe 5 lines of commands that just sets the ball rolling.

 

-EDIT- Slight typo in the code block, oops <_<

Edited January 27, 2005 by roothorick

[Chryzopraz]

Although I'm not involved in EL development, I've seen such discussion many times, so decided to add my 3 cents.

 

It looks like a typical generations conflict

 

Entropy, Leeloo, Wytter and other developers represent older generation of programmers, while OO suporters almost obviously are the younger generation. It does not mean they are physically younger (but probably are), but how different their computer education was.

 

The first group of programmers probably started their computer education with procedural languages like Pascal, C and sometimes assembler or Basic. They learned how processor works, probably how to optimize machine code, they understand the computer. They learned the power low level languages like assembler or C give you over the machine. And probably (like me ) they learned OO languages and found them unnecessary. The growing complexity, more and more levels of abstraction which cover how the machine really works can't appeal to people who are used to the full control over the computer.

 

Younger programmers, who started their education with modern languages and probably never touched the assembler just can't understand that. They never had that feeling of total control and power. They never had the ability to write programs for computers without fancy operating systems that forbids you doing this or that and cover much of the hardware architecture.

 

So basically this is classical generations conflict based on misunderstanding of each other. And youngsters (no offence!) thinking: they know better.

 

Regards

 

Chryzopraz

 

PS.

I'm a university teacher in computer science, so basically I know what I'm writing about.

Also forgive me my English, it's not my mother language.

[Entropy]

Hehe

Good point

Actually, I started with Basic. Then moved to Z80 ASM, then to x86 ASM, and 5 years later, I was forced to learn PHP (my boss pretty much told me that if I don't learn PHP I'll be fired )

Then since knew PHP, and PHP was based on the C syntax, knowing two assembly languages, it was very easy for me to pick up and become effcient in C. 6 months after my "hello world" program in C, I started to work at Eternal Lands

[Leeloo]

Basic V2 -> 6502 assembler -> Turbo Pascal -> x86 assembler -> C/C++ mixture (don't ever do that) -> Miranda -> Prolog -> Real C -> VB.NET.

 

I learned OO design, but never a real OO language (VB.NET still misses important OO facilities like multiple inheritance, and I never learned real C++).

[mikeman]

@Chryzopraz: Actually, I think that's a pretty "easy" consumption. I started 10 years ago to write games(like Snake, or Scorched Earth clones) in Basic, then C, then learn 286 assembly(that nightmare with segments), and I still write 32-bit assembly because I really like it(in fact, one of the things I'm working now is to write an 64KB demo in OpenGL and all-assembly). I was then introduced to OOP with Delphi, which is my favourite languange, and then jumped to C++ because,well, it's more popular. I am still interested in learning how things work in low-level, and if performance is really really critical in some parts, I don't hesitate to use the inline assembler.

 

I just like OOP because I know when is better to give up some "control over the computer" to gain control over the design of my program. After all, if you want "full control" nowadays, you shouldn't program for Windows or Linux or an API like OpenGL. So, the idea that OOP is preferred by people who just can't program in low-level is a little unfair. "Youngsters" should definately learn how things work in low level, but maybe the "oldies" need to de-attach themselves from the machine a little(without forgetting how it works), there are many interesting things that happen in the higher levels.