<beneroth>
kluk, I disagree with your claims about OOP - I haven't observed these issues.
<beneroth>
kluk, have you considered there might be an even shorter way to your goals than the one you're following?
<beneroth>
also, what is your goal anyway? getting sotware done? getting it bug-free? which notions of bugs?
<beneroth>
most bugs in real systems are conflicts/misunderstandings of the process, usually between multiple users of the same software - technical proof of the technical correctness of the software will not help you the slightest with these.
<Regenaxer>
I agree very much, beneroth
<beneroth>
kluk, I claim that FP programming either gets nothing done or when, then is rarely following the strict fundamentals you claim as so important. Also you make it sound like A) your way is inherent to FP B) clojure et al is not FP, at the same time?
<beneroth>
haskell is great for CS researching, including language research.. but real world applications? yes some more than picolisp, but probably not even tremendous more - and in no way near the amount of what gets done in Lisp dialects in general.
<Regenaxer>
FP is a mindset, any language may just help to express it
<beneroth>
T
<beneroth>
same with all other paradigms
<Regenaxer>
right
<beneroth>
turing complete language = you can do it.
<beneroth>
kluk, Most software is in horrible C#/Java/PHP, the world runs on it. how do you explain that? the important part is to get the world running, the rest is hobby.
<beneroth>
kluk, you claimed that Category Theory is not affected from the Gödel incompletness theorems - any link to back this extraordinary claims up? and if you are right... then does this mean, that your FP is not affected by the Halting Problem? I'm not keen enough in math to spell out the exact relation between the Gödel issue and the halting problem, but afaik it's the same problem in different clothing.
<Regenaxer>
I think Gödel is not related to the halting problem, but a formalism being self-referential
<Regenaxer>
You can express self-contradictionary theorems
<beneroth>
yes, and they are even true, but you cannot prove it
<Regenaxer>
"this statement is wrong"
<Regenaxer>
yes
<beneroth>
Conways game of life has the same problems as Göden and Halting
<Regenaxer>
or self-contradicting
<Regenaxer>
not halting is not knowing when or if a result is found
<Regenaxer>
(I'm not firm in that matter either)
<beneroth>
"The concepts raised by Gödel's incompleteness theorems are very similar to those raised by the halting problem, and the proofs are quite similar. In fact, a weaker form of the First Incompleteness Theorem is an easy consequence of the undecidability of the halting problem."
<beneroth>
My current understanding is that the Halting Problem is a subset of the Gödel problem.
<beneroth>
---
<Regenaxer>
Anyway, real-world problems usually cannot be expressed in a formal way
<beneroth>
maybe we should create a second picolisp-* channel for these discussions
<Regenaxer>
:)
<Regenaxer>
No problem here
<kluk>
beneroth "It was not until Stephen Kleene and John Rosser were able to show that the λ-calculus was inconsistent as a logic when Church had to embrace types [76]. To over comethe logical paradoxes shown by Kleene and Rosser, Church, added types to his λ-calculus to obtain the simply typed λ-calculus [33, 12].
<kluk>
"There is one requirement a type theory must meet in order for it to correspondto a consistent logic. Computational constructs such as objects of type theory mustbe total (terminating). That is they must always produce a result."
<kluk>
"It is widely known that showing a type theory to be consistent can be a very difficult task, and often requires advancedmathematical tools. In fact a lot of the work going into defining new type theories goes into showing it consistent. The type theories we have seen up till now are all consistent"
<kluk>
It's part of our history... they made lambda calculus, it was proven inconsistent, then they made STLC and system F etc
<kluk>
Godel does not apply to STLC
<beneroth>
and they haven't yet proven it inconsistent, but they know it's not complete yet?
<kluk>
that is why we build our own numbers
<kluk>
i.e. we do not use set theory
<kluk>
etc
<kluk>
you can't prove a negative in constructive math
<beneroth>
ok, and how does this help you to make other humans more happy and/or productive?
<kluk>
only in classical, non-computable math
<beneroth>
(which is the goal of software)
<kluk>
so they can prove it consistent by providing an evaluator for STLC
<kluk>
happier by offloading thinking to the machine I am sitting in front of
<kluk>
I do less work in my head
<kluk>
by upfronting the requirement gathering
<kluk>
I don't like to do work in my head, especially when I am sitting in front of a computer, it feels silly
<Regenaxer>
I'd be happier too. So kluk please help us
<kluk>
I hate to think "wow the computer is here just waiting for me to type instead of telling me about the functions I could use one what values in order to complete the implementation of this function"
<Regenaxer>
good
<Regenaxer>
great!!
<Regenaxer>
perfect then, everything easier now :)
<kluk>
Regenaxer I want to help too, if I can. I apologize for being rude to cess11 but I did not mean to, I was simply speaking rhetorically, as I always am. I was not talking about him specifically, how could I, as I don't even know him? So please, first assume I am being rhetorical.
<Regenaxer>
I don't feel you were rude
<Regenaxer>
no problem
<beneroth>
kluk, I specifically asked about how it helps you to make OTHER humans happy. That was very on purpose :)
<kluk>
Thank you. I can also find better references for STLC is complete/consistent if needed.
<kluk>
beneroth okay, well kids can learn this stuff
<kluk>
and when I was a kid it was much harder to understand things-not-related-to-what-I-was-doing such as, you know, pointers, the usual stuff
<beneroth>
what about hypothetical Person Peter, who has a problem with getting his accounting done... ?
<kluk>
beneroth okay I have an answer for that, I think
* beneroth
had not much problems with pointers.. it's just indirections... maybe he doesn't understand well what other peoples problem here are
<kluk>
does that help show how I can control the level of security that I use the types to rely on?
<kluk>
since I am basically doing imperative code in FP?
<beneroth>
yes, but how does this help with Peters accounting?
<kluk>
So I first want to dispel this perception that everything will end up looking like a rigid, intractable theorem
<kluk>
beneroth: it helps that it makes it easy to see how any imperative program you may be thinking of can have a 1:1 representation in algebra, right?
<kluk>
no change at all
<beneroth>
Peter does the salary sheets for his employees by hand in MS Word. it takes too long. too many mistakes creep in.
<kluk>
no sacrifices, at first
<kluk>
either ask me a more general question or a specific one in a domain that I understand
<kluk>
that one isn't one.
<beneroth>
that is kinda the question.. the point.. what is the human life quality improving goal of your approach? more rigid software? good - for some applications. useless for others.
<beneroth>
picolisp is made on purpose to solve this kind of problems.. to speed up the time it takes to make a custom application for Peters needs, and to easy change the software when Peters needs change (which do all the time)
<kluk>
how about the web? Joe has a wordpress. He is wide open to all sorts of script kiddies. I make him a CMS in FP. We run it on a hypervisor. Now the website is much harder to hack and less likely to have errors. It will run unassisted for longer, costing less in the long run. Any plugins he might want from wordpress store we can make as a function in one hour and he pays for it only once.
<beneroth>
if you don't operate in that field, than your approach is no competition for picolisp and they cannot be compared meaningfully
<beneroth>
ok
<beneroth>
yeah that is a point
<beneroth>
btw. does the hypervisor matter? how?
<kluk>
I reject the notion that using free lambdas is more rigid than being constrained by the accidental/incidental fact that the computer is a Von Neumann machine.
<beneroth>
let's discuss the WordPress example :)
<cess11>
i've written web application code in f# and haskell, it's way, way harder to determine how hardened the result is
<kluk>
There are many assumptions you make that I don't have time to counter, I take the big ones first.
<beneroth>
cess11, interesting, please share your insights if us. I coded web applications in C++/WordPress/Ruby/C#/Picolisp, but never haskell or F#
<kluk>
"it's way, way harder to determine how hardened the result is" |> what does that mean?
<kluk>
beneroth the hypervisor is just to get rid of linux.
<beneroth>
kluk, that cess11 is speaking from experience, probably from very specific cases he could tell you more about if you ask :)
<beneroth>
kluk, why do you need a hypervisor for that? also whats wrong with linux?
<beneroth>
why not run bare metal then?
<kluk>
why do you need one, you don't, but that is one way to do it, that can be done with haskell. what's wrong with linux, it's an enormous attack vector.
<kluk>
right, the point is to run things on bare metal.
<beneroth>
ok why not bare metal?
<kluk>
we forgot that point some time ago.
<beneroth>
who is 'we' ?
<kluk>
it was called lisp genera I think. we, the followers of Symbolics :)
<kluk>
"worse is NOT better" we
<kluk>
us, here, lispers
<beneroth>
the huge attack vector.. how does it not affect your hypervisor setup when it would affect a linux application?
<cess11>
it's similar to graphql, determining if type providers and type design in the api are predictable is hard
<beneroth>
you assume a bit much when you say "worse is NOT better"... demonstratively it is (see the world runs on bad code..)
<kluk>
If I understand correctly the hypervisor is a thing glue so that an application can run without an OS
<beneroth>
kluk, wrong, you just emulate a bit more
<beneroth>
you still got linux (or another OS) underneath with all the attack vectors.
<cess11>
running a web server on linux doesn't make linux a threat vector
<beneroth>
T
<beneroth>
the TCP DDOS we just ignore.. (it's very doubtful you would solve it in your own bare metal thingy better than linux kernel does already)
<cess11>
your web server might have vulnerabilities and if it does virtualisation isn't going to save you
<beneroth>
T
<beneroth>
your data is in your application. your applications vulnerabilities make the data vulnerable. other vectors may exists but are usually a much lesser concern, so we can ignore it for this example.
<kluk>
beneroth: the world does not run on bad code, not after 1994 when this happened, https://en.wikipedia.org/wiki/Pentium_FDIV_bug , ever since then all code runs on an algebraic CPU.
<kluk>
why not learn from that and continue to apply it upwards? I think you are giving up too quickly :)
<kluk>
I always go back to the history of our field.
<kluk>
ostensibly the romans had 4-floored buildings.
<kluk>
with algebra we can build skycrapers.
<kluk>
It's about being content with what we have versus knowing we can achieve more.
<beneroth>
kluk, I don't disagree.. but see it this way: we haven't even got a coalgebraic way of creating software fast & good enough (picolisp is playing in that race) - and FP has even less so demonstrated much utility for that yet
<cess11>
sure, algebra is useful but the safety factor is much more important than correctness of your equations
<beneroth>
the problem is: how fast can you achieve it? with how dumb people?
<cess11>
in practical engineering
<beneroth>
cess11, T !
<kluk>
beneroth I am saying we must stop trying the coalgebraic way as it cannot be achieved there, our goals.
<beneroth>
kluk, the problem is, a bad solution is better than none or a perfect one which is delivered to late
<kluk>
But everyoen that tries FP in the industry reports earlier delivery
<kluk>
not later
<kluk>
so your premise is invalid
<beneroth>
do you have me a list of projects/companies ?
<kluk>
there are lectures on youtube about both successes and failures
<kluk>
I suggest starting from Elm testimonials
<kluk>
look at companies who adopted it
<kluk>
usually afterwards they adopt Haskell
<kluk>
it's because this stuff saves time
<kluk>
is more productive
<kluk>
simpler, easier to teach
<beneroth>
or because they get smarter programmers
<kluk>
just harder to learn if you are very invested in coalgebra
<kluk>
not smarter
<kluk>
kids learn this
<kluk>
9 year olds
<beneroth>
yes, and? I not denying that smartness can be trained
<kluk>
sons and daughters of the professors involved with the theory behind it
<kluk>
there is nothing smart about substitution, that is all that algebra is
<beneroth>
the better results of switchign to haskell could be entirely of switching/expanding staff
<kluk>
well you may think so, but that already looks like an unproductive line of investigation
<kluk>
You are just not going to accept that FP is easier, right? :)
<beneroth>
now you are taking illegal shortcuts in your proof :)
<kluk>
OOP requires one to learn all sorts of different abstractions... whereas everything in FP is an arrow, from one thing to another. And how do you use the arrow? You replace the terms... over and over again it's always the same.
<kluk>
Whereas for OOP every object is a unique interface, a unique robot.
<kluk>
That must be learned separately.
<beneroth>
I disagree
<kluk>
elaborate :)
<beneroth>
how is in FP not every function a unique interface for which you need to learn the specific calling conventions?
<kluk>
there's no specific calling conventions
<kluk>
no conventions
<kluk>
always the same interface: function takes valued types in a curried way
<kluk>
always that
<kluk>
I am really looking to simplify my life
<kluk>
I want one of everything
<beneroth>
arguing on that level, I can also say that OOP in picolisp is always the same.. you can call any method on any object, and every object is a symbol you can fully inspect.
<kluk>
one way to pass arguments, etc
<kluk>
that is not saying the same thing at all
<kluk>
okay, let me make it simpler
<kluk>
everything for me is lists of pairs
<beneroth>
make it more specific, let's discuss concrete examples :)
<beneroth>
ok
<kluk>
oops, maybe that's not a good metaphor to use between lispers...
<kluk>
(not to get confusing....)
<beneroth>
hahaha
<kluk>
but because a function a -> b is really a set of pairs... right? from domain to image?
<kluk>
in that sense!
<beneroth>
from car to cdr :P
<kluk>
hahah
<kluk>
so if a -> b is really (a,b) then everything has that one interface. But that doesn't help me make my point. My point is your premise for that equivalent is invalid. Equating "let's just use functions" with "let's just use these robots that can be inspected" is non-sequitur,
<kluk>
.
<kluk>
The essense is really to free ourselves from the Von Neumann machine.
<kluk>
That is the essence.
<kluk>
essence*
<kluk>
how one language or another has imperfections are tangential discussions
<beneroth>
yeah show me you get entirely rid of it. I claim you just cloth it differently.
<kluk>
reduction machines are not von neumann, that is widely accepted
<beneroth>
you still end up with new programmer getting into your code having to learn if he has to call foo() or bar() for what he needs to change, no?
<beneroth>
ah stop with your call to authority, we don't like authority :P
<beneroth>
show, don't tell
<Regenaxer>
OOP *is* functional in the same sense as other functions are functional: *if* coded in such a way that there is no dependence on (1) when, and (2) how often, a piece is evaluated
<kluk>
"Conventional programming languages are growing ever more enormous, but not stronger."
<Regenaxer>
Opposite to pil :)
<kluk>
"their primitive word-at-a-time style of program- ruing inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about
<kluk>
programs."
<beneroth>
also I tell you to stop argue with authority and you do what? :D
<kluk>
beneroth I am showing
<kluk>
you said show
<kluk>
He makes the points on the paper
<kluk>
It's part of our discipline
<kluk>
get acquainted with it if you are not yet
<beneroth>
oh I thought of having a real world example and you show me code in FP and in what-you-consider-not-FP and show me how the FP-code is shorter and easier?
<kluk>
beneroth okay!
<kluk>
I have that too
<Regenaxer>
Back to a real issue: What if I change the meaning of equality a little? For anonymous symbols?
<kluk>
hold on, give me some 3 minutes to find it
<cess11>
i think most adopters of elm come from gritty vanilla js
<kluk>
cess11 I can find others, would you like me to?
<beneroth>
Regenaxer, well I would say the problem is just again that you do not track ns.. else you could simply compare name + ns
<Regenaxer>
Like transients are equal if their names are equal
<kluk>
cess11 what is your opinion on that example, though?
<beneroth>
Regenaxer, but I understand why you don't want to track ns, I agree....
<Regenaxer>
I try
<Regenaxer>
ns ?
<beneroth>
namespace
<Regenaxer>
Not a namespace issue
<Regenaxer>
anonymous syms
<beneroth>
ah
<beneroth>
well..
<Regenaxer>
(new) and (box)
<beneroth>
anonymous sym = having the same name, each in their own namespace :P
<beneroth>
ok
<beneroth>
I see
<beneroth>
you want to find similiar anonymous syms ?
<beneroth>
Regenaxer, I would not change that in picolisp
<Regenaxer>
ok, yes, they have no name, so no namespace at all
<Regenaxer>
Not sure what is right
<beneroth>
Regenaxer, I would make them both inherit from same class and give the class an equal method
<cess11>
i think the comparison is weird
<Regenaxer>
We get "redefined" messages when reloading equal relations
<beneroth>
Regenaxer, the alternative is to make anonymous symbols a new datatype, no?
<Regenaxer>
Not a type issue
<beneroth>
but in FP everything is a type issue :P
<beneroth>
no
<beneroth>
I mean
<Regenaxer>
haha
<cess11>
one can take a look at the prominent haskell web app libraries, for example
<Regenaxer>
The question is what *means* equality for such symbols
<Regenaxer>
'='
<beneroth>
Regenaxer, you want to change how anonymous symbols get compared, but without changing how named symbols are compared?
<Regenaxer>
as opposed to '=='
<beneroth>
now they're the same
<Regenaxer>
(= (box) (box))
<Regenaxer>
now NIL
<beneroth>
Regenaxer, same thing as for ordinary symbols
<beneroth>
yes
<Regenaxer>
not sure
<beneroth>
I often build lists or trees of anonymous symbols
<cess11>
on the surface it might seem convenient to express apis as type declarations and hide boilerplate but it ends up in a position similar to laravel, there's a lot of magic going on that'll become problematic as soon as something breaks or needs changing
<beneroth>
Regenaxer, for that I need normal comparison
<Regenaxer>
yes, same problem
<Regenaxer>
hmm, ok, so let's keep it
<beneroth>
Regenaxer, anonymous symbol have a name, for all means and purposes... the address.. no?
<cess11>
haskell seems pretty sweet for implementing languages and closed dsls but the syntax is cumbersome and can't be adapted for interactive development
<Regenaxer>
(= "a" "a") -> T
<Regenaxer>
(== "a" "a") -> NIL
<cess11>
the latter is a drawback in all ml style languages
<Regenaxer>
(= (box) (box) -> NIL
<Regenaxer>
(== (box) (box) -> NIL
<beneroth>
cess11, good arguments
<beneroth>
Regenaxer, this is correct and how it has to be
<beneroth>
Regenaxer, consider storing anonymous symbols in lists and comparing them later.
<Regenaxer>
This does not solve anything
<beneroth>
Regenaxer, there you want the normal functionality which would allow multiple symbols to have the same properties, but different addresses/names, but you can still detect/find them
<beneroth>
(for A (parse-stuff) (push 'List (new NIL 'bla "sdf" 'foo "fgdf")))
<Regenaxer>
I talk about (rel 'nm '+Item)
<Regenaxer>
creates an object
<beneroth>
Regenaxer, my point is, changing the comparison mechanism would break other applications of anonymous symbols
<beneroth>
ok, about the daemon objects? :D
<Regenaxer>
For example?
<Regenaxer>
break which case?
<Regenaxer>
The question is
<beneroth>
having a list of multiple anonymous symbols from which some have the same values. encode some meaning by their index.
<Regenaxer>
what does it *mean* to be equal?
<beneroth>
(not a good example but best I can think of)
<Regenaxer>
not list
<beneroth>
Regenaxer, same name.
<Regenaxer>
individual symbols
<Regenaxer>
and no name
<Regenaxer>
that's the point
<beneroth>
if it has no name, then it can never be equal
<beneroth>
except to itself
<Regenaxer>
all other symbols compare by name
<beneroth>
so do anons
<Regenaxer>
(let X (box) (= X X)) -> T
<beneroth>
yes
<beneroth>
exactly
<Regenaxer>
(= (box) (box) -> NIL
<Regenaxer>
would give T
<Regenaxer>
if compared by name
<beneroth>
if you change comparison, you cannot differentiate anymore between this situation and one where it's different symbols with merely the same values
<Regenaxer>
but there is no name
<Regenaxer>
so *all* anos are the same
<Regenaxer>
it is not consistent
<beneroth>
no, all anons are different!
<beneroth>
name is a proxy for identity
<Regenaxer>
No: (== (box) (box)) -> NIL
<beneroth>
it's two different identities, its correct the way it is
<beneroth>
two humans without a name (yes such exist, even in our times) are not the same
<Regenaxer>
No, different identities are checked with '=='
<Regenaxer>
'=' means structural equality
<beneroth>
hm.. you have a point
<Regenaxer>
(= (list 1 2) (list 1 2)) -> T
<beneroth>
but then why did you ever restring symbol "=" comparison to names?
<beneroth>
:P
<Regenaxer>
(== (list 1 2) (list 1 2)) -> NIL
<beneroth>
*restrict
<Regenaxer>
it ie consequent
<Regenaxer>
symbols have name, value and props
<beneroth>
yes
<beneroth>
so why did you ever only compare with name?
<Regenaxer>
Problem is if there is no name
<Regenaxer>
for other symbols name comparison makes sense
<beneroth>
maybe because externals are the same, even when value and properties change?
<beneroth>
<Regenaxer> for other symbols name comparison makes sense | how?
<beneroth>
why?
<beneroth>
beside the external symbol special case
<Regenaxer>
We want (= "a" "a"), no?
<Regenaxer>
Externals are the same
<Regenaxer>
No need to look at the name
<beneroth>
ok, agreed. then turn it the other way
<Regenaxer>
they are goaranteed to be pointer-equal
<beneroth>
all anonymous symbols get an empty name?
<Regenaxer>
yes
<beneroth>
so this is your original proposal at the start of this discussion, I get? :D
<Regenaxer>
But (= (box) (box)) -> T would be bad
<beneroth>
why?
<Regenaxer>
yes
<Regenaxer>
hmm
<Regenaxer>
good question
<beneroth>
(= (box) (box) is the same as (= "a" "a")
<Regenaxer>
yes
<Regenaxer>
But (= (box) (box)) -> T "feels" wrong
<Regenaxer>
It would be trivial to implement
<Regenaxer>
cause comparing properties is a nightmare
<Regenaxer>
But then 'rel' never detects redefinition for example
tankf33der has joined #picolisp
<Regenaxer>
In my feeling, an anonymous sym is something between a symbol and a list
<cess11>
(= "a" 'a) -> T, it seems
<Regenaxer>
right
<Regenaxer>
all others compare just by name
<Regenaxer>
So (= (box) (box)) -> T would be consistent
<beneroth>
Regenaxer, my recommendation would be to not increase the number of concepts by changing this
<beneroth>
Regenaxer, no
<beneroth>
different names
<beneroth>
unknowns are never equal
<Regenaxer>
No, empty names
<Regenaxer>
not unknown
<beneroth>
no name = cannot have an name equal to anything
<beneroth>
(= (box) (box)) -> NIL is correct
<Regenaxer>
strcmp("", "") -> true
<Regenaxer>
(= "" "") is (= NIL NIL) = T
<beneroth>
(= "" "") = T :P
<beneroth>
aye
<beneroth>
strcmp("",) -> are you mad :D
<Regenaxer>
:)
<Regenaxer>
ok, let's keep it as it is
<Regenaxer>
and change 'rel' to do a deep comparison
<Regenaxer>
or 'def' in this case
<beneroth>
aye
<Regenaxer>
not 'def'
<Regenaxer>
only 'rel'
<Regenaxer>
Thanks!
<beneroth>
:)
<Regenaxer>
It is also dangerous to change such basic things
<beneroth>
T
<Regenaxer>
kluk should make an algebra of symbol comparisons ;)
<Regenaxer>
Then we know what to do
<beneroth>
I have the impression he doesn't like the concept of symbols :P
<Regenaxer>
really?
<kluk>
that would amount to an algebra for coalgebras, and "coalgebra is still in its infancy", and whoever does that will probably win a Turing Award.
<Regenaxer>
:)
<beneroth>
so I understood kluk correctly :D
<kluk>
the way I would solve this symbol issue is by not declaring = for symbols but instead declaring separate functions for each of the intended comparisons, with different names each,
<kluk>
I keep ending my sentences with comma when I mean period.
<beneroth>
good point
<Regenaxer>
separate functions would be a nightmare
<kluk>
In my ideal world each function would do one thing and have a separate name
<beneroth>
which agrees with my argument.. (=) is syntax for (compare-by-name) :P
<Regenaxer>
we need orthogonal equality checks
<Regenaxer>
It is not an implementation issue
<Regenaxer>
but one of meaning
<beneroth>
Regenaxer, well kluk is not wrong. your (=) defined over multiple datatype is kinda multiple functions in one
<beneroth>
Regenaxer, T
<beneroth>
I fully agree
<Regenaxer>
yes, but practical
<kluk>
what is an orthogonal equality check?
<beneroth>
that is also why kluks approach gen fix the implementation issues, but not the meaning issues
<Regenaxer>
= is recursive
<kluk>
then define (recursively-equal ...)
<Regenaxer>
(= <any> <any>)
<beneroth>
kluk, you mean recursiverly-* for everything :)
<beneroth>
it explodes :)
<Regenaxer>
can be a deeply nested structure
<Regenaxer>
beneroth T
<kluk>
beneroth I don't get it.
<beneroth>
kluk, see, that is why I say your approach is stamp collecting
<kluk>
why?
<beneroth>
kluk, you have a approach to elegantly collecting ALL stamps
<cess11>
writing out common lisp style function names is tedious
<kluk>
I'd rather have tedious code than overengineered code :)
<beneroth>
but in the real world, we want as less stamps as possible because humans are so memory constrained
<kluk>
but who is memorizing these things?
<kluk>
I use hippie-expand
<kluk>
I memorize nothing
<beneroth>
who is memorizing all your functions?
<kluk>
emacs
<beneroth>
and knowing when to use which one?
<beneroth>
so you just brute-force-intellisense everything you write a function call? :P
<kluk>
that is my job
<kluk>
I don't understand the issue
<kluk>
give me an example of your issue
<beneroth>
picolisp makes that job easier by having less functions
<beneroth>
which can usually handle whatever you put in them
<beneroth>
which is at odds with your approach
<kluk>
how do mathematicians deal with so many functions? they have no computers, no namespaces...
<beneroth>
but more practical
<beneroth>
kluk, they don't
<kluk>
they do, they can use them
<beneroth>
kluk, is not there that saying that the last mathematican who know ALL of math died in 1920s or so?
<kluk>
any time, with a pen on paper
<kluk>
they pull the function out of thin air
<beneroth>
only with a subfield
<beneroth>
like C++ programmers :P
<beneroth>
you cannot have whole math in your had
<kluk>
I didn't know about that saying
<cess11>
why would i want to fire up emacs to do picolisp development?
<kluk>
what whole math? Im lost.
<beneroth>
you can have whole picolisp in your had
<kluk>
cess11 : so I don't have to use my memory
<kluk>
I try to code with the least amount of mental burden possible
<Regenaxer>
The power of PicoLisp also comes from its orthogonality. A single function can be applied to many types. You can say PicoLisp has only *ONE* type!
<beneroth>
T
<kluk>
I am not trying to impress anyone
<cess11>
the repl has completion and docs already
<kluk>
I am trying to make code easier on me
<kluk>
repl and docs are out of band
<kluk>
emacs is in band
<Regenaxer>
vip also completes
<beneroth>
kluk, no, but you use emacs. a whole OS. instead of a plain BIOS terminal :P
<cess11>
if i'm working in php i use emacs, but not for picolisp
<beneroth>
kluk, our definitions of "easy code" are different
<beneroth>
easy code = paper is ok
<Regenaxer>
btw, vip now even completes the repl' history in the command window
<beneroth>
Regenaxer, nice
<kluk>
Regenaxer "The power of PicoLisp also comes from its orthogonality. A single function can be applied to many types." |> but what was the problem beforehand, when we had to apply each function to the appropriate type? There was never a problem for me. I feel that is one reason why it's difficult for me to see your point of view.
<kluk>
beneroth BIOS terminal now that's hardcore
<Regenaxer>
kluk, you are not used to thinking PicoLisp
<beneroth>
kluk, knowing all these individual functions without emacs is the problem
<kluk>
Regenaxer: in general I cannot juggle in my head this idea of overloaded functions. "functions that do lots of stuff depending on their inputs" are just "one wrapper function that selects which function to call based on the type" in which case why not just give me those inner functions?
<beneroth>
kluk, because you don't need to care
<beneroth>
you just call the function
<beneroth>
if it's not too wrong, it works as intended
<kluk>
beneroth: why would you want to know tons of individual functions without the help of a computer?
<kluk>
honest question
<beneroth>
I just want to find something equal, I don't care if the thing I search are numbers, lists, functions, symbols.. I just compare
<Regenaxer>
kluk, correct "selects which function to call"
<cess11>
there aren't tons of them
<cess11>
and you can just tab through them and use 'doc to read the documentation when unsure
<beneroth>
kluk, picolisp is about 500 functions. you don't even need most of them for most tasks.
<beneroth>
and you don't need to build many functions for your application in picolisp.
<kluk>
[04:35:49] <beneroth>kluk, because you don't need to care, you just call the function |> that's it, for me that is easier the other way around. the way you have it, I *have* to care because I never know if a function works on a type I want to call it on; it's easier if every function just tells me outright the types it works on; like legos tell you outright the pegs they fit and interlock with.
<beneroth>
well here is what your lack of picolisp shows :P
<Regenaxer>
No types is best
<beneroth>
most picolisp functions just work on every type :P
<beneroth>
we only have 3 types
<kluk>
beneroth I believe in searching for functions you need based on the type, that is the extreme version of not having to know function names and not having to memorize anything
<beneroth>
so many functions only work on lists... but what this lists are made of ---doesn't matter
<kluk>
see, I always want less work for me
<beneroth>
yes, we too
<beneroth>
we do it by reducing types
<beneroth>
and reducing functions
<kluk>
beneroth: "most picolisp functions just work on every type :P" again I will have to rely on conventions then. why can't the function just tell me?
<kluk>
I just think it's easier if every time I pick up something to use, the computer helps me by telling me right away, on what things it works.
<kluk>
I'm just lazy.
<Regenaxer>
yes
<kluk>
You folks are better than me mentally.
<kluk>
You can do all this stuff in your head.
<beneroth>
no
<cess11>
it's hard to do fast, iterative development on non-trivial datasets if you need to reason about sophisticated types and function versions
<kluk>
To me it doesn't really matter the names of things.
<kluk>
I search it, use it, forget it.
<beneroth>
we just don't care if it doesn't work. we just assume it works, and it does in nearly all cases. if it doesn't, it crashes, then we care.
<kluk>
it's all about taking things from one type to another for me. everything could be anonymous as far as I am concerned.
<kluk>
so you don't care about different things
<beneroth>
no
<beneroth>
exactly
<kluk>
but your not caring if it doesn't work forces you to memorize so much stuff
<cess11>
my most common application of picolisp is interactively developed, ad hoc dsl wrappers for mysql databases
<kluk>
cess11 I don't reason about any types, I have a dialog with the compiler using type "holes" and then it holds my hand and does half the work for me
<kluk>
again, because I am lazy, and the computer would other wise be idling in front of me
<Regenaxer>
PicoLisp does not compile, so the interpreter can decide at runtime
<Regenaxer>
for you
<beneroth>
kluk, how is that different from what we do with the repl, without even types?
<cess11>
sure you do, and you even need automated assistance to do it
<beneroth>
T
<beneroth>
good point cess11
<kluk>
deciding for me is not the help I need, I need visibility while I have the code in front of me, visibility into what will happen as it runs, while I look at the dead code on the screen, does that make sense Regenaxer ?
<beneroth>
outsourcing caring is not the same as not caring
<kluk>
cess11 sure I do what?
<cess11>
reason about types
<beneroth>
kluk, you should reduce what you to decide
<beneroth>
argh
<beneroth>
wrong wording
<cess11>
you decide whether something is Int or Maybe Int
<beneroth>
kluk, we reduced the amount of information we require to make a decision
<kluk>
cess11 : I ask the compiler "what goes here?" and it tells me "such and such type", I fill it some more, ask again, etc
<Regenaxer>
You want a separate 'print' funtion for every type?
<kluk>
cess11 If "asking" is "reasoning" then sure
<cess11>
in haskell you can't just slog through with type ambiguity and put in the strictness later like you can in picolisp, racket or even php
<kluk>
cess11 that decision of Int versus Maybe Int is good to do, it's part of the reality of the problem domain
<cess11>
you need to make a decision based on speculation before it compiles and lets you look at output
<beneroth>
kluk, it isn't in picolisp :D
<kluk>
beneroth right, that's the difference
<beneroth>
not just in picolisp (technically) but also in the domain it's no difference
<beneroth>
Peter knows perfectly well that salary finance numbers are decimals and not maybe decimals
<kluk>
if they can be null they are maybe
<kluk>
it depends
<Regenaxer>
PicoLisp handles even null in arithmetics
<kluk>
I don't feel the problems you identify with FP
<Regenaxer>
NIL it is
<kluk>
that is messy, no? nil is not arithmetic in reality
<beneroth>
kluk, I feel we are on the same road to simplicity, but I claim we're further ahead than you.
<kluk>
beneroth how so?
<cess11>
it's not identified with fp, it's purity and non-interactivity in haskell i'm complaining about
casaca has quit [Ping timeout: 268 seconds]
<kluk>
cess11 tell me more
<kluk>
cess11 have you looked into Algebraic Effects as the ultimate solution to purely modeling side-effects?
<cess11>
in picolisp i only very rarely use the object database and mainly write function ad hoc fragments i can move around or copy as needed
<cess11>
there are no ultimate solutions
<kluk>
in math there are.
<cess11>
math resides in fantasy
<kluk>
No, it resides on definitions.
<cess11>
which is fiction, fantasy
<Regenaxer>
T
<kluk>
definitions ~= fantasy
<kluk>
non-sequitur
<kluk>
I am trying to have a reasonable discussion
<Regenaxer>
fantasy = only in human brain
<Regenaxer>
even numbers don't exist
<Regenaxer>
only in mind
<beneroth>
only within simulation
<kluk>
You don't know that.
<kluk>
It's a hypothesis.
<kluk>
You frame it as certainty.
<beneroth>
we have multiple evidence for it and no against it, don't we?
<kluk>
for what?
<Regenaxer>
Numbers are a concept of the human mind
<beneroth>
Regenaxer, no..math is not just human
<Regenaxer>
where is a number in nature?
<beneroth>
Regenaxer, bees use same math
<Regenaxer>
I think it is
<Regenaxer>
a projection of the human mind
<Regenaxer>
just concepts
<beneroth>
no, there you are wrong
<kluk>
Regenaxer here is a number in nature: 1
<Regenaxer>
2 apples or 2 bananas
<Regenaxer>
humans detevt this structure
<Regenaxer>
detect
<beneroth>
Regenaxer, yes. but the structure exists outside human mind
<cess11>
what structure?
<beneroth>
else other animals would have different maths
<cess11>
they don't do math
<beneroth>
sure they do
<Regenaxer>
that 2 bananas and 2 apples share a common structure
<kluk>
A number is a function, you have to apply it to a type to see it. Apply it to apples and you see 1 as 1 apple.
<Regenaxer>
all mind only!
<kluk>
Animals sure do math
<kluk>
Youtube octopus puzzle
<kluk>
etc
<Regenaxer>
humans *are* animals
<beneroth>
Regenaxer, do you differentiate between human minds and other minds? or you say all minds are similiar?
<cess11>
i find pattern matching on a short sequence lengths to be a very weird definition of math
<kluk>
Regenaxer: but I am saying more animals than just humans know numbers
<Regenaxer>
We recognize only minds similar to eurs
<beneroth>
cess11, kluk is into category theory, a newer branch of math
<kluk>
cess11 what is pattern matching on short sequence lengths?
<beneroth>
Regenaxer, no, we can also recognize some other minds, I claim :P
<beneroth>
Regenaxer, recognizing something as a mind is not the same as fully grokking it
<cess11>
other animals can do crude counting but it's not elliptic geometry they apply when expecting winter
<beneroth>
Regenaxer, and I agree we cannot recognize all other minds
<kluk>
cess11 wrong, they can calculate volume and circumference
<kluk>
rats can
<beneroth>
cess11, bees do 5 dimensionsal math to give geospatial descriptions to each other
<beneroth>
just because it's probably hardwired in their brain and not in software does not change that they do it, I'd say
<cess11>
math is a creative activity
<beneroth>
paradise birds are very creative
<beneroth>
humans are not so special
<Regenaxer>
Even plants "know" fractals, but only because our mind maps thi concept. The plant does not care
<kluk>
so like programmer's don't care about theory?
<Regenaxer>
Se what means "exists"?
<kluk>
so most programmers are like plants? :)
<beneroth>
kluk, most people are, so probably most programmer, yes?
<beneroth>
nothing wrong with that
<beneroth>
doing the thing, is what matters
<beneroth>
knowing the theory, you probably can do it more consistently/reliably
<cess11>
i'd like to see the bee conference where they decided on notation for 5D geometries
<beneroth>
but if you don't do a thing, because you lack the full theory.. then you worse then the guys who just do something and often get it kinda right enough
<beneroth>
cess11, evolution :P
<beneroth>
so brute forced
<kluk>
so in the end the reason not to use FP is contentment with mediocrity?
<kluk>
What si the reason? I still don't understand.
<beneroth>
C# programmers also don't care about the code
<kluk>
cess11 : again, please stop taking these questions personally. I am asking about our industry, existentially, as per problems identified even by John Backus in 1977. It's a philosophical discussion.
<beneroth>
or SAP
<beneroth>
:P
<beneroth>
kluk, you are still discussing while we provide Peter with the means to automate his salary papers
<kluk>
I reject that that is an argument. You're throwing one example at me. and? Am I suppose to do the work for you of turning that into a proper argument?
<kluk>
What is your argument?
<beneroth>
my argument is, that theorizing is mental masturbation mostly
<beneroth>
fun activity
<beneroth>
not increasing human life quality in itself
<kluk>
we would not have computers without theorizing
<beneroth>
T
<kluk>
no air conditioners
<beneroth>
T
<kluk>
no sky scrapers
<beneroth>
T
<kluk>
no glass
<kluk>
no nothing
<beneroth>
maybe..glass
<kluk>
so that argument is wrong
<kluk>
next argument
<beneroth>
no it's not
<beneroth>
it's not wrong. maybe incomplete, but not wrong
<beneroth>
I don't say: theorizing is useless
<kluk>
it's wrong. try a better argument.
<kluk>
you know it.
<kluk>
I know it.
<beneroth>
I say: it can be useful and it can be useless
<cess11>
safety factor is much more important than algebraic elegance
<kluk>
then let's use it usefully.
<kluk>
argument addressed.
<kluk>
next.
<kluk>
cess11 safety can be guaranteed by algebraic constraints, see Ada. Next.
<beneroth>
what about cess11 examples of haskell web frameworks?
<kluk>
what was the argument?
<kluk>
I can't turn examples into arguments. I can't read other people's minds. :)
<beneroth>
their not better than usual webframeworks (for measures of software quality/usefulness) and are more complicated (resource intensive) to develop and change
<beneroth>
so they're not inherently better than PHP
<kluk>
beneroth they are not more complicated. just more unfamiliar.
<kluk>
there is no "difficult", just "new".
<beneroth>
where is the difference?
<beneroth>
there is
<kluk>
time
<beneroth>
yes
<beneroth>
exactly!
<kluk>
the difference is applied time
<beneroth>
and time matters!
<cess11>
you didn't recognise that you didn't understand the term safety factor in engineering and jumped to conclusions anywy
<kluk>
so apply it
<cess11>
anyway
<kluk>
problem solved
<beneroth>
we only have 70 years
<kluk>
and algebra is taught in middle school
<kluk>
so let's skip uni
<kluk>
done
<beneroth>
yeah I skipped uni
<beneroth>
:D
<kluk>
no need for CS uni
<beneroth>
xD
<kluk>
algebra I learned in middle school
<kluk>
so I gave you the answer
<kluk>
to your argument
<kluk>
do you accept it?
<beneroth>
no
<beneroth>
you disregard time
<kluk>
my solution takes fewer years to learn
<kluk>
you do
<beneroth>
you cannot disregard time
<kluk>
you disregard it
<kluk>
you want people to go to uni to code
<beneroth>
what?
<kluk>
I want middle schoolers to code
<cess11>
so write a universal accounting program and become a billionaire in no time
<beneroth>
T
<kluk>
[05:07:45] <beneroth>we only have 70 years |> address this please. I say with algebra, we learn it in middle school, so my solution saves time, while your solution requires more learning time after middle school, so I win this argument, right?
<beneroth>
you don't. I didn't go to uni, and I haven't studied CS, and I can do OOP alright while I cannot follow your math.
<beneroth>
but well
<beneroth>
adress please cess11 argument
<kluk>
but again. I am talking about the industry in general. not people here.
<beneroth>
I guess your point is: that is not what FP is trying to solve?
<beneroth>
our point: exactly!
<kluk>
I did address his argument: it's not more complicated, just unfamiliar; where's his rebuttal to that?
<cess11>
generalising over millions of people doing all sorts of things is vague at best
<kluk>
cess11 generalizing is what math does
<beneroth>
yes, and schooling and work place stuff is very different in different countries
<kluk>
so we can talk about categories
<beneroth>
ok
<beneroth>
other approach
<kluk>
like the category of average programmers
<beneroth>
what practical software did you produce, kluk?
<cess11>
no, web app libraries in haskell are very familiar, they're like laravel, spring and so on but with different syntax
<kluk>
beneroth how is that relevant to whether John Backus is right that the industry should adopt FP?
<cess11>
it's also harder to predict what subsequent modifications will do
<kluk>
cess11 frameworks is the wrong concept to use in programming
<kluk>
I don't believe in frameworks
<beneroth>
kluk, the industry is doing what gives the quickest way to produce software with acceptable correctness (which is less than perfect)
<cess11>
i didn't use the term
<kluk>
if you use a framework you are already inside a coalgebra
<kluk>
I don't like coalgebras
<beneroth>
kluk, if you solve correctness without solving speed of development, your not improving software development in general and it will never be broadly adopted
<kluk>
but you said "like laravel"
<kluk>
isn't laravel a framework?
<kluk>
"Laravel is a web application framework"
<kluk>
So it is.
<kluk>
So you said it.
<Regenaxer>
You need aerodynamics theory, physics and engineering to build an airplane, but it does not help at all to be a good pilot! :)
<beneroth>
!
<Regenaxer>
I now do real things
<cess11>
you can call it whatever you like, i call it a web app library
<cess11>
show us a product you've built that serves customers
<beneroth>
kluk, we understand your claim as: use this approach to build products to serve customers, it will be better.
<beneroth>
proofs for that pls
<kluk>
cess11 and after that what will you do? because if you change your mind in any way after I show you that, it will have been for Pathos or Ethos, whereas I am trying to have a discussion centered around Logos.
<beneroth>
after that I would consider looking into your approach
<beneroth>
I'm software industry
<beneroth>
I have a software company
<kluk>
beneroth: I already said: go look for Elm testimonials on google, just type those two words, you will get a glimpse of people going Javascript -> FP and seeing improvements.
<beneroth>
yes
<cess11>
nothing stops you from writing fp code in js
<beneroth>
but going everywhere from JS is an improvement :)
<kluk>
still, it answers your question.
<cess11>
elm hides boilerplate but you could do that in js too
<kluk>
You want proof
<kluk>
I am telling you how to find it.
<beneroth>
kluk, no, because I already moved away from js
<kluk>
cess11 You misunderstand Elm then.
<kluk>
It's not about hiding boilerplate, it's about being algebraic.
<kluk>
Bottom-up.
<kluk>
Starting from little, and then building up.
<cess11>
no, like reasonml it's a tool to generate js boilerplate without having to look at it
<kluk>
Javascript starts already from a place where there's a lot of machinery working.
<kluk>
It's not that at all.
<kluk>
That is a very immature understanding of it.
<beneroth>
kluk, in terms of Logos you might be right,,, but in terms of getting software produced?
<kluk>
ReasonML is another language, it's not "a tool to generate js boilerplate" anymore than a C compiler is "a tool to generate microcode boilerplate"
<beneroth>
C compiler is a tool to generate assembler boilerplate
<beneroth>
how is it not?
<kluk>
beneroth come back with a specific problem you have from a specific testimonial, otherwise what else do you want from me? I don't understand what sort of answer you are expecting now.
<beneroth>
"Peter is doing salary accounting in MS Word manually. He likes to work with an CRUD app which produces every month his reports so he hasn't to write them manually." do you consider that a specific problem?
<cess11>
elm like reason is suited for gui design and are mainly popular because they hide some stuff that would commonly be explicit in oop gui design
<beneroth>
this is the sort of problems we solve here and we're interested in. if you cannot solve this problem better, than we're not interested.
<cess11>
personally i don't think either ml styled tool is nicer to work with than clojurescript
<kluk>
How is the C compiler not a tool to generate assembler boilerplate? Well, let's start slowly, to make it easy. In the category of "things that are tools to generate assembler boilerplate" there belongs also a button that takes no input other than my pressing it, and spits out "assembler boilerplate" as output. Now tell me, is that a sensible category for you, the category of "tools that generate assembler boilerplate" such that both "a C
<kluk>
compiler" and "a button that spits out some assembler boilerplate" are of that category? I would say, to any sensible person, that is an idiotic definition.
<kluk>
[05:22:17] <beneroth>"Peter is doing salary accounting in MS Word manually. He likes to work with an CRUD app which produces every month his reports so he hasn't to write them manually." do you consider that a specific problem? |> yes. Solution: 1. export his data to my format; 2. redo his app in a sensible FP technology; 3. profit.
<beneroth>
kluk, show me how you do that more effectively than with picolisp :)
<kluk>
cess11 "because they hide some stuff that would commonly be explicit in oop gui design" moreso than that in fact: Algebra can abstract (hide some stuff) that commonly would be explicit in oop code. That is what it is.
<cess11>
the world isn't sensible
<beneroth>
T
<cess11>
it's unpredictable and commonly hostile
<kluk>
beneroth: Well, this is how I am showing you: 1. all the Elm testimonials, 2. all the haskell testimonials, both from people who first used non-FP, and now are sold. Your rebuttal to that is what?
<beneroth>
brutal, but so it is.
<kluk>
cess11 Perhaps, but saying that is again putting the burden on me to make out an argument from it. Otherwise they are just poetic observations.
<cess11>
fp is much broader than those ml style examples
<cess11>
it's really weird to conflate them
<kluk>
What did I conflate? I will correct myself.
<cess11>
fp with specific ml implementations
<kluk>
specific ml implementations are elements of the FP category. it is not conflation, it is liskov substitution
<cess11>
racket, php and picolisp are nothing like either of those and are well adapted to functional programming
<kluk>
those are not all well adapted to FP, no.
<cess11>
sure they are
<kluk>
You may think they are if you misunderstand FP.
<kluk>
Then what is FP about?
<kluk>
that even PHP can do it?
<beneroth>
you are claiming that elm & haskell are more powerful than turing completness, right?
<cess11>
programming with functions
<beneroth>
T
<kluk>
no, I never said that beneroth
_whitelogger has joined #picolisp
<beneroth>
and they are not FP because?
<kluk>
because look at javascript, it has lambdas and they are coalgebras (context-carrying)
<beneroth>
cess11, do we agree? I think we do.
<kluk>
so a lambda can perfectly be a coalgebra
<kluk>
(of course then it should no longer be called a lambda, but people still call it so in JS)
<kluk>
a lambda is something contextless. It's hard for people to understand but it is so.
<beneroth>
it might be a specific subset
<kluk>
"It is a declarative programming paradigm in which function definitions are trees of expressions that map values to other values"
<beneroth>
if the majority of the people doing FP don't agree with your definition of FP, then you probably use it wrong
<kluk>
So it is what I am saying.
<kluk>
beneroth you are wrong
<beneroth>
it does not exclude coalgebras
<kluk>
we all know what FP is: x -> F(x), the formula for algebra
<kluk>
algebras include coalgebras
<kluk>
oops, sorry, FP is F(x) -> x
<beneroth>
so all programming is FP then? :P
<kluk>
the context is negative
<kluk>
how so?
<beneroth>
you cannot claim "FP is without coalgreba" and "FP contains coalgebra", this are mutually exclusive statements, no?
<kluk>
cess11 no, FP is not "programming with functions", try again
<beneroth>
it sure is in the general understanding of that word
<kluk>
beneroth I am trying to be careful with my words but I don't think you are remembering what I am saying.
<cess11>
sure it is, as opposed to programming with statements, expressions, objects
<kluk>
FP does not use Coalgebraic foundations. It can manipulate Coalgebras. Do you understand now beneroth ?
<beneroth>
cess11, T
<kluk>
cess11: you got that side right, but in the middle of those statements and expressions and objects, if you use a function it doesn't make it FP, why?
<cess11>
as in one can implement a c compiler in haskell
<cess11>
what do you mean, "use"?
<kluk>
the normal definition of use.
<kluk>
what do you not understand?
<cess11>
it's vague
<kluk>
I don't see how.
<kluk>
Help me see how.
<cess11>
reference it? evaluate it? pass it to another function?
<kluk>
what is "it" there? please speak in complete sentences otherwise I have to be interrogating you and doing all the work for you of extracting from you what you are trying to say and it is very tiring, it shows that only I am willing to put in effort in the discussion and it is offputting.
<cess11>
the function
<kluk>
I really don't understand the question. Can someone tell me what is the complete question that cess11 is trying to ask me?
<beneroth>
the question seems clear to me
<beneroth>
the question is: kluk what do you mean by "use" (e.g. referencing/evaluating/passing ?) in your sentence "in the middle of those statements and expressions and objects, if you use a function it doesn't make it FP"
<beneroth>
I suspect cess11 is of the opinion (I am) that "in the middle of using expressions and objects, if you pass a function around, it does make it FP"
<kluk>
Oh... *however* you use it.
<kluk>
I couldn't piece together that question for the life of me.
<kluk>
See you all are better at mentally piecing things together.
<beneroth>
all your tools don't make you so real life compatible, eh? :P
<kluk>
That is why I have to do FP which is for simple brains like mine.
<beneroth>
you're not simpler
<beneroth>
also you are the one claiming your approach would be good for others, too
<beneroth>
we don't claim that
<kluk>
I can do FP with pen and paper, it's just substitution. That is what FP is all about cess11, it's about proofs that reduce inductively versus algorithms that sequence step-wise.
<kluk>
So no matter how I *use* a function in a programming language, if that programming language is a Von Neumann language then it's never going to be FP, no matter how many FP concepts it adopts.
<cess11>
i disagree on the definition of fp but that doesn't matter much
<cess11>
more importantly what you describe as ideal is just that, an ideal suitable for when all possible constraints are known
_whitelogger has joined #picolisp
<kluk>
cess11 the worst part of Haskell is its focus on monads which do not compose
<kluk>
they should be thrown in the garbage and forgotten forever, we have algebraic effects now, we don't need monads anymore.
<kluk>
we found a monad isomorphism that composes
<kluk>
it's like heaven is real
<kluk>
monads should be totally eliminated from Haskell
<kluk>
at this point
<kluk>
that is its worst part by far
<beneroth>
so which programming language do you recommend then, kluk ?
<kluk>
monads are ridiculous, monad transformers are ridiculous to the cubic power
<kluk>
beneroth Scheme
<beneroth>
which one? chicken? or doesn't matter?
<kluk>
I use chicken only because it is the scheme that is arguably the most FP scheme of all
<cess11>
right, so not that debugging is near impossible due to execution order being arbitrary or laziness leading to unpredictable performance issues
<kluk>
it has the least Von Neumann characteristics of all Schemes
<kluk>
the fewer*
<kluk>
fewest!
<kluk>
argh, I give up.
<kluk>
simple brain.
<kluk>
cess11 well, Haskell is really exploiting laziness to do other semantics, and in general I don't like any game like "oh let's use this, but for some other effect it does"
<kluk>
cess11 so I agree with you reasoning about laziness is terrible
freeemint has joined #picolisp
<kluk>
laziness is haskell is "overloaded" for semantic gains elsewhere in areas that you wouldn't think to solve with laziness
<cess11>
it's a shortcut in the same way that the algebraic purity is
<kluk>
That is a big wart in the language for sure.
<kluk>
you are absolutely right.
<cess11>
it's all fun and games until it isn't
<cess11>
and then you're in deep trouble if your customers are losing money because of it
<kluk>
well you are right about that for laziness but not for algebraic purity
<kluk>
I don't know of any stories of FP losing money to customers, certainly not to the tune of 475 million dollars that Intel lost from not using FP to make chips
<kluk>
how many lives were lost due to type errors?
<cess11>
i'm not designing chips, i'm processing huge amounts of somewhat ad hoc structured data and making sure people can do their everyday jobs as easily as possible
<cess11>
this is a very different type of engineering than what that ocaml shop does or chip designers are into
<beneroth>
T
<kluk>
[05:56:03] <cess11>i'm not designing chips, i'm processing huge amounts of somewhat ad hoc structured data |> Oh yes, because CPUs are definitely not "processing huge amounts of somewhat ad hoc structured data", you're right.... :/
<kluk>
We as programmers most definitely do not subject CPUs to "processing huge amounts of somewhat ad hoc structured data"
<kluk>
no sir
<kluk>
not in this establishment
<beneroth>
the data is well structured insofar as the CPU has to care
<kluk>
aha! so you could do the same insofar as *you* care for your program, in FP - *you* decide how much safety, how much to rely on the types. So the question is: why refuse outright any level of help from the compiler?
<beneroth>
the CPU doesn't care if certain amounts of 1s and 0s mean incoming money or outgoing money
<kluk>
Right, and I want to have control over what my program cares.
<kluk>
FP gives me that.
<kluk>
I know that for outsiders if looks like torture.
<kluk>
I want to retain that control, that ability to decide how much safety, how much to rely on the types, and where
<cess11>
in a lot of dayjob development i don't rely on types at all, they're unnecessary
<beneroth>
T
<beneroth>
also: they're not consistently defined over all data and over time.
<cess11>
i don't care whether the type is text, varchar or medium text, i just want to pull it out and check whether there are any mangled 4 byte emojis anywhere in there
<kluk>
"types are unnecessary" is something that only a coalgebraist, top-down thinker can say. Because for me, it's not up to me: a True simply was born a Boolean, it was not me who decided whether that fact is necessary or not, I just deal with it instead of pretending that True is the brother of 17 and the sister of "Hello, world".
<kluk>
beneroth only nominal types are not consistently defined
<beneroth>
if you don't care, why have different types for it?
<cess11>
booleans are trivial
<kluk>
another reason why FP cannot be done in non-FP languages - the types are nominal
<kluk>
cess11 I could use any type in the example.
<beneroth>
kluk, they're not defined for all eternity. marketing is deciding something and puff you're serial numbers are not numeric anymore.
<beneroth>
you then go and change your program
<beneroth>
we just don't change anything.
<kluk>
yeah but at the same time you don't know if anything else changed either, whereas I do.
<kluk>
that is control.
<kluk>
QED.
<kluk>
That is my point.
<beneroth>
do you need to know?
<cess11>
if i were to design a non-trivial type every time i need to pull out a GB of data and parse it i'd never be done
<kluk>
That is our different priorities right there.
<kluk>
Yes.
<kluk>
I do.
<kluk>
That is a sine qua non for me
<kluk>
So yes.
<beneroth>
you are micromanaging in cases when you don't need to.
<kluk>
"don't need to" according to you but you won't come to rescue me
<beneroth>
which results in longer development time.
<cess11>
if i need typing i set up some coercion for it on a case to case basis
<kluk>
beneroth not longer, shorter
<beneroth>
were do you save the time I save by not doing type definitions?
<kluk>
cess11 you sound like you never gave FP a chance and are not interested in this discussion
<beneroth>
where do you save the time I save by not doing type definitions?
<kluk>
beneroth I don't do type definitions. they are inferred.
<beneroth>
ok
<beneroth>
I guess we need to do a real programming challenge to settles this, then :P
<beneroth>
we don't get anywhere
<cess11>
i've spent a lot of time tinkering in ml languages, they're ok for trivial tasks or when the problem domain is fully understood and unchanging
<kluk>
There's so many FP vs OO comparisons online, I wish you would look at some beneroth and give me your thoughts
<cess11>
they suck for interactive or exploratory programming
<kluk>
I have already and decided FP is the clear winner
<kluk>
I can see you here have not looked at both sides in earnest
<kluk>
in order to make an informed decision
<beneroth>
kluk, the point is, you come here and say we should believe your decision
<beneroth>
but you say we should seek the proof ourselves, you can not give us any :P
<kluk>
I gave many references, you have not looked at any
<beneroth>
we're happy with what we have and we don't want to make join our way.. if you are interested, we're happy to show you, but else.. just let us do our thing :)
<kluk>
how many Elm testimonials did you read?
<cess11>
we did but they aren't convincing
<beneroth>
what does js -> elm testimonial give me any value about the picolisp -> elm question?
<cess11>
no one here is arguing shitty js is a nice option
<beneroth>
T
<kluk>
I was attempting to see if the advantages of FP are communicable but now I am coming to think it really only fits bottom-up thinkers.
<beneroth>
maybe. or maybe you are just wrong and use that as a nice excuse :)
<cess11>
the big ml languages has nothing that compares to picolisp 'in and it's crucial for me almost every day and has been for years
<beneroth>
cess11, you mean wrapping other cli tools? so this is.. very laborious to do in scheme?
<kluk>
beneroth But in the end Algebra does everything that Coalgebra does but not vice versa, so it is a natural fact that FP has advantages, at least in that it can solve more problems, strictly mathematically speaking.
<cess11>
elm isn't a scheme
<beneroth>
kluk, yeah stricly mathematically is a very limiting constraint
<cess11>
picolisp is almost a scheme
<kluk>
beneroth I disagree, again, constructivist mathematics is generalizing, not constraining.
<Regenaxer>
In my view Pil is very different from Scheme
<Regenaxer>
only syntax is similar
<cess11>
agreed, but close to a scheme than ml
<kluk>
Yes Pil is nowhere near a scheme
<cess11>
closer
<kluk>
not really
<kluk>
scheme and ml are closer
<Regenaxer>
beneroth, I think I know what to do with the above problem
<kluk>
SML was literally just typed Scheme
<Regenaxer>
I need to change 'class'
<kluk>
check your history books :)
<kluk>
cess11 shows what you know in this discussion, take it as a constructive criticism.
<Regenaxer>
Not sure if that breaks anything
<Regenaxer>
Let's discuss this some other time though. I don't want to interrupt this nice discussion
<beneroth>
Regenaxer, ok
<beneroth>
kluk, how can you say anything about how picolisp compares to scheme if you don't know picolisp?
<kluk>
SML and Scheme have what amounts to the same denotational semantics, it's not going to be the case that some language is going to come out of nowhere and suddenly be more similar to Scheme than SML, that would be a very hard thing to pull off.
<kluk>
Scheme was LC, SML was STLC, that is their history,
<beneroth>
lol what an non-argument
<kluk>
I keep ending my sentences with a comma.
<kluk>
how so?
<beneroth>
it is the same thing a person only knowing PHP or only knowing C# would be saying about picolisp xD
<beneroth>
it's hard, so it cannot be.
<beneroth>
just outside of their personal horizon
<kluk>
I know the history, I know the motivation behind SML, its fruits, CAM, CAML, CAML Special Light, I know the context.
<kluk>
But I am informed about this.
<cess11>
you keep reiterating theoretical convictions and make weird misinterpretations that fit those
<kluk>
that is a description but do you have an argument?
<cess11>
practical programming in picolisp is much closer to practical programming in racket than f#
<cess11>
historical heritage from scheme in sml isn't relevant to such a comparison
<beneroth>
kluk, well you also say "scheme WAS", so implicitly telling us that this point is not valid anymore...so no idea why it should be an argument for anything then
<kluk>
it's not about heritage, I said their denotational semantics amount to the same thing.
* beneroth
doesn't know what "denotational" means
<kluk>
For instance, that is why SML has call/cc and OCaml doesn't (SML was made to be typed scheme, OCaml is a long future evolution that forgot some things)
<cess11>
it means mathematical semantisc
<cess11>
semantics
<kluk>
denotational means by-reduction. it's a reductive, inductive semantics.
<kluk>
as opposed to operational which is step-wise semantics.
<kluk>
both are mathematical
<kluk>
one is algebraic
<kluk>
the other coalgebraic
<kluk>
your imperative programming is also mathematical
<kluk>
it's just that you imperative programmers don't want to formalize what they do.
<kluk>
so they throw the scary word "math" onto FPers
<beneroth>
now you are mixing up CS terms
<cess11>
it's not scary, it's just that adapting to customer business needs is rarely immediately formalisable
<beneroth>
T
<beneroth>
this
<kluk>
[06:19:39] <beneroth>kluk, well you also say "scheme WAS", so implicitly telling us that this point is not valid anymore... |> first of all I reject that saying "was" implied that it isn't anymore. That is simply not true. There is no meaning in "was" that means "which means it isn't anymore". "was" is simple past.
<kluk>
I am not going to spend time unsaying things I did not say.
<beneroth>
customer business needs are not formalisable. and when you get it formalised, then they change, rendering your formalisation useless again
<kluk>
Scheme "was" in that historical context typed scheme. It still is but it matters less today.
<beneroth>
well if your point is about it being typed than it matters today :P
<beneroth>
anyway
<beneroth>
how do you call other CLI programs in chicken scheme?
<kluk>
cess11 the code you write is a formalization already. You just find formalizing simulations/coalgebras easier. I find formalizing algebras easier. However coalgebras are inherently harder (that's why the field is still in its infancy). On the other hand, kids learn algebra all the time. So you prefer to write harder formalizations because your mental prowess is so good that you don't care to do all that heavy-lifting in your brain instead
<kluk>
of letting the computer do it for you.
<beneroth>
kluk, no, we just let some parts being unspecified
<kluk>
beneroth leaving parts unspecified is already a part of formal coalgebra
<kluk>
you cannot escape this reality, I didn't make the rules!
<beneroth>
kluk, so we claim in picolisp we can faster (development time) call another program which has command line tool interface than you can do with your approach. what you say?
<cess11>
sure, express a mysql client wrapper and a parser for output as math
<kluk>
I don't have an enormous brain such that I can understand OOP, I have the same brain I had in middle school, just older. So I can still understand easy middle-schooler things like algebra.
<kluk>
cess11 they already are math, coalgebraic math, do you understand my point or not?
<cess11>
sure, show it in whatever mathematical notation you prefer
<kluk>
beneroth you mean a system call?
<beneroth>
kluk, either make argument A) that X (your FP understanding) is better in general, or make argument B) that it better fits you. In case of A) you need to argue with things which support A, not B. In case of B) this discussion is meaningless
<beneroth>
kluk, it's commonly named that, but strictly speaking system calls implies going via OS, which I don't want necessarily to imply
<kluk>
cess11 I don't prefer it. You prefer it, that's the tech you picked. You may or may not ignore its formal notation but when you write a program you are just formalizing it in that program's language instead of in math notation. it's still formal. it's formal coalgebra. Your programs are formal bisimulation coproofs of coalgebras.
<cess11>
(de rQ (Q) (make (in (list 'mysql "user" "pass" "-e" Q) (link (line T]
<cess11>
what's your superior option?
<beneroth>
T
<kluk>
beneroth the argument for FP being better in general is easy: every coalgebra is an algebra, but not every algebra is a coalgebra, therefore algebras are strictly more powerful, therefore there are some things I can do in FP which you will never be able to do in OOP.
<kluk>
That means it's better.
<kluk>
It solves more problems.
<kluk>
cess11 I am not saying anything about superior
<kluk>
why would you think that
<cess11>
right, better option
<beneroth>
wrong. ability to solve more problems which software customers don't care about is not being better than another language to solve customers problems.
<kluk>
but you added that part about "which software customers don't care about"
<kluk>
to make a strawman
<beneroth>
no
<kluk>
I saw it ;)
<beneroth>
I speak about real world
<cess11>
my better option is slightly longer
<kluk>
look, don't distract from the argument. Algebras represent more things than Coalgebras. That's it.
<cess11>
(de rQ (Q) (cdr (make (in (list 'mysql "user" "pass" "-e" Q) (link (line T]
<kluk>
At some point we all have to deal with this fact.
<beneroth>
else please list me some problems for which the average software customer cares which can be solved with your approach and not with picolisp
<kluk>
beneroth easy, a verified C compiler.
<kluk>
the end customer cares that their programs have no backdoors
<kluk>
done.
<beneroth>
software customers don't care about compilers
<kluk>
read again:
<cess11>
go ahead, start a business and sell a c compiler
<beneroth>
they don't even care about backdoors, I'm sorry
<kluk>
beneroth [06:33:28] <kluk>the end customer cares that their programs have no backdoors
<kluk>
yes they do
<beneroth>
haha
<kluk>
they lose money
<beneroth>
no
<kluk>
yes
<cess11>
the vast majority of c compiler users will go with gcc anyway
<beneroth>
well then explain why cloud business thrives
<kluk>
it doesn't thrive with customers who know the risks
<beneroth>
yes, but they're niche
<kluk>
it thrives with people who lose their shirts
<kluk>
I want to work with people who have money
<beneroth>
so you say: your solution is only better for niche
<beneroth>
my point
<kluk>
not who lose money
<kluk>
you said niche
<kluk>
I did not
<beneroth>
you say people who care
<kluk>
your strawman again
<kluk>
people who care about their businesses
<cess11>
i still want your fine version of my rQ
<kluk>
should be every business
<beneroth>
haha
<beneroth>
yes should be. isn't
<beneroth>
most don't even care about their own business.
<kluk>
cess11 I never said anything about better, you're totally confused about what I am saying
<beneroth>
kluk, you did. otherwise what is the point of this whole discussion?
<kluk>
cess11 your code is formal math, formal coalgebra math. I'm sorry if that offends you.
<cess11>
sure you did, you're constantly reiterating that taking a detour through some strong typed algebraic territory is better
<kluk>
Well, I am a sane person.
<beneroth>
what a bold claim
<kluk>
I don't work for people who own a business but don't care about it, that frankly sounds insane to me.
<cess11>
who do you work for?
<kluk>
I don't know why anyone would do it.
<kluk>
real-world clients that care that they stay in business because that is how they make their money.
<beneroth>
wrong
<beneroth>
I see you don't have much experience with real world customers.
<cess11>
name a few
<kluk>
Carl, Joe, Steven...
<cess11>
doesn't sound like businesses to me
<beneroth>
Siemens, big swiss ecommerce retailer, big shopping retailer, multiple international engineering companies.... that would be my list
<kluk>
"name a few" doesn't sound like an argument to me.
<kluk>
so how does this argument work? it's whoever has the most impressive names on their list wins? or the longest list?
<kluk>
what are the rules?
<kluk>
so I understand your thought process
<cess11>
i work on an erp system tailored for cleaning businesses, our hundreds of customers have a total yearly turnover in the millions of euros and range from one-person companies to thousands of employees, it's built in php over a decade, mostly ad hoc due to management
<beneroth>
kluk, yeah, as a proxy for doing a real world project in both approaches and compare that. that would be the best. maybe name us a real world project you worked on so we maybe can find comparable projects in our portfolio?
<cess11>
give us an example of a business that's successful due to the theoretical convictions you've been reiterating over and over here
<beneroth>
T
<kluk>
cess11 yours. PHP is based on theoretical coalgebraic convictions.
<kluk>
that was easy.
<kluk>
throw me another challenge.
<beneroth>
you're not answering the question
<beneroth>
and your argument is NIL. PHP is the most dominating web software
<beneroth>
shouldn't it be a language based on CT principles, if they are so inherently better?
<kluk>
your saying "you're not answering the question" right after I answered the question feels like gaslighting.
<beneroth>
you responded the question, but you haven't answered
<kluk>
CT is newer than Coalgebra (even though Coalgebra now lags behind in advancements)
<kluk>
all coalgebraic languages keep on adopting more FP concepts
<kluk>
the reverse does not happen
<kluk>
read the signs
<kluk>
oop has already lost
<cess11>
ocaml and scala are more widely adopted than haskell or chicken
<cess11>
alright, can you name the companies where you were employed to engineer software in those languages?
<beneroth>
I give up. Either you are arguing in bad faith, or you are not arguing for what I believe you are arguing (some better approach than picolisp which is better than for what we use picolisp for)
<kluk>
cess11 I only argue bottom-up. That would be a top-down conversation so no. You want Ethos and Pathos. I only have Logos.
<beneroth>
Logos alone is blind and dead.
<beneroth>
so kluk you are NOT arguing for a better alternative than picolisp for the things we use picolisp for? (which is a constrained field)
<kluk>
beneroth Me too. It took me 6 years to understand the advantages and unlearn coalgebra. You want to understand what I do in a few conversations, without the humble openness to try for yourself the way I did. It's not possible that way. You would have to connect to my brain directly to see things with my acquired context.
<kluk>
[06:47:25] <beneroth>Logos alone is blind and dead. |> but at least it helps me in identifying what you said as not being an argument. :)
<beneroth>
we didn't ask you to come here. you came here and claimed to have a better approach
<beneroth>
I mean you may stay, you're welcome. but don't argue against picolisp with something to show, please :)
<cess11>
logos means word, i.e. an arbitrary signifier
<beneroth>
bbl
v88m has quit [Ping timeout: 265 seconds]
<beneroth>
kluk, didn't we establish already in a previous session that machine learning is co-algebraic in nature?
<beneroth>
I think we can even say that machine learning as it is done these days is OOP. it's just OOP with applied GoF flyweight-pattern, externalizing the state into matrices
<beneroth>
why is it done this way? because the FP way failed for higher intelligence task so far
<beneroth>
yes this machine learned system are not proven, and that is a big issue, and we cannot even easily disassemble them to look where they get their logic from (because it's distributed over state, more than in any traditional program)
<beneroth>
(we can disassemble them, but it's not practical)
freeemint has quit [Ping timeout: 252 seconds]
<beneroth>
[OT] I just watched this video (Richard Feynman about intelligent machines) and it gets better and better... 18min.. only tangential related to out discussion, but also kinda having the same essential point: https://www.youtube.com/watch?v=ipRvjS7q1DI
freeemint has joined #picolisp
peterhil has joined #picolisp
<cess11>
things like streams are coalgebraic, it's a wide term that's pretty much a nonsense limitation on practical development
<Regenaxer>
I changed 'class'. It was like this 20 years or so, but I think it was wrong.
<Regenaxer>
It preserved methods and properties
<beneroth>
uh lets talk. but later. busy now. feel free to describe now.
<Regenaxer>
This was the real issue I had with anon syms
<Regenaxer>
yeah
<Regenaxer>
I will dare to release it for now
<Regenaxer>
boldly going ahead ;)
casaca has joined #picolisp
<beneroth>
Regenaxer, pil64 Idontcare :P
<Regenaxer>
me too :)
<Regenaxer>
obsolete ;)
<beneroth>
exciting to learn what the change is. (class) has often nothing to do with anon symbols...
<Regenaxer>
right
<beneroth>
Regenaxer, proven :P
<Regenaxer>
The problem were the redefined messages
<Regenaxer>
So anons were in the way
<Regenaxer>
But the real issue is deeper
<beneroth>
easy solution, start pil without + :P:P
<Regenaxer>
;)
<beneroth>
;-)
<Regenaxer>
With (err ...) for stderr
<beneroth>
away again, some more meetings :/
<Regenaxer>
'class' took pain to keep old method and property definitions
<Regenaxer>
But this is not good
<Regenaxer>
When reloading a file, old stuff remains
<Regenaxer>
But what if a method is gone?
<Regenaxer>
It will still perhaps override another one
<Regenaxer>
same with instance variables
<Regenaxer>
and relations, which are instance variables technically
<Regenaxer>
For *modifying* a class we have 'extend'
<Regenaxer>
So 'class' may well clean up
<Regenaxer>
I see no situation where this gives a problem
<Regenaxer>
tankf33der, any such test case?
<Regenaxer>
My problem was that I never dared to do a (boss 'load "app/er.l")
<Regenaxer>
because it gave tons of messages
<Regenaxer>
*and* if a relation or method was gone, it still remained in the class
<Regenaxer>
which may be fatal
<Regenaxer>
For any other files I follow the rule that it should be re'load'able any time, redefining stuff
<Regenaxer>
So the only case where something breaks if somebody used 'class' instead of 'extend'
<Regenaxer>
(as far as I see)
<tankf33der>
Regenaxer: all tests passed.
<Regenaxer>
Great!! Thanks!
<tankf33der>
I have several parts of picolisp i never use or understand, classes in list of this.
<Regenaxer>
I started with this because these days I'm modifying the BTG application heavily while they are already testing it
<Regenaxer>
So I needed to call them and tell to log out, then I killed the server to restart automatically
<Regenaxer>
tankf33der, no worry :)
<Regenaxer>
Next will be that when doing (boss 'load ..) Iwill also call (boss 'tell ''load ...)
<Regenaxer>
So that all running children will also reload
<Regenaxer>
Then I'm completely hot-pluggable
<Regenaxer>
In case of BTG it is tricky, cause there are 41 DBs and thus 41 possible parent processes
<Regenaxer>
Let's see ...
<Regenaxer>
tankf33der, I check your chess position now
<Regenaxer>
I think I know
<Regenaxer>
'tryCastle' fails probably because it thinks that the King has moved already
<Regenaxer>
the black king
<Regenaxer>
the white king cannot castle in any case, because f1 is attacked by the black bishop on a6