더 많은 자연 언어 프로그래밍 언어가없는 이유는 무엇입니까?

둘 이상의 자연 언어로 사용 가능하고 확장 가능한 프로그래밍 언어가 있습니까?

예를 들어, do..while루프가 있는 영어 버전, 루프가있는 스페인어 버전 hacer..mientas, a가있는 프랑스어 버전 faire..pendant및 a가있는 네덜란드어 버전이 있습니다 doe..terwijl.

내가 이런 종류의 구현을 생각할 수있는 유일한 '프로그래밍 언어'는 Microsoft VBA입니다.

보너스 질문 : 여러 언어로 제공되는 프로그래밍 언어가 왜 그렇게 적습니까?

Excel 수식의 함수 이름은 지역화되어 있으며 영어 단어 나 그에 상응하는 언어를 사용할 수 있습니다.

이로 인해 지역 및 사용자 언어를 이동할 때 셀 수없이 많은 스프레드 시트가 발생했습니다. 또한 지역 문서가 현지화되어 있고 영어 이름을 언급하지 않기 때문에 기능에 대한 정보를 찾기가 어려우며, 반대로 로컬 이름으로 SO를 묻는 것은 대부분의 독자에게 의미가 없습니다.

키워드는 불투명 한 모니 커로 표시되어야합니다.이 키워드는 철자를 쓰는 데 사용되는 영어 단어의 의미와 일치합니다. 영어를 구사하는 프로그래머가 많지 않아 키워드의 절반이 무엇인지 모릅니다.

지난 세기, 특히 1960-1970 년대에는 영어가 아닌 기반의 프로그래밍 언어였습니다. 프랑스에서는 프랑스 식 키워드로 PAF & LSE 를 사용했습니다. WW2 독일에는 K.Zuze의 Plankalküll 이있었습니다. 소련에서는 A.Eshov 가 러시아 키워드를 사용하여 일부 언어 (예 : 라피 라 )를 디자인했습니다 . IIRC PAF (1960 년대 초반 아기 였을 때 아버지가 설계하고 구현 한)는 영어로 된 (또는 러시아어로, 또는 독일처럼 보이는) 키워드와 함께 판매 될 수도 있습니다. APL 과 같은 일부 언어 에는 키워드가 전혀 없었습니다. 다른 언어 ( PL / I )는 예약 하지 않았습니다키워드. 그리고 당신은 전처리 기술 키워드 다시 정의 할 수 있습니다 (C에서 예를 들어 오늘, #define si if& #define sinon else, 유사한 프랑스어 학생들을 위해 .... 매크로 기반의 트릭은 PL / I 또는 커먼 리스프에서 가능).

그러나 IT대부분 영어권 국가 (미국)에서 개발되었습니다. 따라서 프로그래밍 언어와 그 구현에는 영어 사양과 설명서 및 영어 키워드가있었습니다. 따라서 모든 개발자는 기술적 인 영어를 읽을 수 있어야하며 프로그래밍 언어를 "현지화"하는 데 부가 가치가 없으며 다른 언어로도 다른 소프트웨어를 사용하는 것이 더 어려워집니다. 현재 영어권 국가의 기술 및 경제적 지배력으로 인해 모든 엔지니어는 오늘날 영어를 읽을 수 있어야합니다 (북한, 중국 또는이란 소프트웨어 엔지니어도 영어로 된 문서를 읽고 영어 키워드 및 식별자로 코드를 읽을 수 있음) . 따라서 프로그래밍 언어를 "현지화"하기위한 부가 가치가 더 이상 없습니다 (초등학생에게 초등학교 프로그래밍을 가르치는 것 제외).

또한 영어에는 짧은 키워드 가 많기 때문에 ( sinon프랑스어 else에서 영어로 또는 mettre프랑스어 put에서 영어로) 키워드를 영어로 사용하면 약간의 이점이 있습니다 ....

^{아마도 한 세기 안에 중국이 지배적 인 IT 국가가되고 일부 중국 기반 프로그래밍 언어가 번성 할 수 있습니다. 우리는 그때 무슨 일이 일어날 지 모른다 ...}

추신. 영어의 지배는 IT에만 국한되지 않습니다. 영국이 Brexit 시나리오 인 유럽 연합을 떠나도 사실상의 공식 EC 언어는 영어로 남아 있으며 (이는 EU 회원국의 언어가 아님) H2020 ICT 프로젝트는 영어로 작성됩니다.

전문적인 프로그래밍 언어가 번역되지 않은 데에는 매우 좋은 이유가 있습니다.

1) 노력 : 현대 언어를 번역하는 것은 엄청난 일이다. Java를 가져 가십시오. 50 개 정도의 키워드를 번역하는 것은 작은 작업이지만 수천 개의 클래스와 메소드 및 관련 문서로 구성된 전체 표준 라이브러리를 번역해야합니다.

2) 호환성 : 기본 언어 및 표준 라이브러리가 번역 된 경우에도 번역되지 않은 타사 라이브러리 및 코드를 계속 사용할 수 없습니다. 타사 라이브러리 및 코드는 언어를 매력적이고 유용하게 만드는 주요 부분입니다. 번역 된 버전에서는 각 언어가 처음부터 각 번역에 대한 에코 시스템을 시작해야합니다. 모두 더 나빠질 것입니다.

3) 프로그래머는 어쨌든 영어를 알아야합니다. HTTP, CSS, HTML과 같은 많은 표준은 어쨌든 식별자에 영어를 사용합니다. 단어가 표준으로 구워 져서 번역 할 수 없습니다.

프로그래머는 어쨌든 영어를 알아야하기 때문에, 번역 된 버전의 프로그래밍 언어를 만들면 단점이있을뿐 장점도 없습니다.

즉, 전문 프로그래머가 아닌 일반 프로그래머를위한 언어의 경우 번역 된 버전을 작성하는 것이 좋습니다. 이것은 VBA의 경우이며 AppleScript도 번역 버전으로 존재한다고 생각합니다.

나는 매우 오래된 호의적 인 BASIC을 제외하고는 다른 언어에 대해 잘 모릅니다.

컴파일러와 라이브러리 구현자가 큰 필요성을 느끼지 못하는 것은 단지 복잡성을 더한다고 생각합니다. 내 의견에 기여하는 몇 가지 이유가 있습니다.

• "유니버설"언어를 고수하지 않으면 코드의 대상을 제한 할 수 있습니다. 물론, 모든 사람이 영어를 아는 것은 아니지만 모든 언어에 대해서도 마찬가지입니다.
• 단일 단어 키워드는 구문 분석을 복잡하게하는 모든 언어에서 단일 단어 일 필요는 없습니다. 필자는 확인한 적이 없지만 C ++의 단일 다중 단어 유형 "long long"을 처리하기 위해 상당한 양의 특수 케이스가 있다고 상상할 수 있습니다.
• 키워드 번역을 시작하면 로케일 및 숫자 형식도 고려합니까? 예를 들어 쉼표와 마침표를 소수점 구분 기호로 사용합니다. 아니면 독일어 명사를 대문자로 표기해야합니까?
• 주어진 프로그램에서 텍스트의 대부분은 주석은 말할 것도없고 변수, 메소드 및 클래스 이름입니다. 분명히 다른 언어로 작성된 라이브러리가 있지만 모든 사용자에게 서비스를 제공하기 위해 모든 라이브러리의 소스 코드 변환을 유지해야하는 것은 그러한 코드에 대한 논의에서 추가적인 복잡성을 언급하지 않고 대부분의 개발자에게 큰 부담이 될 것입니다.
• 컴파일러는 모든 구현 언어를 이해해야합니다. 아마도 같은 파일에 여러 언어가있을 수도 있습니다. 확실히 컴퓨터에 대한 작은 위업이지만 그럼에도 불구하고 추가 작업. 어쩌면 당신은 다른 언어로 다른 것을 의미하는 동일한 키워드를 다루거나 결국 읽기가 너무 모호한 용어를 다루어야 할 것입니다.
• 다른 언어로 프로그래밍되고 형식이 지정된 MS Office 문서를 다루어야하는 대부분의 사람들은이 문제를 해결할 가치가 없다고 생각하지 않을 것입니다.

개인적으로 코드를보다 체계적인 방식으로 작업 할 수 있다면, 코드를 실제로 이해하는 편집기, 문장, 지시 등을 통해 많은 흥미로운 일을 할 수 있으면 좋겠습니다. 아마도 자동 번역을 지원할 수도 있습니다. 내가 욕설을 궁금해하는 사람은 Smalltalk의 이미지 및 리팩토링 브라우저를 확인하고 더 많은 견인력을 얻었을 때 무엇이 ​​될 수 있는지 상상하십시오.

한 레벨에서 "기호 태그"와 다른 레벨에서 "표면 태그 지정자"로 정의 된 언어가 있고 이들 사이에 잘 ​​정의 된 맵핑이있는 경우에는 가능할 것입니다.

당신이 언어를 상상하여 if, while... do, switch표준에 (어떻게 든)에 정의 된 모든 다른 키워드, 당신은 비 토큰 화 된 형태로 기록 된 지역 코드 "토큰 화 된 형식"에서 시스템 라이브러리를 제공 할 수있다. 그런 다음 실제 컴파일러는 토큰 화 된 레이어에서 작동하며 문제가 없을 수 있습니다.

그러나 이것은 전체 이야기가 아닙니다. 함수 이름으로 인터페이스 된 "표준 라이브러리"가 아닌 곳에서 라이브러리를 가져온 경우에도 여전히 종료됩니다. 그리고 그것들은 언어간에 정식 매핑을하지 않으며 유용하게 사용하기 위해 현지 언어로의 번역이 필요하거나 소스 코드에서 언어의 혼란으로 끝날 것입니다.

주어진 모든 답변은 큰 답변이지만 어쨌든 나는 2 센트를 줄 것입니다.

미국과 영국의 기술적, 문화적, 경제적 지배력 을 계산할 때 영어 단어를 사용하여 가장 성공적인 언어가 만들어지는 것은 논리적이었습니다.

나중에 소프트웨어가 산업 이되면서 세계적인 노력이되었습니다. 프로그래머가 필요한 것보다 적다는 사실은 비밀이 아니므로 소프트웨어 회사 및 IBM과 같은 산업 정의 회사는 러시아, 파키스탄, 인도, 프랑스, ​​독일, 이스라엘 등 전 세계의 프로그래머를 고용하기 시작했습니다. 이미 영어를 기반으로하고 새로운 언어를 만들어내는 기존의 세계적으로 성공적인 언어로 프로그래밍하기 위해 존재하며, 이종 프로그래머의 경우 이미 존재하는 공통 언어는 다른 언어보다 더 나았습니다.

가장 최근에는 오픈 소스 및 무료 소프트웨어 운동 으로 인해 소프트웨어 제작이 전보다 더욱 세계적인 노력이되었습니다. 일부 프로그래밍 플랫폼, 언어 및 프레임 워크를 포함한 일부 공개 소프트웨어 프로젝트는 수백 명의 공동 작업자가 참여하는 대규모 프로젝트입니다.

이스라엘 사람은 스리랑카 사람과 어떤 언어로 공동 작업을합니까? 아마도 그들은 서로의 모국어를 말하거나 읽지 않습니다. 그래서 영어가 구출됩니다.

좋든 싫든 영어는 세계적인 노력의 언어입니다 . 그리고 미국이 그것을 밀고 있기 때문이 아니라 세계가 그것을 밀고 있기 때문입니다.

제이 워커의 역설 :

당신의 모국어는 가장 많이 사용하는 언어이며, 항상 당신의 마음과 뇌의 중심에있을 것입니다. 그러나 영어로 당신은 더 넓은 대화의 일부입니다.

"English Mania"비디오를 참조하십시오 .

결론 :

다른 언어를 사용하는 프로그래밍 언어는 계속 존재하며 (그래픽 토큰 기반 스크래치와 같이) 계속 발명 될 것입니다.

영어는 또한 "액센트가없는"언어이며 ASCII와 다른 인코딩이 필요한 이상한 문자가 없습니다. 나는 이탈리아어이고 이탈리아어 키보드 레이아웃이나 àèéìòù와 같은 악센트 문자를 사용하면 인코딩 오류가 발생하는 경우가 있습니다. 또한 "else"는 "altrimenti"로 번역되고, "in"은 "dentro"입니다.