구문은 프로그래밍 언어에서 정말로 중요합니까? [닫은]

교수 중 한 사람은 "구문은 프로그래밍 언어의 UI"라고 말하고, 루비와 같은 언어는 가독성이 좋아지고 점점 늘어나고 있지만 C \ C ++로 생산적인 많은 프로그래머를 볼 수 있습니다. 받아 들여야합니까?

나는 그것에 대한 당신의 의견을 알고 싶습니다.

면책 조항 : 나는 논쟁을 시작하려고하지 않습니다. 나는 이것이 좋은 토론 주제라고 생각했다.

업데이트 : 이것은 좋은 주제로 판명되었습니다. 모두 참여하게되어 기쁩니다.

그렇습니다. 확실치 않다면 APL , J , Brainfuck , 또는 단순하고 단순한 Lisp 또는 Forth를 사용하여 그저 사소한 프로그램을 이해하려고 노력하십시오. 그런 다음 예를 들어 파이썬과 비교하십시오.

그런 다음 동일한 Python (또는 Ruby 또는 C #)을 Cobol 또는 VB6 과 비교하십시오 .

나는 털이 많은 구문이 나쁘고 모든 언어 환경 에서 자연어와 같은 구문이 좋다고 말하려고하지 않습니다 . 그러나 명백하게 구문 은 큰 차이를 만듭니다. 대체로 튜링 머신 프로그램으로 작성할 수있는 가장 아름다운 프로그래밍 언어로 작성할 수있는 모든 것이 있습니다. 그러나 일반적으로 원하지 않습니까?

실제로 나는 그것이 중요하다고 생각합니다. 가독성은 이미 위에서 논의되었습니다. 또 다른 문제는 아이디어 / 알고리즘을 표현하기 위해 몇 번의 키 입력이 필요합니까? 또 다른 문제는 간단한 오타가 사람의 눈을 잡기 어렵고 얼마나 많은 장난을 유발할 수 있는가입니다.

또한 일부 상황에서는 다른 컴퓨터 프로그램을 통해 코드 조각을 분석 및 / 또는 생성하는 것이 유용하다는 것을 알았습니다. 언어 구문 분석 및 / 또는 올바른 코드 생성의 어려움은 이러한 도구를 작성 / 유지하는 데 얼마나 많은 노력이 필요한지에 직접적인 영향을줍니다.

교수님 께서 Syntactic sugar를 언급하신 것 같습니다 .

구문 설탕 (Syntactic sugar)은 컴퓨터 과학 용어로, 프로그래밍 언어 내에서 구문을 나타내며,이를 통해 표현하거나 표현할 수있는 대안이 존재합니다 .

따라서 교수가 암시하는 것은 하나의 프로그래밍 언어로 작성된 코드 / 구문이 무엇이든 동일하거나 심지어 동일한 언어로 다른 언어로 표현 될 수 있다는 것입니다.

Robertd Martin은 Structured Programming theorem 에서 뽑아서 RailsConf 2010의 기조 연설에서 프로그래머가 프로그래밍 언어를 사용하여 기본적으로 수행하는 작업을 추상화했습니다 .

• 순서 (할당)
• 선택 (if statement)
• 반복 (do-loops)

그것은 모든 프로그래머들이 다른 구문이나 UI (User Interface)에서 한 프로그래밍 언어에서 다른 프로그래밍 언어로 수행하는 것입니다. 교수님이 프로그래밍 언어에 대해 추상적으로 이야기하고 있다면 이것이 내가 추측하고있는 것입니다.

그래서의 본질 , 구문은 중요하지 않습니다 . 그러나 구체적이기를 원한다면 분명히 특정 언어와 구문이 다른 작업보다 특정 작업에 더 적합하므로 구문이 중요하다고 주장 할 수 있습니다.

예, 아니오

구문에는 몇 가지 다른 측면이 있습니다.

• 가독성
• 표현력
• 파싱 ​​성

가독성은 이미 언급되었습니다.

표현력은 흥미로운 경우입니다. 함수 전달을 예로 사용하겠습니다. 시맨틱 / 구문 통의 변곡점이기 때문입니다.

C ++을 예로 들어 봅시다. 이 방식 후에 1 차 함수를 만들 수 있습니다.

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

이 특정 관용구는 일반적으로 Stepanov의 프로그래밍 요소에 사용됩니다 .

다른 한편으로는, 내가 좋아하는 뭔가 커먼 리스프에서 그것을 모방 할 수 이 :

(defun myfunc() )

(defun run_func(fun)
  (fun))

또는 Perl에서-

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

또는 파이썬에서-

def myfunc():
    pass

def run_func(f):
    f()

비록 C ++ 예제는 어떤 타입 메타 데이터를 가지고 있지만 이것들은 본질적으로 동일한 의미 론적 내용을 가지고 있습니다. 어떤 언어가 고차 함수를 가장 잘 전달한다는 아이디어를 표현합니까? 일반적인 리스프는 간신히 구문 변형을 만듭니다. C ++에서는 함수를 '전달'하기 위해 클래스를 만들어야합니다. Perl은 어느 정도의 차별화를 만드는 데있어 매우 간단합니다. 파이썬도 마찬가지입니다.

문제 영역에 가장 적합한 방법은 무엇입니까? '임피던스 불일치'를 최소화하면서 머리 속에 생각을 표현할 수있는 가장 좋은 방법은 무엇입니까?

Parsability는 내 마음에 큰 문제입니다. 특히, 오류없이 언어를 구문 분석하고 잘라내는 IDE의 기능을 언급합니다. 재 포맷이 유용합니다. 토큰으로 구분 된 언어는 루비 / c / 파스칼 등 잘 분석되는 경향이 있습니다.

그러나 실제 문제를 해결하기 위해 모든 진지한 언어로 모든 종류의 주요 시스템을 만들었습니다. 구문은 어떤 것을 표현하는 데 장애가되지만, 해결할 수있는 장애입니다. 튜링 동등성과 그 모든 것.

직관적이지 않고 버그를 유발할 때 구문을 더 많이 인식하지만 구문은 중요합니다. 예를 들어, 악명 높은 "세계의 마지막 버그"농담 :

if (AlertCode = RED)
   {LaunchNukes();}

구문은 중요합니다.보다 일반적인 구문을 가진 Lisp 인 Dylan과 Lisp와 유사한 구문을 가진 Haskell 인 Liskell을 지원하는 두 가지 예를들 수 있습니다. 각각의 경우에, 동일한 의미론을 갖지만 근본적으로 다른 구문을 갖는 언어의 변형이 제안되었다.

Dylan의 경우,보다 전통적인 것을 선호하여 s-expression을 삭제하면 더 넓은 범위의 프로그래머를 유치하는 데 도움이 될 것으로 생각되었습니다. 프로그래머가 Lisp를 사용하는 것을 방해하는 것은 구문 만이 아니라는 것이 밝혀졌습니다.

Liskell의 경우 s- 표현식을 사용하면 매크로를 더 쉽게 사용할 수 있다고 생각했습니다. Haskell에서는 매크로가 실제로 필요하지 않기 때문에 실험도 효과가 없었습니다.

구문이 아무에게도 중요하지 않다면 실험도 시도되지 않았을 것입니다.

답은 " 인자 "를 컴퓨터 요소 와 인적 요소 로 분리하는 데있을 수 있습니다 . 구문에는 많은 인적 요소가 있습니다.

• 가독성
• 간결함
• 유지 보수성
• 교육학
• 오류 예방
• 목적에 적합-REPL 언어, 스크립트 언어 또는 대규모 시스템 언어입니까?

컴퓨터와 관련하여 구문의 유일한 문제는 해결해야 할 모호성이 있는지 여부와 컴파일 / 해석시 코드를 토큰 화 / 파싱하는 데 걸리는 시간입니다. 구문 분석의 오버 헤드가 중요한 문제인 경우

그렇기 때문에 두 가지 측면이 있기 때문에 항상이 질문에 대해 "예와 아니오"로 답해야하는 이유가있을 수 있습니다.

구문이 없다면, 인간 수준에서 코드 블록의 의도를 전달할 수있는 공통 "템플릿" 이 없습니다. 구문은 컴파일러를 표준화 할 수 있는 공통 프레임 워크 를 제공합니다 . 메소드를 공유 할 수 있습니다. 유지 보수를 단순화 할 수 있습니다.

나는 무엇을 생각하는 정말 중요한 것은 API 액세스를 필요로 할 때, 그리고 (메모리 제어 및 잠금 등) 낮은 수준의 기능의 가용성. 대부분의 다른 언어에는 이러한 기능이 포함되어 있습니다. 문제는 추가 기능 이 필요할 때 종종 C와 같은 언어를 사용하여 구현해야한다는 것입니다. 그리고 C를 사용중인 언어와 인터페이스하는 것이 번거 롭습니다.

웹 개발 (및 수학)을 제외한 모든 것에서 C / C ++는 여전히 운영 체제 및 응용 프로그램의 언어라는 것을 알았습니다. 진정한 멀티 스레드, 프리 포밍, 크로스 플랫폼 애플리케이션 개발을 위해 대부분의 시간이 지원됩니다. 그리고 C의 구문은 괜찮습니다. 매우 간단하고 비교적 장황합니다. 놀라운 구문은 그다지 중요하지 않습니다. 강력한 성능 및 API 가용성 우리 모두는 다른 사람들의 코드 (C 또는 그 파생어로 작성된 대부분의 시간)와 인터페이스해야합니다.

구문이 중요합니다. 언어 구문이 응용 프로그램에 대해 편리하고 읽기 쉬운 도메인 별 언어를 만들 수있을만큼 융통성이 있다면 대단히 중요합니다. 만약 당신이 이것을 의심한다면, 18 세기 이전에했던 것처럼 라틴어에서 대수 문제를 겪는 것을 상상해보십시오. 물론 미적분학 텍스트는 초보자에게는 읽을 수 없지만 실제로는 미적분법과 라이프니츠 표기법을 사용하여 고전적인 방법으로 수학 페이지가 필요한 일련의 문제를 신속하게 해결할 수 있습니다. 프로그래밍은 또 다른 수학입니다. 문제 영역에 가까운 편리한 표기법은 생산성을 크게 변화시킬 수 있습니다.

다음은 6의 교수진을 계산하는 프로그램입니다.

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

구문은 최소입니다 :

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

구문이 언어를 어렵게 만든다는 일반적인 믿음이있는 것 같습니다. 흔히 믿게 되듯이, 정반대가 맞습니다.

LISP 구문은 위의 구문 보다 훨씬 많은 구문을 가지고 있기 때문에 읽을 수만 있습니다. 따라서 LISP 팬이 "구문이 중요하지 않다"고하면 결과적으로 SKI 미적분을 시도하도록 요청하십시오. 그들은 비트 구문이 그렇게 나쁘지 않다는 것을 인정해야 할 것입니다.

나는 그것이 개인적인 취향을 넘어서는 중요하지 않다고 생각합니다. 모든 것 (성능, 기능 등)이 같으면 왜 언어 구문에 더 큰 비중을 두지 만 c / c ++와 같은 언어의 성능이나 단순히 작업에 더 적합한 다른 언어의 성능을 넘어서기로 선택했는지 알 수 있습니다. 구문은 나쁜 아이디어처럼 보일 것입니다.

예, 구문은 중요하지만 실제로는 가독성 만 있습니다. 비교:

for i in range(10):
   print(i)

(예, 그건 파이썬입니다)

FOR(i<-RNG-<10){PRN<-i}

(예, 방금 만든 언어입니다) 둘 다 똑같은 방식으로 똑같은 일을하지만 구문이 다르며 Python을 읽기 쉽습니다. 그렇습니다. 구문은 확실히 중요합니다. "구문 설탕"조차 중요합니다.

 @property
 def year(self):
     return self._date.year

보다 읽기 쉽다

 def year(self):
     return self._date.year
 year = property(year)

그렇습니다.

큰 불꽃을 내고 싶다면 사람들에게 C와 같은 언어로 첫 번째 버팀대를 두십시오. 내말은

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

심지어 VS

void foo() 
{ // blah
}

그리고 이것은 같은 언어입니다! 또한 공간, 장소 (함수 이름 및 버팀대, 연산자 등)에 대해 물어보십시오.

1000 개의 답변이 보장됩니다!

구문이 중요합니다. 그러나이 시대에 나는 가독성 때문에 거의 전적으로 중요하며 실제로 필요한 키 스트로크의 양은 아닙니다. 왜?

• 실제로 간단한 것을 쓰지 않는 한, 누르는 키의 수가 프로그램을 작성하는 데있어 제한적인 요소라면 실제로 타이핑 할 때 허약하거나 너무 빨리 생각하는 것입니다.
• 요즘 모든 괜찮은 IDE에는 많은 단축키가 있기 때문에 실제로 사용하는 모든 문자를 실제로 입력 할 필요가 없습니다.

즉, 너무 장황하면 가독성에 영향을 미치는 지점에 도달 할 수 있습니다. 나는 다음과 같은 것을 선호한다 :

foreach (문자열 목록의 문자열)

에:

stringlist 변수가 참조하는 목록에있는 모든 문자열에 대해

...모든 일!

구문은 그것을 배우는 사람들에게 중요하며, 진입 장벽이 낮을수록 언어가 처음에 더 대중적 일 수 있습니다. 그러나 언어가 자신을 풍부하고 간결하게 표현하기가 어렵거나 불가능한 경우 인기가 떨어지기 시작합니다.

매우 간결하고 불투명 한 (Perl)은 지나치게 장황하고 말끔한 것 (AppleScript)만큼 나쁩니다.

균형, 진입 장벽 감소, 높은 생산성 및 쉬운 유지 보수가 필요합니다.

고려해야 할 또 다른 사항은 구문이 더 좋은 프로그래밍 언어를 구문 분석하기가 더 쉬워 컴파일러가 작성하기 쉽고 빠르며 버그가 덜 발생한다는 것입니다.

간단히 말해 구문은 중요하지 않습니다. 그것을 통해 표현할 수있는 의미론은 중요합니다.