<beneroth>
mbti: i did some good test some years ago (online), not sure if it still accurate..
<kluk>
I naturally enjoy doing the information gathering and letting my unconscious and daydreaming do the simplification for me, that I then pursue objectively.
<beneroth>
also mbti is also not without doubts.. but I found it a very nice/helpful model
<beneroth>
I read a lot
<kluk>
Have you seen the work of Dario Nardi? He basically shows mbti in the brain across several people's brain MRIs
<beneroth>
and when doing chores or traveling or sport I listen to podcasts.. kinda feeling I need to use the (life)time
<kluk>
me too, constantly reading. I can tell you read a lot.
<kluk>
indeed
<beneroth>
I see that :)
<beneroth>
we have both very broad knowledge
<kluk>
:)
<kluk>
on the mbti I am an INTP which perfectly explains my behavior
<beneroth>
I love discussing with you and hope we can continue to do that a lot
<beneroth>
it is a bit lonely sometimes without finding someone to understand half what i want to express and relfex on :P
<beneroth>
reflect
<kluk>
thank you very much, I appreciate that, I find it very interesting to exchange ideas with you too. If this bothers Regenaxer we could perhaps take it to some philosophy offtopic channel or wherever you want. I am also open to chatting via skype etc if you are ever up for it.
<kluk>
[20:02:39] <beneroth>it is a bit lonely sometimes without finding someone to understand half what i want to express and relfex on :P ||-> 100%
<kluk>
And as an INTP I really benefit from exchanging my ideas out loud as we are presently doing in this format
<kluk>
so it is of enormous value to me, I really appreciate your time and thoughtfulness you put into our discussion and I think we should keep in touch and exchange ideas as we probably are both people who are constantly running into new interesting ideas all the time with very few other people to share them with.
<beneroth>
same
<beneroth>
and no, as long as this doesn't interrupts/prevents any on-topic discussions/questions here, nobody minds, afaik
<beneroth>
picolispers are a self-selected group from all paths of life but often some pretty similiar principles/views
<beneroth>
i cannot find my mtbi result from (I guess many 5+ years already)
<kluk>
I have an enormous amount of interesting thoughts jotted down on a very large .txt file (many .txt files really) so any time you are up for some discussion about whatever, please hit me up, I am always interested and have time for a good discussion. I keep thinking of trying to make a podcast with my interests but as an introverted person I lack the drive (although I don't have any shame nor anxiety with dealing with people)
<kluk>
I could help you figure out your mbti if you are ever interested, I am a quasi-expert (and I know a real expert)
<beneroth>
I believe it was ENTP ? not sure anymore. certainly E, I remember "the most introvert of the extroverts"
<kluk>
[20:05:46] <beneroth>and no, as long as this doesn't interrupts/prevents any on-topic discussions/questions here, nobody minds, afaik ||-> ok, so long as I am not a burden on anyone, that's fine.
<kluk>
hahah, very interesting
<kluk>
I know ENTPs, we definitely would talk for hours
<kluk>
(as can be evidenced)
<kluk>
[20:06:10] <beneroth>picolispers are a self-selected group from all paths of life but often some pretty similiar principles/views ||-> indeed, one of the reasons I like it here is precisely this.
<kluk>
ENTP for you sounds like it could be, so I would not doubt it at first.
<beneroth>
well I guess I'm somewhat extroverted, but because of some stuff in my childhood socialisation and because of nerdism I not so socially skilled as might optimal
<beneroth>
but I enjoy my alone-time very much :)
<kluk>
that is very interesting, I am the opposite, as an introvert I am actually very socially skilled (even my extremely socially fluent friends tell me that) but I just don't care that much about engaging in it.
<kluk>
yeah, exactly, because I enjoy my alone time too much. I will talk to people when I am done reading. :)
<beneroth>
everything is trade-offs.
<beneroth>
even FP <> OOP, to close the loop :P
<kluk>
haha indeed. I will consider using OOP when their compilers do model-checking as good as my type checker. Otherwise I would like to free up my brain for less automatic-y things. :)
* beneroth
switching into picolisp mode
<beneroth>
what do you care so much about type-checking?
<beneroth>
either it works, or it fails and doesn't matter, or it fails and crashes obviously
<kluk>
well even in CHICKEN Scheme I code as if I had types, so it's really all about the equational reasoning it gives me.
<beneroth>
granted, I get (now) your completeness feature (and/= proving)
<beneroth>
but that is not required for most programming
<beneroth>
(when it is, it is very much required, and those situations must not be mixed up, yes)
<kluk>
well it is required for me to easily compose complex systems in my head :)
<kluk>
do you not find that equational reasoning frees up your brain?
<beneroth>
picolisper: don't do complex systems. break it down until you can easily hold in your brain
<beneroth>
<kluk> do you not find that equational reasoning frees up your brain?
<kluk>
I agree with that. There are no complex systems, only simple systems complected.
<beneroth>
well essential complexity is a thing
<kluk>
so with types it makes it easier for me to see that I am complecting in a composable way
<beneroth>
but so is part and conquer
<kluk>
that is why sometimes I even use something monadically shaped (gasp!) in scheme
<kluk>
when I want certain equational guarantees
<kluk>
yes there is essential and accidental/incidental complexity
<beneroth>
composable = in picolisp = just decide if its a symbol, a number or a list. then you can use it with everything that can work on that type.
<kluk>
yeah but it can be useful to have a type that represents an email that's a string that has already been checked, for example
<kluk>
see Perl's taint for a need for a type for values that came from the world
<beneroth>
if some extra constraints rules apply to the structure of that number/symbol/list doesn't matter for most computation, and if it does, then you very likely will see/feel it very quickly when you do it wrong
<beneroth>
hm
<kluk>
but to restrict me to a few types is to also restrict the "holes" of functions to those few types. So now my functions need to have ifs all over to do the job of types
<kluk>
the truth is there is a natural "other level" above proofs which contains the propositions those proofs set out to prove
<kluk>
and scheme while being a wonderful representation of proofs, ignores representing propositions (types)
* kluk
clicks
<beneroth>
so I reliable know: in this part/layer, I don't trust the stuff. on the layer above/after it, I trust it
<kluk>
I've watched several videos of that guy's
<beneroth>
so basically: do not mix trusted vs. untrusted strings
<kluk>
beneroth: yes do not mix them, but without types, for me to not mix them, I must sprinkle ifs all over
<beneroth>
keep it separate. do not attach context to move around, just keep it code-topologically away from each other, I would say
* beneroth
feels now that his approach might be a bit more FP and the other (in a architecture way)
<beneroth>
s/and/than
<kluk>
than OOP?
<beneroth>
well you attach context/state (the tainting)
<beneroth>
explicitly
<beneroth>
is that not very OOP what you (or Perl) does here? :P
<kluk>
yes it is, because they don't have types :P
<beneroth>
I have more like two locations, one for nasty bits and one for washed ones, and a nice guard on the gate between.
<beneroth>
I don't need to know that the bit is good, its location-dependent
<kluk>
with types I could have a type called TaintedString which can only be constructed through a forced call to clean up the string from malformation
<kluk>
right, it's location dependent
<kluk>
I hate that
<kluk>
that is place-based programming
<kluk>
the opposite of algebra
<kluk>
I don't think in places :)
<beneroth>
yes and I only have one place where this string is moving from one to another code area, so if I get that place right than all is fine.
<kluk>
yes and "getting places right" is precisely the responsibility that types take away from me
<beneroth>
well it's not necessarily sequential :)
<beneroth>
kluk, it doesn't take it away from you. the place where you get it right is the type definition
<beneroth>
so yes, you define it more ephemeral
<kluk>
hmm can you rephrase that? I am confused now.
<beneroth>
but if the type is only used once at once place, than this is kinda unnecessary extra effort, no?
<kluk>
how are types more ephemeral?
<beneroth>
not local = ephemeral
<kluk>
and I don't understand "the place where you get it right is the type definition" because that is not a place/box/reference cell when the program is running
<kluk>
<beneroth>not local = ephemeral ||-> I don't get it :/
<beneroth>
<kluk> and I don't understand "the place where you get it right is the type definition" because that is not a place/box/reference cell when the program is running
<beneroth>
well but would you agree "it" is a "place" during coding step?
<beneroth>
aka "now I invest half an hour to focus on this and get it right, and then I can forget about it" ?
<kluk>
no. the type signatures do not even need to be immediately preceding the function implementation. there is no place.
<kluk>
but I use "place" with a very specific meaning. boxes at runtime
<beneroth>
therefore ephemeral. it is not near the use
<kluk>
that is the source of all confusion
<beneroth>
but it is *somehwere*
<beneroth>
ah ok
<kluk>
no, the types are gone after compilation
<beneroth>
no I use it very abstract
<kluk>
yes so we are using the term differently
<beneroth>
yes
<kluk>
I don't understand how you are using it
<beneroth>
<kluk> no, the types are gone after compilation
<beneroth>
so you trust your program does not change :P
<beneroth>
your types give no guarantees against nasty bitflippers :P
<kluk>
I trust the compiler is a function, it will give me some executable for some proof
<kluk>
they don't
<kluk>
nor against neutrinos
<kluk>
or solar flares
<beneroth>
hehe
<beneroth>
T
<kluk>
:)
<kluk>
Let me come at this from another angle
<beneroth>
as a picolisper (when picolisping) I don't separate between coding/compilation/running
<beneroth>
because in picolisp that separation doesn't exist
<kluk>
The way I see it, values *naturally* have types, so I like when a compiler recognizes the types, because I feel like coding with the help of the computer that way, and I feel I can think less and use my brainpower more productively.
<kluk>
beneroth: I don't separate between those either but as I said, even coding scheme I imagine the types and practice type discipline as if I were being typechecked.
<beneroth>
The way I/picolisp sees it: we just assume it works, and if it doesn't it crashes quickly and loudly and that is desired
<kluk>
Do you not get a dopamine hit (is that the right substance?) when you can get the computer to prove to you your program works before even running it?
<kluk>
(appeal to emotion, lol)
<beneroth>
(nice one)
<beneroth>
T, but I usually don't rely on the computer
* kluk
is trying to understand why he likes types so much
<kluk>
I can say the same but I attribute that to following types in my head
<kluk>
hahahah
<beneroth>
OR I run the little pieces (repl) before combining them
<beneroth>
well ok
<beneroth>
granted
<beneroth>
I surely do typing in my head :)
<kluk>
to me the types are like "cheating" and "buying experienced discipline"
<beneroth>
including "this is a tainted string" "this is a washed string"
<beneroth>
yes, agreed
<beneroth>
but then.. the extreme form of that is C#, no?
<kluk>
no!
<kluk>
those are nominal types
<beneroth>
most time I spend in C# is typing :P
<beneroth>
ah yes
<beneroth>
true
<kluk>
right, because the compiler is not aware of any axioms
<beneroth>
they're not strong
<kluk>
so it cannot help you
<beneroth>
they're the worst of both worlds, agreed
<kluk>
nominal types are very silly concepts
<beneroth>
T
<beneroth>
agreed
<kluk>
yes, the worst of both worlds, great way to put it.
<kluk>
I code in SML even, because it is so pleasurable
<beneroth>
well the picolisp point is.. don't trust the compiler. don't trust someone elses code. just keep it simple.
<kluk>
it feels like playing with Lego
<kluk>
beneroth: I see the point you are making
<beneroth>
the people who write compilers are not fundamental more clever supergenious as you are
<beneroth>
(evidence: enough)
<beneroth>
keep it simple. split it into small units you can reason about.
<kluk>
beneroth: but do you understand that to me it's not about "trust the compiler" but "trust Category Theory (CT)" and haskell is a type checker for CT
<kluk>
beneroth: I agree with KISS and I practice it ferociously
<beneroth>
yes I can see that and I can see that in some cases this is the best approach
<beneroth>
I agree when doing a medicine software (or something which potentially can/will be used for that) it should be completely proven
<kluk>
beneroth: no I agree, I have looked at the code for writing an SML, it's understandable stuff, granted, attached to some theory that must be pre-visited.
<beneroth>
but most of the software is some business shit and for that it's not needed
<beneroth>
SML?
<kluk>
the genius is in using these natural patterns
<beneroth>
T
<kluk>
that are captured by CT and algebraic types
<kluk>
SML = Standard ML ?
<kluk>
do you know it?
<beneroth>
picolisp has A LOT of emergent properties which are not obvious on first (or even second) sight
<beneroth>
ah
<beneroth>
no xD
<beneroth>
Standard ML I know as term :)
<kluk>
SML is exactly Scheme but typed and with an ML syntax.
<kluk>
it is exactly scheme in every way.
<kluk>
very pleasant to use
<kluk>
I can write the same crazy call/cc code on both and they do the exact same thing, one typed, one not.
* beneroth
hasn't grokked the difference of Scheme vs. other lisp dialects. afaik its a larg lisp underfamily?
<kluk>
been there, done that.
<kluk>
Scheme is a lisp that wants to be as close to lambda calculus as possible. Lisp is a family of languages inspired by lambda calculus that then expand in different directions.
<beneroth>
T
<beneroth>
ok
<kluk>
[20:37:11] <beneroth>picolisp has A LOT of emergent properties which are not obvious on first (or even second) sight ||-> what's a good example?
<beneroth>
why so obsessed about lambda?
<beneroth>
(the scheme is, I mean)
<kluk>
I am sorry I cannot explain to you why I like types so much. I must think about this more.
<beneroth>
I mean: is that not different how SOAP was obsessed with XML? a lot of nice theories and models but mostly useless/ineffective in practice
<kluk>
If I know my CS history correctly, Scheme was born out of research into new computer science concepts, and the need for a platform on which to carry out those experiments.
<beneroth>
(about scheme & lamdba, not types)
<kluk>
So like Haskell is for CT today, Scheme was for Lambda Calculus.
<beneroth>
so.. it's CS research
<beneroth>
not practical applications :P
<beneroth>
(absolute legitimate.. but different tasks, different tools)
<kluk>
They were doing research into models I believe, or actors, and ended up finding out that lambda calculus represents those concepts in a more workable way
<kluk>
yes Scheme came out of CS research
<beneroth>
lisp came out of a teacher trying to explain software :P (simplified but funny)
<kluk>
And Simula came out of the need to simulate ships docking or some other banal thing.
<beneroth>
ah
<kluk>
and that's where we got OOP from.
<beneroth>
Simula influenced C++
<kluk>
and Smalltalk.
<beneroth>
Smalltalk is connected to Simula?
<kluk>
<beneroth>lisp came out of a teacher trying to explain software :P (simplified but funny) ||-> very much so
<kluk>
The lambda lectures are amazing, I learned a lot from them
<kluk>
Smalltalk comes directly from the ideas of Simula
<kluk>
Alan Kay saw them and thought of minimalizing them
<beneroth>
ah okay, this part I didn't knew
<kluk>
Simula is ground zero for OOP
<beneroth>
ha lets try this angle!
<kluk>
ok
<beneroth>
so I guess we agree that OOP is not surviving/driving purely on popularity (as PHP does ever after it's initial success against perl)
<beneroth>
?
<beneroth>
(or well, lets say popularity + non-technical aspects)
<beneroth>
(so in that view, C#/java also were/are driven mostly by non-technical aspects)
<kluk>
Sorry one last thing before we move on:
<kluk>
<beneroth>I mean: is that not different how SOAP was obsessed with XML? a lot of nice theories and models but mostly useless/ineffective in practice ||-> but CT is proving fruitful in many areas including physics, so it pays to learn those patterns and apply them, it shortens code and effort immensely (by frontloading them onto the learning phase).
<beneroth>
oh I don't disagree. CT and FP is useful, sure. it's good. but that doesn't automatically mean: best for every task
<kluk>
beneroth: we agree that OOP is not surviving purely on popularity but the fact that most people think in OOP. I mostly agree with the arguments you presented, though new to me. Previously I was more of the opinion that people think equationally, but I suppose that is only when they are consciously trying to figure something out for themselves; otherwise, simulation-mode kicks in and allows most people to program without knowing any math.
<beneroth>
T
<beneroth>
very good points!
<beneroth>
good wording, I try to remember
<kluk>
beneroth: it may not mean best for every task, as lenses prove it, but I would still say an FP foundation is best for every task, and that does not require types but does require evaluation-by-reduction as opposed to evaluation-by-sequencing
<beneroth>
so
<beneroth>
you say: use a lisp dialect :P
<beneroth>
we can agree on that :P
<beneroth>
otherwise: Greenspun's tenth rule
<kluk>
anything that works by reduction like lisps is fine. Because reduction forces algebra as can be clearly seen in F(X) -> X which is the formula for algebra where the arrow is clearly reducing the complexity of X where it first had a complex context and then after the arrow it doesn't anymore.
<beneroth>
hm
<beneroth>
assembly is FP, yes?
<beneroth>
hmmm
<beneroth>
(I'm unsure)
<kluk>
That is the opposition that is fundamental between OOP and FP and that is where I say FP is always the best because there is no "foundation" at all for coalgebras (both literally and metaphorically, meaning coalgebras are about final coalgebras and don't have initial objects (axioms) from which to derive (inductively) new objects, and metaphorically that Coalgebra is a mathematical field still in its infancy and barely researched which is
<kluk>
why OOP languages do not come with a kripke-structure model-checker but instead rely on provenly-inconsistent (see Godel) nominal types based on Set Theory which requires FOL (First Order Logic) which is an inconsistent system (unless you eliminate LEM, the law of the excluded middle, and introduce bottom)
<beneroth>
you don't claim you escape Gödel with CT, do you?
* beneroth
believes there is no way to escape Gödel
<kluk>
[20:51:29] <beneroth>assembly is FP, yes? ||-> good question. Only orthogonal assembly languages can be seen as FP and hence Algebras, albeit very simple algebras, almost string-like. Non-orthogonal architectures such as 8086 where dividing two integers raises flags elsewhere are not FP but OOP due to those observable effects that change the system from one call to another.
<kluk>
beneroth: STLC escaped Gödel
<kluk>
STLC is proven consistent.
<kluk>
Yes I do claim we can escape Gödel, of course.
<kluk>
His problem only exists in set-based arithmetics
<beneroth>
ok, I need to learn about that
<kluk>
it does not apply to constructive anything.
<beneroth>
about assembly
<beneroth>
sooooo.. you're telling me, we build FP on top of OOP? - no, you are not. you are doing FP in source code, the compiler is turning it into OOP on top of assembly... ?
<beneroth>
because I came to the understanding (from our previous discussions) that OOP can be constructed on top of FP, and OOP can be built upon OOP.. (and FP upon FP, but then there is not really a upon maybe).. but I understand your view is that you cannot implement FP on top of OOP, in essence?
<beneroth>
hmmmm
<beneroth>
" cannot implement FP on top of OOP, in essence?" still unsure about this.
<kluk>
Yes, because think of a flip flop, it retains state, and cpus are made of it, so they are OOP or coalgebras. So the circuitry is a coalgebra and there is a very thin algebra of orthogonal assembly on top, or more coalgebra of non-orthogonal assembly on top. However I am not so sure about lisp-based cpus, I think they actually practice reduction on the die, in which case they are algebraic cpus.
<beneroth>
yeah lets ignore lisp machines for now
<kluk>
beneroth: well, if you are asking in terms of not every coalgebra is an algebra so how can a coalgebraic cpu give rise to algebras, the answer is that we use the coalgebra in a very dumb and rough way (i.e. not exploiting the fact is it a coalgebra) and we coerce it into acting like an algebra at a higher level language. If you look at a CPS transform, that is essentially what it does - exploit Von Neumann architecture in a dumb way (i.e.
<kluk>
just keep calling functions and forget the stack) to achieve an FP world.
<beneroth>
FP can be applied upon OOP data for sure, but thats not building upon
<beneroth>
CPS = Continuation-passing style ?
<kluk>
no, FP cannot be applied upon OOP. Think of a map. an FP map is free to run the function across the list in any order. Whereas if I map in OOP, even though "map is an FP-ish concept", it is still not taking advantage of what it could, as now it is just a glorified for loop in map's clothes, and map is now tied to a particular implementation and no longer symbolic/abstract.
<kluk>
CPS = continuation passing style, yes.
<kluk>
the reason complexity is constantly rising in the software industry is entirely accidental and based on the fact they chose OOP/coalgebra where *abstractions do not exist* - that's right, what OOP calls "abstraction" are mathematical "simulations".
<beneroth>
", what OOP calls "abstraction" are mathematical "simulations"." || agreed
<kluk>
Always remember OOP came from Simula; from a very early stage, before they knew the word coalgebra, they already knew OOP is about simulation.
<beneroth>
"reason complexity is constantly rising in the software industry is entirely accidental" || agreed
<beneroth>
" and based on the fact they chose OOP/coalgebra where *abstractions do not exist*" || I think I disagree *pondering*
<kluk>
beneroth: good! So I think now is more or less the breaking point since there are almost no beginner programmer jobs anymore
<kluk>
That is more or less my reasoning and reason why I am betting on FP
<beneroth>
<kluk> beneroth: good! So I think now is more or less the breaking point since there are almost no beginner programmer jobs anymore
<beneroth>
I disagree.
<kluk>
beneroth: the definition for an abstract is substitutability.
<kluk>
There is no substitutability in OOP-land.
<kluk>
for an abstraction*
<beneroth>
what is polymorphism then?
<kluk>
structural type matching
<kluk>
in FP
<beneroth>
I don't know that term
<kluk>
structural types are the axiomatic, inductive types of FP languages like SML, OCaml and Haskell
<kluk>
as opposed to the nominal types of C#, C++ and Java
<beneroth>
how is polymorphism not about substitutability.?
<kluk>
bascially structural typing is compile-time duck-typing (roughly)
<kluk>
it is about substitutability, but out-of-band, right?
<kluk>
because you yourself are not passing around the dictionary of functions for each type
<beneroth>
why out-of-band?
<kluk>
the compiler does it for you
<kluk>
hence out of your band that is the code
<kluk>
because types are naturally out of band from code
<kluk>
that is their usefulness
<beneroth>
well do you pass your dictionary of types around? or does the compiler do it for you (before removing them entirely anyways) ?
<kluk>
it's subtle and hard to appreciate, or rather takes time, I think
<kluk>
maybe I fell in love with CT too hard, too
<beneroth>
anyway
<beneroth>
in picolisp you do pass it around
<kluk>
the compiler does it for me
<kluk>
through a type
<kluk>
precisely
<kluk>
so in picolisp you are manually doing the work types would do
<beneroth>
no
<kluk>
in fact, moreso, you are doing the work that types naturally do
<beneroth>
nonono
<beneroth>
you pass a symbol around
<kluk>
yesyesyes :)
<beneroth>
the symbol has themethods
<beneroth>
they're on the symbol
<kluk>
but bring that stuff to lambda calculus
<beneroth>
so you pass them automatically with passing the symbol
<kluk>
there's no such thing as "a symbol with methods"
<kluk>
bring it to functions
<kluk>
if the methods are on the symbol, you are passing a dictionary around
<beneroth>
the symbol IS the directory
<kluk>
since you even know where they are
<beneroth>
same as the type is dictionary
<kluk>
right, so they are in-band and also your responsibility, yes?
<beneroth>
in what way?
<kluk>
the methods are part of code, and you call them yourself
<kluk>
hence you are managing the dictionaries manually in-band
<beneroth>
I don't see how this is the case, or if it is how it is not the same thing with types
<kluk>
ah!
<kluk>
So now we know of a realization that you are yet to experience and give an informed opinion on. That is very exciting for you! :)
<kluk>
So then...
<kluk>
what if I told you...
<beneroth>
important: I speak about the specific datatype "symbol" in picolisp :)
* kluk
puts matrix sunglasses on
<beneroth>
*drum roll*
<kluk>
what if I told you... that types naturally do that work out-of-band from code, making your code cleaner, shorter and easier to type (sometimes the code can be generated automatically from the types alone)?
<beneroth>
yes.. I claim I already have this all
<kluk>
but in-band
<kluk>
types do it out-of-band
<beneroth>
maybe it would make sense to explain the picolisp symbol type to you
<kluk>
you only have one band
<kluk>
code
<kluk>
go ahead, pleae.
<kluk>
please*
<beneroth>
if there is only one band, than there is no out of band
<beneroth>
:P
<kluk>
If you would explain it I would love to hear it and learn it.
<kluk>
I could be wrong completely.
<beneroth>
then you just vary your definition of what belongs to code and what not
<beneroth>
ok
<kluk>
beneroth: I was saying there is only one band in scheme. in typed languages there are two bands.
<beneroth>
symbol datatype in picolisp as multiple attributes: a name, a list of properties (key/values, keys are symbols again), and a value.
<beneroth>
values can be list/number/symbol (the tree static strong picolisp datatypes)
<beneroth>
the picolisp OOP is based primarily on the symbol datatype. symbol datatype is base for class and for object (in some sense, there is no difference between class and object in picolisp, though this is not exactly true in absolute terms)
<kluk>
hmm
<beneroth>
a class/object in picolisp is a symbol with a certain expected/assumed structure: member variables in the properties, and the value of the symbol being a list.
<kluk>
so structural typing dictates what is an object
<kluk>
but at run-time, so it's duck typing
<beneroth>
T
<kluk>
so aren't symbols like javascript functions?
<beneroth>
(no difference between source and runtime in picolisp)
<kluk>
they have some context they can carry in the form of a dictionary
<beneroth>
functions are lists in picolisp.
<kluk>
well, as I type the code, it's not running yet, so there is still a difference?
<beneroth>
as in all lisps I believe? dunno
<beneroth>
the value of the symbol (object/class), that lists, holds zero to many method bodies and the final element must be another list, which holds (in sorted order!) the list of parent classes
<beneroth>
<kluk> well, as I type the code, it's not running yet, so there is still a difference?
<beneroth>
not really
<beneroth>
the memory/RAM representation is a 1:1 binary encoding of the text source code
<beneroth>
(well it's all pointers and cells, but its EXACTLY the source code structure)
<kluk>
beneroth: okay, are you aware of Lua? The way picolisp is making objects is very reminiscent of how they spring up from nothingness in Lua due to the existence of implicit dictionaries available to every symbol.
<beneroth>
I know what Lua is but I don't know lua
<kluk>
[21:20:22] <beneroth>(well it's all pointers and cells, but its EXACTLY the source code structure) ||-> I see your point, I stand corrected.
<beneroth>
?
<kluk>
short story, Lua doesn't come with objects, but they are so simple to build, everyone makes them ad hoc in more-or-less the exact way you just described how objects are made in picolisp
<beneroth>
ah ok
<beneroth>
picolisp does this all the way up including a full ACID graph database with indexing and everything xD
<kluk>
yeah I never found a good enough reading material on exactly how the db in picolisp works
<kluk>
Would love to learn more.
<beneroth>
ok, I'm the expert on this
<kluk>
full ACID is quite a feat.
<kluk>
whew.
<beneroth>
well technically all transaction are serialized, but in practice this is not an issue
<beneroth>
it's not WAL based (if you know that database term)
<beneroth>
updates are in place
<beneroth>
so that is a big difference to like all other databases
<kluk>
everything is serialized when there is no compile/run time difference
<kluk>
I do not know the term WAL based, no.
<beneroth>
oh here I mean transaction serialization, that is something different
<kluk>
What does it mean? I've never heard it.
<beneroth>
you would call it "sequentialization" I would believe
<beneroth>
WAL = write ahead log
<kluk>
Hmm that is definitely beyond my knowledge.
<kluk>
Let me tell you the little I know about databases first from one RDBMSs refuser to another
<beneroth>
most databases don't actually update the database file(s) when you do an INSERT or UPDATE, they just write the change into the WAL, and some cleanup job later applies all changes to the real database file and truncates/empties the WAL
<beneroth>
this is mostly for write speed, but also to gain (session) isolation
<kluk>
I know MUMPS and its MDH data structure and how it's a B-tree on disk and how it allows for an easy database to use without any ceremony.
<kluk>
the end.
<kluk>
:)
<beneroth>
ok
<beneroth>
I don't think I know MUMPS though I heard the word before
<beneroth>
:)
<beneroth>
RDBMS are all arrays except the index which are btrees (probably also implemented in arrays, i presume)
<kluk>
it's nothing but an on-disk B-tree that always works
<kluk>
beneroth: right
<kluk>
I didn't know they relied on arrays but the indices are b-trees, that I knew
<beneroth>
yeah picolisp database is symbols stored in a binary format on disk (plio - picolisp I/O, also used for IPC/serializing picolisp over network)
<beneroth>
and btree for indexing, built from symbols
<kluk>
so can we use some examples?
<kluk>
in mumps/mdh I can do this out of the blue, with an empty database file: (global-set 'customer1 'address 'street "Baker Street")
<beneroth>
(new 'T) (create new database symbol = T for persistent) -> {2}
<beneroth>
{2} is a full picolisp symbol, just with a defined name
<kluk>
I can do that without having defined any schema at all, nothing at all, no ceremony
<beneroth>
ok
<kluk>
literally I can run that line and it works on an empty program with an empty database
<kluk>
ok go on
<beneroth>
you could that in pildb too, as on the lowest level it is a key/value database (based on the picolisp symbol datatype)
<beneroth>
but usually you would like to create a schema, which is a special kind of OOP
<beneroth>
some more mechanics in the background.. but basically the records are OOP objects
<beneroth>
and indexing etc.. is done with kinda "mixins" mixed in using method calling message mechanism
<beneroth>
e.g. you set value (put> 'Record 'name "kluk")
<kluk>
why does put> need to have all the OOP mechanics behind it? It looks like a very normal, boring function even.
<beneroth>
if 'name is indexed, than put> implementation of the indexing class would be called first, taking care of the indexing, and then this call (message) will be passed on to the field type handler (if there is one or multiple) and then finally just (put 'Record 'name "kluk") would be called to set the property of the symbol 'Record
<kluk>
ah...
<beneroth>
and uppon (commit) the symbol 'Record (and any index tree symbols or what else which got modified) will be safed to disk
<beneroth>
what else which got modified = all external symbols which got modified
<beneroth>
external symbols = symbols with certain (reserved) naming format which get persisted to disk (or loaded, lazy, upon access)
<beneroth>
the naming format is actually a kind of encoded pointer to the starting block of the storage in the database file
<kluk>
interesting. and how does the database handle program crashes? does it ever get corrupted? does it monitor for that or mitigate it?
<beneroth>
database files are split into equally sized blocks = every database does this (including filesystem etc)
<beneroth>
<kluk> interesting. and how does the database handle program crashes? does it ever get corrupted? does it monitor for that or mitigate it?
<beneroth>
when opening/starting the database (the function (pool)) you can give a name for a transaction file which takes care of this. so the changes are written to this transaction file and than in an atomic step transfered from there to the real database file
<kluk>
very nice!
<beneroth>
if upon opening the database this file is not empty = we crashed last time = well ok, delete this stuff and continue
<beneroth>
very simple :)
<kluk>
yep, sometimes all you need is an extra level of indirection
<kluk>
theorem for free
<kluk>
(not really but similar in spirit)
<beneroth>
if you don't specify this filename when calling (pool), well then all writes go directly to the database file, but then you kinda risk corrupting it in case of a sudden power out
<beneroth>
your control :)
<kluk>
beneroth: and is that call to pool costly or is it good practice to use it many times in the program so we can always be sure to minimize corruption risk?
<beneroth>
no other maintenance jobs required except running db garbage collection to free deleted blocks again for usage
<beneroth>
this is extremely maintenance-free for databases
<beneroth>
kluk, not costly, but you just open the database once in the beginning
<beneroth>
than keep the file descriptors
<kluk>
beneroth and then flush afterwards?
<beneroth>
flush is happening when writes happen during (commit)
<kluk>
but how do I know then that I am no longer in a state where if the program crashed the db would corrupt?
<beneroth>
program crash cannot corrupt the database
<kluk>
because of using pool, right
<beneroth>
you don't have multiple processes doing pool on the same database file
<beneroth>
if you want multiple sessions / multiple clients working on the same database files, you do pool on the database and then you fork from this main parent process
<kluk>
ah okay you just pre-empted my next question
<beneroth>
each client session / database connection has its own process, forked from this single parent, all connected via pipe to the parent
<beneroth>
the parent should not do anything more then (or not much more). it then serves as IPC handler for the sessions two coordinate
<kluk>
so here is one thing I don't understand about the db. Can I walk it from start to finish without knowing any key names?
<beneroth>
yes
<kluk>
so it is a tree and just one tree, then?
<beneroth>
root node is always the global variable *DB = {1}
<beneroth>
the root node is basically a list (well a symbol, but with the list in the symbol property list) holding the root nodes of the index trees
<kluk>
but can I do deep assignments, not like key/value but like key subkey1 subsubkey1 subsubsubkey1 value ?
<beneroth>
each index = 1 tree
<beneroth>
yes, because each record in database = symbol.
<kluk>
ah, very similar to the mdh then
<kluk>
I see!
<kluk>
I see the power of the symbols now
<kluk>
it's a pivot on which to make things general such as the database nodes
<beneroth>
the symbols must just indirectly or directly be contained in the top root node {1}
<kluk>
right
<beneroth>
else they would be considered deleted during database garbage collection (which must be explicitly run, so up to the programmer/application)
<beneroth>
you can also have multiple database files
<beneroth>
usually you do that to take advantage of having different block sizes in the files
<beneroth>
or like having one file to store b-tree bodies and another for normal records
<beneroth>
to minimize concurrent access
<kluk>
very smart
<kluk>
let me show you something, I would love to see the equivalent of some of this in picolisp one day:
<kluk>
beneroth: https://pastebin.com/WMP9HHea see especially the "further tests, suggested by "kluk" - I left the tests before that for some syntactical context
<kluk>
my example is straight from the mdh manual.
<kluk>
it creates a simple tree and walks it as if it did not know any keys.
<kluk>
as you can see everything is created without any ceremony.
<kluk>
(without knowing any keys of the subtree of the tree named "o" in that case)
<beneroth>
I see
<beneroth>
easily possible with picolisp out of the box
<beneroth>
just use it as key value database and you're good
<beneroth>
(then without schema, obviously)
<beneroth>
another point
<kluk>
one good thing about the mdh that I want to make sure I am communicating is this self-vivifications where I can say "key subkey1 subsubkey1 subsubsubkey1 value" even before I have ever created any of those subkeys or even that key.
<beneroth>
well
<beneroth>
symbols in picolisp (be it external/persistent database symbols or "normal" memory symbols)
<beneroth>
are just assumed to exist
<beneroth>
created in memory upon first usage
<kluk>
beautiful
<beneroth>
created in database file upon saving a modified external symbol present in memory
<kluk>
and everything created with new is a variable that will be persisted? do you have a link for some introductory usage of the db in picolisp? I can only find real-world examples but I feel I need some dumb examples first like the tests I showed you
<beneroth>
if already existing (in database file), loaded from database file as soon as you access the symbol (retrieving the symbol value or one of its properties)
<beneroth>
right (new) creates objects, not symbols, obviously
<beneroth>
I just stated symbols are always presumed to having existing as soon as you reference one
<beneroth>
:)
<kluk>
ah nice link
<kluk>
right
<beneroth>
(here the handy link to picolisp documentation with search box bottom left: https://software-lab.de/doc/index.html - same ref as in the download)
<kluk>
let me address one thing here. another reason I like types is that they help avoid the ad-hocness of (new ['flg|num] ..)
<kluk>
very nice thanks for that link too
<beneroth>
so (new) takes as first parameter: create as persistent symbol or not, then a list of parent classes, than initial member variables
<beneroth>
all of this is optional
<beneroth>
well ['flg|num] IS using types :D
<kluk>
hahahah
<beneroth>
flg is either symbol T or symbol NIL and num is number type
<kluk>
no, I get it
<kluk>
but it seems like that first position is doing a lot of work
<beneroth>
all missing arguments are always assumed to be NIL
<kluk>
and then with types I don't really have to keep track of argument positions/places like that
<beneroth>
yeah picolisp function overloading works like that..order and type of arguments... and this can be overused.
<beneroth>
but you can also used named arguments if you prefer, you just have to parse it yourself kinda :P
<kluk>
yes and in overuse there disappears discipline
<beneroth>
and function overloading = 1 function name = 1 single function, maybe being an interpreter for whatever arguments you pass
<kluk>
lol named arguments and parsing them myself, sound like the job that types naturally do in their own band :P
<beneroth>
yes
<beneroth>
picolisp is not preventing you to do something stupid if you really want to do it. it has sensible defaults, if you do something ugly the code will certainly also be ugly.. but if you really want, sure go ahead, it's not the VM's job to tell you how to live your life :P
<kluk>
no listen, this is not a criticism of picolisp, as I said I use Scheme a lot and it's got no types. I was just using that to try to explain why I have a bias for types.
<beneroth>
so some disciplined should be followed.. but its easy and a short list of best practices
<beneroth>
yeah sure
<beneroth>
I absolutely see your point :)
<beneroth>
you must also see
<beneroth>
a lot of picolisp language design choices
<beneroth>
well all
<beneroth>
are basicially influenced by two points:
<beneroth>
pragmatism/practicability & the fact that picolisp is very consciously implemented as a runtime, not as a compiler
<beneroth>
an optimized, minimalized runtime
<beneroth>
therefore also the "parse yourself bit".. kinda... no magic overhead implicit parsing existing anywhere
<kluk>
right, that point I get, however I think that this "transparency" of sorts is lost when I am required to use OO objects to interact with the database, now there is all of a sudden OO mechanics behind my call to put> and so on
<kluk>
if it were truly no magic, there would be no objects
<beneroth>
the 3 fundamental datatypes (number/list/symbol) are tagged in the pointer.. so they are strong static typed (the value, NOT(!!!) the variable. variables are just symbols used solely as names)
<beneroth>
kluk you are not forced to use it, you can do pure key/value like in your mdh code snippet
<kluk>
oh, so I did not understand that part
<beneroth>
if you want to use it, use it.. if you want to see what it does.. just look at the source (which you can also examine in the repl, also source = ast = runtime representation)
<beneroth>
you might want to use the OOP pilDb system for additional type checking/indexing/database trigger/whatever processing you wanna do automatically
<beneroth>
but if you don't need a schema, don't use it
<kluk>
also for the forms I suppose? probably it's the OOP mechanics that makes form work seamlessly with the db?
<beneroth>
if you only want a partial schema.. sure... you can always just (put 'Record 'prop value) into the external symbol and it will be saved, even when you never defined this property in a schema
<kluk>
nice!
<beneroth>
what do you mean with forms? GUI forms?
<kluk>
yeah that is what I want
<kluk>
yeah
<kluk>
the html forms
<beneroth>
well that is just operating on a symbol
<beneroth>
no difference between database record and object/symbol in memory
<beneroth>
no Object vs relational split/gap/border
<beneroth>
so basically database records are first class citizen :)
<beneroth>
or well.. it's just persistent symbols :P
<beneroth>
whatever angle you prefer
<kluk>
but for the form/variable interaction do I need to use the OOP mechanics?
<beneroth>
no
<kluk>
(I understand your point now)
<kluk>
okay
<beneroth>
also you don't need the form.l GUI to use the database
<beneroth>
I often use other GUI frameworks
<beneroth>
or none.. just cli tool with database
<kluk>
you mean custom GUI frameworks you created, or are there other GUI libraries somewhere?
<beneroth>
different layers (as in stratified software architecture)
<beneroth>
both
<kluk>
does it do any other gui besides html? just curious now.
<kluk>
yeah I haven't read the stratified architecture blogpost yet but I bookmarked to read it soon
<beneroth>
it's a podcast
<beneroth>
well a reading of a turing award speech
<beneroth>
and some comments/explanations by Eric
<beneroth>
<kluk> does it do any other gui besides html? just curious now.
<beneroth>
I guess most gui implementations for picolisp are web
<kluk>
I have read a few turing award speeches (fortran guy, the eiffel guy, another guy I forgot the name)
<beneroth>
but you can do other guys.. wrap Qt C++ libraries or whatever
<kluk>
I was thinking tcl/tk
<kluk>
I dare bit touch Qt
<kluk>
dare not*
<beneroth>
I don't like the C++ style of Qt
<beneroth>
I prefer the C++ style of the STL
<kluk>
I don't like everything about Qt :P
<beneroth>
yeah full of magic
<kluk>
all that magic and it does less than tk does
<kluk>
pff
<kluk>
moot
<beneroth>
hehe
<beneroth>
picolisp can easily wrap cli tools (so everyting that offers a meaningful piping or terminal functionality) and C-style shared libraries
<kluk>
I am afraid that if I move to picolisp I will miss the theoretical underpinnings. I don't know. I have to try it.
<beneroth>
that could be
<beneroth>
well maybe not
<beneroth>
hm...
<kluk>
beneroth: that is cool but in that respect it has in CHICKEN a fierce competitor as it is very good at both those things too
<beneroth>
dunno xD
<beneroth>
ok
<beneroth>
what about the database benefit? :P
<beneroth>
also if chicken is good at that
<beneroth>
why not mix it?
<beneroth>
call picolisp from chicken or vic versa
<beneroth>
take the best of both worlds
<kluk>
Well, I did a presentation on the mdh and CHICKEN users and implementers liked it a lot so they wrote a library for it. So now CHICKEN also competes with picolisp db-wise and it's my fault :X
<beneroth>
ok.. well come again when chicken support all kinds of indexes :D
<kluk>
yeah it won't do that ever :)
<kluk>
definitely the db in picolisp is more advanced
<kluk>
for sure, no question about it.
<beneroth>
including partial strings or even soundex
<kluk>
well soundex is easy to implement, I have written it myself from the specs, it's a bit fun even
<beneroth>
more complex database queries you can write in pilog, the prolog within picolisp
<kluk>
partial strings? is that somewhat like full-text search in sqlite?
<beneroth>
ah nice!
<beneroth>
yeah
<beneroth>
or like efficently find "beneroth" when searching "ero"
<kluk>
pilog is a very interesting thing, the mdh has nothing even close to that, as I said the mdh is just a self-vivifying disk-based hash-table (implemented as a B-tree, isomorphic to sparse multidimensional arrays)
<beneroth>
basically generating multiple index keys for one string value (substrings)
<kluk>
[22:17:12] <beneroth>basically generating multiple index keys for one string value (substrings) ||-> that is scary good
<kluk>
I don't think sqlite does that
<kluk>
and its full-text features are quite complete.
<kluk>
I really want to take advantage of picolisp's db and db-integrated gui
<kluk>
(variable-integrated GUI, I get it)
<beneroth>
you can also write your own index-generating code... e.g. custom full-text-indexer depending on content/domain. the wiki (also used for the picolisp.com website) has such one
<kluk>
very versatile
<beneroth>
I found the form.l GUI pretty hard to learn at the beginning, because its so different to usual web frameworks.. but I can imagine you have less problems with it, as it is.. well its kinda declarative, not structured/sequential programming
<beneroth>
<kluk> very versatile
<beneroth>
what I really love is
<beneroth>
the fact that most of the database stuff is actually implemented in picolisp code, not in the vm
<kluk>
yes it's definitely hard in the beginning. But many FP concepts were very hard to learn for me too, some took years, and I kept on pushing, to reap the rewards.
<beneroth>
only the very lowest level of writing/loading to database file and some IPC for session coordination is in VM built-in (mostly for efficency)
<beneroth>
all the btree stuff and the searching in btree etc.. all picolisp code you can insepct
<kluk>
[22:20:03] <beneroth>the fact that most of the database stuff is actually implemented in picolisp code, not in the vm ||-> nice, that is something bootstrappers like to do, I am one at heart
<beneroth>
*inspect*
<kluk>
very cool, very cool
<beneroth>
so if something goes weird, you can debug it all the levels down.
<beneroth>
not trivial, but like.. extreme levels more easy and possible than with usual databases
<kluk>
I will pick a small project to complete with picolisp
<beneroth>
good
<kluk>
then I'll bring it for your review :)
<beneroth>
yeah
<beneroth>
just come here into IRC and ask for help whenever you need some :)
<kluk>
and you can tell me where I am overspinning my cogs and could do with less code etc
<beneroth>
yeah
<kluk>
will do
<beneroth>
Regenaxer is very good at that. I learned a lot that way
<beneroth>
much I learned by just reading the code, I guess
<kluk>
yes he is, very patient and knowledgeable
<beneroth>
T
<beneroth>
well
<beneroth>
old hacker IRC social values apply
<beneroth>
"do not disrespect the lifetime of others"..
<beneroth>
but I don't need to tell you that. you are very aware of the limited lifetime thingy ;-)
<beneroth>
<beneroth> old hacker IRC social values apply
<beneroth>
or so I was socialized in gamedev programming IRC
<kluk>
I wasn't aware of that
<kluk>
those social values
<beneroth>
no? I guess it might be more of an implicit than explicit social value
<beneroth>
I mean like: when asking a question, don't ask the question 100 times, show that you tried to research for yourself and RTFM.. eg. state what you have tried or what your understanding is...
<kluk>
oh yes that
<kluk>
definitely I know about all of those
<beneroth>
you surely internalized that
<beneroth>
yeah
<beneroth>
exactly
<kluk>
don't ask to ask e.g.
<kluk>
etc
<beneroth>
that boils down to having respect for the time of others
<kluk>
"can anyone help me with blah?"
<kluk>
yeah don't do that
<beneroth>
and as some nice blog posts pondering about the hierarchy of programmers once formulated: the best programmers are very aware that their lifetime is limited and attempt to spend it optimally
<kluk>
Yes I very much don't want to waste anyone's time especially Regenaxer's
<beneroth>
no worries
<kluk>
hahah nice saying
<beneroth>
yeah that was a fun read.. dunno if i can find it again
<kluk>
I also don't want to burden him so again, if he thinks I am being offtopic I am happy to oblige.
<beneroth>
but the guy was.. I'm only level 3, look, ..but THOSE guys.. and me like.. hm..well fits all xD
<beneroth>
no worries
<beneroth>
people will tell you
<kluk>
have you delved into any FP-based FP languages like Haskell/OCaml/SML/Purescript/Elm/etc?
<beneroth>
the only thing with Regenaxer is not to throw unbased criticism against him.. stuff like "but but arrays" (there is an essay stating why he doesn't see a point in arrays in picolisp) etc.. such things piss him off (even if you don't mean it that way and its all just a big misunderstanding) and then he just leaves the channel :P
<beneroth>
kluk, no, only on a very superficial level
<kluk>
beneroth: got it. I like opinionated people like Regenaxer as I am like that, strong opinions due to my research, which I could be wrong one but I did some.
<beneroth>
I learned C/C++, dabbled in all the other mainstream stuff, though C++ is the best shit, then got convinced that it's overly verbose and inflexible and that I should learn a lisp... but was thrown off of common lisp because multiple platforms/propitiatory compilers even/libraries yeah thanks no had enough of that with C++ kinda. looked into ruby. looked into node.js. looked in some other lisps (but haven't found scheme & co then), then ended up here
<beneroth>
then fell in love with the database even more so
<kluk>
beneroth: let me tell you a very short story. One day I came to know about Haskell, I started trying to learn it, it was super hard, then I learned CT existed, I learned a bit of that, it was super hard, then life happened, fast forward to today when all of a sudden I am watching Bartosz Milewski tell me that "now we are very deep in Category Theory, okay?" and smile giddily. My point is, you don't know what you don't know, and you could
<kluk>
find out it's for you.
<beneroth>
kluk, yeah exactly. you can discuss with him, absolutely. but no kid whining, they should first learn a bit more :P
<beneroth>
kluk, true
<beneroth>
mapper vs. packer, eh? :P
<beneroth>
I stuck with C++ until it didn't satisfy my needs anymore. now I stick with picolisp
<beneroth>
and limited lifetime and currently it fits for the tasks I do
<beneroth>
etcetera
<kluk>
"looked into ruby. looked into node.js. looked in some other lisps (but haven't found scheme & co then), then ended up here" ||-> interesting, I also started with C/assembly (but no C++, I avoided that bullet consciously, always knew it was a terrible language), but then I did like you did, looked into ruby, and ended up doing a career track based on it, a few jobs.
<beneroth>
but yes, I like to learn more :)
<aw->
you guys are still awake?
<beneroth>
aw-, yeah discussing since 9 hours or more xD
<aw->
beneroth glad you finally found a worthy opponent ;)
<beneroth>
no opponent
<beneroth>
sparring partner maybe, but that also doesn't fit well :)
<beneroth>
we learn from each other :)
<kluk>
I get the limited lifetime philosophy but there are time-saving tricks based on patterns only understandable once you know some Haskell/CT
<beneroth>
but I know what you mean, thanks aw- :)
<kluk>
sparring, yes
<beneroth>
kluk, time-savings in the context of programming or everything?
<kluk>
more like exchanging stamps
<beneroth>
also: the guys who came up with Haskell/CT... they kinda proved there are other ways to come to this stuff, no? :p
<beneroth>
true
<beneroth>
stamp collecters
<beneroth>
bits if knowledge and some distilled wisdom
<beneroth>
aw-, please complain when we are too noisy or too OT, yes?
<aw->
kluk: hi, btw i also came to learn Haskell and found it way beyond my level of comprehension and interest
<beneroth>
haha
<beneroth>
aw-, I'm afraid it's the same for me
<beneroth>
I love logic but not math
<beneroth>
and the many special chars in Haskell throw me off
<kluk>
beneroth: well, at first in the context of programming, but they become mind tools that allow you to take incredible shortcuts. You should have seen what I did at work one day with Rails once I had control and some knowledge of monads - I flipped that thing on its head and put an entire programming team out of work after a year.
<beneroth>
kluk, yeah I know this way of things. in some (kinda very real) sense I'm a whole dev/IT department myself, too.
* beneroth
should charge more
<kluk>
aw-: hi aw-! At first Haskell seemed well beyond my level of comprehension too. I cannot stress this enough. However I have a long history of learning hard things eventually so I thought "if I stop, for sure I won't learn it" so I kept at it, took me 4 years to understand monads, and it took some painful CT learning too, and a couple more years after that and now I am comfortable with CT which I never ever imagined I would say these words.
<kluk>
[22:36:38] <beneroth>also: the guys who came up with Haskell/CT... they kinda proved there are other ways to come to this stuff, no? :p ||-> not from Coalgebra :)
<aw->
i dont really want to join the conversion, but just want to add that what Lisp adds for me, the big interest compared to **every** other language I've used, is that I can just write **ANYTHING** i can think of without the language limiting me. So the rest is just up to my knowledge of the available primitives and functions. I get all the rope I need ;)
<kluk>
[22:37:34] <beneroth>I love logic but not math ||-> let me say something about this
<beneroth>
kluk, well you still need to convince me investing so much time would give me a significant benefit in the things I do now over the way I do it now :)
<beneroth>
aw-, agreed!
<beneroth>
aw-, I feel FP/CT etc only would add proving to that.. which is nice property for some things, but really not significant for the stuff I currently primarily do
<aw->
what is CT?
<kluk>
[22:37:34] <beneroth>I love logic but not math ||-> I never knew I liked math either. The problem is most math after high school is no longer algebraic (see real analysis, integration etc) so it becomes "too hard" because you need to understand what they are simulating (it's no longer algebra but coalgebra, hence simulation). Once I understood there is a new constructive math that started in 1958 and is currently in the process of
<kluk>
replacing classical Set-theory based math, I understood that my liking for logic is exactly the same thing as liking constructive math (but not classical math(.
<beneroth>
aw-, Category Theory. the mathematical background for FP hypers :D
<aw->
i see
<beneroth>
kluk, I see, good point
<beneroth>
still no reason why I want to learn that instead of.. dunno.. protein folding
<kluk>
aw- "I get all the rope I need ;)" I definitely understand your perspective and share in it quite a bit.
<kluk>
[22:40:35] <beneroth>kluk, well you still need to convince me investing so much time would give me a significant benefit in the things I do now over the way I do it now :) ||-> I can try! First thing is you probably won't need the 6 years I needed because this stuff is better explained nowadays :)
<aw->
ok i'll let you two continue the discussion, ttyl
<kluk>
CT is the basis for constructive mathematics that started in 192.
<kluk>
1942*
<beneroth>
aw-, I really should stop and get some sleep :D
<kluk>
it's the new basis
<kluk>
the old basis was Set-theory on top of FOL (first order logic)
<beneroth>
aw-, just let us know when we overdo it, be it now or in the future. really ;-)
<beneroth>
kluk> First thing is you probably won't need the 6 years
<kluk>
beneroth: protein-folding can be explained by CT
clacke has joined #picolisp
<beneroth>
that is reducing the cost, but not pointing out a gain :P
<kluk>
aw- later \o
<beneroth>
hi clacke
<kluk>
aw- yes feel free to tell me to shut up and stop being offtopic at any time in the future
<beneroth>
aw-, and have a great day! :)
<kluk>
[22:45:22] <beneroth>that is reducing the cost, but not pointing out a gain :P ||-> I will mull it over and come back to you on that!
<kluk>
I think what convinced me was seeing people do code acrobatics on #haskell
<kluk>
I was impressed at how much work a single line could perform
<kluk>
and I knew there was gold there
<beneroth>
yes. still just a local minimum maybe, if you haven't done a global survey ;-)
<beneroth>
see picolisp. or see the language K if you heard of that biest.
<kluk>
K that has vau? or am I confusing languages?
<beneroth>
I don't want to belittle haskell, not in any way!
<beneroth>
just kinda saying I'm not looking for gold, I need better now :P
<beneroth>
vau? no idea what you mean with vau
<beneroth>
I mean K that incredible condensed language mainly used in finance
<kluk>
there was a scheme, I thought called K, which built fexprs with an operator called vau
<beneroth>
it does with one string what others do with a line of code (or many)
<beneroth>
but I think it's too condensed
<beneroth>
but then again I have no experience with kdb or that finance field
<beneroth>
hm
<beneroth>
I guess you would not like K, it's heavily context dependent I guess
<beneroth>
As a result, K expressions can be opaque and difficult to parse for humans. For example, in the following contrived expression the exclamation point ! refers to three distinct functions: 2!!7!4
<kluk>
well but then it turns into code golfing. the point is not to build small robots (coalgebras, compressing a bunch of sequence-based operators), the point is to just use cogs (functions) instead of whole robots (objects) so that we can really fit things in one line without syntactical golfing, just achieving it from the semantic compression alone.
<beneroth>
yeah, I knew you would say that :D
<kluk>
For example, in the following contrived expression the exclamation point ! refers to three distinct functions: 2!!7!4 ||-> damn!
<kluk>
that is nightmarish
<beneroth>
we want condensed semantic, not condensed syntax
<kluk>
yes!
<beneroth>
:)
<beneroth>
<3
<beneroth>
but I think I have to leave now
<kluk>
CT is the mathematical field that talks about semantic compression
<beneroth>
I really need some sleep and I have a heavy work pensum to finish this weekend :/
<beneroth>
kluk, so.. CT is a compression algorithm :P
<kluk>
please feel free, it was an excellent conversation, I am very glad we had it and I appreciate your time and patience and knowledge
<beneroth>
same!
<kluk>
beneroth: yes, that is what CT is :)
<kluk>
any time you want to talk and I am here hit me up
<kluk>
or feel free to email me at any time, my email is kluk, and it is at the domain sent.com
<beneroth>
you worded it perfect, so I just point you to your own words again (please feel free....)
<kluk>
:)
<beneroth>
ok
<beneroth>
I'm nearly always here .)
<beneroth>
:)
<beneroth>
cu
<kluk>
see ya!
<beneroth>
thanks & take care <3
<kluk>
you too!
<clacke>
hi beneroth
<clacke>
scrolled back a bit and saw mention of picolisp OO?
<clacke>
should I just read the channel history if I'm interested or is there documentation somewhere?
<casaca>
thanks for having this kind of conversation on a public medium. a bit off-topic, but i'd like to add a link to Klong -- http://t3x.org/klong. similar to K but without the ambiguity
<Regenaxer>
Yes, thanks to kluk and beneroth! A very deep and profound discussion
<Regenaxer>
Naturall, I don't agree with some points
<Regenaxer>
Like a "huge chasm there is between FP and OOP"
<Regenaxer>
But I think I have different definitions of FP and OOP in mind
<Regenaxer>
And I don't see why a simple language like Pil needs an Algebra, unless we want to prove language features which is not practical
aw- has joined #picolisp
<kluk>
Regenaxer: Thank you for the feedback, I am humbled. Chasm is an apt term; it does not imply a long distance from each other but does imply the difference is deep and not fully known yet - that is, significant and with long-term consequences and big risks in trade-offs due to unknowns. It must also be noted that while functional programming and category theory feed off each other in terms of their cross-pollinating proponents, such is not
<kluk>
being "too mathy" while forgetting math also defines coalgebras/OO objects and its math is ignored by its proponents.
<kluk>
the case between object-oriented programming and coalgebra theory - "The area of coalgebra is still in its infancy" (http://www.cs.ru.nl/B.Jacobs/CLG/JacobsCoalgebraIntro.pdf) and OO programmers are seemingly not as interested in studying its coalgebraic math - a ripe new field with doubtless many low-hanging fruits and opportunities for eternal fame - as FP programmers are in studying algebraic math. In fact OO sometimes accuses FP as
<kluk>
If I remember correctly, the denotational semantics for dynamic scope is simpler than that of lexical scoping, so supplying a full denotational specification of picolisp should be doable, or what am I missing?
<Regenaxer>
What do you mean with "denotational specification"?
<Regenaxer>
BTW, I think we should use "binding" instead of "scope" here
<Regenaxer>
PicoLisp is statically scoped (visibility of symbols) but dynamically binding
<Regenaxer>
(values of symbols being saved, set and restored)
<Regenaxer>
I CL, default is lexical binding, only special symbols are dynamically bound
<Regenaxer>
Scheme has no "binding", as there are no symbols. It has only variaales, which have no identity as first class symbols (afaik), so there is no binding, and the variables are indeed lexically "scoped"
<Regenaxer>
My government commands me to dig the garden. Away mostly now ...
<kluk>
maybe something like r7rs has for scheme - a denotational semantics
<kluk>
statically scoped but dynamically binding, I will have to think more carefully about that in order to see the big picture
<kluk>
going to bed now!
<Regenaxer>
Sleep well!
<Regenaxer>
My terminology is what was used in the 1980s. Perhaps the meaning drifted a little meanwhile
<Regenaxer>
But as I understand it, "scope" is greek for "vision" (telescope, microscope, periscope etc.), so it is the visibility of symbols
<Regenaxer>
In PicoLisp all (internal) symbols are globally statically visible and accessible (in the current namespace search order)
<Regenaxer>
But they are bound at runtime (function params, 'let' bodies etc.) to values
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
schulze has joined #picolisp
<beneroth>
hi all
<beneroth>
Regenaxer, good points!
<beneroth>
kluk, StampCollector vs ModelMaker.. good definitions, I was not aware of them.
<beneroth>
I'm definitely a ModelMaker. I hated the StampCollector-way of how most things are/were teached in my education
<beneroth>
I understand your claim is that OOP programmers tend more to be StampCollector while FP programmers tend to be ModelMaker by funding their programming models more immediate on formal math
<beneroth>
I guess I may formulate Regenaxer (if I may?) and my view as: ModelMaker is preferable, but it's not an absolute and you can also overdo it - resulting in "mental masturbation", loosing sight of the bigger picture by modeling at too high resolution
<beneroth>
what you do with math and theory is still running a simulation (if not in the program, than in the programmers head combined with the compiler).
<beneroth>
for practical applications, the complete resolution is often not required and often not useful or too computative intensive (= resource exhausting of programmer/compiler/etc)
<beneroth>
choosing the right resolution - well that is necessary and an art :)
<beneroth>
s/art/craft
<beneroth>
craft! not art.
schulze has quit [Ping timeout: 250 seconds]
<Regenaxer>
Interesting. StampCollector vs ModelMaker
<Regenaxer>
Sounds like what I call Elaborators vs Abstractors
<Regenaxer>
I think both are needed
rick42 has joined #picolisp
<rick42>
Hi all! I hope you are all well!
<rick42>
I was able to download and build pil21 with no problems on void (linux)
<rick42>
(Yeah I know I'm "late to the party" :)
<Regenaxer>
Hi rick42! Congratulation :)
<rick42>
:) Hi Regenaxer!
<Regenaxer>
Do you still use MacOS too?
<rick42>
not for programming .. in a long time
<Regenaxer>
ok
fs51 has joined #picolisp
<rick42>
for recording music only .. sadly
<Regenaxer>
we still have issues there with 'native'
<rick42>
ah
<Regenaxer>
(probably)
<rick42>
i thought jon (many months ago in the ml) said it was ok
<rick42>
well, i an "out of the loop" so thanks for the update
<rick42>
i am*
<rick42>
thank God for the mailing list. kept me wired in a bit
<Regenaxer>
good :)
<Regenaxer>
I think Jon did not test native calls
<rick42>
ah. i remembered he was going to abandon pil then tried pil21 and got back into it. :D
<Regenaxer>
right
<rick42>
is there anyone looking into the macos/darwin issues?
<rick42>
... like native?
<Regenaxer>
Not that I know of. tankf33der tested a little I think, and noticed native problem
<Regenaxer>
But he did not dig into it
<Regenaxer>
I think he has no Mac
<rick42>
ah tank has enormous coverage across platforms
<Regenaxer>
yes, but it was his wife's or so ;)
<rick42>
hahaha yeah. "mine" is my daughter's :D
<Regenaxer>
Perfect :)
<rick42>
too expensive otherwise :)
<Regenaxer>
T
<rick42>
did anyone record the last pilcon, and if so, where can I view it?
<Regenaxer>
I think there is no recording
<rick42>
ok thanks for informing me
<Regenaxer>
:)
<beneroth>
rick42, \o/
<rick42>
hey beneroth! \o
<beneroth>
Regenaxer, I would say: no model making without some stamp collecting (evidence to test/experiment with)
<beneroth>
hm.. yes I fully agree with you
<beneroth>
extrem stamp collecting: only copy&paste stackoverflow, without understanding
<Regenaxer>
yes, so different from a good elaborator
<beneroth>
extreme model making: getting caught by the beauty of the models and forgetting to solve the task / not affecting the real world
<beneroth>
Elaborators might be another dimension?
<Regenaxer>
yes, indeed
<rick42>
I've done the extreme model making before. lol!
<beneroth>
Regenaxer, what do you mean by Elaborator?
<beneroth>
I suspect it's a layer above StampCollecting vs. ModelMaking.. (which is kinda about data).. a layer above, about information vs. noise?
<Regenaxer>
It means application domain programming
<Regenaxer>
Abstractors do the easy part ;) System, APIs etc
<Regenaxer>
yes
<beneroth>
this way, Regenaxer ?
<beneroth>
:D
<beneroth>
I agree
<Regenaxer>
So StampCollector is different
<beneroth>
right, this is a dimension orthogonal to StampCollecting vs. ModelMaker
<Regenaxer>
Well, ModelMaker sounds like Abstractor to me
<rick42>
are these the archetypes of programs / processes? :)
<beneroth>
both Elaborating and Abstracting can be done in a more StampCollecting or more Modelmaker-way
<beneroth>
rick42, maybe. maybe it's just shit we just made up ;-)
<Regenaxer>
rick42, of people
<rick42>
ahahaha
<beneroth>
ah right. yes of people, not programs
<rick42>
ah thanks!
<beneroth>
unless you are on the level where you see people as programs (not in the utilitarian/judgmental way, but philosophical, the mind being software)
<beneroth>
Regenaxer, you can do abstractions in ModelMaker way
<beneroth>
or in stampcollector way :P
<Regenaxer>
I think a StampCollector does no abstracting
<beneroth>
Regenaxer, in our view "immutable programming" (as in clojure etc). is a more StampCollecting way then ModelMaker way of solving an Abstraction problem
<beneroth>
no?
<Regenaxer>
I think not
<rick42>
sorry to "break" your convo, but the mention of "nasty details" took me immediately to a problem I'm having of trying to clean data from third party sources and trying hard as hell to get them to say something (promise) about their data
<Regenaxer>
can be both
<rick42>
and they don't know themselves about their own data :(
<beneroth>
rick42, that's normal
<rick42>
hehehe
<beneroth>
just build many tests in your input processing and hit them up whenever they send crap :P
<beneroth>
close the feedback loop so they get an incentive to care/understand their own data
<rick42>
beneroth, but can you classify that "accidental complexity" or "on-purpose complexity"? hahahaha
<Regenaxer>
rick42, "to get them to say something" refers to the customers?
<beneroth>
use a whitelisting approach for testing data, not blacklisting. I mean: check if its good data, do not search for bad data
<rick42>
yes, the data providers
<beneroth>
rick42, actually I believe this would be essential complexity for the programmer
<beneroth>
it doesn't stem from technical/implementation details
<rick42>
beneroth, hmmmm damn you are right
<beneroth>
it stems from the domain
<beneroth>
Regenaxer, the StampCollector is the lowest on the Abstraction scale, agreed.
<rick42>
beneroth, Regenaxer: thanks guys!
<Regenaxer>
If at all
<beneroth>
Regenaxer, so I would say on the Elaborator scale,m the StampCollector would literally implement what the customer says, not what the customer wants - that requries ModelMaking
<Regenaxer>
yeah
<beneroth>
this is my argument for having StampCollector-ModelMaking on both Planes/Scales Elaborator and Abstractor
<Regenaxer>
ok
<Regenaxer>
bbl/afp
<beneroth>
cu
<Regenaxer>
:)
<beneroth>
kluk, I come to the impression that you got the definitions the wrong way around... the FP programmer is a diligent StampCollector (attempting to collect all the stamps through design/types/compiler) while the OOP programmer is a ModelMaker (a builder of a simplified simulation = model, hopefully with the right resolution) :P
<beneroth>
s/impression/suspicion
wineroots has quit [*.net *.split]
casaca has quit [*.net *.split]
clacke has quit [*.net *.split]
<Regenaxer>
ret
<beneroth>
welcome back :)
wineroots has joined #picolisp
<beneroth>
kluk, I base the above claim on the argument that we do not deny the StampCollector the potential of gathering an indeed complete collection (by skill or luck, within the limits of his/her definition of the collection), while a model will always be a simplification of reality (which doesn't prevent it to be bloated with additional pieces not contained in the reality the simulation is modeled after)
mtsd has joined #picolisp
v88m has joined #picolisp
wineroots has quit [Remote host closed the connection]
wineroots has joined #picolisp
<beneroth>
[OT] Feynman about asking Why :))))
<Regenaxer>
Richard Feynman?
<beneroth>
aye
<beneroth>
a funbag
v88m has quit [Read error: Connection reset by peer]
v88m has joined #picolisp
mtsd has quit [Remote host closed the connection]
rick42_ has joined #picolisp
mtsd has joined #picolisp
rick42 has quit [Ping timeout: 252 seconds]
rick42_ has quit [Quit: Leaving]
rick42_ has joined #picolisp
rick42 has joined #picolisp
rick42_ has quit [Client Quit]
fs51 has quit [Quit: Client closed]
rick42 has quit [Ping timeout: 264 seconds]
rick42 has joined #picolisp
rick42_ has joined #picolisp
casaca has joined #picolisp
rick42 has quit [Ping timeout: 245 seconds]
rick42_ has quit [Client Quit]
rick42 has joined #picolisp
<rick42>
beneroth: you talked about deleting your freenode account. Is this enough to do it?: /msg NickServ DROP nick password
<rick42>
beneroth, you mentioned this on the ML. thanks for any help
<beneroth>
yes this is enough
<beneroth>
well it asks then for a second confirmation (or did so)
<beneroth>
instead of /msg NickServ ... you may use /ns ....
<rick42>
done! thanks, beneroth!
<beneroth>
you're welcome :)
mtsd has quit [Quit: Leaving]
* kluk
looks around
<kluk>
[09:13:39] <beneroth>kluk, StampCollector vs ModelMaker.. good definitions, I was not aware of them. |> the C2 wiki is a very entangled cave of tangents of tangents of discussions, but instead of getting lost in the darkness, when I get lost it's usually morning and light again all of a sudden.
<kluk>
beneroth From the wiki: "A Model Maker will want to know why you push in the clutch when changing gear on a stick-shift car." |> OOPers have not shown yet the same curiosity to know why OO works the way it does - to study the mathematics behind it in order to discover improved and more complete versions of OO - as the FPers have shown curiosity to capture their field in a formal way. This capturing can be done for both fields but only one
<kluk>
is interested in knowing what is behind the scenes, what really makes the mechanism behind their paradigm work essentially.
<kluk>
beneroth Check out the stamp collecting of OOPers: SOLID, GRASP, GoF Design Patterns, Dependency Injection, Agile, TDD, BDD, UML, SysML, OOA, OOD, RUP, XP, DSLs, DRY, CQRS, Tell don't ask, DDD, Enterprise Patterns, Anti-patterns, Code smells, Missing Concepts. All those are invented, top-down, not from nature, just like stamps. On the other hand FPers collect models: functions, functors, monads, adjunctions, categories, arrows, algebras,
<kluk>
coelgebras even (the essence of OOP is just one model for us - formalized, unlike most of the OOPers'), etc.
<kluk>
All the FPers models are bottom-up, mathematical objects that had been discovered "in facets" several times beforehand in many areas of life.
<kluk>
Beforehand as in prior to their formalization.
<kluk>
They were formalized so we could stop remaking the wheel every time, like OOPers are happy to by applying GoF patterns etc onto their code again and again without ever being able to say UsePatternBlah OnThisObject AndThisOther go.
<kluk>
I agree that modelmaking perhaps is not the best name because "model" is best reserved for OOPers and simulation builders
<kluk>
But the point is OOPers deal with robots, while FPers deal with blueprints only.
<kluk>
That is why Smalltalk the OOP-est of all is full of actually-live objects, and why the FP-est of all Haskell is lazy, deader-than-dead.
<kluk>
So if we think in terms of RobotCollectors versus BlueprintMakers you won't go astray.
<kluk>
Example of BlueprintMakers overdoing it: e guy called Edward Kmett went into a deep math cave and came back with Lenses. Example of RobotCollectors overdoing it: Martin Odersky doesn't want to pass parameters explicitly so he invents an entire algebra (much much larger than lambda calculus) just to define "implicit parameters" and now his next goal is to not have to say in each function signature which implicit parameter it uses - this is
<kluk>
absolutely pointless work in my opinion, he is way too focused on how languages (robots) work and has completely lost sight of the goal of programming.
<kluk>
a* guy
<kluk>
I think Martin Odersky's work with Scala is a glimpse into why OOPers and RobotCollectors want to avoid any deeper mathematical formalization of what they do: because it will be pages and pages of algebra defining absolutely silly things such as "let me pass this parameter to this function without passing it through the argument list, and without it showing on the function signature" and other such non-generalizable nonsense definitions of
<kluk>
specific robots that help with accidental complexity. That is why OOPers love powerful IDEs and refactoring tools and resharper and so on full of helper robots and top-down tools, whereas lispers are coding on emacs, an editor built bottom up from a simple dynamic lisp with axioms.