"강력한"언어는 무엇입니까?

나는 종종 사람들이 자신이 좋아하는 언어가 다른 언어보다 "강력한"언어로 싸우는 것을 보았습니다. 프로그래밍 언어를 설명 할 때 객체 지향 언어가 무엇인지 또는 동적 언어가 무엇인지 이해할 수 있지만 여전히 "강력한"언어가 무엇인지 정확히 파악할 수는 없습니다. 당신의 생각은 무엇입니까?

"강력한"이라는 단어를 먼저 정의하지 않으면 "강력한"언어가 무엇인지 정의 할 수 없습니다.

힘 의 문자 적 정의는 "역량"이 될 것이며, 우리는 대다수의 컴파일러들과 심지어 튜링이 완료되지 않은 많은 인터프리터들도 프로세서가 명령어를 실행하도록 똑같이 잘 수행한다는 데 동의 할 수 있다고 생각합니다. . 문자 그대로의 정의에 관한 한,이 질문에 대한 대답은 "거의 모든 언어"일 것입니다.

실제로 우리는 거기서 멈추어야합니다. "강력한 언어"를 정의하는 것은 "좋은 사람"또는 "품질의 제품"을 정의하는 것과 약간 비슷합니다. 모든 사람 또는 대다수의 전문가가 동의 할 수있는이 단어들에 대한 객관적인 정의 는 전혀 없으며 , 대부분의 정의는 단순히 질문 을 구걸합니다 . 대화하는 사람에 따라 전원은 다음 중 하나 일 수 있습니다.

• 광범위한 공통 작업을 수행하기위한 풍부한 범용 프레임 워크 또는 라이브러리
• "한 가지 일을 잘 수행하는" 정교한 도메인 별 구문
• 기계 기능에 직접 액세스, 즉 저수준 코드 작성 기능
• 기계 수준의 개념, 즉 고급 코드 를 작성하는 기능을 추상화
• 리플렉션, DI 및 정적 분석과 같은 고급 전략을 가능하게 하는 매우 풍부한 유형 시스템
• 프로그래머가 방금 작업을 수행 할 수있게 하는 매우 느슨한 유형 시스템 (유형 강제 등)
• 개념 검증 을 제공 하는 모든 것을 객체 로 취급하는 기능
• 수학 검증 을 제공 하는 모든 기능을 함수 로 취급하는 기능
• 버그 를 줄여주는 자동 메모리 및 리소스 관리 (GC, RAII)
• 수동 메모리 및 리소스 관리로 잠재적 성능 최적화
• 최소한의 구문 노이즈로 가독성 향상
• 더 영어와 같은 구문 얕은 제공, 학습 곡선을
• 매우 간결한 코드 를 작성할 수있는 기능 (예 : 삼항 연산자, 널 병합, 널 확장)
• 무능력 쓰기 잠재적으로 혼동 코드 (예 : 더 원 사업자 등)

모두 여기서 무슨 일이 일어나고 있는지 보입니까? 사실상 모든 글 머리 기호 기능은 "파워"의 표시로 해석 될 수 있으며 그 반대의 경우도 가능합니다!

어딘가에 누군가 변수 변수 가 언어를 매우 강력 하게 만드는 멋진 아이디어라고 생각했습니다 . 나는 판단하지 않을 것이다. 나는 PHP 사람이 아닙니다.

나는이 모든 성전의 말도 안되는 말 대신에이 간단한 정의를 사용할 것을 제안합니다.

가장 강력한 언어는 가장 짧은 시간에 가장 저렴한 비용으로 최고 품질의 제품을 배송 할 수있는 언어입니다.

막연한? 당신은 내기. 그렇기 때문에 전문가라고 부르려는 사람은 프로그래밍 개념 과 프로젝트 영역을 모두 이해해야 합니다. 이것이 "강력한"것을 결정할 수있는 유일한 방법입니다.

그렇지 않으면, 당신은 총 싸움에 정말 큰 칼 을 가지고있을 수 있습니다 .

시스템 프로그래머이기 때문에 편견이있을 수 있습니다. 모든 커널, 시스템, 서버 및 응용 프로그램 프로그래밍에 사용되는 프로그래밍 언어 또는 여러 프로그래밍 패러다임을 지원하거나 둘 다 "강력한"이라고 생각할 수 있습니다.

C, C ++, D는 강력하지만 분명히 이것은 내 겸손한 의견입니다.

튜링 완전성을 넘어서는 몇 가지 힘에 대한 정의가 있습니다. Mark는 내가 "폴 그래엄 정의"라고 생각하는 경향이 있다고 인용했습니다. 하나의 심각한 결함이있는 꽤 좋은 정의입니다. 잘못되었습니다. 이론적으로 언어 능력에 대한 아주 좋은 정의이지만 이론과 실제의 차이점에 대해 그들이 말하는 것을 알고 있습니다 ...

모든 사람이 완벽하게 버그가없고 완벽하게 미래를 보장하는 완벽한 코드를 작성할 수 있다면 Paul Graham의 정의가 정확할 것입니다. 그러나 그것은 사실이 아닙니다. 실제로 소프트웨어 엔지니어링에 소요되는 많은 시간과 노력은 제품을 처음 만들 때가 아니라 나중에 유지 관리를 통해 이루어집니다. 어떤 통계를 듣고 있는지 (그리고 프로젝트마다 상당히 다를 수 있음) 유지 관리는 프로그램에 들어가는 총 노력의 60 %에서 90 %를 차지할 수 있습니다.

유지 관리는 종종 코드를 처음 작성한 사람이 아닌 코드를 처음 작성한 후 몇 개월 또는 몇 년이 지난 사람이 수행합니다. 이는 원래 코더에게도 "다른 사람의 코드"일 수 있음을 의미합니다. 포인트. 유지 관리 중에 생산성을 높이려면 코드를 읽고 원래 의도를 신속하게 확인할 수 있어야합니다.

따라서, 더 강력한 언어는 쉽게 코드를 만드는 하나 읽어 신속하지 쉽게 코드를 만드는 하나의 쓰기 빨리. 이 둘 사이에는 상당한 양의 중복이 발생하는 경향이 있지만, 간결한 구문은 종종 컴파일러 / 통역자가 유지 보수 프로그래머보다 훨씬 쉽게 추론 할 수있는 세부 사항을 생략하기 때문에 개념이 교차 목적으로 사용되기도합니다.

편집 : 언어의 힘을 설명하는 또 다른 중요한 점이 있습니다. 표현할 수있는 개념의 범위와 언어의 양 끝을 얼마나 쉽게 칠 수 있는지. Paul Graham은이 수준을 추상화 수준에 도달 할 수있는 정도에 대해 평가하려고하지만 절반에 불과합니다. 필요한 경우 갈 수없는 아래에 추상화의 하한을 부과하는 언어는 추상화되어있는 세부 사항이 이유가 있기 때문에 무너집니다. 이것은 COBOL과 같이 쉽게 읽을 수있는 장난감 언어와 쉽게 읽을 수있는 강력한 언어의 차이점입니다. COBOL에는 포인터가없고 인라인 어셈블리에 액세스 할 수 없습니다. COBOL에 적합하지 않은 계산도 표현할 수 있습니다.

COBOL은 또한 추상화 스펙트럼의 하이 엔드에도 영향을 미치지 않습니다. Wikipedia에 따르면 "사용자 정의 형식이없고 사용자 정의 함수가 없으므로"알고리즘과 데이터 구조를 만드는 것이 매우 어렵습니다.

이 문제는 오랜 기간 동안 반복적으로 논의되었습니다 (예 : comp.lang.lisp에서 여러 번). 나는 누군가가 "올바른"대답을 생각해 본 적이 없지만 많은 사람들이 분명히 틀린 답을 제시합니다.

여기에 나오는 답변에서 Mason Wheeler의 답변을 선택하겠습니다. 한편으로는 그가 다루는 문제 가 중요하지만 다른 한편으로는 "파워"와 관련하여 전혀 문제를 부르는 것을 상상할 수 없습니다. 그의 혼다 미니 밴은 안전하고, 조용하며, 핸들링이 더 좋고, 승객 실이 더 많고, 더 편안한 승차감을 갖기 때문에 최고 연료 드래그 스터보다 강력하다고 말하는 것과 조금 비슷합니다. 이 모든 것이 절대적으로 사실이며 모두 중요합니다. 이러한 요소들 (많은 것들 중에서도)은 대부분의 사람들에게 미니 밴을 훨씬 더 실용적이고 합리적으로 만들지 만, 미니 밴 엔진은 약 250 HP를 생산하는 반면 드래그 스터는 약 8000 HP를 생산한다는 사실을 바꾸지는 않습니다.

물론 문제는 차량의 경우 "전력"을 구성하는 것과 그렇지 않은 것을 명확하게 정의한다는 것입니다. 프로그래밍 언어를 사용하면 처리, 편의성, 속도,화물 용량 및 순항 범위를 모두 "전력"의 일부로 취급하는 것과 동등한 논의가 끝납니다. 결과는 끝없이 달리는 실이되어 빛보다 더 많은 열을 발생시키는 경향이 있습니다. 기본적으로 발생하는 대부분의 질문은 완전히 관련이없고 직교 인 피쳐에 첨부하는 중요도에 따라 달라집니다. 예를 들어, MMU를 어셈블리 언어로 프로그래밍하여 높은 수준의 함수를 생성하는 것보다 "강력한"기능 하스켈에? 적어도 IMO에서는이 둘을 비교할 수있는 의미있는 방법이 없으며 "

따라서 내가 싫어하는 한,이 경우 유일한 의미있는 대답은 기본적으로 상대 론적 대답입니다. 강력한 언어는 원하는 것을 성취하는 데 도움이되는 언어입니다. 사람들의 목표의 차이는 가장 "절대적인"힘 측정을 의미가 없게 만듭니다.

간결성과 유연성의 적절한 균형.

좋은 질문입니다. 많은 언어가 "완료 중"이라는 점을 감안할 때, 우리는 이론적으로 가능한 능력과 관련하여 모든 언어를 동일한 근거에 둘 수 있습니다. 그러나 언어는 분명히 다르기 때문에 그렇게하지 않습니다. 그리고 차이점은 무엇입니까?

차이점은 아주 적은 다른 것들을 말할 수있는 능력 입니다. 우리가 극단으로 바로 뛰어들 수 있다면, 나는 하나의 문자 'c'를 사용하여 컨텐츠 관리 시스템을 자동으로 초기화하는 데 가장 적합한 언어 인 언어를 만들 수 있습니다. 그러나 그 요점은 무엇입니까? 물론, 그것은 매우 짧다는 의미 에서 강력 하지만 융통성이 없습니다. 당신이 원하는 것은 너무 장황하지 않고 여러 가지 복잡한 것을 말할 수있는 언어입니다. 조립과 같지 않고 태양 아래서 모든 것을 할 수 있으며 무한대로 유연하지만 장황합니다.

강력한 언어는 가능한 최소한의 길이로 많은 다른 것을 말할 수있는 언어입니다.

튜링 완료를 누르면 (언어가이를 쉽게 수행 할 수 있음) "파워"는 한 튜링 완료 언어로 말할 수있는 모든 것이 다른 언어로 말할 수 있다는 의미에서 큰 의미가 없습니다. Mark Canlas의 대답은 그 사실을 잘 보여줍니다. 간결성과 유연성이 차이를 만듭니다.

Matthias Felleisen의 논문 에서 프로그래밍 언어의 표현력에 관한 논문 은 흥미로운 독서를 만들어냅니다. 그것은 언어로 표현의 개념을 공식화하려고 시도합니다.

언어 적 힘을 구성하는 것에 대해 많은 의견이 일치하지 않는 것 같습니다. 간결함, 가독성, 적응성 또는 단순한 Turing 완성도입니까? 나는 이러한 모든 요소가 작용한다고 생각하므로, 그것을 보는 가장 좋은 방법은 스탯 포인트 측면 일 것입니다. 예, 펜과 종이 RPG를 이야기하고 있습니다.

아이디어는 각 언어에 거의 동일한 수의 "포인트"가 있으며, 이는 여러 범주에 걸쳐 임의로 분배 될 수 있습니다. 논의의 목적으로, 유일한 요소는 간결성, 가독성 및 유연성이라고 말하십시오. 그러면 언어는 매우 간결하고 유연하지만 읽기가 매우 어려울 수 있습니다. 읽기 쉽고 유연하지만 매우 장황합니다.

(어쩌면 언어가 배포해야하는 포인트의 수는 디자이너와 구현 자의 기술에 의해 정의되지만 모든 언어 디자이너가 자신이하는 일에 똑같이 능숙하다고 가정합시다.)

언어 디자이너가 한 범주에서 언어의 강도를 높이기로 결정하면 논리적으로 다른 모든 범주에서 그 잠재적 강도의 일부를 제거합니다. 그렇기 때문에 프로그래밍 언어 디자인은 트레이드 오프에 관한 것입니다. 이러한 관점에서 언어의 전체적인 힘은 여전히 정의 할 수 없으며, 우리는 상대적인 강점에 따라 언어를 분류하는 시도 된 진정한 방법으로 되돌려 야합니다. 만족스럽지 않습니까? 너무 나쁘다.

당신은 두 가지 방법을 주장 할 수 있습니다 : 강력한 언어는 포인트의 분배가 비교적 고르거나 (모든 거래의 잭, 없음 마스터), 다른 사람을 무인 상태로 두지 않고 한 영역에서 가능한 많은 포인트를 갖는 언어입니다 (전문가). 수많은 분야에서 완벽한 숙달을 가진 "르네상스 사람"언어는 없습니다. 그리고 그것이 가장 강력한 언어에 대한 당신의 정의라면, 당신은 운이 좋지 않습니다.

더 자세히 읽으 려면 , 이 기사 (동시에 의견이 혼합되어있는 것으로 보이는 Paul Graham의 글) 도 프로그래밍 언어가 실제로 어떻게 다른지 결정 하는 것이 어려울 수 있다는 생각을 다루고 있습니다. 그는 언어가 선호하는 언어보다 언어가 덜 강력하다는 것을 알기가 매우 쉽지만, 기능 X가 누락되어 있지만 실제로는 더 강력한 언어가 실제로 얼마나 그렇게 있는지보기가 매우 어렵습니다. 기본적으로 언어 X와 같습니다. 다른 것들도 많이 넣었습니다. 나는 그 논문의 인용문을 남깁니다.

귀납적으로, 다양한 언어들 사이의 모든 힘의 차이를 볼 수있는 유일한 프로그래머는 가장 강력한 언어를 이해하는 사람들입니다. (이것은 아마도 Eric Raymond가 Lisp가 당신을 더 나은 프로그래머로 만드는 것에 대한 의미 일 것입니다.) Blub 역설 때문에 다른 사람들의 의견을 믿을 수는 없습니다. 그들이 프로그램에 대해 생각하는 방식.

프로그래밍 언어는 도구입니다. 일부 도구는 매우 전문화되어 있으며 특정 목적에 적합합니다. 다른 사람들은 거의 쓸모없는 점으로 일반화되고 단순화됩니다.

나는 가장 "강력한"언어가 최소한의 시간, 에너지 및 기타 연구 투자로 목표를 달성 할 수있는 언어라고 주장합니다. 즉, 가장 큰 ROI를 제공하는 언어입니다. 어떤 상황에서는 C가 될 수 있습니다. 다른 경우에는 Java; 여전히 다른 사람들에게는 하스켈.

가장 좋은 방법은 다양한 언어와 그 언어에 익숙해지는 것입니다. 그런 다음 새 프로젝트를 시작할 때가 가장 적합한 결정을 내릴 수 있습니다.

프로그래밍 언어에 대한 토론은 일부 Linux 뉴스 그룹의 메일 클라이언트에 대한 토론과 마찬가지로 IMHO와 비슷합니다. 화염 전쟁 인 경향이 있습니다. VB6이 인기 있었던 시간을 기억할 수 있습니다. 심지어 프로그래밍 언어가 아니라고 주장하는 사람들도 있었고, 다른 사람들은 멋진 응용 프로그램을 만들었습니다.

제작자가 언어를 만들거나 디자인 할 때 마음에 다른 점이 있었기 때문에 프로그래밍 언어는 이미 개념이 다르다고 생각합니다. 따라서 한 가지 목적에 맞는 언어와 그 상황에 맞는 언어는 다른 언어에 맞지 않을 수 있습니다. 언어를 강력하게 명명하는 것은 순전히 주관적입니다. 즉, 적용 가능한 측정 항목이 있다고 생각하지 않습니다.

그들은 당신의 도구 상자에있는 모든 도구입니다. 망치는 강력하지만 렌치가 필요한 경우에는 강력하지 않습니다. C / C ++는 시스템 프로그래머라면 훌륭하지만 어도비 플래시는 구축하려는 게임 웹 사이트에 더 적합 할 것입니다.

가장 강력한 프로그래밍 언어는 다음 선형 프로그래밍 문제 를 해결하는 언어입니다 .

최대화

  개발 속도
+ 코드 판독
용이성 + 디버깅 용이성
+ 간결함 / 표현력
+ 학습 / 교육 용이성
-CPU 사용
-메모리 요구 사항

대상

• 튜링 완료해야합니다.
• 기능, 객체 지향, 논리 프로그래밍, 제약 조건 프로그래밍, 동시성, 분산 컴퓨팅 등 다중 패러다임 이어야합니다 .
• 명령 줄 인터페이스, 구성 요소 라이브러리, 서버, GUI 및 웹 응용 프로그램을 만들 수 있도록 다목적 이어야합니다 .
• 이식 가능 해야합니다 . 즉, 크로스 플랫폼 설정으로 이식 및 유지가 용이해야합니다.
• 그것은해야 적응력 , 즉, 변경 개방과 기술이 발생할에 새로운 하드웨어 (양자 칩), 새로운 패러다임, 그리고 다른 혁신으로 진화 할 수.
• CPAN, CTAN 및 CRAN과 같은 라이브러리 개발을 장려해야합니다.
• 무료 이고 오픈 소스 여야합니다 .

(그렇습니다, 나는 이미 완전히 모순적인 답변을 게시했습니다. 그 이유는 내가 방언이기 때문입니다.)

이것은 자연 언어와 관련하여 작성되었지만 프로그래밍 언어에도 적합하다고 생각합니다.

어떤 언어는 본질적으로 다른 언어보다 우월하다는 믿음이 널리 퍼져 있지만 언어 적 근거에는 근거가 없습니다. 물론 어떤 언어는 특정 역사 시대에 다른 언어보다 더 유용하거나 권위가 있지만, 이것은 언어의 고유 한 특성이 아니라 당시의 연설가의 우수성 때문입니다.
-데이비드 크리스탈 (ed.). Language 2 / e의 Cambridge Encyclopedia (1997). p.7

"힘"은 단순히 한 언어에서 다른 언어로 인한 것이 아닙니다. "중국어는 한국어보다 더 강력한 언어입니다."라고 말하는 것은 어리석은 일입니다. 마찬가지로 "APL은 COBOL보다 강력한 언어입니다."라고 말하는 것은 어리석은 일입니다.

언어력을 객관적인 척도로 동일시하려는 몇 가지 시도가 있었다. 이러한 시도는 실패한다고 생각합니다.

• Maori보다 미국 영어를 구사하는 경우 미국에서 취업하는 것이 더 쉬울 수 있습니다. 마찬가지로, LISP 나 J보다는 자바 나 C를 직업 프로그래밍하는 것이 더 쉬운 일임이 분명합니다. 그러나 이러한 경제적 이점은 언어의 타고난 힘을 반영하지는 않습니다. 그 언어의 스피커의 힘에 관한 것입니다.
• "Hi"는 짧기 때문에 "ni hao"나 "shalom"보다 낫지 않습니다. 마찬가지로, 함수가 COBOL보다 APL로 간결하게 표현 될 수 있지만 언어의 타고난 힘을 반영하지는 않습니다.

내 의견은 "다른 언어보다 한 언어의 힘"에 대한 토론은 다른 그룹에 비해 화자의 우월감에 대한 표현이다. 요컨대, 편견과 고정 관념. 물론, 실제로 편견을 가진 사람들은 그들의 고정 관념을 매우 강하게 믿고 있으며, 아마도 당신이 그들의 마음을 바꾸도록 설득 할 수 없을 것입니다.