에펠은 의미가있다

실제로 훨씬 더 있습니다. 그것은 엄격한뿐만 아니라 많은 반 엄격한 연산자를 가지고 있습니다.

프로그래머가 그러한 것들을 사용하지 않는 이유는 그들이 무엇인지, 어떻게 사용하는지, 언제 사용하는지, 어떻게 디자인 하는지를 정확히 알도록 훈련받지 않았기 때문입니다. 그들은 결코 훈련을받지 않았기 때문에 컴파일러 작성자에게 요청하지 않기 때문에 컴파일러 사람들은 그러한 메커니즘을 컴파일러에 넣는 것을 귀찮게하지 않습니다. Computer Science 학생들과 Shade-tree 프로그래머가보다 둥근 교육을 받기 시작하면 컴파일러가 따라 잡기 시작합니다.

그런 부울 연산자를 가진 언어가 있고 그 언어를 사용하여 디자인하고 사용하는 방법을 알고 나면 사용하는 것으로 나타났습니다.

Eiffel에서는 계약 어설 션의 부울이 많은 특성으로 인해 계약 별 디자인으로 인해 “implies”키워드를 사용하는 것이 다소 두드러집니다. “묵시적”연산자를 사용하여 적절하고 효율적으로 만 작성할 수있는 일부 계약이 있습니다. 그런 다음 계약이없는 언어는 더 이상 함의 사용을보고, 훈련하고, 구현할 이유가 없다는 의견을 요구합니다.

이것에 덧붙여 대부분의 프로그래머들은 “수학적이고 논리적 인 약점”이라고 이야기의 나머지 부분을 알려줍니다. 당신이 당신의 교육에 수학과 논리가 무겁더라도, 함축과 같은 구문을 구현하지 않는 언어를 선택할 때, 그러한 것들이 불필요하거나 유용하지 않다고 생각하는 경향이 있습니다. 언어에 의문을 제기하는 사람은 거의 없으며 “컴파일러가 필요를 보지 못했음”과 “프로그래머가 필요를 보지 못했음”이라는 끝없는 악순환이됩니다.

대신에, 컴파일러 사람들은 이론으로 백업하고, 씻지 않은 많은 프로그래머들이 생각하거나 요구하는 것에 관계없이 이론에 의해 제안되거나 암시되는 언어 표기법을 작성해야한다 (예 : 객체 지향 이론). 거기에서 교수, 교사 및 기타 전문가들은 “언어 렌즈를 통한 이론”이 아닌 원시 이론을 기반으로 젊은 어리석은 사고를 전문적으로 훈련해야합니다. 이런 일이 발생하면 사람들은 갑자기 깨어나 무엇을 잃어 버렸는지, 무엇을 습격했는지 알게됩니다.

지금 당장-객체 지향과 같은 가장 무도회라는 이론이 많이 있지만, OO-glass-dark-of-[-pick-your-language]입니다. OO에 관한 대부분의 “이론”책은 어떤 언어의 렌즈를 통해 이론이 무엇인지 해석하기를 원하기 때문에 읽을 수 없습니다. 완전히 틀렸다. 수학 기반의 계산기 나 슬라이드 규칙을 가르치는 것과 같습니다. 아니요. 현실은 스스로에 대해 가르친 다음, “과학”이라고 불리는 것을 관찰하기 위해 표기법을 사용합니다. OO-based-on-language-X라는 다른 매쉬는 현실을 거의 나타내지 않도록 왜곡되어 있습니다.

따라서 언어에서 벗어나 원시 이론을 살펴보고 다시 시작하십시오. 언어의 한계, 제약 및 페인트 작업이 이론이 무엇인지 말하지 않도록하십시오. 단순히 이론의 현실이 자신의 표기법을 지시하게 한 다음 거기에서 언어를 공식화하는쪽으로 이동하십시오.

거기에서 함의와 “의미”가 유용 할뿐만 아니라 우아하고 매우 시원 할 수있는 방법을 얻게됩니다.

좋은 일이!

답변

print (False <= False) # This will print True.
print (False <= True)  # This will print True.
print (True <= False)  # This will print False.
print (True <= True)   # This will print True.

LEFT RIGHT RESULT
F    F     T
F    T     T
T    F     F
T    T     T