Sign in to follow this  

Just Need Some Programming Language Advice

This topic is 3715 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've been programming for a few years now in BlitzPlus (BlitzBasic) and have a good grasp of it, i also have begginer knowledge in C, Java, and Python. I really wanna work on a Complete RPG that will eventually be 3D (even if i have to write a 2d version and upgrade to a 3D). I've created an extremely basic 2D Rpg and i'm ready to make an investment in another language and software to make this game. I would just really like any advice on a good language, or system to use. would it be better for me to get something like Blitz3D or maybe Torque Engine Builder? or just dive into C++? Thanks for any of your help EDIT : I just really dont want to invest my time/money in a language/program and have to change later

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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".

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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++.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 >_>.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ahnfelt
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.


I prefer: "To know that a given part of your program is correct to a high degree before you release it".

C++ absolutely fails in this regard.

It's love for "undefined behavior" means I really have no faith that a C++ program is correct to any sort of degree even after passing all of it's unit tests, which have a nasty tendency of passing due to statistical probability, while still not guaranteeing jack shit.

It's love for "undefined behavior" also means bugs tend to hemorrhage things in a way that causes the problematic symptoms to crop up in totally unrelated parts of your program. It's quite possible to tell in many cases that your program is correct to "some" degree, yet have no way of narrowing down to a specific part of your program where the largest need for improvement is. This can make for some very long lived, serious, known bugs.

I'll take sane behavior over static type checking any day.
I'll take dynamic typing over C++'s static typing any day too. The time saved in writing and refactoring the code in question can be used to write better unit tests.

Share this post


Link to post
Share on other sites
Well, I'll be the first to admit that I would not choose C++ for anything, if it weren't for it's libraries. And even then, I haven't had any use for it for years. I mostly use Java-like languages, and on occasion, functional languages, or a mixture of the two.

Share this post


Link to post
Share on other sites
To the OP and not directed in way to the people that have posted here so far: Be aware of anyone that shows signs anger/sarcasm when talking about what computer languages is better than another. It generally shows some type of insecurity. Some people have emotional relationship with computer lang and will stand up for it no matter what. Which I think is kinda odd given a computer language has never posted on a forum that programmer x is better than programmer y.

Regardless, and outside of the emotional and personal debates, C++ is the most pervasive in the AAA gaming industry. I would hope that most would concede this to be a fact. Also remember this is generally a hobbyist site and some people here have different motivations than say a seasoned "shipped titles" developer. If a language would exist that has the combination of run time speed, legacy, support and productivity of C++ the industry would switch. Unfortunately no such language exists at this time.

As a side note, most lead devs and some non-lead devs have double digit years of C/C++ use and no longer fall into C++'s pitfalls. Most of these devs are also very good teachers to the younger crowd coming into game development.

All that said, if I was starting a new game company/project today I would look for C++ developers. There is just to much active OSS done in C/C++ to ignore.

For tool development C# is a good language however Visual C++ can do everything Visual C# can do. Most tool development is greenfield so you generally have no legacy requirement which makes C# a good fit. Our web guy uses other languages but its really has nothing to do with the current game.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ahnfelt
I have never heard of Komodo.

Yet you authoritatively state that the lack of static information leads to sub-par IDEs. This is the IDE developed by the providers of ActivePerl, ActivePython and Visual Perl, as well as the hosts of the very valuable ASPN. This severely undermines your authority to make your assertion.

Quote:
Does Komodo compare?

To NetBeans? I think so. I haven't used NetBeans in a while, since it used to be really slow (it's written in Java, isn't it? same reason I hadn't used Eclipse in years - both required more horsepower than my machines at the time possessed). Komodo has a rich feature set, but why don't you do something smart like Google it?

Quote:
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.

You know, I'll give you points for trying to say something reasonable. But it's still wrong.

The fact that your program syntax passes a parse validation provides absolutely no guarantee of correctness - at least, not in any way that remotely matters. (Besides, just about every interpreted language provides a syntax checker option - eg perl -c - or an ancillary tool to the same effect - tokenize.py in the standard Python distribution.)

But all this provides you absolutely no guarantees about how your program behaves when it matters - runtime. Compilation doesn't imply validation or verification. It doesn't inherently perform unit tests, it doesn't perform regression tests for a multiuser revision controlled codebase, it doesn't perform integration testing for a component-wise project... Frankly, it doesn't do anything except convert good human-readable code into well-behaved executable code, and shitty human-readable code into Outlook Express. (Ouch!)

Program correctness is completely orthogonal to static or dynamic typing. And since most statically typed languages allow for trivial coercion, compilation doesn't guarantee proper type behaviors!

In short, you're wrong. Again.

Quote:
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.

It's just the inverse of "static language X doesn't have it, so it must be 'radical'." The point is, it's a pointless (counter-)argument.

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

Convince you of what, exactly? That there are contexts where dynamically typed tools are every bit as valid as statically typed languages, and others where either is superior to the other? (Yes, there are contexts where dynamic languages are superior to statically typed languages - contexts where development involves high iteration and frequent change, where expressiveness and adaptability are more valuable than theoretical runtime, where the code is likely to change frequently or be adapted to a variety of tasks.)

I'm sorry. I have no real interest in convincing you. I'm only interested in disputing error. Your opinions are not only yours, but for you to form. I only try to ensure that correct information is presented in these debates, not opinions based on error and misunderstanding.

Share this post


Link to post
Share on other sites
Quote:
Original post by jeremymm
For tool development C# is a good language however Visual C++ can do everything Visual C# can do.
Not true. Visual C# has much smarter intellisense and better refactoring tools, not to mention the whole WinForms designer mode.

Share this post


Link to post
Share on other sites

This topic is 3715 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this