Чи справді Оберон "кращий Паскаль"? [зачинено]

Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або експертними знаннями, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитувань чи розширеної дискусії. Якщо ви вважаєте, що це питання можна вдосконалити та, можливо, знову відкрити, відвідайте довідковий центр для ознайомлення .

Закрито 7 років тому .

Читаючи Ніклаус Вірт , можна помітити, що незважаючи на деяку популярність Паскаля, він не радий, що Оберон (як «відшліфований» наступник Паскаля і Модули) не набув великої популярності. Я ніколи нічого не робив в Oberon, але читаючи сторінку Oberon For Pascal Developers, мені дійсно не сподобалось багато змін, як розробник Delphi / pascal, наприклад

змушуючи зарезервовані слова завжди бути великими
роблячи залежність мови від регістру
позбавлення від видів перерахування

Що ви думаєте про Оберона, чи справді він "кращий Паскаль" з вашої точки зору?

programming-languages delphi pascal

— Максі
джерело

Оберон здається далеким відлунням епохи Ада / Паскаль в програмуванні. Це може бути трохи краще, ніж оригінальна мова Вірта Паскаль, але, очевидно, вона поступається Turbo Pascal / Delphi.

— mojuba

@mojuba, це виглядає як відповідь для мене ...

— glenatron

Хіба це вже не було закрито? Що сталося з історією редагування?

— Роберт Харві

У мене в короткі роки я захопився Обероном. Я б хотів, щоб я знав більше про це, щоб мати думку.

— Баррі Браун

Вимагати застережених слів у верхньому регістрі для мене буде переривкою угоди. Мені нижній регістр набагато легше читати.

— GrandmasterB

Відповіді:

Так, я б назвав Оберона кращим Паскалем. З Обероном професор Вірт потрапив до ядра об'єктно-орієнтованого програмування з розширенням типу та змінними процедур. Мені здається елегантним те, що Оберон є меншою мовою, ніж Паскаль із значно більшою силою.

Оберон 2 зробив мову на крок далі, прив’язуючи методи до записів.

Мені не подобаються зарезервовані великі слова. Я вважаю синтаксис вдосконаленням з усуненням багатьох починається і закінчується.

Oberon був використаний для написання дуже цікавої операційної системи, описаної в Project Oberon: Design of Operating System and Compiler .

— Блейк
джерело

Погодьтеся, Оберон краще. Проблема з Обероном полягає в тому, що він прийшов занадто пізно. Багато інших вдосконалилися на Fortran, Basic, Pascal, C, тому в Оберона є серйозні конкуренти. Тоді мова є лише частиною рішення. "Краща" мова має хороші бібліотеки або інфраструктуру. Javascript чудово завдяки зв’язку з веб-додатками. Тоді реакція ще більше, спираючись на JS. Кого хвилює простота мови? Ми хочемо, щоб прості об’єкти, такі як реагують компоненти, створювали веб-додатки.

— Роланд

Краще і гірше різними способами:

Приємно мати сміття та засоби для модульного та об'єктно-орієнтованого програмування. Це порівняно невелика мова; легко розбирати та реалізовувати.

Відсутність перерахунків - це біль (дійсно, в розширеному діалекті, який ми використовуємо, ми додали їх назад).

Щодо більш сучасних мов, то його мінімалізм є трохи жорстоким, а поводження з рядками як до масивів символів будь-якою мовою є жахливим.

Звичайно, Паскаль теж досить еволюціонував, наприклад, див. Компонент Паскаль.

— грильсель
джерело

Як ви робите розширення для перелічених типів у своєму розширеному діалекті Оберон? Причина, яку я запитую: професор Вірт сказав, що він не бачить хорошого способу зробити це, і тому він видалив перелічені типи з мови.

— Джон Р. Стром

Власне, я вважаю, що незважаючи на свою назву, компонент Паскаль є спадкоємцем Оберона, а не Паскаля (за винятком непрямого, звичайно). Це щось на зразок Algol-X (ніколи не реалізований) -> Algol-W -> Pascal -> Modula (ніколи не реалізований) -> Modula-2 -> Oberon -> (деякі редакції Oberon) -> Компонент Pascal.

— Йорг W Міттаг

Вірт був пуристом; він вирішив, що краще втратити тип безпеки переліків на розтяжність та ортогональність. Ми пишемо багато коду, який виграє від типової перевірки перерахунків, де одночасно випадкові зіткнення значення вводять тонкі помилки. Коротше кажучи, оскільки ми контролюємо як всю базу коду Oberon, так і компілятор, ми обходимось без розширення типу на перерахунки, щоб уникнути класу надзвичайно дратівливих помилок програми.

— груссел