Thread: Which language?

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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

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

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.

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

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.

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:

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.

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.

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

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