Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs.
---
@lispm, I have reply here because I'm temporarily unable to make new posts.
> A large share of contemporary software is written in an object-oriented way.
Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's?
---
> Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'?
You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties.
> How are Racket's mechanisms for extending and redefining the language more principled
Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later.
> Especially since Racket provides some of that, too -> Swindle.
Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it...
> Is the CLOS MOP not principled? Why?
... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances?
The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.
> Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's?
Your original claim was "Unlike other languages that also advertise malleability (Common Lisp, Smalltalk, etc.), Racket is malleable in principled ways". Now you added 'more'. We can discuss which you or me like more, but you claimed that Smalltalk and Common Lisp can't be extended in 'principled' ways. Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'?
How are Racket's mechanisms for extending and redefining the language more principled than for example Common Lisp's CLOS and the Meta-object protocol for CLOS? Especially since Racket provides some of that, too -> Swindle.
I'm using for example LispWorks, a Common Lisp, which uses CLOS throughout to make the language flexible and extensible.
> That's why CLOS has meta-classes, meta-objects and generic functions. They provide the facilities for abstraction.
You must have different standards from mine for what kind of implementation details can be safely ignored. If my code depends on an abstract property of Foo, and the abstract property is observed not to hold, I must lodge a complaint with Foo's implementor, who will tell me either:
(0) It's my fault, I will fix my code. Thanks for telling me.
(1) It's your fault, I never promised to uphold that abstract property.
However, if arbitrary implementation details of arbitrary abstractions can be subverted by anyone, then another answer becomes possible:
(2) It's someone else's fault, and there's nothing either of us can do about it.
I object to the very existence of the last possibility. In what you call a “dynamic object-oriented” program, I prefer to regard genuine abstractions as completely inexistent, and all the implementation details of everything become the collective responsibility of all programmers.
I'm not gonna be there to fix anything that went wrong at that point.
---
I really like this analogy: assertions that are meant to always succeed are like crutches. Just like able-bodied people don't need to use crutches to walk, correctly designed programs don't need to test their own invariants to run.
Just in case: I don't mean any disrespect to people who do need crutches to walk. Nobody chooses to be disabled, but some programmers choose not to prove that their invariants hold.
> People who have an accident may become temporarily disabled, i.e., not able-bodied.
Temporarily -> no need to start over.
> And correctly-designed programs don't have “accidents”.
That's dangerously naive. Many mission critical software has bugs. That's why airplanes for example from Airbus use 'diversity' in both hardware and software. The same functionality is implemented with different sets of hardware and implemented by different teams using different programming languages. The systems are additionally designed for graceful degradation, dynamic reconfiguration, switching to alternative control software, ...
Still: Lufthansa Flight 2904 -> 'Computer logic prevented the activation of both ground spoilers and thrust reversers until a minimum compression load of at least 6.3 tons was sensed on each main landing gear strut, thus preventing the crew from achieving any braking action by the two systems before this condition was met.'
The software was surely not written in Lisp and I also would doubt they would allow Racket 'principled' macros anywhere near Flight Control Software.
> Argh, again I'm temporarily unable to make new posts, so here goes my reply.
Please don't.
You don't understand hackernews. That's a feature of this website to slow down rambling discussions. In deep discussions take your time to answer. After a certain amount of time you can reply.
It's all in the Lisp code for this website.
> What's an incorrect program going to do about its own incorrectness? Rewrite itself?
There are a lot of options:
* inform the next system to take over some functions
* remove some features, while they are faulty, until patches are loaded in
* use alternative implementations
Look at actual Flight Control Software. That's what it does and what it is designed.
Similar for other control systems, for example in power plants. They also need independent implementations controlling each other.
> Yeah, well, that's in itself precisely what's so terrible.
It's the reality. That's why mission critical systems don't believe that even verified software has no bugs.
> Give me a compelling reason to design programs in an object-oriented way. Just to be clear, I don't find the ability to subvert existing definitions particularly attractive, because it undermines my ultimate goal to actually prove things about my programs.
Probably there are other software developers with other requirements. A large share of contemporary software is written in an object-oriented way.
> And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later.
I would just define the classes/objects/functions first and use them later. One can also develop static MOPs.
Nobody forces me to modify a running system, though it usually is a huge time saver - that's why for example most web browsers provides an implementation of Javascript - a dynamic object-oriented language.
> Nobody forces me to modify a running system, though it usually is a huge time saver
I won't dispute this fact, but it's not a principled way to work. The principled thing is to have two separate phases, one for designing abstractions, another for using them. You can't prove anything definitively about things that are eternally open for modification.
---
@lispm, I have reply here because I'm temporarily unable to make new posts.
> A large share of contemporary software is written in an object-oriented way.
Sure, but how does that contradict my original assertion that Racket's mechanisms for extending and redefining the language are more principled than either Common Lisp's or Smalltalk's?
---
> Could it be that you just don't like/use/need/want the object-oriented ways to extend those languages and thus these mechanisms are not 'principled'?
You're right that there's an aesthetic component: I don't have much taste for object-orientation. But this isn't just me being close-minded: I would take object-orientation far more seriously if someone could provide an interpretation of object-oriented programs as mathematical objects with nice properties.
> How are Racket's mechanisms for extending and redefining the language more principled
Racket's macro system is based on a theory of how to macro-expand in a capture-avoiding way, ruling out by construction errors that are very difficult to debug when doing similar things in Common Lisp. And macro systems are more principled than MOPs in that macros are purely static devices: you (re)define the language first, and you use it later.
> Especially since Racket provides some of that, too -> Swindle.
Object-orientation in Racket is completely opt-in. You don't have to use it if you don't want to, and, in fact, I just don't use it...
> Is the CLOS MOP not principled? Why?
... OTOH, in Common Lisp it's far more pervasive. Everything is an object and has a class, and classes can be tampered with in arbitrary ways, precisely using the MOP. How can then you prove anything interesting about how instances of a class will behave under all circumstances?
The essence of abstraction is to ignore implementation details, and concentrate on, well, abstract properties. A MOP achieves the opposite thing: it makes all implementation details available everywhere, complicating the problem of abstraction enforcement.