프로그래밍 언어를보다 안정적으로 (호환 가능) 변경하는 메커니즘이 있습니까?


14

많은 프로그래밍 언어가 있습니다. 그들 중 일부는 자라서 매우 인기가 있습니다. 사람들은 그러한 언어를 점점 더 자주 사용합니다. 그러한 언어의 설립자 (또는 설립 조직 / 커뮤니티)는 언어를 개선하기 위해 변화를 시도 할 수 있습니다. 그러나 때로는 이전 버전과의 호환성으로 인해 일부 변경하기가 어렵고 그와 같은 추한 일이 이미 몇 년 동안 언어에 존재했으며 많은 사용자가 사용했습니다.

언어 설계 단계에서 언어 설계자가 이전 버전과의 호환성을 깨뜨리는 것을 두려워하지 않도록보다 안정적으로 만드는 데 도움이되는 아키텍처 원칙이나 단계가 있습니까?


2
언어 안정성은 모든 종류의 주요 변경을 배제합니다. 질문을 명확히 할 수 있습니까?
Simon Bergot

더 안정적인 것은 이전 버전과 호환되지 않는 변경과 정확히 반대되는 변경 사항이 적다 는 것을 의미합니다 (필요하지 않기 때문에 바람직하지 않음). 어느쪽에 관심이 있거나, 반 독립적으로 두 가지 모두에 대해 질문하고 있습니까?

@Simon 새로운 기능을 추가하려고 할 때 비교 가능성을
제압하는

@delnan은 둘 다 말할 수 있습니다.
Viacheslav Kondratiuk

@viakondratiuk 두려워하지 않는 것은 언어 디자인이 바꿀 수있는 것이 아닙니다. 더 좋은 질문은 "새로운 기능을 추가 해도 변경 내용이 변경되지 않도록 언어를 디자인하는 방법 "입니다.
svick

답변:


6

언어 안정성은 기술적 결정이 아닙니다. 언어 작성자와 사용자 간의 계약입니다.

저자는 주어진 버전을 다소 안정적으로 광고합니다. 언어가 덜 안정적 일수록 저자가 더 많이 변경할 수 있습니다. 언어에 관심이있는 각 사용자는 새로운 기능을 익히거나 다음 달 업데이트로 인해 중단 될 수있는 응용 프로그램을 개발하기 위해 시간을 투자 할 것인지 결정할 수 있습니다.

새로운 개념에 관심이 있거나 피드백을 제공하여 도움을 원하기 때문에 불안정한 언어를 사용하는 것이 흥미로울 수 있습니다. 비즈니스의 경우 기술에 시간을 투자하기 전에 기술이 더 안정 될 때까지 기다리는 것이 좋을 수 있습니다. 출시 시간 및 사용자 경험과 같은 것에 더 관심이 있습니다.

따라서 이것은 커뮤니케이션 및 신뢰 문제입니다. 녹 언어 개발을보십시오. 그들은 무엇을 바꾸고 있고 무엇을 지키고 있는지에 대해 분명합니다. 특정 지형지 물에 대한 결정을 지연 시키려면 지형지 물 게이트라고하는 것을 사용합니다. 다른 한편으로, 각도 팀은 변화가 예상보다 컸기 때문에 2.0 발표에 대해 많은 분노에 직면했습니다.

도서관 저자조차도 API의 안정성에 대해 이야기해야합니다. 다른 사람들이 사용하는 거의 모든 기술은 안정성과 완벽 함 사이의 균형을 유지해야합니다. 자동차 제조업체는 페달의 위치를 ​​변경할 수 없으며 랩톱 디자이너는 같은 이유로 새로운 키보드 레이아웃을 만들지 않습니다. 제품 사용 방법에 대한 결정을 내릴 수 없다면 사용자를 돕지 않습니다.


5
  • 언어는 사전에 얼마나 잘 설계되었는지에 관계없이 일생 동안 언어가 변경됩니다. 지구상에서 가장 멋진 언어를 즉시 배송하려고하는 대신 먼저 유용하고 확장 가능하도록 노력하십시오. 실제로 사용할 수있는 평범한 언어는 이론에만 존재하는 멋진 프로그래밍 언어보다 가치가 있습니다.
  • 매크로와 같이 구문을 확장 할 수있는 기능을 고려하십시오. 매크로는 자동으로 좋지 않으며 너무 강력 할 수 있습니다. 일부 언어는 처음부터 매우 유연한 구문을 사용하므로 매크로의 필요성이 줄어 듭니다. 고려해야 할 몇 가지 시나리오 :

    • |>언어를 떠나지 않고 새로운 연산자를 소개 할 수 있습니까 ? 이 연산자의 우선 순위와 연관성을 선택할 수 있습니까?
    • 인라인 기능 / 람다 / 폐쇄를 위해 얼마나 많은 행사를 거쳐야합니까?
    • 기존 언어 구문을 사용하여 foreach 루프 구문을 구현할 수 있습니까? 예를 들어 Ruby와 Scala는 람다를 사용한 유연한 메소드 호출 구문을 통해이를 수행 할 수 있습니다.
  • 의미를 확장 할 수있는 시설을 고려하십시오. 일반적인 요구 사항은 다음과 같습니다.

    • 사용자 정의 형식이 기존 연산자에 고유 한 의미를 할당 할 수있는 연산자 오버로딩 따라서 수학이 많은 응용 프로그램에서 언어를 훨씬 더 즐겁게 사용할 수 있습니다.
    • 리터럴 과부하. 문자열 리터럴을 고유 한 문자열 유형으로 만들 수 있습니까? 현재 범위의 모든 숫자 리터럴을 큰 숫자로 만들 수 있습니까?
    • 메타 객체 프로토콜. 언어에 특성이없는 경우 현재 객체 시스템 내에서 특성을 구현할 수 있습니까? 다른 분석법 순서를 구현할 수 있습니까? 객체가 저장되는 방식이나 메소드가 전달되는 방식을 바꿀 수 있습니까?
  • 회귀 테스트를합니다. 많은 테스트. 언어 디자이너뿐만 아니라 사용자도 작성했습니다. 기능을 추가 할 때 이러한 테스트가 중단되면 이전 버전과의 호환성 이점과 비교하여 해당 기능의 이점을 신중하게 평가하십시오.
  • 언어를 버전 화하십시오. 문서뿐만 아니라 소스 코드 자체에도 있습니다. 일단 그렇게하면, 변경할 수없는 언어의 유일한 부분은이 버전 pragma 구문입니다. 예 : 라켓을 사용하면 방언을 지정할 수 있습니다. Perl을 사용하면 use v5.20Perl v5.20의 이전 버전과 호환되지 않는 모든 기능을 사용할 수 있습니다. 단일 기능을 명시 적으로로드 할 수도 있습니다 use feature 'state'. 비슷한 : Python 's from __future__ import division.
  • 예약어가 거의없는 방식으로 언어를 디자인하는 것이 좋습니다. 해서 class소개하는 클래스 I라는 이름의 지역 변수를 가질 수없는 것을 의미하지 않는다 class. 실제로, 이것은 변수 또는 메소드 선언을 도입하는 키워드를 생성하며, C와 같은 유형 이름을 사용하여 선언을 도입하는 전통에 반합니다. 또 다른 대안은 $variablesPerl 및 PHP에서와 같이 sigils를 사용하는 것 입니다.

이 답변의 일부는 Guy Steele의 연설 "Growing a Language"(1998) ( pdf ) ( youtube )의 영향을받습니다.


일부 요점은 언어를 확장 할 수있는 언어를 사용하는 프로그래머에 대해 말하고 일부는 언어를 확장 할 수있는 디자이너에 대해 이야기합니다. 두 사람은 대부분 관련이 없습니까? 그리고 나는 그 질문이 후자에 대해 이야기하고 있다고 생각 합니다.
svick

@svick 아이디어는 최종 사용자가 언어를 확장 할 수있어 언어 자체를 변경하지 않고도 많은 확장과 실험을 수행 할 수 있다는 것입니다. Metaobject 프로토콜, 운영자 오버로드 및 매크로 시스템은 나중에 변경하기 위해 문을 열어 두는 방법입니다. 이 문을 통해 구현 된 것이라도 언어를 근본적으로 깨뜨리지는 않습니다. 불행하게도,이 문 자체는 나중에 다시 디자인해야 할 수도 있습니다. 이것이 바로 Simon의 대답 전제가 시작되는 부분입니다. 안정성을 약속하기 전에 약간의 베타 테스트를 통해 언어가 실제로 작동하는지 확인하십시오.
amon

1

꽤 중요한 단계는 언어 자체의 버전을 관리 할 수있는 패키지 관리자를 홍보하는 것입니다.

예를 들어 Scala에는 SBT를, Clojure에는 Leiningen에 사용합니다. 두 가지 모두 프로젝트별로 사용하려는 언어 버전을 선언 할 수 있습니다 . 따라서 최신 버전의 언어로 친환경 프로젝트를 시작하는 것은 쉽지만 기존 프로젝트를보다 편안한 속도로 업그레이드 할 수 있습니다.

물론 언어에 따라 관련 라이브러리가 필요한 버전 (예 : 스칼라 등)으로 이식 될 때까지 기다려야 할 수도 있지만 그럼에도 불구하고 작업이 더 쉬워집니다.


가능한 한 많은 언어를 수입 가능한 패키지 / 모듈에 가능한 한
jk

예, 그러나 반드시 그런 것은 아닙니다. 예를 들어 Scala의 컴파일러는 Scala로 작성되지만 Scala 버전을 sbt로 설정하면 Jar로 가져와 소스를 컴파일하는 데 사용됩니다. 불투명 바이너리 일지라도 마찬가지입니다. 이제, 가능한 많은 언어를 가져 오기 가능한 패키지로 정의해야하는 이유가 있지만, 이것들은 amon의 답변에서 다룹니다
Andrea
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.