But it was you who introduced the law of non-contradiction in this conversation, then wrote a program that had nothing to do with it, and when called out you started with this nonsense about physics, cubits and what it means for "you" to be "you" and other unrelated topics. Either your program is about the LNC or it isn't, and if it isn't (as it turned out to be the case) why bring it up in the first place.
The CPU thing is nonsense and I don't see what I have to answer about it. In contrast, the Expression Problem is directly related to your initial assertion about extensibility, but instead you talked about something else. Getters/setters aren't about extensibility, by the way.
Finally, Haskell excels at IO, network, API calls, etc. People write distributed sysyems in Haskell -- why on earth would you think otherwise?
> It's so pedestrian, it's probably your home page.
I don't understand this. It reads like an attempt at trolling but I don't understand what it means. In which sense should I be offended? Google is my home page, does that help you somewhat?
I did do that. With the intent to determine whether the discussion is about denotational semantics (theory) or operational semantics (practice).
In theory there is no difference between theory and practice, but in practice there is...
>Either your program is about the LNC or it isn't
>The CPU thing is nonsense and I don't see what I have to answer about it
Until you decide on the 'CPU thing', I don't see how you can possibly decide whether ANY program is about the LNC or not.
Denotationally - it clearly is about the LNC as defined. It expresses precisely "P ∧ ¬P".
Operationally - it is about the LNC IF and only IF "P ∧ ¬P" can be evaluated simultaneously.
If your notion of "simultaneously" doesn't mean "evaluated in a single CPU cycle/instruction" then explain what you mean?
The leaky abstraction of CPU time is somewhat inconvenient to functional purists. As is the fact that strongly-typed Haskell reduces to untyped machine code.
Somewhere between typed and untyped Lambda calculus lies the choice of "right tool for the job".
>Getters/setters aren't about extensibility, by the way.
Would this be a good time to call out the fact that all you have been doing is Socratizing? Saying that X is not Y, says nothing about Y.
You asked me to give you an example, and trivially extending an object-model to support new fields in unstructured (read: untyped) data is not good enough for you.
If you think 'extensibility' has some universal/objective /theoretical meaning devoid of practical context, then go ahead and tell us what that meaning is.
> Finally, Haskell excels at....
How are you measuring that and against what objective standard for 'excellence' (or lack thereof)?
>People write distributed sysyems in Haskell.
People write (and have written) distributed systems in all sorts of languages.
In what measurable way is Haskell better?
>Google is my home page, does that help you somewhat?
Only in so far as Google doesn't use Haskell.
If Haskell offers value at that scale/complexity, then I imagine "building a better Google with Haskell" is a great idea for a startup?
Q.E.D you are admitting that non-contradiction it's an axiom of language and not an actual law. As in law of physics.
I don't expect you to answer my question re: the number of CPU cycles you consider as being a "simultaneous" evaluation of p ∧ ¬p least you had to admit the LNC is incoherent ;)
> That's chicanery on your part. Usually done by people who know they are losing the argument ;)
Isn't this what somebody who knows they are losing the argument would say ? ;) But if you are in it to win arguments - have a noddie badge. You win The Internet.
My problem-space is the CAP theorem. Global-scale distributed systems. Where most of the complexity is 'side effects'. But we call it network IO/communication/persistence/API calls etc.
Haskell would add zero value, because the bugs are rarely about type errors, and predominantly about Byzantine failures.
It's so pedestrian, it's probably your home page.