모든 목적에 맞는 "유니버설"프로그래밍 언어가없는 이유는 무엇입니까? [닫은]

기존의 모든 프로그래밍 언어의 최고의 기능을 결합하여 범용 프로그래밍 언어에 맞지 않는 이유는 무엇입니까?

같은 이유로 당신은 닭을 개척 하기 위해 스위스 군용 칼 을 사용하지 않습니다 ...

스위스 군용 칼에는 일반적으로 날뿐만 아니라 드라이버와 같은 다양한 도구가 있으며 오프너 및 기타 여러 도구가 있습니다. 이 부착물은 피벗 포인트 메커니즘을 통해 나이프 손잡이 안에 보관됩니다 ...

나이프의 디자인과 유연성으로 인해 전 세계적으로 인정을 받았습니다 ...

때문에

1. 아무도 모든 레거시 코드를 다시 작성하고 싶지 않습니다.
2. 모든 목적에 동의하는 것은 어렵다
3. 포괄적 인 목적 목록을 작성하면이를 구축하기 전에 변경됩니다.
4. 새로운 목적으로 인해 누군가 완전히 다른 언어를 시작할 것입니다.
5. 마이크로 소프트
6. 사과
7. 오픈 소스
8. 모든 바벨 피쉬로 무엇을할까요?
9. SQL을 보편적으로 만들지 못했습니다.

프로그래밍에서 가지고있는 것은 매우 큰 문제 영역입니다. 이 영역은 매우 다양한 방향으로 다양합니다.

이것이 임베디드 비행 컨트롤러가 C로 작성되고 웹 사이트가 PHP, Java, Rails, .NET 등으로 작성되는 이유입니다.

임베디드 비행 컨트롤러의 경우 작동 할 약 128k의 메모리가 있습니다. 내 코드에서 처리되지 않은 예외가 발생하면 비행기가 추락하고 200 명이 사망하고 $ 1B의 조정에 따라 소송을 제기해야합니다. 고객에게 1 천만 달러를 잃어버린 지상 항공기를 수리하기 위해 세계 공항. 매우 타이트하고 잘못 될 수있는 움직이는 부분이 적은 언어로 작업해야합니다.

내 웹 응용 프로그램의 경우 몇 GB의 메모리가 작동하지만 네트워크 속도는 제한적입니다 (매일 더 적은 수준으로 제한되지만 웹 최대 제한). 나는 많은 기능을 제공하고 가능한 한 빨리 전송 될 수있는 출력을 생성하는 언어를 살펴볼 것이다. 사이트가 다운 되더라도 신경 쓰지 않습니다. 판매액 (100 달러)을 잃고 폭파 된 유스 케이스를 패치해야 할 것입니다.

웹 사이트는 15 년 넘게 C로 작성되지 않았으며 (아무도 cgi 스크립트를 사용합니까?) 비행 컨트롤러가 C ++을 살펴보기 시작했지만 매우 제한적인 방법으로 알고 있습니다.

1. 차고 (또는 부모의 차고)로 가십시오.
2. 도구 상자를여십시오.
3. 둘 이상의 도구가 표시되면 질문에 어떻게 적용되는지 생각해보십시오.

도구 상자가 없거나 중공 핸들에 드라이버 비트가있는 작은 망치 중 하나만있는 경우 큰 동정심을 나타냅니다.

진심으로. 자동차 판매점에 가면 정비공은 그의 도구 상자에 하나의 모든 도구를 가지고 있습니까? 그 (또는 그녀)는 다양한 자동차 수리 작업을 수행하도록 특별히 설계된 전문가 급 도구를 갖춘 전문가입니다.

마찬가지로 전문 소프트웨어 개발자는 자신의 거래를 수행 할 수있는 충분한 도구를 보유해야합니다. 도구 상자를 열고 필립스 스크류 드라이버에 해당하는 소프트웨어 만 보는 경우 전문가가 될 수 없습니다.

오픈 엔드 렌치, 박스 엔드 렌치, 래칫 렌치 또는 조절 가능한 렌치로 볼트를 돌릴 수 있습니다. 미끄러운 조인트 플라이어를 사용하여 볼트를 꼬집어 돌릴 수도 있습니다. 그러나 썰매 망치로 볼트를 돌리는 것은 매우 어렵습니다.

다른 사람에 대한 대답의 다른 종류는 - 사실이 생각하는 잠재적 인 하지 아마도 엄격하게 디자인 언어는 생각 될 수 있지만 언어가하는 "보편적 인"하나, 기능 및 다른 언어의 패러다임을 가능하게하는.

위 의 brettmjohnson의 비유 를 사용하기 위해 각 프로그래밍 언어가 상자 안에있는 도구 (또는 스위스 군용 칼)라는 아이디어는 모든 사람들이 만드는 가정이지만 실제로는 잘못된 가정입니다.

프로그래밍 언어가 툴박스라면?

원하는 언어로 기능을 추가 및 제거 할 수 있고 필요한 도구가 포함 된 도구 상자가 있으면 다른 용도로 사용하더라도 어떻게됩니까?

이 개념은 이미 부분적으로 존재합니다. 예를 들어, Nemerle 과 같은 언어 를 사용하면 언어에 구문 을 추가 할 수 있으므로 "언어 X의 최상의 기능"을 가져와 Nemerle (또는 자신의 언어)에 추가 할 수 있습니다. 이것은 반드시 항상 자신의 매크로를 작성한다는 것을 의미하지는 않습니다-각 언어 (또는 패러다임)가 표준 라이브러리의 매크로 내부에서 정의 될 수 있습니다-당신이 할 수있는 import Haskell; import Prolog;것처럼 두 언어를 마치 마치 당신의 언어?

그렇다면 다른 언어 / 패러다임의 기능을 서로 어떻게 사용할 수 있을까요? 대답 할 수는 없지만 .Net 및 JVM과 같은 프레임 워크는 일부 솔루션을 제공합니다. 언어는 컴파일 방식으로 인해 적어도 부분적으로 호환됩니다. 예를 들어 C #으로 작성된 코드를 가져와 불만없이 F #에서 사용할 수 있습니다.

오늘날 솔루션의 '문제'는 이러한 언어를 함께 사용하려면 언어를 별도의 프로젝트로 작성해야하므로 서로 참조 할 수 없으며 단방향 참조 만 가능하다는 것입니다. 언어 장벽은 각 프로젝트가 다른 프로젝트가 액세스하기 전에 모든 파일을 공통 중간 언어로 개별적으로 컴파일한다는 것입니다.

이 장벽을 제거하기위한 디딤돌은 다른 언어 (예 : C # 및 F #)의 코드가 동일한 프로젝트 내에서 컴파일 될 수 있도록하는 것입니다. 이론적으로 각 파일을 개별적으로 (또는 부분 유형 또는 순환 참조가있는 경우 그룹으로) 컴파일 한 다음 이미 컴파일 된 (CIL) 객체에 액세스 할 수있는 다른 언어의 파일을 컴파일 할 수 있습니다. 그래도 컴파일 순서를 엄격하게 정의해야하지만 F #의 경우 컴파일 순서가 이미 필요합니다.

어쨌든, 나는 "범용 언어가있을 수있다"는 말은 아닙니다. 나는 현재 존재하는 언어들 사이에 훨씬 더 나은 상호 운용성이있을 것을 제안하고있다. 실제로 언어와 라이브러리, 도구 등을 구현하는 작업이 엄청 나기 때문에 머지 않아 크게 개선되지는 않을 것입니다.

일부 언어의 최고 기능은 다른 언어의 최고 기능과 충돌합니다.

예를 들어, 타입 인식 리플렉션은 정말 좋은 기능이지만 느슨하게 입력 된 언어에서는 그다지 가치가 없지만 느슨한 타이핑은 때로는 큰 이점이 될 수 있습니다.

한 언어 내에서도 항상 최상의 기능을 모두 사용할 수는 없습니다.

"모든 거래의 잭-없음의 주인." 떠오른다.

일부 프로그램에는 속도가 필요하고 다른 프로그램에는 많은 양의 메모리가 필요하거나 디스크에 빠르게 액세스 할 수 있습니다. 어떤 언어는 능숙하지만 다른 언어에는 좋지 않습니다. 전혀 좋은 언어를 얻지 못할 것 같습니다.

따라서 어떤 언어로든 거의 모든 프로그램을 작성할 수는 있지만 그 문제를 해결하기 위해 작성할 수있는 "최고의"프로그램은 아닙니다.

있습니다. 없음 도구는 모든 것에 최선이지만, 많은 프로그래밍 언어와 같은 몇 가지 도구가 제공 하는 모든 목적으로하지 않도록 최선의 모든.

작업에 가장 적합한 도구를 선택할 수 있지만 모든 목적으로 사용할 수있는 프로그래밍 언어가 있으며 선택할 수 있습니다. 나는 그것을 권장하지 않지만 가능합니다.

"일반화 / 전문화 역설"이라고 불리는 무언가 때문에 아마도 다른 이름을 가지고 있으며 실제로 역설이 아닙니다.

프로그래밍 언어가 일반화 될수록 무언가를 달성하는 데 더 많은 코드가 필요합니다. 언어가 더 전문화되면 할 수있는 언어가 줄어 듭니다.

언어는 사람들이 생각하는 방식을 형성합니다. 이것은 자연어에 해당됩니다. 어린이가 "하나, 둘, 다수"라는 숫자를 가진 하나의 언어 만 알고 있다면, 어린이 수학을 가르치는 것은 어렵다 ... (죄송합니다, 링크가 없습니다) 영어로 우리는 마치 장소가 된 것처럼 다른 시간에 대해 이야기합니다. 따라서 시간 여행의 개념은 상상할 수 있습니다. 다른 언어로는 시간 여행이라는 개념이 결코 화자들에게 일어나지 않을 것 입니다.

프로그래밍 언어에서도 마찬가지입니다.

따라서 우리가 단일 프로그래밍 언어를 가지고 있다면 모든 사람은 모든 계산 작업에 대해 정확히 동일하게 생각할 것입니다. 따라서 우리는 대안을 모색하지 않을 것이며, 무언가를하는 가장 좋은 방법은 알려지지 않을 것입니다.

우리가 범용 언어에 가장 가까운 것은 C입니다. C는 기본 하드웨어 개념 (실제 하드웨어에서 실제로 수행되는 방식)과 매우 밀접하게 매핑되며 모든 * 언어의 프로그램은 C로 변환 가능합니다 (CFront가 어셈블러에 C 컴파일러를 사용한 방법 참조) 작업) C의 문제는 기본적으로 위에서 언급 한 변환이 C 프로그래머의 관점에서 의미가 없다는 것입니다.

"Lambdas"는 항상 C에서 가능했습니다. 전체 프로젝트 / 파일에 대한 코드 확산을 포함하여 구문이 해제되었으므로 선호되는 솔루션이 아닙니다. 캡처 불가능 / 업 밸류 / 등 버전으로 함수를 다른 곳에 정의하고 함수에 포인터를 전달하십시오. ( qsort () 참조 ) 캡처 된 값과 함께 람다를 사용하기 위해 작성해야하는 코드의 양과 복잡성이 크게 증가합니다. 람다는 언어의 일부인 언어와 달리 기본적으로 모든 곳에서 사용됩니다.

C와 C ++의 주된 차이점은 C ++에게 당신을 위해 물건 을 처리하도록 요청하는 방법입니다 . 그러나 더 이상 단 한 줄의 코드만으로도 실제로 요청하는 양을 더 이상 볼 수 없습니다. 대답은 다음과 같습니다. (이 모든 다른 코드에 따라 다름)

일부 프로그래밍 언어는 특정 작업에 적합하지만 전 세계에서 사용중인 대부분의 현재 프로그램이 해당 언어로 프로그래밍 된 경우에는 의미가 없습니다. 즉, 언어를 사용하여 해당 프로그램을 시작하여 구현할 수 있다면 주어진 것은 아닙니다.

보편적 언어를 사용하는 기술적 장점에 대한 불가능? 그건 말도 안돼 넌 할 수있어모든 기반을 다루는 보편적 인 언어가 있습니다. 문제는 대부분 역사적입니다. 다른 언어는 다른 일을하고 다른 공동체에서 사용되도록 고안되었습니다. 그들 중 많은 사람들이 붙어있었습니다. 그 환경 설정 (vi! emacs! 대기, 나는 Java! C #, 대기, Microsoft, 오픈 소스 등을 의미합니다. 등)과 역사적 사고의 일반적인 삽입에 추가하십시오 ... 작은 나라에서 자연 언어를보십시오. 이 주제가 얼마나 미친 지 알기 위해 일부 유럽 국가와 같은 대중. 일부 도시에는 자부심과 기쁨이 있습니다. 국가와 프로그래밍 공동체는 다르지 않으며 프로그래밍 공동체가 더 합리적이지 않습니다. 만약 그렇다면, 우리는 모두 유니버설에서 '어딘가'라는 에스페란토와 프로그램을 말할 것입니다 ...

"모든 기능을 결합하여"더 나은 언어를 만들 수 있다고 생각하는 것은 실수입니다.

부풀어 오르고 복잡하며 읽을 수없는 혼란으로 끝날 가능성이 큽니다.

좋은 언어 디자인은 선택과 절충이 필요합니다. 아마도 최고의 / 가장 혁신적이고 가장 성공적인 언어는 새로운 것을 추가하는 것보다 무언가를 꺼내고 더 나은 대안을 제공하는 언어 입니다. 예 :

• 구조화 된 프로그래밍 언어 (C, Pascal)- "goto"를 꺼내고 프로 시저 및 구조화 된 루프 등으로 대체합니다.
• Java- "수동 메모리 관리"를 수행하고 GC / 관리 메모리로 대체
• Haskell / Clojure- "제어되지 않은 가변 상태"를 취합니다.
• 리스프 (Lisp)-대부분의 "언어 구문"을 취하고, 유연한 s-expression의 homoiconic 트리로 대체

이 위에는 Bob Martin 아저씨가 전한 훌륭한 이야기가 있습니다- 마지막 프로그래밍 언어

최고의 기능을 모두 갖춘 도구는 없습니다. 예를 들어, Javascript 및 Scheme의 좋은 기능은 작다는 것입니다. 따라서 기능을 포장하기 시작하면 이미이 기능을 잃어 버렸습니다.

Still Cobra 는 다른 언어의 모든 멋진 기능을 제공하는 방향으로 유망합니다. :-)

그러한 언어를 만들면 또 다른 새로운 언어가되기 때문입니다. 팬 기반이 크더라도 다른 모든 언어는 계속 존재합니다.

이후 많은 새로운 언어가 발명되었지만 C는 여전히 존재합니다.

파이썬은 보편적 인 언어라고 말할 수 있지만 루비도 있습니다.

많은 언어가 존재하는 이유는 많은 프로그래머가 있고 일부는 새로운 언어를 만들고 싶어하기 때문입니다.

모든 사람이 동의하는 단일 범용 언어가없는 이유는 모든 결정을 내리는 일부 기관에서 기술로 프로그래밍하는 것이 아니기 때문입니다. 누구나 원하는 것을 자유롭게 할 수 있습니다.

좋은 일입니다.

지금까지 작성된 모든 내용으로 인해 새로운 이론적 근거를 많이 추가하기는 어렵지만 몇 가지만 다루겠습니다.

• 진화 (Evolution) : 자원과 틈새 시장에 대한 경쟁이 도입되고, 변형되고, 생존하기위한 것은 생물학적 시스템 만이 아니다. 경쟁은 좋으며 사물을 발전시킵니다.

• 성숙도 : 우리는 아마도 한 세기도되지 않은 시간 동안 컴퓨터 언어를 만들어 왔습니다. 아직 모든 질문을 알지 못하기 때문에 아직 답을 얻을 수 없습니다.

• 별개의 기원 : 이것에 대한 올바른 단어는 확실하지 않지만 세계에는 많은 지역에서 시작된 많은 글쓰기 시스템이 있습니다. 점토판으로 조각해야한다는 요구에 의해 부분적으로 지시 된 설형 문자에 대해 생각해보십시오. 산스크리트어, 그리스어, 히브리어, 로마자, 아랍어 알파벳을 생각하십시오. 상형 문자, 많은 동아시아 국가에서 공유되는 6000 개 이상의 기호로 아름다운 글씨를 쓰는 중국식 방법. 키릴 자모, 카타카나, 히 리가 나와 같은 음성 기반의 현대 혼합 알파벳을 생각해보십시오. 나는 언어학자가 아니기 때문에 부정확 함을 너무 가혹하게 화나게하지는 않지만, 전 세계 문화가 무언가를 필요로 할 때, 그것을 만들어 내고 필요에 따라 스스로 만들 것입니다. 전 세계적으로 많은 의사 소통이 있었을 때 컴퓨터 언어가 등장했습니다. 강력한 아이디어 리더십을 가진 곳에서 나왔습니다. 그러나 프로그래밍 언어는 다양한 문화 (일부 기업 문화)에 서비스를 제공하므로이를 만든 사람들을 반영합니다. 컴퓨터 언어에는 디자인과 사용을 구체화 한 문화적 유산이 있습니다. OS 커널 문화권에서 C 및 C ++는 기본 코드 생성, 하드웨어 추상화 계층 생성을위한 하드웨어와의 밀접한 / 효율적인 결합 및 크기에 따라 설치 가능한 크기를 허용하므로 Java (또는 다른 방식)에서 곧 폐기 될 것 같지 않습니다.

• 디자인 디자인 : 프로그래밍 언어는 다양한 조직 패러다임을 사용합니다. COBOL과 Ada는 많은 계층 구조를 가진 국방부의 일부인위원회에서 왔습니다. C, C ++, Java 등을 올바르게 기억한다면 많은 디자이너가 한 명 또는 소수의 디자이너로부터 온 것입니다. 프레드 브룩스 (Fred Brooks)는 그의 논문 인 디자인 디자인 (http://www.youtube.com/watch?v=pC-DlX-PaF4)에서위원회 결과와 비전 기반 접근 방식을 비교합니다. 오늘 다빈치 또는 보편적 프로그래밍 언어를 정의하기위한위원회를 선택하기 위해 앉았다면, 어떤 방법으로 설계해야하는지 누가 알겠습니까?

어쩌면이 모든 것에 약간 다른 경사가있을 수 있습니다.

언어 란 무엇입니까? 엄청나게 간단하게, 어휘, 구문 및 의미론입니다.

프로그래밍 언어로 가장 먼저하는 일은 무엇입니까?
클래스, 변수, 메소드를 정의하여 어휘와 의미를 확장합니다.

왜? 이제는 이전에는 말할 수 없었던 것을 말할 수 있습니다.
좋든 싫든 새로운 특수 목적 언어를 만들었습니다.

IMHO, 범용 언어로 찾아야 할 것은 특수 언어를 쉽게 만들 수 있다는 것입니다.

swiss-army-knife 주장을 제외하고는 ( 도메인이 있습니다. 도메인 고유의 언어보다 우수한 광역 언어를 설계하는 것이 더 어렵지만) 그런 언어가 둘 다가 아니라는 의미는 아닙니다 가능한 최상의 아이디어), "최상의 기능을 결합하는"문제가 있습니다 :

• 언어 기능의 경우 "최고"는 주관적이거나 최소한 (간헐적으로) 논쟁의 여지가 있습니다.
• 일부 기능은 호환되지 않습니다. 한 언어의 좋은 기능이 다른 언어의 좋은 기능과 결합되면 폭발 할 수 있습니다.
• 아직 새로운 기능이 나오지 않았습니다.

요컨대, 언어 디자인은 그보다 더 어렵고 복잡합니다. 그러나 Scala를 살펴볼 수도 있습니다 .

비주얼 배치는 사용자 정의 가능한 프로그래밍 언어를 시도합니다. 아래 링크는이 프로그래밍 인터페이스가 범용 프로그래밍 언어의 요구에 맞게 조정되는 방법을 보여줍니다.

http://sourceforge.net/apps/phpbb/visualbatch/viewtopic.php?f=4&t=4

보편적 인 프로그래밍 언어가 있습니다. 이것을 "기계 언어"라고하며 다른 컴퓨터 언어의 모든 것은 기계 언어로 실행됩니다.

그것은 어떻게 생겼습니까? 0-9의 문자열과 AF.

그러나 사용하기에는 나쁜 년입니다. 따라서 Alan은 기계 언어로 번역 될 수있는 언어를 발명했으며 Alan이 원하는 것에 더 적합합니다. Bill은 Bill이 원하는 것을 다른 언어로 발명했습니다. 오래지 않아 Cobol과 Fortran, Lisp 및 Java가 있습니다. 그들 모두는 기계어의 단순화 된 버전이며, 특정 종류의 프로그램을 작성하기는 쉽지만 다른 유형의 프로그램을 작성하는 것은 어렵거나 불가능합니다. 하나는 회계에 좋고 다른 하나는 우주 왕복선을 제어하는 ​​데 좋습니다.

으니까,

UNIVERSAL 컴퓨터가 없습니다.

UNIVERSAL 플랫폼이 아닙니다.

유니버설 프로그래머가 아닙니다.

유니버설 클라이언트조차도 아닙니다.

:피

그래서 우리는 단순히 다른 것을 위해 다른 것을 필요로합니다. ;)

여기서 대부분의 답변은 각 문제에 가장 적합한 도구를 사용하는 데 중점을 둡니다. 나는 이것이 충분한 이유라고 생각하지 않습니다.

대기업을 살펴보면 특정 프로젝트에 대해 더 나은 언어가 있더라도 일반적으로 회사는 단일 또는 소수의 언어와 기술을 사용하는 경향이 있습니다.

이는 표준화 개선, 손쉬운 지원, 코드 공유 등으로 인한 이점이 특정 언어의 부가 가치보다 (대부분) 더 크기 때문에 이루어집니다.

나는 "연필로 조각상을 조각하지 않기 때문에"모든 대답에 요점이 없다고 생각합니다.

TRULY는 모든 새로운 프로젝트 전에 언어를 선택합니까?

진실은 우리가 몇 프로그래밍 언어를 필요로하고, 프로그래밍 세계는 그런 식으로 더 잘 될 것입니다 : 사람들이 제작에 초점을 맞출 것이다 스크립트 언어를 더 나은 대신 예를 들어 파이썬 / 루비 / 펄 / younameit에 분산된다.

C #은 Windows에 프로그래밍되어 있으며 (모노가 있습니다. 모노가있는 사람은 매일 모노 앱에서 C #을 실행합니까?) 사용자가 Windows7 / 8을 구매하게하여 Microsoft에 돈을 버는 것입니다.
다른 회사들도 똑같이하고, 오픈 소스는 더 잘 알고, 천재도 마찬가지입니다. 그리고 우리는 닮은 언어를 많이 가지고 있습니다. 그것은 인류의 자기 중심적 성격 일뿐입니다.

우리는이 질문에 답하기 위해 경제학을 조사해야합니다. 하나의 언어만으로 사업 비용을 절감했다면, 우리는 그것을 가질 것입니다. 그들은 그것을 표준화하고 모든 사람들이 그것을 사용하도록 요구합니다. 다른 언어는 먼지가 많은 학문적 건물과 야생의 열광적 인 지하실에서 풀려납니다. 이것은 일어나지 않았으므로 보편적 인 프로그래밍 언어에서 인센티브가 없어야합니다. 그렇지 않으면 자연스럽게 진화했을 것입니다.