Oberon est-il vraiment «un meilleur Pascal»? [fermé]

12

En lisant Niklaus Wirth , on peut remarquer que malgré une certaine popularité de Pascal, il n'est pas content qu'Oberon (en tant que successeur "poli" de Pascal et Modula) n'ait pas eu beaucoup de popularité. Je n'ai jamais rien fait à Oberon, mais en lisant la page Oberon pour les développeurs Pascal, je n'ai vraiment pas aimé beaucoup de changements en tant que développeur Delphi / pascal, par exemple

  • forçant les mots réservés à être toujours en majuscules
  • rendre la langue sensible à la casse
  • se débarrasser des types d'énumération

Que pensez-vous d'Oberon, est-ce vraiment "un meilleur Pascal" de votre point de vue?

programming-languages delphi pascal Maksee
la source
3
Oberon semble être un écho lointain de l'ère Ada / Pascal dans la programmation. Il peut être légèrement meilleur que le langage Pascal original de Wirth, mais il est évidemment inférieur à Turbo Pascal / Delphi.
mojuba
2
@mojuba, cela ressemble à une réponse pour moi ...
glenatron
N'était-ce pas déjà fermé une fois? Qu'est-il arrivé à l'historique des modifications?
Robert Harvey
J'ai eu une brève fascination pour Oberon pendant mes années universitaires. J'aimerais en savoir plus pour avoir une opinion.
Barry Brown
1
Exiger des mots réservés en majuscules serait une rupture pour moi. Je trouve les minuscules beaucoup plus faciles à lire.
GrandmasterB

Réponses:

8

Oui, j'appellerais Oberon un meilleur Pascal. Avec Oberon, le professeur Wirth est entré au cœur de la programmation orientée objet avec l'extension de type et les variables de procédure. Je trouve élégant qu'Oberon soit une langue plus petite que Pascal avec beaucoup plus de puissance.

Oberon 2 a poussé la langue un peu plus loin en liant les méthodes aux enregistrements.

Je n'aime pas les mots réservés en majuscules. Je trouve la syntaxe une amélioration avec l'élimination de nombreux débuts et fins.

Oberon a été utilisé pour écrire un système d'exploitation très intéressant décrit dans Project Oberon: The Design of an Operating System and Compiler .

Blake
la source
D'accord, Oberon est meilleur. Le problème avec Oberon est qu'il est arrivé trop tard. Beaucoup d'autres ont amélioré Fortran, Basic, Pascal, C, donc Oberon a de sérieux concurrents. Ensuite, la langue n'est qu'une partie de la solution. La «meilleure» langue a de bonnes bibliothèques ou une infrastructure. Javascript est génial en raison du lien avec les applications Web. Ensuite, réagir est encore plus grand, en s'appuyant sur JS. Qui se soucie de la simplicité de la langue? Nous voulons des objets simples comme des composants React pour créer des applications Web.
Roland
6

C'est mieux, et pire, de diverses manières:

Il est agréable d'avoir un ramasse-miettes et des installations pour une programmation modulaire et orientée objet. C'est une langue relativement petite; facile à analyser et à mettre en œuvre.

Le manque d'énumérations est une douleur (en effet, dans le dialecte Oberon étendu que nous utilisons, nous les avons rajoutés).

Par rapport aux langues plus modernes, son minimalisme est un peu brutal, et traiter les chaînes comme des tableaux de caractères dans n'importe quelle langue est horrible.

Bien sûr, Pascal a également beaucoup évolué, par exemple voir Component Pascal.

grrussel
la source
Comment tapez-vous l'extension sur les types énumérés dans votre dialecte Oberon étendu? Raison pour laquelle je pose la question: le professeur Wirth a dit qu'il ne voyait pas de bonne façon de le faire, et c'est pourquoi il a supprimé les types énumérés de la langue.
John R. Strohm
2
En fait, je crois que malgré son nom, Component Pascal est un successeur d'Oberon, pas Pascal (sauf indirectement, bien sûr). Il va quelque chose comme Algol-X (jamais implémenté) -> Algol-W -> Pascal -> Modula (jamais implémenté) -> Modula-2 -> Oberon -> (quelques révisions d'Oberon) -> Component Pascal.
Jörg W Mittag
2
Wirth était un puriste; il a décidé qu'il valait mieux perdre la sécurité de type des énumérations pour l'extensibilité et l'orthogonalité. Nous écrivons beaucoup de code qui bénéficie de la vérification de type des énumérations, où les collisions de valeurs co-incidentes introduiraient sinon des erreurs subtiles. En bref, puisque nous contrôlons à la fois la base de code Oberon entière et le compilateur, nous faisons sans extension de type sur les énumérations, afin d'éviter une classe d'erreurs de programme extrêmement irritantes.
grrussel