roothorick

There's two distinct sides of the coin, and you completely missed one of them. Computers are getting faster and faster whether you like it or not, and people want ways to use that power. Want proof? Look at commercial games, especially mainstream FPS games. Less than a decade ago, everyone was playing the original Doom, with graphics that today can only be described as "classic". Fast forward to today, Doom 3 is out, which taxes just about every computer on the market to its absolute limit to bring stunning visuals that as little as two years ago were unfathomable. And people love the game largely for that very reason -- they're being shown what their $1k+ computer can REALLY do, and they're eating it up. Because it is such a two-sided coin, I'm supporting it being an option -- slower system? Don't use it. BTW mikeman, would you mind publishing your patch for perspective view? It's nice to have something to go on.

Actually, your English is a lot better than that of a lot of people I've met online who claim it's their primary language. (Nobody I've met on these forums falls under that category as far as I can remember however.) Just hang out on IRC for a while... Anyway, back on topic. Figured it's appropriate to show my background: BASIC (MS QBasic) -> Perl -> Python -> C and C++, and now I'm starting to learn x86 assembler. And right now I'm definitely one of the few fence-sitters on the OO topic.

In today's day of GeForces and whatnot, performance really isn't an issue. However, I definitely could see wanting to make it an option, for just this reason. Add a fog effect that makes anything beyond a certain distance impossible to see, and cull at that distance. I've seen a lot of first-person and third-person games with very large landscapes do this, and it seems to be the "generally accepted" way.

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 <_<

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.)

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.

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?

For that one reason and that one reason alone, you should deny everyone working on it of the features provided by C++? Most notably, inlining, which allows you to optimize code in ways that you would otherwise have to sacrifice a massive amount of readability for. The complex data types like vectors, maps, etc. provide a significant advantage for readability too, providing much more readable syntax for such structures. Do you really want to sacrifice such large advantages just because you're stuck in your ways? Maybe you should reconsider your philosophies here, it's this kind of stubborn conservatism that turns peaceful large-scale disagreements into civil wars. And you decisively missed something completely. _ALL_ natural languages (English, Spanish, French, etc.), regardless of their character sets, regardless of their originating cultures, regardless of their syntax, are object-oriented -- what's a noun? It's a variable referring to a class, or an instance thereof. And out of the 30+ natural speaking languages that have ever existed, the concept of noun has prevailed in each and every one of them. The rest is obvious. Since we already communicate with each other in an OO format, wouldn't it make sense to communicate to a computer in an OO format? It's less to learn, and we're conditioned to think in an OO sense straight from Day 1 out of the womb! In fact, since it's so universal, it's by no means a stretch to say that the human brain is specifically designed to think in an OO fashion. However, it's all really irrelevant, as no OO (programming) language requires you to write OO code. If you don't want to, don't. It's that simple.

I believe it. It's easy to approach a new language with the same standards and habits that you used with an older, completely different language. Any style switch is difficult, and honestly, if you don't like doing something a certain way, don't do it that way. I really don't care if EL remains in a traditional style. But one thing that really gets on my nerves as I look at making changes to the client is the fact that I have only basic types, arrays, and structs to work with. The suggestion was not so much to drastically change the style of the code, as it was to make the tools available for people with different styles and habits to work on the same codebase provided they're able to understand (but not necessarily agree with) the styles and habits of the other developers, and much more importantly, providing sane complex containers with good error checking that can be used pretty much in place in additions and modifications to the code.

I'm not so much suggesting a switch to C++ as I'm suggesting a switch from C. C really has no useful tools for developing complex projects such as MMORPGs. In C, there are no vectors or lists (only arrays, which have no bounds checking whatsoever, making them EXTREMELY bug-prone). There aren't even references (although, given, there are pointers, which are really more like memory addresses than actual references). And all those complex data structures offered by just about every other major language out there, like maps (C++) / dictionaries (Python) / hashes (Perl)? Nowhere to be found. You have to emulate them using arrays if you want that functionality. Oh, and be sure to code in bounds checking too! And guess what? There's no class-based behavior beyond structs, and structs can't contain methods, which dirties your namespace REALLY fast. For all I really care, you can go ahead and switch to Objective C. Or Java. Or Ruby. Or Python. Hell, even Perl would be better. I only suggested C++ because it would be by far the easiest move (as you can reuse pretty much all of the existing code). Just get rid of C. Coding anything this complex in C is a truly painful experience, and maintaining it is close to impossible.

There's plenty of documentation online, in particular I must recommend The C++ Annotations and especially (although more once you have a grasp of the language) the C++ FAQ LITE. What's nice about C++ is that it's very similar to C, so if you already know C there isn't nearly as much to learn than if you were going to, say, Python. By the way, I just stumbled upon draw_scene.c... is a 304-line function REALLY necessary?

I'm extremely curious -- why? You didn't give any reasons. After reading over the code myself, I can't help but ask why nobody has attempted to port it to C++ yet...

Everyone knows the kind of scam I'm talking about, although they probably didn't use my terminology for it. You know, when someone quickly removes items from the trade and clicks in so that you get nothing? I happened to be thinking idly, and came up with a possible solution: Trade continues as normal until one of the players involved change their offer. When this happens, if either player has already clicked in, that player's "agreed" mode is reset -- the terms have changed, and need to be re-agreed on. Even if the other player then clicks to agree before the otherwise-victim has time to react, the ready state on the other end has cleared, and agreement must be reached again. While yes, scamming is legal, and I fully understand the reasoning behind it, the targeted technique here, IMO, isn't scamming. It's deliberately exploiting a flaw in the game in which they can freely change their offer and make the trade without the consent of the other player, thereby stealing what was originally offered. I would personally consider it a bannable offense.

amd64 isn't a normal USE flag; and it doesn't look like it belongs in IUSE. (See ut2003, ut2004, openoffice-bin ebuilds for examples of architecture handling.) Not sure exactly what's going on there, but judging by just about every arch-sensitive ebuild I can think of in portage, arch keywords don't go in IUSE.

The rules specifically forbid modified clients from connecting to the server. However, I need to be able to use a client with my modifications in order to test whatever changes I make, be them added features, bug fixes, enhancements, etc. Obviously, there must be some sort of consideration in place for this, but I can't find anything... So what's the policy for this?