3 ms·

> about rust. Is it better than, for example, oberon, or it's descendents? It's a completely different language with different focus and features. "better" dep

by Rochus 10mo ago

> about rust. Is it better than, for example, oberon, or it's descendents? It's a completely different language with different focus and features. "better" depends on the requirements you want to solve with the language. Rust can do memory management at compile time whereas Oberon and its descendants (such as my Oberon+ version) use a garbage collector at runtime. Rust is much bigger and more complex than Oberon, but it also has features which make it more suitable for systems programming. Simpler is not automatically better. If a language is too "simple" (i.e. minimalist), the complexity often shifts from the language specification to the application code, requiring more boilerplate or "clever" tricks to solve complex problems. And it was not only simplicity (as Vidar assumed), but Oberon indeed had a different approach to OO in that there were no bound procedures, but the idea was (as you can observe e.g. in the Oberon systems and in publication by Wirth an his PhD students) that "type extension" (i.e. inheritance) is used to create extensible message hierarchies, which then are polymorphically handled by procedures accepting a VAR parameter of the most general message type. In this handler, the messages are dispatched by the IS operator or the WITH or CASE statement. This has similar effects as e.g achievable by sum types, and interestingly is closer to e.g. Alan Kay's view of OO than the implementation found in Smalltalk-80 (notably, Wirth arrived at this message-centric model independently of Kay’s work in the Smalltalk lineage).

mikethe 10mo ago
"Simpler is not automatically better. If a language is too "simple" (i.e. minimalist), the complexity often shifts from the language specification to the application code, requiring more boilerplate or "clever" tricks to solve complex problems." ..fascinating.. ..it always comes down, again and again, to what is the problem you need to solve, and from there, what is the best solution. And at that point, once you have identified the problem.. in a way it's a toss-up whether you implement your own solution, or just happen to have heard of a solution to a similar or equivalent (or the same) problem, developed by somebody else. ..or how willing you are to dig in search of said hypothetical already-existing solution. And said hypotheticals must then themselves be evaluated, which also takes time.
mikethe 10mo ago
OO is a big issue here. Or rather, in general. I have read "The Art of Unix Programming", where a very big fuss is made over object-orientation. It's like they want to take a really big gun that means big business, and shoot it. Ever since reading that, I yelp whenever I see it mentioned, and squint in suspicion at the offender. So when a titan like Wirth endorses it.. ..there is obviously something of great importance that needs to be clearly understood, and that is -not- obvious. The same thing when I see mentions of C++. Except that I haven't yet found endorsements of it from anybody of Wirth's stature. Sites like suckless really do not help. Related: https://plan9.io/wiki/plan9/lfaq/index.html#HARDWARE_AND_SOFTWARE https://plan9.io/wiki/plan9/lfaq/index.html#HARDWARE_AND_SOF... " Is it object-oriented? No, not in the conventional sense. It is written in a strict dialect of ISO/ANSI C. In a wider sense, its general design of making all its ``objects'' look like files to which one talks in a well-defined protocol shows a related approach. "
- mikethe 10mo ago
  To clarify, you obviously understand OO better than most, certainly much much much better than I do. I happen to have Wirth's book on oberon here, have started reading it. So possibly, eventually, I will reach your level. :-)
- Rochus 10mo ago
  Raymond argues in the referenced book that while OOP has value in specific domains, its benefits have been oversold and its typical usage often conflicts with the core Unix philosophy of simplicity and transparency. I think that's a valid position, and hyping and overselling is a continuous fad in the programming industry, which is famously susceptible to what Fred Brooks called the "Silver Bullet" syndrome: the desperate search for a single magical technology that will solve the inherent difficulties of software engineering. The "simplicity and transparency" Raymond champions are indeed virtues, but they are also slogans used to rally a specific community. Just as "Memory Safety" is the rallying cry for Rust today, "Small is Beautiful" was the rallying cry for Unix in the 1970s. The industry seems to advance not by finding a static "truth," but by lurching between opposing philosophies, each powered by its own wave of activism. I recommend to ignore the "moral" arguments, but to focus on the engineering trade-offs. Most "revolutions" are just rediscoveries of old ideas. Functional Programming is largely Lisp (1958) re-branded. The "Anti-OO" movement is partly a return to procedural modularity (Pascal/C). Our job is not to be "pure"; your job is to build working, maintainable software using the best tools we can find for the specific problem at hand.
cxr 10mo ago
> "type extension" (i.e. inheritance) is used to create extensible message hierarchies, which then are polymorphically handled by procedures accepting a VAR parameter of the most general message type. In this handler, the messages are dispatched by the IS operator or the WITH or CASE statement. This has similar effects as e.g achievable by sum types, and interestingly is closer to e.g. Alan Kay's view of OO That seems off. Kay's comments have always struck me as in line with Brad Cox's views. Cox's book uses this example a lot as a poor/insufficient substitute for dynamic dispatch.
- Rochus 10mo ago
  > Kay's comments have always struck me as in line with Brad Cox's views It is unlikely that the two would have agreed on this. Kay's view is actually based on messages, as implemented in Erlang, for example, and to some extent in Smalltalk-72. Cox, on the other hand, has implemented the object and dispatch model of Smalltalk 80, that Ingalls invented and published in 1978, almost exactly, even with the same method lookup caching. > Cox's book uses this example a lot as a poor/insufficient substitute for dynamic dispatch. The Wirth and Smalltalk approach are both fundamentally "late-bound search" mechanisms, differing mainly in whether the search state is optimizable by a central engine (VM) or fixed in the user's explicit control flow (Handler). This is a classic example of dualism in computer science, specifically the Expression Problem (or the Data/Operation duality). You are simply traversing a 2D matrix of (Types × Operations), just choosing a different axis as primary. It's mathematically isomorphic, both are performing a directed graph traversal to find the code that matches (CurrentType, CurrentMessage). Only the ergonomics and possibility for caching differ. Smalltalk hides the dispatch loop in the VM, which can do caching and the dispatch effort goes from O(N) to O(1) in time. Wirth exposes the dispatch loop in the WITH statements with a dispatch effort continuously O(N).
  - cxr 10mo ago
    Perhaps I'm misreading a different (opposite/orthogonal) intent from what you meant when you wrote the quoted passage in your initial comment. Some form of dynamism is required, else it fails the "extreme late binding" criterion that Kay insists is fundamental to his view of OO. I'm not familiar enough with Smalltalk-72 or what Ingalls did that makes it so different from the Smalltalk-80 that Cox read about in Byte. > differing mainly in whether the search state is optimizable by a central engine (VM) or fixed in the user's explicit control flow (Handler). This is a classic example of dualism in computer science, specifically the Expression Problem (or the Data/Operation duality). You are simply traversing a 2D matrix of (Types × Operations), just choosing a different axis as primary. If you are doing whole-system development and have control over the entire thing (a "closed world" system), then it is that simple. But whether it's an open world or a closed world changes things. Cox is fond of a simple example that he repeats in his book (fairly early on—it's on something like page 9) to demonstrate that dynamic dispatch is fundamentally necessary because it means you don't have to have panoptic control/involvement over the objects in a system (with all types known at compile time). If you're programming every operation with switch statements that select code paths based on objects' type tags, not only do you have to go visit all N routines where each of those N operations are implemented to update them when introducing a single type, but it also requires a priori knowledge of all types to be baked into the system that you release at the time of release, whereas OO on a live system means that you can introduce new types even after the initial system has shipped to the user.

by Rochus 10mo ago

mikethe 10mo ago

"Simpler is not automatically better. If a language is too "simple" (i.e. minimalist), the complexity often shifts from the language specification to the application code, requiring more boilerplate or "clever" tricks to solve complex problems." ..fascinating.. ..it always comes down, again and again, to what is the problem you need to solve, and from there, what is the best solution. And at that point, once you have identified the problem.. in a way it's a toss-up whether you implement your own solution, or just happen to have heard of a solution to a similar or equivalent (or the same) problem, developed by somebody else. ..or how willing you are to dig in search of said hypothetical already-existing solution. And said hypotheticals must then themselves be evaluated, which also takes time.

mikethe 10mo ago

OO is a big issue here. Or rather, in general. I have read "The Art of Unix Programming", where a very big fuss is made over object-orientation. It's like they want to take a really big gun that means big business, and shoot it. Ever since reading that, I yelp whenever I see it mentioned, and squint in suspicion at the offender. So when a titan like Wirth endorses it.. ..there is obviously something of great importance that needs to be clearly understood, and that is -not- obvious. The same thing when I see mentions of C++. Except that I haven't yet found endorsements of it from anybody of Wirth's stature. Sites like suckless really do not help. Related: https://plan9.io/wiki/plan9/lfaq/index.html#HARDWARE_AND_SOFTWARE https://plan9.io/wiki/plan9/lfaq/index.html#HARDWARE_AND_SOF... " Is it object-oriented? No, not in the conventional sense. It is written in a strict dialect of ISO/ANSI C. In a wider sense, its general design of making all its ``objects'' look like files to which one talks in a well-defined protocol shows a related approach. "

mikethe 10mo ago
To clarify, you obviously understand OO better than most, certainly much much much better than I do. I happen to have Wirth's book on oberon here, have started reading it. So possibly, eventually, I will reach your level. :-)
Rochus 10mo ago
Raymond argues in the referenced book that while OOP has value in specific domains, its benefits have been oversold and its typical usage often conflicts with the core Unix philosophy of simplicity and transparency. I think that's a valid position, and hyping and overselling is a continuous fad in the programming industry, which is famously susceptible to what Fred Brooks called the "Silver Bullet" syndrome: the desperate search for a single magical technology that will solve the inherent difficulties of software engineering. The "simplicity and transparency" Raymond champions are indeed virtues, but they are also slogans used to rally a specific community. Just as "Memory Safety" is the rallying cry for Rust today, "Small is Beautiful" was the rallying cry for Unix in the 1970s. The industry seems to advance not by finding a static "truth," but by lurching between opposing philosophies, each powered by its own wave of activism. I recommend to ignore the "moral" arguments, but to focus on the engineering trade-offs. Most "revolutions" are just rediscoveries of old ideas. Functional Programming is largely Lisp (1958) re-branded. The "Anti-OO" movement is partly a return to procedural modularity (Pascal/C). Our job is not to be "pure"; your job is to build working, maintainable software using the best tools we can find for the specific problem at hand.

cxr 10mo ago

> "type extension" (i.e. inheritance) is used to create extensible message hierarchies, which then are polymorphically handled by procedures accepting a VAR parameter of the most general message type. In this handler, the messages are dispatched by the IS operator or the WITH or CASE statement. This has similar effects as e.g achievable by sum types, and interestingly is closer to e.g. Alan Kay's view of OO That seems off. Kay's comments have always struck me as in line with Brad Cox's views. Cox's book uses this example a lot as a poor/insufficient substitute for dynamic dispatch.

Rochus 10mo ago
> Kay's comments have always struck me as in line with Brad Cox's views It is unlikely that the two would have agreed on this. Kay's view is actually based on messages, as implemented in Erlang, for example, and to some extent in Smalltalk-72. Cox, on the other hand, has implemented the object and dispatch model of Smalltalk 80, that Ingalls invented and published in 1978, almost exactly, even with the same method lookup caching. > Cox's book uses this example a lot as a poor/insufficient substitute for dynamic dispatch. The Wirth and Smalltalk approach are both fundamentally "late-bound search" mechanisms, differing mainly in whether the search state is optimizable by a central engine (VM) or fixed in the user's explicit control flow (Handler). This is a classic example of dualism in computer science, specifically the Expression Problem (or the Data/Operation duality). You are simply traversing a 2D matrix of (Types × Operations), just choosing a different axis as primary. It's mathematically isomorphic, both are performing a directed graph traversal to find the code that matches (CurrentType, CurrentMessage). Only the ergonomics and possibility for caching differ. Smalltalk hides the dispatch loop in the VM, which can do caching and the dispatch effort goes from O(N) to O(1) in time. Wirth exposes the dispatch loop in the WITH statements with a dispatch effort continuously O(N).
- cxr 10mo ago
  Perhaps I'm misreading a different (opposite/orthogonal) intent from what you meant when you wrote the quoted passage in your initial comment. Some form of dynamism is required, else it fails the "extreme late binding" criterion that Kay insists is fundamental to his view of OO. I'm not familiar enough with Smalltalk-72 or what Ingalls did that makes it so different from the Smalltalk-80 that Cox read about in Byte. > differing mainly in whether the search state is optimizable by a central engine (VM) or fixed in the user's explicit control flow (Handler). This is a classic example of dualism in computer science, specifically the Expression Problem (or the Data/Operation duality). You are simply traversing a 2D matrix of (Types × Operations), just choosing a different axis as primary. If you are doing whole-system development and have control over the entire thing (a "closed world" system), then it is that simple. But whether it's an open world or a closed world changes things. Cox is fond of a simple example that he repeats in his book (fairly early on—it's on something like page 9) to demonstrate that dynamic dispatch is fundamentally necessary because it means you don't have to have panoptic control/involvement over the objects in a system (with all types known at compile time). If you're programming every operation with switch statements that select code paths based on objects' type tags, not only do you have to go visit all N routines where each of those N operations are implemented to update them when introducing a single type, but it also requires a priori knowledge of all types to be baked into the system that you release at the time of release, whereas OO on a live system means that you can introduce new types even after the initial system has shipped to the user.