프로그래밍 언어가 엄격하거나 느슨해야합니까? [닫은]

Python과 JavaScript에서 세미콜론은 선택 사항입니다.

PHP에서 배열 키 주위의 따옴표는 선택 사항 ( $_GET[key]vs $_GET['key'])이지만 생략하면 먼저 해당 이름으로 상수를 찾습니다. 또한 블록에 대해 두 가지 스타일 (콜론 또는 중괄호 구분)을 사용할 수 있습니다.

나는 지금 프로그래밍 언어를 만들고 있는데, 얼마나 엄격하게 만들어야하는지 결정하려고한다. 추가 문자가 실제로 필요하지 않고 우선 순위로 인해 명확하게 해석 될 수있는 경우가 많이 있지만 일관성을 장려하기 위해 여전히 문자를 적용 해야하는지 궁금합니다.

어떻게 생각해?

좋아, 내 언어는 멋진 템플릿 언어만큼 프로그래밍 언어가 아닙니다. Haml 과 Django 템플릿 사이의 십자가 종류 . 내 C # 웹 프레임 워크와 함께 사용되며 확장 성이 뛰어납니다.

언어 유형에 따라 사용 방법이 다르므로이 질문에 대한 답변은 실제로 사용하려는 언어에 따라 다릅니다.

예를 들어 Perl은 매우 느슨한 언어이므로 빠른 수정 또는 숫자 크 런칭 스크립트를 작성하는 데 매우 유용합니다. 견고하고 견고한 프로젝트에는 C #을 사용합니다.

대상 사용량에 맞게 균형을 맞출 필요가 있습니다. 엄격할수록 코드 작성에 시간이 오래 걸리지 만 견고성, 재사용 성 및 유지 관리가 쉬워집니다.

스크립팅 언어와 달리 프로그래밍 언어에서 내가 찾는 것은 일관성 과 강력한 타이핑입니다.

현재 프로그래밍 언어에서는 모호하지 않게 특정 위치에서 세미콜론을 생략 할 수 있습니다 ( {}블록 의 마지막 표현 은 하나임). 이 경우 프로그래밍 언어를 사용하여 문자를 생략 할 수있게되면 이제 프로그래머에게 추가적인 문제가 있습니다. 그녀는 이제 일반 언어 구문 위에 어떤 경우에 구문의 일부를 생략 할 수 있는지 알아야합니다.

이 추가 지식은 프로그래머가 코드를 작성하는 데 아무런 문제가되지 않지만 나중에 기존 코드를 해석해야하는 사람 (한참 후에 원래 작성자 포함)에게는 부담이됩니다.

PHP 예제는 상수 key가 동일한 컨텍스트에 추가 될 때 프로그램에서 미묘한 버그가 발생할 가능성을 엽니 다 . 컴파일러는 이것이 의미하는 바가 아님을 알 방법이 없으므로 컴파일 타임 대신 런타임시 문제가 분명해집니다.

모호성이있는 모든 곳에서 컴파일러는 프로그래머가 실제로 무엇을 의미하는지 추측 할 수있는 방법이 필요합니다. 이런 일이 생길 때마다 프로그래머가 실제로 다른 것을 의미했지만 모호한 해결 규칙은 없었습니다.

논리적으로 올바른 코드를 작성하는 것은 이미 어렵습니다. 구문 상 모호성을 추가하면 표면에 "친숙한"것처럼 보일 수 있지만, 코드베이스에 새롭고 예상치 못한 디버그하기 어려운 버그를 도입하라는 공개 초대입니다. 결론은 가능한 한 엄격해야합니다.

귀하의 예에서, 세미콜론은 Python 및 JavaScript에서 선택적이라고 언급했습니다. Javascript의 경우 적어도 이것은 사실이 아닙니다. 세미콜론은 다른 C 패밀리 언어와 마찬가지로 JS에서도 필요합니다. 그러나 특정 상황에서 누락 된 세미콜론을 삽입하려면 언어 사양에 JavaScript 파서가 필요합니다. 이것은 의도가 잘못되어 코드를 망치는 경향이 있기 때문에 매우 나쁜 것으로 널리 간주됩니다 .

언어를 얼마나 느슨하게해야하는지에 대한 대답은 텍사스 액센트 "얼마나 운이 좋습니까?"라는 질문에 대한 대답과 같습니다.

언어에 큰 변화가 없다면 모든 사람이 코딩 일관성을 위해 열심히 노력할 필요는 없습니다. 사용자가 불필요하게 복잡성을 증가시키는 요청을 할 때 마음에 들지 않으므로 왜 개발 언어에 요청해야합니까?

개인적으로 선호하는 것은 오타를 잡을 수있을만큼 충분히 엄격하지만 가능한 한 여분의 상용구를 사용하지 않는 것입니다. 이 문제에 대해 http://www.perlmonks.org/?node_id=755790 에서 이야기 합니다.

즉, 당신은 자신을 위해 언어를 디자인하고 있습니다. 원하는대로 만들어야합니다.

나는 내 언어가 내 뜻대로하는 것을 좋아합니다. 일반적으로 그것은 느슨해지기 위해 꽤 기울어집니다. 또한 제한된 영역을 디버그 / 분석 할 수 있도록 요소 또는 블록에 "strict"태그를 지정할 수 있기를 원합니다.

나는 일반적으로 "프로그래머로서 나를 더 편하게 해줄 것"이라는 측면에 빠지는 경향이있다. 물론 그것은 하나 이상의 것을 의미 할 수 있습니다. Javascript에는 거의 유형 검사가 없으므로 이상한 버그가 발생할 때까지 훌륭하게 작동합니다. 반면에 Haskell에는 많은 유형 검사가있어 더 많은 작업을 선행하지만 일부 클래스의 버그를 클로버합니다.

솔직히 말해서 나는 그들이하는 일을보기 위해 많은 언어를 조사하고 그들 중 아무도 틈새 시장을 찾지 않으려 고 노력했습니다!

나는 그것을 할 수있는 확실한 방법이 하나 이상 있다고 생각하지 않습니다. 적어도 사람들이 아직 합의를 찾은 것이 없다면. 다른 유형의 시스템으로 언어를 만들어서 배우고 있습니다.

행운을 빕니다.

좋은 프로그래밍 언어는 엄격한 규칙을 가져야하며 구현시 일관성있게 시행해야하지만 규칙은 도움이되도록 작성해야합니다. 또한 실제로 다른 두 프로그램 사이의 "Hamming distance"가 하나 인 경우를 피하기 위해 언어 설계를 고려해야합니다. 분명히 숫자 또는 문자열 리터럴을 사용하여 그러한 일을 달성 할 수는 없습니다 (123 대신 12123 또는 13 유형을 의미하는 프로그래머라면 컴파일러는 프로그램의 의미를 잘 알지 못합니다). 반면에, 언어가 :=할당과 ==평등 비교를 위해 사용되고 단일 언어를 사용 하지 않는 경우= 법적인 목적을 위해, 우연한 과제 할당과 우연한 과제 비 할당 비교 가능성을 크게 줄입니다.

컴파일러가 사물을 유추하는 것이 유용한 곳이 있지만 그러한 추론은 종종 가장 간단한 경우에는 가장 가치가 있고 더 복잡한 경우에는 덜 가치가 있다고 제안합니다. 예를 들어 다음을 대체 할 수 있습니다.

  사전 <complicatedType1, complicatedType2> 항목 =
    새로운 사전 <complicatedType1, complexType2 ()>;

와

  var item = new Dictionary <복잡한 유형 1, complexType2 ()>;

복잡한 유형 유추가 필요하지 않지만 코드를 훨씬 더 읽기 쉽게 만듭니다 (예를 들어, 저장 위치의 유형이 식의 유형과 정확하게 일치하지 않기 때문에 필요한 시나리오에서만 더 자세한 구문을 사용함) 그것을 만들면 필요할 수있는 장소에 특별한주의를 기울이는 데 도움이됩니다).

좀 더 복잡한 유형의 추론을 시도하는 데 가장 큰 어려움은 모호한 상황이 발생할 수 있다는 것입니다. 좋은 언어는 프로그래머가 컴파일러에 정보를 포함시켜 이러한 모호성을 해결하는 데 사용할 수 있도록 (예를 들어, 다른 타입보다 선호하는 타입 캐스트를 고려하여) 허용해야한다고 제안합니다. 과부하는 다른 코드를 실행할 수 있으며, 프로그래머는 사용할 수있는 경우에는 동일하게 동작하거나 위의 방법으로 처리 할 수없는 경우에만 플래그를 지정해야합니다.

나에게는 가독성이 가장 중요하다.

언어에 익숙한 사람에게는 컨텍스트를 깊이 분석하지 않고도 코드 조각의 의미가 명확해야합니다.

언어는 가능한 자주 실수를 표시 할 수 있어야합니다. 임의의 임의의 문자 시퀀스가 ​​구문 적으로 올바른 프로그램을 만들면 도움이되지 않습니다. 그리고 변수를 처음 사용할 때 변수가 자동으로 생성되면 철자가 틀리 client므로 cleint컴파일 오류가 발생하지 않습니다.

구문 외에도 언어에는 명확하게 정의 된 의미가 있어야하며 적절한 구문을 결정하는 것보다 어려울 수 있습니다 ...

좋은 예 :

• Java에서 "1"문자열 1은 int이며 1.0두 배이며 1L길다. 한 번보고 당신은 그것이 무엇인지 알고 있습니다.

• Java에서는 =과제입니다. 기본 유형의 값과 참조 유형의 참조를 지정합니다. 복잡한 데이터를 복사하거나 비교하지 않습니다.

• Java에서 메소드를 호출하면 괄호가 필요 하며이 방법은 변수와 명확하게 구별됩니다. 따라서 괄호가 없으면 메소드 정의를 검색 할 필요가 없으며 단지 데이터를 읽는 것입니다.

나쁜 예 :

• Java에서와 같은 기호 client는 패키지 경로 요소, 클래스 또는 인터페이스 이름, 내부 클래스 이름, 필드 이름, 메소드 이름, 로컬 변수 등 거의 모든 것이 될 수 있습니다. 명명 규칙을 도입하거나 준수하는 것은 사용자의 책임입니다.

• Java에서는 점이 .과도하게 사용되었습니다. 패키지 이름 내의 구분 기호, 패키지와 클래스 간 구분 기호, 외부 클래스와 내부 클래스 사이의 구분 기호, 인스턴스 식과 인스턴스에서 호출되는 메서드 간의 커넥터 등이 될 수 있습니다.

• 많은 언어에서 if블록의 중괄호 는 선택 사항이므로 누군가가 (실제로는 존재하지 않는) 블록에 하나 이상의 문을 추가하면 불쾌한 실수가 발생할 수 있습니다.

• 연산자를 삽입하십시오 : 때로는 숫자 표현에서 멈추고 그것이 의미하는 것을 단계별로 열심히 생각해야합니다. 우리는 모두 수학 표현식을와 같은 접두사 표기법으로 쓰는 데 사용됩니다 a * b / c * d + e. 대부분 우리는 덧셈과 뺄셈에 대한 곱셈과 나눗셈의 우선 순위를 기억합니다 (그러나 우리는로 나누지 않고 c*d, 나누기 c만하고 d? 로 곱한다는 것을 알고 계셨습니까?). 그러나 고유 한 우선 순위 규칙을 가진 추가 연산자가 너무 많아 일부 언어에는 과부하가 발생하여 추적하기가 어렵습니다. 괄호를 사용하는 것이 더 나은 접근 방법 일 수 있습니다 ...

자연어와 유추 할 수도 있습니다. 이메일로 Grammar Nazi입니까? 또는 분할 부정사, 누락 된 연결 또는 잘못 배치 된 수정 자와 같은 문법 오류로 문제가 없습니까? 그 대답은 개인적인 취향으로 요약됩니다.