우리는 맞춤형 스크립팅 언어를 작성하려고합니다. 대소 문자를 구분하지 않는 키워드 를 제공하여 언어를 용서할 것을 제안했습니다 .
개인적으로 아이디어가 마음에 들지 않지만 팀에는 아이디어를 기대하는 사람이 거의 없어 최종 사용자를 행복하게 할 것입니다. FORTRAN, BASIC, SQL과 같은 언어의 예는 대소 문자를 구분하지 않음을 나타냅니다.
이것이 좋은 생각입니까?
답변
최종 사용자가 누구인지 자문하십시오. C 또는 Javscript에서 프로그래밍 경험이 있거나 Unix에서 IT 경험이있는 사람이 작성해야한다면 대소 문자 구분이 올바른 방법 일 것입니다. 이것이 사용자가 기대하는 것이기 때문입니다. 그러나 대부분의 최종 사용자, 심지어 고급 사용자에게는 혼동을 줄 수 있습니다.
VB / VBA / VBScript는 대소 문자를 구분하지 않으므로 프로그래머가 아닌 사용자도 쉽게 언어를 익힐 수 있습니다. 정확하게 스크립트는 아니지만 많은 사용자가 접근하는 Excel 수식은 대소 문자를 구분하지 않습니다. 대부분의 글에서 대소 문자를 선택하면 텍스트가 다소 전문적이고 세련되게 보일 수 있지만 자체적으로 의미가 변경되지는 않습니다. 단어 의미를 . 그렇기 때문에 개발자가 아닌 개발자는 대소 문자를 구분하는 스크립팅 언어에 혼동 될 것이라고 생각합니다.
다시 말하지만, 이것은 기술적 선택이 아닙니다. 대상 고객을 잘 아는 사람들이 선택해야하는 제품 관리 선택입니다.
답변
구현하기가 쉽지 않은지가 아니라 제시하려는 사용자 경험에 따라 결정해야합니다.
사용자가 대소 문자를 구분하지 않는 것이 더 쉬워지면 구현해야합니다.
포인트 SQL의 경우 대소 문자를 구분하지 않습니다. 대화 형 설정에서 사용하기가 매우 쉽습니다.
이 볼 수있는 또 다른 방법은 이제까지의 차이가 될 것입니다 keyword및 Keyword해당 언어로,이 차이는 사용자에게 의미가있을 것인가? 스크립팅 언어의 경우 대답은 “아니오”라고 말합니다.
답변
프로그래밍 언어는 대소 문자를 구분해야합니다. 사람들은 이것에 매우 쉽게 적응할 수 있습니다. 그들은 대부분 소문자로 작업하고 기존 API에서 대소 문자 또는 모든 대문자 식별자를 조심해야한다는 것을 기억해야합니다.
언어를 대소 문자를 구분하지 않는 것이 분명해 보였습니다. 모든 컴퓨팅 시스템 및 해당 I / O 장치 (키보드, 프린터 및 디스플레이 장치)에서 소문자를 사용할 수 없었기 때문입니다. 프로그래밍 언어 구현은 대문자로 작성된 프로그램 만 허용해야했습니다. 왜냐하면 프로그램 만 표시하거나 인쇄 할 수 있기 때문입니다. 대소 문자를 구분해야하므로 대문자 와 대소 문자를 구분해야 소문자를 거부 할 수 있습니다. 소문자는 프로그래머가 원하는 것이었지만 항상 가질 수는 없었습니다. 대문자로 소리 친 프로그램으로 작업하기를 원하는 사람은 아무도 없었습니다. 하드웨어 제한 일뿐입니다.
한동안 터미널에서 케이스를 접는 것도 일반적이었습니다. 터미널이 대문자 만 표시 할 수 있지만 대문자와 소문자를 지원하는 컴퓨팅 시스템에 로그인해야하는 경우 터미널은 소문자를 대문자로 접습니다. 이것이 너무 오래되었다고 생각하십니까? “Apple II와 마찬가지로 Apple II Plus에는 소문자 기능이 없었습니다.” (http://en.wikipedia.org/wiki/Apple_II_Plus) 초기 Apple 컴퓨터 사용자가 대소 문자가 혼합 된 BBS에 전화를 걸 때 터미널 에뮬레이터 (또는 호스트)는 모두 대문자로 접어야했습니다. 모든 대문자로 작성된 메시지는 당시 게시판에서 일반적이었습니다. 이 기능은 여전히 Linux 커널과 같은 Unix와 유사한 운영 체제에서 찾을 수 있습니다. 예를 들어stty olcuc 쉘 프롬프트에서를 .Unix tty 라인 규칙은 출력시 소문자를 대문자로 매핑 할 수 있으며 입력시 대문자를 소문자로 매핑 할 수 있습니다. 이를 통해 소문자가없는 터미널에서 소문자 프로그래밍 언어로 작업 할 수 있습니다.
대소 문자 무감각은 현대화 된 국제 컴퓨팅 환경에서 잘 작동하지 않는 과거의 컴퓨터 시대의 구식 개념입니다. 다른 언어로 확장 하시겠습니까? 프랑스어는 어떻습니까 : È와 è는 동등하다고 생각하십니까? 아니면 일본인? 히라가나와 가타카나를 단지 사례로 간주하여 후일과 후 이루는 동일한 식별자입니까? 이러한 어리 석음에 대한 지원은 어휘 분석기를 크게 복잡하게하는데, 이는 전체 유니 코드 공간에 대해 대등 한 맵을 가져야합니다.
수학은 대소 문자를 구분합니다. 예를 들어, 대문자 시그마는 합산을 나타내는 반면, 소문자 시그마는 표준 편차와 같은 다른 것을 나타냅니다. 이것은 어려움없이 동일한 공식으로 발생할 수 있습니다. (프로그래밍 언어가 Σ와 σ를 동등하게합니까?)
영어 철자법은 민감합니다. 예를 들어, 많은 고유 명사는 일반 명사 또는 다른 어음 부분에 해당합니다. “may”는 동사이지만 “May”는 한 달 또는 여자의 이름입니다. 또한 약어 나 약어가 소문자로 쓰여 있으면 혼동 될 수 있습니다. SAT는 학력 적성 시험을 의미하는 반면 “sat”는 “sit”의 과거 분사입니다. 똑똑한 사람들은 세부 사항에주의를 기울이고 적절히 활용하십시오.
기본적으로 대소 문자를 구분하지 않는 1985 년 이래로 작성된 새로운 프로그래밍 언어는 두 번째로 이메일과 게시를하지 않는 사람들을위한 것입니다.
언어가 코드 생성 대상으로 사용되어 다른 언어로 코드를 번역하고 다른 언어가 대소 문자를 구분하는 경우 어떻게됩니까? 구별을 포착하려면 모든 이름을 어떻게 든 변환해야합니다. (이것은 기술적 인 결정이 아니며, 대상 청중의 정서적 취향 만 중요하다는 것은 우스운 일입니다.)
다른 운영 체제에서 파일을 가져올 때 Windows에서 사례 처리로 인한 성가신 문제를 살펴보십시오. 그것은 기술적 인 문제입니다. 대소 문자 구분 파일 시스템은 대소 문자를 구분하지 않는 외부 데이터에 문제가 있습니다.
일반적인 Lisp은 이상적인 접근 방식에 도달했습니다. 심볼 이름은 대소 문자를 구분하지만 토큰을 읽을 때 대문자로 접 힙니다. 이 즉, 토큰 foo, fOO, FOO및 Foo모든 나타낸다 같은 기호 : 이름 문자열로 저장되어있는 기호 "FOO". 또한이 동작은 기본 읽기 테이블 구성 일뿐입니다. 독자는 글자를 대문자, 소문자로 접거나 대소 문자를 뒤집거나 보존 할 수 있습니다. 마지막 두 가지 선택은 대소 문자를 구분하는 방언을 생성합니다. 이런 방식으로 사용자는 최대한의 유연성을 갖습니다.
답변
실제 결정 요인은 이름이 같은 여러 항목을 얼마나 자주 갖고 싶어하는지입니다. 대소 문자 구분은 SQL에서 열 이름을 원하지 않기 때문에 SQL에서 작동합니다 SELECT. 다른 모든 줄은 Object object = new Object()클래스, 인스턴스 및 생성자를 참조하는 동일한 이름을 원 하기 때문에 Java에서 성가시다 .
즉, 대 / 소문자 구분은 이름을 오버로드하는 데 주로 유용하며 오버로드는 대부분 크고 복잡한 프로젝트에서 유용합니다. 스크립팅 언어와 같이 자주 사용하지 않는 경우 대소 문자를 구분하지 않으면 프로그래밍이 훨씬 간단 해집니다.
식별자가 대소 문자를 구분하지 않고 공백을 구분하지 않는 규칙 언어를 한 번 만들었습니다. 또한 동일한 식별자를 참조하는 별칭을 만들 수있었습니다. 예를 들어 ProgrammersStackExchange, 프로그래머 스택 교환 및 PSE는 모두 정확히 동일한 기호로 확인되어 상호 교환 적으로 사용될 수 있습니다.
도메인이 똑같은 것을 참조하는 매우 잘 알려진 방법이 많았 기 때문에 도메인이 매우 잘 작동했기 때문에 이름 충돌이 거의 없었습니다. 한 이름을 사용하여 쿼리를 입력하고 다른 이름을 사용하여 결과를 얻음으로써 아무도 놀라지 않을 것입니다. 언어 지원을 통해 도메인과 프로그래밍 언어 간 번역이 매우 쉬워졌습니다. 그러나 변수에 대한 모든 참조를 찾는 것과 같이 특정 작업을 더 어렵게 만들었습니다. 고맙게도 제 경우에는 이러한 상황이 거의 발생하지 않았거나 도움을주기 위해 도구를 쉽게 구축 할 수 있었지만 자신의 상황을 고려해야합니다.
답변
스크립트 언어는 대소 문자를 구분한다고 가정합니다. 변수 이름이나 키워드에 잘못된 대소 문자를 사용하여 오타를 작성했는지 알려주는 컴파일러 또는 구문 검사기를 작성 하시겠습니까? 그렇지 않다면 언어를 대소 문자를 구분하지 않는 강력한 논거가 될 것입니다.
답변
변수를 즉석에서 선언 할 수 있습니까? 그렇다면 대소 문자를 구분하여 논쟁 할 것입니다.
ATypo = 42;
반대로
Atypo = 42;
불필요하게 디버깅 시간을 요구하고 있습니다.
답변
FORTRAN, BASIC, SQL과 같은 언어의 예는 대소 문자를 구분하지 않음을 나타냅니다.
FORTRAN 및 SQL (및 COBOL)이 대소 문자를 구분하지 않는 이유는 원래 문자 세트가 대문자 만있는 머신에서 사용하도록 원래 설계 되었기 때문입니다. 해당 언어에서의 대소 문자 구분 (적어도)은 언어 디자인 선택보다 역사적인 유물입니다.
이제는 더 관대하게 대소 문자를 구분할 수 있다고 주장 할 수 있지만, 반대편에서는 대소 문자 구분으로 인해 대소 문자를 구분하기 때문에 대소 문자 구분이 더 읽기 쉬운 코드가된다는 것입니다.