프로그래밍 언어와의 호환성 유지 및 결함 수정


56

먼저, 어떤 맥락 (대부분 당신이 알고있는 것들) :

Java 5, 6, 7 등, PHP 5.1, 5.2, 5.3 등이 있습니다. 새로운 버전을 출시하면 새로운 API를 사용할 수 있고 버그를 수정하며 추가 할 수 있습니다. 새로운 기능, 새로운 프레임 워크 등.

그러나 언어 (또는 플랫폼) 문제는 어떻습니까? 언어에 문제가있는 경우 개발자는 언어를 피하거나 (가능한 경우) 언어를 배우는 법을 배웁니다.

이제 해당 언어의 개발자는 해당 언어를 사용하는 프로그래머로부터 많은 피드백을받습니다. 따라서 시간 (및 버전 번호)이 지남에 따라 해당 언어의 문제는 느리지 만 확실하게 사라질 것입니다. 글쎄,별로. 왜? 이전 버전과의 호환성이 그 이유입니다. 그러나 왜 그렇습니까? 보다 구체적인 상황은 아래를 참조하십시오.


내 질문을 설명하는 가장 좋은 방법은 PHP를 예제로 사용하는 것입니다.

PHP는 수천 명의 사람들에게 사랑 받고 증오합니다. 모든 언어에는 결함이 있지만 분명히 PHP는 특별합니다. 이 블로그 게시물을 확인하십시오 . PHP에는 매우 긴 결함 목록이 있습니다. 이제는 PHP 개발자가 아니지만 (아직은 아님), 그 전체를 읽었으며 그 목록의 큰 부분이 실제로 문제가 될 것이라고 확신합니다. (주관적이기 때문에 전부는 아닙니다).

만약 내가 적극적으로 PHP를 개발하는 사람들 중 하나라면, 반드시 그 문제들을 하나씩 해결하고 싶을 것입니다. 그러나 그렇게하면 새 버전에서 실행될 때 언어의 특정 동작에 의존하는 코드가 중단됩니다. 두 단어로 요약하면 이전 버전과의 호환성입니다.

내가 이해하지 못하는 것은 PHP를 이전 버전과 호환성을 유지 해야하는 이유는 무엇입니까? 모든 문제가 해결 된 상태에서 PHP 버전 8을 출시하면 "이 버전에서는 이전 코드를 실행하지 마십시오!"라는 큰 경고를 표시 할 수 없습니다.

지원 중단이라는 것이 있습니다. 우리는 몇 년 동안 그것을 가지고 있었고 작동합니다. PHP와 관련하여 요즘 사람들이 mysql_*함수 사용을 적극적으로 권장하지 않는 방법을 살펴보십시오 (대신 권장 mysqli_*및 PDO). 더 이상 사용되지 않습니다. 사용할 수 있습니다. 우리는 그것을 사용해야합니다. 함수에서 작동한다면 왜 전체 언어에서는 작동하지 않습니까?

나 (PHP 개발자)가 이것을한다고 가정 해 봅시다.

  • 모든 결함을 수정 한 새로운 버전의 PHP (8)를 시작하십시오.
  • 새 프로젝트는 해당 버전을 사용하기 시작합니다. 훨씬 더 좋고, 명확하고, 더 안전합니다.
  • 그러나 이전 버전의 PHP를 버리지 않기 위해 보안 문제, 버그 등을 수정하여 업데이트를 계속 발표합니다. 여기에 나열되지 않은 이유가 있습니다. 일반적인 관행입니다. 예를 들어, 주로 버전 5.5.x에 중점을 두었지만 Oracle이 MySQL 버전 5.1.x를 어떻게 업데이트했는지 살펴보십시오.
  • 약 3 년 또는 4 년 후에, 나는 이전 버전의 PHP 업데이트를 중단하고 죽습니다. 3 년에서 4 년 동안 대부분의 프로젝트는 어쨌든 PHP 8로 전환 될 것입니다.

내 질문은 :이 모든 단계가 의미가 있습니까? 너무 어려울까요? 할 수 있다면 왜 안 되나요?

예, 단점은 이전 버전과의 호환성을 깨뜨리는 것입니다. 하지만 그 대가는 지불 할 가치가 없습니까? 거꾸로, 3 년에서 4 년 안에 문제의 90 %가 해결 된 언어를 갖게 될 것입니다. 그 이름은 인기를 보장 할 것입니다.

편집 : 좋아, 그래서 나는 3 ~ 4 년 안에 사람들이 가상의 PHP 8로 옮길 것이라고 말했을 때 나 자신을 정확하게 표현하지 못했습니다. 새 프로젝트.


31
PHP는이 특정 질문에 대한 나쁜 예입니다. 작업 할 버전을 선택하지 않는 경우가 많기 때문입니다. 대부분의 PHP 사이트는 공유 서버에 배포되며 서버 소유자는 사용자가 아닌 버전을 선택합니다. mysql_*예를 들어 5.5에서 더 이상 사용되지 않는 새로운 버전으로 많은 것들이 수정 되었지만 호스팅 제공 업체의 대다수가 하나 또는 두 개의 버전을 가지고 있다면 관계가 없습니다 (5.3은 불행히도 여전히 대다수의 것입니다. 공급자 제공).
yannis

5
... 포팅해야 할 코드의 양, 중단 될 코드의 양, 적응해야 할 타사의 양 등을 과소 평가한다고 생각합니다.
dagnelies

12
"화성 헤드셋"에 관한 Joel Spolsky 의이 훌륭한 블로그 게시물 joelonsoftware.com/items/2008/03/17.html 은 하위 호환성의 중요성을 과소 평가하는 모든 개발자에게 필수적입니다.
Doc Brown

3
또한 PHP는 매번 릴리스 할 때마다 기능을 천천히 중단하고 있으며 결과적으로 많은 부분이 중단됩니다. 불행히도, PHP는 개발자들이 더 이상 사이트를 방해하지 않을 것이라는 것을 알기 위해 사용 중지 경고를 생성하는 데 어려움을 겪는 어려운 상황에 처했습니다.
솜털 같은

20
python 2.x => python 3.x는 잘 설계된 하나의 언어에서 약간 더 잘 설계된 다른 언어로의 급격한 변화이며, 호환되지 않는 많은 구문을 자동으로 변경하기 위해 당사자가 지원합니다. 두 언어 사이에서 코드를 이식하는 것은 두 언어간에 쉽게 변경할 수 있습니다. Py3k는 여전히 매우 느리게 상승하고 있습니다.
Phoshi

답변:


25

잘 들리지만 실제로는 거의 작동하지 않습니다. 사람들은 실행 코드를 변경하는 것을 매우 꺼려하며 새로운 그린 필드 프로젝트의 경우 이미 알고있는 언어 / 버전에서 전환하는 것을 꺼려합니다.

"작동하는"기존의 실행 코드를 변경하는 것은 프로젝트의 우선 순위 목록에서 높은 순위가 아닙니다. 관리자가 이미 지불했다고 생각한 것에 노력을 기울이지 않고, 언어 나 플랫폼의 최신 릴리스로 업그레이드 할 수 있도록하기 위해 개발자는 "지금은"이전 릴리스를 그대로 유지해야한다고 선언 할 것입니다. 새 릴리스에서만 사용할 수있는 훌륭한 기능으로 사용자를 유혹 할 수는 있지만 언어에 대한 명확한 이득없이 사용자 기반을 줄일 위험이있는 도박입니다. 시원하고 현대적인 기능은 널리 알려진 의견으로 조각난 설치 기반의 가격과 쉽게 비교할 수 없으며 "업그레이드 런닝 머신"으로 명성을 얻을 위험이 있습니다.

(분명히, 이것의 대부분은 자신의 즐거움을 위해서만 취미 애호가가 작성한 프로젝트에는 적용되지 않습니다. 그러나 (여기서는 화염) ... PHP는 처음부터 글을 쓰는 것이 기쁘기 때문에 해커가 거의 선택하지 않습니다. )


65

하위 호환성의 영향을 과소 평가하고 있습니다. 모든 활성 프로젝트가 3-4 년 내에 마이그레이션 될 것으로 예상하는 것은 너무 낙관적입니다.

내가 PHP 개발자라고 가정하십시오. PHP에는 결함이 있지만 그 결함을 해결하는 방법을 알고 있습니다. 이것이 PHP 개발자로 돈을받는 이유의 일부입니다. 이제 PHP 8이 나오고 이러한 결함을 수정한다고 가정하지만 이전 버전과 호환되지는 않습니다. 결과적으로 :

  • PHP 8의 코드를 업데이트하는 데 시간을 할애해야합니다. 이제는 고객 요청에 응답하고, 새로운 기능을 구현하고, 경쟁을 따라갈 수 있습니다.
  • 이 작업을 수행 한 후에도 코드에 버그가 생겨 예상치 못한 호환성 문제가 발생하거나 예상치 못한 호환성 문제가 발생했을 가능성이 큽니다.

이를 감안할 때, "더 좋고, 명확하며, 더 안전하다"고하더라도 PHP 8로 마이그레이션 하지 않는 강력한 동기가 있습니다. 아직 수십억 줄의 COBOL (!)이 있다고 추정됩니다. 물론 훨씬 더 나은 기술이 있지만 업데이트 비용과 버그 위험이 결합되어 있지만 그만한 가치는 없습니다.

둘째, 내 코드를 마이그레이션하기로 결정하더라도 사소하지 않은 앱은 타사 라이브러리에 의존하므로 타사 라이브러리가 마이그레이션된다는 보장이 없습니다. 예를 들어, Python 3은 2008 년 12 월에 출시되었지만 Django (아마도 최고의 Python 웹 프레임 워크)는 거의 5 년 동안 안정적인 프로덕션 지원 Python 3을 지원하지 않았습니다 ( 여기여기 참조 ).


8
놀랍게도 많은 오래된 COBOL 포지션이 있으며, 특히 오래된 보험 회사 인 Oo
Chad Harrison의 경우

1
@ Josh Kelley : 나는 당신에게 동의하지만 이러한 문제는 라이브러리와 C ++ (템플릿)을 포함해야하기 때문에 기존 코드를 Python, PHP와 같은 새로운 코드와 명확하게 분리 할 수없는 언어에만 영향을 미친다고 생각합니다. 다른 컴파일 모델을 가진 언어 (예 : Java, Scala, Clojure)는 두 언어가 소스 코드 수준에서 호환되지 않더라도 기존 코드 (예 : Java)에 새 코드 (예 : Clojure)를 추가 할 수 있음을 보여줍니다.
Giorgio

2
이 질문을 별도의 질문이나 의견으로 게시해야하는지 모르겠습니다. 그러나 왜 일류 개념으로 코드 마이그레이션을 향상시키는 프로그래밍 언어를 만들 수 없었습니까? 자바에는 경고를주는 @Deprecated 주석이 있습니다. 다른 언어는 실제로 이전 코드를 올바른 새 코드로 대체하는 매크로를 제공 할 수 있습니다. 최신 버전을 사용하는 경우 더 이상 사용되지 않는 코드를 호출하면 오류가 발생하지만 더 이상 사용되지 않는 새 코드를 사용하도록 이전 코드가 변환됩니다. 그냥 spitballin '
Daniel Kaplan

7
@tieTYT-일부 프로그래밍 언어는이를 수행합니다. Python 2to3 또는 Go 's gofix ( talks.golang.org/2012/splash.slide#68 )를 참조하십시오 . 이전 기능을 더 이상 사용하지 않는 데 도움이되지만 언어 의미가 변경 될 때 소프트웨어가 다른 소프트웨어를 얼마나 잘 이해하고 업데이트 할 수 있는지에는 한계가 있습니다.
Josh Kelley

3
@hydroparadise 내 숙모는 은행 및 보험 회사의 개발자로 일하고 있으며, 위기가 닥쳤을 때 그녀의 회사 고객 중 일부 는 소프트웨어가 더 저렴하기 때문에 COBOL 로 돌아 가기 로 결정했습니다 ! 따라서 경제조차도 기업이 새로운 언어 / 버전으로 이동하는 속도에 영향을 줄 수 있습니다.
Bakuriu

17

당신은 인간의 행동에 대해 많은 가정을하고 있습니다. 너무 많이 바꾸면 사람들은 경쟁 업체를 평가할 것입니다. 경쟁 업체는 어쨌든 전환에 많은 노력을 기울여야하기 때문입니다. 오픈 소스 언어의 경우 사람들은 이전 버전을 포크합니다.

예를 들어 파이썬을보십시오. 3.x는 4 년 동안 사용할 수 있었으며 여전히 널리 채택되지 않았습니다. 사람들은 새로운 프로젝트에 사용하려고 시도하지만 유지 관리가 얼마나 많은 코드 작업인지 과소 평가하고 있다고 생각합니다.

물론 대부분의 사람들은 python 2.x를 "결함"으로 간주하지 않았습니다. PHP 사용자와 같은 불만은 없었습니다. Php는 훨씬 더 위험한 위치에 있습니다. 왜냐하면 많은 사람들이 기존 코드 기반 때문에 그것만 고수하기 때문입니다. 이전 버전과의 호환성을 잃어버린 경우 많은 사람들이 파이썬으로 이동하기를 기다렸을 것입니다.


나는 당신이 여기에 좋은 지적이 있다고 생각합니다 (+1). 나는 이전 버전과의 호환성이 잘못된 문제라고 생각합니다. 특히 별도의 컴파일을 사용할 수있는 컴파일 된 언어의 경우 (Scala 및 Clojure를 Java와 통합하거나 C #을 C ++로 통합하는 방법 참조). 그러나 새로운 언어는 결국 오래된 언어의 업데이트 버전이라는 느낌을 유지하는 것은 포크를 피하거나 사람들이 단순히 다른 언어로 이주한다는 것을 매우 중요합니다. 레거시 코드를 다루는 것보다 이러한 이유가 훨씬 더 강하다고 생각합니다.
Giorgio

1
@Giorgio False 문제? 동시에 더 많은 버전의 언어를 지원해야하는 모든 라이브러리 작성자에게 알려주십시오.
svick

@ svick : 별도의 컴파일을 사용하면 다른 버전의 언어를 지원할 필요가 없습니다. Scala가 스칼라 용으로 컴파일되지 않은 Java 라이브러리를 사용하는 방법을 참조하십시오.
Giorgio

9

PHP 이외의 다른 언어의 경우, 그렇습니다. 그것이 바로 파이썬 3으로 전환하면서 파이썬이하는 일입니다.

그러나 PHP의 문제점은 언어 디자인 자체에 결함이 너무 많아서 "PHP 8"이라고 부르는 것과 완전히 다른 언어가 될 수 있다는 것입니다. 그리고 다른 언어로 전환해야한다면 현재 존재하고 안정적인 대안이 아닌 새로운 PHP를 계속 사용하는 이유는 무엇입니까?

또한 PHP 커뮤니티는 새로운 것을 적용하는 데 매우 느립니다. 제거하는 데 걸린 시간을 살펴보십시오 register_globals. 2000 년 이후 보안 위험으로 알려져 있습니다. 12 년 후에야 마침내 제거되었습니다. 또 다른 예로, PHP5가 소개되었을 때 PHP4에 비해 크게 개선되었지만 커뮤니티는이를 채택하지 않았습니다. 4 년이 걸렸고 GoPHP5 와 같은 대규모 작업 이 채택을 시작했습니다. 그리고 심지어 이전 버전과 호환되지 않는 많은 변경 사항도 없었습니다.


5

면책 조항 : ColdFusion 사용자 그룹을 관리합니다.

ColdFusion은 동일한 문제를 겪고 있습니다. 많은 사람들이 사랑하고 많은 사람들이 멸시합니다. 또한 Java 이전 버전에 기반한 톤 및 톤의 FUD. ColdFusion 10은 작년에 출시되었으며, 거대한 판매자이며 지난 주에 버전 11의 시험판을 테스트하기 위해 가입했습니다. 또한 두 가지 주요 오픈 소스 대안이 있습니다. 하나는 JBoss가 지원합니다.

CF10에는 구현하고 싶은 새로운 기능이 많이 있지만 코드베이스의 크기, 향후 프로젝트 수 및 모든 것을 한 번 회귀 테스트 해야하는 리소스에 따라 CF 7 또는 8에서 마이그레이션하는 것이 어려울 수 있습니다 '최신 버전입니다. 코드가 같은 방식으로 컴파일되지 않는 경우와 8과 9 사이의 작은 구문상의 차이가 많이 발생했습니다. 일단 발견되면, 나는 그것들을 우리의 코딩 표준에 문서화하여 향후 프로젝트 나 새로운 개발자들에게 사용되지 않도록했습니다.

그러나 ColdFusion 11 (또는 프로그래밍 언어)이 특정 기능과 구문을 완전히 사용하지 않으면 기능을 찾고 대체하려는 노력의 수준이 엄청날 수 있습니다. 테스트 노력은 어려울 수 있습니다. 회사는 개발자, QA 및 프로젝트 관리자에게 더 이상 사용되지 않는 모든 것을 찾고 교체하고 테스트하기 위해 비용을 지불합니까? 못 미더운.

최신 버전의 언어가 이전 버전과 호환되지만 코드 변경없이 성능이 향상되면 (CF9가 CF8보다 약 30 % 빠르고 CF10이 CF9보다 훨씬 빠릅니다) 여전히 작동하는 경우 함수 호출을 변경하는 데 관심이 있습니까?

회사는 서비스 요금 청구, 비즈니스 구축 및 더 많은 고객 확보를 위해 고객 만족과 요구 충족에 대해 걱정해야합니다.

FWIW, 어느 시점에서 최신 버전의 jQuery를 사용하고 싶지만 특정 기능은 사용 후 몇 가지 버전에서 더 이상 사용되지 않으며 시스템에있는 JavaScript의 양을 감안할 때 어떻게 해야할지 모르겠습니다. 우리는 그것을 뽑을 것입니다.


4

여기에 절충점이 있습니다. 일부 버그는 수정이 필요하지만, 누군가의 코드를 어 기지 않고는 변경할 수 없습니다. 나는 모든 버그 수정이 버그를 아무리 모호하게하거나 깨뜨 렸든지간에 누군가가 그것을 위해 무언가를 사용하게 될 것이기 때문에 모든 버그 수정이 누군가의 프로젝트를 망칠 것이라는 "규칙"이라고 말하는 사람을 기억하는 것 같습니다. 프로그래머의 본질입니다.

이것이 주요 릴리스, 부 릴리스 및 개정의 차이점입니다. 일반적인 원칙으로 :

  • 주요 릴리스에는 주요 변경 사항이 포함되어 있다고 가정합니다.
  • 마이너 릴리스는 동작이 약간 변경 될 수 있습니다.
  • 개정판은 거의 상호 호환되어야합니다.

예를 들어, 언어 v2.3에서 무언가를 작성하는 경우 v2.3.2로 업그레이드해도 아무런 차이가 없을 것으로 예상됩니다. v2.4로 업그레이드하면 몇 가지 사항이 변경 될 수 있습니다. 작은 구문 조정, 일부 기능은 약간 다르게 동작하므로 로직 등을 조정해야합니다. v3.0으로 업그레이드해도 고장이 나더라도 놀라지 않을 것입니다. 전적으로-더 이상 사용되지 않거나 누락 된 기능, 지원되지 않거나 너무 많이 변경된 기능으로 다시 조정 할 수 없으므로 실제로 새로운 변경 사항을 설명하기 위해 일부 기능을 다시 작성해야합니다.

편집하다:

Steve Vance의 논문 Advanced SCM Branching Strategies 는 다음과 같이 말합니다.

일반적으로 마침표와 연결된 숫자 (예 : 1.2.3)로 이름이 지정된 2 ~ 3 개의 릴리스 레벨이 있습니다. [...]이 구조에서 첫 번째 숫자는 메이저 버전과 연관되어 있으며, 이는 이전 버전에서 현저한 기능 및 기능 향상을 나타냅니다. 마이그레이션이 필요한 비 호환성이있을 수도 있습니다. 두 번째 숫자는 기능 및 기능 향상이 적고 버그 수정이 많으며 비 호환성이없는 부 버전을 나타냅니다. 세 번째 숫자는 거의 모든 버그 수정 모음을 나타내는 패치 수준을 나타냅니다. 패치 레벨간에 기능 또는 기능 향상이 없으며 비 호환성이 허용되지 않습니다.

내가 이것에 대한 유일한 변경은 프로그래머가 종종 버그를 "사용"하는 방법을 찾는 전술 한 원칙이므로 "많은 버그 수정 및 비 호환성"이있는 부 버전은 어려울 수 있습니다. 버그는 버그를 사용한 것을 망가 뜨리거나, 대안이 불필요 해져서 문제를 일으키기 시작합니다.


2.3-> 2.4가 기능을 추가 할 것으로 예상하지만 제거하지는 않을 것입니다.
Donal Fellows

1
우연히도, 나는 최근에 관련 인용문을 보았습니다. 댓글이 너무 길어서 답변을 수정하겠습니다.
anaximander

2

그것은 언어의 목표가 무엇인지-언어로 어떤 유형의 응용 프로그램을 만들 것인지에 달려 있습니다.

예를 들어, Android를 무시하고 Java는 대부분 대기업 시스템 및 미들웨어에 사용됩니다. 이러한 유형의 응용 프로그램은 크기와 시간이 매우 커지는 경향이 있습니다. 이것은 약간의 의미가 있습니다. 개발 단계의 작업자 50 명 이상이 500K + LoC의 시스템을 상상해보십시오. 일반적으로이 유형의 시스템은 개발자 10 명과 함께 유지 보수를 시작합니다. 언어 변경 및 변경이 이전 버전과 호환되지 않는 경우 일부 부분을 작성한 프로그래머가 없어서 아무도이를 원하지 않기 때문에 프로젝트를 새 버전으로 쉽게 마이그레이션 할 수 없습니다. 이것은 더 작은 문제이며, 더 큰 문제는 500 LoC 응용 프로그램을 새로운 언어 제약 조건에 적용하는 데 비용이 많이 들기 때문입니다. 예를 들어 제네릭이 유형 지우기로 구현되지 않은 경우List list = new List(); 수백만 줄의 코드를 컴파일하지 않으면 다시 작성해야 할 것입니다.

반면에 PHP는 웹에서 더 간단한 응용 프로그램에 사용되는 경향이 있습니다. 일반적으로 단일 프로그래머 또는 소규모 팀이 개발합니다. 아이디어는 개발자들이 전체 프로젝트를 잘 알고있어 언어 변경을보다 쉽게 ​​통합 할 수 있다는 것입니다. 또한 사이트를 매우 빠르게 구축하는 것이 목적이며, 사이트를 더 빠르게 구축할수록 새로운 언어 기능으로 더 잘 수행 할 수 있으면 이전 버전과의 호환성 비용으로도 구현됩니다.


1

마이크로 소프트는 ASP.NET (클래식 ASP의 후속 버전)이나 VB.NET과 비슷한 변경을 수행했다고 주장 할 수있다 (하지만 언어를 "재부팅"하면 대부분의 혜택을 잃어 버렸지 만 후자는 많은 양보를 했음에도 불구하고).

어쨌든, 누군가 마이그레이션 도구의 도움을 받아 VB6 코드를 VB.NET으로 마이그레이션하는 악몽을 기억한다면 언어 마이그레이션 도구가 주요 언어 업데이트에 적합하지 않다는 데 동의 할 것입니다.

플랫폼을 전진시킬 수도 있지만 최소한 몇 가지 개정을 통해 "더 이상 사용되지 않는"API에 대한 지원을 제공해야합니다.


1

사람들이 인기있는 프로그래밍 언어에서 비명을 지르는 많은 "결점"은 그렇지 않습니다. 그들은 오늘날 비명을 지르는 사람들이 가장 좋아하는 장난감이 언어가 부족하다는 것입니다.
다음 과대 광고가 나오면 언어가 그 과대 광고를 따르지 않기 때문에 갑자기 결함이 있습니다.

Java에서 클로저가 없다는 것이 전형적인 예입니다. 그것은 전혀 언어의 결함이 아니며, 언어를 포함하도록 언어를 변경하면 (아무도 안타깝게도) IMO가 기본적으로 그것을 무너 뜨리거나 최소한 읽고 이해하기가 훨씬 더 어려워집니다.

너무 많은 사람들이 잃어버린 것은 각 언어마다 강점과 약점이 있으며 모든 약점을 피하면서 모든 강점을 결합한 무언가를 만들려고하면 전혀 쓸모없고 무력하고 불가능한 완전히 쓸모없는 괴물을 만들 것입니다 효과적으로 사용하십시오.

다른 사람들이 지적했듯이, 이전 버전과의 호환성은 기존 사용자를 유지하는 데 필수적이며, 많은 사람들이 백만 줄 코드베이스를 "더 나은"것으로 개조하기 위해 수천 시간과 수백만 달러 / 유로를 소비하지 않을 것이라고 덧붙였습니다. 그들이 수년간 사용했던 언어의 버전보다, 그리고 당신은 충분히 내버려 두어야 할 아주 좋은 주장을 많이했고, 아마도 다음 "자바 킬러"라고 생각되는 새로운 과장된 아이디어를 가지고 놀고 싶다면 d "자바의 복제본이"고정되지 "않는 한"자바 iz ded "를 비명하기보다는 그 장난감을 가지고 노는 것이 가장 좋습니다.


1

새로운 버전의 언어는 이전 버전과 새로운 버전의 언어로 컴파일되는 코드의 99.99999 %가 의도적으로 그렇게하지 않도록 의도되지 않은 경우가 아니라면 대부분 동일하게 작동하도록 노력해야한다고 제안합니다. 새 버전이 이전 버전에서 컴파일 된 코드를 거부하면 코드가 가장 좋지 않기 때문에 이전 컴파일러와 새 컴파일러 모두에서 컴파일되는 다른 방식으로 작성 되었기 때문입니다.

예를 들어 Java 또는 C #과 유사한 새 언어를 디자인하는 경우 해당 언어에서 허용하는 일부 컨텍스트에서 암시 적 유형 변환을 금지합니다. 주어진 C #의 간단한 예로서

int someInt;
double someDouble;

someInt.Equals(someDouble)변수의 내용에 관계없이 표현식 은 false를 리턴합니다. 이 때문에 컴파일 double로 변환 얻을 수 있습니다 ObjectintEquals해당 유형의 과부하를, 그래서 컴파일러는 변환을 수행하고 전화를합니다. 새 버전의 C #과 .NET Framework를 디자인 할 때는 유용한 변환 기능을 사용할 수 없으므로 권투 변환을 금지해야합니다. 쓸모는 없지만 무해한 방식으로 이러한 비교를 수행하는 일부 프로그램이있을 수 있으며 컴파일러에서 해당 코드를 거부하면 해당 프로그램이 중단 될 수 있지만 이러한 쓸모없는 코드를 수정하거나 제거하면 개선 될 수 있습니다.

약간 덜 명확한 예로,

float f=16777216f;
int i=16777217;

그리고 표현을 고려하십시오 f==i. 몇 가지 코드 / 정수 비교를 떠 수행하고 올바르게 작동하지만 코드 중 하나로 다시 작성해야 가능성이 있습니다 f==(float)i, (double)f==i;또는 (double)f==(double)i;[ intdouble후자의 두 개의 동등한 것 때문에 승진, 무손실]. 직접 비교 일부 코드 floatinteger값은 항상 충분히 작은 숫자를 처리 할 수 floatdouble비교가 동일하게 작동,하지만 컴파일러는 일반적으로 그것을 알 수 없다; 코드는 언어의 규칙이 프로그래머의 의도와 일치하기를 기대하기보다는 어떤 종류의 비교가 필요한지를 분명히해야합니다.


1

이전 버전과의 호환성을 유지하지 않는 것이 가장 좋습니다.

Microsoft는 VB6 프로그래밍 언어를 완전히 호환되지 않는 새로운 언어로 대체했습니다. 따라서 오늘날에도 16 살짜리 VB6은 여전히 ​​dotNet 버전 (2014 년 8 월 Tiobe 인덱스)보다 인기가 있습니다. 가트너는 아직도 140 억 줄의 VB6 코드가 사용되고 있다고 추정했다.

2014 년 Microsoft는 Visual Basic 프로그래밍 커뮤니티의 요구에도 불구하고 VB6을 업데이트하거나 공개하지 않을 것이라고 다시 발표했습니다. 그러나 그들은 적어도 2024 년까지 VB6에 대한 지원을 확장했으며 Windows 7 및 8에서 잘 작동합니다. 이는 동일한 버전의 VB6에 대한 26 년 이상의 지원입니다.

dotNet을 사용하기 위해 기존의 작동 소프트웨어를 다시 작성해야하는 이유는 무엇입니까?


이것은 이전의 14 가지 답변보다 실질적인 것을 제공하지 않는 것 같습니다
gnat

1

이전 버전과의 호환성을 깨는 데는 몇 가지 다른 문제가 있습니다. 일부 문제는 대부분의 프로그래밍 언어가 플랫폼 (통역사 / 런타임)이기도한다는 사실에서 비롯되며, 다른 문제는 인간 본성의 가정에서 비롯됩니다.

A. 이전 버전으로 작성된 코드는 성능, 보안 또는 기능을 향상시키는 새로운 릴리스의 이점을 얻지 못합니다. 컴파일러 / 인터프리터의 여러 주요 버전을 지원하여이 문제를 완화 할 수 있지만, 이는 막대한 리소스 소모 (즉, 비용이 많이 들거나 시간이 오래 걸리고 엉덩이가 아프다)입니다.

B. 최신 버전으로 작성된 코드는 이전 버전으로 작성된 코드와 호환되지 않을 수 있습니다. 여러 주요 버전의 언어를 처리 할 수있는 인터프리터 / 컴파일러를 사용하여이 문제를 해결할 수 있지만 별도의 인터프리터 / 컴파일러를 지원하는 것보다 엉덩이가 더 고통 스럽습니다 (A의 해결 방법).

C. 주요 변경 사항은 너무 자주 / 빠르게 발생하면 배우고 배우지 않아도되기 때문에 언어를 사용하기 어렵게 만듭니다. 언어를 변경하면 사람들이 가장자리를 넘어서서 새로운 언어로 전환하거나 사람들이 구 버전의 언어를 계속 사용하게하고 새로운 버전으로 전환하지 않을 수 있습니다 (파이썬에서와 같이). 그런 다음에도 변경 사항은 새로운 사용자를 유치하고 오래된 사용자를 자극 할 수 있습니다.

D. 새로운 문서를 보관하고 유지해야합니다. Google에서 물건을 찾아보고 현재 사용중인 버전과 다른 버전의 문서를 읽는 것을 발견하는 것은 다소 혼란스러운 경험입니다.

전반적으로 외부 모듈이 사용중인 버전을 신경 쓰지 않아도되는 프로그래밍 언어를 만들면 올바른 이유로 (언어의 주요 결함을 수정하기 위해) 하위 호환성을 깨는 것이 거의 확실히 옳은 일입니다. . 이것이 이루어지지 않는 주된 이유는 프로그래밍 언어 설계자들이 특히 초기에 호환성을 깨는 데 드는 비용을 과대 평가 ( 다른 사람의 답변과 모순)하기 때문일 수 있습니다 . 사실 호환성을 깨뜨리는 문제는 해당 언어의 사용자가 해결하거나 해결할 수 있습니다. 그리고 이것은 프로그래밍 언어만을위한 것이 아닙니다. 이것은 API, 사용자 인터페이스, 실제로는 모든 상황에서 모든 인터페이스에 적용됩니다.

페이스 북은 UI 나 개발자 API를 바꿀 때 사람들을 혼란스럽게한다. 과거에는 플랫폼 작업이 어려웠습니다. 어떤 경우에는 API가 단순히 파란색으로 작동을 멈췄습니다. 그러나 사람들은 계속해서 그것을 사용했고 이제 API와 UI는 5 년 전보다 뛰어났습니다. 사람들은 자신에게 좋은지 나쁜지 변화에 대해 불평 할 것이지만, 그 (고소)가 그 변화를 잊어 버리는 좋은 이유는 아닙니다. 불행히도, 프로그래밍 언어 개발자는 언어 문제를 그대로 유지하기 위해 이것을 사용합니다.

따라서 언어를 개선하기 위해 언어를 변경하지 않는 또 다른 두 가지 이유는 다음과 같습니다.

E. 언어 개발자는 사용자에게 변화에 대한 두려움이 언어를 정체시키는 좋은 이유라고 생각합니다.

F. 언어 개발자들은 언어를 만들 때 자신의 언어를 좋아했으며 아마도 결함이 있다고 생각할 것입니다.

G. 나이가 들어감에 따라 언어는 보통 소규모 핵심 개발자 집합을 갖지 못하게하고 더 많은위원회가 만든 짐승으로 변합니다. 즉, 해당 언어에 대한 결정이 느리고 종종 보수적이고 독창적입니다.

H. 마지막 이유는 일부 주요 변경 사항이 통역사 / 런타임에 대한 설계 결정에 대한 상당한 재평가가 필요하기 때문입니다. 때로는 언어를 향상시키기 위해서는 너무 많은 작업이 필요합니다. 나는 이것이 대부분의 것보다 드문 문제라고 생각할 것입니다.

언어 디자이너가 반드시 도구 디자이너 일 필요는 없으므로이 문제에 대한 좋은 해결책을 생각하지 않거나 제대로 실행하지 않습니다. 주요 변경 문제를 해결하기 위해 생각할 수있는 몇 가지 솔루션은 다음과 같습니다.

  1. 제거 될 때 더 이상 사용되지 않습니다.

  2. 좋은 표준 변환기 도구를 제공하십시오 . 파이썬은 2to3 도구를 제공했지만 잘 알려지지 않았고, 내가 기억하는 것처럼 파이썬 3과 함께 표준으로 제공되지 않았으며, 잘 작동하지도 않았습니다 (문제를 해결하기 위해 2to3에서 생성 된 프로그램을 수동으로 수행해야 함을 기억합니다) 수정하지 않았습니다). 컴파일러 / 통역사가 이전 버전을 감지하면이 변환기 도구가 자동으로 실행될 수도 있습니다. 더 쉬울 수있는 것은 무엇입니까?


Facebook 비유의 문제점은 사용중인 Facebook 레거시가 없다는 것입니다. 선택의 여지가 없습니다. 현재 Facebook 버전을 사용하거나 Facebook을 전혀 사용하지 않습니다. 한편, Python 2출시 된 지 7 년이 지난 지금도 여전히 많은 사람들 Python 3이 존재하기 때문에 여전히 존재합니다 Python 3.
케빈

나는 그것이 비유의 문제라고 생각하지 않습니다. 그것은 실제로 내 요점이었습니다. Facebook은 "결점 수정"경로를 선택했으며 "역 호환성"경로를 거의 피했습니다. 그렇기 때문에 기존 버전의 API가없는 이유입니다. 하나의 극단적 인 예입니다.
BT

프로그래밍 언어에서 이전 버전과의 호환성을 깨 뜨리면 사람들이 이전 버전을 계속 사용하거나 포크 할 수 있습니다. 이전 버전의 Facebook은 더 이상 존재하지 않습니다. Facebook은 거대한 사용자 기반을 가진 브랜드이기 때문에 이전 API를 지원하는 복제본을 만들 수는 있지만 아무도 사용하지 않을 것이라고 생각합니다.
Kevin

Facebook은 업데이트시 이전 버전이 더 이상 존재하지 않는다는 이점이 있습니다. 프로그래밍 언어는 그다지 다르지 않으며 관련 차이점입니다. 프로그래밍 언어 Python 2가 아직 있기 때문에 오래된 버전의 프로그래밍 언어를 사용할 수 있습니다.
Kevin

너의 의도를 알 겠어. 나는 여전히 두 가지 극단의 끝을 생각합니다. 지원되지 않는 언어 버전에서 주요 결함이 분명 해지면 해당 언어 버전을 사용하지 않을 수 있습니다.
BT

0

PHP 코드에 문제가 있는지 모르겠지만 오래된 언어의 경우 오래된 레거시 코드가 수년 후에 업데이트되지 않거나 때로는 수십 년이 지나야 작동하기 때문에 비즈니스를 운영하는 데 중요하고 너무 큽니다 (예 : 수백만 SLOC)이므로 다시 작성하는 것은 의미가 없습니다. 그렇기 때문에 오래된 라이브러리, 특히 라이브러리에서 쉽게 업데이트 할 수 있음에도 불구하고 Java가 이전 버전과의 호환성을 거의 종교적인 문제로 만든 이유입니다. C99 및 C11과 같은 표준 채택에도 불구하고 Linux 커널의 많은 코드가 수십 년 동안 업데이트되지 않았다고 생각합니다.

"기업가"가 적은 언어에서도 오래된 기능 코드를 깨는 것은 문제가 될 수 있습니다. 그것은 파이썬 2-> 3에서 일어난 일입니다. 라이브러리와 시스템 스크립트의 전체 묶음은 안정적이지 않고 더 이상 유지되지 않습니다. 그것들을 적응시키는 데 몇 년이 걸립니다. 따라서 개발자는 좋아하는 라이브러리가 아직 이동하지 않은 경우 반드시 Python 3으로 이동할 수 없으므로 자신의 코드는 Python 3에서도 작동하지 않으므로 커뮤니티 조각화가 발생합니다.


-1

이 문제는 이전 버전과의 호환성 문제에 있습니다. 내가 실행하는 대부분의 PHP 스크립트는 이전 RedHat 서버에서 실행되고 있습니다. 향후 스크립트에 최신 버전의 언어를 사용하려면이 서버에서 PHP를 업데이트해야합니다. 이전 스크립트가 손상되거나 이전 코드를 모두 다시 작성하는 데 몇 시간이 걸릴 위험이 있습니다. 새로운 표준. 또한 모든 개발자는 PHP가 특정 방식으로 반응합니다 (그 방식이 '파손'되었는지 여부에 관계없이). 더 이상 그런 식으로 반응하지 않으면 개발자가 기본적으로 PHP를 다시 가르쳐야 할 수도 있기 때문에 생산성의 주요 장애물이 될 수 있습니다.

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