왜 많은 언어가 대소문자를 구분합니까?

Question

왜 많은 언어가 대소문자를 구분합니까?

그것은 단순한 문제의 상속?C++은 대소문자를 구분하기 때문에 C,Java 은 대소문자를 구분하기 때문에 C++,etc.?또 거기에 더 많은 실용적인 뒤에 이유?

Answer 1

유닉스.

UNIX는 사례에 민감했으며 UNIX에서 사용하기 위해 개발 된 많은 프로그래밍 언어는 사례 민감성이었습니다.

컴퓨터는 용서하지 않습니다. 대문자는 소문자와 같은 것이 아니며 완전히 다릅니다. 그리고주기를 처리 할 때 RAM 등이 비싸지 않았을 때 컴파일러와 컴퓨터를 강제하기위한 노력의 가치가있는 것으로 보이지 않았다.

사건의 무감각성이 어떻게 같은 일이 될 때까지 실제로 유용한 것이되지 않았는지 주목하십시오. 시각적 기본 일단 기업이 대중을 프로그램하는 데 도움이된다는 개념에 투자하기 시작한 후에는 결론에 좋은 일이었다 (즉, Microsoft는 Windows에 더 많은 프로그램이 있다면 더 많은 돈을 벌고있다). .

Answer 2

나는 당신이 당신이 "그 언어의 저자 (들)가 그것이 그렇게 낫다고 생각했기 때문에 더 나은 대답을 얻을 것이라고 생각하지 않습니다. 개인적으로, 나는 그들이 옳다고 생각합니다. 나는 같은 소스 파일의 어느 곳 에서나이 줄을 찾는 것을 싫어합니다 (동일한 개체+메소드를 참조하십시오) ...

SomeObject.SomeMethod();
...
SOMEOBJECT.SOMEMETHOD();
...
someObject.someMethod();
...
sOmEoBjEcT.sOmEmEtHoD();

나는 아무도 이것을보고 기뻐할 것이라고 생각하지 않는다 ...

Answer 3

고려해야 할 흥미로운 점은 영어도 대소 문자를 사용한다는 것입니다. (나는 이것이 대부분의 자연 언어에서 사실이라고 생각하지만, 그것은 모든 사람에게는 사실이 아닐 수도 있습니다.)

다음 사이에 큰 차이 (어쨌든 내가 살고있는 곳)가 있습니다.

독서를 좋아합니다.

그리고

독서를 좋아합니다.

마찬가지로, 많은 사람들 하다 잘못 대문자를 자본화하면 일반적으로 의미하는 바를 이해할 수 있습니다. 그러한 글쓰기가 고려되는 것은 아닙니다. 옳은. 나는 이런 종류의 일에 관해서는 고집입니다. 물론 모든 것을 스스로 얻는다는 말은 아닙니다. 나는 그것이 언어 사례 민감도를 프로그래밍하는 상속의 일부인지는 모르겠지만, 그럴 수 있다고 생각합니다.

프로그래밍 언어에 대한 사례 민감도의 뚜렷한 장점 중 하나는 텍스트가 문화적으로 무감각합니다. 소스 파일에 사용되는 텍스트 인코딩이 어떤 텍스트 인코딩이 사용되는지에 대해 때때로 철자를 쓰는 것은 충분히 나쁘다. 문화 그것은 더 나빠질 것입니다 :(

Answer 4

실제로 개발자와 언어 구문 사양 모두에 대해 매우 실용적입니다. 하위/대문자 구별은 식별자 명명에 많은 표현력을 더합니다.

언어 구문의 관점에서 볼 때 특정 식별자가 하위 또는 대문자 (예 : Java 클래스 이름)로 시작하도록 강요 할 수 있습니다. 따라서 구문 분석이 더 쉬워 지므로 구문을 깨끗하게 유지하는 데 도움이됩니다.

개발자의 관점에서 볼 때, 이는 수많은 편리한 코딩 규칙을 가능하게하여 코드를 더 명확하고 이해하기 쉽게 만듭니다.

Answer 5

제 생각에는 케이스 민감도가 이름 공간을 확대 할 것입니다. 다음과 같은 멋진 트릭

MyClass myClass;

사례에 민감한 컴파일러는 불가능합니다.

Answer 6

케이스 폴딩은 영어로만 간단합니다 (및 모든 문자 <128). 독일인 SZ 또는 "Sharp S"(ß) ISO 8859-1 Charset에는 대문자 변형이 없습니다. 그것은 약 1 후에 유니 코드에서만 받았다 10 년의 토론 (이제 모든 글꼴을 업데이트해야합니다 ...). Kanji와 Hiragana (일본 알파벳)는 소문자조차 모릅니다.

이 혼란을 피하기 위해,이 시대의 유니 코드에서도 케이스 폴딩을 허용하는 것은 현명하지 않습니다. 그리고 유니 코드 식별자.

Answer 7

구문 분석과 컴파일이 정말 비싸고 밤새도록 소모 할 때 케이스에 대해 걱정할 필요가 없다면 컴파일러에게 유리했습니다.

일단 식별자가 사례를 통해서만 독특한 존재로 들어 왔을 때 돌아가는 것은 매우 어려워졌습니다. 많은 개발자들이 그것을 좋아했고 그것을 취소하려는 큰 욕구가없는 것 같습니다.

Answer 8

ExpertSexChange

나는 이것이 답변을 읽기 위해 지불 해야하는 곳에서 오버플로를 쌓는 경쟁자라고 생각합니다. 흠 ... 사례 무감각으로 사이트 이름의 의미는 모호합니다.

이것은 언어가 사례에 민감한 좋은 이유입니다. 덜 모호한! 프로그래머에 대한 모호성은 유키로 간주됩니다.

Answer 9

사례 민감도는 이름 지정 규칙을 사용하여 언어 가독성을 추가합니다. 당신은 쓸 수 없습니다

Person person = new Person("Bill");

컴파일러가 클래스 이름과 변수 이름을 구별 할 수 없기 때문에 언어가 사례 둔감 한 경우.

또한 사람, 사람, 사람, 사람, 사람과 사람이 있으면 모두 동등한 토큰이되면 두통이 생길 것입니다. :)

Answer 10

자본 형태는 무엇입니까? 나? 나 (u+0049) 또는 İ (U+0130)?

자본화는 로케일의 종속입니다.

Answer 11

많은 (비 프로그래밍) 언어 (예 : 로마 알파벳을 사용하는 유럽인)는 대소 문자에 민감하기 때문에 해당 언어의 원어민이 상류 / 소문상 차이를 사용하는 것은 당연합니다.

프로그래밍 언어가 바로 아이디어 그렇지 않을 것입니다 BE CASE-SENSTIVE는 초기 세대 하드웨어 (5 비트 문자 코드를 사용한 프리 컴퓨터 텔레타이프 머신 포함)의 한계에서 발생하는 과거 아티팩트입니다.

사례 맹인 언어를 주장하는 사람들은 구별 할 수 없어야합니다.

IAmNowHere

~에서

IAmNowhere

(그것은 농담! ;-)

Answer 12

그것들 때문에 개구리 상자로 바보, 정확히이 실에서 반대의 관점에 대한 이유가 있기 때문에 (나는 그것이 무엇에 관한 것인지 묻지 않을 것입니다. 나무를위한 나무와 그 모든 것).

foobar = foobar = foobar 일 때, 당신은 당신의 컨벤션을 선택하게되고, 다른 코더는 동일하게 할 수 있습니다. 그들이 당신의 선호도를 공유하는지 여부. 혼란이 없습니다.

그들은 또한 다른 캡이 있지만 동일한 파일에서 동일한 이름으로 상수, 기능 및 변수를 갖는 천재의 뇌졸중으로 도망 갈 수는 없습니다. 다시, 혼란이 없습니다.

당신은 당신의 가변 웹 사이트를 호출하고, 그들의 웹 사이트를 호출하고 어떤 시스템이 혼란스러워합니까? 스캔 할 때는 쉽게 잡히지 않습니다.

조회는 이름을 찾기 전에 소문자로 변환하는 것이 훨씬 더 많은 처리입니까? 자신의 조기 최적화를 수행하는 것은 한 가지 일입니다. 선택한 언어 개발자로부터 기대하는 것은 요점을 놓친 다른 수준입니다.

... 그러나이 모든 대답은 사례 감지 성이 혼란을 줄입니다. 한숨을 쉬다

Answer 13

또한 많은 사람들이 잘못 생각한다고 믿는 사례에 민감한 언어 인 일반적인 LISP도 있습니다. 입력 할 때 (car x) 청취자로, 그것은 바로 변합니다 (CAR X) 처리를 위해. 소문자 이름으로 기호를 정의 할 수 있지만와 같은 것으로 인용해야합니다. |lower-case-symbol|. 따라서 입력 (car x) 또는 (CAR X) 또는 (Car X) 모두 동일하게 작동합니다.

(Franz Lisp는 한 시점에서 청취자가 케이스를 접지 않을 것이며 CL 키워드는 소문자에있을 것입니다. 나는 그곳에서 무슨 일이 있었는지 알기에 충분히 잘 따랐습니다.)

Answer 14

편지의 상부 보편적 인 개념이 아닙니다. Java는 유니 코드를 사용하므로 사례에 민감하지 않은 Java를 원한다면 프로그램의 의미는 컴파일 된 로케일에 따라 변경 될 수 있습니다.

대부분의 언어는 정수 리터럴 한가운데에 점이나 쉼표 (또는 아포스트로피 또는 공간)를 넣을 수 없습니다. 아마도 로케일 의존적이기 때문일 것입니다.

Answer 15

서 .NET Framework 개발자 가이드 자본화 규칙, 케이스,감도:

대소문자 지침 전적으로 식별자를 만들게 읽고 인식하고 있습니다.케이싱할 수 없 용을 회피하는 수단으로 이름 라이브러리 사이에 충돌이 요소입니다.

가정하지 않는 모든 프로그램 언어는 대소문자를 구분합니다.그 하지 않습니다.이름에 따라 다를 경우 혼자입니다.

Answer 16

모자가 없다면 어떻게 소리 지르나요?! 아!

당신은 표현력이 있어야합니다. 그러나 모든 정직에서, 세상의 모든 사람들 중에서 프로그래밍 논리를 다루는 사람들은 차이가 실제로 차이라고 주장하는 첫 번째 사람 일 것입니다.

Answer 17

사례 민감도는 실제로 사례 일관성에 도움이되지 않습니다.

Foo.Bar  
foo.Bar  
fOO.bAR  

경우 편집기가 쉽게 고정 할 수있는 둔감 한 언어. 민감한 언어를 고치는 경우 합법적 일 수 있으므로 더 어렵습니다. 편집자는 foo.bar와 foo.bar가 존재한다면 먼저 ckeck해야하며 변수를 선언하는 것을 잊지 않고 잘못된 사례를 입력했다고 추측해야합니다 (foo가 foo와 다르기 때문에).

Answer 18

여기 많은 사람들이 여러 형태의 자본화가 같은 것을 언급하는 것이 나쁘다고 말했습니다.

person
perSoN
PERSON

실제로 나쁜 것은이 모두 코드의 다른 객체를 언급하는 경우입니다. 변수, 사람, 사람 및 사람이 모두 다른 것들을 참조하는 경우 문제가 있습니다.

Answer 19

내가 보았던 사례 민감도를 보았던 모든 예는 나쁜 비판적 코드를 작성하려는 욕구를 기반으로합니다. 예를 들어 "날짜"대 "MyDate"인수 - 둘 다입니다. 마찬가지로 설명이 아닙니다 그리고 나쁜 연습. 모범 사례는 실제로 무엇을 말하는 것입니다 : 생년월일, 고용, 인보이스데이트 등 무엇이든. 그리고 올바른 마음 속에 누가 다음과 같은 코드를 작성하고 싶어 할 것입니다.

Public Class Person
    Public Shared ReadOnly PERSON As Person
End Class
Public Class Employee
    Public person As Person = person.PERSON
End Class

놀랍게도 이것은 완벽하게 유효한 경우입니다 안에민감한 vb.net 코드. 사례 민감도가 당신이 좋은 프로그래밍 관행에 더욱 강력하게 불순종 할 수 있다는 생각은 그것에 대한 논쟁입니다.

Answer 20

많은 사람들이 Employee_social_security_number만큼 읽기 쉬운 직원을 찾는다.

Answer 21

사례에 민감한 언어를 사용하면 사람들이 열악한 코드를 작성하도록 권장합니다.

Const SHOESIZE = 9

Class ShoeSize

ShoeSize.shoesize = SHOESIZE

call shoeSize(ShoeSize);

function shoeSize(SHOEsize)
{
   int ShoeSIZE = 10
   return ShoeSize
}

듀. 다른 목적으로 "신발화"보다 더 나은 변수 이름을 생각할 수 없습니까? 사용할 수있는 10 억 단어가 있지만 대신 Shoesize를 계속 사용하도록 선택합니까?

Answer 22

또한 모든 클래스, 변수, 기능 및 메소드에 단일 레터 ( "A"및 "B"및 "C")를 사용할 수도 있습니다.

하지만 왜 원하십니까?

의미가있는 이름을 사용하십시오, 아니다:

function a(a)
{
    int a = a.a;
    return a
}

Answer 23

언어가 사례 민감한 또 다른 이유가 있습니다. ID는 해시 테이블에 저장 될 수 있으며 해시 테이블은 다른 경우에 대해 다른 해시를 제공하는 해싱 함수에 따라 다릅니다. 해시 함수를 통해 실행하기 전에 모든 ID를 모든 상단 또는 전부로 변환하는 것이 편리하지 않을 수 있습니다. 나는 내 컴파일러를 작성할 때이 문제를 발견했습니다. 내 언어를 사례에 민감한 것으로 선언하는 것은 훨씬 간단했습니다 (Lazier).

Answer 24

이 전체 스레드를 읽었습니다. 나는 민감도에서 가치를 발견했다고보고 한 사람들이 진정한 높은 수준의 언어로 프로그래밍 된 적이 없다고 믿어야합니다 (정의에 따라 사례에 민감하지 않음). K & R은 C가 중간 수준임을 인정합니다. Pascal, Delphi, Lazarus, Ada 등으로 프로그래밍 한 후, 읽기 쉬운 코드는 간단한 경우에 민감한 구성에 집착하지 않고 빠르게 쓰기가 간단하다는 것을 알게됩니다. 결국, 가독성은 주제에 대한 첫 번째이자 마지막 단어입니다. 코드는 컴퓨터가 아닌 인간을 위해 작성되었습니다. Case Insensitive Code로 디버깅하는 데 문제가 없습니다. 중간 수준의 언어로 이동하면 사례 민감도에 대한 장점이 없다는 것을 알게됩니다. 그러나 디버깅 케이스 민감도가 문제를 일으킨 시간이 상당한 시간이 소요되었습니다. 특히 다른 코더에서 모듈을 함께 패치 할 때. 또한 많은 응답자가 사례 무감각의 의미를 이해하지 못하는 것으로 보입니다. 캐릭터 AZ 만 영향을받습니다. 이것들은 ASCII 문자의 순차적 하위 집합입니다. 기계 코드의 3-4 바이트는 컴파일러 가이 범위의 문자에서 사례를 무관하게 만듭니다. 언더 바, 숫자 또는 다른 것을 변경하지 않습니다. 다른 언어와 캐릭터 세트에 대한 요점은 단순히이 토론에 적용되지 않습니다. 컴파일러 또는 인터럽트는 Compile Time에서 ASCII에 따라 분석을 위해 문자를 일시적으로 변환하거나 변환하지 않도록 코딩됩니다.

나는 K & R이 저지른 실수를 반복하는 Python과 같은 새로운 언어에 충격을 받았습니다. 예, 컴파일러, 소스 및 객체 코드의 총 RAM이 1000 바이트 인 환경에서 6 바이트를 절약했습니다. 그때였습니다. 이제 기억은 문제가되지 않습니다. 이제 현명한 이유없이, 파이썬의 예비 단어조차도 사례에 민감합니다! "인쇄"의 "for"를 변수 또는 함수 이름으로 사용할 필요는 없다고 생각합니다. 그러나 그 가능성은 각 식별자의 정확한 경우에 대한 인터럽트와 만족하는 데 소요되는 시간의 비싼 시간에 의해 보존되었습니다. 내가 생각하는 나쁜 거래.

사례 민감도를 지원하기 위해 지금까지 읽은 가장 가까운 것은 해싱에 대한 의견입니다. 그러나 세부 사항에주의를 기울여 처리 할 수있는 이러한 희귀 한 코딩 이벤트는 코더가 케이스 민감한 코드를 작성하는 데 사용해야하는 무의미한 조사의 가치가없는 것 같습니다. 문제의 두 가지 견해. 하나는 나쁜 코딩을 장려하고 코드에 트랩을 설정하며 더 큰 개념에서 멀어지게하려면 추가주의를 기울여야합니다. 다른 하나는 아래쪽이없고, 높은 수준의 언어로 완벽하게 작동했으며, 유연성이 해를 끼치 지 않으면 유연성을 허용합니다. 베타보다 VHS 승리의 또 다른 사례처럼 보입니다. 여기는 내 두 센트의 가치가 있습니다.

Answer 25

학습은 항상 예에 따라 더 쉽기 때문에 여기에 있습니다.

C#(CASE 민감하지만 VB.NET에서 사용할 수있는 경우는 둔감합니다) :

CONSTANT_NAME
IInterfaceName // Uses I prefix in all case sensitive and insensitive languages
ClassName      // Readable in both case sensitive and insensitive languages
_classMember   // sometimes m_classMember or just classMember
DoSomething(someParam) // Method with action name, params can be _someParam
PropertyName   // Same style in case sensitive and insensitive languages
localVariable  // Never using prefix

Java와 JS는 C#과 유사한 스타일을 사용하지만 메소드/함수/이벤트는 변수와 같이 선언됩니다.

ObjectPascal (Delphi 및 Lazarus/FPC는 ADA 및 VB.NET과 같이 사례 둔감합니다)

CConstantName     // One can use Def or no prefix, not a standard
IInterfaceName
TClassName        // Non-atomic types/classes have T prefix e.g. TStructRecordName
PSomePointer      // Pointers have types, safer low level stuff
FClassFieldMember // F means Field member similar to m
DoSomething(Parameter) // Older code uses prefix A for parameters instead
PropertyName
LLocalVariable    // Older code uses prefix for parameters not local vars

각 유형에 대해 Onecase 및 접두사 만 사용하면 모든 언어로 적합합니다. 접두사없이 시작된 언어조차도 케이스에 의존하지 않고 접두사를 사용하는 인터페이스와 같은 최신 구성이 있습니다.

따라서 언어가 사례에 민감한 경우 실제로 중요하지 않습니다. 사례만으로 표현하기에는 너무 혼란스럽고 접두사를 사용하여 필요한 사례 민감한 언어에 최신 개념이 추가되었습니다.

사례 민감한 언어는 접두사를 사용하기 시작 했으므로 동일한 식별자 이름으로 케이스 사용을 중지하는 것이 합리적입니다.

이 문제를 고려하십시오 : 당신은 무언가, 무언가라는 메소드/함수 매개 변수 및 무언가라는 로컬 변수라는 클래스 멤버가 있습니다. 모든 곳에서 가장 일관성있는 카세 스타일을 사용하고 접두사를 추가하는 것이 더 쉽지 않습니까?

CASE Insensitive Languages의 팬은 코드 품질을 관리하고 단지 하나의 스타일을 원합니다. 때때로 그들은 한 라이브러리가 잘못 쓰여지지 않았다는 사실을 받아들이고 엄격한 스타일을 사용하는 반면 라이브러리에는 스타일이나 코드가 좋지 않을 수 있습니다.

사례 민감성과 무감각 한 언어에는 엄격한 징계가 필요하며 어디에서나 한 스타일 만 갖는 것이 더 합리적입니다. Strictcase, 모든 곳에서 하나의 스타일 및 접두사 만 사용하는 언어가 있다면 더 나을 것입니다.

열악한 C 코드가 많이 있습니다. 케이스 민감도는 읽을 수 없으며 그것에 대해 아무것도 할 수 없습니다. 둔감하지 않은 경우 라이브러리를 다시 작성하지 않고 코드에서 좋은 스타일을 시행 할 수 있습니다. 아직 존재하지 않는 엄격한 언어로 모든 코드는 품질이 적당합니다. :)

Answer 26

사람들은 대부분 사례 민감도가 중요하다는 것에 동의하는 것처럼 보이며 동의합니다.

그러나 올바른 경우에 무언가를 입력해야 할 때는 성가신 일이 될 수 있으므로 IDE가 잘못된 케이스를 입력 할 수 있어야한다고 생각하지만 자동 완성 단축키에 도달하면 케이스 무의미한 일치를해야합니다. 이것은 우리에게 두 세계의 최고를 제공합니다.

Answer 27

일반적인 코딩 표준에 의해, 사람은 수업, 사람은 변수 이름, 사람은 일정합니다. 자본화가 다른 동일한 단어를 사용하여 관련이 있지만 약간 다른 것을 의미하는 것이 종종 유용합니다.

그래서, 당신이 당신의 사업에 3 명의 직원이 Robert라고 불렀다면, 당신은 그것들을 Robert, Robert 및 Robert라고 부를 것입니까? 그리고 당신이 어떤 의미인지 정확히 알기 위해 사람들에게 의존합니까?

이메일 시스템이 사례에 민감한 경우 robert@widgets.com, robert@widgets.com 및 robert@widgets.com과 같은 이메일 주소를 알려주십시오.

개인 데이터의 무단 위반 가능성은 엄청날 것입니다. 데이터베이스 루트 비밀번호를 불만을 품은 직원에게 해고하려는 경우는 말할 것도 없습니다.

Bob, Robbie 및 Robert라고 부르는 것이 좋습니다. 로버트 A, 로버트 B, 로버트 C라고 부르는 것이 더 나은 것이 더 좋습니다.

실제로 - 왜 지구상에서 실수 나 혼란을 불러 일으키는 이름 지정 규칙이 있는데, 사람들이 매우 경계하는 사람들에게 의존 하는가? 당신은 당신의화물에 너무 부족합니까?

그리고 아마도 "myclass myclass"라는 편리한 속임수를 언급 한 사람에 관해서는 왜, 왜, 왜? 사용 된 메소드가 클래스 메소드인지 인스턴스 메소드인지 여부에 관계없이 의도적으로보기 어렵게 만듭니다.

또한 다음 사람에게 수업의 특정 인스턴스에 대해 더 많은 코드를 읽을 수있는 기회를 잃었습니다.

예를 들어.

고객 previorcustomer

고객 NewCustomer

고객 CorporateCustomer

인스턴스 이름은 동료를 기반으로 한 클래스보다 더 이상 더 이상 말해야합니다!

Answer 28

단어 분리가 중요하지 않다면 왜 우리는 단어 사이에 공백을 두는가? 그러므로 나는 이름의 단어 사이에 밑줄이 가독성을 증가 시킨다고 생각합니다. 또한 적절한 문자의 대문자로 소문자가 읽기가 가장 쉽습니다. 마지막으로, 모든 단어를 입소문으로 전달할 수 있다면 "자본 C 소문자 밑줄 자본 C 소문자 USTMER"보다는 "기업 밑줄 고객"이라는 단어로 전달할 수 있다면 훨씬 쉽습니다! - 전자는 '머리 속에서'말할 수 있습니다. 후자는 할 수 없습니다. 저는 사례 민감도에 만족하는 사람들이 어떻게 이러한 사례 민감한 이름을 뇌에서 처리하는지 궁금합니다. 나는 정말로 어려움을 겪고 있습니다. 그래서 나는 사건 민감도가 전혀 도움이되지 않는다고 생각합니다. 제 생각에는 COBOL의 역전 단계입니다.

Answer 29

사람들이 진지하게 생각하기 때문입니다.

케이스 insensitivity는 케이스 보존 및 유형 네임 스페이스와 가변 네임 스페이스 간의 분리와 결합 될 때 가장 잘 작동합니다. 이것은 다음을 의미합니다.

• 수업을 '로 선언하는 경우TextureImage'그리고 그것을 사용하려고 노력하십시오'textureImage', IDE는 당신을 자동으로 고정시킬 수 있습니다. 이를 통해 식별자를 선언하거나 밑줄을 사용하지 않는 한 Shift 키를 누르지 않아도되는 이점이 있습니다.

• Java 및 기타 여러 언어와 마찬가지로; 입력하는 데 완벽하게 유효합니다. "MyClass myClass". IDE와 컴파일러는 유형의 사용과 변수의 사용을 구별하는 데 아무런 문제가 없어야합니다.

또한 사례 무감각성이o' 그리고 'O'다른 객체를 결코 언급하지 않을 것입니다. 일반적인 논쟁은 다음과 같습니다.

• "sOmEoNe wIlL tYpE cOdE lIkE tHiS"; => 그리고 누군가가 _never_는 프로그래밍 팀에 합류 할 수있게되므로 이것은 Strawman 논쟁입니다. 그들이 그렇게 했음에도 불구하고, 사례 무감각은 문제보다 솔루션입니다. 왜냐하면 그들이 사용하는 미친 대문자/소문자 조합을 기억할 필요가 없기 때문입니다.

• "당신은 사례 무감각을 쉽게 국제화 할 수 없습니다!"; => 프로그래밍 언어의 95% 이상이 아주 좋은 이유로 영어로 작성됩니다. 경쟁 캐릭터 인코딩은 없으며 지구상의 대부분의 키보드는 영어를 기반으로합니다 (부분적 또는 전체). 유니 코드 식별자를 지원하는 것은 아마도 21 세기에 누군가가 생각해 낸 가장 멍청한 아이디어 일 것입니다. 유니 코드 문자의 상당 부분이 Frikkin Invisible Surragates이기 때문에 Google 번역을 사용하지 않고도 읽기 코드는 충분히 어렵고, 캐릭터 맵을 복사하거나 캐릭터 맵을 복사하지 않아도 코드를 쓰는 것이 어렵습니다.

• "그러나 사례 민감한 언어에는 더 많은 식별자가 있습니다!"; => 아니요, 그들은 문법적으로 과부하 된 식별자를 가지고 있으며, 이는 실질적으로 더 나쁩니다.

나는 사례에 민감한 언어를 사용하지 않지만 이런 종류의 것에 대해 진지하게 생각하면 장점은 명백합니다.

Answer 30

합리적인 대답은 언어의 디자이너가 언어가 미래에 대한 생각을 더 쉽게 이해할 수있게 해줄 것이라고 생각했다는 것입니다. :)