3 ms·

Nice tribute to Wirth. I just have some feedback :-) > ...modular languages offer one implementation for each interface. Unfortunately, this is totally incorr

Nice tribute to Wirth. I just have some feedback :-) > ...modular languages offer one implementation for each interface. Unfortunately, this is totally incorrect. Modular languages absolutely allow any interface to have multiple implementations which can be chosen amongst. This corresponds to how a Java 'interface' can have multiple implementations. In fact programming to the interface and swapping the implementation is one of the main selling points of interfaces. > Some of those constraints remained long after advances in hardware and software made the insistence on one-pass compilation seem obsolete. With compile speeds nowadays we can only wish that this insistence was obsolete. It's needed now more than ever with the slow-as-molasses compilers (apart from a notable few) of today.

pjmlp 3y ago
He is talking in the context of modules as in Modula-2 and Oberon, not language types, or the split interface/implementation, which goes towards your point as Modula-3 and Ada allowed various interface module/package declarations to the same implementation. Still not the same as Objective-C/Java interfaces that later on become more widely known, or Standard ML modules, CLU clusters, all of them type system based.
- yawaramin 3y ago
  It's not clear to me that he means only Modula-2 and Oberon when he says 'modular languages', especially as just in the previous paragraph he says: '...stopped caring much for purely modular languages, including Ada as it was then'
  - pjmlp 3y ago
    Modular languages are languages that support modules. https://en.wikipedia.org/wiki/Modular_programming https://en.wikipedia.org/wiki/Modular_programming See "Languages that formally support the module concept include..."
kragen 3y ago
what he says is correct about languages like modula-2, oberon, ada, ocaml, c, and c++, at least within a single compilation. you can have multiple implementations of the interface described in a single .h file, but you have to choose at most one of them every time you go to compile. this is distinct from how things like java work; java doesn't have this problem c++ compilation is mostly slow not because c++ compilers use lalr parsers (they don't) but because c++ programs commonly wedge lots of the implementation into the "interface", i.e., the .h file, and use recursive textual #include non-c++ compilers are super fast
- pjmlp 3y ago
  Nowadays, import std; import something_with_templates; int main () { std::println ("Hello World"); something_with_templates::my_func("data"); } Is also super fast.
  - kragen 3y ago
    thanks! this is interesting! for me, with the something_with_templates commented out, that gives these errors: $ g++ -Wall -Werror -O -std=c++23 pjmlp-hello.cc -o pjmlp-hello pjmlp-hello.cc:1:1: error: ‘import’ does not name a type 1 | import std; | ^~~~~~ pjmlp-hello.cc:1:1: note: C++20 ‘import’ only available with ‘-fmodules-ts’, which is not yet enabled with ‘-std=c++20’ pjmlp-hello.cc: In function ‘int main()’: pjmlp-hello.cc:5:8: error: ‘println’ is not a member of ‘std’ 5 | std::println ("Hello World"); | ^~~~~~~ $ g++ -Wall -Werror -O -std=c++23 -fmodules-ts pjmlp-hello.cc -o pjmlp-hello In module imported at pjmlp-hello.cc:1:1: std: error: failed to read compiled module: No such file or directory std: note: compiled module file is ‘gcm.cache/std.gcm’ std: note: imports must be built before being imported std: fatal error: returning to the gate for a mechanical issue compilation terminated. so it looks like it could conceivably be super fast if it worked. perhaps std.gcm should be included in the libstdc++ package or built as part of apt install? still, though i wasn't able to test, i anticipate some slowness due to the semantic model of template expansion, which is one step removed from preprocessor textual expansion

pjmlp 3y ago

He is talking in the context of modules as in Modula-2 and Oberon, not language types, or the split interface/implementation, which goes towards your point as Modula-3 and Ada allowed various interface module/package declarations to the same implementation. Still not the same as Objective-C/Java interfaces that later on become more widely known, or Standard ML modules, CLU clusters, all of them type system based.

yawaramin 3y ago
It's not clear to me that he means only Modula-2 and Oberon when he says 'modular languages', especially as just in the previous paragraph he says: '...stopped caring much for purely modular languages, including Ada as it was then'
- pjmlp 3y ago
  Modular languages are languages that support modules. https://en.wikipedia.org/wiki/Modular_programming https://en.wikipedia.org/wiki/Modular_programming See "Languages that formally support the module concept include..."

kragen 3y ago

what he says is correct about languages like modula-2, oberon, ada, ocaml, c, and c++, at least within a single compilation. you can have multiple implementations of the interface described in a single .h file, but you have to choose at most one of them every time you go to compile. this is distinct from how things like java work; java doesn't have this problem c++ compilation is mostly slow not because c++ compilers use lalr parsers (they don't) but because c++ programs commonly wedge lots of the implementation into the "interface", i.e., the .h file, and use recursive textual #include non-c++ compilers are super fast

pjmlp 3y ago
Nowadays, import std; import something_with_templates; int main () { std::println ("Hello World"); something_with_templates::my_func("data"); } Is also super fast.
- kragen 3y ago
  thanks! this is interesting! for me, with the something_with_templates commented out, that gives these errors: $ g++ -Wall -Werror -O -std=c++23 pjmlp-hello.cc -o pjmlp-hello pjmlp-hello.cc:1:1: error: ‘import’ does not name a type 1 | import std; | ^~~~~~ pjmlp-hello.cc:1:1: note: C++20 ‘import’ only available with ‘-fmodules-ts’, which is not yet enabled with ‘-std=c++20’ pjmlp-hello.cc: In function ‘int main()’: pjmlp-hello.cc:5:8: error: ‘println’ is not a member of ‘std’ 5 | std::println ("Hello World"); | ^~~~~~~ $ g++ -Wall -Werror -O -std=c++23 -fmodules-ts pjmlp-hello.cc -o pjmlp-hello In module imported at pjmlp-hello.cc:1:1: std: error: failed to read compiled module: No such file or directory std: note: compiled module file is ‘gcm.cache/std.gcm’ std: note: imports must be built before being imported std: fatal error: returning to the gate for a mechanical issue compilation terminated. so it looks like it could conceivably be super fast if it worked. perhaps std.gcm should be included in the libstdc++ package or built as part of apt install? still, though i wasn't able to test, i anticipate some slowness due to the semantic model of template expansion, which is one step removed from preprocessor textual expansion