언어가 빠르게 바뀌면 이것이 좋은 것으로 간주됩니까?


14

나는 빠르게 변화하는 언어들 (예를 들어 매년 향상되는 언어)과 느리게 향상되는 언어를 보았다.

제 질문은, 언어가 빠르게 바뀌면 프로그래머에게 좋은 것입니까, 나쁜 것입니까? 프로그래머는 언어로 새로운 것을 배우는 것을 좋아합니까, 아니면 이미 알고있는 것을 고수하는 것을 선호합니까?


4
-1 : 너무 모호하고 가설로 답할 수 없습니다. "신속하게"무엇입니까? "개선"이란 무엇입니까? 변경 사항이 모두 이전 버전과 호환되는 경우 무엇이 중요합니까? 보다 구체적으로 질문을 개선하십시오. 빠르게 변화하는 구체적인 언어가 도움이 될 수 있습니다.
S.Lott

기존 프로그램은 여전히 ​​변경되지 않습니까?

4
나는 전혀 변하지 않는 언어를 선호하지만 라이브러리로 임의의 새로운 기능을 추가 할 수있을 정도로 유연합니다. 모 놀리 식 코어에 묻힌 모든 기능을 갖춘 거대하고 서투른 언어는 썩을 운명입니다.
SK-logic

"변경 사항"과 "이전 버전과의 호환성 나누기"는 완전히 다릅니다. 후자는 실제 문제입니다.
user16764

답변:


16

언어가 빠르게 바뀌면 프로그래머에게 좋은 일입니까, 나쁜 일입니까?

좋은

  • 변경 사항으로 인해 버그가 적고 향후 코드를 더 쉽게 작성할 수있는 멋진 합성 설탕이 추가 될 수 있습니다
  • 변경 사항은 프로그래머가 스스로 구현하거나 타사에 의존해야하는 일반적인 관용구 / 디자인 패턴을 표준화 할 수 있습니다.
  • 변경 사항으로 인해 일반적으로 사용되는 기술과 쉽게 통합 할 수 있습니다.
  • 변경 사항은 일반적인 실수를 방지하는 데 도움이 될 수
  • 변경으로 인해 위험한 프로그래밍 방식이 폐기되거나 제거 될 수 있습니다.
  • 변경 사항은 내가 구현하거나 타사에 의존해야했던 것들에 대해 언어 표준 라이브러리에 유용한 추가 기능을 제공 할 수 있습니다.

나쁜

  • 언어에는 복잡성이 추가되었습니다. 새로운 기능이 기존 기능 (예 : C ++과 C의 관계)에서 항상 잘 작동하지는 않습니다.
  • 레거시 코드가 오래되어 업데이트없이 새 버전의 언어에서 더 이상 작동하지 않을 수 있습니다 (Python 2.x-> 3.x).
  • 언어에 대한 컴파일러 및 기타 도구를 업데이트해야합니다. 이제 여러 버전이 존재할 수 있습니다.
  • 타사 라이브러리는 최신 버전의 언어를 지원하지 않을 수 있습니다
  • 표준이 있음에도 불구하고 새로운 기능을 구현하고 더 모호한 동작을 정의하는 표준 / 정상적인 방법을 찾는 데 시간이 걸릴 수 있습니다.

프로그래머는 언어로 새로운 것을 배우는 것을 좋아합니까, 아니면 이미 알고있는 것을 고수하는 것을 선호합니까?

많은 프로그래머들이 새로운 기능을 가지고 호기심을 만족시킵니다. 그러나 이것이 새로운 기능이 항상 프로덕션 코드에 적합하다는 것을 의미하지는 않습니다. 이는 특정 상황에서 업그레이드 비용과 새로운 기능의 이점을 비교해야하는 사례 별 결정입니다.

재미 있거나 새로운 기능에 대해 배우는 것을 좋아할 수도 있지만, 하루가 끝날 무렵에는 유용한 제품을 누군가에게 제공하는 것이 중요합니다. 합리적인 지원과 안정성을 갖기에는 충분히 현대적이면서도 상당히 생산적이지 않은 도구 모음을 선택해야했습니다.


C ++는 C의 진화가 아니며 C와 호환되는 새로운 언어입니다.
Nikko

대부분의 사람들은 C ++를 제대로 사용하지 않고 C와 마찬가지로 C ++을 사용합니다. 그리고 C ++을 올바르게 사용하면 분명히 복잡하고 모든 언어 기능을 지원하지 않는 특정 컴파일러의 역사가 있습니다.
sylvanaar

안정성을 선호하는 또 다른 주요 사항 : 인증 된 환경에서 작업 할 때 언어 업데이트가 중요한 문제가 될 수 있습니다. 문제는 작은 패치 릴리스라도 전체 인증 프로세스를 처음부터 처음부터 끝까지 수행해야하며 시간이 많이 걸린다는 것입니다.
Donal Fellows

@Nikko 나는 동의하지만, 그것은 C와 역 호환이어서 많은 재미있는 문제를 만듭니다 :)
Doug T.

11

이전 버전과 호환되는 경우 개선이 훌륭 합니다.

C #은 이것을 훌륭하게 수행합니다. 그들은 lamdba 표현을 추가하고, 멀티 스레딩, linq에 대한 더 나은 지원을 추가합니다. 그러나 5 살짜리 C # 2.0 프로그램은 변경 없이도 잘 작동하며 변경없이 쉽게 C # 4.0으로 업그레이드 할 수 있습니다.

새로운 작업을 배우는 것이 더 쉽고 빠른 방법으로 작업을 수행 할 수 있다면 좋습니다. 1 시간의 학습 시간이 개발 시간을 절약하는 것을 의미한다면 그만한 가치가 있습니다.


5

정기적으로 개선하고 싶지만 500 kloc 코드베이스를 깨뜨리고 이전 버전과 동일한 방식으로 코드를 작동시키기 위해 대규모 "업그레이드 프로젝트"를 트리거하고 싶지 않습니다.


4

언어 안정성은 비즈니스와 개발자에게 필수입니다. 언어 변경은 문제를 해결하거나 이전 릴리스에서 누락 된 기능을 소개하는 경우에 환영하지만 언어를 변경하여 유행을 이루거나 경쟁 업체를 따라 잡기 위해 언어를 변경하는 것은 그리 좋지 않습니다.

언어가 안정되면 시간이 지남에 따라 개발자는 언어를 완전히 익히고 자신이 아는 것으로 비즈니스 서비스를 제공하기 위해 노력하기 때문에 언어 학습에 집중하지 않습니다. 결과는 더 짧은 프로젝트, 행복한 최종 사용자 및 더 자랑스러운 개발자입니다!

학습 비용과 시간도 변화합니다. 모든 고용주가 개발자에게 새로운 기능을 교육 할 의향이있는 것은 아닙니다. 이것은 개발자들에게 스스로 또는 다른 것을 훈련시켜야하는 상당한 부담을 가중시킵니다. 이것은 사소한 것이 아니며 전문화 된 과정은 각각 $ 1500- $ 3500가 될 수 있습니다!

지속적인 변화는 개발자들을 '레거시'소프트웨어로 잠글 수 있습니다. 지금부터 2 년 동안 MVVM에 익숙하지 않은 ASP 개발자 나 WPF를 배우지 못한 Windows Forms 개발자의 경우를 생각해보십시오. 이러한 잠금은 개발자의 경력을 크게 손상시킬 수 있습니다.

시간이 지남에 따라 비즈니스의 소프트웨어 아키텍처는 가든 샐러드처럼 보입니다. 모든 종류의 도구와 버전을 사용하면 비즈니스 이익없이 소프트웨어를 한 버전에서 다음 버전으로 업그레이드하는 것 외에는 아무것도하지 않는 프로젝트를 찾을 수 있습니다.


2

나는 옳은 대답이 하나도 없다고 생각합니다.

일반적으로 말하면, 언어가 비교적 어리면 비교적 큰 변화를 비교적 빠르게 만들 수있는 자유가 더 많습니다. 기존 코드의 기초가 크지 않기 때문에 사람들은 일반적으로 실험에 훨씬 더 개방적입니다.

언어가 오래됨에 따라 사용자가 실제로 관심을 가질 정도로 충분히 넓게 사용된다고 가정하면 기존 코드의 기초는 변경 가능한 사항에 대해 더 엄격하고 엄격한 제한을 설정하기 시작합니다. 더 많은 기능을 사용하는 코드가 더 많을뿐 아니라 어떤 변경 사항으로 인해 코드가 손상 될 수 있는지 추측하기가 더 어려워 질뿐 아니라 사람들의 기대치가 변경됩니다.

예를 들어, 루비와 포트란을 쓰는 사람들이 거의 같다고 가정 해 봅시다. 또한 두 코드에 동일한 양의 코드가 있다고 가정 해 봅시다. 루비 사용자에게는 Fortran 사용자보다 일반적으로 동일한 비율의 변경 (및 동일한 작업을 수행하는 방식으로 변경)이 Fortran 사용자보다 훨씬 더 수용 가능할 가능성이 매우 높습니다. (적어도 그것을 개선으로 본다고 가정).

나는 많은 사람들이 언어에 대한 사람들의 인식에 달려 있다고 생각합니다. 언어를 선택하는 사람들 때문에 그것의 "최첨단는"많은 더 많은 가능성이 그게 걸릴 거라면, 기존의 코드를 많이 파괴 주요 변경 참아 있습니다 유지 최첨단을.

또 다른 요소는 언어가 계획된 프로젝트의 규모와 수명입니다. 상대적으로 작은 프로젝트를 지원하는 언어 나 초기에 기대 수명이 짧은 것으로 알려진 언어 (예 : 웹 UI)는 많은 사람들이 동일한 코드 기반을 계속 사용하지 않을 가능성이 높기 때문에 비교적 자주 문제를 해결할 수 있습니다. 예를 들어 10 년 동안 말입니다. 초기 릴리스에 도달하는 데 5 년이 걸릴 수있는 더 크고 더 오래 살았던 프로젝트를 위해 더 많은 언어를 지원하는 언어 (예 : C ++ 또는 Java)는 30 년에서 40 년 동안 정기적으로 사용 (및 지속적인 개발) 할 수 있습니다. 거래보다 안정성.


2

나는 그의 C ++을 좋아한다고 말한 사람이 있었고 그 방식으로 유지됩니다. 그는 D에 관심이 없거나 관심이 없으며 C #을 알고 사용하고 싶지 않습니다. 그는 자신이해야 할 많은 프로젝트를 위해 Java를 배웠고, 자신이 알고있는 언어로 분명히 잘 해냈습니다.

다른 사람은 C #을 좋아하고 모든 키워드를 알지 못하거나 .NET 4 라이브러리 (비동기 및 모두)를 알지 못하고 추상 키워드 또는 사용 된 속성을 사용하지 않았습니다.

나는 단순히 대부분의 사람들이 DONT CARE를 말하는 것입니다.

이제 업그레이드의 영향으로 사람들이 돌보아 줄 것입니다 (libs 또는 컴파일 된 코드의 경우).


C ++ "진화"는 새로운 표준 인 C ++ 11입니다. "C #"또는 "D"는 C ++ 진화가 아닙니다. C ++가 C의 진화가 아니기 때문에
Nikko

1
@ 니코 : 아하. 좋은 지적. 내가 아는 소수의 C ++ 프로그래머를 제외하고는 C ++ 0x 또는 C ++ 11에 대해서도 들었습니다. 그들에게 호기심 충분히 얻을 무언가를보고 발생과 회사 업그레이드 컴파일러하지 않는 한 나는 확신 그는 신경도 기능 봐 실 거예요있어 (내가 희망 움직임은 그들 중 하나입니다)

@ acidzombie24 : C ++에서 오랫동안 프로그래밍을 해왔으며 (1995 년 이후) C ++ 11에 대한 첫 인상은 실제 생산성보다 언어에 더 복잡성을 더한다는 것입니다. 언어의 의미는 너무 복잡해졌습니다. 매우 미묘하고 버그를 찾기가 매우 어렵습니다. 그리고 이러한 수정에 소요되는 시간은 생산성을 저하시킵니다. 실제로 새로운 표준을 사용해야한다면 내 의견이 바뀔 수 있지만, 일부 새로운 기능을 깊이 살펴본 후에도 느낌이 크게 향상되지 않았습니다.
조르지오

0

나는 C #에 대답 할 것이다 (그러나이 분석은 스칼라에도 적용될 수있다) :

이 기능 변경으로 언어의 "스타일"에 접근 할 때 몇 가지 문제가 발생합니다.

2011 년에 C #은 많은 다른 작업을 수행 할 수 있으며 이는 좋습니다. 불행히도 두 가지 패러다임이 있습니다 (더 이상은 아님).

  • 죄송합니다
  • 기능성 (람다 함수 및 LINQ 고려)

다른 유형 검사 스타일

  • 동적 타이핑
  • 정적 타이핑

언제든 서로를 사용하고 싶을 때 항상 명확한 것은 아닙니다.


0

나는 그것이 언어와 그 언어가 가진 다음에 달려 있다고 생각합니다. 예를 들어, C #과 Java가 Carra 와 같이 하위 호환성을 유지하는 한 더 빠른 속도로 변경 사항이 발생하기 시작하면 가능하다고 생각합니다 . 그러나 언어가 아직 견인력을 얻지 못했지만 여전히 빠르게 변화하고 있다면, 오늘 배우려고하는 것이 6 개월 후에 나오는 것과 완전히 다를 가능성이 있기 때문에 나는 그것에 신경 쓰지 않을 것입니다. 언어가 새롭거나 인기가 없기 때문에 그냥 전달하는 것이 나에게 해롭지 않을 것입니다.

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