오베론은 정말 더 나은 파스칼입니까? [닫은]

Niklaus Wirth를 읽으면 Pascal의 인기가 있음에도 불구하고 Oberon (Pascal과 Modula의 "광택 된"후계자)이 인기를 얻지 못했다는 것을 기쁘게 생각하지 않습니다. 나는 Oberon에서 아무것도 한 적이 없지만 Oberon For Pascal Developers 페이지를 읽는 것은 델파이 / 파스칼 개발자와 같은 많은 변경 사항을 좋아하지 않았습니다.

예약어를 항상 대문자로 설정
언어를 대소 문자 구분
열거 형 제거하기

오베론에 대해 어떻게 생각하십니까? 오베론은 실제로 "더 나은 파스칼"이라고 생각합니까?

programming-languages delphi pascal

— 막시
소스

Oberon은 프로그래밍에서 Ada / Pascal 시대의 먼 반향처럼 보입니다. Wirth의 원래 Pascal 언어보다 약간 나을 수 있지만 Turbo Pascal / Delphi보다 열등합니다.

— mojuba

@mojuba, 저에게 답인 것 같습니다 ...

— glenatron

이미 닫히지 않았습니까? 편집 기록은 어떻게 되었습니까?

— Robert Harvey

나는 대학 시절 오베론에 대해 잠깐 동안 매료되었습니다. 의견이 있으시면 더 알고 싶습니다.

— 베리 브라운

대문자 예약어를 요구하는 것은 저에게있어 거래를 깨뜨릴 것입니다. 소문자를 훨씬 쉽게 읽을 수 있습니다.

— GrandmasterB

답변:

예, 저는 오베론을 더 나은 파스칼이라고 부를 것입니다. Oberon과 함께 Wirth 교수는 유형 확장 및 프로 시저 변수를 사용하여 객체 지향 프로그래밍의 핵심에 도달했습니다. Oberon은 Pascal보다 더 작은 언어로 훨씬 더 강력하다는 것이 우아합니다.

Oberon 2는 메소드를 레코드에 바인딩하여 언어를 한 단계 더 발전 시켰습니다.

대문자 예약어를 싫어합니다. 많은 시작과 끝을 없앰으로써 구문이 개선되었다는 것을 알았습니다.

Oberon은 Project Oberon : 운영 체제 및 컴파일러 디자인에 설명 된 매우 흥미로운 운영 체제를 작성하는 데 사용되었습니다 .

— 블레이크
소스

동의합니다, 오베론이 더 낫습니다. 오베론의 문제는 너무 늦었다는 것입니다. 많은 사람들이 Fortran, Basic, Pascal, C를 개선하여 Oberon은 경쟁이 치열합니다. 그런 다음 언어는 솔루션의 일부일뿐입니다. '최상의'언어에는 좋은 라이브러리 또는 인프라가 있습니다. Javascript는 웹 응용 프로그램과의 연결로 인해 좋습니다. 그런 다음 JS를 기반으로 반응이 훨씬 커집니다. 언어 단순성에 관심이있는 사람은 누구입니까? 웹 애플리케이션을 구축하기 위해 반응 구성 요소와 같은 간단한 객체가 필요합니다.

— 롤랜드

여러 가지면에서 더 좋고 나쁩니다.

가비지 콜렉션과 모듈 식 및 객체 지향 프로그래밍을위한 기능이있는 것이 좋습니다. 상대적으로 작은 언어입니다. 파싱하고 구현하기 쉽습니다.

열거의 부족은 고통입니다 (실제로 우리가 사용하는 확장 된 Oberon 방언에서는 다시 추가했습니다).

더 현대적인 언어에 비해 미니멀리즘은 약간 잔인하며 문자열을 모든 언어의 문자 배열로 취급하는 것은 엄청납니다.

물론 파스칼도 상당히 진화했습니다. 예를 들어 컴포넌트 파스칼을보십시오.

— 그 루셀
소스

확장 된 Oberon 방언에서 열거 된 유형에 대한 유형 확장을 어떻게 수행합니까? 내가 묻는 이유 : Wirth 교수는 그것을 할 수있는 좋은 방법을 볼 수 없다고 말했기 때문에 언어에서 열거 된 유형을 제거했습니다.

— John R. Strohm

실제로, 나는 이름에도 불구하고 Component Pascal은 Pascal이 아닌 Oberon의 후속 제품이라고 생각합니다 (간접적으로는 제외). Algol-X (아직 구현되지 않음)-> Algol-W-> Pascal-> Modula (아직 구현되지 않음)-> Modula-2-> Oberon-> (일부 개정 Oberon)-> Component Pascal과 같은 것입니다.

— Jörg W Mittag

Wirth는 순수 주의자였습니다. 그는 확장 성과 직교성을 위해 열거 형의 유형 안전성을 잃는 것이 낫다고 결정했습니다. 우연한 값 충돌로 인해 미묘한 오류가 발생하는 열거 형의 유형 검사에서 이점을 얻는 많은 코드를 작성합니다. 간단히 말해, 우리는 전체 Oberon 코드베이스와 컴파일러를 모두 제어하기 때문에 매우 자극적 인 프로그램 오류의 클래스를 방지하기 위해 열거 형에 대한 확장명을 사용하지 않습니다.

— grrussel