clacke has quit [Read error: Connection reset by peer]
wineroots has quit [Remote host closed the connection]
mtsd has joined #picolisp
<kluk>
beneroth: at around 24:00 here: https://www.youtube.com/watch?v=9_iYlp8smc8 you will see the Categorical proof that OOP is not method(object, args) but instead object(method, args). I don't mean implementation-wise; if your language has methods taking a "self" argument, what is actually happening is still what I am saying: the live object had to first be evaluated to retrieve its virtual-table of methods; then the right method was
<kluk>
selected; then it was called and passed the object as the first argument; you cannot resolve which method to choose without first resolving the object to its v-table.
<kluk>
beneroth: His extract (Store p f) = f p amounts to extract (Class method object) = object method thereby proving my point that the method is an argument to the object.
<kluk>
This is something misunderstood by the vast majority of OOP programmers as they usually lack foundations.
<Regenaxer>
In PicoLisp it is (meth> Object Arg ...)
<Regenaxer>
following the SmallTalk way of sending messages to objects
<kluk>
Regenaxer: read what I said about implementation-wise. If you are not first resolving the v-table from the Object to know which method to call, you have not implemented objects.
<Regenaxer>
There is no v-table in Pil
<kluk>
in no language is it really method(object, args), not even in PicoLisp, unless it does not implement OOP
<kluk>
okay, then that is not OOP, or am I mistaken?
<Regenaxer>
I think it is pure OOP
<Regenaxer>
much more pure than in Java or C++ imho
<kluk>
how do you know which "talk" method to call if you don't yet know if my object is a cat (to meow) or a dog (to bark) without first resolving the object to its list-of-methods ?
<Regenaxer>
You should study PicoLisp first
<Regenaxer>
The message code sends the symbol to the object
<Regenaxer>
(msg> Obj)
<kluk>
exactly.
<kluk>
That is my point
<kluk>
Therefore: Object(method)
<Regenaxer>
The object has a tree of classes and suqerclasses
<Regenaxer>
no
<kluk>
the symbol was sent to the object.
<Regenaxer>
*method* executes
<Regenaxer>
yes
<kluk>
how do you know which method? you don't know if I have a cat or a dog
<Regenaxer>
so it executes itself
<Regenaxer>
it searches the inheritance tree
<kluk>
there you go. so that is the "object" in the coalgebra.
<kluk>
refer to the video at 24:00
<Regenaxer>
I have no time to watch videos
<Regenaxer>
and I don't use youtube
<kluk>
The point is: OOP is always this shape: SomethingThatHasAccessToTheMethodList(which_method_I_want_to_call, arguments)
<kluk>
which is not this shape: method(object, args)
<kluk>
It does not matter that the object is data for Category Theory
<kluk>
everything is data in CT
<kluk>
you are focusing on the wrong level of the conversation
<Regenaxer>
in lisp the CAR executes
<Regenaxer>
There is no sense in (otject message)
<Regenaxer>
because object is not a function
<Regenaxer>
So what is your point?
<Regenaxer>
or problem?
<kluk>
Yes there is sense in (object message), because objects are dynamic, and when I have one, I can't first pick the method "makeSound" out of nowhere, I have to make a #makeSound symbol and send it as an argument to the existing live in-memory Object so that it can return to me the "function that stands for that method" so I can then call it with the arguments.
<kluk>
"objects are not a function" yes they are in CT.
<kluk>
they are a function from X to F(X), which is a coalgebra
<kluk>
with FP the functor is on the negative side
<kluk>
with OOP it is on the positive side
<kluk>
hence the fundamental difference (duality, really) between algebra and coalgebra
<Regenaxer>
You addressed beneroth, and I did not read your conversation, so I don't understand what the problem gs
<kluk>
It is a very subtle point to understand as I can see.
<Regenaxer>
is
<Regenaxer>
Why should we understand it?
<Regenaxer>
what problem?
<Regenaxer>
You say syntax does not matter
<Regenaxer>
so (msg> obj) is ok
<kluk>
The problem is without this understanding, we have the problem we have today, with people believing the two paradigms can work together, and we get monsters like Scala and everything else we have today.
<Regenaxer>
PicoLisp is no monster
<Regenaxer>
so it does it right, no?
<Regenaxer>
Have you ever tried to understand it?
<Regenaxer>
OOP is extremely simple in pil
<Regenaxer>
because it is straight to the point
<Regenaxer>
send message
<Regenaxer>
the combination of msg and obj fires
<Regenaxer>
no matter of syntyx
<Regenaxer>
syntax
<Regenaxer>
implementation-wise it is that the message searches for itself
<Regenaxer>
message is the action, object is data happening to know what to do with the message
<Regenaxer>
So code in the classes finally gets executed
<kluk>
That is an entire tangent. I have no problem with picolisp. Some things are naturally coalgebras (OOP objects), for instance lenses. However, most things are (or want to be) algebras. Lisp is an algebraic (at least, reduction-based) language. It's hard for it to "go wrong" even when it adopts objects. The point is very few things are naturally represented as objects.
<kluk>
Look at OCaml. One lesson I learned from them: it's pointless to put OO features in a reduction-based language - no serious person will use it.
<kluk>
Whenever I need a coalgebra I had rather roll my own with closures than trust implicit mechanics from the compiler writer.
<kluk>
See lenses, they don't use an OOP library to implement it, they just code the barebones algebra, the minimum needed structure.
<Regenaxer>
No idea what you are talking about, sorry
<kluk>
The structure that OOP brings to each Object is coalgebra plus a ton of other stuff.
<kluk>
Where did I lose you?
<Regenaxer>
Since early on, cause I did not watch the vid or read the links, sorry ;)
<Regenaxer>
I see no problem atm
<Regenaxer>
I know that I need OOP in Pil a lot
<Regenaxer>
and that it is extremely helpful
<Regenaxer>
so why bother?
<kluk>
There is definitely a problem somewhere if you still think that method(object, arguments) is how OOP works anywhere. There is no way to get the method without asking the object.
<kluk>
It's about having a clear understanding of things so you know when you actually need an object (very seldom).
<Regenaxer>
yes, but msg> *asks* the object
<Regenaxer>
I don't need the object, I need classes
<kluk>
"ask" is not a lambda-calculus concept. Does message get passed to the object? Does it get applied to the object?
<Regenaxer>
to get lazy binding of behavior
<kluk>
late binding, yes
<Regenaxer>
Please see first what Pil does befor judging
<kluk>
so you need to sort of use the object as a function.. because you need to ask it "what is the real method that corresponds to this method name?"
<Regenaxer>
it is a pil channel here
<Regenaxer>
no, object is data
<Regenaxer>
the message searches data, the inheritance tree
<Regenaxer>
the object does not do anything
<kluk>
so the message is a function?
<Regenaxer>
the classes and superclasses have data
<Regenaxer>
data is code
<Regenaxer>
yes, message is a function
<Regenaxer>
all messages have the same function code
<Regenaxer>
it exists only once in the system
<Regenaxer>
it is 'meth'
<kluk>
so what if the object does not understand that message? then what was that method you called, really? what was it?
<Regenaxer>
then 'meth' throws an error
<Regenaxer>
(doc 'meth)
<kluk>
okay, so it's "meth" which is the function and not "the message" as you implied. "the message" would be Bark or Meow
<kluk>
you are being loose with language
<Regenaxer>
'meth' and 'msg>' have the same code
<Regenaxer>
also 'foo>' and 'bar>'
<Regenaxer>
the ">" is just a naming convention
<kluk>
the "meow" part, specifically, for a cat object, the "meow" part is what in picolisp? a symbol? a function?
<Regenaxer>
If you write (meow> Animal)
<Regenaxer>
then Animal is some object
<kluk>
that desugars into meth> meow Animal or something? let's talk desugared only
<Regenaxer>
some of its classes may have (dm meow> () ..)
<Regenaxer>
desugars?
<Regenaxer>
without sugar?
<Regenaxer>
syntactic sugar, ok
<Regenaxer>
So, no, not "meth> meow Animal"
<kluk>
in your example, meow> is not "the function that prints meow", it is *instead* "the function that looks up to see if the object it was passed implements a method called meow that can then be retrieved and called"
<Regenaxer>
exactly!
<kluk>
exactly, so we agree, you are just not familiar with CT terminology.
<Regenaxer>
yes, no idea what "CT" means
<kluk>
What you just agreed to is: meow --Lookup--> method(self) : ( inputs -> (outputs, objects) )
<kluk>
Category Theory
<Regenaxer>
ah, ok
<Regenaxer>
With "inputs" you mean arguments I presume
<kluk>
so now I hope you can understand... in FP if I did (meow myCat), meow is "the function that prints meow" whereas in OOP even though you may think myCat.meow() is equivalent to meow(myCat, ()) , what actually is true is that that "meow" there that you are looking at is not "the function that prints meow" but instead "the function that looks up to see if the object it was passed implements a method called meow that can then be retrieved and
<kluk>
called"
<kluk>
Do you get it now?
<kluk>
yes inputs are arguments
<Regenaxer>
no
<kluk>
Therefore, to say that OOP is just method(object, args) is to forget that there is a huge infrastructure supporting that method being found, and that that method depends on the object, which is usually not the case for arguments being passed to functions.
<Regenaxer>
"the function that prints meow" is still 'meow>'
<Regenaxer>
it is the only thing executed
<Regenaxer>
it interpretes code in the classes
<kluk>
if meow> is "the function that prints meow" then what happens when I pass it an object that does not meow?
<Regenaxer>
then meow> does not know what to do
<Regenaxer>
and complains
<kluk>
therefore.... meow> is *not* "the function that prints meow"
<kluk>
as it depends on the object.
<Regenaxer>
yes, depends on *data*
<kluk>
unliked in FP where args don't depend on the function.
<kluk>
Doesn't matter. Depends on something.
<kluk>
That's the point.
<Regenaxer>
no
<Regenaxer>
nonsense
<kluk>
Yes indeed :)
<kluk>
everything is data.
<Regenaxer>
yep
<Regenaxer>
Again, what is your problem?
<kluk>
Regenaxer: I like you as a person and I like what you did with picolisp. I have no problem. This was the end of a discussion I couldn't finish with beneroth. I made my point and hopefully he will be able to appreciate it.
<Regenaxer>
I did not see that discussion. Was it in this channel?
<kluk>
Yes it was right here, I think the first or second day we all migrated to libera.
<Regenaxer>
ok
<Regenaxer>
I was busy
<kluk>
So if you did not use CT to guide your decisions, what was the paradigm or philosophy you had in mind that allowed you to reach such a minimalist language that is nevertheless so powerful?
<kluk>
CT is all about doing a lot with very little.
<Regenaxer>
Perhaps just because I did it bottom up, starting with a minimal set concepts
<Regenaxer>
Everything else followed naturally from those
<Regenaxer>
like how a message behaves
<kluk>
That makes me chuckle
<Regenaxer>
:)
<kluk>
doing it bottom up and letting everything naturally follow, is sort of the textbook definition of an Algebra :)
<Regenaxer>
indeed
<Regenaxer>
axioms
<kluk>
Right, and I am stuck thinking that way, which is why it's so hard to work with the industry full of OOP'ers doing things in an opposite/dual coalgebraic way
<kluk>
That's why I am attract to things like Picolisp
<kluk>
among other algebras
<Regenaxer>
I'm also shocked by what they call OOP in most mainstream languages
<kluk>
(probably also why Haskellers can understand monads no problem, but have trouble understanding lenses, as monads are algebraic but lenses are coalgebraic)
<kluk>
Well, OOP has been stripped of its definitions as they went along attaching SOLID, GRASP, Agile, TDD, OOA, RUP, XP, DSL, GoF, DRY, CQRS
<kluk>
What is even the definition of OOP? Is there an official one? I have watched many Uncle Bob videos and I know the usual ones...
<kluk>
But is there one not based on opinions?
<Regenaxer>
you are right
<kluk>
"The area of coalgebra is still in its infancy"
<Regenaxer>
So lets not call OOP what Pil does. It is just objects
<Regenaxer>
not "oriented"
<kluk>
It's folly to use OOP in the industry when its (co)algebra is "still in its infancy" according to textbooks on Coalgebra.
<kluk>
Regenaxer: let's probe it this way:
<kluk>
is OOP the only way to do polymorphism? or do you offer an algebraic way, for example, type classes a la Haskell and Purescript?
<kluk>
(in picolisp)
<kluk>
I am asking in Picolisp now.
<Regenaxer>
interesting question
<kluk>
It's about how you language allows solving the Expression Problem
<Regenaxer>
straight it is only with class inheritance
<Regenaxer>
but as you can easily manipulate code ...
<kluk>
well no... I know I can easily manipulate code in lisp to create whatever I want :)
<kluk>
but it's about the facilities you give
<Regenaxer>
I do it often with 'assoc' lists
<kluk>
so it seems you give more facilities for coalgebraic (OOP-based) polymorphism than to algebraic polymorphism
<kluk>
so that is a bias towards OOP
<kluk>
Regenaxer: yes, you may do it with assoc lists, but you could also have left us to make our own objects out of let-over-lambdas (closures)
<kluk>
so again, it's about the facilities the language comes with
<kluk>
what it makes comfortable.
<Regenaxer>
Pragmatism
<kluk>
How so?
<kluk>
What is more pragmatic about the way OOP does polymorphism?
<Regenaxer>
Even more often than defining methods in classes, I store code directly in other structures, typically in GUI
<Regenaxer>
'(doSomething arg)' is stored in the form
<Regenaxer>
in the button object
<kluk>
You may consider those semantically just "bindings", no need to call them "storing" :)
<Regenaxer>
There is nothing bound
<Regenaxer>
I see it as stored in other nested structures
<Regenaxer>
to be executed on some event
<Regenaxer>
"binding" I use for symbol values
<Regenaxer>
terminology differs
<Regenaxer>
Same happens with confusing "scope" and "binding"
<kluk>
Technically that code works in a language without mutable (storable) boxes. So that is why technically they may be considered bindings (associating a name to a value). Even less than that, I can imagine a Button constructor that takes a function from void to void. So it would work even in a language without bindings (lambda-calculus).
<Regenaxer>
yes, can be done anywhere
<kluk>
Did you look into what FP languages were doing when you were implementing picolisp?
<Regenaxer>
I only saw other Lisps
<Regenaxer>
I started in 1983
<kluk>
Really? That is very interesting. So where did you get the idea for embedding a database into the language?
<Regenaxer>
with predecessors of PicoLisp
<kluk>
Sorry, I didn't mean to interrupt, please go on.
<Regenaxer>
the DB came later
<kluk>
I find this stuff fascinating.
<Regenaxer>
around 1995
<Regenaxer>
The DB is just making symbols persistent
<kluk>
So from 1983 to 1995 picolisp did not have an embedded database, but did it have all the web facilities already? What made it stand out, if no DB?
<Regenaxer>
so it is also a consequence of existing concepts
<Regenaxer>
At that time it used native GUIs, no web yet
<kluk>
So you yourself had the idea of making the db just from extrapolating the concept of symbols? You were not inspired by another language with an embedded db?
<Regenaxer>
right
<kluk>
Regenaxer: Really, native GUIs? Wasn't tcl/tk around then? I hope you did not recreate a lot of the work those guys did.
<Regenaxer>
I was annoyed by interfacing relational DBs
<Regenaxer>
The first version of Pil was on a Mac 512
<kluk>
Regenaxer: my kudos, thinking of making variables persistent as you can see by looking around you is not something that comes easy to people.
<Regenaxer>
using the Mac toolbox
<Regenaxer>
hmm, I think it was a natural consequence
<kluk>
I totally understand being annoyed with RDBs
<kluk>
I cannot stand them
<kluk>
Regenaxer: Yeah I think it was a "natural" (deductive) consequence too :)
<kluk>
but most people are not algebraic thinkers like you and me so they didn't think of this
<kluk>
They think top-down
<Regenaxer>
right
<Regenaxer>
and want just things to work quickly
<Regenaxer>
Sorry, I must continue here. Lets see what beneroth says, he has a different vieewing angle
<kluk>
Thank you for the conversation
<Regenaxer>
He can better compare with existing systems than me
<Regenaxer>
Welcome, let's continue sometimes :)
<kluk>
Regenaxer: yes, let's :)
rob_w has joined #picolisp
clacke has joined #picolisp
<beneroth>
hi friends :(
<beneroth>
:)
<Regenaxer>
Cheers beneroth! :)
<beneroth>
Regenaxer, kluk, nice much exciting stuff to read for me!
<beneroth>
unfortunately I'm busy, I will read up asap :)
<beneroth>
cheers Regenaxer o/
<Regenaxer>
No hurry!
<beneroth>
in any case it's logged again thx to aw- :)
<Regenaxer>
yep
<kluk>
beneroth: no hurry, take your time
<Regenaxer>
I think we should discuss OOP in next PilCon
<beneroth>
Regenaxer, OOP in picolisp? yes. OOP in general: better not xD
<beneroth>
that would not be useful for most participants, I'd guess
<Regenaxer>
Right
<Regenaxer>
We could explain the PicoLisp view on it
<beneroth>
picolisp OOP is far away from mainstream OOP though, there is a lot to explain
<beneroth>
T
<Regenaxer>
I think I have clear rules when to use it and when not
<beneroth>
and your solution for the diamond problem is just the nicest... unbelievable that other clever language designers didn't came to that solution
<beneroth>
Regenaxer, interesting :)
<beneroth>
I guess I have clear rules too, but I'm not sure that I can formulate it into a good wording
<Regenaxer>
Let's brainstorm next time
<beneroth>
T
<Regenaxer>
It is definitely not good if languages force one to use it always
<beneroth>
fully agree. java fashion OOP was dumb from the very start.
<beneroth>
dunno how it is in Erlang.. I'd guess Erlang & Co got it pretty right
<beneroth>
but there an "object" is basically a process, afaik
<kluk>
"Very much in the same spirit as I thought about it back in the 60s." - Alan Kay, of Erlang with respect to the original meaning of OO
rob_w has quit [Quit: Leaving]
mtsd has joined #picolisp
clacke has quit [Remote host closed the connection]
wineroots has quit [Remote host closed the connection]
wineroots has joined #picolisp
olaf_h has joined #picolisp
brainfunnel has joined #picolisp
<beneroth>
kluk, yeah I knew about that, saw this :)
<beneroth>
what a day eh.. still couldn't read your discussion.
olaf_h has quit [Quit: Leaving]
brainfunnel has quit [Quit: thanks, bye!]
* beneroth
reading now
<beneroth>
<Regenaxer> There is no v-table in Pil
<beneroth>
hm... maybe in a certain way the list of methods in the class symbol could be seen as a v-table, in a way? *pondering
<Regenaxer>
hmm, you see the assoc lists as table, yes
<Regenaxer>
I think I choked on the name
<beneroth>
<kluk> Yes there is sense in (object message), because objects are dynamic, and when I have one, I can't first pick the method "makeSound" out of nowhere, I have to make a #makeSound symbol and send it as an argument to the existing live in-memory Object so that it can return to me the "function that stands for that method"
<Regenaxer>
"v" is for "virtual", right?
<beneroth>
Regenaxer, v-table is the name in C++
<Regenaxer>
yes, I know
<beneroth>
yeah, for "virtual methods". I think you can also do methods which have no lookup
<Regenaxer>
statically compiled
<Regenaxer>
"virtual" makes no sense in pil
<beneroth>
about the last @kluk message I quoted: kluk, this sounds like you want to point out that this is a difference between 'object' and 'function' - which is not true in picolisp as code is data and everything is dynamic...so even for functions in picolisp the vm first looks up the function name symbol to find the method body
<beneroth>
which is also happening in compiled language, but there doing compiling, not during execution
<beneroth>
the deference/lookup already happened, I would say
<beneroth>
Regenaxer, T
<beneroth>
in pil everything is virtual, nothing is static except of the strongly typed fundamental 3 datatypes
<Regenaxer>
I won't call it virtual
<Regenaxer>
Dynamic is better
<beneroth>
<kluk> The problem is without this understanding, we have the problem we have today, with people believing the two paradigms can work together, and we get monsters like Scala and everything else we have today.
<beneroth>
I don't know scala
<beneroth>
but that statement just sounds completely wrong to me, at this moment...
<beneroth>
naturally it triggered Regenaxer :))
<Regenaxer>
yes, monster
<Regenaxer>
But fact is that C++ and Java became monsters
<Regenaxer>
Instead of re-using code, they blew up
<beneroth>
T
<beneroth>
well C++ you can use differently, C++ covers like.. nearly everything. probably you can easily implement a elegant lisp with just a bit of templating or so...
<beneroth>
but java is completely lost, a failed attempt to become the middleman (and cash in) between hardware and any application
<beneroth>
I fail to see any progress that java brought to programming language science
<Regenaxer>
me too
<beneroth>
hm
<beneroth>
I believe java is implemented in c++ :D
<beneroth>
C++ is great to write big VM's, I guess
<beneroth>
<Regenaxer> message is the action, object is data happening to know what to do with the message
<beneroth>
yes Regenaxer, I agree. I believe is true to Alan Kays idea of OOP.
<Regenaxer>
T, the only code that runs is the message
<Regenaxer>
it interprets data in the object
<beneroth>
the method handling in picolisp is basically the GoF pattern "chain of responsibility".
<beneroth>
I don't think you can say that about the C++ v-table & co
<beneroth>
Regenaxer, yeah you are right on the software level, kluk was speaking about the entirely abstract semantic/logical level, I think he is right. But I'm not so sure if it really matters.
* beneroth
continues reading & commenting
<beneroth>
<kluk> the "meow" part, specifically, for a cat object, the "meow" part is what in picolisp? a symbol? a function?
<beneroth>
it is a symbol
<beneroth>
nothing more
<Regenaxer>
it is a symbol with a function definition
<beneroth>
a key as in key/value, in a sense
<Regenaxer>
Yes, but it *is* defined
<Regenaxer>
(meow> Animal)
<Regenaxer>
(getd 'meow>) -> <num>
<Regenaxer>
But this is implementation
<Regenaxer>
kluk wanted not to look at impl.
<Regenaxer>
In any case the action is in meow>
<Regenaxer>
You can do (send 'meow> Obj)
<beneroth>
T
<Regenaxer>
then 'meow>' may be undefined
<beneroth>
where is the <num> pointing at? that part of the implementation I don't get right now
<Regenaxer>
It points to code
<Regenaxer>
llvm-ir code
<beneroth>
ah
<beneroth>
makes sense
<Regenaxer>
same as (getd 'meth)
<Regenaxer>
'meth' is just a container to hold that pointer
<beneroth>
I see. I think kluk will love this xD
<Regenaxer>
good :)
<beneroth>
so dm in a way is defining a method and creating a global function of the same name
<beneroth>
hehehe
<beneroth>
he will love that xD
<Regenaxer>
a global function with the same *def*
<Regenaxer>
(setq meow> meth)
<beneroth>
<kluk> the "meow" part, specifically, for a cat object, the "meow" part is what in picolisp? a symbol? a function?
<beneroth>
so I'm wrong
<beneroth>
it becomes a function
<Regenaxer>
yes
<beneroth>
though a function in picolisp is a symbol pointing to the function body
<Regenaxer>
T
<beneroth>
so in picolisp the real answer to this question of kluk would be: MU
<beneroth>
:))
<Regenaxer>
Neither yes nor not yes ;)
<beneroth>
<Regenaxer> yes, message is a function
<beneroth>
<Regenaxer> all messages have the same function code
<beneroth>
<Regenaxer> it exists only once in the system
<beneroth>
T
<beneroth>
I see now
<beneroth>
maybe we must make kluk aware that a function in picolisp can have many names :))
<Regenaxer>
In any case, the action is not in the object. (msg> Obj) is just syntactic sugar for (send 'msg> Obj)
<Regenaxer>
So 'send' is the action
<beneroth>
T
<Regenaxer>
'meth' just sends itself
<beneroth>
that I'm fully aware of :)
<Regenaxer>
yes
<beneroth>
yeah that bit was new to me
<beneroth>
now I grokked the full OOP system of pil
<Regenaxer>
:)
<beneroth>
well new.. I knew I didn't had the whole picture. :)
<Regenaxer>
It is easier than it looks like :)
<Regenaxer>
simpler
<beneroth>
<kluk> "the function that looks up to see if the object it was passed implements a method called meow that can then be retrieved and
<beneroth>
well no method hiding without that
<beneroth>
having this mechanism is the whole point of OOP
<beneroth>
yes we are fully aware that mainstream implementators of OOP didn't got that.. or at least not their users
<Regenaxer>
Mainstream OOPs seem not to want to improve the programmer's power, but only protect them from themselves
<beneroth>
I believe I can speak also for Regenaxer in stating that a term means what their creator meant by it, not what the masses misunderstood and repeated without learning (at least when the creator is still alive and not many generations gen-drifting with the terminology, which is the fate of all terminology)
<Regenaxer>
right
<beneroth>
<Regenaxer> Mainstream OOPs seem not to want to improve the programmer's power, but only protect them from themselves
<beneroth>
YES
<beneroth>
that is the point. that is ON PURPOSE
<Regenaxer>
yes
<beneroth>
the designes just don't tell these programmers, because these programmers are full of themselves anyway, they would not like this punch :)
<beneroth>
but this is the full purpose and complete legitimate point and the reason why this languages are popular with bigcorps. because this way the bigcorps can manage. they cannot manage overly smart programmers.
<beneroth>
and they cannot risk to depend on them, that is the important point
<beneroth>
and with the absolute numbers of code-monkeys vs. programmers this is an absolute reasonable strategy
<beneroth>
arguing with theory against this is missing the whole point :)
<beneroth>
(CS theory I mean)
<Regenaxer>
Yes
<beneroth>
<Regenaxer> I did not see that discussion. Was it in this channel?
<beneroth>
I believe this discussion was before you joined, Regenaxer
<Regenaxer>
I see
<beneroth>
I believe maybe only aw- saw it, if even
<beneroth>
and there was no logger then
<Regenaxer>
T
<beneroth>
kluk should have been aware instead of going into a rabble with you :D
<Regenaxer>
He did not address me
<Regenaxer>
I just commented his question to you
<beneroth>
T
<beneroth>
right
<beneroth>
<kluk> Right, and I am stuck thinking that way, which is why it's so hard to work with the industry full of OOP'ers doing things in an opposite/dual coalgebraic way
<beneroth>
well
<Regenaxer>
Sorry, interrupt here, some duty
<Regenaxer>
bbl
<kluk>
beneroth: I will start reading and answering in some half an hour :)
<beneroth>
because mainstream OOP is that way absolutely purposefully, see my comment above. it was never the goal of SUN to design a language for simple efficient programming. it was their goal to have a nice VM-middleware they can make money with, and to design a language which can be used to effectively produce software even as a bigcorp which has many programmers - and according to the Sturgeon's law ("90% of everything is crap") most of those programmers would
<beneroth>
not be overly clever or disciplined (I believe this is the bigger problem that biological brain) and would lose themselves and not have any effective output
<beneroth>
kluk, perfect :)
<beneroth>
lets do a bit async here :)
<beneroth>
<kluk> What is even the definition of OOP? Is there an official one? I have watched many Uncle Bob videos and I know the usual ones...
<beneroth>
a better naming would be "message oriented programming"
<kluk>
beneroth: Even if we consider Erlang = OO (which I could, according to Alan Kay) it's still a coalgebra. That is why implementation does not matter.
<kluk>
What matters is that the first "call" needs to resolve to "a list of methods for this object"
<beneroth>
"I wanted to get rid of data." Alan Kay
<beneroth>
"
<beneroth>
using this understanding to make much nicer and smaller and more
<beneroth>
The second phase of this was to finally understand LISP and then
<beneroth>
powerful and more late bound understructures."
<kluk>
beneroth: yes, what he means by that is naked data. He wanted to encapsulate all data points under actions/behaviors so that they would produce another object that means a value (for instance in Smalltalk a number is an object again)
<beneroth>
here is the core definition
<beneroth>
"
<beneroth>
hiding of state-process, and extreme late-binding of all things. It
<beneroth>
can be done in Smalltalk and in LISP. There are possibly other
<beneroth>
OOP to me means only messaging, local retention and protection and
<beneroth>
systems in which this is possible, but I'm not aware of them."
<kluk>
So that ties it perfectly with the definition of Coalgebra: X -> F(X)
<kluk>
(sorry I still haven't had time to read your previous messages, will do soon)
<beneroth>
yeah I believe your definitions are too strict
<kluk>
beneroth: these are the definitions of Algebra/Coalgebra. On the contrary, they are too generalized.
<kluk>
Every object you come up with from any OO language will be a coalgebra.
<beneroth>
it depends about what ones want to speak
<kluk>
what ones?
<beneroth>
<kluk> is OOP the only way to do polymorphism? or do you offer an algebraic way, for example, type classes a la Haskell and Purescript?
<beneroth>
I don't think so in picolisp. picolisp everything is duck typed beside the fundamental 3 types. so everything is polymorph to a extreme degree.
<kluk>
How is that related to the question? I am having a hard time following.
<beneroth>
kluk, I'm still reading and commenting on your previous messages
<beneroth>
you are confusing the timeline now for both of us :)
<kluk>
beneroth: cool, we're both catching up, in opposite ways
<beneroth>
yeah start at the top dude :D
<beneroth>
else it becomes a time-traveler mess :D
<beneroth>
then we exist multiple times and those us debate multiple arguments at the same time cross each other :D
<kluk>
okay I will :)
<kluk>
in 5 minutes!
<beneroth>
<kluk> Regenaxer: my kudos, thinking of making variables persistent as you can see by looking around you is not something that comes easy to people.
<beneroth>
WTF
<beneroth>
I have a hard time seeing that. I mean... persistence IS nothing else than "serialization"
<Regenaxer>
ret
* beneroth
learned about storing stuff from gamedev C++ book which first file things were like how to dump a object from RAM to file and load it again and how this could cause problems when loading on another architecture/OS with another RAM layout
<beneroth>
conceptually there is no difference between RAM and disk storage, just some different nonfunctional properties ("nonfunctional" in the requirement sense, not FP/etc sense)
<beneroth>
<kluk> I totally understand being annoyed with RDBs
<beneroth>
<kluk> I cannot stand them
<beneroth>
just think of RDB's as big arrays full of arrays. they're nothing else.
<beneroth>
that is why they feel so clunky
<beneroth>
ok, your turn kluk, I want to see where we agree/disagree now before going into evaluation of consequences/conclusions ;-)
* beneroth
is semi-afk but available
<kluk>
okay, I will start now
<beneroth>
have fun :D
<kluk>
Thanks! I feel we're talking through one shared walkie-talkie, so it's already fun
<beneroth>
haha, T
<beneroth>
elegant analogy
<beneroth>
<beneroth> <kluk> Right, and I am stuck thinking that way, which is why it's so hard to work with the industry full of OOP'ers doing things in an opposite/dual coalgebraic way
<beneroth>
on second reading...kluk what would you say about social organisation.. it's often top-down (if not always, or as soon as it is in an equilibrium)... at least bigcorps are hierarchical and so surely top-down ;-)
<beneroth>
THAT is way they use co-algebraic programming languages.. it's their natural tendency how to organize things, this is the way they know how to organize (and often very successful so).
<beneroth>
that is also what creates all these conflicts between clients/managers and engineers (be it machine engineers or programmers)
<beneroth>
so social design patterns applied to technical stuff. which doesn't fit well, but the alternative would work even less
<beneroth>
because the alternative has a weaker interface to the big human social structures
<beneroth>
therefore you can only have the alternative in either small communities / small companies / sheltered research labs in bigcorps.
<beneroth>
what are your thoughts on that?
* beneroth
keeping shut again now, if I can
<Regenaxer>
:)
<beneroth>
I'd guess you agree with my point here, Regenaxer? ;-)
<Regenaxer>
The one about keeping shut? ;)
<beneroth>
hahaha
<beneroth>
you know I cannot
<beneroth>
I meant the other
<beneroth>
this might be an interesting to discuss with Rudy (social/technical org patterns) (if he even likes to spend time on such discussions)
<Regenaxer>
yes, he knows all the big ones
<Regenaxer>
But like we both he spends a quite independent life
<Regenaxer>
For us it is easy, we are not tied up in those structures
<beneroth>
T
<beneroth>
and we must not be smug about people who are not so lucky
<Regenaxer>
yeah
<beneroth>
yes we've very consciously and laboriously have chosen this path, and we also had to sacrifice things for that ...blabla.. but still :)
<kluk>
<beneroth>hm... maybe in a certain way the list of methods in the class symbol could be seen as a v-table, in a way? *pondering ||-> definitely; from a categorical point of view they are the same.
<kluk>
<Regenaxer>"virtual" makes no sense in pil ||-> In computing, "virtual" usually means "not physically existing as such but made by software to appear to do so"; so as part of the OO definition I can say that methods need to be virtual; that is, they at first seem to be there, but then their actual presence needs to be looked up somewhere else.
<kluk>
<beneroth> this sounds like you want to point out that this is a difference between 'object' and 'function' - which is not true in picolisp as code is data and everything is dynamic...so even for functions in picolisp the vm first looks up the function name symbol to find the method body
<kluk>
Right, I do want to point out that difference; even if functions need their names looked up, that is still one fewer indirection step than OO: OO will need to first resolve the object to its v-table, then have "meth>" looked up which is the step that is equivalent to the function name being looked up; so this part happens "later" in OO whereas it happens "earlier" in FP; this makes all the difference; "later" and "earlier" are with respect
<kluk>
to the arrows in F(X) -> X and X -> F(X) for algebra and coalgebra (fp and oop).
<kluk>
[14:31:33] <beneroth>naturally it triggered Regenaxer :)) ||-> lisps cannot stray too far from being algebraic anyway, as they are stuck in evaluation by reduction; that is why even Clojure, a very Java-ish lisp, almost a non-lisp by some, works fine and doesn't become crazy land like Java.
<kluk>
[14:34:04] <beneroth>I fail to see any progress that java brought to programming language science ||-> I could not name a single one either; I could name a few needless things it invented, like "interface" from not being able to do multiple inheritance (as per Uncle Bob)
<kluk>
<kluk> the "meow" part, specifically, for a cat object, the "meow" part is what in picolisp? a symbol? a function? [14:41:00] <beneroth>it is a symbol [14:41:03] <beneroth>nothing more ||-> Right!
<kluk>
[14:41:21] <Regenaxer>it is a symbol with a function definition ||-> this is where we get confused here; a method meow is not a symbol to a function that prints meow, like a function called meow would be; a method meow is a symbol to a function that looks up in an object if it has a meow method. (I see you said this was wrong afterwards)
<kluk>
Imagine no one in the world ever wrote the method meow that prints meow. Now I go into any language and type the equivalent of "send the message meow to the object X". meow still exists as a symbol to a function, but as you see now it is just a lookup function; it is not the function that will print meow; this is the core difference between oop and fp and why oop cannot be simply thought of "oh it's just meth(obj, args)"
<kluk>
<beneroth>so I'm wrong [14:46:23] <beneroth>it becomes a function || -> regardless, that function is not *the* function that prints meow. it's a function that looks up to try to find a function that prints meow. That is what makes OOP not meth(obj, args). That is my whole point.
<kluk>
[14:42:37] <Regenaxer>kluk wanted not to look at impl ||-> looking at the implementation just confuses things; you can imagine an implementation that actually has you write methods as taking a first argument named self, as in python; still, that does not make it possible for me to call meow on an object and have it meow if I never wrote the method; meow still exists as a lookup function; and that is why it is so different from an FP meow.
<kluk>
[14:43:46] <Regenaxer>then 'meow>' may be undefined ||-> categorically there is no "then" meaning "in that case"; the fact is "meow>" seems to "always" perform some sort of lookup to see if a function/method exists for it on the object passed to it; that is what makes the OOP meow and the FP meow totally different beasts.
<kluk>
[14:44:58] <Regenaxer>'meth' is just a container to hold that pointer ||-> I love this indeed; this gives the game away; meth is a container (only coalgebras model containers) to hold a pointer (to a v-table or otherwise a dynamic way to look up the desired method/function)
<kluk>
<Regenaxer> yes, message is a function <Regenaxer> all messages have the same function code <Regenaxer> it exists only once in the system ||-> right, because all messages end up becoming a function that "looks up to see if a method of the same name exists for the object that was passed to this function".
<kluk>
[14:48:57] <Regenaxer>In any case, the action is not in the object. (msg> Obj) is just syntactic sugar for (send 'msg> Obj) ||-> (send 'msg> Obj) expands to step 1. Look to see if Obj answers to msg; step 2. if it does, call the msg function; therefore (send 'msg> Obj) is not equivalent to msg(obj) but indeed to obj(msg) as something-that-belongs-to-the-object will be the source-of-truth (dependency) for the msg. Since the msg depends on
<kluk>
the obj, you cannot call msg(obj) as that msg cannot be evaluated "depending on obj". No matter the syntactical acrobatics, you cannot avoid those two steps; those two steps are what makes OO obj(meth, args) and what makes it not mix well with FP.
<kluk>
[14:51:27] <beneroth>well no method hiding without that <beneroth>having this mechanism is the whole point of OOP ||-> hey, that's my point :P
<kluk>
<beneroth>I believe I can speak also for Regenaxer in stating that a term means what their creator meant by it, not what the masses misunderstood and repeated without learning ||-> I agree with this too;
<kluk>
<beneroth>arguing with theory against this is missing the whole point :) ||-> These lessons I am expounding on here have been learned in 1968 ( http://web.archive.org/web/20070331194254/http://www.reciprocality.org/pdf/reciprocality.pdf ) at some point some annoying people like me will have to appear and try to precipitate change, or we will forever be a mediocre field undeserving of the title of engineering.
<kluk>
<beneroth>because mainstream OOP is that way absolutely purposefully, ... ||-> yes, I agree with every point you made regarding the industry preference for OOP and how hard that makes for FP programmers to work. I am trying to add another piece of information, which is that OOP and FP will never "join" in a "friendly" language, because they are dual paradigms to each other; sure you can add some OOP to a lisp but that's because lisp
<kluk>
locks you into eval-by-reduction so you can be pretty safe you won't be swamped by OO mediocrity; however, look at Java, C++, C# and other langauges trying to adopt FP concepts; it usually results in ridiculous reinterpretations that end up losing the value of the FP-ness of the imported concepts.
<kluk>
That's it.
<kluk>
My answers are all after ||->
<beneroth>
"that does not make it possible for me to call meow on an object and have it meow if I never wrote the method"
<beneroth>
easily possible in lisp xD
<kluk>
how?
<beneroth>
"we will forever be a mediocre field undeserving of the title of engineering."
<beneroth>
haha. yes.
<beneroth>
<kluk> how? || a FEXPR? :)
<kluk>
fexprs won't help you call meow on an object and get it to print meow if you never write (print "meow")
<beneroth>
you can write (print WhatIWasCalledWith)
<beneroth>
also again
<beneroth>
in picolisp
<kluk>
<beneroth>haha. yes ||-> Nooo! :) Let's branch away and form a new discipline, we could call it constructivist programming, and leave the bisimilarity simulations to OOPes
<kluk>
OOPers*
<beneroth>
you don't call the object, you call a function with takes object + method name + method arguments as parameter
<kluk>
beneroth: that would not qualify as an OO Object.
<kluk>
(print WhatIWasCalledWith would not.
<beneroth>
you are the one wanting to qualify everything as an OO object :P
<beneroth>
we picolispers don't care :D
<beneroth>
<kluk> <beneroth> haha. yes ||-> Nooo! :) Let's branch away and form a new discipline, we could call it constructivist programming, and leave the bisimilarity simulations to OOPes
<beneroth>
well
<kluk>
<beneroth>you don't call the object, you call a function with takes object + method name + method arguments as parameter ||-> you're still getting confused by syntax; that function you call, can be called meow, without (print "meow") ever having been written; so it's not the real meow.
<beneroth>
I don't see how any other strategy would be socially scalable
<kluk>
Functional programming is all about the real meow.
<kluk>
strategy for doing what?
<beneroth>
nothing is real in software
<beneroth>
one point after another
<kluk>
errors are real :)
<beneroth>
only if they have an effect
<beneroth>
same for features :)
<beneroth>
<kluk> Functional programming is all about the real meow.
<beneroth>
lets chew a bit on this bit
<kluk>
an error, the way I mean it, as a thrown exception, is always an effect
<kluk>
okay let's
<beneroth>
1) this bit 2) error & reality 3) social scaling stuff
<beneroth>
1)
<beneroth>
real meow... as I understand you, you don't do the dynamic-lookup-thingy, ok. but you still have to write the (prinl "meow") <somewhere>
<beneroth>
and what you get is a single meow function which is always doing the same thing
<kluk>
Of course.
<kluk>
Yes.
<beneroth>
the whole point of OOP / method calling as chain of responsibility = not doing always the same thing
<beneroth>
it's conditional
<kluk>
I agree.
<beneroth>
it's control
<beneroth>
ok
<kluk>
You're making my point of just what a huge chasm there is between FP and OOP.
<beneroth>
I'm not sure about that
<beneroth>
I mean
<kluk>
Did you watch the Bartosz Milewski video I linked at 24:00 ?
<beneroth>
in FP you also implement control. if you implement "hey <unknown subject meow please>" you also do somewhere an implicit or explicit if cat (prinl "meow") else if human (prinl "fake meow"))
<beneroth>
kluk just the bit at 2400
<kluk>
I am saying that this is how OO is seen in theory. I am not making any controversial claims.
<beneroth>
yes, and? how is this relevant? even more so if it diverges from Alan Kays definition?
<kluk>
In fact I am not making any claims that would not be recognized as true by Dr. Milewski.
<kluk>
Alan Kay, despite giving a name to an idea, actually gave a name to a mathematical entity that existed before him.
<beneroth>
if it would be certainly true, than it would be a fact, not a claim, no? :D
<kluk>
So while I respect his right to define what OO is... he cannot define what coalgebra is.
<beneroth>
<kluk> Alan Kay, despite giving a name to an idea, actually gave a name to a mathematical entity that existed before him.
<kluk>
And every OO object seems to be a coalgebra.
<beneroth>
well isn't that true for all mathematics?
<kluk>
beneroth: sometimes it happens, sometimes it doesn't happen.
<beneroth>
your comment on my: <beneroth> in FP you also implement control. if you implement "hey <unknown subject meow please>" you also do somewhere an implicit or explicit if cat (prinl "meow") else if human (prinl "fake meow"))
<beneroth>
I see this just as different sugars
<beneroth>
FP style or OOP style
<beneroth>
you still need to convince me that there is an essential difference
<kluk>
in FP you also implement control. if you implement "hey <unknown subject meow please>" you also do somewhere an implicit or explicit if cat (prinl "meow") else if human (prinl "fake meow")) ||-> no, this does not happen as part of the mechanical structure of functions, the way it happens as part of the mechanical structure of methods.
<beneroth>
both is turing complete, so both are different representation of the same reality
<beneroth>
kluk, how does it happen then and why is it relevant that it is different?
<kluk>
<beneroth>I see this just as different sugars <beneroth> FP style or OOP style ||-> the whole reason I am having this conversation is to disabuse you of this erroneous notion.
<kluk>
(or to see if I can do it to someone smart)
<beneroth>
yes I know :D
<beneroth>
and I'm willing to learn, so guide me :D
<kluk>
<beneroth>you still need to convince me that there is an essential difference ||-> why doesn't 24:00 from Bartoz Milewski convince you? Can you clarify this?
<kluk>
Also, even, when taken together with that cool stackoverflow coalgebra link...
<kluk>
I think those two things together explain very well the issue. So I need to know what part of those explanations you are getting stuck on.
<beneroth>
it doesn't convince me to care about this difference because I don't see what difference it makes in the practical properties I get by choosing in general one strategy over the other
<beneroth>
I agree that FP tends to force the programmer to think more thoroughly, as discussed in our first session.
<kluk>
beneroth: Okay, I can speak to that. When OOP programmers tell me "just use methods as functions" I cannot because methods are structures such that they are aware of how to be polymorphic, whereas FP functions are structures such that they are not aware of how to be polymorphic (structural typing is done "outside" the function and does not disrupt its usage)
<beneroth>
but that doesn't mean that is universally general better than OOP for all situations
<kluk>
things in FP are smaller and simpler-structured.
<beneroth>
When OOP programmers tell me "just use methods as functions"
<beneroth>
well we don't do that here :D
<beneroth>
also C++ allows you to not use the OOP system.. so you have real functions. unlike java.
<kluk>
<beneroth>I agree that FP tends to force the programmer to think more thoroughly, as discussed in our first session. ||-> You are right, and I agree, and "think more thoroughly" is literally the F in F(X) -> X (the formula of Algebras)
<kluk>
OOP doesn't want to do the thinking so they defer F to the result-side: X -> F(X)
<beneroth>
and that is bad because?
<kluk>
Hence they cannot really mix.
<kluk>
That makes them unmixable.
<beneroth>
that doesn't follow
<kluk>
How so? It does follow as the arrow is backwards for OOP from FP and vice-versa.
<beneroth>
you can interface between them, so you can mix them in a program. a certain piece of code cannot be both, but you can mix an heterogeneous soup out of FP and OOP pieces
<beneroth>
stratified design
<kluk>
in FP you are always "taking from the context": F(X) -> X (you have some context F for your X and you get another X without context); in OOP you are always "shoving into the context": X -> F(X) (you have some message X and you send it to a context/object F.
<beneroth>
yeah
<beneroth>
but same thing
<beneroth>
you do something and you have a context
<beneroth>
how you transport that context is the difference.. not essential, I find
<beneroth>
for some tasks one strategy is better, for some tasks the other
<beneroth>
chose the tool according to the task, not the other way around
<beneroth>
btw
<beneroth>
what about declarative languages (e.g. prolog, or some sane SQL if I dare to say)
<beneroth>
is prolog FP ?
<beneroth>
is it OOP?
<beneroth>
is it another paradigm and separate from both?
<beneroth>
(but can be mixed also in our soup) ?
<kluk>
<beneroth>you can interface between them, so you can mix them in a program. a certain piece of code cannot be both, but you can mix an heterogeneous soup out of FP and OOP pieces ||-> beneroth, this is for sure; we both agree on this; for instance, lenses in Haskell are coalgebras (hence OO objects). What I am saying is: if you use FP + OOP in a sequence-based evaluation language like C++/Java/C#, you do not get the benefits of FP.
<kluk>
However, if you use FP + OOP in a reduction-based evaluation language (like all lisps and other FP languages) then you do get the benefits of both. In mathematics this is precisely true: every coalgebra is (can be seen/rewritten as) an algebra but not the other way.
<kluk>
Prolog is FP because it is based on equational reasoning and reduction rules.
<beneroth>
ha we agree on something :D
<kluk>
It is not a separate paradigm. There are only two ways of "going about doing things": algebra and coalgebra. This cannot be escaped.
<kluk>
I am not saying I want there to be only two things.
<beneroth>
if you use FP + OOP in a sequence-based evaluation language like C++/Java/C#, you do not get the benefits of FP || what about when you don't connect them as sequence but concurrently?
<beneroth>
e.g. math
<kluk>
beneroth: then, if I have to send a message to get a function instead of calling a function I already have, it's coalgebra, otherwise it's algebra. It's that easy :)
<beneroth>
wel.. integer algebra? dunno what the term is probably... is usually implemented FP-style even in OOP languages
<beneroth>
you can be fancy in C++ and implement basic math functions on top of an set-theory implementation in templates, kinda the principia mathematica way...
<beneroth>
kluk, so the parts are FP or OOP, combining it is always OOP then? :P
<beneroth>
well yes
<beneroth>
follows from FP is more fundamental than OOP as we already concluded in session 1
<kluk>
SQL is still functional, it's a monad, you can see it in LINQ if you squint and there it's easier to see it's a monad.
<beneroth>
hence arguing for FP over OOP is really a bit similiar like arguing for machine code vs. 3rd generation languages
<beneroth>
LINQ is an abomination
<beneroth>
it just looks the same
<kluk>
Yes, FP is more fundamental, algebras can do everything coalgebras can, which is why we can have a type-checked lens in Haskell but OOP cannot hindley-milner-ly understand my types.
<beneroth>
but LINQ-to-sql is complete a different thing from LINQ-over-objects
<beneroth>
kluk, so a pure FP language doesn't exist and would be meaningless, yes? :P
<beneroth>
math might be purely FP. but when it because implemented in a physical computer it gets infected with the co-algebraic reality :P
<beneroth>
hihi
<beneroth>
brb
<kluk>
<beneroth>hence arguing for FP over OOP is really a bit similiar like arguing for machine code vs. 3rd generation languages ||-> thank you for this; this is a common misunderstanding. The math behind FP is about making things more generalized, not more specific. So to say algebra and FP are more fundamental than coalgebra and OOP is not equivalent to saying that "machine code is more foundational than software abstractions". Machine code
<kluk>
is more specific. FP concepts are more general. It's the opposite.
<kluk>
beneroth: actually math is pure OOP
<kluk>
surprisingly enough
<kluk>
Only intuitionistic/constructivist math is FP
<kluk>
So for instance, real analysis is OOP
<kluk>
(because streams are coalgebras and streams model infinities after the decimal point)
<kluk>
most of math is still "analogic"/OOP
<kluk>
Only since 1958 did people start seriously rewriting the foundations of math on top of Types (see Homotopy Type Theory)
<beneroth>
"machine code is more foundational than software abstractions". || but it is! memory management is crippled in C
<kluk>
no, the word is not foundational
<kluk>
we can make a cpu that runs lisp, those exist, and they are reduction machines and not state machines
<kluk>
so machine code is *not* foundational
<kluk>
foundational means generalized
<kluk>
in math
<beneroth>
more generalized = more abstract
<beneroth>
hmm
<kluk>
yes.
<kluk>
That is why I always say "forget the computer, programming has nothing to do with it"
<kluk>
Programming is about making propositions and proving them.
<beneroth>
so the essence of reality is OOP. and FP is more powerful because it is more abstract. but for practical applications it degenerates into OOP again to be able to interop with reality :P
<kluk>
It can be done with pen and paper, with finger and a beach.
<beneroth>
T
<beneroth>
computer were once humans
<kluk>
the cpu is incidental
<beneroth>
well still are, in a way :)
<kluk>
it is there just because we want to compute. It's like a hallway. it has nothing to do with the destination other than it has a door to it.
<kluk>
yes and every OOP programmer today is still a computer
<beneroth>
T
<beneroth>
that I meant
<kluk>
whereas in FP-land we submit the effects for the compiler to worry about.
<beneroth>
why?
<kluk>
<beneroth>so the essence of reality is OOP. ||-> I would argue against that.
<beneroth>
there is no essential difference between a compiler implemented in silicon or in human, is it?
<kluk>
<beneroth>why? ||-> why what?
<beneroth>
I would argue against that. || kk later :)
<beneroth>
kluk, why favour compiler
<beneroth>
s/favour/prefer
<kluk>
so I can get it out of my head and not need to do the computer's job for it anymore
<kluk>
<beneroth>there is no essential difference between a compiler implemented in silicon or in human, is it? ||-> the difference is stress.
<beneroth>
the silicon also experiences stress...mostly as heat
<beneroth>
you just want to outsource the load from your self-object to another object, you selfish object
<kluk>
but I don't care about that as a human, that is its job.
<beneroth>
ok
<beneroth>
granted
<kluk>
FP gives the computer its job.
<beneroth>
but then
<kluk>
OOP makes the computer force me to do its job.
<beneroth>
how is that different to C# ? the C# programmers think less than the C# VM :P
<kluk>
and I think even less as an FP programmer. Why aren't they as lazy as I am?
<beneroth>
well FP programmers just prefer talking about CS theory over cranking out software *smug smug smug alert*
<kluk>
lol
<beneroth>
:D
<beneroth>
hehehe
<kluk>
talking is half the job
<kluk>
thinking is 30%, 10% is sleeping... the final 10% is coding in FP.
<beneroth>
I love the nerd definition of Joscha.. "nerd is a human who (falsely) believes that communication/talking is to present ideas to peers for review"
<kluk>
that is too close to the truth for comfort :)
<beneroth>
while most of humanity is talking to determine social structure
<beneroth>
<kluk> that is too close to the truth for comfort :) | so T
<kluk>
beneroth: how do you square the fact that everyone learns algebra in school, and when OOP was first adopted everyone in the industry reacted the same way they are now reacting to FP "oh this is so hard, the masses will never get it"
<beneroth>
on some level I just cannot grok that
<kluk>
I think with time the industry will grow out of OOP
<kluk>
with time and with gadflies like me
mtsd has quit [Quit: Leaving]
<beneroth>
because I learned C++ completely myself (even without internet) just with a book, and grokked it. and only later I found out that it is considered difficult. meanwhile I had extreme difficulties with HTML because it is not coherent nor consistent/logical. maybe that is way more social people can grok it easer?
<beneroth>
kluk, I think you wrong. the most likely path (if our civilization not breaks down before that and software (in the non-philosophical sense) becomes a thing of the past) is that everything will be full of many levels of abstractions (kubernetes-style) to run some docker-kind of containers inside containers
<kluk>
I think the opposite!
<beneroth>
like.. how many "smart" (hahaha) light bulbs have fully functional linux universal computer on it, restricted to a few functions, because mass productions means its cheaper to crank out this systems than task-specific IC's
<kluk>
The most likely path will be something like a pucolisp on a cpu.
<beneroth>
that would be nice
<kluk>
beneroth: we are building castles in the sand
<kluk>
they cannot withstand time
<beneroth>
I would prefer living in your reality :D I don't think we do
<beneroth>
yes
<beneroth>
but.. we never did anything else
<kluk>
there will be a reckoning when all this code becomes impossible to touch anymore.
<beneroth>
no, we just put another layer on top
<beneroth>
which patches some of the errors whenever they occure
<beneroth>
to expensive to reevalute and re-implement
<kluk>
beneroth: I think we are living in my reality: C#/C++/Java adopting FP heralds so.
<beneroth>
and eventually we will forget what actually happens and then we forget the essential skills for it
<beneroth>
<kluk> beneroth: I think we are living in my reality: C#/C++/Java adopting FP heralds so
<beneroth>
well
<beneroth>
other languages are copying LISP since 1950. they still haven't reached it's power.
<beneroth>
they will not, not without becoming lisp
<kluk>
beneroth: this "just put another layer on top" only will keep happening until a market disrupter comes up with the next lisp machine.
<beneroth>
hey cyborg_ar :) nice to see you more active on IRC again :))
<beneroth>
<kluk> beneroth: this "just put another layer on top" only will keep happening until a market disrupter comes up with the next lisp machine.
<beneroth>
lets hope
<beneroth>
I try to be such a guy :d
<beneroth>
but then again Chuck Moore is not outplaying all the bigcorps, except in some small niches ;-)
<kluk>
beneroth: we are missing a Steve Jobs -like person who will bring common sense to the masses and free us from the Von Neumann machine.
<kluk>
Chuck Moore's Forth is still a coalgebra
<kluk>
Term rewriters are coalgebras.
<beneroth>
he didhn't bring common sense to the masses. he just made it more attractive and then forced them somewhat
<kluk>
And it pains me to say that.
<beneroth>
what is the FP equivalent of social organization?
<kluk>
Libertarianism (contracts are the functions and they fill in for everything that models like courts and police can do)
<beneroth>
human is a state-building species consisting of individual agents.
<kluk>
That is a very astute question by the way.
<beneroth>
thx
<kluk>
I don't think we build state, I actually think we think in terms of equality, which is why people say "like" so much, "like" = equality.
<beneroth>
<kluk> Libertarianism (contracts are the functions and they fill in for everything that models like courts and police can do) || sounds a lot like the etherium idea.
<beneroth>
I think its BS
<kluk>
So I actually think humans think in FP.
<beneroth>
only on a very local and limited level
<kluk>
ethereum is not distributed so it would not sound like ethereum. Ethereum is still centralized, when you have a central model you have a coalgebra.
<beneroth>
they only think about equality of people they regard as similar to themselves.
<kluk>
that is the only equality that exists in nature.
<kluk>
being similar genetically.
<kluk>
like 2 and 3 are similar for both being integers.
<beneroth>
yeah, so it's islands of FP within a OOP super-system
<beneroth>
like your FP programs :P
<kluk>
I don't mind algebraic coalgebras... I mind coalgebras in coalgebraic languages.
<kluk>
I don't mind lenses.
<kluk>
I use lenses knowing they are a coalgebra in Haskell and I don't mind it.
* beneroth
doesn't know your terminology enough to debate you on that
<beneroth>
do you mind mindlessness?
<kluk>
What I don't do is say "hi client, before you tell me your problem, I will tell you that I will solve your problem with objects which are coalgebras"
<kluk>
That is insanity.
<beneroth>
no, that is every telephone support :P
<beneroth>
so
<beneroth>
in essence you just repeat what I said:
<kluk>
do I mind mindlessness? No, I prefer mindlessness. When the compiler knows my types structurally I can be mindless. When it doesn't I have to do the computer's job for the computer while sitting in front of the computer. That makes no sense to me.
<beneroth>
<beneroth> for some tasks one strategy is better, for some tasks the other
<beneroth>
<beneroth> chose the tool according to the task, not the other way around
<kluk>
But always choose FP as the foundation.
<kluk>
Add that.
<kluk>
Reason: every coalgebra can be algebraized but not vice-versa.
<kluk>
So we should always start from an FP language.
<kluk>
Otherwise there can be no FP.
<beneroth>
kluk, sounds like the road to meditation, which in extreme results in you modifying your own internal reward function, and then dying because you are happy with it and don't care :)
<beneroth>
kluk, ok.. so Regenaxer did the right thing with picolisp?
<beneroth>
considering that he wanted it to be forth first :D
<kluk>
it's funny you should say that. I feel like math modified my internal reward function to be "learn more math to be increasingly happier"
<kluk>
(and it's working)
<beneroth>
oh nothing wrong with that
<beneroth>
all good and fine and legitimate
<beneroth>
just not interopting so well with nature :D
<beneroth>
when you cheat it, kinda :D
<kluk>
beneroth: if Regenaxer wanted picolisp to be Forth first (and as a term rewriter forth is a coalgebra) then he made the right choice in going with lisp (as it is naturally stuck in reduction for evaluation and therefore it is stuck in algebraic world)
<beneroth>
he tried with forth first, and found it too hard to keep the stack state in mind all the time, so he made a lisp with some forth features
<beneroth>
which boils down to your argument and point :)
<beneroth>
as stack state is context etc.
<kluk>
<kluk>I don't mind algebraic coalgebras... I mind coalgebras in coalgebraic languages. ||-> by this I mean, lenses in Haskell are fine because they are type checked, despite the fact they are actually OO objects (mathematically); whereas using Objects in OO languages, I have to do all the bookkeeping in my head, the computer does not help me model-check it.
<beneroth>
so basically.. you should program in picolisp and be happy :D
<kluk>
(model-checking is the OO equivalent for type-checking)
<beneroth>
<kluk> (model-checking is the OO equivalent for type-checking) || equivalent? I would say it is semantically the exact same thing
<kluk>
<beneroth>he tried with forth first, and found it too hard to keep the stack state in mind all the time ||-> hahahahaha, what am I telling you? Precisely this. This is why I avoid coalgebras. They are too hard and I enjoy mindlessness and I am lazy and I want the computer to do most of the job it can do for me.
<beneroth>
yeah I noticed, we're out of sync again :D :D
<beneroth>
<3
<kluk>
beneroth: it is not semantically the same. they are duals of each other. model-checking is kripke-structures in coalgebra (that is, simulation and then checking for bisimilarity, which means objects are the same up to the names of their methods but not their state) math whereas type-checking is theorem proving in algebra.
<kluk>
we're not that much out of sync! I'm some 4 messages behind if that.
<beneroth>
T
<kluk>
Ah I see it now :))
<beneroth>
:)
<kluk>
Yes that is my point.
<kluk>
And!
<kluk>
If you do FP in an OOP language you still have to mind state. That is why you can't reap the benefits of FP in OOP-land.
<beneroth>
" simulation and then checking for bisimilarity, which means objects are the same up to the names of their methods but not their state) math whereas type-checking is theorem proving in algebra." hm... I see. but is that just a difference of the implementation layer? the semantic task executed is the same... hmmm
<kluk>
So to conclude, that is why mixing FP in OOP languages is a dead-end, and/or a path towards pure FP acceptance.
<beneroth>
nvm
<beneroth>
<kluk> So to conclude, that is why mixing FP in OOP languages is a dead-end, and/or a path towards pure FP acceptance.
<beneroth>
well but didn't we already establish that mixing FP and OOP results in a OOP superstructure?
<beneroth>
:P
<beneroth>
pure FP is nice, but it cannot connect to the printer, or?
<beneroth>
when it connects to the printer, its OOP again :P
<kluk>
<beneroth> hm... I see. but is that just a difference of the implementation layer? the semantic task executed is the same... hmmm ||-> that is a valid question. It does not look like they are the same thing. I'll tell you why. Coalgebras model infinitudes, algebras don't. So that is why type-checkers can "prove" whereas simulations can only "check bisimilarity" i.e. "do the actions and then look to see if the objects are what you said they
<kluk>
would be". Simulations are never exhaustive. Type-checking can offer exhaustion guarantees (and very often does, in order to be practical; only Shen did not guarantee this, that I can remember now).
<beneroth>
yeah, I think you are right
<kluk>
[16:54:01] <beneroth>pure FP is nice, but it cannot connect to the printer, or? ||-> this is an excellent question. I have a whole video answering this question here https://wiki.call-cc.org/event/coding-jam-2021 called Bleeding-edge Stateless Programming (by Luke K)
<beneroth>
about which I have some philosophical/social comments, but later
<kluk>
The answer is "FP can connect to the printer just fine"
<kluk>
(I am a bit behind)
<beneroth>
kluk, and the system of (FP + printer) would still be considered FP? I don't think so
<kluk>
<beneroth>well but didn't we already establish that mixing FP and OOP results in a OOP superstructure? ||-> if you are careless, yes. That is why I say we must always start from FP/algebra.
<beneroth>
same as prolog result binding
<kluk>
beneroth: yes it would. I prove it in the video. It's still algebraic, hence still FP.
<kluk>
just like getLine in haskell does not get a line
<beneroth>
ok, noted, I will watch. not now.
<kluk>
I can talkToPrinter without it being a side-effect.
<kluk>
[16:58:20] <beneroth>ok, noted, I will watch. not now. ||-> would love to hear feedback if you have any after you watch some time if you do
* beneroth
also doesn't know haskell well. but his work buddy is a huge Haskell fan
<kluk>
(my presentation uses CHICKEN Scheme)
<beneroth>
kk
<beneroth>
ah that is you? ok :D
<kluk>
I make it so Scheme becomes 100% pure
<kluk>
Yes I am that guy. :)
<kluk>
What a weird thing to say.
* beneroth
hopes he will find this link again in your big log xD
<kluk>
well at least now things are being logged :)
<beneroth>
kluk, you have identity, you are OOP :P (do you know discworld? :P)
<beneroth>
2) errors and reality
<beneroth>
you defined errors as exceptions being thrown
* beneroth
is switching topics, ok? I think we finished the previous point somewhat until I watched the vid
<beneroth>
where is the difference between exceptions and information being passed around?
<kluk>
I have only a binding, not a box! :P
<kluk>
what is discworld?
<beneroth>
granted, exception = breaking the simulation which needs then restart/continuation
<kluk>
reading you now...
<beneroth>
Terry Pratchett, author of discworld novels. a mix of parody on fanatasy genre while being satire & astute observation of society & human reality
<beneroth>
one group of beings in his universe die when they say "I", because identity means living means being able to die (ceasing to exist). they hate live.
<beneroth>
pretty FP people
<kluk>
Yes let's go to 2), I am with you.
<beneroth>
ok
<beneroth>
brb
<kluk>
ok. I am typing.
* cyborg_ar
leaves a monad laying around
<beneroth>
cyborg_ar, :D
<kluk>
[17:01:01] <beneroth>where is the difference between exceptions and information being passed around? ||-> what a wonderful question. I really want to answer this. It's a beautiful question. The answer is that when you pass information around through passing arguments to functions, you are using the only band (i.e. channel) available to you in FP-without-exceptions. When you introduce algebraic exceptions to FP (notice: algebraic
<kluk>
look at it). When you implement a monad, you are looking at it as if the second band it offers is "the same band as parameter-passing code" which is why when you implement it you are forced to deal with not just the monadic operation but also the context and its structural upkeeping. It turns out that algebraic exceptions are isomorphic to monads, but with a major advantage: you never need to code "join", the monadic "flatten" operator
<kluk>
exceptions, not the usual ones, I mean type-checked exceptions) then you introduce a second band for information to be passed around. This is what monads do, too, they build a second band so that you can tangle parameter-passing code with monad-affecting code. It turns out that this second band, as I said, is also algebraic, and can be considered both "the same band" and "a different band" categorically (it depends on how you choose to
<kluk>
that "tangles" both bands. In other words, with algebraic effects you can define the effect-band and the pure-band totally separately and only tangle them at usage site.
<kluk>
<beneroth>granted, exception = breaking the simulation which needs then restart/continuation ||-> this is only true for coalgebraic exceptions which usually cannot resume like common lisp restarts can. Common Lisp is closer to algebraic but it still doesn't give you the continuation from the (exception-)throw site for you to come back cleanly.
<beneroth>
ok
<beneroth>
I find we have the same understanding here
<kluk>
Cool!
<beneroth>
btw. the (catch) in picolisp has two modes (depending of first argument): exception handling (as in OS exceptions or programmer defined errors, which are "thrown" by (quit), nothing to do with (throw)) or catching a symbol thrown by (throw) = non-local jump, nothing to do with exception handling
<beneroth>
some more to discuss here or do we move to 3) more philosophical stuff?
<kluk>
ah! that is amazing. Where did it take this idea from? Did you know SML is already like that except that throw/catch are already (to begin with) capable of throwing and catching any type, exception or not.
<kluk>
we can move to 3
<beneroth>
" Where did it take this idea from?" no idea, ask Regenaxer. most picolisp users get this pretty confused at the beginning, because of the widespread believes about catch/error handlign from other stacks
<beneroth>
" like that except that throw/catch are already (to begin with) capable of throwing and catching any type, exception or not." || that is how it is in C++. you can throw anything in C++.
<beneroth>
the dumb thing with C++ is, you must know what things are thrown at you to be able to catch it. which is not transparent in code, needs documentation. huge weakness.
<beneroth>
you kinda must know if you just catched a pointer or an integer. they look the same :D
<beneroth>
(which is a weakness, of course, no need to debate :D)
<beneroth>
on to 3?
* beneroth
tries to get some work done on the side, so the breaks are appreciated
<cyborg_ar>
exception handling in C++ is a shitshot
<cyborg_ar>
show*
<beneroth>
cyborg_ar, T
<beneroth>
absolutely
<cyborg_ar>
the usual recommendation is to not use exceptions at all
<kluk>
(just a sec)
<beneroth>
yes, so the whole design is a failure :D
<beneroth>
kluk, no stress
<kluk>
I see. On to 3!
<beneroth>
ok
<beneroth>
I guess we agree on human social structures being OOP in nature?
<kluk>
We do not.
<beneroth>
ah nice
<beneroth>
:D
<beneroth>
ok so which social structures are not OOP in nature then?
<beneroth>
(using OOP as placeholder for co-algebraic, poor Alan Kay)
* kluk
thinks
* beneroth
thinks this is not inherent, but a result of another thing)
<kluk>
Let me give you an example.
<kluk>
Do you know any latin or other ancient languages?
<beneroth>
not really. I know swiss german which is basically full of ancient german :P I know some latin terms, but I was never educated in latin
<beneroth>
I know some quenya xD
<beneroth>
(ancient elfish in tolkiens universe)
<kluk>
Okay. No problem. In Latin, they did not use the verb "to have" to say "to have" (because it still held its older sense of "to hold, to take").
<kluk>
So to say "I have a car" (they had chariots and called them cars) you would say "currus mihi est" = a car is to me
<kluk>
Instead of "I have a car"
<kluk>
I believe (I could be wrong) that the same was the case for Ancient Greek. I know it is the case for some Celtic languages today and their ancient versions.
<beneroth>
I see. but looks to me like an indirection, not FP
<kluk>
Well, but for sure it does not look like one thing containing the other, right?
<kluk>
And thanks for helping me get to the point! :)
<kluk>
it looks like two adjacent things.
<kluk>
A car is to me. As in: A car is right next to me.
<kluk>
(and therefore I own it)
<beneroth>
are you aware of the fringe psychology theory about the "Bicameral mind" (I learned about it from the iconic "Snow Crash" cyberpunk novel)
<kluk>
Only very superficially. I could not intelligently elaborate on it. Would you, to show me the connection?
<beneroth>
I find that theory wonderful. I guess one could argue that would be an FP human social structure
<beneroth>
but I agree with the theory is probably wrong, still wonderful though
<beneroth>
hm
<kluk>
I'd be surprised if it relates faithfully to this dichotomy
<kluk>
but this dichotomy can also be reframed as bottom-up (algebra) versus top-down (coalgebra) and many people have detected that pattern before.
<beneroth>
the core idea is that humans were, upon to a point (the bronze age collapse), not really consciousness
<beneroth>
but yeah, just a sidenote
<kluk>
ah okay.
<beneroth>
we can explore it later
<kluk>
I understand. I would agree with it in general as I can see other consequences this hints at. Later.
<beneroth>
<3
<kluk>
so do you see my point with "to have"?
* beneroth
wants to meet and hug kluk :P
<kluk>
That is just the beginning
<kluk>
I could argue this endlessly and provide more examples
<kluk>
But I like to start with emblematic examples
<kluk>
:)
* kluk
hugs beneroth
<beneroth>
yes I see it. it sounds like the (not sure if true) tale that some australian aboriginies use a global coordinate system for space instead of a local coordinate system
<beneroth>
aka "my nordic arm" depending on location, never "my right arm".
<beneroth>
agreed?
<kluk>
Right, it is about a dual way of seeing the world, and choosing or being born with a bias to think in one way.
<beneroth>
this probably would result in a less egocentric worldview in general (literally)
<beneroth>
T
<beneroth>
but then
<kluk>
Well, I do argue that the equivalent to FP in social interactions (you put it better before, I forget the exact phrase) is contract-based societies (as contracts are function types mathematically per Curry-Howard isomorphism) so I do think it would end up in a better world than what we have.
<beneroth>
but I don't see that this, or your latin car, results in FP. I mean if the pointer is from car to person or person to car, or if both have a member variable pointing to another, its still OOP
<beneroth>
<kluk> Well, I do argue that the equivalent to FP in social interactions (you put it better before, I forget the exact phrase) is contract-based societies (as contracts are function types mathematically per Curry-Howard isomorphism) so I do think it would end up in a better world than what we have
<beneroth>
hm
<beneroth>
better in what sense? more efficient and more effective, so probably better for the quality of life for the whole species? yes
<beneroth>
ants do that, no?
<kluk>
in a nominal sense that more people would qualify it using the word "better"
<beneroth>
not so sure if it fits well with the human mammal nature
<beneroth>
and that is basically the point I was hinting at
<kluk>
I believe that is why the enemies of the Romans usually held their ground
<beneroth>
who did?
<beneroth>
I would say the Romans were more FP than most enemies
<beneroth>
disciplined military is organised by abstraction, so more FP in style, than individualistic synced simulations, you disagree?
<beneroth>
yes they have stratified hierarchies in their social structure, but that didn't make them different from other societies
<beneroth>
brb
<beneroth>
ha! you gave me some more ideas
<kluk>
beneroth: ants cannot make new contracts (i.e. cannot create new types in FP) so they are in a limited equational world.
<beneroth>
kluk, yes! that was also part of the "Bicameral mind" theory
<kluk>
mammals are creative and want to make new contracts (play with each other, create tools, etc)
<beneroth>
it needed an outsystem "programmer"
<beneroth>
kluk, agency
<beneroth>
individuality = identity
<beneroth>
OOP
<beneroth>
there is no identity in FP, is there?
<kluk>
that is a good point. you are right.
<beneroth>
same value = euqal
<beneroth>
in FP. not necessarily in OOP
<kluk>
you are right.
<beneroth>
(some of this thoughts came to me between our first session and this one, you made me think a lot :) )
<kluk>
I am thinking about your military questions
<beneroth>
ah
<beneroth>
I found a better picture
<beneroth>
well my point is, most didn't stand ground against romans, did they?
<kluk>
In a nutshell, the Romans used formations, tactics and strategies, whereas their enemies used guerilla tactics mostly. Which of those is FP and which is OOP?
<beneroth>
nordic/east germania was not conquered by romans because they didn't like the climate and nature there, not because of the tribes
<beneroth>
kluk, counterquestion: which is more generalized, which makes more use of abstractions? :)
<beneroth>
not sure if this line works out as I intend.. but
<beneroth>
I have a better analogy of the same style, maybe
<beneroth>
the nordic tribes.. they came there as a result of fleeing from the mongol hordes
<beneroth>
and centuries later some mongols threatened europe.. if they wouldn't have been called back (as their Khan died), they would surely overrun middle age european nations
<beneroth>
why? they where more FP than the city states I would argue here
<kluk>
<beneroth>yes they have stratified hierarchies in their social structure, but that didn't make them different from other societies ||-> hmm you hint at something good here. I do think there is something to do with hierarchies and being able to tell apart algebra from coalgebra. Because coalgebras have identities as you correctly pointed out, they have nominal hierarchies (instead of structural such as functions, functor maps, natural
<kluk>
transformations, etc). Whereas in FP things are more "all the same" and so "all replaceable" and I think I would associate this more with the state of anarchy that the non-Romans lived in prior to conquest.
<beneroth>
<beneroth> why? they where more FP than the city states I would argue here
<beneroth>
nomadic groups bear less context with them around than static stonehouse-dwellers
<kluk>
<beneroth>nordic/east germania was not conquered by romans because they didn't like the climate and nature there, not because of the tribes ||-> I agree, and also because they did not see much bounty as the nordics relied heavily on wooden buildings and the Romans thought very little of it.
<beneroth>
"a. Because coalgebras have identities as you correctly pointed out, they have nominal hierarchies (instead of structural such as functions, functor maps, natural"
<beneroth>
yes that is my point
<beneroth>
T
<kluk>
<beneroth>well my point is, most didn't stand ground against romans, did they? ||-> I believe they did, they fought bitterly, but the Romans knew how to go to the jugular.
<kluk>
The Romans at that point were so efficient that guerilla tactics could only slow them down a couple centuries but not stop them.
<beneroth>
on individual level they might been stronger, but only started to gain ground when they started to copy tactics from the romans
<beneroth>
spear formation etc.
<beneroth>
T
<kluk>
agreed on that.
<beneroth>
ok, next level, connecting this with the Joscha Bach computational philosophy
<kluk>
I am reading your nordic example.
<beneroth>
ah T
<beneroth>
:D
<kluk>
[17:52:48] <beneroth>why? they where more FP than the city states I would argue here ||-> 100% agree.
<beneroth>
:D
<beneroth>
nice
<kluk>
[17:53:18] <beneroth>nomadic groups bear less context with them around than static stonehouse-dwellers ||-> 100% yes. We agree.
* beneroth
ponders whoever must read this stuff must think we are mental or way over the head. :D
<beneroth>
anyway
<beneroth>
so next level?
<beneroth>
that human social structures are more OOP than FP is a result of what humans are
<beneroth>
LOL
<beneroth>
sidenote
<beneroth>
<kluk> [17:53:18] <beneroth> nomadic groups bear less context with them around than static stonehouse-dwellers ||-> 100% yes. We agree.
<beneroth>
context = externalities = dependencies
<kluk>
Yes so the lesson is, FP is distributed (as we know in the real world, it enables distributed computing) and so anarchic (non-hierarchical) and primitive (foundational) but resilient (guerilla tactics = type checking, thinking bottom up) whereas OOP is Roman-like, disciplined (because it lacks type checking - discipline = training = model-simulation=coalgebra, lacks connection to principles (algebra and axioms)) and is more sophisticated
<kluk>
(has context) but more monolithic (hard to change) however in big dosages against a big algebraic enemy it usually wins (pragmaticity of OOP wins minds of programmers instead of FP winning)
<beneroth>
so basically.. node.js claiming to be FP is complete BS when considering that they like to encapsulate every single 3-line-function into its own NPM package, becoming OOP
<kluk>
[18:00:43] <beneroth>so basically.. node.js claiming to be FP is complete BS when considering that they like to encapsulate every single 3-line-function into its own NPM package, becoming OOP ||-> yes, and on an inner level, the "functions" that javascript uses are really objects themselves and are not in any way like the simple structureless arrow they are in FP.
<beneroth>
(now exclusively using the FP/algebraic OOP/co-algebraic terminology,not Alan kay or picolisp software concepts - more an info for the later readers)
<beneroth>
(if they are different or not is another thing and not relevant now)
<beneroth>
kluk, ha
<beneroth>
I like being smug with you against js :P
<beneroth>
fully agree
<kluk>
Right! we are strictly talking about FP and OOP both from a mathematical categorical point of view where they are respectively algebra and coalgebra systems
<beneroth>
yep
<beneroth>
poor silent reader :)
<kluk>
hah
<beneroth>
you said in session 1 that you have some nice counterarguments to Joschas computational philosophy?
<beneroth>
wanna expand on them now or after connecting his stuff with our discussion?
<kluk>
I could do it now - can you point me again to what is meant by Joschaas computational philosophy?
* beneroth
listened/read quite some stuff from Joscha, and it made sense because of his previous training with Robert Anton Wilson and other stuff
<beneroth>
ah okay :D
<beneroth>
then maybe let me explain it and connect it with our previous level, and you can than critize both :D
<kluk>
I may know what it is without having associated it to a name or may not know it at all
<kluk>
however you prefer
<beneroth>
maybe, maybe not. I found it quite a revelation for my ponderings
<beneroth>
so my claim is: human social structures tend strongly to OOP because humans are OOP in nature, as explained by Joscha's hypothesis about the human nature... (which I now gonna expand)
<beneroth>
(or as I understand Joscha, but I believe I grok him)
<kluk>
ok
* beneroth
pondering about which angle to open this
<kluk>
you can also start with an example (just a reminder)
<kluk>
I don't know if it works here
<kluk>
that is, coalgebraically, since models are sequence-based and hence simpler; rather than axiomatically
<beneroth>
ok in tl;dr (later backed up with reasoning/examples, bear with me): human minds are simulations implemented in biological apes (well apes have that stuff too...but...)
<beneroth>
hehe yeah
<beneroth>
ok
<beneroth>
chemistry, on the very lowest level
<beneroth>
I guess we agree that it is kinda FP
<beneroth>
same with laws of physics, as we already established in session 1
<beneroth>
chemistry results from laws of physics, afaik
<beneroth>
biochemistry would then also be FP... protein expressions etc..
<kluk>
Yes chemistry is clearly algebraic and thus FP.
<kluk>
(I am terrible at chemistry and I could be totally wrong about this)
<beneroth>
now lets start with live.. at first without any sensors, just some thing swimming in the soup, feeding on whatever it happens to get as input (it is passive)
<kluk>
Yes laws of physics would be algebraic if I am correct.
<beneroth>
(in a sense.. it is already identity, but maybe we could ignore that)
<kluk>
ok
<beneroth>
<kluk> Yes laws of physics would be algebraic if I am correct. || well we just assume and any evidence so far looks so
<beneroth>
no evidence to the contrary
<kluk>
yes
<kluk>
yes
<kluk>
correct
<beneroth>
<beneroth> now lets start with live.. at first without any sensors, just some thing swimming in the soup, feeding on whatever it happens to get as input (it is passive)
<kluk>
ok
<beneroth>
next level: sensors: now the environment gives more food/less food
<kluk>
ok
<beneroth>
next level: actions: lets wibble(?) a bit to change location
<beneroth>
(still all in water)
<beneroth>
optimize for food intake
<beneroth>
a very basic agent, in the sense of a basic kybernetic system
<kluk>
yes
<beneroth>
(we're already in OOP territory, but not so significant yet)
<kluk>
agreed
<kluk>
I was just thinking that
<beneroth>
next level: predator, being able to feed of others (other singular cells?) which already did some feeding (input searching & preprocessing) for us
<beneroth>
and now it already becomes social on a very basic level.. or OOP in the sense of objects interacting...because next level is: trying to avoid predators vs. trying to mitigate avoidance strategies
<beneroth>
how do that?
<kluk>
I don't understand the question.
<beneroth>
compute a model of the "others" and their behaviours, run simulations, use this to decide into which directions you wobble (aka searching a solution tree of actions-and-consequences, score using a cost-function than decide actions. gather feedback -> improve model)
<kluk>
ah yes
<beneroth>
(was rethoric question, sorry)
<kluk>
okay
<kluk>
I'm with you.
<beneroth>
nice
<beneroth>
most of the rest is then just scaling up this setup....but lets expand in detail (but faster/bigger steps now)
<kluk>
ok
<beneroth>
e.g. building social structures (schools/swarms of fish... synchronizing behaviour with other peers - a lot of that happening in FP fashion over multiple OOP instances - countermodeling that as predator etc)
<beneroth>
fish swarms and bird flocks afaik synchronize a lot by just copying a next neighbour -> swarm behaviour. the copy function is obviously FP
<beneroth>
brb
<kluk>
(what I am thinking now: neural networks are definitely a coalgebra (you keep putting information in a context and altering an unobservable, indirectly-available state) so I agree that all beings with neurons are learning by processing simulations. however those simulations are made in order to approximate an abstract function to its counterpart in reality)
<kluk>
ok
<kluk>
with you so far
<kluk>
take your time
<beneroth>
yes
<beneroth>
(had to pee, damn implementation needs)
<beneroth>
excellent comment about neural networks
<kluk>
lol
<beneroth>
<beneroth> excellent comment about neural networks
<beneroth>
also what makes them so bad in the big difference to "classic" programming.. in classic programming, we can disassemble and debug the steps of the program, while in neuronal networks all that "knowledge/model" is in the context smeared around, which makes it a LOT harder (not impossible, but often for all practical considerations)
<beneroth>
basically we are now capable of building simulations in silicon which we cannot simulate in our brains, yes?
<beneroth>
see Alpha Go etc (which showed that human Go excellency was a local minimum)
<beneroth>
next?
<beneroth>
s/next/continue
* kluk
thinking
<beneroth>
take your time. quality first.
<beneroth>
(also we're now in a sidebranch, but interesting one. we jump back soon)
<kluk>
[18:24:57] <beneroth>basically we are now capable of building simulations in silicon which we cannot simulate in our brains, yes? ||-> we naturally simulate them in our brains, right?
<beneroth>
right
<kluk>
hmm I will have to look at Alpha Go
<kluk>
okay next.
<beneroth>
it revolutionized Go strategies, apparently. it found out the strategies humans needed some hundred generations, and then some more. it made moves which were considered bad in traditional Go teaching but apparently lead to more optimal strategies over more steps than we collaboratively searched the solution tree
<beneroth>
or so I understood, without knowing much about Go or the detail implementation of Alpha Go
<beneroth>
ok
<beneroth>
onwards to land animals, then mammals and apes/monkeys which already have a lot of social structure and social interactions
<kluk>
very interesting, will definitely look into it. onwards.
<kluk>
yes, much context now
<beneroth>
so a lot of modeling and simulation
<beneroth>
T
<kluk>
definitely
<beneroth>
Joscha computational philosophy (well it's not all his idea alone, though some aspects certainly are) as multiple aspects..
<beneroth>
one of it is a hypotheses for the nature of consciousnesses
<beneroth>
the claim is basically... lets expand
<kluk>
wow this will be super interesting
<beneroth>
1) our biological machinery.. and our biological neurons.. they don't feel. they're physical, biochemistry.
<beneroth>
(nicely seen in the fact that brain has no pain..and brain surgeries are done while people are awake to check on them)
<kluk>
very nice, ok
<beneroth>
2) but with all these social interactions (with in-groups and out-groups, supporters and predators) and modeling etc...
<beneroth>
it would be benefical for the biological physical machinery (which in its very essence is nothing that a transport for DNA, in some way)
<beneroth>
to SIMULATE how the other ape/animal/human-people WOULD think, how they would feel (= need sensors) and decide/react to certain events, be it random events in the environments or be it actions-counter-actions-interactions with other social beings
<beneroth>
3) so the hypothesis is, the human brain runs SIMULATIONS of the own person and other persons, and the difference of other persons and the own is, that the own = the one instance (identity) for which we also have write access to some degree to call methods
<beneroth>
-> consciousnesses = the simulation of consciousnesses = the story/narrative the brain tells itself to evaluate what to do
<kluk>
and the running of the simulation gives rise to consciousness... as you just typed
<beneroth>
yes
<beneroth>
in essence: physical matter cannot be consciousness. ONLY simulations can be consciousness..
<kluk>
is that recursive in a way or am I seeing double?
<beneroth>
many recursive and many layered feedback loops
<beneroth>
in a sense... when the brain has a clock frequency (which I believe is established).. and consciousness is a computation/simulation executed... I mean.. you remember, and that why you believe
<beneroth>
this model has various implications.. and explanations for some psychological stuff
<kluk>
really? give me one example for explaining something psychological. I am very intrigued, this thinking is new to me.
<beneroth>
(joscha claims indeed that Minsky & Co, the founders of AI science, basically started with that because they were disillusioned with psychology, saw it as a dead end (especially to bring it in accordance with biology))
<kluk>
And also, would that not raise the question of whether neural networks are conscious?
<beneroth>
it does. Joscha viewpoint is basically: more complicated neural networks could be conscious. he denies that current ML neuronal networks are.. in a sense.. I think)
<beneroth>
so the extended model for how this works with body control etc.. (which I also have largely from slatestarcodex, but I believe it's congruent with Joschas view)...
<beneroth>
<kluk> And also, would that not raise the question of whether neural networks are conscious?
<beneroth>
well
<beneroth>
I believe this can be more easily said, maybe
<beneroth>
imagine (and I believed this to be possible before knowing about this hypothesis, but then it was a contradiction) we can build a ML neuronal network (or other system) which can believably fake to be conscious
<beneroth>
I guess we agree, this is possible in principle.
<kluk>
yes we can attempt to pass the Turing test
<beneroth>
yeah
<beneroth>
an advanced emulation
<beneroth>
Joscha's claim is then, that there is no difference between real consciousness and an emulated one. there are certainly different degrees (as there are different degrees of simulation) and multiple things are requirement to give rise to conscious (e.g. memory, agency, models of itself and outworld) and if not all is required than its left away, kinda
<kluk>
left away how?
<beneroth>
with that I mean.. you don't want to simulate a consciousness if you don't need to, to solve your computation
<beneroth>
psychological things.. my memory is not so exact, and that stuff is mainly from slatestarcodex blog, but let me try...
<kluk>
oh, so then neural networks must be given sufficiently sophisticated problems to solve in order to achieve progressively higher levels of consciousness?
<beneroth>
hm.. yes
<beneroth>
well
<beneroth>
" higher level" is a slippery slope to define, but lets ignore that for the moment and come back to it
<kluk>
ok. and okay yeah any psychological examples would be elucidating
<beneroth>
first body control maybe
<beneroth>
so eyes... a lot of processing happens before we "see", right?
<beneroth>
we have blips of photons hitting our retinas, this is then interpreted
<beneroth>
and modeled. through multiple layers of ML systems and filterings. to filter out a lot of noise signals. to interpolate the blind spot caused be "eye-cable" (I mean the nerve connection eye to brain, forgot the term), etcera
<kluk>
okay.
<beneroth>
in the end this gets projected into the 3d world we "experience"
<kluk>
yes
<beneroth>
sometimes with quite strong interpretation made up from memory (e.g. believing to recognize a person from afar, and when coming near (= more information) you see its someone else)
<kluk>
yes, and optical illusions, etc
<beneroth>
sometimes with hallucinations (artefacts with no/weak connection to outworld)
<beneroth>
exactly
<beneroth>
the model is then.. that there is kinda (very roughly) two systems (each made up of many layers of ML and feedback loops)
<beneroth>
one from the sensors "bottom-up" (or however we want to call it, not related to other bottom-up/top-down thingies)
<beneroth>
and one top-down "brain wants X" so to say
<kluk>
ok
<beneroth>
ah yes
<beneroth>
sidenote/important definition
<kluk>
go ahead
<beneroth>
mind = prediction machine
<beneroth>
as we defined in the very beginning with simple biological agents
<beneroth>
predicting changes in environment, predicting behaviors of others, and also fundamentally predicting our own behavior
<beneroth>
the bottom-up machinery is also full of prediction machines.. e.g. eye sensor predicting when there is a certain blip there, and I model this is part of an object, then also a certain other photon blip there on retina
<beneroth>
(e.g. perspective viewing through 2 eyes)
<beneroth>
etcetera
<kluk>
right, so the mind is another effect of running the neural network against reality at every cycle. it is a prediction machine because its outputs are "the most likely next frame"
<beneroth>
prediction machine = goal/cost function: make predictions fit the evidence, forward in time
<beneroth>
kluk, T
<beneroth>
so also a correction mechanism from top-down-system to bottom-up-system and vic versa!
<beneroth>
both correcting each other and trying to achieve a common "understanding" of whats going on
<kluk>
I can see that
<kluk>
Tell me if I arrived at a sensible conclusion from your exposition:
<beneroth>
in this view.. the thinking of moving an arm.. is not like function call "move arm coordinates", but more like modeling in the top-down-system "arm is here". this getting communicated (biochemical and electrical) to the top-down-system, which tries to fit it to the sensor input (muscles, taste sensations, etc)..finds a difference, does not correct the top-down system but does fit the bottom-up system.. aka muscle should give that sensor input = moving arm
<beneroth>
s/electrical) to the top-down-system,/electrical) to the BOTTOM-UP-system
<kluk>
Right, I see where you are getting with this.
<kluk>
Can I interject now or are you not finished yet?
<beneroth>
various psychological malfunctions would then be malfunctions in this systems or in the coordination between them
<kluk>
oh yes the examples :)
<beneroth>
e.g. autism = human face recognization, feeling recognition, etc.)
<kluk>
Yes (but... I can think of a counterargument when you're done)
<beneroth>
schizophrenia (which is most times hearing voices out of walls and such shit, not so often coupled with multiple personalities as it is common believed) = bottom-up system deliveres heavily noise, or top-down-system doesn't get the input from bottom-up-system
<beneroth>
(yeah not sure if I get this examples right.. they're mostly from slatestarcodex, not joscha, and I might misremember the exact significant parts.. but you get the rough idea)
<kluk>
that's amazing, this only goes to show how useful knowing about algebra/coalgebra can be in so many areas of reality
<beneroth>
haha, nice conclusion, agreed :D
<kluk>
So then now you want my opinion on whether this correlates with people thinking in OOP, yes?
<kluk>
or rather, whether it corroborates it.
<beneroth>
disassociation/dis-associative personality event (very rare but very extreme psychological thingy) (I guess multiple personality disorder fits the same) is a ofc very obvious in that the top-down-system got a new instance/lost memory/replaced memory eg.
<beneroth>
well
<beneroth>
my point, to connect this together (OOP conneciton here is not from joscha but mix from his stuff and our discussion, but I think he would agree)
<kluk>
right
<beneroth>
that human mind is a simulation so an OOP system and from that follows the tendency to model social structures also in a OOP way
<beneroth>
your turn. brb
<kluk>
Okay!
<kluk>
So I see your cards and I would argue back with that experiment I barely remember, where the monkeys wouldn't know why they keep beating up any monkey who tries to grab a banana from the ceiling, because they first conditioned some monkeys to do that, and then slowly replaced trained monkeys with untrained monkeys until every monkey would repeat the action of beating without having been trained explicitly.
<beneroth>
ah I know this one
<kluk>
There is also a human social experiment where they have actors pretending to be patients at a doctor's clinic and then everyone gets up and sits down again at the ring of a bell, except the person being pranked on who is not an actor
<beneroth>
(sidenote: this OOP system is obviously modeled on top of FP, and I guess some more mapreduce-FP being applied on top again)
<kluk>
and eventually they convince the non-actor to act according to them, without understanding why
<beneroth>
hmmm
<kluk>
so despite the first actors or the first monkeys having learned through simulation, the new pranked person / monkey learned in a different way.
<beneroth>
I think this can be explained very easily socio-psychologically without any regard on implementation of that as minds
<kluk>
okay I see your counterargument
<kluk>
let me think a bit
<beneroth>
synchronize with social group, to satisfy the need (= instinct = pretty hard wired goal to optimize for) to belong to the group (which in evolutionary term is very basic to most mammals, especially monkeys and humans could in many areas for most of the live of our species not survive without the herd, still true mostly, I think)
<kluk>
yes that is a valid counterargument and I accept it. I'm looking to see if I find any inconsistencies with this view...
<beneroth>
the monkey experiment.. I agree you can see the monkeys as functions with the believe/tradition being passed on like a context... Dawkins call these memes
<beneroth>
but that is than another level of resolution when looking at it.. does not conflict with the claim that the monkey minds are implemented using OOP objects
<kluk>
Right and memes were suddenly a useful concept because they are an algebraic unit of idea that can be composed, functorialized (image macros repeating references), and so on
<beneroth>
yes, T
<beneroth>
you are right, meme is a FP concept kinda
<kluk>
agreed, does not conflict, at least at first it does not seem to.
<beneroth>
its algebratiation
<beneroth>
or however this word is..
<kluk>
yes, algebraization probably, any formation is artificial anyways as algebra is an arabic term which was never used in ancient greek
<beneroth>
well english allows to make up words pretty easily :D
<beneroth>
well...algorithms.. algebras.. I guess the greeks called it platonic ideas :P
<beneroth>
which are FP, of course
<beneroth>
but also virtual most likely
<kluk>
algorithm is also arabic :)
<beneroth>
T
<beneroth>
no coincidence :)
<beneroth>
well
<beneroth>
no
<beneroth>
yes it is arabic
<beneroth>
not persian
<beneroth>
persian <> arabic
<kluk>
ah, interesting, I love this stuff.
<beneroth>
so the Joscha hypothesis.. gets rid of souls to explain things.. that was the part I could never solve before I heard this idea
<kluk>
how does it get rid of souls?
<kluk>
because it explains consciousness?
<beneroth>
souls as in extra/super-natural identifiers
<beneroth>
yes
<kluk>
ok.
<beneroth>
in my view
<beneroth>
my words
<kluk>
Yes, at first I think it is very convincing. I had not heard of it before. I am still mulling over it but it seems to be superficially right to me at first.
<beneroth>
I basically could not explain consciousness before without souls but also that explanations was then in conflict with quasi-materialistic natural science worldview
<kluk>
one way to explain consciousness without soul that I came across that is very algebraic is to consider that every bit of stuff (atoms, quarks or whatever) have some quantum of conscience in them
<beneroth>
though Joscha denies being a materialist in philosophical terms.. or kinda he says to accept that our reality is mostly virtual based and implemented on a objective reality
<kluk>
" or kinda he says to accept that our reality is mostly virtual based and implemented on a objective reality" ||-> that is a compelling phrasing.
<beneroth>
so we assume an objective (also: shared) reality, but only conceive it through sensors and modeling full of noice and whatnot.. and so objective reality is not experiencable directly (that I worked out long before)
<beneroth>
<kluk> one way to explain consciousness without soul that I came across that is very algebraic is to consider that every bit of stuff (atoms, quarks or whatever) have some quantum of conscience in them
<beneroth>
yes I know
<beneroth>
but then again.. is that an explanation? isn't that the ad-infinitum argument in different cloths?
<beneroth>
(aka who created the creators creator..)
<kluk>
"so we assume an objective (also: shared) reality, but only conceive it through sensors and modeling full of noice and whatnot.. and so objective reality is not experiencable directly (that I worked out long before)" ||-> except through careful algebraic bottom-up examination, then that is one tool to approach direct observation of reality.
<beneroth>
that is deduction, not direct experience, I argue
<kluk>
[19:21:01] <beneroth>but then again.. is that an explanation? isn't that the ad-infinitum argument in different cloths? ||-> I agree, it is not very satisfying.
<kluk>
[19:22:01] <beneroth>that is deduction, not direct experience, I argue ||-> precisely, so through logic we can approach direct observation of reality
<beneroth>
colors (as we experience them) are not real, they are certain radio-frequencies measured by our eyes and than modeled for us in this way
<beneroth>
precisely, so through logic we can approach direct observation of realit
<beneroth>
T
<beneroth>
!
<beneroth>
this was worked out by the ancient greek and also by the very advanced god-arguments in the middle ages (they just had some issues with the axioms)
<kluk>
how did the ancient greeks call this or refer to this idea? give me some googlables
<beneroth>
e.g. color
<beneroth>
ah I already wrote that
<kluk>
what would you say about the Stoics arguing that Logos is god? Logos is order, reason, logic, discourse, spoken word, etc
<kluk>
does this touch on that/
<kluk>
?
<beneroth>
<kluk> how did the ancient greeks call this or refer to this idea? give me some googlables | no idea. I would see the logical deducations of Plato and others as such things. or the greek who worked out that earth is a sphere and even calculated its exact diameters pretty close (with measuring the shadow of two pillars in two different cities)
<beneroth>
haha
<beneroth>
excellent question
<beneroth>
yes, it seems to me that it fits very well to very ontological implications/further aspects of Joschas philosophy
<kluk>
well, then I need to read this Joschas because I have been concluding along the same lines
<beneroth>
life is complex structure self-perpetuating through time
<beneroth>
he literally argues that.. eating and waste disposal.. is about extracting order and outputting entropy
<beneroth>
in the very sense of thermodynamics
<kluk>
right
<beneroth>
so all life tries to get rid of entropy by externalizing it
<beneroth>
to keeps its order intact
<beneroth>
Joscha believes the universe (reality of/containing everything) is computational in essence
<beneroth>
like that there is (maybe not discoverable for us) a step function going from one state of the universe to the next
<beneroth>
e.g. mandelbrot fractal.. I'm sure you know it
<kluk>
yes
<beneroth>
very simpel code, very extensive result
* kluk
is pondering
<beneroth>
so joscha tells its like we live in such a fractal, and we can make out some patterns and orders, though whatever we work out is probably only partially usable to predict and local-bound
<kluk>
wait, but we work out math (and computable math) and that seems to be usable universally, no?
<beneroth>
yes
<kluk>
so math has to be the stuff that makes the universe?
<kluk>
hence why you say the foundation is FP?
<kluk>
and Joschas says it
<beneroth>
and its not our brain, because we can see that bees model their homes as hexagonals, which is the geometrical optimum for border vs. area
<beneroth>
TZ
<beneroth>
T
<beneroth>
and hexagonals can also see in water/soap bubbles when they are moved together
<beneroth>
so math/geometry is definitely not (or surely not only) our imagination or a sideeffect of our brains
<beneroth>
i think he also stated something along the lines of: there is probably not a value for PI
<kluk>
yes, I am aware of that hexagonal honeycomb fact, very interesting indeed
<beneroth>
but that it is a function, which is only computed for as much resolution as needed
<kluk>
I am a finitist and I agree there is no PI, but that is the view of every constructivist mathematician now I suppose.
<beneroth>
that lead him also to suspect that quantum computers might not be possible
<kluk>
In fact I had a recent debate with two math PhDs about whether .9 repeating is 1
<kluk>
I agree quantum computers will not be possible
<kluk>
very interesting he and I have arrived at similar results but again, not very surprising if you start from a computable foundation
<beneroth>
because it would be outsourcing calculations to the universe in essence... Joscha suspects that this values are not observable because they don't exist, they don't get computed
<beneroth>
T
<beneroth>
he studied CS and philosophy
<beneroth>
is a strong AI researcher...
<kluk>
Yes but I sort of think AI will not be possible for the same reason (that it would be outsourcing calculations to the universe and only we can do that with neurons because they are made out of universe stuff)
<kluk>
I think that is where he and I part ways and I am curious to learn why
<beneroth>
I think here I disagree, and Joscha too
<beneroth>
T
<beneroth>
well because
<beneroth>
the computation is universal
<beneroth>
doesn't matter if implemented in biochemistry or in silicon, that is no fundamental difference
<kluk>
but neurons connect to sensors that connect to reality, whereas the cpu does not do that.
<kluk>
cpu doesn't become wetware
<beneroth>
now you sound like an embodyment-ai-follower
<beneroth>
no
<kluk>
(I think you probably think I am just stuck in the old paradigm now)
<beneroth>
but your brain is also not conciouness
<kluk>
hahah
<beneroth>
the software running on it / implemented on it, is consciousness
<beneroth>
(insofar it is not only a big illusion.. but this is irrelevant)
<kluk>
I understood the argument, but I think the argument is more an observation, and now I am arguing that it only happens because neurons are algebraically made of universe stuff which allows us to delegate computation to it. We have an interface to it.
<kluk>
no?
<beneroth>
afaik embodyment is not an overly old paradigm
<beneroth>
no
<beneroth>
the computation is laws of physics, the rest follows on top of that
<beneroth>
Joscha words: universe seems to be some sort of physic simulation and we are some yeast in the cogs
<beneroth>
:P
<kluk>
ah ok, I can work with that example and give my own equivalent
<kluk>
give me a sec
<beneroth>
other angle (also Joschas arguments)
<kluk>
go on
<beneroth>
he agrees/claims: humans are the most advance "intelligence" probably the only (fully?) consciousness intelligence
<beneroth>
on our time-speed
<beneroth>
in one interview (I think I can send you the link later, should be able to find it) he argues...
<beneroth>
it might well be possible that trees (or some of them) are consciousness and intelligent life (in the sense of having models of environment and manipulating environment etc)
<beneroth>
but not on our timescale but a much larger one
<kluk>
so to compete with that example, I would say that the physical quanta (atoms, quarks, cords, whatever) are SKI combinators that the universe is a cpu for (very simple cpu die that would be). Therefore, it doesn't matter that we simulate it with a silicon cpu, because that silicon cpu is not using the neurons that arrange particles in such a way for the universe to run it for us. We are always having to run the cpu program on the cpu, there
<kluk>
is never a connection to the universe's cpu.
<beneroth>
e.g. he jokes maybe humans function of the species was to put all this CO2 in the atmosphere again! because trees kinda happened before there was bacteria etc. to fully digest/recycle them, hence oil
<beneroth>
there is no universe's cpu (well maybe, outside, dunno, irrelevant)
<beneroth>
the universe IS the computation
<beneroth>
we don't connect to it, we are part of the simulation running
<beneroth>
inclusive the nested simulations implemented in our biological bodies
<kluk>
[19:43:05] <beneroth>it might well be possible that trees (or some of them) are consciousness and intelligent life (in the sense of having models of environment and manipulating environment etc) ||-> I think if you observe how their roots behave (admittedly difficult, since its under the earth, but there have been dug up lands where there were trees and we see how they act(ed)) it becomes very clear that they are conscious.
<beneroth>
well unsure if consciouness is already required for that level of agency
<beneroth>
e.g. one nice fact.. the smell of fresh cut grass.. that is actually a defense mechanism of grass, with the intended effect to lure predator animals upon the grazer animal which attacks the plant
<beneroth>
but that doesn't require a full blown simulation, that can be hardcoded and be the result of simple genetic algorithm + evolutionary pressure/filtering
<kluk>
wow, very interesting
<beneroth>
another viewpoint (my words, or from some other source than Joscha)
<beneroth>
are humans using potatoes?
<beneroth>
or are potatoes using humans for procreation ;-)
<kluk>
commensalism
* beneroth
needs to look that up
<kluk>
"an association between two organisms in which one benefits and the other derives neither benefit nor harm"
<beneroth>
ah yes
<beneroth>
T
<kluk>
so here is the thing
<kluk>
I think there is one vector of attack to this argument that you just exposed
<beneroth>
so big trees will benefit from us bringing that C02 back into athmosphere which was bound underground for millenia
<kluk>
namely this:
<kluk>
[19:47:42] <beneroth>but that doesn't require a full blown simulation, that can be hardcoded and be the result of simple genetic algorithm + evolutionary pressure/filterin
<beneroth>
so maybe human species is just a conspiracy of plants :P
<beneroth>
(half joke)
<kluk>
hahah
<beneroth>
pls expand
<kluk>
so if for some beings they do not require full simulation, then we could say that perhaps all "primitive" beings do not require full simulation until pigs dogs dolphins octopodes and humans get into the picture
<kluk>
i.e. until what we commonly call consciousness can be recognized
<beneroth>
T
<kluk>
would that immediately be unacceptable to Joschas?
<beneroth>
no
<beneroth>
that would be in line with his arguments, I believe
<kluk>
okay, so then I can tie this into another idea (!)
<beneroth>
ah, exciting!
<kluk>
that is very similar and shows how many people have been figuring out this duality
<kluk>
have you heard of the packer/mapper duality?
<kluk>
the duality I first referred to was that between simulation and the more primitive running of functions (like those selected by genetic algorithm for instance)
<kluk>
"Most people start off as Packers, but only some of them take those packets of information and try to correlate them, becoming Mappers to some degree or another. Most kids go through a "why?" stage in their life. A Mapper parent will likely help them develop into Mappers as well. A Packer parent, who can't give them answers to "why?" is more likely to result in them never seeing interactions between the packets, with a high probability
<kluk>
that they will become Packers as well."
<kluk>
c2 is invaluable
<beneroth>
I need a packer definition
<beneroth>
I understand the mapper
<kluk>
okay, hold on
<beneroth>
from wikipedia
<beneroth>
but it has no packer definition
<beneroth>
<kluk> c2 is invaluable fully agree
<kluk>
A packer is someone who doesn't want to risk losing an important piece of information. If you are willing to ReFactor your thoughts, then you're a mapper. Mappers do their refactoring in the background, which is why they sometimes do their best creative work when their conscious mind is distracted. (Driving, doing manual work, etc) -- MikeWarot
<beneroth>
ok
<kluk>
Packing is like mapping in that you collect information, but differs from mapping in that you don't have any particular desire to simplify your mental map. Packers are the world's great storehouses of memory: they are the storytellers, the historians, those who memorize and repeat.
<kluk>
so they learn from simulation, top-down, and not from overthinking and simplifying, bottom-up
<beneroth>
very nice model, I didn't know this before, thank you for showing this to me!
<beneroth>
my point
<beneroth>
I guess it's a scale, not a either-or
<kluk>
Well, as he says it, most people start off packing, because you have no choice but to collect information, for instance a baby
<beneroth>
I'm primarily a mapper I think, but I've trained a packer skill to just accept/ingest information and delay the mapping to later (when I have more puzzle pieces) instead of shying away from ingesting that information
<kluk>
then you solidify some functions and start using them sharply
<beneroth>
T
<beneroth>
<beneroth> I'm primarily a mapper I think, but I've trained a packer skill to just accept/ingest information and delay the mapping to later
<kluk>
beneroth: do you know your mbti type?
<kluk>
yes I want to comment on that
<kluk>
that is very interesting, I often research and discuss how people think
<beneroth>
that I would mostly put on robert anton wilsons books.. well same with James Joice.. needs a packing before some mapping can be done eventually