저는 멀티 플랫폼 프로그래밍에 관한 논문을 작성 중이며 장점/단점에 대한 섹션을 포함하고자합니다. 내 이해에서; 어떤 응용 프로그램을 멀티 플랫폼으로 사용하는 것은 개발자에게 큰 판매 포인트입니다. 왜냐하면 다른 모든 것들 중에서도 거의 모든 컴퓨터 사용자가 잠재적 인 관심사가 될 수 있기 때문입니다. 나는 가능한 단점을 파악하려고하고있다. 만약에 어떠한?플랫폼에 독립적 인 언어에 단점이 있습니까?
일반적으로 다중 플랫폼 환경에서는 인터프리터 또는 JVM과 같이 언어와 시스템 간의 추상 수준이 더 필요합니다. 이 추가 수준은 특정 컴퓨터에 해당 환경에서 코드를 실행하는 방법을 알려주고 주어진 명령 집합을 처리하기 위해 컴퓨터가 실행해야하는 코드를 더 많이 제공합니다. 이 때문에 다중 플랫폼 응용 프로그램은 일반적으로 느립니다.
이 논리는 각 환경에 대해 동일한 응용 프로그램을 여러 번 코딩하는 대신 코더가 프로그래밍 할 수있는 종류의 인터페이스를 만듭니다. 각 플랫폼은이 인터페이스를 독자적으로 구현해야하지만 일관된 방식으로 코드를 실행합니다.
또한이 계층은 여러 플랫폼에서 보편적 인 동작을 제공하기위한 것이지만 한 플랫폼에서 다른 플랫폼으로의 파일 저장과 이름 지정 규칙의 차이점을 고려해야 할 수도 있습니다.
웹 브라우저가 가장 널리 보급 된 예입니다. 좋은 브라우저를 가지고 있다면 웹 표준 코드 (HTML/CSS/JS 등)를 해석하고 이러한 차이점을 수용 할 필요가있는 코드 작성자 대신 특정 플랫폼에 표시하는 방법을 처리합니다.
, 나는 여러 플랫폼에서 실행 무언가를 만드는 것은 많은 더 많은 작업이라고 말해야한다. 추가 작업의 대부분은 런타임 시스템에 있습니다. 무언가 독립적 인 플랫폼을 만드는 것은 더욱 어렵습니다. 당신은 ANSI C와 같이 매우 널리 쓰이는 표준을 고수해야한다.(제목이 묻는 질문) 플랫폼에 독립적 인 단점이 있습니까? 언어 구현으로
필자는 코드를 많이 작성할 필요는 없다고 덧붙여 야한다. 당신은 더 열심히 생각해야합니다. Lua은 몬스터 대규모 구현이없는 플랫폼 독립적 인 언어의 좋은 예입니다. GHC은 반대입니다 : 많은 플랫폼에서 많은 성능을 발휘하는 많은 코드 —하지만 런타임 시스템만으로는 버전 6 Unix의 4 배 크기입니다!
"모든 거래의 잭, 아무도의 주인"은 어떨까요?
한 플랫폼에서 언어를 설계하고 구현하면 해당 플랫폼에 맞게 디자인을 조정할 수 있습니다. 또한 자원은 일반적으로 제한되어 있으므로 구현 및 디버깅은 많은 플랫폼이 아닌 하나에 집중됩니다.
이는 자원이 풍부하고 Perl과 같은 커뮤니티 활동에는 적용되지 않습니다.
주요 단점은 다음과 같습니다
주요 단점 - 언어 능력과 컴파일러 능력 사이의 경계는 ...
할 수 - 당신은
이 좀 더 철학적 질문입니다 ... 특정 플랫폼 향상을 사용할 수 없습니다 directx 코드를 작성하십시오. 그러나 같은 결과가 리눅스에서 발생하기 위해서는 ...
크고 복잡한 런타임을 필요로하기 때문에 여러 번 사용하면 언어 적게 기능이 풍부 해집니다. 대부분의 언어는 제대로 해내 기 위해 노력하지만, 여러 플랫폼에서 구현의 이점을 누리지 못했을 가능성이있는 커플이 있습니다.
Common Lisp은 이것에 대한 사례 연구와 같습니다! :-)
어떤면에서는 이론적 관점에서는 이상하게 보일 수도 있지만 현대의 비 전문 프로세서가이를 신속하게 구현할 수있는 몇 가지 방법이 있습니다. 예를 들어, 오류 상태를 알리는 대신 쓰레기를 반환 할 수있는 무의미한 산술 표현식이 있습니다. 왜냐하면 그렇게하는 것이 훨씬 효율적일 수 있기 때문입니다.
다른 방법으로는 플랫폼 독립적 인 시도를했는데 거의 이득을 얻지 못해 복잡성이 추가되었습니다. 전형적인 예가 경로명 서브 시스템입니다. make-pathname 함수 서명은 다음과 같습니다 :
make-pathname &key host device directory name type version defaults case
(또는 다른 시스템에서 버전 관리 된 파일 시스템을 사용하여). 오늘날 복잡성은 most people don't care about입니다. (경로명과 논리 경로 이름은 기술적으로 별개의 기능이지만, 그들이하려고하는 것에는별로 멀지 않은 것으로 알고 있습니다.)
프로그래머는 언제 어디에서 유연성을 필요로하는지 짐작할 수 없습니다. 미래, 심지어는 유연성을 원할 것입니다. 프로그래머들은 이것을 잘 알고 있습니다. 그래서 "기민성"과 같은 싸구려 단어가 보편화되었습니다. 플랫폼 독립적 인 언어를 설계 할 때 언어는 추상화를위한 것이며 플랫폼은 매우 구체적입니다. 물론, 모든 플랫폼 독립적 인 언어는 C에서부터 상당한 양의 빨기로 가득합니다.
Ask Sun. 회사 전체에서 Java는 어떻게 작동 했습니까? (예, 알겠습니다. 1과 모두의 샘플)
이 경우 공급 업체의 관점에서 볼 수 있습니다. 그들은 인기있는 반면, 판매 한 OS의 (실제!) 힘을 활용할 수있는 언어를 만들지 않았습니다. Windows에서 실행되어야하며, 그러한 모든 일이 절실히 필요합니다. 하위 프로세스를 포크하고 부모와 자식간에 파이프 또는 두 개를 열려고합니까? 너무 나빴어. 스레드 버그로 재미를보십시오. 개 느린 파일 I/O로 재미있게 보내십시오. (Java가 마침내 "nio" 구현을 포함하는 경우)
Microsoft는 물론 .NET과 같은 실수를하지 않았습니다. 또한 여러 런타임 구현에 리소스를 사용하는 대신 더 나은 언어 기능에 중점을 두었습니다.
그는 환경이나 언어에 대해 묻고 있습니까? 플랫폼 독립적 인 언어 *의 가장 보편적 인 예가 C이고, C에서 추상화 계층은 일반적으로 병목 현상이 아니라고 말할 수 있습니다. – Ken