TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Niklaus Wirth on the importance of abstraction to language design (2018) [video]

3 pointsby hazelnut-treeover 1 year ago

1 comment

Rochusover 1 year ago
&gt; &quot;<i>unless you strive for that concept of machine independence [..] you&#x27;ll never really make great progress in the art of programming</i>&quot;<p>Well, if I then have a look at the Oberon language and the Oberon system I see an abundance of constructs like SYSTEM.VAL(LONGINT,pointer), SYSTEM.ADR(designator) etc. which assume that and address is compatible with the LONGINT 32 bit signed integer type; and there is the trick that you can pass any type to an ARRAY OF BYTE VAR-parameter; and there are a lot of adventurous type casts of all sorts using SYSTEM.VAL and code which is not only non-portable to another architecture, but even incompatible with code generated by another compiler (assuming specific headers of records or arrays, etc.). There are even modules in the Oberon System using such non-portable and compiler cheating tricks where there is actually no need since all could be represented in plain Oberon (with no SYSTEM module etc.).<p>&gt; &quot;<i>C++ the worst disease ever created</i>&quot;<p>But it let&#x27;s me implement very efficient and portable code without the nasty tricks mentioned above, because I can take references or pointers of things which can be type-checked by the compiler. Of couse I can also do nasty things in C or C++, but as demonstrated Oberon is no different in that respect (even worse because there is no way to do low-level programming with at least some type-checking support at all). All in all an unnecessary and unworthy claim for a man of his stature.