Just Need Some Programming Language Advice

Quote:

Original post by jah2488 I just really dont want to invest my time/money in a language/program and have to change later

Well, quit programming then, because you will never find the one Final Solution™ language. I know over 12 programming languages, and I will probably learn more eventually.

Anyway, to answer your immediate question: pick either Java or Python. Why? Because you already know a little bit of them. C is not an option because of the number of facilities missing from the language itself. You'll spend too much time implementing features you get for free from Java and Python.

Which one of them? It really doesn't matter. There are trade-offs that make them roughly even.

thanks, i know your right i'll never find one perfect language, its all part of the learning process, but i just didn't want to end up changing languages in the middle of my current project. :]

Yah i think i'm gonna go with python, i've been able to find a few more resources on it than Java

thx again for the help

Quote:

Original post by jah2488 I just really dont want to invest my time/money in a language/program and have to change later

As Oluseyi said there is no final solution, but I think I know what you were trying to say here. You want a language that can do almost anything you would ever want to implement in any game you can think of, so that when you generally become a more experienced programmer, you'll be able to hold to the same language you started with, instead of having previously programed with a limited language and now having to learn a new/more complex language that can let you pull something off.

If I interpreted right, then I would say go with the "trinity", (or what I would consider to be "the trinity") which is "C++, SDL, OpenGL".

I know haw easy pygame can make things seem, but when you outgrow it (and you will), you'll feel like you wasted time with it.

Of course, that's just speaking from my experience.

Quote:

I know haw easy pygame can make things seem, but when you outgrow it (and you will), you'll feel like you wasted time with it.

This is complete bull.

Quote:

instead of having previously programed with a limited language and now having to learn a new/more complex language that can let you pull something off.

So is this implication here that Python is somehow "limited."

Quote:

but i just didn't want to end up changing languages in the middle of my current project. :]

Then don't. The language itself isn't going to force you to change, only your own anxiety over whether or not you're using the "best" tool. There is no "best" tool, there is only the right tool for the job. And the right tool for the job is the one that will let you achieve your requirements most easily. Python is pretty good at that, so you'll be fine.

Quote:

Original post by jpetrie This is complete bull.

...? Ok, I'll play:

Walking causes cancer.

Give me a "because", so that I would have grounds to answer with something a little more constructive then just: "No it's not".

Quote:

So is this implication here that Python is somehow "limited."

No, it's an implication that a "limited language" is "limited". My "personal opinions" on pygame are an independent statement.

Quote:

Original post by Vuk Samotnjak Quote: Original post by jpetrie This is complete bull. ...? Ok, I'll play: Walking causes cancer. Give me a "because", so that I would have grounds to answer with something a little more constructive then just: "No it's not". Quote: So is this implication here that Python is somehow "limited." No, it's an implication that a "limited language" is "limited". My "personal opinions" on pygame are an independent statement.

Since you are the one dissing Python/Pygame, I'd say the burden of proof is on *you* to discuss how you feel these tools don't live up to your "trinity".

The onus is on you. You're the one who claimed that the OP will be limited by Pygame, or that Pygame (and by extension, Python) is some toy language one "outgrows." Why don't you provide a "because" for that assertion?

These sorts of baseless and subjective assertions about languages are a waste of time, and extremely harmful to people like the OP. They only serve to reinforce their anxiety regarding "using the perfect tool" and can additionally perpetuate irrelevant FUD. Frankly, there's is absolutely nothing wrong with the OP continuing to use BlitzPlus to make games. In all likelyhood, in fact, he'd probably end up producing more (and better!) games that way than 75% of the people on these forums who spend hours of their time and megabytes of bandwidth trying to figure out the "best language" to work in.

The important thing is for him to pick a tool and get to work. Sniping at his choice with comments like, "well, when you outgrow it," isn't helpful. Don't do it.

You know, I'll furthermore address the issue regarding "easy." This is, in fact, the one the more clueless arguments one can make against a language. As game developers, we spend countless man-hours and countless millions of dollars building tools and technology so we can make games more easily. "Easy" in no way means "bad," "less powerful," or anything like that. A language or toolchain that's easier to use enables cheaper, faster development, which is a very good thing. One who prefers a language that is "harder" purely on the basis that it is "harder" and thus must be more powerful is somebody I wouldn't ever want to work with.

@jah2488

Since you have some experience with Java and Python, my recommendation is for you to stick with them, but if you feel like trying something new, C# with XNA wouldn't be a bad choice. The community is already strong, the documentation is great for getting started, and I've just found it enjoyable to use. However, you're limited to Windows and the XBox 360 which may or may not be a concern for you.

Where I work, we use all of the following:
C++
C#
Perl
PHP
Python

Not all of these are used for the actual game, but they are part of the job. And this is a proper game development studio, so it's not like I'm talking about some tangentially related industry either.

What many people seem to believe in here is that investments does not pay off. They'd rather stay safe with the languages they know than try something new. And the reason is clear: they will be less productive in the new language. But what they forget is that if you find a better tool, in time you'll be much more productive.

One of the most common supporting arguments is that are that there is no perfect tool. That is no reason not to pick one of the better tools.

On a side note, there is nothing wrong with Vuk Samotnjaks comment, which was clearly stated as an opinion. He tried Python, and he feels that it's limiting, that's all. If you don't agree, by all means post your own opinion. Don't bash him for posting his.

Here's a few of my views:

C++ has tonnes of gaming related libraries available. That itself makes it worth considering. However, it lacks a lot of productivity boosting things that other big languages have: a huge standard library, garbage collection, etc.

Java has the jMonkeyEngine, and many C/C++ game engines and libraries is available from the language. It has most of the modern mainstream language features, but suffers to some degree from it's single-paradigm OOP approach.

C# is a lot like Java, but with some important improvements (delegates for example) and a few extra annoyances. Depending on your choice of libraries, it might not be cross platform (many of the popular ones are not, like XNA, WinForms, etc.).

As for dynamically typed languages like Python, the lack of static information leads to sub-par IDEs and less safety, two things which I miss a lot. On the other hand, they typically have more "radical" features (such as closures) and they are often less verbose.

Personally, I would pick a less mainstream language, such as D, Scala, haXe or a functional language depending on the task. But for your first few languages, you're probably better off with a big community and many examples. Actually, Java may be a good choice, since the single-paradigm will give you a good understanding of OOP, which will be a benefit, should you want to try more languages later on.

Quote:

Original post by Simian Man Since you are the one dissing Python/Pygame, I'd say the burden of proof is on *you* to discuss how you feel these tools don't live up to your "trinity".

First, I would like to make it clear that my intention was not to "diss" Pygame (Python I didn't mention). Maybe being so nonchalant in saying that one will "outgrow" pygame was a mistake on my part.

I just jumped in because I had a few specific situations where pygame didn't seem to suit well. Like there was this one time (at band camp) when I wanted to get back sound waveform information to present a 3D analyzer for things like sound pitch and scale, and some other frequency related measures. Well I couldn't find anything in pygame from where I could get access to the mixer array (or any kind of structure) that could provide me with that data.

Also, I had some problems with making standalones - and as with most things this is just a matter of personal preference (which from now on I should probably keep to my self), but in order for everything to work I would have to package python itself, pygame and Soya as opposed to just having a binary with the appropriate dlls. Also, I do know about utilities like freeze and py2exe, but I couldn't find a way to make it produce properly.

Yes, now that I look at it, with just those two things it probably seems out of place to just suggest that one will "outgrow" pygame, because in all fairness, I probably didn't search properly for the solutions that were most likely there. However at the time, shedding the abstraction layer seemed like the right thing to do.

Is that thinking flawed? Maybe, I don't know. I would appreciate your insight on that.

Quote:

Original post by jpetrie These sorts of baseless and subjective assertions about languages are a waste of time, and extremely harmful to people like the OP.

They are subjective, yes. I don't think what I said was baseless though.

How is it "harmful" to give an opinion? I mean there are many programming languages out there, I doubt that all of them are as well suited to game development as C++ or Python. If I implied anything, it's that he should not stick with some fringe language that's out of the mainstream (in relation to gamedev). <- I don't see how that's "baseless". I think it's just logic, and actually helpful for someone trying to decide where to start.

If I'm wrong, the majority will disagree, and based on that jah2488 can come to an informed (dare I say "harmless") decision.

No harm, no foul.

Quote:

Original post by Vuk Samotnjak I just jumped in because I had a few specific situations where pygame didn't seem to suit well.

The same can be said for any technology, pygame or not, when used for something other than it's intended purpose.

Quote:

a 3D analyzer for things like sound pitch and scale,

Not a game

Quote:

Also, I had some problems with making standalones

Seems to have little to do with pygame and more to do with the relevant python utilities.

Quote:

How is it "harmful" to give an opinion?

An opinion without stated basis or other temperament is prone to repetition as gospel by those who don't know any better, leading to a vortex of all-consuming misinformation as the gospel is spread, not just as opinion, but as gospel "truth" and "fact" as the rumorzombies of newbiedom mistakenly wrangle words and prose out of their original, malleable forms.

Tempering ones opinions by clearly labeling them as merely that is something I always encourage, helping harden as iron does to steel the humble meaning you mean to convey with your words, avoiding future misconstruing as grandiose bible by those less knowledgeable than you -- or at least those that think themselves less knowledgeable than you.

...we here at gamedev tend to get a bit tired of beating lies, damned lies, and statistics (from 10 years ago) out of newbies acting on false premises, so regardless of how minimal the harm here may be in this case, we tend to be a bit antsy about unlabeled opinions, except for the very few rare exceptions which everyone in the apparent knowhow appears to agree wholeheartedly about. In fact, only two examples even come to mind at all off the top of my head:

1) C++ is a poor 1st language
2) VS6 for C++ sucks compared to modern alternatives

Even these opinions are almost always backed up with the multitude of reasoning behind them, or at least a few sweet factoids to start with to mostly solidify the sentiment barring further counterpoints with relevant counter-counterpoints.

Quote:

Original post by MaulingMonkey The same can be said for any technology, pygame or not, when used for something other than it's intended purpose.

Yes.

Quote:

Not a game

He, he. Are you asking me or telling me?

Who's to say that it's not a part of a game? Maybe for additional eye candy or actual event triggering purposes. Either way, if you're trying to imply that the given situation is irrelevant as a basis on which my personal opinions about pygame are formed, then I would have to disagree.

Respectfully, of course.

Quote:

Seems to have little to do with pygame and more to do with the relevant python utilities.

Well, it's one of the reasons I wouldn't want to use pygame (a personal reason, and imho a valid one). But yes, by no means is that an argument that speaks for pygame functionality. That's something I should have clearly labeled.

Quote:

An opinion without stated basis or other temperament is prone to repetition as gospel by those who don't know any better, leading to a vortex of all-consuming misinformation as the gospel is spread, not just as opinion, but as gospel "truth" and "fact" as the rumorzombies of newbiedom mistakenly wrangle words and prose out of their original, malleable forms. Tempering ones opinions by clearly labeling them as merely that is something I always encourage, helping harden as iron does to steel the humble meaning you mean to convey with your words, avoiding future misconstruing as grandiose bible by those less knowledgeable than you -- or at least those that think themselves less knowledgeable than you. ...we here at gamedev tend to get a bit tired of beating lies, damned lies, and statistics (from 10 years ago) out of newbies acting on false premises, so regardless of how minimal the harm here may be in this case, we tend to be a bit antsy about unlabeled opinions, except for the very few rare exceptions which everyone in the apparent knowhow appears to agree wholeheartedly about. In fact, only two examples even come to mind at all off the top of my head: 1) C++ is a poor 1st language 2) VS6 for C++ sucks compared to modern alternatives Even these opinions are almost always backed up with the multitude of reasoning behind them, or at least a few sweet factoids to start with to mostly solidify the sentiment barring further counterpoints with relevant counter-counterpoints.

Thank you for taking the time to explain the intricacies of the gamedev community dynamic/psyche (I must say, I read your post twice, and I really think it goes above and beyond the "call of duty" - I mean just looking at the elaborate dictionary used - it really made me smile, since it's not something I'm used to seeing on the "interwebs"). I won't be nearly as surprised in the future when I receive "passionate" responses to my opinions. Even though my opinions were clearly labeled as such.

So again, my thanks, and sorry for being a bother (If I was by any chance).

Quote:

Original post by jah2488 thanks, i know your right i'll never find one perfect language, its all part of the learning process, but i just didn't want to end up changing languages in the middle of my current project. :] Yah i think i'm gonna go with python, i've been able to find a few more resources on it than Java thx again for the help

Yeah, I think you should go with Python. Because C++ is a good language, but it kinda gets difficult to learn.
The perfect language isn't there because all of the have some kind of loop holes and error. It's kinda like looking for a flawless video game.
I think you should work on Python. And depending on your programming skills, you might be able to advance. Gems, it's a good language to run into if you are just now coming from Python.

mhm thanks everyone :]

didn't mean to cause any arguements

yah to clarify my OP, i've made a dozen or so working very small games, and i'm just willing to take the time into planning a larger game. Something that will probably take me 6months to a year, but i'm willing to just take it one step at a time and just add features as i go along (i'm working on a adventure/rpg). I figured with this new project it was time to take on a new language, perhaps something more complex, but just not too complex.
i like what jpetrie said about me still using BlitzPlus, because hes been the Only Person i've ever found on this site to not shutter at the sound of someone using such a "excuse for a programming language" i really like programming in Blitz but thought it was inferior because of being derived from the BASIC language.

I also found it extremely hard to get any tutorials, help, resources, etc for Blitz when it comes to RPGs, and thought the change was out of neccesity.

I was concidering Java and Python because i heard they were both utilized OOP and i also know thats a benefit for game programming especially RPGs.

ty again for all your input

i'll just have to research a lil more before diving into this project

Quote:

Original post by Vuk Samotnjak If I interpreted right, then I would say go with the "trinity", (or what I would consider to be "the trinity") which is "C++, SDL, OpenGL". I know haw easy pygame can make things seem, but when you outgrow it (and you will), you'll feel like you wasted time with it. Of course, that's just speaking from my experience.

Having used your trinity, I've found the language portion of it can be easily cut out and replaced without much consequence if any. With that being said, in recent developments, I've found my preferred "trinity" to be Python, Pygame, PyOpenGL. PyOpenGL can be dropped into places to fill the gap pygame leaves performance wise, albeit it's a little more confusing to use, but it still doesn't come close to the complexity of doing the same things in C++.

Quote:

Original post by Ahnfelt As for dynamically typed languages like Python, the lack of static information leads to sub-par IDEs...

Komodo. Buy a full version.

Quote:

...and less safety...

Clarify "safety," because it sounds like a bogeyman right now.

Quote:

On the other hand, they typically have more "radical" features (such as closures)...

LISP has closures. LISP is older than C++ (by nearly 30 years!). Smalltalk has closures. Smalltalk is older than C++. Just because C++ doesn't provide it, or didn't originally, does not make it "radical." It just makes C++ pedestrian.

Quote:

Original post by Oluseyi Quote: Original post by Ahnfelt As for dynamically typed languages like Python, the lack of static information leads to sub-par IDEs... Komodo. Buy a full version.

I have never heard of Komodo. Maybe it's great, I can't know every IDE in the world. However, what I DO know is that there are free, open source IDEs out there, like NetBeans. Does Komdo compare? Is it one of-a-kind?

Quote:

Original post by Oluseyi Quote: ...and less safety... Clarify "safety," because it sounds like a bogeyman right now.

Sorry, that needs clarification. To know that your program is correct to some degree before you run it. In order from least to most: this may be none, ie. the syntax is parsed while the program is run, the syntax is parsed immediately before it's run, checking that symbols are in scope, some actual type checking, more type checking, etc.

Quote:

Original post by Ahnfelt Quote: On the other hand, they typically have more "radical" features (such as closures)... LISP has closures. LISP is older than C++ (by nearly 30 years!). Smalltalk has closures. Smalltalk is older than C++. Just because C++ doesn't provide it, or didn't originally, does not make it "radical." It just makes C++ pedestrian.

Yes, it does make it "radical". In quotes. Take the hint. The "Lisp had X feature 30 years ago" trump card doesn't contribute anything, we've all heard it times and times again.

Like I said, they're my views, not truths set in stone. I would only be delighted if you could convince me otherwise.

Quote:

Original post by Vuk Samotnjak Quote: Not a game He, he. Are you asking me or telling me? Who's to say that it's not a part of a game?

Telling. To play the devil's advocate with you, while it is indeed possible for such a mechanism to be part of a game, the same can be said for just about anything else... again!

Japanese translation and currency conversion could also easily be part of a game, or voice recognition. However, these would fulfill relatively niche rolls in the programming of a given game, and as such fall outside the domain of a general purpose game programming library such as pygame. I feel that sound analysis also falls outside the domain of general game programming, echoing the implicit decision by pygame's author(s).

In the current state of human evolution, it's impossible to provide a general purpose library that does everything. Instead, one uses a combination of libraries for most tasks, ranging from totally general purpouse to rather domain specific, and then all the way down to things coded just for a single program -- not part of any library -- because said code is too domain specific to be applicable to any other project.

Now, I've assumed the example you've given is not part of a game, based on the following assumptions:

1) It's unreasonable to assume one library will deal with all the tasks, unless either:
a) The project is designed within the limitations of said library
b) The project is tiny (single-tasked in nature, and thus requiring only a single problem solution... or at least very few)
On the grounds that no library can accomplish everything, as described earlier.

2) You're reasonable (at least in writing off pygame for said example)
3) You appear to think it reasonable to assume one library will deal with all the tasks of your example (and thus must be one of the exceptions of point 1, because of 2)
4) Your example uses a design you've clearly stated falls outside of pygame's capacities (eliminating exception 1.a)
5) By process of elimination, the example must be simple in nature, as per 1.b
6) A game complex enough to incorperate such a sound based system isn't simple in nature
7) Ergo, as per 5 and 6, it's not a game, as further evidenced by being presented as such -- as a standalone project -- rather than part of a larger whole.

Now, clearly, this leaves a lot of potential failure points on this rather intuition based line of reasoning, but I think it's strong enough an argument to assume the conclusion as the case unless clearly stated otherwise.

Quote:

Thank you for taking the time to explain the intricacies of the gamedev community dynamic/psyche

No problem. I was bored. Am again >_>.