Which language?

Ok, I'm stuck, I apologise in advance for probably being the hundredth person to ask this, where do I start?

I want to get into serious programming for games, not making my own little games type of thing, properly doing it, and I don't mind having to spend a lot of time doing other things before I make something that actually looks like a game.

I probably will make some small stuff for fun :)

I've been looking around and getting slightly more confused as I go on. I don' know what to learn, I hear the big guns are using C/C++ (reason why I'm here) but I imagine doing stuff in things like XNA would be a lot easier. What about Java?

Shoudl I just go ahead and start learning C++ straight off the bat?

Thanks in advance :)

For serious games, C++ is the language for simply one reason: speed. XNA and Java can't beat C++ in speed and C is just not cut out for such large projects.
That said, you have a split road here:
- Either you go the fast, easy way and learn doing some small games with nice results. The drawback is that it isn't C++, and you'll probably have to go back to the basics when doing bigger games.
- Or you could go the hard way right off the bat. Start with C++, and make your way slowly into making games.

That's how I see it, anyway.

Well since this is a C/C++ board my vote is for C/C++.

Why would you ask what language to use when most of us here clearly love C/C++ more than is probably healthy for any programmer?

Quote:

---

Originally Posted by Bubba

Well since this is a C/C++ board my vote is for C/C++.

---

Ditto. But to add an element of non-self-interest, I only program in C, not C++ ('cause its just silly :p), but I've been working on a game (in POSIX C) and would definitely say that community is overwhelmingly C++ AFAICT so if you want to live in Italy, you should learn ___ian.

Elysia's comment about "large projects" is interesting: by tonnage, the Titanic would definitely be a C++ project, whereas a large marine diesel engine (say you have an OS, where the game is played -- the game actually dwarves the OS in terms of resource usage) would be like a C project and by it's nature "smaller".

Just google "game programming <<insert name of language here>>>"

Example
News pygame - python game development
PythonGames - PythonInfo Wiki

Quote:

---

Originally Posted by MK27

Elysia's comment about "large projects" is interesting: by tonnage, the Titanic would definitely be a C++ project, whereas a large marine diesel engine (say you have an OS, where the game is played -- the game actually dwarves the OS in terms of resource usage) would be like a C project and by it's nature "smaller".

---

I would also say a lot of operating systems were created before C++ was invented, plus I'll bet some OS code also is C++ behind the scenes.

Games can be serious in a lot of languages; it's all about what you put into it. That being said, C++ with libraries. Don't reinvent the wheel when you're just trying to make a game, unless you're some sort of guru (even then you may spend 5 years creating a sub-par graphics engine, for what?). Even professional game studios in the industry are starting to show interest in open source third party libraries like Ogre, and Boost is well established. Choose a graphics, sound, networking, physics, input, and a few other libraries, and get to work. This is all covered extensively here and at gamedev.

It may be a little more overwhelming than learning C# and XNA, but if you push yourself through it you'll learn more quicker. Big no to Java, there just isn't enough libraries, support, etc. XNA is nice if you want to sort of showcase your skills as a developer, create a small game, maybe try and win one of their contests. I wouldn't invest in it as a serious platform for future game development; at least anymore than C++. There's always exceptions, with really nice/addictive gameplay that can pull it off in XNA on Xbox 360, or Flash on a site, or game for iPhone, and be considered professional and successful. Choose your game, then choose your requirements, then your language. Of course it helps to know some languages first xD but do you think the designers know them? No, they figure out their specific requirements after the basis of their game, and don't have to know anything about the language other than it's a tool to get the job done.

Thanks for the replies all :)

@Elysia: Guess I'll be buying some books in the near future! Prob gonna start with the recommended "C++ without fear"

Prob just use the compiler I get with that for now.

This may sound dumb to people in the know, but does the fact that have done a fair old bit of Access, Excel and Visual Basic help at all? I'm also from a very technical background focused on electronics and such.

@bubba: Fair point lol

Sorry you posted as I was writing this one Dae. Ok, sorry I may not have understood that one. Are you saying go ahead and learn C++, but I'd have to be a bit of a maniac to ignore all the resources available in *cringes expecting a telling off for bad wording* plugins, libraries and the like.

I don't know what "compiler" it comes with, but I'd recommend Code::Blocks + gcc (mingw) or Visual Studio as your IDE / compiler. They are usually the most popular ones, and for good reason.

The fact that you've programmed before does help, obviously. There is more to programming than merely syntax. That said, you still have a tough future ahead of you since C++ isn't exactly easy to learn, nor is game programming.
But still, you have this forum's entire resources at your disposal. If you run into problems, use them. Many members here are happy to answer questions or doubts.

Sounds like an excellent place to start! I hopefully I'll be coming up with some good questions soon then :)

Wonder if anyone I know has a book I can borrow so I can get started right away?

Oh, while I'm asking, are there any good qualifications in C++, like CCNA sort of quals.

I'm NOT doing this just to bicker, bare with me and I'll get to the real reason :p

Quote:

---

Originally Posted by Elysia

I would also say a lot of operating systems were created before C++ was invented, plus I'll bet some OS code also is C++ behind the scenes.

---

Technically, the first statement is FALSE.

I'd say one very major reason for C++'s popularity would be the libraries more than the core syntax, and those libraries perhaps lend themselves more to high-level end user applications, which is where C++ tends to predominate. OO API's are a boon, no doubt, for many such things.

The point being choose the tool for the job; your implication that C++ would be a better choice "universally" for anything and everything is just wrong-headed; by that way of thinking, modern interpreted languages like python and perl would be much better for a lot of things that remain C++ purely out of tradition (because those are the veteran developers) and MOST IMPORTANTLY because of business concerns (you can close source compiled product).

Basically, I agree the OP should go with C++ but I think it is stupid of you to foster a mentality I often perceive amongst neophyte C++ programmers whereby a language they have never spent any serious time with (C) is useless or atavisitic, simply because they cannot comprehend writing a serious project without OO. No surprise: they have never tried to do so and then universalize their subjectivity because they work within myopic and self re-enforcing cliques. Which is a limitation of theirs, not anyone else's -- don't encourage it, it's banal, pointless, and annoying.

I have no idea what you're ranting about.
There is one thing I did make out. I wouldn't recommend a big project with C because it is complex, and using another language such as C++, Java, whatever tends to be more trivial because these languages were designed for big modern applications in mind.
C has its world where the absolute low-level, close to the hardware is needed.

These are usually the use the right tool for the job descriptions of the languages. But sure, you can use C for whatever you want, just as any other language. But again, consider the right tool for the job principle.

Quote:

---

Originally Posted by Elysia

I have no idea what you're ranting about.

---

This is what I'm ranting about:

Quote:

---

There is one thing I did make out. I wouldn't recommend a big project with C because it is complex, and using another language such as C++, Java, whatever tends to be more trivial because these languages were designed for big modern applications in mind.

---

There is some truth in this, but it hinges on what you mean by "big". "Big" here would mean the kind of project that no one is going to be involved in for at least several years from when they start if not more, at which point they will be knowledgeable enough to make their own decision and someone saying "oh, of course you should use C++ for that" will be just silly. At this point they will also recognize that lots of people do big projects in C and aren't complaining about it.

But by spouting this rhetoric in C++ programming 101 you are creating a false impression amongst the naive. You are trying to create a mystique.* They end up with the belief that anything over a few thousand lines is "big" and therefore unsuited to C. This is not reality. It just sounds like some kind of defensive/argumentative meme that has propagated itself like a virus in insular communities. It's probably rooted in history, from a time when C++ was new and no doubt poo-pooed by traditionalists and conservatives. It does not foster open mindedness, it's reactionary nonsense and it fosters morons who are no where near working on a "big" project but believe what they are doing is more complex than anything done with C, simply because they are using C++, which is terrible because it reifies the method over the task. They think they are somehow working on some magical level and are now lightyears beyond the dumb cavepeople who wrote their operating system for them. That's pure ignorance.

My last example of this was some dufus on a web-dev forum who tried to explain to me that C is not a modern language and needs to be replaced. When I informed him that people had been trying hard and failing at that for decades, and that most of what makes web-dev possible are big modern applications written in pure C, his response was, "well it's a fine minimalist thing like Go, but eventually people have to move on and play something else".** My response to his response was that after we invent a better Go, we should invent a better Chess and maybe a better wheel, too, which the wheel is so venerable it's amazing vehicles still roll around on them.

You are a C++ programmer. Be happy, do your thing, and quit trying to put everyone else down: if you were so sure of what you were saying (which you shouldn't be, because you're wrong) you would not have to say it. It cannot be meaningful except in a fantasy sense to beginners and it is patronizing and dumb for people with more experience. It is completely childish to go around saying every big modern application not written in C++ was done that way because the developers didn't know any better. In reality, other people have done far more impressive things in both languages than (chances are) you or I will ever do. I'm sorry you are upset by the fact that many people have preferred C and are on some kind of mission to correct them.

Quote:

---

C has its world where the absolute low-level, close to the hardware is needed.

---

Hardware is always needed, Elysia. I agree that if I did not have to run programs on a computer, I would be happier with a much "higher level" language completely abstracted from little details like memory management.

Quote:

---

But again, consider the right tool for the job principle.

---

Of course, which I think comes down to: If you want to live in Italy, learn Italian. If you want to program games, learn C++. No doubt, there are Italians who will argue that the reason Italians speak Italian is because Italian is the best language in history, but that is pompous and ridiculous, esp. considering most of them speak only Italian fluently.

* maybe you've fallen for it yourself.
** and nb. this was a Java developer who's "truth" was that C++ was just as clunky and backward as C and hampered his ability to program properly because it is not good enough for a smart guy like him.

Wow epic argument :) All points from either side noted!

Ok, I've started up reading "Thinking in C++" and it's making a great deal of sense to me, am I likely to get confused soon or if I'm getting concepts should I plod on?

If it makes sense to you :) and "plod on". If you're wrong, you'll find out later, to a certain extent that is inevitable, that's why you don't begin as an expert.

Quote:

---

Originally Posted by woody_294

Ok, I've started up reading "Thinking in C++" and it's making a great deal of sense to me, am I likely to get confused soon or if I'm getting concepts should I plod on?

---

Just plod on. Once you have acquired basic programming skills by becoming proficient in using one programming language, it becomes easier to learn new programming languages, even if they focus on different programming paradigms.

@MK47:
Let's see if I can summarize what you mean to say.
- Simply saying use C++ over C for big projects is misleading due to a number of factors. Essentially, you are trying to say that it depends on the project needs, and whatnot.
- You are implying that I am implying that every non-C++ program was made by developers who were naive. That they really should have been using C++ because it's superior.

Now, to correct those points.
I am not going to go through all the trouble to emphasize in words when C++ probably is a better tool than C. I'm quite content to say that usually C++ is better suited for a task than C, especially for larger applications. Because C++ has been designed for more modern needs.
For the second point, I am implying nothing of the sort. Programs have been designed in a specific language due to business specific factors. It's life. Could they have used a better language? Could they have made better choices? Does the program suffer because of those decisions to use a bad language (if they did pick a bad language)? Perhaps. Perhaps not. But I am in no way implying that the developers were stupid. Either they chose the language for a reason or were forced due by a number of factors. This is more likely than that they are stupid.

And as for the hardware, I am not sure you get my point. We need a low-level language to handle those kind of platforms. There must be such a language.
Often we see C usually because it's the easiest and cheapest way of making a compiler for a system. I find it a shame, seeing as C++ could fit that job, as well, and providing a richer development environment.

But let's not start an argument over this here. It will only end up in a C vs C++ war, which none of us want, I'm sure. We both agree on the approach the OP should take, so let's keep it at that.

Quote:

---

Originally Posted by Elysia

But let's not start an argument over this here. It will only end up in a C vs C++ war, which none of us want, I'm sure.

---

Well, I won't, since I actually like OO and will probably pick up some C++ at some point because I'll like C with OO. But I don't think it is the be all and end all AND I think you are making it synonymous with "modern needs", which is a snake chasing it's own tail.

As you say, I think generally a choice of languages is made for more pragmatic reasons than what is most ideal in an ideal sense (which that will probably come down to what you are most comfortable with). An example of a pragmatic reason would be that business will always favour compiled languages because they can be close sourced. This is despite the fact that on modern computers, they do not really have much advantage over interpreted languages, but interpreted languages will tend to have a lot of advantages over them WRT to "providing a richer development environment", pretty much because of their nature.

Of course, those interpreted languages have to be written with a compiled one. Higher, and higher, and higher...once upon a time, C was at the top of that chain (not the bottom). We should not be down playing the value of doing of low level stuff (which is implicit in your assertion about "bigger" and "more modern": bigger in what sense? More modern in what sense? A monkey could write a million lines of code given the opportunity, though s/he might need a bureaucracy to help with this now massive undertaking, but so what? I don't buy the "50 000 goofs can't be wrong" bit. And all this stuff is concurrent, not consecutive.)

I am going to plod on!

Ok, am I right in thinking, through reading these posts that there isn't a large difference between C and C++ other than in C++ you use objects, what do you use in C instead of objects? Is the whole thing in one "object"...

I'll stop there, I may be making uneducated guesses into having mistaken preconceptions, lol.

Quote:

---

Originally Posted by MK27

An example of a pragmatic reason would be that business will always favour compiled languages because they can be close sourced.

---

If the software is provided as an online service, that reason would not be relevant.

Quote:

---

Originally Posted by woody_294

Ok, am I right in thinking, through reading these posts that there isn't a large difference between C and C++ other than in C++ you use objects, what do you use in C instead of objects? Is the whole thing in one "object"...

I'll stop there, I may be making uneducated guesses into having mistaken preconceptions, lol.

---

Yes, I think that you should ignore the differences between C and C++ until you are proficient in at least one of them. If you really want to know, then the answer is that objects are used in C as well, but the connotation of what an "object" really means may be different, or may actually be the same, depending on what you are talking about.

Quote:

---

Originally Posted by MK27

Well, I won't, since I actually like OO and will probably pick up some C++ at some point because I'll like C with OO. But I don't think it is the be all and end all AND I think you are making it synonymous with "modern needs", which is a snake chasing it's own tail.

---

I don't make it out to be the one-for-all solution.
Likewise, I do not say it is perfect for all "modern" needs, only it has more tools that a modern developer might want, than say, C.
This is all purely subjective on what you work with, of course, but I usually associate modern with big, complex applications. And I usually associate C++ having the entire subset of C, hence making it a valid replacement (that is, being able to replace, not should) for C, should such a thing arise.

Quote:

---

Originally Posted by woody_294

Ok, am I right in thinking, through reading these posts that there isn't a large difference between C and C++ other than in C++ you use objects, what do you use in C instead of objects?

---

There are some OO type methodologies in C but for simplicities sake let's say there are not: the point is, objects and classes do not make the impossible possible -- they do not permit you to do anything that cannot be done another way.

Doing it another way may be more awkward. On the other hand, OO is not by definition the best way to do something, and often going a more (supposedly awkward) route may be more optimal. OO is pretty great tho, and did revolutionize programming.

Part of the reason OO lends itself so well to game programming is that there are many many different games which all share certain certain similarities, and these basically identical, but fairly complex, high level concerns are easily classed and generisized. As they say, it makes it easier to avoid having to ask people to re-invent the wheel.

IMO, you might as well use OO for everything, because even when it is slightly less optimal, this difference is unlikely to have much real significance on modern computers. Which is also why I said if not for the business concerns, interpreted languages would be used a lot more than compiled ones, and as laserlight implies, they certainly are on the web, partially by necessity.

Quote:

---

Originally Posted by Elysia

This is all purely subjective on what you work with, of course, but I usually associate modern with big, complex applications. And I usually associate C++ having the entire subset of C, hence making it a valid replacement (that is, being able to replace, not should) for C, should such a thing arise.

---

I won't take issue with the second part beyond saying that at this point in time AFAICT reality has put a damper on C++'s portability, but (hopefully) that will resolve itself in time.

Is a modern BIOS or kernel a big complex application? Your kernel and your BIOS are just as modern as your web browser.

If you are just going to measure lines of code and people hours of work, a very low level project written in assembly could easily be as big as the web browser, and conversely, you could do a web browser in perl or python in less time with 1/10th the code base.

If you are going to measure the executable size, it should be noted that smaller is actually better and the reason we can have such massive end user apps is due to the streamlined, maximally optimized foundations they run on. And thanks to modern hardware, fat bloated apps work just fine. But writing a "big" application in this sense is stupid thing to do for it's own sake, so if by modern you mean "conducive to lazy and mindless design", then terrific!

Ie, this "big" thing basically sounds like a big phallic fallacy to me.

A lot of people will look at a computer and say the most "modern" and "impressive" thing on it are the graphics and the interface or whatever. The truth is, all those impressive modern things have been enabled by HARDWARE CAPACITY and have nothing to do with a particular programming language. I doubt the programming has changed to become "more complex and modern" to accomplish these goals -- it is just you can do a much greater quantity of it without worrying about resources.

IMO the most complex and modern applications (such as the web) involve a mixture of C (infrastructure), C++ (end user applications), and tons and tons of interpreted stuff (the glue and the content). Which interpreters are surely "big modern applications" and with a few exceptions (such as javascipt/spidermonkey) those are written in C. Why? I will guess it is a "Keep It Simple, Stupid" philosophy which might be ultra-important on very tight, high performance, incredibly dynamic applications like interpreters, which are completely different from games and interfaces in the sense they are much fewer in number, lean much less on external libraries, and probably highly idiosyncratic (as opposed to generic) in design.

I think maybe instead of thinking, I should have read about it, as I am doing now :)

I'll try to keep my guess work to a minimum in future!

Quote:

---

Originally Posted by MK27

IMO the most complex and modern applications (such as the web) involve a mixture of C (infrastructure), C++ (end user applications), and tons and tons of interpreted stuff (the glue and the content).

---

What??

These web applications aren't event 1/10th as complex to develop as your traditional wages program. And it's not because of choice of compiled languages over interpreted ones. But instead the often very complex business rules and the need for adaptation to new rules that makes these type of projects much more complex.

Meanwhile game development is a lot more complex than web or even business applications. It takes years and large teams of programmers to develop something that is on par with today standards for a game release. And when it is finished, it's often full of bugs yet to be tackled or even discovered.

Web applications are incredibly moronic applications to develop. It's Programming by Lego (tm) most of the time. And while there is no doubt newer technologies are bringing web development to the business reality of current desktop programming challenges, it will still take a few good years before this becomes the norm.

Quote:

---

Originally Posted by Mario F.

What??
These web applications aren't event 1/10th as complex to develop as your traditional wages program.

---

By "web" I did not mean "page" I meant the internet considered as a sum of necessary parts -- servers, browsers, interpreters, user applications.

Also it seems a little far fetched to say that a payroll program is by nature 10 times more complex than (eg) a contemporary web forum. Unless you are paying people in different flavours of sub-atomic particles or something. Of course, I have no doubt you can charge 10 times as much for them, which is good business.

There are elements of games that are quite complicated, but overall I do not think they need to be understood as such simply because of their size, which is what takes the time and people power. Like, a movie trilogy probably takes more resources than a commercial, but they need not be any more complicated (and often aren't). Again, simply making a big fat mess is not impressive unless you are the government, even if you do manage to spend a quadrillion dollars on whoop de do.

As for your absurdist snobbery about web-dev, well I would expect as much Mario ;) Web-dev people have to work in multiple high level languages, some of them as complex as they come, and deal with a very heterogeneous and unstable realm as far as standards go. I'd would love to see you get started on the Google search engine (clearly a moronic assemblage of Lego) and make it work even 1/1000th as well. They deserve like a Nobel prize in data handling or something for that.

Geez, you really wish to continue this, don't you?

Quote:

---

Originally Posted by MK27

Is a modern BIOS or kernel a big complex application? Your kernel and your BIOS are just as modern as your web browser.

---

Yes, they are, and probably even more complex. Therefore, it stands to figure that using a higher level language such as C++ (Java & co are probably not qualified here) would reduce the complexity and the time it takes to maintain and write the BIOS and kernel.
You did a good job at hinting at it yourself:

Quote:

---

If you are just going to measure lines of code and people hours of work, a very low level project written in assembly could easily be as big as the web browser, and conversely, you could do a web browser in perl or python in less time with 1/10th the code base.

---

In other words, the more tools a language provides that we can utilize in a good way, the less hours we have to put into creating and maintaining something.
Put another way: you could give your secretary pen and paper. She could probably do her work, but then again, it would be faster and smoother if she had a computer, no? Because in this case, she could utilize the resources provided by the computer to do a better job in less time. The does, and will, hold true in case of software development.
Let this be my point. For bigger, more complex software, it usually stands to reason that more tools to do your work--and that means tools designed for this kind of work--would make your work more efficient and faster.
For this analogy, you can label the pen and paper C and the computer C++.
Obviously, there are some things that a computer cannot do. For example, you wouldn't put a computer to recruit new people, would you? No, I thought not. In that case you might need something else. We could put labels to that, as well, such as Java or C.
But I hope I do get my point across in that.
I'm too lazy to type all that out in words in a casual reply, however.

Quote:

---

But writing a "big" application in this sense is stupid thing to do for it's own sake, so if by modern you mean "conducive to lazy and mindless design", then terrific!

---

You know very well that's not what I mean.
I hate bloated applications. I hate Microsoft's products a lot, usually because they are so big, bloated and slow!

Quote:

---

A lot of people will look at a computer and say the most "modern" and "impressive" thing on it are the graphics and the interface or whatever. The truth is, all those impressive modern things have been enabled by HARDWARE CAPACITY and have nothing to do with a particular programming language. I doubt the programming has changed to become "more complex and modern" to accomplish these goals -- it is just you can do a much greater quantity of it without worrying about resources.

---

But at the same time, what an application needs to do in today's world is far greater and herein lies my point. Look at Office. It does a thousand things. Writing all that code have taken years. What would it have taken had it all been written in assembly, for example?
So languages have evolved to meet modern challenges. That was also my point. And my point was also that C has not focused on this aspect. It has focused more on being the low-level language for dealing with hardware.

Quote:

---

Originally Posted by MK27

By "web" I did not mean "page" I meant the internet considered as a sum of necessary parts -- servers, browsers, interpreters, user applications.

---

Ah. Did miss your point then.
But I'm unsure as to how relevant that can be.

Quote:

---

Also it seems a little far fetched to say that a payroll program is by nature 10 times more complex than (eg) a contemporary web forum. Unless you are paying people in different flavours of sub-atomic particles or something.

---

It's not far-fetched. Payroll programs are among the most complex business software applications. It may seem it's just a matter of calculating wages, but a quick perusal over the business requirements of such applications along with the Law that regulates the development of these applications and you WILL change your mind.

And then this only for small to mid-size companies with rather simple organizations.

Quote:

---

As for your absurdist snobbery about web-dev, well I would expect as much Mario

---

I literally have no place to put your opinions on my statements. My rubbish is your treasure.

Good god do all posts end up like this?

Quote:

---

Originally Posted by woody_294

Good god do all posts end up like this?

---

All "which language?" threads end up like this, no matter where you go. Shall we debate the merits of English versus Latin?

Quote:

---

Originally Posted by Elysia

For this analogy, you can label the pen and paper C and the computer C++.

---

Why would I stop there? I'd label the pen and paper C, an old electric typewriter C++ (which, thankfully, I never had to use), and the computer perl. I still think nothing beats pen and paper for some things, btw. Like composing on a typewriter (the more modern technology) is definitely not a desire most sane people possess. But this is a very crass analogy.

Quote:

---

So languages have evolved to meet modern challenges. That was also my point. And my point was also that C has not focused on this aspect. It has focused more on being the low-level language for dealing with hardware.

---

It has been a focus of low level developers concerned with hardware, that is not "it's focus". C and C++ are the same thing in this regard anyway. It has also been a focus of many developers who write high level APIs. You are now using modern == high level, which is just dumb. There is a modern low level and a modern high level, high and low do not refer to a progressive evolution from one to the other.

Even after a bunch of posts here (and previous threads) I still have not seen you define what you mean by "modern challanges", which is why I responded to this as simply meaning "is a standard OO interface available"? If you want to keep redefining it until the question is "Is it the programming language known and loved by Elysia? Is the language one Elysia is highly efficient, productive, and proficient at?" then I think I understand what those modern challanges are about (a tishload of expensive and stubborn developers :)).

My point about repeatedly bringing up countless examples of "big modern applications" written in C is not to prove that C is the best language in the world, it's just to demonstrate that many highly capable people besides Elysia have chosen in to work in C, and by some coincidence it is their work (and not somebody else's) which came to occupy that place. So while it may be more efficient and productive for many people (including Elysia) to work in C++, this is a subjective and not a universal truth. There is nothing about C which makes it "inappropriate" for big modern projects; plenty of very successful big modern projects are done using C.

I suppose they are not done they way you would do them, but I don't need to think about the whys and wherefores of that.

Quote:

---

Originally Posted by Mario F.

Payroll programs are among the most complex business software applications.

---

This is like saying pumpkins are one of the biggest kind of squash.

Quote:

---

Originally Posted by woody_294

Good god do all posts end up like this?

---

No, eventually the vBulletin database fails and we have to start again. Basically, the tradition is that (some) C++ people have some kind of hidden childhood trauma about the fact that C still exists. An Oedipus complex that failed, or something. Then they insist on screaming, "My Daddy is dead! My Daddy is dead!" while he's standing there in front of them.

Quote:

---

Originally Posted by MK27

Why would I stop there? I'd label the pen and paper C, an old electric typewriter C++ (which, thankfully, I never had to use), and the computer perl. I still think nothing beats pen and paper for some things, btw. Like composing on a typewriter (the more modern technology) is definitely not a desire most sane people possess. But this is a very crass analogy.

---

I think this is a splendid example.
You prefer the pen and paper, but you also know that it will take longer to get things done with the pen and paper (and maybe even harder to organize)!
That is not to say things cannot be done with pen and paper, it might just take a bit longer.
Excellent point!

Quote:

---

It has been a focus of low level developers concerned with hardware, that is not "it's focus". C and C++ are the same thing in this regard anyway. It has also been a focus of many developers who write high level APIs. You are now using modern == high level, which is just dumb. There is a modern low level and a modern high level, high and low do not refer to a progressive evolution from one to the other.

---

Shall we redefine it as modern high-level and modern low-level then?
C is good for modern low-level (as C++ should also be), while C++ and higher a good for modern high-level?

Quote:

---

Even after a bunch of posts here (and previous threads) I still have not seen you define what you mean by "modern challanges", which is why I responded to this as simply meaning "is a standard OO interface available"? If you want to keep redefining it until the question is "Is it the programming language known and loved by Elysia? Is the language one Elysia is highly efficient, productive, and proficient at?" then I think I understand what those modern challanges are about (a tishload of expensive and stubborn developers :)).

---

Meh. It's about creating software as Office (I mentioned that, didn't I?). Office is obviously so big and complex I imagine it's a nightmare to hold it together! :o
This must then be an excellent point about what modern high-level languages must be designed to solve, then?

Quote:

---

My point about repeatedly bringing up countless examples of "big modern applications" written in C is not to prove that C is the best language in the world, it's just to demonstrate that many highly capable people besides Elysia have chosen in to work in C, and by some coincidence it is their work (and not somebody else's) which came to occupy that place. So while it may be more efficient and productive for many people (including Elysia) to work in C++, this is a subjective and not a universal truth. There is nothing about C which makes it "inappropriate" for big modern projects; plenty of very successful big modern projects are done using C.

---

Of course, they used the pen and paper instead of the computer. So where does that leave us? Well, it probably took them a lot longer to build the software and get it stable. And if they have rushed the schedule, it will probably be buggier or less well built than a similar application in another high-level language in the same time frame.
That is not to say it couldn't be done. It just goes to say that it probably took a lot longer and that it was probably a bigger challenge than if they had used a more suitable tool (and suitable developers for the task), don't you think? Subjective, I think, but I do still think the general principle holds true.

As for the rest...
ZzZzZzZzZzZzZz
I rest my case.

Quote:

---

Originally Posted by MK27

I'd would love to see you get started on the Google search engine (clearly a moronic assemblage of Lego) and make it work even 1/1000th as well. They deserve like a Nobel prize in data handling or something for that.

---

Google certainly utilizes many languages. The back-end programs that actually handle the data directly are C++; then it's interfaced to Java, Python, and more. It's true some web dev can be just as complex as your standard C++ library, not mathematically or algorithmically but thinking at a higher level. As far as algorithms in web dev, it can be complex but only because it should probably be interfaced to a more suited language such as C/C++, Java, etc. Which is what Google, Facebook, etc. do obviously. People who code BIOS and OS are trained and experienced with that task. It's hardly as complex for them as it is for you and me. Even so, I would never say any web dev is as complex as that, and if it is, they are doing something wrong. Of course, does creating the back-end for your website in C++ count as web dev? I would say no, but you can see you can't blanket statement web dev versus other programming.

I do enjoy seeing native programmers attempt transitions like using XHTML, CSS, jQuery, the many different libraries and your choice of web language together effectively. Producing valid, reusable, cross-compatible, simple and effective code. As simple as they are usually you'll end up with awful code. It's like watching a programmer try to design graphics, it usually doesn't end well, as most simply don't think well on both levels. Then there's the jack of all trades.

Quote:

---

Originally Posted by woody_294

Good god do all posts end up like this?

---

I must say it doesn't help having fanatic quotes in our signatures or avatars (ahem Elysia, you ooze C++ fanboi). Then we got people here who exclusively use C, or C++, but never both. Personally, not only do I see both their merit, but would consider both as options for projects until omitted. Many people here will just jump straight to one language. Fanaticism, fanboyism, whatever you want to call it.

All I meant was don't be a masochist, like that guy in in the job section developing Wagrold. Don't go and start reading NeHe thinking you're going to code some custom graphics engine. There's really no purpose unless you plan on making that a career choice (3d engine developer). Even then I'd probably start at a higher level. There's really nothing wrong with C for this project other than libraries. Your project will never be scaled higher than many successful C games, such as open sourced Quake 3. Nowadays you're going to want the options C++ provide for games. There's a good chance you'll just end up writing C with classes style code anyway (meaning you don't fully understand how to utilize C++, which takes time, and the further you go along the more you favor metaprogramming over OO). You could always just ignore templates or classes, or both, if the style fits you better. In many cases I don't see any reason to go fully down to C for games, applications, etc.

If I were just starting, I would be looking into the recently released Unreal Development Kit, or the good ol Source Engine. Start at a high level. Actually achieve something. Start a team or join a team (there's plenty ranging from mods, to professional). If you disagree, well, revert back to previous suggestions.

Quote:

---

Originally Posted by Dae

Of course, does creating the back-end for your website in C++ count as web dev? I would say no, but you can see you can't blanket statement web dev versus other programming.

---

Heheh, I read a blog post on this recently: The ambiguity of “web developer”.

Quote:

---

Originally Posted by Elysia

I think this is a splendid example.
You prefer the pen and paper, but you also know that it will take longer to get things done with the pen and paper (and maybe even harder to organize)!
That is not to say things cannot be done with pen and paper, it might just take a bit longer.
Excellent point!

---

No, in fact what I am saying is that when I write long polished material (like a story or an essay), I find it faster and easier to compose it on paper, then type it out and do some editing and formatting on the computer. That's completely normal, many if not most professional writers work that way (probably most WRT to books).

A naive person who has not done much such composition might say, "Well wouldn't it be better and faster if you just composed on the computer?" No -- for me the transfer phase (from paper to screen) is a very significant editing and revising stage which would only take longer and be less effective done another way, and so also the composition phase.

Quote:

---

C is good for modern low-level (as C++ should also be), while C++ and higher a good for modern high-level?

---

How about modern low level "C++" would be more or less "modern low level C", whereas "modern high level C" would be quite different from "modern high level C++", which sticks a little better to the facts and avoids your subjective politicising.

Quote:

---

Meh. It's about creating software as Office (I mentioned that, didn't I?). Office is obviously so big and complex I imagine it's a nightmare to hold it together!
This must then be an excellent point about what modern high-level languages must be designed to solve, then?

---

Right, and OO is one way to deal with this if it is a very serious problem for you. And it's nice. But if you have enough experience working on big projects without formal classes, then it may not be such a big problem. Not that I'm such a wizard, I'm just extrapolating from these aforementioned fools who think they could not have accomplished "hello world" without defining a new class. After 30 years, they'll still think the same thing about whatever it is they are doing, maybe.

I will admit it is easier to get a handle on an unfamiliar piece of code if it is heavily OO based, because you do not have to squint too hard to discern the logic (which may be even harder to do if everything you work on is heavily OO -- you are stuck flapping your hands around going "but how"?). Once you are familiar with it I don't think this is such a big issue.

Quote:

---

It just goes to say that it probably took a lot longer and that it was probably a bigger challenge than if they had used a more suitable tool (and suitable developers for the task), don't you think?

---

What I meant before and what your statements boils down to is that the tool needs to match the pool of available developers -- if you have a plentiful supply of people who's forte is C++ and C++ satisfies the business model (closed source), why look any further? But you are a little delusional to believe that this state of affairs reflects "the best of all possible worlds".

But I'm not knocking it. I just think you have been misled about "what C is good for" and are passing that mistake on to others.

Quote:

---

Originally Posted by Dae

As far as algorithms in web dev, it can be complex but only because it should probably be interfaced to a more suited language such as C/C++, Java, etc.

---

Only in your mind are those languages "more suited" to complex tasks than interpreted ones. As a rule they are built on a C/C++ foundation and are capable of accomplishing more high level activity in a more compressed fashion == greater complexity.

As for a lot of web infrastructure being C or C++, yeah, and just as well, BUT the reason for this is pragmatic (you have lots of highly skilled programmers available, you can depend on the standards used, and, most importantly, you can close the source*). The only other factor is that compiled executables will still outperform interpreted programs to a degree. But there is no C code left in the executable, this has exactly nothing to do with the nature of the language.

* I'm sorry to bruise your developer's ego this way, but the people who sign your check did not choose C++ because it's so wonderful, they chose it because they must use a compiled language.

Quote:

---

Originally Posted by woody_294

Good god do all posts end up like this?

---

Like how exactly? You mean people debating heatedly about something, instead of being paragons of suave manners and consequently boring and uninteresting?

Yeah. Many threads are like that. No one here is angrily arguing at anyone. It's ok.

Quote:

---

Originally Posted by MK27

>>This is like saying pumpkins are one of the biggest kind of squash.

---

No. It's like saying "payroll software is one of the most complex business applications you can develop".

But because you never done any payroll software and don't even know the requirements for such software, you estimate WRONGLY that you can produce an usually accepted argument about generalizations. Problem is, there's no generalization.

I'll say it again just in case your head is still up your arse: Payroll software is one of the most complex business applications there is.

Quote:

---

Originally Posted by Mario F.

I'll say it again just in case your head is still up your arse: Payroll software is one of the most complex business applications there is.

---

I was not contradicting you, pumpkins are the biggest form of squash. No question!

Ah. Now we're getting somewhere.
We're beginning to form the definition of the right tool for the job.

Quote:

---

Originally Posted by MK27

No, in fact what I am saying is that when I write long polished material (like a story or an essay), I find it faster and easier to compose it on paper, then type it out and do some editing and formatting on the computer. That's completely normal, many if not most professional writers work that way (probably most WRT to books).

A naive person who has no done much such composition might say, "Well wouldn't it be better and faster if you just composed on the computer?" No -- for me the transfer phase (from paper to screen) is a very significant editing and revising stage which would only take longer and be less effective done another way.

---

And to me, that would be a lot slower.
Nevertheless, if you would properly learn (and prefer) to do it on computer instead of paper, it would be faster because I guarantee you can type faster on the keyboard than you can write on paper!

Quote:

---

How about modern low level "C++" would be more or less "modern low level C", whereas "modern high level C" would be quite different from "modern high level C++", which sticks a little better to the facts and avoids your subjective politicising.

---

Ah, but I would class modern low level C++ at least as C++ + C, because you would (or at least I would) use a lot of high-level elements and hide the low-level C stuff in the code!
But sure, I think if we modify that fact, those definitions are cool.

Quote:

---

Right, and OO is one way to deal with this if it is a very serious problem for you. And it's nice. But if you have enough experience working on big projects without formal classes, then it may not be such a big problem. Not that I'm such a wizard, I'm just extrapolating from these aforementioned fools who think they could not have accomplished "hello world" without defining a new class. After 30 years, they'll still think the same thing about whatever it is they are doing, maybe.

---

I think this boils down to the right tool for the job and the right people for the job.
Obviously, it is difficult even for one used to pen and paper to write a story as quick as one used to computers in the same time frame purely because it takes longer to write or type each letter, even if everything else was the same!

I like to classify it as this:
If it's a high-level application, use C++, Java, C#, whichever you know best. If you know C best, think twice. Consider the possibility of learning a higher-level language. If not, use C.
If it's a low-level application, use C or C++, whichever you know best. If it's Java, C#, etc, learn C++ or C.
If it's a simple application, use whatever language you know best.

Quote:

---

Originally Posted by Elysia

Nevertheless, if you would properly learn (and prefer) to do it on computer instead of paper, it would be faster because I guarantee you can type faster on the keyboard than you can write on paper!

---

Yep, which is part of the reason it is better to compose on paper. So in this sense, there is no point in learning to do it on a computer, because "dictation speed" is not the issue, and sitting with a keyboard is much more awkward than sitting with a paper and pen. I also prefer to read books than the screen. I think trying to contradict this one will be like trying to claim you prefer a phone booth to a couch -- maybe, but if so your head is really screwed up.

Quote:

---

Obviously, it is difficult even for one used to pen and paper to write a story as quick as one used to computers in the same time frame purely because it takes longer to write or type each letter, even if everything else was the same!

---

Not if story A is actually enjoyable whereas story B was a piece of half thought out crap. Writing skills are completely different than typing skills. IMO "typing skills" or "computer skills" are a completely irrelevant distraction there. Going with the KISS philosophy, it is important to consider what the nature of your task is. It does not involve a computer, and the computer cannot help you do it better, so the computer amounts to an unnecessary complication. A lot of very famous and/or successful writers cannot type at all. No doubt, a lot of untalented hacks churn out ad copy, PR material, and bland reportage quickly at a keyboard. They might as well, since there is no point wasting time on the activity, which is also true when reading the product.

I can type just fine and think at the computer -- I (almost) never use paper for anything programming related. Except learning, in which case again I'd rather read a book (and the iWhatever will never ever possibly change that, despite the feelings of gadget fetishists, the paperback is a far more miraculous piece of technology). Newspapers would be better on line tho, the news does not require paper.

If composing human language material on a computer made the task easier in the sense that it is easier to do it better (as opposed to faster) we'd all be that much closer to Shakespeare now, but that is very definitely NOT the case.

Quote:

---

Originally Posted by MK27

As for a lot of web infrastructure being C or C++, yeah, and just as well, BUT the reason for this is pragmatic (you have lots of highly skilled programmers available, you can depend on the standards used, and, most importantly, you can close the source*)

* I'm sorry to bruise your developer's ego this way, but the people who sign your check did not choose C++ because it's so wonderful, they chose it because they must use a compiled language.

---

I honestly don't understand what you mean by this. Could you elaborate. Seems to be at the center of your argument, but I'm not sure what you mean by closing the source in the context of C and C++ as opposed to interpreted languages.

Quote:

---

Originally Posted by MK27

...and sitting with a keyboard is much more awkward than sitting with a paper and pen.

...


I think trying to contradict this one will be like trying to claim you prefer a phone booth to a couch -- maybe, but if so your head is really screwed up.

---

Erm, I like to sit at a keyboard when writing the stories, you know...
Pen and paper makes my hand hurt and it just takes so long time -_-

Quote:

---

Not if story A is actually enjoyable whereas story B was a piece of half thought out crap. Writing skills are completely different than typing skills. IMO "typing skills" or "computer skills" are a completely irrelevant distraction there. Going with the KISS philosophy, it is important to consider what the nature of your task is. It does not involve a computer, and the computer cannot help you do it better, so the computer amounts to an unnecessary complication. A lot of very famous and/or successful writers cannot type at all. No doubt, a lot of untalented hacks churn out ad copy, PR material, and bland reportage quickly at a keyboard. They might as well, since there is no point wasting time on the activity.

---

This discussion is only about typing speed. Let all other factors be the same. Skill, the story, etc. Only the typing speed.
Like if I would write with a pen and paper instead of a computer. It just wouldn't be as fast (not to mention my wrist would hurt if I had to write down all that text on paper with a pen)!

I see debates about C vs C++ and C++ vs C and they are all equally as ignorant. Use what works. However my language of choice is C++ and I have no reason to look elsewhere. It fulfills all the requirements that I need and I have a lot of experience with it. Plus it is my personal preference so all in all it works for me.

I find people that are 'language hookers' if you will and pick up this or that new language all the time. The problem I have with those types is that while they have an impressive resume they usually suck in all of the languages. Point being you cannot be an expert at every language - it's just not possible. And although core computer science can be applied to any language it still does not flesh itself out as to be so black and white in the real world. I'm a fairly decent C++ programmer and I also know C#. However, I would not say I'm a professional level C# programmer even though I have done C# professionally. My skill level in C# is not where I think it should be for a C# dev. Now perhaps I am underestimating myself or perhaps it is because I'm comparing my C# experience to the time it took me to become what I would call 'decent' at C++. And I'm not just talking code here or technical stuff b/c that is first or second year stuff. Being good at a language to me means knowing how and when to apply it to solve real world problems. Any monkey can learn syntax but it takes a programmer to apply the language effectively. That skill is not something you learn overnight and usually is the result of many previous failed design attempts.

My advice is to learn languages but pick one, perhaps two, as your core language. You can't and won't be great at all of them but you can focus your efforts on a few of them and come out looking pretty good. Programming is a lot more than just writing code in this language or that.

Quote:

---

Originally Posted by Elysia

This discussion is only about typing speed. Let all other factors be the same. Skill, the story, etc. Only the typing speed.

---

You are now saying, "Let's just presume I am actually an awesome cook, so I know how to make great food, and now reconsider my argument about how the microwave is much more convenient and I make my best food thanks to the ease and convenience of the microwave. Then we can prove only losers cook with gas."

I'm afraid I can't give you that, Elysia. It makes much more sense for me to believe that you have little or no interest in cooking (which is totally fine) but are fascinated with technology (also fine) so you would be a great candidate to do authentically enthusiastic infomercials about microwave ovens.

Quote:

---

Originally Posted by Mario F.

Seems to be at the center of your argument, but I'm not sure what you mean by closing the source in the context of C and C++ as opposed to interpreted languages.

---

Consider web technology: since server side interpreted programs remain on the server and are not exposed to the public, the source can remain secure. And lo and behold, the biggest realm for interpreted language programming is server side programming!

Why don't they continue to use C/C++ or some other compiled language? Because they don't have to. Otherwise PHP, etc, would not even exist. That stuff could be completely replaced with C/C++. Hold your breath. DAE's argument that the quality of the code is worse has nothing to do with the language, as we know, and everything to do with inexperienced developers.

The REAL reason you need to use a compiled language with commercial software is so you can distribute product with no source code. That is not possible in perl or python -- the program is the source code. All this stuff about performance and my favourite syntax is tripe, or 80-90% so.

Another big reason is this one:

Quote:

---

Originally Posted by Bubba

you cannot be an expert at every language -- my language of choice is C++ and I have no reason to look elsewhere.

---

And it is totally a good reason, but this does not make C/C++ (or any compiled language) the ultimate omega language. Compiled languages and their experts are a necessity, and I don't think anyone is in a big rush to create a new one.

But, while the realm for compiled language programming will (by necessity) always exist, it is shrinking, just like the realm for assembly did. As DAE points out, Google loves python and it is rapidly replacing C++ in a lot of other areas too, me thinks -- like a lot of new projects that once upon a time would have been C++ are now python, but of course they are generally open source (and probably pre-empt or replace closed source alternatives). This is precisely because of the "development advantages" Elysia has been plugging. They are simply much more pronounced in python, so people who like to program in C++ often enough end up liking python even better. Or else they skip C++ (skip C!) and go straight into that new niche.

Quote:

---

...compiled language with commercial software is so you can distribute product with no source code

---

That's not entirely accurate when it comes to C#. It is compiled but into MSIL which is very simple to reverse engineer since there is a 1 to 1 translation from C# to MSIL. In order to get a true binary C# must be compiled into native machine code and then you lose most of the size and speed benefits of C#. At that point it looks pretty much like C/C++ does when it is compiled to machine code and it must bring in all the libs it relies on - which is usually far more than C/C++ relies on.

Quote:

---

Originally Posted by MK27

But the REAL reason you need to use a compiled language with commercial software is so you can distribute product with no source code. That is not possible in perl or python -- the program is the source code.

---

Possible inconsistencies in the exact version of the Python interpreter aside, it is possible to distribute a Python program without distributing the source code, i.e., by distributing the compiled bytecode. It is also possible to embed a Python interpreter in order to avoid an interpreter incompatibility. In theory, there is no reason why the same cannot be done for Perl.

Consider also why a product like Zend Guard exists for PHP: server side scripts are distributed, and the developer may wish to avoid giving out the source code.

EDIT:
Oh, and then there are tools available to translate Python code into native executables rather than just Python bytecode. Again, this could be applied to any language whose programs are otherwise normally interpreted from source at run time.

Quote:

---

Originally Posted by MK27

They are simply much more pronounced in python, so people who like to program in C++ often enough end up liking python even better.

---

Except me :(
I don't like python.

Quote:

---

Originally Posted by MK27

Only in your mind are those languages "more suited" to complex tasks than interpreted ones. As a rule they are built on a C/C++ foundation and are capable of accomplishing more high level activity in a more compressed fashion == greater complexity.

---

If the Google Search Engine back-end were in Python, I would imagine it would be down more than these forums. It probably wouldn't even run. Sorry to break it to you. Three words: GIL. Honestly, Python just isn't fast enough for the massive amount of data Google processes (it's quite astounding), generates algorithmically, etc. It's much better at scripting the actions of an already existing solution, working with the data, etc.

I'm not saying run to the lower level at the first sign of any complexity, it's really a rare case, especially in web dev.

Quote:

---

Originally Posted by Dae

I must say it doesn't help having fanatic quotes in our signatures or avatars (ahem Elysia, you ooze C++ fanboi). Then we got people here who exclusively use C, or C++, but never both. Personally, not only do I see both their merit, but would consider both as options for projects until omitted. Many people here will just jump straight to one language. Fanaticism, fanboyism, whatever you want to call it.

All I meant was don't be a masochist, like that guy in in the job section developing Wagrold. Don't go and start reading NeHe thinking you're going to code some custom graphics engine. There's really no purpose unless you plan on making that a career choice (3d engine developer). Even then I'd probably start at a higher level. There's really nothing wrong with C for this project other than libraries. Your project will never be scaled higher than many successful C games, such as open sourced Quake 3. Nowadays you're going to want the options C++ provide for games. There's a good chance you'll just end up writing C with classes style code anyway (meaning you don't fully understand how to utilize C++, which takes time, and the further you go along the more you favor metaprogramming over OO). You could always just ignore templates or classes, or both, if the style fits you better. In many cases I don't see any reason to go fully down to C for games, applications, etc.

If I were just starting, I would be looking into the recently released Unreal Development Kit, or the good ol Source Engine. Start at a high level. Actually achieve something. Start a team or join a team (there's plenty ranging from mods, to professional). If you disagree, well, revert back to previous suggestions.

---

Fair one, I've been doing some level design on the L4D SDK and it was fun, I'm probably going to be doing some of that stuff too, along with maybe some 3D modelling etc, I just don't know which bit of developing I want to do yet :)

Quote:

---

Originally Posted by Mario F.

Like how exactly? You mean people debating heatedly about something, instead of being paragons of suave manners and consequently boring and uninteresting?

Yeah. Many threads are like that. No one here is angrily arguing at anyone. It's ok.

---

Fair one, I wasn't really expecting the war :) I guess I thought it was a little more structured in what language you use for what, it seems that you can use lots of different languages for one purpose. I think I'm after a language to learn to get me into programming, hopefully one I'll use so it can be my main one. I can see myself learning C among others (I know some of the equipment at work uses Oracle/SQL) aswell but I think I'm gonna use C++ as my entry point.

Then I can come back and give you lot some stick ;)

P.S. Sorry if i miss something directed at me some of what I'm reading is a bit alien to me and I might get lost in it!

Nothing has been directed at you yet, that you have missed... don't worry.

Thanks Elysia, I'm a bit dazed and confused atm, lol.

Quote:

---

Originally Posted by MK27

Consider web technology: since server side interpreted programs remain on the server and are not exposed to the public, the source can remain secure. And lo and behold, the biggest realm for interpreted language programming is server side programming!

---

There's indeed a problem with distributing your work if it's based on web technologies. Python wasn't a good example for the reasons Laserlight mentioned. But you can argue for PHP for instance, and I would agree.

However, companies wishing to distribute projects developed in, say PHP, can protect themselves by adopting different methods of distribution and making use of properly written EULAs. Ultimately, they may not even distribute the software, but instead just the service. On the other hand, these type of languages do not respond well to just any type of development. Their problem domain is very limited and not that well compatible with the notion of software distribution in the first place.

[quote]The REAL reason you need to use a compiled language with commercial software is so you can distribute product with no source code.[quote]

No. The real reason is probably an historical one. Compiled languages simply had a stronger impact in software development history. C and C++ specifically, took the development community by storm and contributed enormously to increase the focus on compiled solutions as a "standard" for performance and control over the end result.

Interpreted languages (which can also be distributed without source) are still struggling to get accepted as de facto solutions to real-life computing by even the open source community on most cases. There's no reason whatsoever for, say Firefox, to not have been developed in Java. But the end result would probably not have made it one of the most successful OS projects to date.

Quote:

---

But, while the realm for compiled language programming will (by necessity) always exist, it is shrinking, just like the realm for assembly did. As DAE points out, Google loves python and it is rapidly replacing C++ in a lot of other areas too, me thinks -- like a lot of new projects that once upon a time would have been C++ are now python, but of course they are generally open source (and probably pre-empt or replace closed source alternatives). This is precisely because of the "development advantages" Elysia has been plugging. They are simply much more pronounced in python, so people who like to program in C++ often enough end up liking python even better. Or else they skip C++ (skip C!) and go straight into that new niche.

---

There is nothing in the compiled nature of C++ that is making it less useful. What is displacing C++ in certain areas is not the fact it is compiled. Instead it's the emergence of high-level languages (interpreted or not) that can produce similar results in a lot less development time in key problem domain areas. And this is not Python for sure. Python's problem domain is rather small in comparison. Instead generic programming languages like Java, Delphi, VB, or C#. Some more successfully than others.

What really moves languages about the ladder of "popularity" is their ability to deliver more in less time and with less effort. Many of the languages that can compete with C++ are themselves compiled and this has no effect on their ability to displace C++.

A programming language like C#, being marketed the way it is and by who they are, has the potential to all but completely wipe out C++ from traditional GUI-based software in the Microsoft platforms. It's just impossible to negate the advantages of C# (supported by the .Net Framework) over C++ on this area. It's overwhelming. And even more because if there is a need for a performance-critical backend, C# can interface with C++ on those areas where it will make a difference.

This has nothing to do with the fact C# is interpreted or not. Programmers don't really give a rat's arse to that. They don't even care about the fact the resulting MSIL that gets distributed is a dead giveaway to their source code. There's enough tools to obfuscate and even compile to native code. It is simply the fact they can build a complex GUI application in a fraction of the time it would take them in C++ with any of the current frameworks and without the complexity involved in library dependency that is the hallmark of C++ development.

Quote:

---

Originally Posted by Dae

If the Google Search Engine back-end were in Python, I would imagine it would be down more than these forums. It probably wouldn't even run. Sorry to break it to you. Three words: GIL. Honestly, Python just isn't fast enough for the massive amount of data Google processes (it's quite astounding), generates algorithmically, etc.

---

I have no doubt about that, I just brought up Google to point out to Mario that programming the web is not all kiddy stuff. Altho "generates algorithmically" kind of implies the data is somehow too complex to deal with any other way, as opposed to simply being of incredible volume. You keep trying to slyly imply that python (which I have no personal attachment to) is maybe too simplistic to do grown up work when the issue is not related to that at all. This is more of that mystique++ malarky. The same algorithms are possible either way, just what is a barely noticeable performance issue under normal circumstances might be somewhat more severe if you are talking about dynamically indexing the entire WWW.

Like I have seen more than one person cboard who has absorbed some piece of nonsense about the limitations of using interpreted languages, and now they are real neophyte C++ programmers no one can tell them anything different (the "see no hear no speak no" monkey).

How many people are currently working on a project that involves the amount of data Google processess? How many people have ever worked on a project of that scale?

There will always be a need for compiled languages. There is the real and obvious need that somewhere along the line you need a compiled executable. But this does not account for their general predominance -- I think that is more because of tradition and the time it takes to develop programming expertise, and very significantly because of the closed source issue.

Quote:

---

I guess I thought it was a little more structured in what language you use for what, it seems that you can use lots of different languages for one purpose. I think I'm after a language to learn to get me into programming, hopefully one I'll use so it can be my main one. I can see myself learning C among others (I know some of the equipment at work uses Oracle/SQL) aswell but I think I'm gonna use C++ as my entry point.

---

And just to be clear I'm not trying to mess with what is a wise decision, I just get tired of the C++ glee club pretending that this is part of the Divine order and thank God they've saved another poor soul from the clutches of the Devil and the deep blue ____. I like programming; for me it is about more than my allegiance to one language over another and people should not be taught this attitude.

Quote:

---

Originally Posted by laserlight

Possible inconsistencies in the exact version of the Python interpreter aside, it is possible to distribute a Python program without distributing the source code, i.e., by distributing the compiled bytecode.

---

I wasn't aware of that about python, in which case it may end up getting genuine "market share".

Ever seen a javascript obfuscator?
Free Javascript Obfuscator

They get almost obscene. But all this only supports my point about how significant issue of restricting source distribution is and how significant a historical factor it has been. And how all this "in the best of all possible worlds" stuff is slightly fantastic idealization.

Quote:

---

Originally Posted by Mario F.

There is nothing in the compiled nature of C++ that is making it less useful. What is displacing C++ in certain areas is not the fact it is compiled. Instead it's the emergence of high-level languages (interpreted or not) that can produce similar results in a lot less development time in key problem domain areas. And this is not Python for sure. Python's problem domain is rather small in comparison. Instead generic programming languages like Java, Delphi, VB, or C#. Some more successfully than others.

---

Well, I think you are downplaying the advantages of interpreted languages, such as easy portability and such. I'd count Java and most/all of those others as interpreted in that sense. They use some kind of interpreter.

Otherwise, I totally agree/was informed by your last post, Mario. The reason I used python as an example is because even in my short programming career I would say over the last 6-12 months I just keep noticing more and more python projects popping up (nb., of course what it is most likely to "replace" is perl, tho the perl interpreter I believe has a number of technical advantages, such as no GIL/concurrency issue). My impression of python is that it looks much more like C/C++, so C/C++ students have probably taken to it. Plus it's new-fangled and has a scarey cool name.

Actually, why are we classing interpreted languages as more portable than compiled ones? Both require that there exists software, one way or another, for the target platform. This Java portability nonsense is rubbish, I say. I have no good evidence of the contrary.
I wouldn't say interpreted languages are more portable than compiled ones...
Rubbish, I say. Rubbish! Let's turn this thread into a 3rd direction too, shouldn't we? It will be fun!

Quote:

---

Originally Posted by Elysia

I wouldn't say interpreted languages are more portable than compiled ones...

---

If the makers of an interpreted language want to make it portable, they concentrate the efforts on their runtime interpreter, leaving (for the most part) the programmers free of that task. Conversely, if the makers of a compiled language want to make it portable, they will have an hard time doing it in the run-time library and the end result is a generic language that puts on the programmer the weight of such task.

This is what is meant generally when it is said "interpreted languages are more portable than compiled ones", and not that compiled languages cannot be equally or more portable than interpreted ones.

Quote:

---

Originally Posted by MK27

I'd count Java and most/all of those others as interpreted in that sense. They use some kind of interpreter.

---

Don't you think you are generalizing a bit to much here? By that logic all programming languages are interpreted in the sense that the cpu interprets the opcodes it is given.
I wouldn't call C# (or any other .net language) interpreted because it is compiled to native code at runtime.
As for java; I don't know how sun's official java vm handles java bytecode, but I have read about other VMs using a JIT compiler.

Quote:

---

Originally Posted by Mario F.

If the makers of an interpreted language want to make it portable, they concentrate the efforts on their runtime interpreter, leaving (for the most part) the programmers free of that task. Conversely, if the makers of a compiled language want to make it portable, they will have an hard time doing it in the run-time library and the end result is a generic language that puts on the programmer the weight of such task.

---

But this is more about implementations than the languages themselves.

Quote:

---

Originally Posted by Mario F.

If the makers of an interpreted language want to make it portable, they concentrate the efforts on their runtime interpreter, leaving (for the most part) the programmers free of that task. Conversely, if the makers of a compiled language want to make it portable, they will have an hard time doing it in the run-time library and the end result is a generic language that puts on the programmer the weight of such task.

---

All the code in the runtime essentially has to be the same as for any compiled language, so I see no difference here. Both the compiled and interpreted languages must define a function in their framework as a series of OS calls.

Quote:

---

Originally Posted by _Mike

Don't you think you are generalizing a bit to much here? By that logic all programming languages are interpreted in the sense that the cpu interprets the opcodes it is given.
I wouldn't call C# (or any other .net language) interpreted because it is compiled to native code at runtime.
As for java; I don't know how sun's official java vm handles java bytecode, but I have read about other VMs using a JIT compiler.

---

They are called interpreted because there is a middle-software, ie a program between the code and the OS, that reads the instructions in the instructions and converts them to machine-specific instructions.
This is as opposed to native binaries where the instructions are machine instructions which are natively fed to the cpu. So I would definitely call C# and Java interpreted languages.

Quote:

---

Originally Posted by _Mike

But this is more about implementations than the languages themselves.

---

I'm not sure what you mean. The implementation is not going to solve any portability issues. These do not steam from a language specification that works differently from one implementation to another. That would be a bad language design. Instead portability issues that arise from compiled languages translate into lack of immediate access to certain portable facilities. For instance, file access.

The solution has to be given by the programmer or the library developer. So it can be said in general that portability issues are easier to deal with in interpreted languages that can develop a language specification that includes all the needed functionality and handle differences between each platform in the runtime layer.

Quote:

---

Originally Posted by Mario F.

No. It's like saying "payroll software is one of the most complex business applications you can develop".

But because you never done any payroll software and don't even know the requirements for such software, you estimate WRONGLY that you can produce an usually accepted argument about generalizations. Problem is, there's no generalization.

I'll say it again just in case your head is still up your arse: Payroll software is one of the most complex business applications there is.

---

Not wanting to dip my toes into this particular boiling pot but I would like to add large-scale insurance systems to payroll systems. Same level of complexity WRT laws, regulatory bodies and so forth and absolutely no place for C b/c C keeps you glued to the code-level whereas C++ or any language that really supports things like OOP from the ground up lets one consider the larger architectural problems and frankly simplifies maintenance. This opinion is based on my experience; yours may vary. I use C for embedded and C++ for larger scale apps. If all you learn or become proficient with is a single language your tool box will only have one tool and you will be forever trying to pound a screw into a board with a hammer....to awkwardly twist an old analogy...

The other misconception I would like to do away with here is that this forum is only populated by C++ 101 programmers....some are and some are not.

Quote:

---

Originally Posted by Mario F.

The solution has to be given by the programmer or the library developer. So it can be said in general that portability issues are easier to deal with in interpreted languages that can develop a language specification that includes all the needed functionality and handle differences between each platform in the runtime layer.

---

Yet, this is not about compiled vs interpreted, but what portable functions in the portable framework different languages provide.
Should C or C++ implement the entire Java framework, they would be just as portable despite being compiled instead of interpreted.
This whole interpreted languages are more portable is still rubbish.

Quote:

---

Originally Posted by _Mike

Don't you think you are generalizing a bit to much here? By that logic all programming languages are interpreted in the sense that the cpu interprets the opcodes it is given.

---

Sure, but they do not require an additional interpreter.

Quote:

---

I wouldn't call C# (or any other .net language) interpreted because it is compiled to native code at runtime.

---

Well, logic kind of dictates that this is true of everything, since nothing runs on the computer unless it is native code. I don't know anything about mono so I can't say in what technical sense the "just in time engine" may differ from (eg) the perl interpreter.

Tho in any case I would say it effectively falls into the class of an interpreted language in the sense I am trying to get at, because it requires a runtime interpreter (or whatever you would like to call it). That process is an added layer of abstraction.

Quote:

---

Originally Posted by Elysia

All the code in the runtime essentially has to be the same as for any compiled language, so I see no difference here. Both the compiled and interpreted languages must define a function in their framework as a series of OS calls.

---

Okay, here's an example. It does not quite reflect a "carved in stone" difference, but I think it is generally the case anyway:

In C, socket programming on the MS platform uses a different API than on unix, meaning you would have to have two different versions of your code, one for each platform. In perl, there is only one socket module* -- the pre-compiled perl interpreter itself deals with platform specific elements. So the exact same program can be run without modification on both platforms.

* actually there's probably six, but they are all the same in the sense they all work the same on all platforms.

Quote:

---

Originally Posted by Elysia

Except me :(
I don't like python.

---

I do but that is why there is more than one language in each language class :)

At the end of the day its gotta come down to what you are more productive with *that meets the needs of the requirements*.

If you are working in a team you often do not have a choice of language, platform, etc; then your choice is to have a Coke and a smile, get good at the teams default language/platform or quit.

So as long as you have the freedom to define all of the project characteristics, go for what you know...once you get out into the corporate world you can kiss that freedom goodbye.

Quote:

---

Originally Posted by jeffcobb

If you are working in a team you often do not have a choice of language, platform, etc; then your choice is to have a Coke and a smile, get good at the teams default language/platform or quit.

---

This is what I meant by the "best of all possible worlds" syndrome. The quote is from Voltaire's Candide, which is a satirical critique of unrestrained, uncritical optimism: no matter what indignity or absurdity Candide is forced to suffer, he insists that it is for the best and only good things will come to him because of it, that he is the apple of God's eye and surely living in "the best of all possible worlds".

Neither I nor Voltaire think this is a wise attitude, but YMMV. The consequence is that if you cannot admit something is wrong, you will never have a chance to fix it.

Quote:

---

Originally Posted by Mario F.

I'm not sure what you mean. The implementation is not going to solve any portability issues. These do not steam from a language specification that works differently from one implementation to another. That would be a bad language design. Instead portability issues that arise from compiled languages translate into lack of immediate access to certain portable facilities. For instance, file access.

The solution has to be given by the programmer or the library developer. So it can be said in general that portability issues are easier to deal with in interpreted languages that can develop a language specification that includes all the needed functionality and handle differences between each platform in the runtime layer.

---

Maybe I am expecting to much of the C++ standards (I haven't read them so I'm just going by what I've heard from friends), but say I am using STL's fstream class for file access in C++. Isn't it required that it behaves the same across all platforms/implementations?
And if it behaves differently under different OSes it would be because of the implementations of fstream are different, and not because the C++ language in it self is less portable than interpreted language X.
Unless the STL isn't part of the C++ standard.. Then I guess this would be irrelevant. :)

As for the "which language" question the topic was originally about; For me, who don't work as a professional programmer and never plan to, the best language is which ever one that I feel like using at the time :D I wouldn't say I'm an expert at any language, or even that I know much about any. But I know enough to get by for my personal needs at least.
Then again I would probably have had a different point of view if I was working in this area.

Quote:

---

Originally Posted by jeffcobb

If you are working in a team you often do not have a choice of language, platform, etc; then your choice is to have a Coke and a smile, get good at the teams default language/platform or quit.

So as long as you have the freedom to define all of the project characteristics, go for what you know...once you get out into the corporate world you can kiss that freedom goodbye.

---

Ah right, lol. Guess I'll just learn one and then expect to have to learn more then!

Just out of interest does anyone know what the Unreal Engine is written in???

*Edit* C++ and Unreal Script, kinda supports my C++ for now seeing as I'm gonna have a crack at doing stuff in UE3 too.

Quote:

---

Originally Posted by woody_294

Just out of interest does anyone know what the Unreal Engine is written in???

---

Yo, woody, when I said the game programming community is predominately C++ I was not joking around. If that is what you are interested in, don't have any doubts, C++ is what you want to start learning, you are in good company, there is no question that it occupies a central place in contemporary programming and the history of computing as a whole. You'll learn lots from it and have a good time.

Other languages become most interesting once you already know one, so don't worry about anything else for now. But PLEASE don't end up a myopic snob like Elysia :p

Quote:

---

Originally Posted by _Mike

Maybe I am expecting to much of the C++ standards (I haven't read them so I'm just going by what I've heard from friends), but say I am using STL's fstream class for file access in C++. Isn't it required that it behaves the same across all platforms/implementations?

---

Of course. But fstream doesn't help you handle other platform specific tasks tied to file access, like reading file properties, traversing directory structures or file searching operations. These were more the type of things I meant. But there's other examples if somehow you are missing the point, like the aforementioned sockets programming, or multi-threading. All are strictly platform specific.

C++ is a portable language of course. Undeniable. However the difficulties of keeping it portable are reflected on the fact it is your code that needs to be portable. Necessarily this has been eased through the years with plenty of libraries that were made available by other programmers.

However, with interpreted languages that want to be portable, the programming language creators can devise a more friendly environment for the programmer that doesn't force them to think much about portability issues when writing code for more than one system, because they can delegate all platform specific issues to the runtime interpreter/compiler. They can even start to think in terms of the compile-once-run-anywhere paradigm (think, not necessarily succeed).

...

But I'm not making a case for interpreted languages and against compiled languages. I'm just answering Elysia indignation about the phrase "interpreted languages can be more portable than compiled languages" and what's the usual context of that phrase. Interpreted languages advantages have been also their downfall because with that they loose their ability to tackle with the system at a lower level or offer acceptable performance levels, often needed in many problem domains. Hence why C# or Java can't beat C++ on game development for instance, or why none of these languages could efficiently be used on many embedded systems or be used to emulate these systems, or even be used to create an efficient compiler, operating system, or even a GUI.

Quote:

---

Originally Posted by woody_294

Ah right, lol. Guess I'll just learn one and then expect to have to learn more then!

Just out of interest does anyone know what the Unreal Engine is written in???

*Edit* C++ and Unreal Script, kinda supports my C++ for now seeing as I'm gonna have a crack at doing stuff in UE3 too.

---

Woody: Learn the language now that helps solve your problem *now*. The second (and third, etc) will be only a fraction of the effort if you know your first one well because there are concepts that are the same in almost every language.

Except Visual BASIC. Complete waste of time.

<smile> Just tweaking my Windows comrades...

Quote:

---

Originally Posted by MK27

This is what I meant by the "best of all possible worlds" syndrome. The quote is from Voltaire's Candide, which is a satirical critique of unrestrained, uncritical optimism: no matter what indignity or absurdity Candide is forced to suffer, he insists that it is for the best and only good things will come to him because of it, that he is the apple of God's eye and surely living in "the best of all possible worlds".

Neither I nor Voltaire think this is a wise attitude, but YMMV. The consequence is that if you cannot admit something is wrong, you will never have a chance to fix it.

---

I am simply reflecting my reality. What you code for (and by extension how you make your living) reflects yours. I have worked in a number of shops from corporate IT centers to small consultancies to wild, by-the-seat-of-your-pants California start-ups and in not one of them was it 100% my favorite environment; either the OS or the language or the version control system or...whatever was something I would cuss out on a daily basis. That is largely why I took the last year off and just coded stuff that I liked, in my "comfort zone". The realities of life are going to be kicking me back into that world soon and I will probably have to deal with C# or something like that...sigh. Fun while it lasted.

Quote:

---

Originally Posted by MK27

I have no doubt about that, I just brought up Google to point out to Mario that programming the web is not all kiddy stuff.

---

Oh really? You brought it up to point to Mario, not to tell me it was all in my head? You have no doubt about.. my explanation for what was all in my head?

You have no idea what my feelings are of Python. Don't pretend to know, or to generalize me.

I'm done with this. Woody, I'd have to say pay attention to Mario's responses (as always), as sometimes I really can't wrap my mind around these other guys.

Quote:

---

Originally Posted by MK27

My impression of python is that it looks much more like C/C++, so C/C++ students have probably taken to it.

---

You should not say "much more" without providing a basis for comparison. You probably are comparing Python and Perl, but otherwise it is not obvious that Python "looks much more like C/C++" since say, PHP "looks much more like C/C++" than Python. (Heh, PHP even has C++ references with C++ syntax!)

Quote:

---

Originally Posted by MK27

Plus it's new-fangled and has a scarey cool name.

---

Perl is nearly as new-fangled and has a less scary cool name. PHP is more new-fangled, and I guess that its name is retroactively recursively cool :)
Oh, and while we're at it, Ruby is a gem, but I'm not rich enough to buy it :p

Quote:

---

Originally Posted by _Mike

Maybe I am expecting to much of the C++ standards (I haven't read them so I'm just going by what I've heard from friends), but say I am using STL's fstream class for file access in C++. Isn't it required that it behaves the same across all platforms/implementations?
And if it behaves differently under different OSes it would be because of the implementations of fstream are different, and not because the C++ language in it self is less portable than interpreted language X.
Unless the STL isn't part of the C++ standard.. Then I guess this would be irrelevant. :)

---

Incidentally, std::fstream was never part of the STL. The parts of the standard library derived from the STL are mostly those related to containers, iterators and generic algorithms.

Quote:

---

Originally Posted by Mario F.

But there's other examples if somehow you are missing the point, like the aforementioned sockets programming, or multi-threading. All are strictly platform specific.

---

Libraries like Boost and POCO provide counterexamples to a general statement that sockets programming and multi-threading are strictly platform specific with respect to C++.

Quote:

---

Originally Posted by Mario F.

But fstream doesn't help you handle other platform specific tasks tied to file access, like reading file properties, traversing directory structures or file searching operations. These were more the type of things I meant.

---

It is not apparent that the reason why the C++ standard library does not provide facilities to do these is related to C++ being normally compiled rather than runtime interpreted. They sound merely like deficiencies in the standard library.

Quote:

---

Originally Posted by Mario F.

However, with interpreted languages that want to be portable, the programming language creators can devise a more friendly environment for the programmer that doesn't force them to think much about portability issues when writing code for more than one system, because they can delegate all platform specific issues to the runtime interpreter/compiler.

---

The problem is that with a more comprehensive standard library (e.g., what Elysia was talking about in post #61), these issues should also disappear for compiled languages (in theory: every programming language that I have worked with has a platform specific issue somewhere), and in fact these runtime interpreted languages usually do provide these portable facilities as libraries rather than having all these facilities embedded in the core language.

As such, I do not think that citing the incompleteness of these standard libraries supports your point on its own. Rather:

Quote:

---

Originally Posted by Mario F.

Interpreted languages advantages have been also their downfall because with that they loose their ability to tackle with the system at a lower level or offer acceptable performance levels, often needed in many problem domains.

---

The law of leaky abstractions is at work here. I think that the desire to satisfy the many possible uses of C and C++, from low level to high level, with a "perfect design" means that it is difficult to agree on what exactly their standard libraries should support, and how they should go about it (especially in C++), and often in the end proposals are just dropped due to lack of consensus. Part of this is about design by committee, but part of it is also about the purpose of these languages vis-a-vis their typically compiled code.

So, these standard libraries could be more easily made complete if not everyone was satisfied, but then those who need the extreme speed or esoteric features that are limited by a general library API may end up using their own libraries, perpetuating a lack of portability.

Quote:

---

Originally Posted by laserlight

So, these standard libraries could be more easily made complete if not everyone was satisfied, but then those who need the extreme speed or esoteric features that are limited by a general library API may end up using their own libraries, perpetuating a lack of portability.

---

What-if scenarios don't serve us here. As it stands the standard libraries do not serve the full spectrum of the language portability issues. It's a valid point you have there, but I don't see how useful it can be. It belongs perhaps on another debate.

In any case, not all portability concerns in C++ steam from access to specific areas of the machine. The language specification needs to be made platform agnostic and this naturally results in language features that are made portable by the programmer. I'm thinking data types, for instance.

And I insist, I'm only addressing what I have been perceiving is a common cause for the "interpreted languages are more portable than compiled ones" argument. Strictly speaking for any given problem domain, a programming language is either portable or not portable. I.e. It will either serve for a portable solution, or not. There is no such thing as more or less portable. So the root of the argument must lie elsewhere. As it stands, it has usually been the ability of interpreted languages to free the programmer from most portability concerns.

Quote:

---

Originally Posted by Mario F.

What-if scenarios don't serve us here. As it stands the standard libraries do not serve the full spectrum of the language portability issues. It's a valid point you have there, but I don't see how useful it can be. It belongs perhaps on another debate.

---

I am not sure if we understand each other here. This is what I think your argument is: interpreted languages tend to be more portable than compiled ones because the abstractions for portability can be handled by the runtime interpreter.

I do agree with your argument, but I think that the examples that have been cited to support it are off the mark. My argument is that many of these abstractions can be handled by the standard libraries for compiled languages, but in practice they are not fully handled because these compiled languages tend to be more general purpose, and thus it is difficult to fully satisfy all stakeholders, and so in the end none are fully satisfied.

Consequently, citing the disparity in the portability provided by the standard libraries does not support the argument that it is because of the runtime layer that interpreted languages are more portable. One can design a compiled language that does not aim to be so general purpose, and thus design a standard library that ignores "minority" concerns in favour of serving "the full spectrum of the language portability issues".

Quote:

---

Originally Posted by Mario F.

In any case, not all portability concerns in C++ steam from access to specific areas of the machine. The language specification needs to be made platform agnostic and this naturally results in language features that are made portable by the programmer. I'm thinking data types, for instance.

---

Yes, I am actually quite surprised that you did not raise the issue of built-in types with implementation defined ranges earlier as compared to portable libraries, they are a more obvious and far better example of the benefits of a runtime interpreter that provides a virtual machine. It is because I have this in mind that I can agree with your argument.

By the way, "steam" should be "stem".

Roger dodger all, expect to see me in the C++ forum, or back in this one, asking questions at a later date!

Or, god forbid, answering one, which doesn't sound likely for a fair old while lol

Quote:

---

Originally Posted by Mario F.

Hence why C# or Java can't beat C++ on game development for instance, or why none of these languages could efficiently be used on many embedded systems or be used to emulate these systems, or even be used to create an efficient compiler, operating system, or even a GUI.

---

This is more of the lopsided ignorance. I am sure perl could be used to create a highly efficient compiler (I'll bet it's even been done); one of it's claims to fame is not just the string handling potential of the syntax, but that it cannot be outpaced doing it because of the nature of the underlying C code (ie, a perl program will be as fast as a C/C++ program at string processing).

Which "string processing" is a pretty broad realm. The people who wrote POGL (the perl openGL bindings) claim that

Quote:

---

General Purpose GPU (GPGPU) processing is one area in which Perl can be compared with compiled languages in terms of performance.

Based on their own benchmarks, Perl OpenGL developers claim that there are no significant performance differences between C and Perl (via POGL), when rendering a realtime 3D animated object with dynamically generated texturemaps.

---

which is a pretty fancy claim and I have not seen it refuted either.

As for creating an OS, well, most people would agree the only realistic choice there is a compiled language.

As for GUI's: IMO this is exactly the kind of thing interpreted languages are perfect for. Again, my experience is specifically in perl (having done GUI work in C and perl): I have never seen nor heard of a GUI application that could not be done just as well in perl as it would in C/C++, and with a fraction of the codebase. You clearly have never used these languages, Mario, and have a completely corrupt understanding of what they are about.

All GUIs in Perl that I have seen have been butt ugly.
Or was it Python?

Quote:

---

Originally Posted by Elysia

All GUIs in Perl that I have seen have been butt ugly.

---

There are gtk and I think wxWidget API's, which means they look exactly like other GUI's because they use the same libraries.

You would not even know they were perl (or python, or ruby, or believe VB), is the point. The "appearance" is in the library and most of those are not language specific.

Quote:

---

Originally Posted by MK27

This is more of the lopsided ignorance[...]I am sure perl could be used to create a highly efficient compiler (I'll bet it's even been done); one of it's claims to fame is not just the string handling potential of the syntax, but that it cannot be outpaced doing it because of the nature of the underlying C code (ie, a perl program will be as fast as a C/C++ program at string processing).

---

You say I'm ignorant and then base all your argument for perl being able to create "highly efficient compilers" (your words, not mine) in such a trifle issue as string processing? Part of the reason why most people don't take you seriously anymore.

Quote:

---

As for GUI's: IMO this is exactly the kind of thing interpreted languages are perfect for.

---

Only... I didn't mention GUIs. I said GUI Libraries. But I guess you have no idea what I'm talking about. And comparing C with Perl in terms of access to GUI based material is really a motivating factor to put you back on my ignore list. You are just too weird for me.

Quote:

---

Originally Posted by Mario F.

You say I'm ignorant and then base all your argument for perl being able to create "highly efficient compilers" (your words, not mine) in such a trifle issue as string processing? Part of the reason why most people don't take you seriously anymore.

---

I wasn't aware that they had started :p. Anyway, I'll stand by my statement on this one. Stage 1 of compilation is 100% about string processing and so is a lot of the rest. Unless you want to interpret "string processing", or data parsing, in a naive way, in which case we are just arguing semantics and the underlying truth of what I've said remains the same.

Quote:

---

Only... I didn't mention GUIs. I said GUI Libraries. But I guess you have no idea what I'm talking about. And comparing C with Perl in terms of access to GUI based material is really a motivating factor to put you back on my ignore list. You are just too weird for me.

---

Actually, you said "even a GUI". As usual, when someone points out you are lying or extremely wrong, you turn around and try and pretend you never said exactly what you said.

As for my opinion about GUI programming, I do it, mostly in C, I understand how it works, and I'll stand by statement on this one even more firmly: interpreted scripting languages are *perfectly* suited to it, and no ridiculous delusion of yours will change that.