유닉스 / C의 불일치와 불완전 성의 예는 무엇입니까?

리차드 가브리엘 (Richard Gabriel)의 유명한 에세이 The Rise of Worse는 더 낫다 . 그는 Unix가 인터페이스의 단순성보다 구현의 단순성을 우선시한다고 주장하기 위해 "PC 실패자 문제"( Josh Haberman의 다른 곳에서 논의) 의 예를 제시합니다 .

내가 생각해 낸 또 다른 예는 숫자에 대한 다른 접근법입니다. Lisp는 임의로 많은 수 (메모리 크기까지)를 나타낼 수있는 반면 C는 숫자를 고정 된 비트 수 (일반적으로 32-64)로 제한합니다. 이것이 정확성 축을 보여줍니다.

일관성과 완전성에 대한 몇 가지 예는 무엇입니까? 다음은 가브리엘의 모든 설명입니다 (그가 풍자 만화라고 인정합니다).

MIT / 스탠포드 접근

• 단순성-구현과 인터페이스 모두에서 디자인이 단순해야합니다. 인터페이스가 구현보다 단순해야합니다.
• 정확성-모든 관찰 가능한 측면에서 디자인이 정확해야합니다. 부정확성은 단순히 허용되지 않습니다.
• 일관성-디자인이 일치하지 않아야합니다. 불일치를 피하기 위해 디자인이 약간 덜 단순하고 덜 완성 될 수 있습니다. 일관성은 정확성만큼 중요합니다.
• 완전성-디자인은 실용적 많은 중요한 상황을 포함해야합니다. 합리적으로 예상되는 모든 사례를 다루어야합니다. 단순성은 완전성을 지나치게 줄일 수 없습니다.

뉴저지 접근

• 단순성-구현과 인터페이스 모두에서 디자인이 단순해야합니다. 인터페이스보다 구현이 간단해야합니다. 단순성은 디자인에서 가장 중요한 고려 사항입니다.
• 정확성-모든 관찰 가능한 측면에서 디자인이 정확해야합니다. 올바른 것보다 단순 해지는 것이 약간 좋습니다.
• 일관성-디자인이 너무 일관성이 없어야합니다. 경우에 따라 일관성을 위해 일관성을 희생 할 수 있지만 구현 복잡성이나 불일치를 도입하는 것보다 덜 일반적인 상황을 처리하는 디자인 부분을 삭제하는 것이 좋습니다.
• 완전성-디자인은 실용적 많은 중요한 상황을 포함해야합니다. 합리적으로 예상되는 모든 사례를 다루어야합니다. 다른 품질을 위해 완전성을 희생 할 수 있습니다. 실제로 구현의 단순성이 위태로워 질 때마다 완전성을 희생해야합니다. 단순성이 유지되는 경우 완전성을 달성하기 위해 일관성을 희생 할 수 있습니다. 인터페이스의 일관성은 특히 가치가 없습니다.

가브리엘이 옳은지 (스택 교환에는 적합하지 않은 질문인지) 묻는 것이 아니라 그가 언급 한 것에 대한 예를 들어 보자.

질문의 제목은 일부 기본 사용자 인터페이스 불일치가 귀하에게 관심이있을 수 있음을 나타냅니다.

유닉스 명령어는 옵션과 플래그를 지정하는 특정 구문을 따르지 않습니다. : 플래그로 '-'예를 들어, 대부분의 명령은 앞에 하나의 문자를 사용 cat -n some_file하지만, 예외 같은 tar tf some_file.tar과 dd in=some_file out=some_other_file count=2일반적으로 사용되는 명령에 존재합니다.

유닉스와 그 자손과 친척은 약간 다른 정규 표현식 구문을 가지고 있습니다. 쉘은 다른 프로그램 (grep, egrep, vi)이 '. *'를 사용하는 경우 "*"를 사용합니다. egrep은 '+'와 '|' 연산자로서 grep은 그렇지 않습니다.

기본 "모든 것이 파일입니다"시스템 호출 인터페이스가 불완전한 것으로 간주 될 수 있습니다. 읽기 / 쓰기 / 검색 / 닫기가 모든 I / O 장치에 맞지는 않습니다. "ioctl"호출에는 엄청나게 필요한 예외가 발생하지만 사운드 카드와 같은 장치는 그다지 적합하지 않습니다.

일관성

Lisp는 매우 일관된 구문을 가지며 모든 언어 확장은 매크로 등을 통해 자연스럽게 임베드 될 수 있습니다. 반면에 C는 다소 코드 구문을 가지고있어 어떤 "단축키"를 취할 수 있으므로 어떤 경우에는 C 코드가 더 단순 해 보입니다.

완전성

Lisp에서 필요한 특정 언어 기능이없는 경우 매크로를 사용하여 직접 구현할 수 있습니다. C에도 전처리 기가 있지만 다소 복잡합니다.

C의 문자열은 문자 0을 포함 할 수 없으며 라이브러리 함수는 이진 데이터를 처리하기에 적합하지 않습니다.

Unix 시스템의 파일 이름은 문자 0 또는 문자 47 (슬래시)을 포함 할 수 없습니다.

원래 Unix 구현에서 파일 이름은 14 자로 제한되었습니다. 이후 버전에서는이 제한이 완화되었습니다. 그들은 그것을 제거하지 않았다.

추가 : 인수가 너무 많거나 메모리가 너무 많은 인수 목록 또는 너무 큰 환경을 인수 목록 E2BIG으로 exec사용 하려고 할 때 시스템 오류 조건 .

유닉스는 이런 종류의 자의적인 제한으로 악명이 높다. 1987 년 Perl이 출현하기 전까지는 큰 데이터 세트 나 긴 레코드가있는 데이터 세트 또는 이진 데이터를 처리하는 것이 매우 신뢰할 수 없었습니다.

IIRC 선생님은 C char *에서 switch문장에 변수 를 사용할 수 없다는 것이 불일치의 문제라고 말했지만 일반화 (완전성) 문제였습니다. 나는 그냥 "일관성"을 사용하는 것이 낫다 생각 하여 프로그래밍 언어 규칙의 도메인을 정의 고체 기준을 가지고 있기 때문에,하지 (적어도하지 C. 어쩌면 버그 언어가 일관성 문제를 가지고 같은 언어) 언어 자체를 프로그램에서 알고리즘 또는 소프트웨어 설계를 규칙에 입력을 적용하여 작동합니다. 따라서 언어 로 허용되지 않는 언어는 허용되지 않고 IMHO 언어와 일치하지 않을 계획 입니다.

1. 나는 완전성을 완전성으로 사용했습니다. 나는 그들이 같은 것 같아요. 어쩌면 내가 틀렸을 수도 있습니다.
2. 이것은 대답이 아닙니다. 어쩌면 제안이나 내 의견.

내가 가지고있는 가장 좋은 예는 파일 이름이 .. -r입력 된 가난한 사용자입니다 rm *.

이 이야기가 사실 이건 아니건, 그것은 유닉스 증오의 고전이되었습니다.

이러한 많은 예는 Dennis Ritchie 자신이 소개 한 Unix-Haters 핸드북을 참조하십시오 .

또한 이러한 유형의 문제를 피하는 것이 Microsoft의 Power Shell 설계에 큰 영향을 미쳤다고 덧붙입니다.

• 명령에 대한 동일한 (짧은) 플래그의 무수한 의미는 불일치입니다.
• 정규식을 사용하는 각 프로그램에는 고유 한 구문이 있습니다.
• 서비스의 구성 파일은 모두 다른 구문입니다 (일부 용서할 수 있음, 메일러 데몬은 웹 서버 또는 시스템 시작과 거의 관련이 없지만 여전히)
• 다른 편집자가 있습니다! 사용자는 다른 껍질을 사용합니다 !! 데스크탑 환경이 왜 그렇게 많은가요?!?

쉘이 프로그램이 아닌 구형을 확장한다는 사실 인 OTOH는 다른 시스템에 존재하는 많은 자극 불일치를 제거합니다. 동일한 명령을 사용하여 파일 시스템의 한 곳에서 다른 곳으로, 디스켓으로 또는 Zip 디스크에서 테이프로 파일을 복사 할 수 있다는 사실을 이해하십시오.

따라서 유닉스는 일관성이 없습니다. 다른 시스템도 마찬가지입니다. ;-)

무한 정수를 지원하는 LISP 대 기계 정수만 지원하는 C는 언어 '정확성'의 예가 아닙니다. 언어의 디자인 목표가 매우 다르다는 점에서 발생하는 간단한 문제입니다.

C의 요점은 운영 체제를 구현하는 데 사용할 수있는 컴퓨터와 가까운 언어였습니다. 기계 (대부분)는 무한 정밀도 10 진수를 지원하지 않습니다. 기계는 (주로) 고정 비트 길이의 정수를 갖습니다.