KISS 원칙이 프로그래밍 언어 설계에 적용 되었습니까?


14

KISS ( "간단하고 멍청하게 유지"또는 "간단하게 바보 유지", 예를 들어 여기 참조 )는 비록 공학에서 유래 한 것임에도 불구하고 소프트웨어 개발에서 중요한 원칙입니다. Wikipedia 기사에서 인용 :

Johnson은 설계 엔지니어 팀에게 몇 가지 도구를 제공한다는 이야기를 가장 잘 보여줍니다. 설계중인 제트 항공기는 이러한 도구 만 사용하여 전투 조건에서 현장의 평균 정비공이 수리 할 수 ​​있어야한다는 과제가 있습니다. 따라서 '멍청한'은 사물이 깨지는 방식과 문제를 해결할 수있는 정교함 사이의 관계를 말합니다.

이것을 소프트웨어 개발 분야에 적용하려면 "제트기"를 "소프트웨어", "평균 정비공"을 "평균 개발자"로, "전투 조건"을 "예상 소프트웨어 개발 / 유지 보수로" 조건 "(마감, 시간 제한, 회의 / 중단, 사용 가능한 도구 등).

따라서 나중에 쉽게 작업 할 수 있도록 소프트웨어를 단순하게 (또는 쉼표를 생략 할 경우 간단한 어리석게) 유지하는 것이 일반적으로 통용되는 아이디어입니다 .

그러나 KISS 원칙을 프로그래밍 언어 설계에도 적용 할 수 있습니까? 이 원칙을 염두에두고 특별히 고안된 프로그래밍 언어, 즉 "일반적인 작업 환경에서 평균 프로그래머가 최소한의인지 노력으로 최대한 많은 코드를 작성하고 유지하도록 허용"하는 것을 알고 있습니까?

특정 언어를 인용하면 언어 디자이너가 이러한 의도를 명확하게 표현하는 일부 문서에 대한 링크를 추가 할 수 있다면 좋을 것입니다. 어쨌든 특정 프로그래밍 언어에 대한 개인적인 의견보다는 설계자의 의도에 대해 배우고 싶습니다.


4
기본 언어 군 (또는 적어도 원래 언어의 의도)을 살펴 보셨습니까?

4
기본 언어와 파스칼은 둘 다 교육 언어로 설계되었습니다.
Michael Brown

1
간단하게 무엇을 의미합니까? 대부분의 언어는 그다지 많지 않다는 점에서 매우 간단합니다. 어셈블러보다 덜 복잡한 것은 없습니다. 프레임 워크는 종종 복잡하지만 "최소한인지 노력으로 최대한 많은 코드를 작성하고 유지 관리"할 수 있도록 설계되었습니다.
pdr December

7
Scheme (r)은 몇 년 동안 (10 년 동안) 교육 언어로 사용되었으며 LISP와 Algol을 단순화하여 개발되었습니다. SICP 책은 언어 자체를 가르치는 데 시간이 덜 걸립니다. 또한 DSL이 떠 오릅니다.
vpit3833

3
@Giorgio는 Haskell을 살펴 봅니다. 그것은 매우 가지고 있으며, 내 말은 아주 작은 비트를 내장에-. 대부분의 사업자는 언어 자체에 필요한 주요 라이브러리에있는 함수가 아니라, 그것은 제거하기 위해 최선을 다했다 모든 불필요한 부분을
지미 호파

답변:


15

미니멀리즘을 생각할 때 나는 Lisp and Go를 생각 합니다 . Lisp를 사용하면 함수와 목록 만 있으면 얻을 수있는만큼 간단합니다 (물론 조금 더 있지만 무엇이든). 그러나 Go 사례가 더 흥미 롭다고 생각합니다.

Go는 단순하도록 설계되었습니다 (적절한 읽기입니다). 그들이 사용하는 용어는 "기능 직교성 (feature orthogonality)"이며, 이는 어떤 특징이 진정으로 독특한 것을 제공하는 경우에만 추가되어야한다는 것을 의미합니다. 이는 Plan9에 대한 저자의 Russ CoxRob Pike의 생각으로 시작된 것으로 보인다. (최소한의 디자인에 관심이 있다면 간단한 창 시스템 에 관한 Rob Pike의 논문을 잘 읽어보십시오.)

다음은 간단한 구문 예입니다.

하나의 루핑 구조 만

루프는 다음 중 하나처럼 보일 수 있습니다.

무한 루프

for {
}

while 루프

for <conditional> {
}

전통적인 for 루프

for i := 0; i < 10; i++ {
}

Foreach 루프

// works for maps or arrays
for k, v := range arr {
}

다목적 스위치

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

여러 번 반환

return val1, val2, ...
  • 던질 필요가 없습니다 (마지막 반환 값으로 오류를 전달하십시오)
  • 출력 매개 변수가 필요 없음
  • 튜플의 필요성을 제거

인터페이스

type X interface {
    DoSomething()
    String() string
}
  • 제네릭과 유사한 문제 해결
  • 추상화 가능

임베딩

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}
  • 상속과 같은 문제를 해결
  • 수업이 필요하지 않음

채널

세마포어를 구현하는 데 사용할 수 있습니다

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

스레드 간 메시지 전달에 사용

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

비동기 이벤트를 처리하는 데 사용할 수 있습니다

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

결론

문법의 모든 부분을 다루지는 않겠지 만, 미니멀리즘이 무엇을 할 수 있는지 알 수 있기를 바랍니다. 이 언어는 많은 새로운 기능을 추가하기 때문이 아니라 추가 기능없이 다른 언어의 최상의 기능을 사용하기 때문에 흥미 롭습니다.

일반적으로 문제를 해결하는 한 가지 "최상의"방법이 있습니다. 예를 들어, 메일 링리스트에서 많은 사용자가 제네릭이없는 것에 대해 불평합니다. 토론 후, 그들은 자신이하고 싶은 모든 것이 인터페이스를 통해 이루어질 수 있다는 것을 알고 있습니다. 관용구 문에 대한 효과적인 예를 읽으십시오 .

KISS 언어의 장점은 코드 스타일이 언어에 의해 제한되기 때문에 관용적 코드를 작성할 수 있다는 것입니다. 예를 들어, Go에서는 다음과 같이 작성할 수 없습니다.

if <condition>
    statement;

중괄호를 사용해야합니다.

if <condition> {
    statement;
}

구문에는 다른 많은 사람들의 코드를 쉽게 읽을 수있는 다른 많은 예제가 있습니다.

특색있는 언어에 비해 KISS 언어의 장점 :

  • 다른 사람의 코드를 이해하기 쉽게
  • 전체 언어를 이해하기 쉬움 (C ++은 이해하기 어려운 것으로 유명합니다)
  • 구문이 아닌 알고리즘에 집중

5
겸손한 의견으로는 전통적인 for 루프 의 구문은 KISS가 아닙니다. 물론 그것은 모든 C와 같은 프로그래머에게 친숙하지만, 처음 배운 것을 기억합니다. 매우 혼란 스러웠습니다. 기본은 더 KISS : for i=1 to 10또는 python입니다.for item in group
mouviciel

3
@mouviciel-나는 전통적인 for 루프를 거의 사용하지 않습니다. 문제 for i = 1 to 10i10이 될지 여부 입니다. 언어에 따라 다를 수 있습니다 (bash에는 10, 파이썬에는 포함되지 않음). 전통적인 for 루프는 보편적입니다.
beatgammit

+1, 특히 미니멀리즘의 이점에 대한 요약.
Giorgio

1
사례 연구로 가기는 흥미 롭습니다. 실제로, "간단한"언어는 "간단한"코드 나 더 쉬운 이해로 이어지지 않습니다. 코드를 이해하기 쉽도록 복잡성이 더 높아야합니다 (예 : 좋은 제네릭 지원).
Andres F.

14

파이썬선 (Zen)은 왜 파이썬이 내가 할 수있는 것보다 훨씬 더 단순한 언어인지를 말해 줄 것이라고 생각합니다 .

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

@Giorgio 님의 질문에 답변

귀하의 질문에 따르면

"이 원칙을 염두에두고 특별히 설계된 모든 프로그래밍 언어를 알고 있습니다. 즉,"평균적인 작업 조건 하에서 일반 프로그래머가 최소한의인지 노력으로 최대한 많은 코드를 작성하고 유지하도록 허용합니다. "

파이썬은 저에게 즉시 떠오르는 것입니다. Python의 디자인은 Perl의 방법론 인 유명한 "한 가지 이상의 방법이 있습니다"에 직접 반응합니다. 프로그래머가 코드를 매우 쉽게 작성할 수 있도록하는 것이 좋지만 유지 관리에는 도움이되지 않습니다. Perl로 작성된 (매우 잘못 작성된, 인정할 것입니다) 프로그램을 관리하기 전에 파이썬이 좋은 코딩 관행과 간결한 언어를 강요하는 것을 좋아합니다.

파이썬은 또한 프로그램을 작성할 때 하나의 특정 방법론을 따르도록 강요하지 않습니다. 엄격한 객체 지향 프로그래밍 스타일을 따르거나 순차적으로 실행할 간단한 스크립트를 작성할 수 있습니다. 클래스를 초기화 main()할 필요가 없다면 Java에서 수행 해야하는 것처럼 메소드 를 호출하는 것이 매우 좋습니다. (또한 파이썬에서 stdout으로 인쇄하는 것은 훌륭하지만 다소 의미가 없습니다.)

마지막으로, 언어와 함께 광범위한 표준 라이브러리를 포함하는 "배터리 포함"방법이 훌륭합니다. 패키지의 일부 외부 저장소를 탐색하는 대신 필요한 대부분이 이미 언어에 포함되어 있습니다. 외부 저장소를 갖는 것도 좋지만 기본 작업을 수행하기 위해 파고 들지 않아도 정말 편리합니다.


3
유용한 인용에 감사드립니다. 이것이 파이썬 디자이너의 공식적인 의도입니까? 또한 모든 독자가 Python에 대한 귀하의 의견에 동의하지는 않을 수도 있으므로 "Python은 단순한 언어"라고 잘 알려진 사실로 언급하기에는 너무 강할 수 있습니다. "Python은 단순성을 염두에두고 설계되었습니다"로 공식화 할 수 있습니까?
Giorgio

@Giorgio-파이썬은 실제로 간단한 언어라는 것은 많은 개발자들의 경험입니다. 배우기, 쓰기 및 읽기가 간단합니다. 따옴표에 대해서는 파이썬이 "배터리 포함"이므로 import this명령 을 사용하여 언어에서 직접 가져올 수 있습니다 .
mouviciel

1
TCL도 이에 대한 좋은 해답이며 IIRC도 PERL의 복잡성에 대한 대응이었습니다.
jk.

@mouviciel 여러 곳에서 놀랍도록 복잡한 파이썬 스파게티 코드를 발견 한 후에는 더 이상 파이썬이 목표를 달성하지 못한다고 생각합니다. 파이썬은 단순함에있어 대부분의 언어보다 낫지 않습니다. 우연히 난독 화하는 데 매우 효과적 일 수 있습니다.
이즈 카타

1
사람들이 대부분의 __magic_functions __ () 및 @decorators에서 멀리 떨어져있는 한 파이썬은 간단합니다.
weberc2

3

"단순성"을 유지하는 데있어 중요한 열쇠는 복잡성이 필요한시기를 인식하고이를 가장 잘 처리 할 수있는 시스템 부분을 갖추는 것입니다. 불변의 값, 변경 가능한 값 및 엔티티를 구별하지 않는 단일 종류의 객체 참조가있어 Java를 "단순하게"만들지 만, 값과 엔티티를 구별 할 필요가 없습니다. 단지 프로그래머가 도구를 빼앗아 도움을 줄 수 있습니다.

보다 일반적으로, 프로그래밍 언어 또는 프레임 워크 기능이 다중 사용 사례를 지원하려는 경우, 다른 사용 사례에서 다른 동작이 적절한 상황이 발생하지 않도록해야하지만 컴파일러는 말할 수 없습니다. 그들 떨어져. 언어 나 프레임 워크에 더 많은 유형을 추가하면 복잡한 것처럼 보일 수 있지만 많은 경우 실제로 일을 더 쉽게 만들 수 있습니다.

예를 들어, C에서 부호있는 유형과 부호없는 유형을 둘러싼 규칙의 혼란을 고려하십시오. 이러한 규칙의 복잡성은 일부 코드는 부호없는 정수 유형을 사용하여 숫자를 나타내는 반면 다른 코드는이를 사용하여 래핑 대수 반지의 멤버를 나타내는 데 있습니다. (특히 정수 세트 합동 모드 2ⁿ). 유형 변환 규칙은 때때로 한 가지 용도에 적합한 방식으로, 때로는 다른 용도에 적합한 방식으로 동작합니다. 랩핑 및 랩핑되지 않은 유형이 따로 있으면 정수 유형의 수를 두 배로 늘리지 만 이와 관련된 규칙을 단순화 할 수 있습니다.

  • 임의의 크기의 비링 정수 타입은 임의의 크기의 링에 할당 될 수있다; 링은 동일하거나 더 작은 크기 의 링에만 할당 될 수있다 .

  • 비 고리 정수 및 고리를 포함하는 관계 연산자 이외의 연산은 내재적으로 정수를 고리 유형으로 변환합니다.

  • 고리는 명시 적으로 숫자 또는 더 큰 고리로 캐스트 될 수있다. 부호없는 링의 값은 링의 0에 추가 될 때 링 값을 산출하는 음이 아닌 가장 작은 정수입니다. 부호있는 링의 값은 링의 0에 추가 될 때 링 값을 산출하는 가장 작은 크기의 정수이며, 타이의 경우 음의 값이 선호됩니다.

  • 상기 언급 된 것을 제외하고, 링은 동일하거나 더 작은 링을 갖는 작동으로 제한된다.

  • 다른 유형의 비링 정수에 대한 연산은 숫자를 피연산자의 모든 값을 수용 할 수있는 유형으로 상향 변환하거나 적절한 유형이없는 경우 컴파일러에서 거부해야합니다.

링 유형을 정의하면 정수 유형의 수를 두 배로 늘리는 것처럼 보이지만 이식 가능한 코드 작성을 크게 단순화합니다. 숫자와 링에 동일한 부호없는 유형을 사용하면 유형 수가 줄어들지 만 복잡한 규칙으로 이어 지므로 효율적인 휴대용 코드를 작성하는 것이 거의 불가능합니다.


+1 완전히 동의했습니다. "간단한"언어 (작은 스펙을 갖는 단순한 의미)가 반드시 간단한 코드 나 프로그래머의 추론을 이끌어내는 것은 아닙니다.
Andres F.

좋은 의견. 비용과 이점 측면에서 복잡성을 추가해야합니다.
user1071847

2

틀림없이, Tcl은 이러한 라인을 따라 개발되었습니다. 전체 언어는 단일 매뉴얼 페이지에서 12 개의 규칙으로 만 설명 할 수 있습니다 . 매우 간단하고 일관됩니다.

Tcl의 제작자는 다음을 원래 목표로 주장했습니다.

  • 언어는 확장 가능해야합니다. 각 응용 프로그램이 언어의 기본 기능에 고유 한 기능을 추가하는 것이 매우 쉬워야하며, 응용 프로그램 별 기능은 마치 처음부터 언어로 설계된 것처럼 자연스럽게 표시되어야합니다.
  • 언어는 매우 간단하고 일반적인 언어이므로 여러 다른 응용 프로그램에서 쉽게 작동하고 응용 프로그램이 제공 할 수있는 기능을 제한하지 않아야합니다.
  • 흥미로운 기능은 대부분 응용 프로그램에서 제공되므로 언어의 기본 목적은 확장 기능을 통합하거나 "함께 붙입니다". 따라서 언어에는 통합을위한 좋은 기능이 있어야합니다.

"보낸 사람 은 Tcl의 역사 "- http://www.tcl.tk/about/history.html


2

KISS로 인해 언어가 디자인에 고정되어 있으면 언어를 확장 할 수 없습니다. 성장할 수없는 언어는 죽을 것입니다.

다음 비디오에서 Guy Steele 은 프로그래밍 언어가 성장해야하는 이유와 이유를 똑똑하게 설명합니다. KISS를 적용하면 일단 석방 되었기 때문에 랑게 게가 어떻게 커질 수 있습니까? 도구 세트는 고정되어 있으며 절대로 변경할 수 없습니다.

"언어 성장" 에 관한 1998 ACM OOPSLA 컨퍼런스에서 Guy Steele의 기조 연설은 사용자가 개발할 수있는 프로그래밍 언어 설계와 관련된 중요성과 문제를 논의합니다.

한 시간 길이의 비디오이지만 볼만한 가치가 있습니다. Guy Steele이 누군지 모른다면 언어 디자인에 대해 이야기 할 때 정말로해야합니다.

KISS를 언어 디자인에 일반적으로 적용하는 것이 잘못되었다고 생각하기 때문에이 비디오를 답으로 선택하고, 언어 디자인의 저명한 사람으로부터 연설을 보는 것이 언어 디자인의 미래에 대한 이해를 넓히는 데 도움이되기를 바랍니다.

언어 설계에 대해 배우기 위해 여기에 왔고 KISS를 사용하지 않는 이유를 제시했기 때문에 언어 설계에 도움이되는 것을 지적하는 것이 공평합니다. 인지의 표기법

편집하다

위의 답변을 썼을 때의 이유는 다음과 같은 추론에 근거한 것입니다. 엔진을 고정 된 도구 세트로만 유지할 수 있다면 언어 설계와 관련하여 그 의미를 다시 한 번 수정하면 언어가 해제되면 언어를 변경할 수 없다는 것입니다. 의견은 그것이 의미하는 것이 아님을 나타냅니다. 수정 된 이해와 더 일치 할이 수정 된 답변을 제시하겠습니다.

그너 티브 차원의 표기법 을 살펴보면 언어 설계와 관련된 경쟁 차원이 단순성보다 많다는 것을 알게되고, 너무 중점을두면 다른 사람들에게 고통을 줄 것입니다. 간결성 (KISS)에 중점을두고 언어 설계 전문가들에 의해 뒷받침 되는 문제로 가이 스틸 (Gay Steele)연설 을 제출하여 디자인을 단순하게 유지하려는 노력이 다른 차원에 영향을 미친다는 것을 보여주었습니다. 더 중요한 것은 단순성뿐만 아니라 다양한 차원을 살펴보고 장단점을 평가해야한다는 것을 전달하려고합니다.


3
비디오를 사용할 수 없게되면 어떻게됩니까? 또는 일부 국가에서 액세스 할 수없는 경우 귀하의 답변은 완전하고 독립적이어야합니다. 최소한 비디오에 대한 간략한 요약을 제공하도록 업데이트하십시오. 링크 만 답변 이 실제로 도움이되지 않으며 언제든지 제거 될 수 있습니다.
yannis

3
@AndreasScheinert 답변 방법 가이드를 사용하면 링크에 항상 요약 및 / 또는 관련 견적이 첨부되어야합니다.
Thomas Owens

3
귀하의 평가에 동의 할 수 있을지 모르겠습니다. 예를 들어 Tcl은 매우 간단합니다. 사용에 관한 11 가지 규칙만으로 수년간 지속되었습니다. 그럼에도 불구하고, 그것은 20 년 이상 존재하면서 상당히 단순 해졌습니다. 현재 12 개의 규칙이 있으며, 이는 라이브러리가 커졌을뿐만 아니라 모든 단순성을 유지하면서 기본 특성도 커질 수 있음을 증명합니다.
Bryan Oakley

1
"KISS를 적용하면 언어가 릴리스 된 후에 언어가 어떻게 성장할 수 있을까요? 일단 도구 세트가 고정되어 있으며 절대로 변경할 수 없습니다." 새로운 라이브러리 (영어, 단어에 새로운 단어 추가)를 추가하거나 새로운 언어 구문 (영어에서는 새로운 동사 시제, 새로운 전치사 등)을 추가한다는 의미입니까? 자연어는 결국 새로운 단어를 계속 추가하면서 새로운 문법 규칙 추가를 중단합니다. 따라서 직관에서 단순함은 라이브러리 / 단어 수가 아니라 문법 규칙의 수를 나타냅니다.
Giorgio

3
@Guy Coder : 반면에, 링크를 게시 한 비디오는 답변 시작 부분에서 다른 말로 표현하는 것처럼 보입니다. 즉, 언어는 사용자 (프로그래머)가 언어를 확장하십시오 (새 라이브러리 추가). 핵심 언어가 무한정 성장해야한다고 말하는 것은 아닙니다.
Giorgio

1

여기에서 큰 따옴표의 브루스 맥키 니의 하드 코어 비주얼 베이직 에서 BASIC의 디자이너의 입에 박았 단어를 설정, Kemeny커츠 . 강조합니다.

모든 컴퓨터 언어는 자신의 느낌, 분위기, 정신을 가지고 있습니다. 당신은이 정신을 실제로 정의 할 수는 없지만 그것을 볼 때 그것이 무엇인지 알고 있습니다. 나는 Basic을 Albert Einstein의 진술에 대한 반추라고 생각합니다.

가능한 한 단순하게 만드십시오.

이 인용문은 Basic, John Kemeny 및 Thomas Kurtz의 원래 디자이너가 작성 했으므로 더 단순화되었을 것입니다.

가능한 것보다 간단하게 만드십시오.

그것이 바로 하드 코어 Visual Basic 프로그래머들이 모이는 모순입니다. 우리는 단순하고 우아하며 직관적 인 것을 원하지만 그렇지 않습니다. 우리는 우리의 프로그램이 현실을 모델링하기를 원하지만 그렇지 않습니다. 우리는 컴퓨터 나 운영 체제가 우리가 생각하기를 원하는 방식이 아니라 우리의 언어가 생각하는 방식대로 작동하기를 원하지만 가격을 지불하지는 않습니다 .


관련 메모에서, 언어 구성이 "다수의 목적을 달성하기 위해"만들어 질 수 있다는 사실은 그러한 디자인이 다른 목적을 위해 다른 구성을 갖는 것보다 바람직하다는 것을 의미하지는 않는다. 예를 들어, C는 부호없는 유형을 사용하여 숫자 수량과 래핑 대수 링의 멤버를 나타냅니다. 다수의 추가 모든 링의 크기 또는 부호의 것은 구성원 수득한다 같은 결과를 피연산자의 값을 처리 할 수있는 충분한 크기를 산출한다 임의의 크기 및 부호의 두 숫자를가하면서, 링. 두 가지 목적으로 서명되지 않은 유형 사용 ...
supercat

... C의 규칙은 깨끗하고 이식 가능한 코드를 작성하는 것이 거의 불가능한 방식으로 때때로 숫자로, 때로는 링 멤버로 간주해야 함을 의미합니다.
supercat

1

그러나 KISS 원칙을 프로그래밍 언어 설계에도 적용 할 수 있습니까? 이 원칙을 염두에두고 특별히 고안된 프로그래밍 언어, 즉 "일반적인 작업 환경에서 평균 프로그래머가 최소한의인지 노력으로 최대한 많은 코드를 작성하고 유지하도록 허용"하는 것을 알고 있습니까?

내 생각에 간단한 프로그래밍 언어는 최소한의 구문과 기능 (Scheme, Forth, ML)이 거의없는 언어이기 때문에 "단순"의 의미를 명확히하는 것이 좋습니다. RAD (rapid application development)를 염두에두고 언어 디자인을 실제로 찾고 있다고 생각하며 그중 몇 가지가 있습니다. 이 StackOverflow 스레드를 참조하십시오 (예 : /programming/66227/what-is-the-best-multi-platform-rad-language)


"제 생각에 간단한 프로그래밍 언어는 구문이 적고 기능이 거의없는 언어이기 때문에"(Scheme, Forth, ML) : 글쎄, 실제로 위키피디아에서 정의를 복사했지만 두 가지를 식별하는 경향이 있습니다. 예를 들어, Scheme은 매우 빠르게 배울 수 있으며 그 후에 해결해야 할 문제에 집중할 수 있습니다. 다른 언어 (직장에서 사용하는 C ++와 같은)는 계속 커지고 항상 새로운 것을 배워야합니다. 또한 다른 프로그래머가 다른 언어 하위 집합을 사용하는 경향이 있기 때문에 코드 유지 관리가 쉽지 않습니다. 따라서 SML과 Scheme을 "간단한"것으로 간주합니다.
Giorgio

1

비록 아무도 C를 언급하지 않았지만, 몇 가지 중요한 방식으로 단순성을 최우선으로 생각하지만 프로그래머가 단순성을 인식하지 못하는 급진적 인 방식으로 종종 사용됩니다.

  • 숨겨진 마술은 없습니다. 당신이 작성하는 경우 a + bC에서, 당신은 기껏해야 하나의 어셈블러 명령어로 컴파일 할 것이라는 보장이있다.

    Java와 같은 비교적 간단한 언어에서도 a + b변수가 문자열 인 경우 와 같은 간단한 명령문 은 몇 마이크로 초가 걸릴 수 있습니다. 다른 언어 a + b는 핑크 코끼리가 나타나도록 과부하 될 수있는 C ++의 극단적 인 예를 통해 이것에 훨씬 더 많은 것을 추가합니다 . C에서는 그렇지 않습니다. 함수 호출이 아닌 경우 몇 나노초 이상 걸리지 않습니다. 이러한 성능 예측 가능성은 C의 주요 기능 중 하나이며, 확실히 단순성입니다.

  • 데이터 유형은 메모리에 구축하려는 모든 흥미로운 데이터 구조를 설명하면서 가능한 한 간단합니다. CPU가 처리 할 수있는 기본 유형은 + 집계 ( struct) + 반복 (배열) + 참조 (포인터)입니다. ).

    이와 관련하여 다양한 lisp 기반 언어가 C보다 훨씬 단순하다는 것은 사실입니다. 그러나 C와 마찬가지로 프로그래머가 메모리를 자유롭게 조작 할 수는 없습니다.

  • 기능의 직교성 : 기능을 자유롭게 결합 할 수 있으며 기능이 예상대로 작동합니다. 많은 언어는 특정 구문이 정의 된 컨텍스트에만 표시되도록하여 실패합니다.

    예를 들어 C 및 C ++의 가변 길이 배열을 예로 들어 보겠습니다. C는 모든 곳에서 런타임 길이를 허용하지만 C ++ 표준을 확장하려는 가장 자유로운 요청은 자동 배열과 같은 특정 컨텍스트에서만, 심지어 첫 번째 차원에서만 허용합니다. 이를 통해 C는 런타임에만 알려진 크기의 진정한 다차원 배열을 처리 할 수있는 반면 C ++ 프로그래머는 data[k + (j + i*lineLength)*lineCount]계속해서 다시 쓰도록 축소 됩니다.

    이것의 또 다른 예는 포인터입니다. C의 데이터 포인터 이것은 실제로 다른 변수의 메모리 주소를 보유하는 변수에 지나지 않습니다. 포인터 자체는 변수이므로 이중 포인터는 잘 정의 된 것입니다. 즉 무엇이 무엇인지 int, int*무엇이 int**있어야 하는지 분명 합니다. 당신이 무엇인지 전혀 단서가없는 경우 C ++ 참조이 비교 int&&의 의미 부여 intint&!)

C가 너무 많은 증오를 얻은 것은 바로이 단순성이라는 것이 사실입니다. 언어의 단순성으로 인해 프로그래머는 프로그래머보다 더 많은 자유를 얻을 수 있으므로 정의되지 않은 동작과 잘못 처리 된 포인터에 많은 문제가 발생합니다. 특히 프로그래머가 int (*array[m])(struct foo* (*arg)[n])독자에게 두통을 유발하는 경향이있는 유형 으로 변수를 정의 할 수있는 직교성의 단순성은 실제로 몇 가지 간단한 기능의 자유로운 조합에 의해 매우 복잡한 형태가 매우 간결한 형태로 표현 될 수 있기 때문에 독자에게 두통을주는 경향이 있습니다 . 이것은 C가 뛰어나고 사용하기 어려운 언어라는 명성을 얻는 단순성의 유형입니다.

또한이 언어의 단순성으로 인해 프로그래머는 기능이 풍부한 언어보다 훨씬 더 많은 코드를 작성하여 버그가 번성 할 수있는 비옥 한 기반을 제공하게되었습니다. 그럼에도 불구하고 주요 목표는 가상 머신이 아닌 실제 컴퓨터를 프로그래밍하는 것이 가장 간단한 고급 언어로 남아 있습니다.


downvoter가 투표 이유를 설명하는 메시지를 남길 수 있습니까?
Giorgio

C는 엉망입니다. 부호가없는 long에 부호있는 short를 추가하고 결과를 int에 저장하면 얻을 수있는 작업을 시도해보십시오. "long long"이 없어도 여덟 개의 정수 유형이 있습니다. 간단하지 않습니다.
Simon B

@SimonB 당신은 내 게시물이 무엇인지 명확하게 이해하지 못했습니다. 정수 유형에 대한 단순성은 다음과 같습니다. 정수 유형은 크기 (바이트 및 비트)를 가지며 부호가 있거나 부호가 없을 수 있습니다. 이 두 직교 피쳐의 조합을 사용할 수 있습니다. 내가 말하는 것은 바로이 직교성입니다. C에는 실제 하드웨어를 완전히 활용하는 데 필요한 모든 기능이 있으며 특정 복잡성을 수반합니다. 그러나 C가 이러한 복잡성을 처리하는 방식은 간단한 개념을 직교 방식으로 결합하여 프로그래머 가 복잡한 작업을 수행 하도록하는 것입니다.
cmaster-monica reinstate

0

Java Wikipedia-위키 백과에 명시 적으로 언급되어 있지는 않았지만, 단순화는 여러 번 언급되었으며 그 당시의 유일한 심각한 OO 가능 언어가 느슨하게 사용 된 언어는 C ++로 강력했습니다. 그러나 경고에 대한 몇 가지 함정이 있습니다.

JVM은 크로스 플랫폼 개발을 단순화하기위한 방법으로 고안되었으며 "한 번에 어디서나 쓰기"는 몇 년 동안 Java의 만트라가되었습니다.

C #은 언어의 단순화 범주에 속한다고 생각합니다.


C #이 처음에 C ++ 단순화로 설계되었다는 의미입니까?
Giorgio

2
C ++과 OO? 앨런 케이는 그렇게 생각하지 않습니다. C # Sinplyfication ???? 나는 당신이 단순함의 의미를 모른다. 나는 그런 것들을 선언하기 전에 진술하는 것이 최선이라고 생각합니다. LISP는 구문이 거의 없으므로 단순합니다. 반대로 C #에는 많은 구문과 키워드가 있습니다.
AndreasScheinert

플랫폼 간 개발을 단순화 할 수 있다고해서 언어 자체가 단순하지는 않습니다. 크로스 플랫폼이지만 무언가 그 자체로는 여전히 간단하지 않을 수 있습니다.
Bryan Oakley

@Bryan Agreed-Java의 디자인은 크로스 플랫폼 프로그램이 (당시) 단순하지 않다는 것을 고려하고 간단한 프로그램을 만들려면 간단한 언어가 필요했으며 프로그램 자체에서 플랫폼 특정 코드를 처리하는 복잡성을 제거해야했습니다.
mattnz

2
@Giorgio C #은 Java를 재구성 한 것입니다. Java는 C ++보다 덜 복잡하고 (예 : 다중 상속 없음) 훨씬 더 큰 것 (예 : 방대한 표준 라이브러리, 가비지 수집)입니다.
Sean McSomething

-2

흠 ... 이것은 실제로 '긍정적으로'대답하기 어려운 질문입니다. 프로그래밍 언어 디자인의 단순성 (그리고 작동하기 쉬운 ')이 생각되면 즉시 생각합니다.

  1. 코드의 "가독성"– 언어가 객체, 메소드 등을 얼마나 잘 캡슐화하는지
  2. 언어 API 및 인터페이스의 일관성

이런 것들을 잘하는 많은 언어들이 있습니다. 그러나 제 머릿속에 튀어 나오는 것은 '프로그래밍 언어'로서 PHP를 잘 하지 않는 언어입니다 .

[면책 조항-PHP를 작성했으며 PHP는 여전히 간단한 웹 프로젝트를위한 '언어로 이동'입니다. 이것은 사랑에 대한 비판이다 ...]

첫째, PHP는 일반적으로 웹 서버에서 실행되는 환경에 적합합니다. 설정, 유지 관리가 쉽습니다.

PHP로 어려움을 겪고있는 곳 : "비정상적인"일을하고 싶을 때-일반적으로 정기적으로하지 않는 일 (필자는 SOAP 웹 서비스를 소비한다고 생각하는 경우-내가 한 것이 아닌 것) PHP로 많은 것을 했어요), 당신은 두 가지 옵션에 직면합니다 :

1) PHP에 대한 다양한 오픈 소스 확장. PHP 객체 모델은 인터페이스 디자인이 라이브러리에서 라이브러리로, 개발자에서 개발자로 크게 일관성이없는 곳에서 충분히 느슨합니다. 누군가 들어 본 적이없는 라이브러리를 사용하는 일련의 코드에 직면 할 때 언어가 느슨한 API / 라이브러리 생성을 허용하기 때문에 '이것이 무엇을 하는가'를 알아내는 데 많은 시간을 소비합니다.

2) "내장"기능- 많은 기능이 있습니다 . 다른 라이브러리를 찾거나 나중에 약간의 기능을 구현하는 몇 가지 토끼 구멍을 뚫었습니다.impossiblyfound_basefunction()

제 생각에는 단순성은 일관성입니다.


-3

이제 프로그래밍 언어에 대한 KISS의 접근 방식은 재미있는 개념입니다. 적어도 프로그래밍 언어를 CPU의 명령어 세트에 대한 추상화 계층으로 생각한다면 말입니다. "KISS"를 더 자세히 정의하지 않은 경우. 여기서 말하는 것은 옥스 카르 트가 자동차에 최대한 적용되는 KISS입니다.

이제 KISS에 대한 또 다른 해석은 "불필요한 장식품없이 똑똑하게 수행되고 지나치게 복잡하지는 않습니다"와 같은 것일 수 있습니다. 특히 비슷한 것들에 대해 너무 많은 특정 사례가 없어야한다고 주장 할 수 있습니다. 일반적으로 수학은 본질적으로 물건을 끓여주는 데 능숙합니다. .

프로그래밍에는 두 가지 유명한 추상 모델이 있습니다.

  • 하나는 컴퓨터와 컴퓨터가 할 수있는 모든 것을 계산할 수있는 간단한 교육 모델을 정의하는 튜링 머신입니다.
  • 다른 하나는 Church 등의 Lambda-Calculus입니다. 알. 그것은 힘과 같습니다

재미있는 점은 튜링 머신의 레이아웃이 매우 단순하지만 다루기 쉬운 시스템이 아니며 "스마트 키스"에 적합하지 않다는 것입니다. 그러나 Lambda Calculus는 우리가 알고있는 프로그래밍 언어와 더 관련이 있습니다. Lisp와 Scheme은 람다 미적분학의 개척 기능으로 많은 언어로 발전했습니다.

Lisp과 Scheme은 구문이 가장 현명하다. 구문은 프로그래밍 언어의 주요 문제입니다 (아마도 항상 새로 개발 된 이유 일 수 있습니다). C ++의 경우 인간의 두뇌가 컴파일러가 일부 소스 라인을 해석하는 방법을 예측하는 것은 거의 불가능합니다.)

Lisps는 명령에 대한 하나의 공통 형식을 도입하여 구문 복잡성을 완전히 줄입니다.

(command param1 param2 ...)

이것은 다음과 같은 메소드 호출 일 수 있습니다.

(max 1 2 3 4)

if 분기, 루프 등

(if (< 1 2) 
    (write 4)
    (write 5))

(여기의 모든 코드는 의사 리스프 / 거울 불가지론입니다)

형태

(command param1 param2 ...)

목록으로 해석 될 수도 있습니다

(item1 item2 item3)

이것이 Lisps의 단순함과 아름다움의 기초입니다. if명령문 목록에서와 같이 중첩 된 목록 은 트리를 구성 하기 때문에 기계와 기계 앞의 사람이 쉽게 이해할 수 있습니다.

Lisps의 또 다른 기능은 매크로 입니다. 여기에서 더 이상 자세히 다루지 않겠습니다. 그러나 일반적인 함수 호출과 "구문 (예 : for 루프, 변수 선언 등) 사이에는 구문상의 차이가 없으므로 파서가 처리해야 할 모든 것 프로그래밍 언어) 직접 구문을 만들 수 있습니다 매크로는 본질적으로 프로그램을 구성 하는 트리 조작입니다 .

나는 Lisp가 프로그래밍에 KISS를 가지고 있다고 생각합니다. 매크로를 사용하여 구문을 조작 할 수 있다는 것은 Lisp가 상당히 역동적으로 진화 한 현상으로 이어졌습니다. 다음과 같은 새로운 언어 기능이 필요합니다-객체 방향을 말하십시오-매크로로 OOP 시스템을 작성하십시오!

C가 OOP 기능 (C ++, Obj. C)으로 약 2 회 연장되었지만 Lisp는 여러 번 연장되었지만 결국 승자가되었습니다.

이것이 Lisp의 또 다른 단점입니다. Lisp의 흥미로운 새로운 돌연변이에 대해서는 Clojure와 Clojurescript를 참조하십시오.

KISS 속성 때문에 Lisps는 일부 언어를 가르치는 것으로 선호됩니다. 교육 언어의 청사진에서 Fogus 개요와 같이 ( http://blog.fogus.me/2013/01/21/enfield-a-programming-language-designed-for-pedagogy/ )

우선, 나는 새로운 주제를 배우고 때로는 복잡한 주제에 대해 학생들에게 경이로운 구문 규칙을 사용하는 것은 매우 해롭다는 것을 믿는 사람입니다. 따라서 Enfield는 최소한의 구문 규칙과 Lisp와 유사한 구문보다 최소로 설계되었습니다.

2
OP는이 질문과 관련하여 KISS를 " 명쾌한 노력으로 최소한의 코드로 최대한 많은 코드를 작성하고 유지할 수있는 평균 작업 조건 하의 일반 프로그래머가 가능"하도록 명확하게 정의합니다 . OP는 또한 " 특정 프로그래밍 언어에 대한 개인적인 견해보다는 디자이너 (문서화 된) 의도에 대해 배우고 싶다"고
gnat
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.