beneroth changed the topic of #picolisp to: PicoLisp language | The scalpel of software development | Channel Log: https://libera.irclog.whitequark.org/picolisp | Check www.picolisp.com for more information
aw- has quit [Quit: Leaving.]
rob_w has joined #picolisp
mtsd has joined #picolisp
mtsd_ has joined #picolisp
mtsd_ has quit [Client Quit]
mtsd has quit [Ping timeout: 264 seconds]
mtsd has joined #picolisp
Nistur_ is now known as Nistur
mtsd_ has joined #picolisp
mtsd has quit [Read error: Connection reset by peer]
mtsd_ has quit [Ping timeout: 272 seconds]
peterhil has joined #picolisp
peterhil has quit [Ping timeout: 244 seconds]
peterhil has joined #picolisp
beneroth has joined #picolisp
inara` has quit [Quit: Leaving]
inara has joined #picolisp
aw- has joined #picolisp
peterhil has quit [Quit: Must not waste too much time here...]
kluk has joined #picolisp
<Regenaxer> Hi kluk!
<kluk> Regenaxer Hi :)
<kluk> Regenaxer I'm glad to see you hear, I would like to ask you a question, after much thinking
<kluk> here*
<Regenaxer> OK, good
<kluk> What I really would like to understand from you, and I ask this way so we can disregard our preferred semantics to words such as "freedom", so I will keep it informal, but what I would like to understand is, if I agree with you that picolisp is simpler/easier (you pick which), then what is FP compared to it? And the perspective I ask this from, is that to me, FP feels like "cheating" informally speaking, i.e. that
<kluk> I am able to offload some thinking to the computer, is my "cheating" in this case. So I would like to know, what is it about picolisp that gives you that same feeling that you are "cheating", because I could still see that FP'ers were "cheating" before I understood it but I don't yet understand how you can feel you're "cheating" if that makes sense.
<kluk> I had a hard time finding examples how dynamic binding gives practical advantages, for instance, so I could not answer this by myself.
<kluk> Regenaxer obviously the embedded database and the amazing integrated GUI are obvious "cheats" that are easy to recognize, so I am not talking about those features.
<Regenaxer> hmm, what "cheating" do you mean? And what do you FP compare to?
<Regenaxer> compared to pil? Pil is also FP (though FP is just a way of thinking, not the lang)
<Regenaxer> Then, dynamic binding makes a lot of things easier, as you don't need to carry static environments around
<kluk> By "cheating" I mean an informal way to perceive an advantage. To me even before I knew FP, I could see that people were taking more advantage of the computer than I was (that is what I am calling the "cheating" that I perceive in FP). For instance, maybe the "cheating" that OOP'ers perceive, i.e. the advantage they perceive in OOP, is modularity. I don't know, I don't get it, but I'm not interested in what
<kluk> OOP'ers think but in how you think - how do you perceive the advantage that picolisp gives you (perhaps specifically about dynamic binding) that could make a beginner that doesn't "get it" yet see it and recognize it as an "advantage" that you have over other languages.
<kluk> Well I want to stay away from words like "easier" because they become longer to unfurl
<kluk> That is why I want to perceive it from your point of view. I couldn't find any examples of enthusiasts of dynamic binding showing the tricks it allows, so to speak
<Regenaxer> OK, that is easy
olaf_h has joined #picolisp
<Regenaxer> Look at the pil GUI and how it integrates with the DB. It all runs in a dynamic environment
<Regenaxer> Most behavior is in code snippets
<kluk> Yes but I grant you that the DB is a notable "cheat"/awesome advantage over other languages that any beginner/non-picolisper can see that it feels like "cheating" (i.e. feels easier) if you can use an embedded DB so nicely as you can in picolisp.
<Regenaxer> (gui '(+Able +Button) '(: home obj foo) "Test" '(doSomething (: foo bar)))
<Regenaxer> these are code pieces
<Regenaxer> no full functions needed
<Regenaxer> as whole env is determined at runtime
<Regenaxer> Or take the 'make' envs
<kluk> no full functions, as in you can pass this quoted/frozen version of a function call and have it eval'ed when it needs to be "called" right?
<Regenaxer> Or just look at rosetta code and compare toCL or Scheme
<Regenaxer> Nothing frozen
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> sorry, I still don't know why this happens...
<kluk> Well, so then, about the rosetta code comparisons
<kluk> they bring me back to this:
<Regenaxer> ok, conventions
<kluk> And as you say there, we as programmers are expected to commit to memory some (or better, all) conventions that the language will not help with
<kluk> So that is also a topic I would like to visit with you, why this preference.
<kluk> But from the perspective of how do you feel that is better for you
<kluk> that you feel others may be "missing out on"
<kluk> I want to know what I am missing.
<Regenaxer> The convs make things clear
<Regenaxer> You see immediately what the program elements *mean*
<Regenaxer> e.g. a symbol is *mainly* a global variable
<Regenaxer> It still can be bound locally
<Regenaxer> but if not, it is clear what its purpose is
<Regenaxer> And saves from some hazards
<Regenaxer> eg. a local var 'Car' is better than 'car'
<Regenaxer> (let Car (foo) ... Car ...)
<Regenaxer> (let Car (foo) ... (car ..) ...)
<Regenaxer> So it is recommended that locally bound symbols start in upper case
<Regenaxer> (this is not because of dynamic binding, but because symbols use the value for functions)
<Regenaxer> a Lisp-1 iirc
<kluk> so when you say "you see immediately what the program elements *mean*", to me that does not relate, because I would use that sentence if the code instead of taking arguments (locally-bound-symbol Function-symbol) it took them as ((someName "of-type" LocalllyBoundSymbol) (someOther "of-type" FunctionSymbol)), so I think this is where it may be important to understand what "immediately seeing something" means to
<kluk> each of us. To me "immediately seeing" means not having to think, by being able to just read it, or have the computer tell me without my having to write the type; for you, "immediately seeing" means "quickly recalling something you have memorized and practiced over many times" - is this a fair assessment?
<Regenaxer> It has nothing to do with type, but with behavior I would say
<kluk> But I did not say that it has to do with type, it just so happens that the type fulfills to me the role of "not having to think by being able to have the computer tell me"
<kluk> I would not care about types if they did not do that.
<kluk> To me it has all to do with thinking less, do you see what I am trying to say?
<beneroth> hi Regenaxer, kluk :)
<Regenaxer> So types of behavior
<kluk> beneroth: hello :)
<Regenaxer> Hi beneroth :)
<beneroth> nice thinking kluk, I'm glad you ask this way :)
* beneroth also tried to get a bit more into "what is the benefit of Functional programming/paradigm"
<kluk> beneroth: well I know you folks here are accomplished and very good at what you do so I want to learn what I am missing
<beneroth> wise
<Regenaxer> I would not say "less thinking" but "less searching in the code"
<kluk> beneroth: oh I can help you with that ;)
<beneroth> we're also interested to learn, but we have strong opinions :D
<kluk> Regenaxer So, I am also interested in how you qualify what my "cheating" is, in your point of view. What do you think I get from FP that makes me prefer it? I phrase it as less thinking, but how would you phrase it? I am interested in that because it would help me see things the way you do.
<kluk> beneroth most definitely, but I am still interested in exchanging them
<Regenaxer> FP is good because of clear behavior
<Regenaxer> no side effects
<beneroth> kluk, about your question: the biggest exclusive feature of picolisp is probably that it is a interpreter-only. All code is interpreted. all code is data. functions are data. functions don't act on data (as implied in FP) but ARE data, so everything can be applied to everything, kinda... but it's still simple, not complex.
<Regenaxer> What *can* be done in FP should be done so
<Regenaxer> eg. separating out things
<beneroth> Regenaxer, I was very surprised to learn that FP would give the benefit of easily parallelism in theory..but in practice.. none of the major FP languages is parallel-by-default
<beneroth> Regenaxer, T
<Regenaxer> beneroth, yes, interesting
<kluk> beneroth I agree that is disappointing
<Regenaxer> because parallelism requires synchronization
<beneroth> picolisp is very multi-paradigm programming. use FP were effective. use OOP where effective. use logic programming where effective.
<Regenaxer> FP means "calculation"
<beneroth> Regenaxer, yep, that appears to be the reason.. the overhead of managing it is to high
<Regenaxer> calc only
<Regenaxer> it is even a contradiction
<beneroth> Regenaxer, FP proponents see domain stuff as calculation, including e.g. accounting use cases
<kluk> beneroth re your answer, those benefits I can understand, but then am I correct in understanding that that places picolisp in competition with e.g. Ruby? (for being a good interpreter-only language like you said)
<Regenaxer> E. Normand defines calculations
<Regenaxer> as independent of *when* and *how often*
<beneroth> but I agree with you... being similiar to math is nice for language/logic research, but not so optimal for practical applications. most practical stuff is impure math if it is mathy at all.
<Regenaxer> paralellism is *when*
<kluk> I don't see FP as calculation, I see it as substitution, but maybe I am too textbookish.
<kluk> Regenaxer "What *can* be done in FP should be done so" That is interesting to hear from you.
<beneroth> kluk, well what about FP is then different form lisp as pure lambda? :P
<Regenaxer> Eric Normands separates Data - Calculations - Actiins
<beneroth> Regenaxer, yep
<beneroth> Regenaxer, but it's also his own terminology
<Regenaxer> I love FP
<kluk> beneroth right, nothing, that is why even CL is considered (rightfully) FP
<Regenaxer> But it is not interesting
<kluk> I agree! FP is not interesting in the way that non-FP is, clearly, since non-FP things such as design patterns attract immense audiences, while Category Theory paltry ones.
<beneroth> kluk, you can do FP in C++. you can also do procedural computing in Haskell. some things are easier in some languages, but a turing complete language is turing complete, so you can programm every paradigm in every language in theory.
<beneroth> kluk, nah we're not talking about popularity. we're the wrong ones to talk about that, lol :D
<kluk> beneroth see, this is where I disagree, and I think it is about lax language usage. FP cannot be done in C++ because substitution cannot be done in C++ (if it could it would not need templates)
<Regenaxer> With "interesting" I mean "solving problems"
<Regenaxer> Calculations are usually clear
<beneroth> tmeplates are part of C++, you can programm everything in pure templates if you like to
<kluk> Oh, that is a solving-problems definition of "interesting"
<kluk> beneroth but you missed my point
<Regenaxer> I need a computer to solve problems :)
<beneroth> same for FP, question is what kind of problems :D
<kluk> beneroth C++ does not allow substitutions so it does not allow FP
<beneroth> how does it not allow substitutions? you can program it into it, why not?
<Regenaxer> kluk, how do *you* define FP then?
<beneroth> Regenaxer, good question. good point.
<Regenaxer> if not calculations with data
<kluk> Haskell doesn't really allow procedural either; neither does CL for that matter. Even a progn is denotationally just lambdas.
<Regenaxer> independent of the lang!
<kluk> Forget Haskell, CL cannot do procedural code.
<kluk> beneroth I am trying to use a word that you will not bend out of meaning :)
<kluk> beneroth you can pick one for me if you don't like substitution
<beneroth> kluk, we have this from Eric Nomad from lispcast.com, a FP proponent, he said programming in the IO monad in Haskell would practically being programming prodecurally
<beneroth> kluk, no, I don't get what you mean by "you cannot do it".. when many FP languages are implemented in C or C++ :D
<Regenaxer> T
<kluk> beneroth let's examine that statement slowly
<kluk> each line of that "procedural program' in Haskell is actually fed to a bind operator
<kluk> it's all lambdas being reduced
<beneroth> sorry for the word bending, I'm not trying to bend words just for the bending, I sincerely have problems with the terminology (which might be entirely my shortcoming)
<beneroth> T
<kluk> it just looks like sequence
<beneroth> yes
<kluk> okay so this is the part that is important that I was trying to explain before
<kluk> We need to pick words with 1 meaning
<beneroth> whats the difference of "un-nesting" a nested call in picolisp?
<kluk> otherwise this communication will be impossible
<beneroth> T
<Regenaxer> yeah
<Regenaxer> so let's first define FP
<Regenaxer> if not Normand's
<Regenaxer> the *when* and *how often* criteria
<kluk> FP is evaluation by simplification to head-normal form.
<Regenaxer> what is head-normal form?
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<beneroth> wb
<kluk> Repeating: [09:27:13] <kluk>FP is evaluation by simplification to head-normal form. Procedural is one-line-after-the-other and/or Turing/Von Neumann machines.
<beneroth> <Regenaxer> what is head-normal form?
<beneroth> <kluk> FP is evaluation by simplification to head-normal form.
<kluk> Thank you :)
<kluk> okay. 4 is the head-normal form of 2+2
<beneroth> so.. compression?
<kluk> 6 is the head-normal form of 12/2
<Regenaxer> I don't get it
<beneroth> but.. symbol Pi is much shorter than the value
<beneroth> me neither
<kluk> Whichever name you pick, but pick one and let's let that name have only that meaning :) you say compression, some say reduction, simplification...
<Regenaxer> 12/2 = 6?
<kluk> 12 divided by 2 is 6
<beneroth> Regenaxer, both is the same value
<Regenaxer> a calc :)
<beneroth> not exactly
<beneroth> more like 2 representations
<beneroth> function in the pure math sense, not in programming sense
<Regenaxer> why is that FP?
<Regenaxer> ok
<Regenaxer> so independent of time, yes
<beneroth> dunno... kluk please continue :)
<beneroth> T
<kluk> Why is that FP... because it is, do you want me to show you good sources that it is so? In what level are you asking that question?
<Regenaxer> No sources
<Regenaxer> There must be some clear definition
<Regenaxer> We said you can do FP in C, you denied that
<kluk> Okay. Propositional logic -> declarative statements -> equational reasoning -> hence the tool for assessing equality is simplification of either side of the equation.
<kluk> C does not reduce anything. it walks in assembly steps.
<kluk> 1:1 to assembly almost.
<beneroth> simplification doesn't necessarily mean calculating the value
<kluk> MASM reduces
<Regenaxer> Yes, so FP in asm is fine too
<kluk> MASM is an assembly language that reduces, so there's an FP example.
<kluk> the Macro language in MASM is FP
<kluk> does that make sense?
<Regenaxer> Sorry, no
<beneroth> if you can do MASM/FP on von-neumann cpu, why can you not implement MASM in C?
<kluk> macros work by substitution ,not steps
<kluk> is that clear?
<Regenaxer> I don't the point of reduction
<beneroth> we also don't like macros, even as lispers :D
<beneroth> well it's just one tool among many
<kluk> beneroth we are not talking about turing-equivalence
<beneroth> well
<kluk> but about the way languages choose to evaluate. they still need to choose between algebra and coalgebra. there is no avoiding that choice.
<beneroth> if you would try to programm FP in C, at what point do you give up and why?
<Regenaxer> MASM is Microsoft Assembler?
<kluk> 2 + 2 does not give 4 in C
<Regenaxer> I used M80 30 years ago
<kluk> it gives a bunch of instructions for a CPU to change states rapidly.
<kluk> I cannot replace a computation with its value
<kluk> there is no referential transparency
<kluk> MASM is Microsoft Assembler, yes.
<Regenaxer> the C compiler may handle referential transparency
<Regenaxer> not the C runtime
<beneroth> what is "referential transparency" ? changing the variable name whenever the variable has a different value?
<Regenaxer> I is to get the same value, so it can be pre-calculated
<kluk> beneroth referential transparency is equality of function and their values
<Regenaxer> yes, sin(0) is zero
<beneroth> this is fine in abstract sense, but impossible in practical terms. we don't have the value for PI.
<Regenaxer> I do not find that so very important
<Regenaxer> it is trivial
<kluk> let's not bring infinitudes into this conversation, that is another debate
<beneroth> it's just a mapping.
<kluk> Tell me why you find it trivial please
<kluk> beneroth you and I are still not communicating well, I am trying though
<Regenaxer> it is memoizatiin
<Regenaxer> ion
<beneroth> Regenaxer, T
<beneroth> caching :P
<Regenaxer> referential transparency is nice
<Regenaxer> but it does not solve anything
<kluk> it is memoizability
<beneroth> and that gives which benefit?
<kluk> equational reasoning
<Regenaxer> a performance benefit
<kluk> that is the benefit
<kluk> ER
<Regenaxer> What make equational reasoning a better program?
<beneroth> Regenaxer, in theory, in practice apparently not so easy to realise that theoretical benefit on current hardware
<Regenaxer> *how makes ...
<beneroth> +1
<kluk> Regenaxer To me, it's the fact that it requires less thinking on my part, and seemingly the computer can do more heavy-lifting for me than in non-FP languages.
<kluk> if it were harder to think I would not touch FP with a ten-foot pole
<Regenaxer> Again, there are no non-FP languages
<kluk> Yes, there are, those that do not give me facilities for ER
<kluk> which boils down to eval-by-reduction/simplication instead of by steps
<beneroth> but that cannot be better than the approach of "thinking less"
<kluk> I am saying this *is* the approach of thinking less
<kluk> how did I get you confused?
<beneroth> do less stuff > do stuff more efficient
<Regenaxer> kluk, can you give a concrete example?
<kluk> I am lost
<Regenaxer> for the benefit?
<beneroth> kluk, I understood you as saying you are outsourcing some steps to logic & computer.
<beneroth> but yes. let's get specific, that is more helpful.
<kluk> Regenaxer an example of thinking less? Yes, I try to code something in FP, I get it wrong, the compiler tells me what to fix, I go there and fix it, now it runs, therefore the computer thought for me, as I didn't even have time to know there was an error and the computer already completed the investigation thereof and gave me a report thereof.
<Regenaxer> In my daily work, less then one percent is spent on algorithms
<kluk> I am not talking about algorithms
<Regenaxer> Forget about compilers
<kluk> I am not talking about compilers
<Regenaxer> Pil gives answers at runtime
<beneroth> we have no compiler
<Regenaxer> "I get it wrong, the compiler tells me what to fix"
<beneroth> not even at runtime
<kluk> But then I have to investigate runtime errors and that takes more thinking than not having to do it when in FP the computer does it for me
<kluk> [09:44:01] <Regenaxer>"I get it wrong, the compiler tells me what to fix" > okay, I get it wrong, the interpreter tells me what to fix. Now what do you say?
<beneroth> how? if you have the wrong VAT value in your accounting calculation, you have a runtime error, compiler cannot help you with that
<Regenaxer> The interpreter only shows *what* is wrong, not how to fix it
<Regenaxer> It helps to understand
<kluk> beneroth in FP I choose where the risks are, if I care about VAT then I can encoded that care into types and have a non-runtime interpreter throw the error for me before I run the code (since I cannot say the word compiler anymore...)
<Regenaxer> both code and the problem
<kluk> Regenaxer in haskell the interpreter tells me what to fix
<beneroth> kluk, if the list of VAT codes you received is incomplete, than your type encoding is incomplete
<Regenaxer> The main issue in programming is to understand te problem
<kluk> beneroth I don't understand that, maybe because I know nothing about VAR
<kluk> VAT
<kluk> maybe you can give me a better example
<Regenaxer> The computer never can understand it
<beneroth> I try to think of.
<beneroth> I have the suspicion you want to solve problems I kinda don't have.
<Regenaxer> me too
<kluk> Regenaxer but regardless of the main issue with programming, you still seem to not agree with me that I do less thinking than you in picolisp, am I right in thinking that you do not agree with that yet?
<beneroth> yes, we disagree
<kluk> I don't want to solve problems, right now I want to understand how you see FP and the advantages of avoiding it.
<beneroth> we claim that we spend most time thinking about domain problems, and we cannot see how you reduce them.
<Regenaxer> kluk, we dont avoid it
kluk has quit [Read error: Connection reset by peer]
<beneroth> wanted to say the same
<Regenaxer> we use it where appropriate
<beneroth> it's just one tool
<Regenaxer> exactly
<Regenaxer> for simple, clear things
kluk has joined #picolisp
<beneroth> using only a single paradigm is like only using a single language.
<beneroth> wb :)
<kluk> <beneroth>we claim that we spend most time thinking about domain problems, and we cannot see how you reduce them.
<beneroth> so to repeat: we don't want to avoid FP
<kluk> [09:48:13] <beneroth>using only a single paradigm is like only using a single language.
<beneroth> but we see it only as one tool among a bunch of different tools
<kluk> beneroth I understand that part of your perspective
<Regenaxer> FP is the hammer
<Regenaxer> so everything looks like a nail
<kluk> no, that is I think a shallow assessment of a deep conversation that perhaps you are not appreciating
<beneroth> we believe you claim FP to be better than OOP or logic programming or... whatever. our point is: it depends on the use case.
<kluk> maybe because I am not doing a good job
<kluk> beneroth but you do not even agree that in FP one thinks less and the computer helps more?
<kluk> Regenaxer do you agree with as much?
<Regenaxer> I still think we mean different things with FP
<kluk> I am using the CS meaning
<Regenaxer> No idea
<kluk> CEK machine is FP, Von Neumann register machine is Procedural.
<beneroth> kluk, I disagree, I don't think that statement is true without some additional constraints
<kluk> Easiest way I can put it.
<Regenaxer> In any case not less thinking
<kluk> It is the academic definition, the one I use.
<kluk> CEK vs Von Neumann, that is FP vs Procedural. Do you understand the difference there?
<beneroth> SQL is FP, or was
<beneroth> agreed?
<Regenaxer> I dont know CEK
<kluk> Regenaxer so you actually think you do less thinking in picolisp than someone does in FP statically with types at "compile" time?
<beneroth> T
<kluk> Regenaxer look it up, it will help you understand what FP is (perhaps that is why you do not understand it, respectfully)
<Regenaxer> hmm, I never thought about "less thinking"
<Regenaxer> "better" thinking perhaps
<kluk> OCaml <- Caml <- Caml Special Light <- Cam <- ... CEK machine.
<kluk> Easiest way to explain it.
<Regenaxer> No idea about all of them
<beneroth> same
<kluk> Damn.
<beneroth> sorry :/
<Regenaxer> Never looked at OCaml
<kluk> Well but you surely have an overall vision of CS and its historical accomplishments?
<Regenaxer> Not sure if "overall"
<Regenaxer> I'm a meteorologican ;)
<kluk> Regenaxer oh so you do not have formal CS background?
<beneroth> kluk, do you actually claim FP would be the best (most effective in programming effort) choice to implement every use case? or if not, for what would it not be so useful?
kluk has quit [Read error: Connection reset by peer]
<beneroth> well what is a "formal" background.. some people come out of university without knowing who Knuth is xD
<beneroth> wb
kluk has joined #picolisp
<Regenaxer> kluk, no, I have no formal CS background
<beneroth> <Regenaxer> I'm a meteorologican ;)
<beneroth> <beneroth> kluk, do you actually claim FP would be the best (most effective in programming effort) choice to implement every use case? or if not, for what would it not be so useful?
<beneroth> <kluk> Regenaxer oh so you do not have formal CS background?
<beneroth> * kluk hat die Verbindung getrennt (Read error: Connection reset by peer).
<kluk> last I saw: [09:54:29] <kluk>beneroth I claim it is the way that allows me the least thinking in 99% of cases.
<beneroth> * Benachrichtigung: kluk ist offline (libera.chat).
<kluk> thanks
<beneroth> * Benachrichtigung: kluk ist online (libera.chat).
<beneroth> <beneroth> well what is a "formal" backgr
<kluk> (by the way I spent hours going around my router and could not solve this disconnect issue. reading your messages now...)
<beneroth> kluk, ok, that is an answer. so we must check out if your 99% use cases somewhat fit our 99% of use cases, or if we simply talk about different use cases ;-)
<kluk> beneroth I think formal CS background is a bachelor in CS. I do not have any formal CS background. All I know comes from loving CS.
<beneroth> same
<Regenaxer> ok, so the router is not guilty
<kluk> Well then I am marrying CS and you're just dating it :P
<beneroth> but my friend has a CS degree, he works as picolisp programmer with me.
<beneroth> he loves haskell.
<kluk> beneroth I should have said 99% of each use case (99% of the code base of any use case will be least-thinking if using FP)
<beneroth> ok
<beneroth> that is a even more general statement :D
<beneroth> with some space of side-effects ^^'
<kluk> the 1% is for the side-effects
<beneroth> s/of/for
<beneroth> hehe, now we're communicating
<Regenaxer> can we say "easier" thinking instead of "less"?
<kluk> Regenaxer the thing is you have a conception of "easier" that is perhaps different from mine and I don't want to entangle into semantic discussion
<kluk> what I am defending majorly is:
<Regenaxer> ok
<kluk> to me it feels like cheating doing FP, because it feels too easy, like I am getting something for nothing, and if you don't feel that using picolisp, then maybe you are missing something, or maybe you feel that way when you do picolisp because of feature X and I am missing something because I don't understand feature X
<kluk> The point is I would recommend FP to a beginner even just on the fact that it is easier
<kluk> nevermind any acdemic advantages
<kluk> academic*
<kluk> get it?
<beneroth> well we're cheating in having control of the entire stack instead of having to work around existing bloat we cannot ignore
<Regenaxer> yes
<beneroth> so it feels to me programming picolisp vs. other languages
<kluk> I would say to a beginner: "in FP it's always equations an substitutions and nothing else ever ever ever"
<kluk> "whereas in procedural, you deal with many different objects each with their own interface and API that you must learn separately etc"
<kluk> equations and** substitutions
kluk has quit [Read error: Connection reset by peer]
<kluk> you are cheating in having control of the entire stack, I am thinking about that, thanks for that.
kluk has joined #picolisp
<kluk> [10:00:58] <kluk>you are cheating in having control of the entire stack, I am thinking about that, thanks for that.
<beneroth> is it the connection between your device and your router, or your router and the internet?
<Regenaxer> We saw your last message
<Regenaxer> So nothing gets lost
<Regenaxer> only our messages perhaps
<olaf_h> > to me it feels like cheating doing FP, because it feels too easy > I think this will be the case in any situation where one uses the right tool in the right situation and knows how to handle it.
<kluk> Yeah but really I would like to drive home the point that I would recommend FP to a beginner solely on the basis of less thinking. I would say it's just always substitution based and there is never something new. And once they learn substitution that applies everywhere and even to types and even to kinds which are types of types. It never stops applying. It's only one rule. It's super simple. This is how I would
<kluk> talk to a beginner about FP. See I didn't mention anything about correctness or math.
<kluk> [10:01:29] <beneroth>is it the connection between your device and your router, or your router and the internet? |> that question would need to be dumbed down for me to answer it :P
<olaf_h> sorry, have to leave, but like to read further in irclog later. Bye :-)
olaf_h has quit [Quit: Leaving]
<beneroth> olaf_h good argument. cu :)
<kluk> yeah, that is a good point olaf_h
<Regenaxer> ok olaf, cu later
<kluk> beneroth sorry I am too dumb to answer your router question
<beneroth> kluk, your router has probably a website at 192.168.0.1 or 192.168.1.1 or 10.0.0.1, try to open these IP's in your browser
rob_w has quit [Remote host closed the connection]
<beneroth> if you still can open that website during disconnect, than the problem is after your router
<kluk> beneroth yes, that is the router admin interface at one of those IPs indeed
<beneroth> T
<kluk> beneroth that "disconnect" is only IRC-wise, I don't notice it anywhere else
<beneroth> ah ok.
<kluk> https://elm-lang.org/examples/buttons check this out, compare this with Javascript *in the mind of a beginner*
<beneroth> well we can agree that Javascript is an ugly mess :D
<beneroth> with "beginner" you mean "beginner in programming", yes?
<kluk> beneroth well, it's the preferred curly-braced C-family syntax of almost everyone so they cannot complain (the public at large)
<kluk> beneroth yes beginner at programming
<kluk> 1 min bathroom break
<beneroth> as a picolisper, I don't like the imports :P
<beneroth> same
<Regenaxer> me too
<beneroth> good we have all our own toilets :D
<Regenaxer> and take the device with us ...
<beneroth> that I don't do. but you are programming literally *everywhere* :D
<Regenaxer> T
<Regenaxer> not under shower yet
<kluk> Let me say it this way: I can code in SML, OCaml and Haskell; but I don't feel I know any SML, OCaml or Haskell; instead, it feels like those languages know something that in turn I know. And that to me is one part of "thinking less". In Ruby/C#/C++ I always have to learn *the language* because they haven't gotten around to finally decide once and for all (i.e. formalize) what an "object" is. So I gave up and went
<kluk> to the place where people decided what functions are, and now I can get away with know less (i.e. I don't know SML, OCaml, Haskell, but I can code in them because they know something I know, namely eval-by-substitution).
<kluk> Regenaxer check out the elm example on the link above if you care
<kluk> Regenaxer I suggested comparing that to the equivalent javascript code from the perspective of a beginner at programming.
<Regenaxer> I tried, but it shows nothing in my browser
<kluk> Regenaxer everything in that code can be explained in terms of substitution and just that.
<Regenaxer> I try another browser
<kluk> Regenaxer sorry about that, must be because they are javascript heavy
<Regenaxer> yeah
<beneroth> functional JS does not give a functional website
<Regenaxer> now works (in PilBox)
<Regenaxer> I always use w3m first
<kluk> So I feel that if I had to explain it to a beginner I'd rather explain two buttons controlling an integer in terms of "just substitution" than in terms of "objects, DOM, javascript, etc"
<kluk> gotcha
<kluk> I feel I can always get away with explaining much less in FP
<kluk> and that translates to quicker learning times
<kluk> in javascript, that code to be explained would need the concept of not just functions but prototypes, objects, DOM, so many things
<kluk> whereas in FP I only need to explain that everything operates through the same mechanism of substitution
<beneroth> but an integer on the screen is a state?
<beneroth> a side-effect
<kluk> it's very uninteresting as you put it, Regenaxer :)
<beneroth> controled by two actions (in Eric Normads terminology). no?
<kluk> because it's boring as it's always the same, just substitution and nothing else, ever
<kluk> beneroth the integer is a model
<Regenaxer> There is a very similar example in Rosetta
<Regenaxer> "GUI component interaction"
<kluk> beneroth meaning it's a structure that the runtime will know about
<beneroth> link ?
<Regenaxer> searching
<Regenaxer> yep
<beneroth> kluk, yes. just as devils advocate, the JS beginners now don't get teached raw JS but some sort of JS framework.. where you have button and integer and than it's the same again, no? :P
<beneroth> (not that I like those frameworks. I find them horrible bloaty)
<kluk> beneroth yes but you see, that is substitution envy, because in JS you cannot just abstract away from it totally and natively arrive at Elm - it needs to be done as a separate walled-garden language as Elm is, in order to keep FP possible.
<beneroth> Regenaxer, the Picolisp implementation is certainly smaller than the Haskell or Scala versions
<kluk> the picolisp implementation is also FP and does not compete with the Elm one
<kluk> nor the Haskell nor Scala ones
<kluk> the picolisp implementation on that link is evaled by-substitution
<beneroth> yes, all lisp is? including the OOP in picolisp?
<beneroth> no?
<kluk> in fact it is very strongly reminiscent of tcl which is also by-substitution
<beneroth> this piece of code has some OOP in it, btw
<kluk> all lisps that I have seen are by-substitution and hence FP
<Regenaxer> What is by-substitution here?
<beneroth> '(+Var +NumField) is defining the parent classes of the gui element
<kluk> Regenaxer every time you see an open-parenthesis in that code, and you match it with its close-parenthesis, that form is eval'ed to its simplified (head-normal form) and then that resulting value is substituted for the form.
<Regenaxer> OK, thoug I would not call this substitution
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<Regenaxer> by-substitution means replacing something
<kluk> You cannot avoid FP if your language feels like coding in an AST (which is what Lisps feel like always)
<kluk> ASTs eval by substitution, period.
<kluk> Therefore if your language is homoiconic to ASTs then they are evaled by substitution forcibly.
<kluk> You cannot escape it.
<kluk> Or, I am wrong, and I will be shown lisp code that escapes looking like its exact AST.
<Regenaxer> Note that in this example there are 3 different points in time of evaluation
<Regenaxer> ore more
<kluk> Regenaxer but I cannot read it sequentially - it's too far from possibly being procedural
<kluk> I can only read it from inside out
<kluk> like an AST
<Regenaxer> yes, thats ok
<kluk> oh I am not criticizing it
<kluk> just better defining FP
<kluk> To rewrite that code in procedural, the html would need to be some sort of StringBuilder buffer...
<kluk> etc.
<beneroth> kluk, "feels like" ? picolisp is coding the AST
<kluk> beneroth right, but the reality does not matter because in reality all programming languages are equally turin-capable. what matters is the facilities.
<beneroth> the runtime representation of a picolisp program is just a binary representation of the source code.
<kluk> hence, feels like matters.
<kluk> yes I get it.
<kluk> but it's not relevant.
<kluk> What matters is the language the programmer uses.
<beneroth> agreed
<kluk> If that language needs to translate to cpu microcode or make a deal with the devil doesn't really matter.
<beneroth> I find it does
<beneroth> because this deals bring in constraints and bloat
<kluk> Tell me why
<kluk> how so
<beneroth> the interface offered to the programmer is usually more restricted than what the translator/compiler can do
<beneroth> often on purpose
<kluk> but I am lost. what is the point you are making, first?
<beneroth> this is not our main point of discussion. but my point is, the more layers between the programmer and the machine, the more restrictions you usually have in practice
<kluk> I want to have whatever restrictions that allow the computer to help me thinking.
<beneroth> but let's go back to the specific GUI example
<beneroth> well
<kluk> in fact I also dabble in sub-turing DSLs.
<kluk> okay let's go to any example you want
<beneroth> I want to be able to control that stuff, so I can add or remove restrictions as I need it
<beneroth> including adding restrictions.
<beneroth> T
<kluk> beneroth me too but I want to start from a place-of-least-thinking as default
<beneroth> yeah sub-turing DLS are great :)
<Regenaxer> I think we should discuss that GUI interactio
<beneroth> T
<kluk> okay GUI discussion
<Regenaxer> mple in pilCon
<beneroth> ah
<beneroth> good idea
<Regenaxer> It seems intersting
<Regenaxer> It adresses kluk's question of advantages of dynamics
<beneroth> kluk, so you say it is FP, but we say it's full of OOP. so indeed those paradigms can be combined and it might me meaningful to combine them sometimes?
<Regenaxer> yes, oop too
<kluk> beneroth what is happening is this: look at CLOS for instance, the object system in CL. It's an OOP system. Okay. But it's coded in a language that evals by simplification. Lisp does not take steps. Even progn in lisp is denotationally equivalent to lambdas/lets, so the fact it becomes a sequence of instructions in assembly is not important (it would become simplification instruction on a lisp machine cpu, for
<kluk> instance, so the cpu here is incidental). What matters is that Lisp is by-subst and sure you can make an OOP system in a by-subst language but look at OCaml and how many people use its OO system (answer: 1% of OCaml users) and try to think about why... I think it's because OOP becomes redundant in FP where you have closures-a-la-carte.
<beneroth> I don't know CLOS
<Regenaxer> OOP does not become redundant
<kluk> OCaml achieved a very impressive feat of fitting OOP type system within an extended lambda calculus... and nobody cared.
<Regenaxer> the purpos is different
<kluk> Yeah because no one usually cares about OO systems in by-subst languages, that's why you don't know about CLOS :P
<Regenaxer> I use oop when the future is unknown
<beneroth> no, because I never learned Common Lisp
<Regenaxer> which it often is
<beneroth> I found out that Common Lisp has platform dependencies and multiple compilers and found I had enough of that with C++, no thanks.
<kluk> Regenaxer closures are objects are closures. in FP therefore objects become redundant because closures can give you object basics and then you can build on top of that yourself, hence a la carte
<beneroth> kluk, if closures are objects, than programmign with closures is OOP paradigm, no?
<Regenaxer> Objects are not the oint
<Regenaxer> point
<kluk> beneroth yeah I don't use any language that acknowledges that the computer exists (they get too distracted talking about that)
<Regenaxer> it is polymorphism and inheritance
<beneroth> T
<beneroth> and message passing
<Regenaxer> yes
<Regenaxer> so you can extend any time
<beneroth> mixin
<Regenaxer> without touching what is there
<Regenaxer> yes, prefix in pil
<kluk> beneroth closures are objects in a basic sense; notice there is basically no formalized definition of an object; but in its coalgebraic form it is nothing but a closure, yes. however OOP objects are that plus inheritance, polymorphism, etc
<kluk> Regenaxer "extend at any time without touching what is there" is one of those principles that I understand that people hold fast too but I think is bunk.
<kluk> I had rather throw away code and replace it with new code than "extend code" which sounds icky
<beneroth> no, that is the core point of our discussion
<kluk> okay sorry, put be back on focus
<Regenaxer> It is extremely important in some cases
<beneroth> you don't want to rewrite half or the whole program when something needs to change
<Regenaxer> You don't know the full problem domain
<beneroth> and things change all the time
<beneroth> it is a red queen situation
<kluk> beneroth okay but that is a caricature that never happens. when all my functions are one-liners, yes I prefer to throw away one line and rewrite it.
<Regenaxer> So extending or modifying later always involves changing existing code
<Regenaxer> not wih OOP
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> Regenaxer extending and modifying later aka the Expression Problem is *solved* by type classes in all FP languages except in SML and OCaml where Functors/Modules solve it.
<kluk> last: [10:41:15] <Regenaxer>not wih OOP
<beneroth> one liner functions is not good enough. we also want to reduce number of functions.
<kluk> Regenaxer I disagree with "So extending or modifying later always involves changing existing code; not wih OOP" that is wrong, you are outdated in that knowledge; type classes solve that expression problem for FP.
<kluk> It's over, that problem is solved, it's old news.
<beneroth> we put in extra effort to remove stuff. because then it's later easier to add.
<kluk> beneroth see, I don't want to reduce the number of functions
<beneroth> kluk, you need to solve it better
<beneroth> ok
<kluk> this is an inherent and interesting disagreement we have
<beneroth> yes!
<kluk> I think more functions = better, I want tons of tiny functions
<beneroth> we optimize for software maintenance
<kluk> me too
<beneroth> nah, then you end up with node.js
<kluk> you just think doing that is exclusive to your side
<kluk> it's not
<Regenaxer> kluk, "type classes" sounds a lot like oop
<kluk> I;'m trying to make you see
<Regenaxer> reinventing the wheel
<kluk> OOP did not exclusively solve the Expression Problem folks, please :)
<kluk> :)
<beneroth> yes
<beneroth> not exclusively
<kluk> please look up the Expression Problem, it is solved in SML, OCaml, Haskell....
<kluk> it's solved.
<kluk> Let's address unsolved problems.
<kluk> that you think are problems.
<beneroth> we don't claim exclusivity. but we claim Regenaxer solved it better then some other approaches :)
<Regenaxer> Which problem is solved?
<kluk> the Expression Problem
<Regenaxer> whay is it?
<beneroth> or other way: what is unsolved if it is turing-computable?
<kluk> The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts).
<Regenaxer> The point of inheritance is overriding
<kluk> OOP and procedural people think they have exclusivity to that solution
<Regenaxer> non-destructively
<Regenaxer> FP people too
<kluk> Regenaxer I am trying to end this tangent by saying that concern of yours is taken care of already.
<kluk> Do you disagree in some capacity?
<Regenaxer> I have no concern
<kluk> look under "Solutions"
<Regenaxer> it is trivial in inheritance
<kluk> there are: Type classes, functors, tagless-final, all of which are used in FP
<Regenaxer> What is the expression problem?
<kluk> the expression problem is that problem that you brought up about extending without changing
<kluk> you want to do that, me too
<kluk> we all do
<kluk> and we do already in FP
<kluk> using type classes, just as easy as inheritance, without the mess and ickyness
<kluk> no taxonomies, it's a flat mixin-like scenario
<Regenaxer> How do you change an *existing* type?
<Regenaxer> ok, mixin is what pil does
<Regenaxer> it is oop for me
<kluk> "change"?? "change" will cause "change" no matter the paradigm, right?
<kluk> You already said "change" so you painted me into a corner
<Regenaxer> no
kluk has quit [Read error: Connection reset by peer]
<Regenaxer> it changes only behavior
<Regenaxer> not code
kluk has joined #picolisp
<Regenaxer> overriding
<Regenaxer> I said: "it changes only behavior"
<Regenaxer> not code
<kluk> give me a concrete example
<kluk> if you could
<kluk> so I can give you the equivalent in FP and show no change
<Regenaxer> I can give an object a method which runs only for *that* object
<Regenaxer> all other objects of that class don't change
<kluk> there's no equivalent for me there as I don't have objects sitting there at runtime waiting to receive messages in FP
<Regenaxer> It is how the message is interpreted
<Regenaxer> ok, then a class
<Regenaxer> a subclass
<kluk> well I don't have objects in FP so I don't have that problem? Don't know how else to answer it.
<kluk> Tell me a use case
<kluk> You need to extend client to have a birthday?
<kluk> is that it?
<Regenaxer> No, not data
<Regenaxer> behavior
<kluk> oh, then it's even easier
<kluk> you want to add behavior without changing anything, okay, easy
<Regenaxer> good
<kluk> just say that your data is now a ThingThatDoesX and that every ThingThatDoesX implements X and now you implement X for your data and pronto nothing was changed.
<Regenaxer> so you talk about oop
<Regenaxer> It is just terminology
<Regenaxer> you say data I say objects
<Regenaxer> you say types
<Regenaxer> I say classes
<kluk> but we're getting lost in semantics again, or what is your point?
<Regenaxer> I have no point
<Regenaxer> you said oop is obsolete
<Regenaxer> I said it is extremely useful
<Regenaxer> in pil
<Regenaxer> it is not what is in Java or C++
<kluk> well it seems smart people who like it only do it in by-subst languages such as yourself and present company :)
<kluk> so you obsoleted OOP
<Regenaxer> I still don't get that "subst"
<kluk> look up the CEK machine
<kluk> to explain FP is to explain what CEK is
<Regenaxer> no time for that
<kluk> just look at what it is, that is FP, whatever language behaves like that is FP
<kluk> well, too bad, that is the definition of FP
<kluk> CEK is basically what defined it.
<kluk> We must always make time to improve in our constantly changing field
<Regenaxer> I stay with Eric Normand's definition
<kluk> there's no "stay" in our field
<kluk> it's constantly growing and changing
<Regenaxer> right
<kluk> to stay is to be left behind
<Regenaxer> you should learn PicoLisp :)
<kluk> why does Eric Normand disagree with those he does? Have you asked that?
<kluk> Regenaxer I am trying but it is too hard, I don't have the memory to commit conventions to
<kluk> I find that weird and I don't see how I have to memorize things while sitting at a computer, I find it odd and ultimately I don't get it
<kluk> it's not true to me
<Regenaxer> Then try to understand it!
<Regenaxer> You are just theorizing
<kluk> The ideal programming language meets me halfway, comes at me with live help, while I code, almost a dialog with me, I feel that picolisp is like a princess that is playing too hard to get
<Regenaxer> PicoLisp evolved from decades of praxis
<Regenaxer> it is ultimate pragmatism
<beneroth> T
<beneroth> Eric Normand states that the general FP definition is not clear enough, not defining all things, merely implying some. I listened that podcast epsiode just yesterday.. let me find it
<kluk> Eric Normand is incorrect in that regard, I will talk to him over the phone any day,
<kluk> FP is clearly defined
<kluk> and implemented in the CEK machine
<kluk> what you've never seen is the "object machine" where is that?
<kluk> nowhere, because OO is ill-defined. Unlike FP.
<Regenaxer> You have no idea, sorrt
<Regenaxer> sorry
<Regenaxer> What I mean with oop is pil's oop
<beneroth> T
<Regenaxer> otherwise oop is not defined, yes
<kluk> I have no idea of what?
<beneroth> let's try another approach then
<Regenaxer> of the oop *we* mean
<beneroth> why don't you program your FP stuff in picolisp instead of chicken? :D
<kluk> Right, because each language defines OOP as they wish
<Regenaxer> T
<kluk> but FP was defined in 1964, actually in the SECD machine: "The machine was the first to be specifically designed to evaluate lambda calculus expressions. It was originally described by Peter J. Landin in "The Mechanical Evaluation of Expressions"[1] in 1964. "
<beneroth> you define FP like that. others define it differently
<kluk> "The description published by Landin was fairly abstract, and left many implementation choices open (like an operational semantics)."
<kluk> Guess what is the only way to define a language without an operational semantics?
<kluk> Answer: if it's FP.
<kluk> beneroth No
<kluk> beneroth I do not subscribe to relativism
<kluk> beneroth CS is a field with define nomenclature
<kluk> we use our nomenclature in our field
<kluk> names have meanings
<beneroth> well you should the read the memo by Einstein, relativity is real :D
<kluk> the beginning of wisdom is calling things by their names.
<beneroth> yes, but what if you run out of names?
<kluk> beneroth I don't care for Einstein, if you want to explore that I could show you he did not prove relativity.
<kluk> beneroth then use AAAAAA, AAAAB, AAAAC, etc
<kluk> beneroth that's not a serious question of yours
<kluk> in lambda calculus functions are lambdas, hence anonymous
<kluk> we don't need names
<kluk> hence we don't run out
<Regenaxer> Nonsense
<Regenaxer> This discussion becomes pointless
<beneroth> yes
<Regenaxer> We are talking of different thigs all the time
<kluk> Well, you don't seem to want to accept the academically accepted definition of FP within the field of Computer Science.
<beneroth> it's theorizing without practical meaning
<Regenaxer> things
<kluk> I cannot force you to accept it.
<Regenaxer> right
<kluk> Nor do I want to.
<kluk> Regenaxer we are only talking about different things all the time because you use your words loosely
* beneroth is still confused if *we* are doing FP now or not xD
<kluk> I use my words in a fixed way so as not to get confused
<kluk> beneroth you cannot escape FP in lisps
<beneroth> we don't understand your words
<Regenaxer> kluk, no, I have clear definitions
<kluk> beneroth which words?
<kluk> point htem out
<kluk> them*
<kluk> Regenaxer your definitions are not the academically accepted definitions
<kluk> Regenaxer they are idiosyncratic
<Regenaxer> Who cares?
<kluk> Regenaxer I care about CS.
<kluk> who else?
<kluk> hands up
<kluk> o/
<beneroth> kluk, your definitions are not accepted in practice. see wikipedia for https://en.wikipedia.org/wiki/Functional_programming
<kluk> wikipedia is not an authority in CS
<beneroth> "In computer science, functional programming is a programming paradigm where programs are constructed by applying and composing functions."
<kluk> I gave you the quote
<kluk> Landin invented SECD
<Regenaxer> I give up
<Regenaxer> you are a fundamentalist
<beneroth> kluk, well ok then look up stack overflow, it plays even less strict with words than wikipedia
<kluk> it's not about applying and composing functions because you can do that in C++ right?
<Regenaxer> we are pragmatics
<kluk> so it cannot be that, just think a bit
<kluk> I don't know what "fundamentalist" means in CS
<beneroth> kluk, you are not working as a programmer, right? you will get a hefty culture shock if you ever get into the industry
<kluk> beneroth stack overflow? why not textbooks and papers in the CS field?
<Regenaxer> afp, bye!
<kluk> beneroth I sure am and have been for quite a lifetime
<beneroth> ok, what software did you produce?
<kluk> why do you think wikipedia and stackoverflow define CS?
<beneroth> not in academia. but most programmers are by now people with a 2 week training on stack overflow examples. doesn't matter if you/me like it or not, that is reality
<kluk> wait, but we are again at this appeal to authority thing. if you measure opinions in terms of achievements of the interlocutor, then I can give you a list of 5 Turing Award winners that say what I am saying. Do you want that?
<kluk> beneroth the fact that people trust stack overflow or not does nothing to define what CS is
<kluk> wrong people being wrong online
<kluk> is nothing new
<kluk> changes nothing in CS
<kluk> just because stack overflow has a cool CS-y name, it means nothing
<kluk> What matters is arguments and proof. I am trying to prove what I am saying by showing you who defined FP, Landin.
<kluk> Your refutation to that is "wikipedia and stackoverflow"
<beneroth> kluk, here is a paper by the first turing award winner, explaining why your approach does not fully work: https://www.cs.umd.edu/~gasarch/BLOGPAPERS/social.pdf
<kluk> that is barely a debate
<Regenaxer> ret for a moment
<kluk> by Turing Award winner there you mean Alan Perlis?
<kluk> he was for FP
<Regenaxer> beneroth, after 20 years there is a nice new feature in E/R
<beneroth> Regenaxer, yeah? :)
<Regenaxer> I should explain in PilCon
<Regenaxer> in short:
<beneroth> yes
<Regenaxer> Joints were not allowed in +Bag's
<kluk> “It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.” —Alan Perlis
<Regenaxer> Now they are
<Regenaxer> in a restricted form
<Regenaxer> I needed iy
<Regenaxer> it
<beneroth> ok
<Regenaxer> and it turned out to be possible
<beneroth> I still have some issues with joints an inheritance I think
<Regenaxer> really?
<beneroth> I don't recall the details right now. might well be an artefact of my system which is not present in pure picolisp
<Regenaxer> We should look at that on the 20th. can you join?
<beneroth> yes..on second thinking it is... my mistake..
<Regenaxer> ok :)
<beneroth> sunday, yes certainly
<Regenaxer> cool!
<Regenaxer> I missed that feature sometimes
<beneroth> yeah
<beneroth> bags must be used sparsely, but they're meaningful
<Regenaxer> and used kludges like in-between-objects
<beneroth> sometimes I use a different entity instead of a bag
<beneroth> T
<beneroth> exactly that :)
<Regenaxer> yes, thats fine too
<beneroth> it's fine, and more exact in pure database modeling, but actually it's not picolispy
<beneroth> because on application layer you want to ignore this kludges usually
<beneroth> unless they have additional attributes
<Regenaxer> The point with joints was that they did not know enough about the bag
<beneroth> yeah!
<Regenaxer> Now there are two optional function arguments
<beneroth> so more metadata into the daemon object?
<beneroth> ah
<beneroth> "actions" for? :P
<Regenaxer> (rel (+Joint) foo (+Cls) list asoq)
<Regenaxer> actions to put and get
<Regenaxer> on the opposing bag side
<beneroth> perfect
<beneroth> yes that was missing
<beneroth> combination with +List works as before, all fine?
<Regenaxer> What not works if there are bags on both sides
<beneroth> ok. but +List on both sides?
<Regenaxer> yes, +List is fine
<Regenaxer> (+List +Joint) ... (+List +Bag)
<beneroth> kluk, SCNR, therefore we have only 3 datatypes in picolisp. why do you use more? :p
<beneroth> Regenaxer, nice
<beneroth> oh that is useful
<beneroth> so you can flavour one side with additional attributes not needed on the other end
<Regenaxer> yes
kluk has quit [Read error: Connection reset by peer]
<Regenaxer> my use case: http://ix.io/3pWB
<Regenaxer> Sorry, must go
<Regenaxer> afp again
kluk has joined #picolisp
<kluk> beneroth: maybe I should use fewer. that is why I am here asking questions, to learn. My question for you is, if you have 3 types, why not have the picolisp interpreter know about those types and help the programmer somewhat instead of forcing the programmer to memorize conventions? Why are programmers of programming languages so resistant to teaching their thoughts to their languages so that that knowledge does
<kluk> not live only in docs and minds but in live code?
<beneroth> Regenaxer, I see. a collection of flags.
<Regenaxer> yes, in this given case
<beneroth> kluk, please stop making assumptions.
<Regenaxer> afp
<beneroth> kluk, these 3 data types are static and strong typed in picolisp. immutable even.
<kluk> so as I am writing the code can my emacs connected to picolisp help me not type code that clearly does not work given what picolisp knows so far about my code?
<kluk> I want to code while holding hands with the computer, I think that is not coming through. I feel it is a waste to sit at the computer while it waits for me to type.
<kluk> I cannot get over that, maybe I am not seeing something.
<beneroth> yes. why even use emacs. use the much smaller vip.
<kluk> as the years go by into the future ideally I want programming languages to force me to memorize increasingly less things, less conventions, and that those programming languages help me increasingly more and more automatically while I type and proactively help me avoid errors-that-only-can-be-seen-in-the-future-when-the-program-runs.
<kluk> how do you see the future changing? will you be committing to memory more or fewer things? etc?
<beneroth> our strategy is to be as small as possible. leave away as much as you can, because than it's easier to find the right spot to add something later if needed.
<beneroth> also less code: less code to test, less code to read, less code that contains bugs.
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> beneroth that sounds like my strategy
<kluk> if you are interested in exploring what FP is, that should make you curious
<kluk> Also, re your Alan Perlis paper, here are some Alan Perlis verified quotes:
<kluk> Syntactic sugar causes cancer of the semicolon. -- Alan Perlis
<kluk> A programming language is low level when its programs require attention to the irrelevant. -- Alan Perlis
<kluk> Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Alan Perlis
<beneroth> we all agree on that
<kluk> "In English every word can be verbed. Would that it were so in our programming languages."
<kluk> -- Alan Perlis
<kluk> See? Verbs, not nouns.
<kluk> He likes FP.
<kluk> beneroth what is interesting to me about all this is that you say you are interested in learning more about FP but your rhetoric displays resistance to it
<beneroth> :)
<beneroth> yes :)
<kluk> What new things did you learn in your latest research on it? Was it actually done in earnest or to try to refute it? I can tell you I looked for good dynamic binding examples but could not find any.
<kluk> However you will definitely find examples if you type "how does fp solve the expression problem" etc
<kluk> So I feel some of the questions I am made are too basic to even start being understood, so much so that you all are still confused about what FP is
<kluk> Such a clearly defined thing.
<beneroth> I'm only interested in getting quicker at programming and updating software. I thought maybe FP has to offer something which is not covered in picolisp for me yet. The search continues....
<kluk> Have you dismissed that possibility that FP has something to offer not covered in picolisp already?
<kluk> or are you still searching?
<beneroth> you didn't answer my questions about what software you produced, or why you don't give programming in picolisp a try :)
<beneroth> both :)
<beneroth> opinions are temporary.
<kluk> Because I don't think that is a mature question, unless you can reveal the chaining in reasoning: let's say I coded nothing. Does that mean my opinion does not matter? On the other hand let's say I won a Turing Award, does that mean my opinion matters more? Why not just go by *logic* and screw the name of the person who created the argument? Why don't you think that way? Can you explain to me why does a programmer
<kluk> not care about the arguments solely but does care about appeal to authority?
<kluk> I gave up arguing with appeals to authorities when I was still a teenager
<beneroth> I would weight having produced software which is in practical use more highly than a turing award. much of CS is not about optimizing software programming.
<kluk> but that weight is towards what? the validity of my arguments? can you explain the chain in reasoning there? how does having worked in X and Y company make my argument about Z stronger?
<kluk> I will answer any question you can prove relevant.
<beneroth> not validity. weight if I should invest more lifetime for the promise of increased productivity later. or I don't should play this gamble.
<kluk> I can find you a guy with a better resume than you and pay him to argue my points, now what?
<kluk> what happens then?
<kluk> you don't have to hear it from me
<kluk> I can find you very high level people that say what I say
<kluk> how will that affect your thinking?
<beneroth> I ask the same questions: what software have you done using that approach, for how long is it in use, how many changes did you make to it and how hard was that?
<beneroth> once I'm satisfied with the answers, I will try the approach myself. and then make it part of my approach or toss it aside.
<beneroth> this way I came to picolisp :)
<kluk> beneroth the answer to all those questions I already gave you before, I can see you did not care to check. Go to youtube, type noredink elm haskell, you will find that company answering all your questions, they are profitably in business, full of programmers with impressive resumes that make the arguments I am making, so what is your next move now?
<beneroth> yes. and same applies to Regenaxer and me? that is not good enough. they must also be better.
<beneroth> or else why should I switch my strategy which is working for me?
<kluk> "they must also be better" what does that mean? the devs I find must be better than you and Regenaxer for their arguments to count?
<beneroth> no, their arguments my be valid. I don't care. they must be better for me to considering making their approach into my approach
<beneroth> only results count.
<kluk> beneroth it's really hard to communicate to you because you are so resistant. Look at your question: "or else why should I switch my strategy which is working for me?" The answer is : only you care about improving your own life. If you do not care about improving, don't spend time researching for potentially better ways to do the same things; if you do care, then do spend the time.
<kluk> I am willing to show you FP if you are willing to learn it but you think you can be proven it's better for you without you learning it. That is not possible.
<beneroth> yes, potentially better. How can I know if its really better or if I'm already at a better local optimum?
<kluk> yoiu have to try it first
<beneroth> ok
<kluk> invest time
<kluk> there's no "knowing if it's better for me" without trying and either burning yourself or reaching nirvana
<kluk> does that make sense?
<kluk> I did not know if FP was going to "be better for me" in the beginning and the first 4 years
<kluk> (but I learn slowly, don't be scared)
<beneroth> well if you cannot prove it's better without learning it, then I ignore it. you basically say there are no products which demonstrate the superiority (e.g. by having half the development time compared to another approach while having higher user satisfaction)
<beneroth> yes
<beneroth> but you arrogantly believe that your approach is the best, without trying out picolisp :P
<kluk> beneroth: no one proved to you the way you do it now is better than FP. you are a victim of fate, then, and you think that is smart?
<kluk> beneroth I have used dynamic binding before, picolisp did not invent
<kluk> it
<kluk> I have also used 4gl languages, having an embedded DB and gui system is normal to me
<kluk> "you basically say there are no products which demonstrate the superiority (e.g. by having half the development time compared to another approach while having higher user satisfaction)" |> dude, I said you can find on youtube many testimonials. I said the *opposite* of what you are accusing me of having siad.
<kluk> Don't slander me like that, please.
<beneroth> well then provide links instead of mere claims.
<beneroth> and please something to read, not youtube.
<kluk> you can see in the past logs I've told you several times you can google haskell elm testimonials and youtube that too
<beneroth> if the abundance is that big, then there must be stuff.
<kluk> it's too easy, there's too many
<kluk> just look for them
<kluk> I gave you the keywords
<kluk> watch whichever you like
<kluk> many to choose from
<beneroth> do you recommend a specific one which you find points out the benefits better than other testimonials?
<beneroth> also, as you are unsure if we do here FP or not (I would think we do, but not pure FP), how can you be sure that we don't already make optimal use of FP?
<beneroth> I don't want to do the work of choosing myself if you can recommend me something on your authority.
<kluk> beneroth I am not unsure that lisps are stuck being FP. You don't already make optimal use of FP because your not-compiler is oblivious to things it could know, that is, the algebra of the language and how its types relate to its functions, which it clearly knows about but leaves the programmer to do from memory (or I am wrong about that and I am assuming it)
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> beneroth I can recommend you others if you don't like that one for any reason
<beneroth> thx
<beneroth> you seem to talk about very minor mindless problems
<beneroth> : (+ 1 'a)
<beneroth> !? (+ 1 'a)
<beneroth> a -- Number expected
<kluk> minor mindless problems? how did you conclude that?
<beneroth> still youtube though, nothing to read.. will watch later. I can read faster than watching, I don't like watching unless I can do it while doing something else
<beneroth> kluk, how types relate to functions. how is that ever a problem?
<beneroth> what can go wrong?
<kluk> I am always busy doing something else which is why I prefer videos
<kluk> beneroth I am not sure I understand your question. how do types relate to functions? where? in general? in general types are the formulas that functions prove.
<kluk> beneroth do you know APL?
kluk has quit [Read error: Connection reset by peer]
<beneroth> not really. it's successor MATLAB is good for number crunching. I'm not interested in number crunching.. when I need to do number crunching, I use a language optimized for it.. might be eve APL
kluk has joined #picolisp
<beneroth> <beneroth> not really. it's successor MATLAB is good for number crunching. I'm not interested in number crunching.. when I need to do number crunching, I use a language optimized for it.. might be eve APL
<kluk> sorry, just a sec!
<kluk> Okay, APL is not for number crunching only, it's a general purpose programming language (!)
<kluk> beneroth it's a shame you don't have time to watch something like this, it would cut much time needed spent looking at examples yourself: https://www.youtube.com/watch?v=9xCJ3BCIudI
<beneroth> I will watch soon
<beneroth> ok
<kluk> that would help you understand my mindset
<beneroth> well I would like to find at least one example of something which I cannot do easier in picolisp
<beneroth> which doesn't invalidate your claim that *it* works well for you...
<kluk> but that comes with a refinement: that the thing you find that cannot be done easier in picolisp have nothing to do with embedded databases nor embedded gui systems. Because not only am I not arguing against those, those have nothing to do with procedural versus FP. I think the focus that I would suggest to you is the narrower proposition that FP is better than dynamic binding languages. In (chicken) Scheme I have
<beneroth> we don't claim that picolisp is the best choice for everything or everyone
<kluk> an embedded database (now) and there is a very good web library there that does gui very nicely.
<kluk> beneroth yeah so let's touch on that a bit, that is also something important, that things are not best for everyone, I totally agree
<beneroth> for some people Java / C# is the best
<kluk> but I think it is important to understand that difference so that we can all stop fighting and understand each other better
<kluk> I agree
<beneroth> probably those people are the most numerous even
<beneroth> also chicken has nothing on picolisp as long it doesn't come with a flight simulator :P
<beneroth> (that didn't work for a while, haha)
<beneroth> I think even excel once had one, as an easteregg. but an older version...
<beneroth> more serious.. how easy can you interface with other software in chicken?
<Regenaxer> ret
<Regenaxer> uh, still ongoing :)
<kluk> beneroth I think chicken has one of the easiest FFIs although I do my best to avoid it as for me they always become a time vampire
<beneroth> what about CLI wrapping?
<kluk> I think it offersw a 1:1 dsl in which you can just rewrite the header file for the C library you want to link tp
<kluk> to*
<beneroth> CLI wrapping is definitely one of the cheats of picolisp
<kluk> CLI wrapping? I use rlwrap for development. Do you mean if it comes with readline?
<Regenaxer> No, calling external cli programs
<Regenaxer> eg. 'curl'
<beneroth> like unix pipes work
<Regenaxer> yes
<Regenaxer> (in (list "curl" URL) (while (line) ....]
<kluk> ah, never heard of that as cli wrapping, interesting, sure making system process calls, I think it could be more straightforward to be honest because last time I attempted to use it to do IO with some other program I spent 3 hours and did not achieve full ability to communicate back and forth and keep the pipe going.
<beneroth> sounds like you could benefit from picolisp :)
<kluk> but with macros eventually any code can look like the one you posted in chicken scheme
<kluk> hahah
<beneroth> after you learned how it works in pil, you can go and implement it in chicken :P
<beneroth> if you can do it, as a compiled language
<Regenaxer> To call FFI in pil, you do things like:
<Regenaxer> (%@ "socket" 'I AF_INET6 SOCK_DGRAM 0)
<Regenaxer> i.e. open a socket
<Regenaxer> How would thay look in chicken?
<Regenaxer> AF_INET6 and SOCK_DGRAM are just constants
<beneroth> could be functions, to be more FP :P
<Regenaxer> sure :)
<Regenaxer> But socket() is never FP
<Regenaxer> it depends on *when*
<Regenaxer> (usually ;)
<kluk> There's a proof already that any interpreted program can be compiled. I am pretty sure the chicken scheme compiler is an instance of such proof. So that difference is really immaterial. In fact, can you explain to me why this focus on interpreted versus compiled? what difference does it make? isn't your beef instead specifically with some bad things that became associated with compiled languages, that really don't
<kluk> have to have anything to do with it
<kluk> Regenaxer I am quite sure in scheme it is quite more verbose than that; it ends up looking like what it would look like if you wrote C header file prototype signatures in scheme
<Regenaxer> ok
<Regenaxer> PicoLisp code cannot be compiled because the compilation would be useless
<Regenaxer> it cannot call any built-in functions
<beneroth> "proof that any interpreted program can be compiled" ? wat mate? FEXPR's mate?
<Regenaxer> But PicoLisp has a compile for a variation, "PilSrc", i.e. the implementatien language
<Regenaxer> yes, in pil all are fsubrs, they interprete thier args at runtinm
<Regenaxer> so no static compilation is possible
<kluk> Regenaxer wait, why is it not possible to compile a program that contains an eval function? isn't ECL a thing? That's a Common Lisp that compiles to C and has eval.
<kluk> chicken scheme compiles to C and has eval.
<kluk> what am I missing?
<Regenaxer> Thats not the point
<Regenaxer> (+ (foo) (bar))
<Regenaxer> a compiler compiles calls to foo and bar
<Regenaxer> then: calls '+', right?
<Regenaxer> '+' is complex, not a single instruction
<beneroth> good line of explanation
<Regenaxer> (bignums)
<Regenaxer> But '+' interprets the arguments
<Regenaxer> Not usable in the above code
<kluk> in the most common case, yes, but not necessarily, right? Anything you want is possible in programming if you specify it. Imagine this: (with-late-binding (+ (foo) (bar))) are you saying with-late-binding is impossible to code and compile into your programs that you'll ship?
<Regenaxer> Any code in pil can be arbitrarily dynamic
<Regenaxer> Compilation may be provable
<beneroth> input (from user or other software) might be not known during compile time, or even during shipment.
<Regenaxer> but it would need to emulate all that behavior
<kluk> srfi15
<kluk> fluid-let
<kluk> it's done
<Regenaxer> A compiler is static by definition
<kluk> and it compiles to C
<kluk> but it can do whatever you programmed it to do
<Regenaxer> Gives monster-code, extremely slow and unusable
<kluk> if you program it to look up a v-table
<kluk> it'll do that
<beneroth> does it not only solve it by compiling an interpreter into the final executable, kluk ?
<kluk> beneroth isomorphically yes
<Regenaxer> yeah
<Regenaxer> So that proof is useless
<kluk> wait, what is the problem with that?
<kluk> what law does it infringe?
<Regenaxer> No problem at all
<beneroth> kluk, picolisp is just that interpreter
<Regenaxer> T
<Regenaxer> it operates on data
<beneroth> code is data.
<kluk> but I think Regenaxer was implying picolisp could not produce compiled binaries
<Regenaxer> It can
<Regenaxer> but for PilSrc
<Regenaxer> which is another language
<kluk> so what did you say was impossible exactly?
<Regenaxer> To build a compiler for PicoLisp
<kluk> that is a difference that evades me but okay, let's go with that
<beneroth> kluk, we ship the source code to where the program is executed
<Regenaxer> I decided that earyly on
<beneroth> there is no difference between source code and the program
<kluk> beneroth are you saying that is an unavoidable fact and detriment?
<Regenaxer> a compiler would need many compromizes
<Regenaxer> and drawbacks
<kluk> oh, that is what picolisp does, yes
<kluk> well with everything there are trade-offs
<beneroth> T
<Regenaxer> yeah
<kluk> but to say it is impossible is not accurate
<Regenaxer> a compiler gives you speed
<kluk> don't discourage people from trying to write a compiler for picolisp :)
<Regenaxer> ok, not meaningfully possible
<kluk> it's funny that you go straight to speed, a compiler also gives you the ability to check things before you run...
<Regenaxer> There *is* one, the system itself
<Regenaxer> but not real full Pil
<beneroth> there is a reason why most lisp kicked out FEXPR's from their langugaes
<Regenaxer> right
<kluk> well I mean a strict native code compiler.
<Regenaxer> yes
<Regenaxer> but for another lang
<Regenaxer> semantically
<kluk> what do fexprs have to do with this?
<beneroth> one-time or just-in-time? We see just-in-time compiler just as another source of errors
<Regenaxer> A FEXPR takes all the code as an arg
<kluk> really, you have bad experiences with JITs?
<Regenaxer> at runtime
<beneroth> fexpr are functions which decide themselves what they do with the non-evaluated arguments
<kluk> right, isn't fexprs what picolisp has with quote?
<Regenaxer> not related
<beneroth> T
<Regenaxer> you can quote code
<Regenaxer> or functions
<beneroth> fexpr is about how the function is defined
<beneroth> functions in picolisp are lists
<Regenaxer> PicoLisp uses 'prg's very often
<Regenaxer> they run in the dynamic env
<kluk> well but I would say the effect is very similar, granted?
<Regenaxer> Similar to quote? Yes
<kluk> to fexpr
<kluk> ok
<Regenaxer> fexpr toi
<Regenaxer> too
<beneroth> imagine a (sub-turing, or turing-coomplete) DSL
<beneroth> fexpr's are nice to implement a DSL interpreter
<beneroth> now when it gets the DSL source/expressions as a list, as first parameter, then you could give the fexp'r a second parameter which tells the fexpr what do with the DLS source.. e.g. a preprocessor
<beneroth> not sure if that is a good example :/
<Regenaxer> good I think
<kluk> well you're doing a basic decoupling between specification and implementation there, right?
<beneroth> the second parameter could be a function to apply to the source code. or whatever else you like it to be.
<beneroth> yes, to achieve that, as an example use case.
<kluk> right, form
<Regenaxer> and also 'action', 'html', 'ask'
<kluk> beneroth right, so that scares me to death, to think of all the bugs that could be hiding in that approach
<Regenaxer> all FEXPs
<kluk> do you both not get tired ever of hunting down runtime bugs? so many FP people started by being burned out of just that.
<beneroth> kluk, it's easy manageable if you use a stratified design approach
<Regenaxer> no need to worry at all
<beneroth> we rarely ever have runtime bugs
<Regenaxer> it is all interactive
<Regenaxer> life
<Regenaxer> cause not static and separate
<beneroth> usually easy to debug, because you don't have to reproduce really, you can jump right into the process, connect a repl to it... unless you engineering yourself out of that somehow with bad coding :D
<Regenaxer> Just single-step and inspect the env
<beneroth> no mapping between executable and source code.. because it's both the exact same thing
<Regenaxer> yes
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<Regenaxer> everything is the "real" thing
<Regenaxer> not emulated by a debugger
<kluk> beneroth so is stratified design approach a design pattern that is defined somewhere?
<kluk> I'll catch up on the log
<kluk> So I remember reading from the picolisp website (or maybe it was a thread discussion from the mailing list) that segfaults are easily attainable by calling a symbol as a function which isn't a function. how do you debug that? there's no stack trace, right?
<kluk> that is one of the scariest parts for me
<kluk> feels like looking into an abyss
<beneroth> kluk, there is a turing award lecture about it ;-)
<Regenaxer> In practice not a problem
<kluk> I understand "everything is the real thing", I get that.
wineroots has joined #picolisp
<kluk> well you see I believe you because you are very smart, so when you say in practice it's not a problem, for you, I believe you.
<Regenaxer> And I understand that segfaults are scary
<beneroth> kluk, that is a beginner error. if you follow naming conventions you don't just call non-functions by accident. even then.. it crashes, what else do you want?
<kluk> I don't know that I could transfer that onto me.
<Regenaxer> but they are normal errors
<Regenaxer> sent by the OS or hardware
<kluk> but don't you lose the stack trace or am I wrong again?
<Regenaxer> yes, but you do a (traceAll) if you don't know where it happens
<Regenaxer> usually you know
<Regenaxer> It is the same as getting into an infinite loop
<Regenaxer> It can always happen
<kluk> right, so I would do a traceAll the second time around after the client had the error already, right?
<Regenaxer> yes
<Regenaxer> Other signals are caught
<Regenaxer> but in segfault the system is in an undefined state
<beneroth> so better quit and restart
<Regenaxer> So a debug break would be dangerous
<kluk> since you have the full state of the code as "the real thing" could you not catch that (sure, a penalty in performance would be paid) but then the benefit would be that you could catch it and return the state of the program right before crashing, just like Smalltalk can do too for the same reason that they also practice "everything is the real thing"
<kluk> does that make sense?
<beneroth> you could do that
<Regenaxer> As I said, catching would be trivial
<beneroth> we deem the penalty in performance not worth to do it in general
<kluk> I understand your point of view here, few things are better than what you do already with segfaults
<Regenaxer> like all other signals
<kluk> I know it would be trivial
<Regenaxer> term, interrupt etc
<kluk> but the penalty, right?
<Regenaxer> no penalty
<Regenaxer> read above
<Regenaxer> The interpreter is in an undefined state
<kluk> no, only after the fake call
<kluk> if you "if call will be fake, don't call" then no
<beneroth> in pure FP sense, it was wrong before the call :D
<kluk> then you pay a penalty
<kluk> right, lol
<beneroth> hihi
<Regenaxer> yes, but you cannot even check fake fcnction pointers before calling
<beneroth> don't do stupid things in the AST :D
<beneroth> in practice it is really no issue
<kluk> Regenaxer I think you can, can't you keep track of functions with some tag?
<kluk> well listen I am not trying to change anything, just curious about the design decisions
<beneroth> yes, by naming convention.
<beneroth> well
<beneroth> technically
<beneroth> the function body is a list
<kluk> since the "everything is real" like Smalltalk can be turned into all kinds of crazy useful stuff such as programs that ship their immediate state prior to catastrophic errors
<beneroth> and the function you call.. is a symbol which value points to the function body
<kluk> beneroth so it would suffice to have that shape?
<Regenaxer> kluk, I know what you mean
<kluk> it's the same deal
<kluk> I really like "everything is real" it's an awesome feature and so powerful
<beneroth> T
<beneroth> "if its a word in lowercase, then its a function I may call." that is the rule to prevent this mistake :)
<Regenaxer> So checking every primitive call would be a big penalty
<Regenaxer> beneroth, the point is not only named functions
<beneroth> T
<Regenaxer> ((+ car Offset) Arg)
<kluk> yeah, the solution to not pay that runtime penalty is types but... :P
<beneroth> T :D
<beneroth> it's radical
<Regenaxer> it is not worth the overhead
<beneroth> let it crash and let the programmer get the beating they deserve
<Regenaxer> T
<kluk> ouch
<Regenaxer> also (adr Expression)
<Regenaxer> can be any pointer
<beneroth> yes.. but..well...
<Regenaxer> (set (adr ...
<beneroth> I never needed to use that xD
<kluk> what do you say to the people who go to FP to avoid those errors? are they weak programmers? didn't get enough beatings and didn't toughen up, more or less?
<Regenaxer> yes, but (struct)
<beneroth> T
<beneroth> kluk,
<Regenaxer> on stack buffers
<beneroth> kluk, we should have more beatings on programmers to have better software. no computer can solve that, xD
<kluk> hahahah
<beneroth> joking
<kluk> of course lol
<Regenaxer> kluk, these are low-level errors, not the *real* errors one makes
<beneroth> that is what we try to say
<beneroth> the real errors are misunderstanding or lose definitions in the requirements
<kluk> okay but let's be fair here
<kluk> you saying that is like a pro-bowler telling me (who plays with the guards up) that the real difficulty in bowling is not even keeping the ball in the middle. Well yes I know that, but I can't keep the ball in the middle.
<kluk> so can we agree out of you both and I, you are the bigger brained and I am the one who is choosing the easier language? I want to be the one choosing the easier language.
<kluk> and I think I am.
<kluk> that is why it feels like cheating.
<Regenaxer> I make such stupid error too now and then, but they don't worry me
<kluk> okay! so I think maybe it could be that you just have a more resilient personality?
<kluk> and that you are not so much affected by constant errors that other people are (and you aren't), so you don't feel you need the guards other people do?
<Regenaxer> No, the real errors are much more often, and harder to solve
<kluk> for instance, maybe you are the opposite of a space-cadet. you are a laser-focused person that could build a ship in a bottle.
<Regenaxer> strategic errors
<kluk> I've never heard of strategic errors
<Regenaxer> opposite of tactical ;)
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<beneroth> one big thing is to keep in mind.. in picolisp, you try to keep the code very small. not having huge third party libraries you cannot trust. keep stuff simple, and keep stuff separate that doesn't need to be related.
<kluk> opposite of tactical, got it, lol
<beneroth> that lowers the attack surface a lot
<kluk> doesn't help, obviously, but the joke is a good pun
<beneroth> :D
<beneroth> well
<kluk> beneroth in FP we also try to keep the code very small, that is why I started talking about APL :)
<beneroth> maybe you can reword it into Fred Brooks essential complexity (the customers problem) vs. accidental complexity (issues coming from computers & software & implementation approach)
<Regenaxer> I mean the strategic programming decisions, in the application domain
<kluk> I could, I like that duality to explain things
<kluk> I think FP is minimum possible accidental complexity since it does not acknowledge the way the cpu works
<kluk> Regenaxer sure, in the application domain. that is what I mean with my bowling analogy. We all know the real problems are in the problem domain. but I can't keep the ball in the middle of the lane without the guards up. I can't keep the functions from crashing without types helping me.
<Regenaxer> Crashing is good, you see that it is wrong
<kluk> The point of FP is to build an algebra whose vocabulary is the vocabulary of the problem domain. This fits very well with domain driven design.
<Regenaxer> not the case in app domain
<kluk> Regenaxer I'd rather see that it is wrong before crashing
<kluk> since it's possible
<kluk> and I don't get to do the work
<kluk> the computer does it for me
<Regenaxer> bullshit
<kluk> you never answer why not rely more on the computer?
<Regenaxer> dream on
<kluk> why not let it do more of the thinking?
<Regenaxer> you are repeating yourself
<kluk> why the sudden rudeness?
<Regenaxer> Because you are theorising without practical use
<Regenaxer> Sorry, getting tired or going in circles
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> well I disagree, I think the rudeness is uncalled for
<Regenaxer> Either you are interested in Pil, then use it. Otherwise forget about it. I made PicoLisp to be useful for me
<kluk> thank you for your time.
<Regenaxer> I put in 45 years of programming to solve the problems *I* see in programming. Others have other problems, so I cannot be helpful.
<kluk> thank you, that really puts it into perspective for me.
<beneroth> crashing is good
<Regenaxer> OK, welcome kluk
<beneroth> the alternative to crashing is not flawless functioning.
<kluk> beneroth that's the dream/goal
<beneroth> the alternative to crashing is going on with flawed state and flawed data without noticing it before the mistakes spread all over the place
<kluk> beneroth yes I certainly understand that side of the issue
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<Regenaxer> I'm not a missionary, I can't explain well. The only important thing for me in PicoLisp is "being in control". What else is projected into it is not my beer, so everybody is free to do with it what she likes. I just can't bear people complaining about things from a theoretical perspective without knowing it practically.
<Regenaxer> Ref the Joshu Koan in the beginning of https://software-lab.de/doc/faq.html
<kluk> I can never understand koans, to me they all sound like the sound of a hand waving. But I understand what you are saying. You had an itch and you scratched it. You created a language that solves your problems and puts you in control. You did not design it to put others in control, just you. Anyone else with the same itches can come along for the ride. In that sense I think Picolisp betrays Lisp in that Lisp was
<kluk> supposed to give control to the programmer and not the language creator. At least that was what attracted me to it. I ended up staying for the FP while you saw other qualities that elude me. We're different people with different problems. If I had an enormous brain such that my only errors were in the problem domain I would also want a language with no checks that just gets out of the way of my big brain. But
<kluk> since I doubt myself more often than not I prefer to bowl with the guards up.
<kluk> your FAQ does not ask where the inspiration for the logo comes from!
<cess11> ml style fp is a tradeoff
<cess11> if you can fully know your problem domain it might be possible to type it up and then just live happily ever after extending the system with functions
<cess11> in practice this situation is very rare, because commonly we need to encode social organisations and judicial ontologies
<cess11> if you do finance, define your own network protocols and build applications on top, simulate physics, implement programming languages or do static analysis on machine code your ontologies are stable forever and ever
<kluk> cess11 I don't code the ontologies, that way I am never stuck in that problem
<beneroth> Regenaxer, oh you replaced the quote? :D
<beneroth> kluk, who is doing the ontologies then?
<cess11> keep the messages here instead of privs
<cess11> i've learned from experience
<kluk> it doesn't get done in the code. I make things as flat as possible
<kluk> "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. —- Alan Perlis"
<kluk> hence flat
<kluk> cess11 this notion that fp is for when you know the whole domain and there will be no changes, where did you pick that up from?
<cess11> if you read your system ontology from yaml or whatever that your customers define themselves you still need to set the limits and define parsers for it even if you don't write those files yourself
<kluk> cess11 that is true of procedural but not functional, most people confuse those
<cess11> i've learned from experience
<kluk> what fp language is your experience in?
<cess11> doesn't exactly matter which ml languages i have experience in
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<cess11> how do you explain that jane street prefers ocaml over haskell?
<kluk> eagerness?
<cess11> i think it's because it's more malleable and easier to implement problem domains with unknown unknowns in
<kluk> which specific feature(s) of OCaml make(s) it easier to implement problem domains with unknown unknowns in?
<cess11> the main one that sets it apart from haskell
<kluk> eagerness?
<cess11> you have control over the laziness in haskell
<kluk> but then there's little point in using it really
<kluk> lots of haskell idioms are only possible because of laziness
<kluk> having to eager here and there decharacterizes the language
<cess11> sure
<cess11> it's also a hassle to describe problem domains with many unknowns and unknown unknowns
<kluk> but why, where in OCamls it's not? tell me the difference, what is it? mutability?
<cess11> that translates into really complex type nests
<cess11> ocaml allows control over execution and has oop besides the ml style stuff
<kluk> in practice a tiny minority of OCamlers use the oop stuff
<kluk> I still don't understand what OCaml has that haskell doesn't that makes it "more malleable and easier to implement problem domains with unknown unknowns in"
<Regenaxer> beneroth, the Josho quote has been the same all the time :)
<beneroth> ah ok.
<cess11> i doubt it, i think it's common for certain use cases, like wrapping ffis and hacking together solutions where little is known and things can change fast so upfront theoretical investment means someone else gets the money
<beneroth> sounds to me like moving the domain knowledge from programming to configuration. which is often done in enterprise software. and which is bad. most powerful tool to configure a computer is a programming language.
<beneroth> so you end up programming again, you just call it differently but it's still pogramming.
<kluk> to me the "upfront theoretical investment" is precisely the building of the ontologies, whereas specifying what the program actually does doesn't feel very theoretical
<beneroth> I don't think you can meaningfully separate these two things. we agree about where the difficulty is.
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> beneroth here is something you can read, you can see OO objects being used in an FP setting for great good: https://speakerdeck.com/paf31/the-future-is-comonadic
<beneroth> now you argue my point? :D
<kluk> beneroth I always argue all sides against each other and let the winner reveal itself naturally
<kluk> beneroth but notice closely that the Comonad to be useful still needs to use a State monad inside. Essentially this means that the dream of "immutable, stateless OOP objects" is a fake idea without any foundation in Computer Science. You can clearly see, when using Comonads in FP, that they still need State to be useful, to act as the objects we think of when we say OOP.
<kluk> Precisely confirming out intuition, without State, you get an "OOP object" that can only be initialized and then cannot be changed, only a new one with the "changes" can be created. You can clearly see it.
<kluk> our intuition*
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<beneroth> I don't see a difference between state and data
<kluk> state you can change, like a box with something in it. data is the thing inside the box, that you override when you put new data in the box/state.
<kluk> it is elementary.
<beneroth> what is the difference if it's in a box or outside of the box?
<beneroth> can you not see into the box?
<kluk> if it's outside the box there is no concept of change. the behavior "change" only exists for box/state not for data.
<kluk> "State/Store is the simplest example of a comonadic UI, but it comes with no restrictions whatsoever, so it's also the least interesting. You can drop down to State/Store from any comonad because "Store is the mother of all comonads", but you lose all restrictions you enforced."
<kluk> meaning "state is the mother of OO objects and the most uninteresting and least restrictive object possible (i.e. a reference cell)"
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<beneroth> bbl. afk
kluk has quit [Read error: Connection reset by peer]
kluk has joined #picolisp
<kluk> beneroth re FP not offering usable parallelism technologies: https://futhark-lang.org/
Regenaxer has quit [Remote host closed the connection]