Is there any disadvantages to a language being platform independent?_问答_开发者

I'm working on a paper about multi-platform programming and I'd like to include sections on advantages/disadvantages. From my understanding; having any application be multi-platform is a huge selling point for the developer since it enables almost any computer user as a p开发者_开发知识库otential buye, among other things. I'm just trying to figure out possible disadvantages. If any?

Generally on a multi-platform environment you will need an additional level of abstraction between the language and the machine such as an interpreter or the JVM. This additional level tells the specific machine how to run the code in its environment and brings more code that your computer has to run to handle a given set of instructions. Because of this, multi-platform applications are generally slower.

The logic behind this is instead of coding the same application many times for each environment, you create an interface of sorts for coders to program for. Each platform needs its own implementation of this interface but is intended to run code in a uniform way.

Also, while this layer is intended to provide universal behavior on multiple platforms you may still need to take into consideration differences in naming conventions and file storage from one platform to another.

Web browsers are the most widespread example of this. If you have a good browser, it interprets web standard code (HTML/CSS/JS etc) and takes care of how to display it on your particular platform instead of the code writer needing to accommodate for these differences.

Are there disadvantages to a language (asked in the title) being platform-independent?

As a language implementor, I have to say that making something run on multiple platforms is a lot more work. Most of the extra work is in the run-time system. Making something platform-independent is even harder; you have to stick to some very widely used standard like ANSI C.

I should add that you don't necessarily have to write a lot of code; you just have to think harder. Lua is a good example of a platform-independent language without a monster large implementation. GHC is the opposite: lots of code to get great performance on many platforms—but the run-time system alone is four times the size of version 6 Unix!

How about "Jack of all trades, master of none"?

Having a language designed and implemented on one platform allows the design to be tailored for that platforms. Also, resources are usually limited, so implementation and debugging are focused on one rather than many platforms.

This doesn't apply to community efforts where resources are in abundant supply, such as Perl.

Major disadvantage - you can't use platform specific enhancements...

This is a more philosophic question - where is the boundary between language abilities and compiler abilities...

you can write directx code.. but in order for the same result occur in Linux...

Primary disadvantages are:

Extra time to develop due to platform differences (e.g. filesystem access differs on different platforms)
Much more testing required and hence much greater expense to test on multiple supported platforms.

It many times makes a language less feature rich, or alternatively slower due to the need for a larger and more complex runtime. Most languages manage to pull it off decently well, but there's a couple out there that likely did not benefit from implementation across platforms.

Common Lisp is like a case study at this! :-)

In some ways, they got it pretty much right: there are some things that seem odd from a theoretical perspective but enable modern non-specialized processors to implement it quickly. For example, there are some nonsensical arithmetic expressions which are allowed to return garbage instead of signaling an error condition, because it can be a lot more efficient that way.

In other ways, they tried to be platform independent, and it just added complexity with little or no gain. One classic example is the pathname subsystem; the make-pathname function signature looks like this:

make-pathname &key host device directory name type version defaults case

Back in the 1980's when it was standardized, it might have seemed reasonable to include native support for very rich filesystems, but I haven't seen a VAX (or any other system with a versioned filesystem) in over 10 years. Today, it's complexity that most people don't care about. (I know pathnames and logical pathnames are technically separate features, but they're not that far off in what they try to do.)

As a programmer, you can never guess what area you'll need flexibility in in the future, or even on what axis you'll want flexibility -- programmers know this well, which is why cheesy words like "agile" have become common. When designing a platform independent language, you're dealing with the worst of both worlds: languages are for abstraction, and platforms are very concrete. Sure enough, every platform independent language is full of a decent amount of suck, from C on up.

Ask Sun. How did the whole Java thing work out for the company? (yeah, I know, sample of 1 and all)

In this case, I am looking at it from a vendor's standpoint. They made a language, which while popular, did nothing to leverage the (actual!) power of the OS they sold. It had to run on Windows, with all of the crippling nonsense that such entails. You want to fork off a child process and open a pipe or two between parent and child? Too bad. Have fun with your thread bugs. Have fun with your dog-slow file I/O. (when, if ever, did Java finally include an "nio" implementation?)

Microsoft of course made no such mistake with .NET. And they focused on better language features, instead of spending resources on multiple runtime implementations.