왜 오래된 프로그래밍 언어가 계속 수정됩니까?


46

이 질문 "왜 사람들은 여전히 ​​오래된 프로그래밍 언어를 사용합니까?" 나는 그것을 아주 잘 이해합니다. 실제로 내가 가장 잘 알고있는 두 프로그래밍 언어는 C와 Scheme이며 둘 다 70 년대로 거슬러 올라갑니다.

최근 C99와 C11과 C89의 변경 사항에 대해 읽었습니다 (실제로 가장 많이 사용되는 C 버전과 K & R에서 배운 버전 인 것 같습니다). 주위를 둘러 보면 사용량이 많은 모든 프로그래밍 언어가 적어도 10 년에 한 번 정도 새로운 사양을 얻는 것처럼 보입니다. 포트란을 사용하는 대부분의 사람들이 여전히 포트란 77을 사용하고 있음에도 불구하고, 포트란조차도 여전히 새로운 개정을 받고 있습니다.

이것을 조판 시스템 TeX의 접근 방식과 대조하십시오. 1989 년에 TeX 3.0이 출시되면서 Donald Knuth는 TeX는 기능이 완전하며 향후 릴리스에는 버그 수정 만 포함 할 것이라고 선언했습니다. 이 외에도 그는 죽을 때 "남은 모든 버그가 기능이 될 것"이라고 말하면서 더 이상 업데이트가 이루어지지 않을 것이라고 말했다. 다른 사람들은 TeX를 자유롭게 포크 할 수 있으며 그렇게했지만 결과 시스템의 이름이 공식 TeX와 다르다는 것을 나타내도록 이름이 바뀌 었습니다. 이는 Knuth가 TeX가 완벽하다고 생각하기 때문이 아니라, 50 년 안에 같은 일을 할 안정적이고 예측 가능한 시스템의 가치를 이해하기 때문입니다.

대부분의 프로그래밍 언어 디자이너가 왜 같은 원리를 따르지 않습니까? 물론, 언어가 비교적 새로운 언어라면, 언어가 정착하기 전에 급격한 변화의시기를 겪는다는 것이 합리적입니다. 또한 기존 의사 표준을 체계화하거나 의도하지 않은 판독 값을 수정하는 것 이상을 수행하지 않는 사소한 변경에 반대 할 수는 없습니다. 그러나 언어가 10 년에서 20 년이 지난 후에도 여전히 개선이 필요한 것 같습니다. 왜 이미 사용중인 언어를 바꾸려고 시도하지 않고 언어를 포크하거나 다시 시작하지 않습니까? 만약 어떤 사람들이 Fortran에서 객체 지향 프로그래밍을하고 싶다면, 그 목적을 위해 "Objective Fortran"을 만들고 Fortran 자체 만 남겨 두지 않겠습니까?

향후 개정에 관계없이 C89는 이미 표준이며 사람들이 계속 사용하지 못하게 막을 수 있다고 생각합니다. 이것은 사실이지만 내포는 결과를 초래합니다. GCC는 페단 틱 모드에서 더 이상 사용되지 않거나 C99에서 미묘하게 다른 구문을 경고하므로 C89 프로그래머는 새로운 표준을 완전히 무시할 수 없습니다. 따라서 C99에는 언어를 사용하는 모든 사람에게이 오버 헤드를 부과하기에 충분한 이점이 있어야합니다.

이것은 논쟁의 권유가 아닌 실제 질문입니다. 분명히 나는 ​​이것에 대한 의견을 가지고 있지만, 지금은 왜 이것이 왜 일이 이미 수행되었는지 아닌지 이해하려고 노력하고 있습니다. 나는 질문이 다음과 같다고 생각한다.

구식 언어를 기반으로 새로운 언어를 만드는 것과는 달리 언어 표준을 업데이트하면 얻을 수있는 실질적 이점은 무엇입니까?


2
더 오래된 표준 (예 : GCC --std=x스위치) 을 시행하는 스위치를 사용하여 많은 컴파일러를 호출 할 수 있으므로, 새로운 표준을 만들면 더 오래된 코드를 불안정하게하는 도구가되지 않습니다.
Blrfl

2
"이전 언어를 기반으로하는 새로운 언어"를 어떻게 정의합니까? Fortran 90은 이전 F77을 기반으로 한 "새로운 언어"라고 주장합니다. 고정 대 자유 소스, 동적 대 정적 메모리 등 프로그래밍 방식이 완전히 바뀌 었습니다. 또한 Fortran 2003은 F90을 기반으로하는 "새로운 언어"라고 주장 할 수있었습니다. F90과의 호환성을 유지하면서 객체 지향 프로그래밍을 추가했습니다. C ++ 및 C. 관계 같은데
tpg2114

1
나는이 질문이 매우 중요하다고 생각하며 왜 누군가가 그것을 닫고 싶어하는지 이해하지 못합니다. 아마도 약간의 설명이있는 것은 매우 흥미로운 현상입니다. 몇 년 전, 나는 포트란의 새로운 기능에 대해 읽고 있었고 스스로에게 물었다. 포트란 프로그래머가 이러한 기능을 필요로한다면 왜 단순히 C로 바꾸지 않는가? 최근 C ++과 관련하여 비슷한 고려 사항이있었습니다 .C ++ 개발자가 람다를 사용하려면 OCaml ( linux-nantes.org/~fmonnier/ocaml/ocaml-wrapping-c.php )로 전환하지 않는 이유는 무엇입니까? 왜 그들은 새로운 언어를 만들고 여전히 C ++라고 부르는 것을 선호합니까?
Giorgio

3
@ tpg2114 (FORTRAN 77 : Fortran 90)과 (C : C ++)의 차이점은 Fortran 90이 FORTRAN 77을 대체 한 것으로 간주됩니다. "Fortran을 배우려면 Fortran 2003 또는 "지금은 표준이기 때문에 90 세 이상입니다." "C를 배우고 싶다면 새로운 표준이기 때문에 C ++을 배우십시오."라는 두 가지 언어로 표현되기 때문에 아무도 말하지 않을 것입니다. 내가 말했듯이, 의미는 결과를 가져옵니다.

6
C는 절대 죽지 않기 때문에
Adel

답변:


13

언어 디자이너가 기존 언어를 수정하려는 동기는 혁신을 도입하는 동시에 목표 개발자 커뮤니티가 함께 머물면서 새로운 언어를 채택하도록하는 것입니다. 기존 커뮤니티를 기존 언어의 새 개정판으로 옮기는 것이 새 커뮤니티를 만드는 것보다 효과적입니다 새로운 언어를 중심으로 물론, 이것은 일부 개발자들이 예전 표준에 만족하더라도 새로운 표준을 채택하도록 강요합니다. 커뮤니티에서 커뮤니티를 함께 유지하려면 소수의 사람들에게 특정 결정을 내려야하는 경우가 있습니다.

또한 범용 언어는 가능한 많은 프로그래머에게 서비스를 제공하려고 시도하고 종종 의도하지 않은 새로운 영역에 적용된다는 점을 고려하십시오. 따라서 디자인의 단순성과 안정성을 목표로하는 대신, 커뮤니티는 언어가 새로운 응용 분야로 이동함에 따라 새로운 아이디어 (다른 언어에서도)를 통합하도록 선택할 수 있습니다. 이러한 시나리오에서는 첫 번째 시도에서 올바르게 얻을 수 없습니다.

이는 언어가 수년에 걸쳐 큰 변화를 겪을 수 있으며 최신 개정판이 첫 번째 개정판과 매우 다르게 보일 수 있음을 의미합니다. 언어의 이름은 기술적 인 이유로 유지되지 않지만 개발자 커뮤니티는 새로운 언어에 대해 이전 이름을 사용하기로 동의하기 때문입니다. 따라서 프로그래밍 언어의 이름은 언어 자체가 아닌 사용자 커뮤니티를 식별합니다.

IMO 많은 개발자들이이 수용 가능한 (또는 바람직한) 동기를 찾는 동기는 약간 다른 언어로 점진적으로 전환하는 것이 완전히 새로운 언어로 뛰어 들기보다 더 많은 시간과 노력을들이는 것보다 쉽고 혼란스럽지 않다는 것입니다. 선호하는 언어가 하나 또는 두 개이고 새로운 (급진적으로 다른) 언어를 배우는 데 열중하지 않는 많은 개발자가 있다고 생각하십시오. 그리고 새로운 것을 배우는 것을 좋아하는 사람들에게도 새로운 프로그래밍 언어를 배우는 것은 항상 힘들고 시간이 많이 걸리는 활동입니다.

또한 덜 알려진 언어를 사용하는 소규모 커뮤니티보다 대규모 커뮤니티 및 풍부한 생태계의 일부인 것이 바람직 할 수 있습니다. 따라서 커뮤니티가 계속하기로 결정하면 많은 회원들이 고립을 피하기 위해 따르기로 결정합니다.

부수적으로 레거시 코드와의 호환성을 유지하면서 진화를 허용한다는 주장은 다소 약하다고 생각합니다 .Java는 C 코드를 호출하고, Scala는 Java 코드와 쉽게 통합하고, C #은 C ++와 통합 할 수 있습니다. 소스 코드 호환성없이 다른 언어로 작성된 레거시 코드와 쉽게 인터페이스 할 수있는 예가 많이 있습니다.

노트

일부 답변과 의견을 통해 일부 독자들은이 질문을 왜 "프로그래밍 언어가 진화해야합니까?"라고 해석 한 것 같습니다.

프로그래밍 언어가 진화해야하고 이유 (새로운 요구 사항, 새로운 아이디어)가 분명하기 때문에 이것이 문제의 핵심은 아니라고 생각합니다. 문제는 "왜 이런 진화가 많은 새로운 언어를 생성하는 대신 프로그래밍 언어에서 발생해야 하는가?"입니다.


이 답변은 내가 본 것 중 가장 의미가 있습니다. 언어를 업데이트하면 기존 커뮤니티, 라이브러리 등을 (적어도 일부) 상속받을 수 있습니다. Lisp의 가장 큰 문제는 약간의 숫자라는 것을 기억합니다. 공동체를 유지하기 어렵게하는 비 호환 방언; 기존 언어를 업데이트하면 다른 커뮤니티를 같은 방식으로 조각화하는 것을 피할 수 있습니다.

@ SunAvatar : 내가 알고있는 한 Lisp에는 몇 가지 방언이 있지만 일부는 다른 언어 (Common Lisp, Scheme, Racket, Clojure)보다 더 성공적입니다. 새로운 언어를 시작할 때마다 아주 작은 커뮤니티 만이 모일 위험이 있습니다. Lisp 커뮤니티에서 이것은 일반적인 관행으로 보입니다. 누군가 새로운 아이디어가 있다면, 그들은 분기하고 어떤 일이 일어나는지 봅니다. 다른 언어의 제작자에게는 커뮤니티를 잃어 버리는 것은 선택 사항이 아닙니다.
Giorgio

@ SunAvatar : 기존 라이브러리를 상속하는 것이 강력한 논거라고 생각하지 않습니다. 이를 위해 소스 코드 호환성이 필요하지 않습니다. Clojure와 Scala가 Java 코드를 사용하는 방법을 참조하십시오.
Giorgio

1
언어는 죽지 않으며 언어를 사용하는 프로그래머 만 죽습니다.
Evan Plaice

@SunAvatar : 다른 정책을 따르려고하는 커뮤니티도 있습니다. 이름은 언어를 식별하고 커뮤니티의 일부가 너무 많은 언어를 사용하는 경우 혼란을 피하기 위해 새로운 이름을 사용합니다. 예를 들어 racket-lang.org/new-name.html
Giorgio

21

이전 버전과의 호환성이 답입니다. 주어진 언어, 특히 C와 같이 널리 사용되는 언어는 수십 년 동안 변경없이 작동하는 코드를 가질 수 있습니다. 유지 관리가 필요한 경우, 개발 작업을 위해 최신 시스템에서 실행되는 동안 여전히 이러한 종류의 플랫폼을 대상으로 할 수있는 컴파일러가 있어야합니다. 표준화 및 언어 버전 업데이트는 프로그래밍 방식을 최신 상태로 유지하면서 전체 "새로운"언어를 배우지 못하는 베테랑 프로그래머에게 친숙 함을 제공합니다.

업데이트 된 언어 중 많은 부분이 "새 반짝이는 비트가 고정 된"만큼 덜 업데이트됩니다. 야레의 짐승은 종종 아직도 숨어 있습니다.

크 누스가가는 한, 그는 학업 적이며 TeX는 업데이트 된 것이 아니라 올바른 것으로 입증되었다는 것을 기억하십시오.


14
Tex = 형식 과학 논문 텍스트의 문제 영역은 크게 변하지 않았습니다. 프로그래밍 언어의 영역 = 새로운 컴퓨터에 대한 새로운 용도를 찾는 것이 더 광범위합니다. 라틴어가 영어처럼 많은 새로운 단어를 추가하지 않는 것과 같은 이유입니다.
Martin Beckett 2011

이전 버전과의 호환성이 올바른 이유라고 생각하지 않습니다. Scala는 기존 Java 코드와 쉽게 통합 될 수 있지만 Java의 상위 세트는 아닙니다. 따라서 일반적으로 새 언어가 소스 코드 수준에서 이전 언어와 호환 될 필요는 없다고 생각합니다. 새 코드에서 레거시 코드를 호출하기위한 잘 정의 된 메커니즘이 있으면 충분합니다.
Giorgio

@Martin Beckett : "Tex = 형식 과학 논문 텍스트의 문제 영역은 많이 변하지 않았습니다.": 질문의 요점이 빠져 있다고 생각합니다. OP는 프로그래밍 언어에 혁신이 필요한지 묻지 않고 (혁신이 필요하다는 것을 부정 할 수는 없다) 새로운 언어를 만드는 대신 구식 언어가 개정되는 이유를 묻는다.
Giorgio

시스템은 시간, 돈 및 전문 지식 (특정 언어로 얻은 경험)을 바탕으로 구축됩니다. 새로운 노력에는 유지 관리 노력 (3 가지 범주 모두)보다 훨씬 많은 비용이 듭니다. 일반적으로 언어와 플랫폼을 개선하지 않으면 유지 관리 비용이 상승한 다음 새로운 시스템의 비용이 더 매력적이며 인생에서 여덟 번째 시간 동안 COBOL 앱이 완전히 다른 플랫폼으로 재 호스팅되는 것처럼 보이지 않을 수 있습니다 더 이상 그런 식으로.
JustinC

업데이트 된 COBOL 언어 표준과 COBOL 도구 구현자가 자체 고유 한 기능을 추가하면서 언어를 향상 시켰으며 더 넓고 주류 인 최신 플랫폼에서 작동하는 기능을 향상 시켰습니다. 이 앱은 60 년 동안 살아남지 못했을 것입니다. 상대적으로 비용은 나중에 인생에서 나중에 올랐지 만, 전문 지식의 부족으로 인해 현재의 언어가 등장했을 때 정기적으로 다시 작성하는 것과 비교할 때 전체적인 노력은 달러로 페니였습니다.
JustinC

5

분명한 대답은 언어 디자인과 시스템 아키텍처에서 여전히 진보가 진행되고 있으며, 많은 사람들이 볼트를 사용하는 최신 기술 (여러 코어, 더 나은 스레딩 또는 메모리 모델)을 이용하려는 오래된 언어에 관심이 있다는 것입니다. 언어 표준에 따라 또는 구워졌습니다. 또한 일부 타사에 의존하지 않고 어떤 컴파일러 또는 플랫폼을 사용하든 관계없이 신뢰할 수있는 작업 (예 : XML 구문 분석, DB 액세스)을 수행하는 "한 가지 방법"을 사용하는 데 도움이됩니다. 설치되었거나 설치되지 않았을 수도있는 라이브러리 (필요한 버전 등일 수도 있고 그렇지 않을 수도 있음).


따라서 "사람들이 더 오래된 언어에 관심을 갖기"만하다면 귀하의 답변이 "기존 언어에 대한 감정적 인 애착"으로 표현 될 수 있습니까? 나는 당신의 대답을 이해하려고 노력하는 것을 중대하게 말하지 않습니다.
Avner Shahar-Kashtan

아니요, 언어는 여전히 활발히 사용되고 있으며 최신 기술을 활용하려는 사람들이 사용하고 있습니다. 나는 (AFAIK) 적극적으로 사용되지 않기 때문에 누군가가 ALGOL에 멀티 스레딩 지원을 추가 할 것이라고 생각하지 않습니다. 그러나 FORTRAN과 COBOL은 여전히 ​​새로운 시스템을 개발하는 데 사용되므로 언어 ​​사양이 정기적으로 업데이트되어 새로운 기술과 기술을 통합합니다.
TMN

1

범용 언어의 기본 개념이나 목표는 관련성을 잃지 않습니다. 그러나 작업 환경이나 하드웨어의 약간의 변경으로 인해 언어에 업데이트 나 작은 기능을 추가해야합니다.

알고리즘이 언어로 표현되는 방식은 64 비트 유형에 대한보다 명확한 지원, 표준 정규 표현식 지원 또는 새로운 유형의 파일 시스템에 대한보다 강력한 지원이 필요할지라도 변경되지 않습니다.

기존 언어에 '새로운'기능이 추가되는 경우가 몇 가지 있지만, 대부분의 경우 이러한 변경 사항은 사람들이 이미 어려운 작업을 단순화 한 것입니다. (함수 포인터와 펑터 대신 고차 함수를 사용하는 C ++ 참조)


1
두 번째 단락에서 설명하는 변경 사항은 상당히 반박 할 수 없습니다. 즉, 이의를 제기하는 것이 아니라 누구도 심각하게 이의를 제기 할 수 없음을 의미합니다. 람다에 관해서는 C ++에서의 유용성에 대해서는 언급 할 수 없지만 알고리즘이 표현되는 방식을 바꾸지 않으 려면 왜 추가해야 합니까?

아, 그들은 매우 유용합니다. 내가 틀리지 마 C ++ (IMO)에서 가장 중요한 추가 기능입니다. 나는 내가 무엇을 의미했는지 명확하지 않았다고 생각합니다. 일반적으로 메모리, 결정적 성능 및 높은 최적화 가능성에 직접 액세스 할 수 있도록 C ++을 선택합니다. 최근 추가로 변경되지 않습니다. C ++을 선택한 이유에 대한 다른 프로그래밍 작업을 단순화했지만 C ++은 여전히 ​​똑같은 이유로 유효합니다. 체계는 규칙적으로 업데이트되지만 데이터 코드 및 lispy-ness는 변경되지 않으므로 오늘날 20 년 전과 같은 이유로 체계를 선택합니다.
Ben

"람다의 경우 C ++에서의 유용성에 대해서는 언급 할 수 없지만 알고리즘이 표현되는 방식을 바꾸지 않으면 왜 추가해야합니까?" 처음부터 그들을 가지고 있습니까?
Giorgio

2
@Giorgio 언어의 캐시 및 추상화 기능을 제어합니다. 기존 언어가 둘 다를 제공하지 않으면 언어를 희생하지 않고 언어를 전환 할 수 없습니다. 언어를 수정하거나 새 언어를 만들어야합니다.
mike30

@ 마이크 : "캐시 기능"은 무엇을 의미합니까?
Giorgio

-2

이것은 구어를 고려한 것과 같습니다.

과거에는 지금처럼 자주 사용되지 않은 단어 (또는 다른 의미로 사용 된 단어)가있었습니다.

예. nice : in (매우 오래된) 영어는 오늘날 우리가 사용하는 것과 거의 반대의 의미를 가지고 있습니다.

나쁜 것 : 아주 오래 전에 나쁜 것은 하나의 의미만을 가졌으므로 이제는 "매우 놀랍다"는 것을 의미 할 수 있습니다.

또 다른 새로운 발전은 서면 언어를위한 휴대 전화 '텍스트 말하기'입니다.

나는 프로그래밍 언어가 비슷한 방식으로 개발되지 않는 이유를 개인적으로 알지 못하고 단어와 기능은 의미 / 행동을 지정했으며 새로운 아이디어, 새로운 방법론을 통합하기 위해 변경해야합니다.

나는 많은 다른 언어를 사용하는 사람들을 알고 있으며, 종종 3-4 번째 후에는 새로운 언어를 배우기가 더 쉬워 진다고 제안합니다.

비슷한 경험을 가진 프로그래머가 있는지 모르겠습니다.있는 경우 놀라지 않을 것입니다.

나는 자바에서 happies 프로그래밍을 느낀다는 것을 알고 있습니다 (영어로 말하는 happies를 느끼는 것처럼) 이것은 조심해야 할 'gotchas'가 있지만 '미국 영어'또는 '호주 영어'로 의사 소통을 할 수 없다는 것을 의미하지는 않습니다. . Java에서 PHP, Perl로가는 것과 비슷하지만 구조는 비슷하지만 나를 잡아서 벽에 머리를 부딪치게 만드는 작은 어려움이 있습니다.

이것은 영어에서 프랑스어로 또는 Java에서 SAS로 이동하는 것과 다릅니다. 이것들은 매우 다르기 때문에 능숙 해지기까지 꽤 오랜 시간이 걸립니다.

어쨌든 그것이 내가 취하는 일입니다.


나는 당신이 "면직"을 생각하고 있다고 생각합니다.
uliwitness
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.