Including arrows et al

[digikar99]

arrows is another small utility library I love. Though, only five projects use it. Though, does anyone know why nesting -<> needs a full code-walker rather than just a tree traversal?

Edit:

does anyone know why nesting -<> needs a full code-walker rather than just a tree traversal?

The issue is reopened.

Edit 2020-11-23: There does not exist a defacto standard for threading macros in common lisp yet. See https://github.com/cl-library-docs/common-lisp-libraries/issues/3#issuecomment-732013019 for the elaboration.

Edit 2020-11-24: Relevant discussion includes

• comments until and including https://github.com/cl-library-docs/common-lisp-libraries/issues/3#issuecomment-730671646
• https://github.com/cl-library-docs/common-lisp-libraries/issues/3#issuecomment-732013019 and the comment following it
• https://github.com/cl-library-docs/common-lisp-libraries/issues/3#issuecomment-732437773 and https://github.com/cl-library-docs/common-lisp-libraries/issues/3#issuecomment-732455315

Edit 2020-12-10: Discussion continues over to https://github.com/cl-library-docs/common-lisp-libraries/issues/7

[Hexstream]

For whatever it's worth, I have nearly 15 years of Common Lisp experience and I think the entire concept of "arrows" should just die a horrible death. It's just one of those alluring but egregious newbie traps.

[digikar99]

I've had a number of people express their dislike for arrows (while a number of other people express their liking) - and I haven't been able to groak the POV for dislike or understand the reason.

[Hexstream]

From a Common Lisp expert's point of view, arrows just obfuscate the code while not providing any benefits whatsoever. It's like an arbitrary layer of encryption.

I am assuming the people who like arrows are newbies or people with bad taste or newbies with bad taste.

[digikar99]

I mean I find

(-<> object-of-interest
  (function-1 <> arg-2)
  (function-2 arg-1 <>)
  (function-3 arg1 arg2 <> arg4)
  (a-function-with-long-name <>))

to be cleaner than

(a-function-with-long-name (function-3 arg1
                                       arg2
                                       (function-2 arg-1
                                                   (function-1 object-of-interest
                                                               arg-2))            
                                       arg4))

I see this getting worse with more nesting. Is there any recommended style to structure such code?

In the first style, I can clearly see the flow: take this object, apply function-1 with these arguments, then function-2 with these arguments, function-3 with these arguments, and finally, pass that to a-function-with-long-name. The use case I find this useful is when all the functions are operating on essentially one conceptual/concrete object - say a list, string or CLOS-object.

[Hexstream]

The arrows stuff just looks like an arbitrary alternative way to write things, thereby reducing consistency and increasing cognitive load. And while editing code, you would find yourself juggling between the normal way to write things and the arrows way depending on the situation. It's just arbitrary overhead. The uniformity of syntax is one of the greatest things about Common Lisp...

I would do this:

(a-function-with-long-name
 (function-3 arg1
             arg2
             (function-2 arg-1
                         (function-1 object-of-interest
                                     arg-2))            
             arg4))

Where's the indentation problem, now? I just added a newline to your example...

I used to have constant, egregious problems with indentation depth, but that suddenly disappeared when I learned to properly factor code into variables, functions, etc. (Any remaining occasional mild annoyances related to indentation depth will be completely solved by my "upcoming" metabang-bind replacement...)

In the first style, I can clearly see the flow

If you can't immediately see the flow in the normal style, maybe that's because you keep wasting your time with arrows instead of mastering the normal style... and what will you do if you need to browse and edit a codebase that doesn't use the arbitrary arrows stuff?

[digikar99]

My own knowledge and usage of threading macros is limited to -> and -<>, and may be, it becomes more side-taking with additional macros.

I'm not... very convinced. The indentation is another kind of cognitive overhead - should I newline or exceed the 80/100 char limit?

Okay, let's see what my brain says when I go over to read this system's code itself:

    (write-string 
     (with-output-to-string (s)
       (let* ((sorted-symbols (-> (iter (for symbol in-package package-keyword
                                             external-only t)
                                        (collect symbol))
                                  (sort λ(string< (symbol-name -)
                                                  (symbol-name --)))))
...

write-string -> with-output-to-string -> let* -> sorted-symbols -> uh, what? Okay, first external symbols, and then sort them. The alternative way would be:

    (write-string 
     (with-output-to-string (s)
       (let* ((sorted-symbols (sort (iter (for symbol in-package package-keyword
                                               external-only t)
                                          (collect symbol))
                                    λ(string< (symbol-name -)
                                              (symbol-name --))))
...

This... does feel more natural. Okay, will agree on the part on syntax-consistency.

Okay, so, why do threading macros "feel" good, to some at least? Let's see another instance...

(-> package-keyword (find-package) (package-name))

Hmm... looks good. You take the package-keyword, then find-package, then package-name. Here's the code in context:

         (iter (initially
                (format s "~&# ~(~a~)~%" (-> package-keyword
                                             (find-package)
                                             (package-name)))
...

Uh? iter -> initially -> format-> eh?

So, here is what I feel is the case: arrow/threading macros look good in isolation. And if there were a data processing function, that is pretty much only doing function calls one after the other, their use might be more justified for that case. However, interspersing the two styles - "inside-out" and "linear" - just feels unnatural, and the reason seems to be - as you stated - cognitive switching involved in switching between the two modes; it seems to resemble multitasking, and we know, most humans aren't good at multitasking.

Now, I'd also love to see if this is true regardless of one's experience with arrow/threading macros. It does feel it should be; but I'd love to hear the opinion of someone who loves (and perhaps has more familiarity/experience) with threading macros.

[Hexstream]

Note that you can save quite a bit of indentation by inserting a newline after sorted-symbols.

I don't know that (-> package-keyword (find-package) (package-name)) looks good even in isolation, and I really have to stop and think to parse what it even means.

It's not like (package-name (find-package package-keyword)) was ever hard to read... and it's shorter!

Note how the normal evaluation order mentions the most important things first, closer to what value you want to get, a bit like a summary: I want to get the package-name of the package of the package-keyword. Whereas the arrows order reverses this and starts with the details: I want to get the package-keyword and then the package of that and then the package-name of that.

[digikar99]

IMO, it depends on what is more important.

(-> package-keyword (find-package) (package-name)) makes it clear that package-keyword is the argument. (Okay, this may not be the best use-case demonstrating the arrows though.) This says - you take the package-keyword, then find-package, then package-name. It makes the order of processing clear, which happens to be more important if you already know the return-type of the form. This isn't the best example, because the return types differ. But say, you are processing a sequence, where all the relevant operations take in sequences and emit sequences. The order of operations seems to become more important then.

For (package-name (find-package package-keyword)), one needs to "search" for the argument es-ecially once it gets deeper - is it package-name? Nope. find-package? Nope. package-keyword? Seems so. Yeah, this was the argument we were concerned about. but this makes it clear that the return-value of the form is the return-value of package-name. Perhaps, that can be mitigated to some extent by emacs packages like highlight-symbol, but you still need to know apriori that you are looking for the argument named package-keyword. The case using arrow macros makes it clear enough, for some of us at least. The order of operations is reversed: package-name? Okay, and before that? Oh, find-package.

So, arrows win for arguments/order-of-operations, perhaps in an isolated environment; usual syntax wins for return-values. But, like I said, I'll also wait for the perspective of an arrow-lover.

[Hexstream]

There is nothing that makes the arguments clearer than the normal syntax, since you just provide them directly with the function name in the function call. In arrows syntax, you separate the argument from its function call. And what if there are multiple arguments involved? I just don't understand the value.

Normal syntax always wins over arrows syntax. I don't understand your confusion... If you can't find anyone who has 10+ years of Common Lisp experience and loves arrows, that might mean something...

[digikar99]

The argument is clearer because it is at the beginning. You know what you are passing into the "machine".

One more addition: if the use of arrows is restricted to data processing - to calling of one function after another - then, this, essentially is composing (and currying) (it is, no?), me not knowing the overheads associated with the functional curry-and-compose approach. If the overheads are insignificant, then again, arrows are redundant.

[Hexstream]

Arrows provide no value and you would do best to avoid them like the plague, that's the takeaway. ;P

You might like to review how form evaluation works and stuff...

[Harleqin]

I can certainly understand that one is rather wary of arrows. Working in a larger Clojure codebase, I can say that I more often remove or reduce than introduce their usage.

There are even some extensions of this idea that lead to truly horrible messes, e. g. some “functional pipeline” constructs.

However, I do see some valid use cases. Some examples that come to mind:

• Multi-step sequence transformations where it's hard to name the intermediary steps (though you could maybe use SERIES for this, or (let* (($ (first form)) ($ (second one $))…)…))
• Guarded chaining of accessors using some-> (though you could probably use alexandria's (when-let* (($ (first acc)) ($ (second acc $))…)…))
• Conditional application of multiple transformations using cond->.

Let's take one (notorious) example of that last one:

(cond-> nil
  ((zerop (mod n 3)) (strcat "Fizz"))
  ((zerop (mod n 5)) (strcat "Buzz"))
  (t (or (strcat n))))

What like about this is that it gets rid of the thing that annoys me most about the FizzBuzz task: the repetition of the divisibility tests. But again, there are alternatives:

(let* (($ (when (zerop (mod n 3))
           "Fizz"))
       ($ (if (zerop (mod n 5))
              (strcat $ "Buzz")
              $)))
  (or $ (strcat n)))

In summary, the cases where I see arrows as useful are where you can get to a point-free style when the points have no point, i. e. they have no useful naming: possible names being either overly general (data, result) or overly specific (maybe-fizz, maybe-fizz-ior-buzz). I find naming things $ as above also quite ugly.

So yeah, it's a narrow call, and especially newbies will more often err on the side of overuse, just as with recursion, currying, loop, higher order functions, do, continuations, macros, etc., but I think that outright dismissal is also not warranted. Maybe it is unhealthy top-down-reading addiction against unhealthy inside-out-reading addiction. I think you have to look at it case by case, and not be led astray—often “fewer moving parts” beats superficial consistency.

Anyway, I'm completely fine either way, and I do not think that arrows are essential. I think that it is part of the job of the curator to include only things that they are convinced of. (I, for one, would never recommend or mention things that use Python or shudder YAML. :stuck_out_tongue_winking_eye:)

[Hexstream]

If arrows only provide some small value some of the time (and even this I doubt), then I don't think they justify all the overhead (especially cognitive overhead) associated with their use (such as learning to use them and importing them) and especially deciding when to use them or not and how and why.

This opens a whole new universe of stylistic choices which will inevitably lead to inconsistencies, and potentially the creation of one or more style guides in an attempt to reduce the inconsistencies.

I'd really just throw out that whole universe.

I think it's telling that pretty much only newbies ever get excited about arrows, and it is them I trust the least to make the best stylistic choices.

In short, as a matter of "policy", I think it's best to tell everyone to never use arrows.

[phoe]

I vote for including arrows. They allow separation of computation into logical steps the same way local variable bindings do. Speaking from this context, arrow macros act as anonymous variable bindings. For instance:

(-<> object-of-interest
  (function-1 <> arg-2)
  (function-2 arg-1 <>)
  (function-3 arg1 arg2 <> arg4)
  (a-function-with-long-name <>))

The above is equivalent to:

(let* ((temp1 object-of-interest)
       (temp2 (function-1 temp1 arg-2))
       (temp3 (function-2 arg-1 temp2))
       (temp4 (function-3 arg1 arg2 temp3 arg4)))
  (a-function-with-long-name temp4))

Of course, code that uses the let or let* bindings usually adds more meaningful names for the variables (which also increases debuggability, because locals with meaningful names are then available for view in the debugger).

So, from another Common Lisp expert's point of view, I find it very hard to justify the example of

(a-function-with-long-name
 (function-3 arg1
             arg2
             (function-2 arg-1
                         (function-1 object-of-interest
                                     arg-2))            
             arg4))

because the indentation is all over the place, even if we apply newlines, and because locals are not preserved and therefore hamper the usefulness of the Lisp debugger.

as a matter of "policy"

There's no policy here, just personal preferences. If a non-trivial population of Lisp programmers find arrows useful (which is the case in reality), I see no reason for denying them the documentation and description of a language construct that they find useful, even if I do not use that construct myself. In the worst case, I can macroexpand or macrostep it and file usability bugs if the macroexpansion in question is not readable enough to me. For instance, I can read the resulting expansion, e.g. the expansion of

(-<> 42
  (cons 1 <>)
  (list <> :foo <>)
  (print <>))

which is

(PRINT
 (LET ((#:R656 (CONS 1 42)))
   (LIST #:R656 :FOO #:R656)))

which should be understandable to every Lisp programmer. More complex arrow macro expressions might need some work, though, because e.g. the below example does not expand well. (Edit: see https://github.com/Harleqin/arrows/issues/2)

(-<> 42
  (list <> <> <>)
  (cons 1 <>)
  (cons <> 2)
  (list <> :foo <>)
  (print <>))

---

I'd just recommend to avoid the cl-arrows system and instead recommend arrows or arrow-macros because of the former's licensing issue; see https://github.com/nightfly19/cl-arrows/issues/5

[Hexstream]

I vote for including arrows.

So you have chosen death...

They allow separation of computation into logical steps the same way local variable bindings do. Speaking from this context, arrow macros act as anonymous variable bindings.

The default syntax already does.

which also increases debuggability, because locals with meaningful names are then available for view in the debugger [...] and because locals are not preserved and therefore hamper the usefulness of the Lisp debugger.

This sounds like an imaginary use-case, or at least it's not one I've come across in nearly 15 years of Common Lisp. Honestly, I spend a very insignificant amount of time in the debugger (perhaps because it is already so damn informative), so I don't really see any reason to write code in a way that would make the debugger more useful.

That said, thanks to proper decomposition into functions, nearly all my functions are trivial, which inherently makes debugging easier. There is no point in preserving locals in a trivial function, and most of the would-be locals are then function arguments, which the debugger tends to preserve.

because the indentation is all over the place

I have no idea what the indentation "being all over the place" even means, especially in a pejorative sense.

In fact, the different levels of indentation make it easier to separate and identify the various logical parts of the expression. I don't understand how you can possibly not notice this.

There's no policy here, just personal preferences.

And good taste and horrible taste.

If a non-trivial population of Lisp programmers find arrows useful (which is the case in reality)

There is also a "non-trivial population of Lisp programmers" who hate s-expressions, who also almost all happen to be newbies. Weird coincidence, eh?

In the worst case, I can macroexpand or macrostep it and file usability bugs if the macroexpansion in question is not readable enough to me. For instance, I can read the resulting expansion, [...] which should be understandable to every Lisp programmer.

There is something DEEPLY WRONG with a macro if the expansion might be seen as more readable than the macro call.

[phoe]

So you have chosen death...

By whom? You? I read this as some kind of poorly made death threat, even if this is a Lord of the Rings quote. Poorly made, because you must know Saruman's fate if you've decided to quote him.

The default syntax already does.

Yes, let and let* serve exactly this purpose, as I described above. Arrows are just shortcuts for anonymous variables and some people find them handy.

This sounds like an imaginary use-case, or at least it's not one I've come across in nearly 15 years of Common Lisp. Honestly, I spend a very insignificant amount of time in the debugger (...)

Yes, you must not have used the locals feature of the debugger many times during your 15 years of Common Lisp. You must be aware of it by now though; the debugger will show you the values of all local variables instead of optimizing them away without a trace. All that's required is code compiled with high debug settings, and the values must be locally bound.

Let's consider this synthetic test case:

(defun foo (x) (1+ x))
(defun bar (x) (1+ x))
(defun baz (x) (1+ x))
(defun quux (x) (1+ x))
(defun fred (x) (cerror "Continue." "Oops.") (1+ x))
(defun frank (x) (1+ x))
(defun zoop (x) (1+ x))

And let us consider the difference between locals in these two debugger invocations on high debug/safety settings.

CL-USER> (zoop (frank (fred (quux (baz (bar (foo 42)))))))

Oops.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [CONTINUE] Continue.
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {10015C0103}>)

Backtrace:
  0: (FRED 46)
      Locals:
        X = 46
  1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FRED (QUUX (BAZ #))) #<NULL-LEXENV>)
  2: ...

CL-USER> (let* ((temp1 (foo 42))
                (temp2 (bar temp1))
                (temp3 (baz temp2))
                (temp4 (quux temp3))
                (temp5 (fred temp4))
                (temp6 (frank temp5)))
           (zoop temp6))

Oops.
   [Condition of type SIMPLE-ERROR]

Restarts:
 0: [CONTINUE] Continue.
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {10015C0103}>)

Backtrace:
  0: (FRED 46)
      Locals:
        X = 46
  1: ((LAMBDA ()))
      Locals:
        TEMP1 = 43 ; !!!
        TEMP2 = 44 ; !!!
        TEMP3 = 45 ; !!!
        TEMP4 = 46 ; !!!
  2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET* ((TEMP1 #) (TEMP2 #) (TEMP3 #) (TEMP4 #) (TEMP5 #) (TEMP6 #)) (ZOOP TEMP6)) #<NULL-LEXENV>)
  3: ...

Suddenly, we have all the intermediate values of computation steps smiling back at us for no cost whatsoever. All that was required was simply using let* to bind the temporary variables. We can use the inspector as we wish on these or copy them to the REPL for further processing, both using standard Slime/Sly facilities.

This test case is synthetic, but you are free to replace these function calls with any deeply nested function call. There are many of them used in practice.

I don't really see any reason to write code in a way that would make the debugger more useful.

That's only your style of doing Lisp. Other people have it differently, e.g. me. I would like it if you properly acknowledged that fact and not stopped calling something objectively bad because it is subjectively bad for you.

That said, thanks to proper decomposition into functions, nearly all my functions are trivial, which inherently makes debugging easier. There is no point in preserving locals in a trivial function, and most of the would-be locals are then function arguments, which the debugger tends to preserve.

(I've removed formatting to make reading easier.) Sure, but again, not everyone writes hundreds of tiny functions, and it is not always feasible either when the function complexity rises. When someone actually needs to debug a live stack trace that spans multiple functions, some of them sizeable (25+ lines with multiple locals), especially in an impure context where arguments may get mutated, it's beneficial for them to be able to see the values of temporary variables on the stack (which might hold information about what and how got mutated) in order to figure out what went wrong.

I have seen such functions commonly in real-world Lisp applications, e.g. SBCL, CCL, ECL, Mezzano, JSCL, ACL2, pgloader, Postmodern, Hunchentoot, Swank/Slynk. If these applications contain functions of such size and number of locals, then it is either because their authors were unable to decompose them further, which I cannot assume because that would imply incompetence of massive scale of all these software authors and maintainers, or because it is either impossible or unfeasible to decompose them, which in turn then proves my point that it is worthwhile to produce software that helps with debugging those functions.

I have no idea what the indentation "being all over the place" even means, especially in a pejorative sense.

It means this:

(
#(
#############
#############(
#########################(
#####################################   ))
#############   )))

As opposed to this:

(
##(   )
##(   )
##(   )
##(   ))

(I have replaced spaces with hashes and removed list bodies for better visibility.)

The latter approach 1) saves horizontal space and 2) cleanly separates the individual computational steps on new lines. The former has neither of those advantages.

In fact, the different levels of indentation make it easier to separate and identify the various logical parts of the expression. I don't understand how you can possibly not notice this.

The different levels of indentation, especially being arbitrarily dependent on the lengths of function names, make it harder to understand which value is piped into which place. It is hard to understand a function call whose arguments span multiple lines, where one of the argument forms takes 4+ lines, contains its own multi-linearguments, and is then followed by other argument forms that follow the same scheme.

I can understand how you can possibly not notice this (since this is mostly a matter of personal preference), but I am not pushing my preferences onto you by calling my taste "good" and your taste "horrible", like you do in your next comment:

And good taste and horrible taste.

Is basic civility too much to ask of you? If that is too much, then I do not think you have much room left to wonder why people do not want to see you or your content on Lisp Discord, Lisp subreddit, Common Lisp subreddit, SBCL bugtracker, lobste.rs, Derpibooru, and wherever else you were banned from by explicitly and repeatedly not being civil.

There is also a "non-trivial population of Lisp programmers" who hate s-expressions, who also almost all happen to be newbies. Weird coincidence, eh?

You suddenly start talking about newbies who hate S-expressions, and then act as if your claim about newbies who hate S-expressions also applies to arrow macros. This is a textbook straw man argument. You did nothing to refute my original point, which is that a non-trivial population of Lisp programmers (who also happen not to be newbies) find arrows useful.

There is something deeply wrong with a macro if the expansion might be seen as more readable than the macro call.

(I've removed formatting and caps to make reading easier.) You must have completely misunderstood what I meant by my earlier comment.

Again, you disliking arrow macros is your personal taste. Other people have it differently, and this does not mean that they deserve to have their tastes questioned or called horrible. Pushing your personal tastes onto other people in an aggressive way and deprecating their own differing tastes is, by definition, bigotry.

Again, since you are likely aware of the definitions I've linked above, I truly wonder whence comes your annoyance when different parts of the Internet decide to cut ties with you as a result of your behavior. I guess it simply must be more convenient for you to instead rage about it all on Twitter month after month, blame it all on an imaginary Common Lisp Mafia that you summon whenever you need to cover up your own behavior, invoke your own definition of "ethics" on people who are "unethical" when they decide not to put up with your antics, or perhaps conjure yet another "policy" that serves only to further your own personal agenda rather than serve other people. Oh, anyway, have you removed me from https://common-lispers.hexstreamsoft.com/ yet, as I've asked?

[Hexstream]

By whom? You? I read this as some kind of poorly made death threat, even if this is a Lord of the Rings quote. Poorly made, because you must know Saruman's fate if you've decided to quote him.

It's just a meme. Chill out.

Yes, let and let* serve exactly this purpose, as I described above. Arrows are just shortcuts for anonymous variables and some people find them handy.

Actually, it's a bit more profound than that. I've often talked about reducing the scope of bindings. Well, the ultimate form of binding scope reduction is just replacing the binding and its reference by the original expression.

and it is not always feasible either when the function complexity rises.

That doesn't seem like a safe assumption to me. I'm certainly eager to see how well my coding style scales to larger projects. I suspect it will do so brilliantly, and that I won't suddenly find myself forced to write grotesquely huge functions.

I have seen such functions commonly in real-world Lisp applications, e.g. SBCL, CCL, ECL, Mezzano, JSCL, ACL2, pgloader, Postmodern, Hunchentoot, Swank/Slynk.

Admittedly, I don't really read third-party code. Frankly, I can't really stand to read any coding style but my own. I do think my coding style is already pretty close to optimal given the available infrastructure, and I'm looking forward to building the appropriate infrastructure to get even closer to the platonic ideal.

which in turn then proves my point

I find your standards of proof wanting.

It means this:

That does look ugly, but is fortunately almost completely unrelated to the original code.

The different levels of indentation, especially being arbitrarily dependent on the lengths of function names, make it harder to understand which value is piped into which place. It is hard to understand a function call whose arguments span multiple lines, where one of the argument forms takes 4+ lines, contains its own multi-linearguments, and is then followed by other argument forms that follow the same scheme.

To me that sounds about the same as if you told me that typing on a keyboard without looking at it is inherently hard. Rationalizing a process as being hard does not make it hard.

Is basic civility too much to ask of you? If that is too much, then I do not think you have much room left to wonder why people do not want to see you or your content on Lisp Discord, Lisp subreddit, Common Lisp subreddit, SBCL bugtracker, lobste.rs, Derpibooru, and wherever else you were banned from by explicitly and repeatedly not being civil. [...] Again, since you are likely aware of the definitions I've linked above, I truly wonder whence comes your annoyance when different parts of the Internet decide to cut ties with you as a result of your behavior.

We may have wildly diverging concepts of "basic civility".

You are the ultimate useful idiot. There are very few acts more heinous than blaming the victim. I was banned from Lisp Discord mostly because mfiano is insane, lobste.rs entirely because pushcx is insane, and Derpibooru mostly because TheSmilingPony is insane. The reality is, I do tend to quickly get banned from shitty corrupt places when the sociopaths/psychopaths in charge immediately detect, quite correctly, that I'm inevitably going to fuck up their cushy little cult if they don't act fast.

Lisp subreddit, Common Lisp subreddit, SBCL bugtracker

I am not even banned from those places, as far as I know, and I don't see why I would be. Did you just make that up? Or did you just unquestioningly gobble up mfiano's shitty lies again?

a non-trivial population of Lisp programmers (who also happen not to be newbies) find arrows useful

Who? Could you name me 10 Common Lispers who know WTF they are doing AND enjoy arrows?

(I've removed formatting and caps to make reading easier.)

This is veering into malicious misquotation territory, which is surprising given your usual healthy obsession with accuracy.

I guess it simply must be more convenient for you to instead rage about it all on Twitter month after month, blame it all on an imaginary Common Lisp Mafia that you summon whenever you need to cover up your own behavior, invoke your own definition of "ethics" on people who are "unethical" when they decide not to put up with your antics, or perhaps conjure yet another "policy" that serves only to further your own personal agenda rather than serve other people. Oh, anyway, have you removed me from https://common-lispers.hexstreamsoft.com/ yet, as I've asked?

I do value ethics far higher than anybody's mere comfort, including mine.

Oh, anyway, have you removed me from https://common-lispers.hexstreamsoft.com/ yet, as I've asked?

Now "FOUR", but you get the point.

[lonjil]

I was banned from Lisp Discord mostly because mfiano is insane,

Actually, you were banned for repeatedly violating the rules and the fact that you pissed off approximately every single active member.

[Hexstream]

Actually, you were banned for repeatedly violating the rules

Completely false, in fact the first time I got banned for no reason whatsoever (for one day as I recall, as I learned several months later), I basically got banned for getting yelled at by some mentally ill person (WHEN I WASN'T EVEN THERE) when you magically decided not to apply the rules for that specific person because you felt it was convenient.

The second time I got banned was mostly about mfiano being in deep shit after he repeatedly abused his power and I was completely exposing him, and Seren enabled him pretty much 100% of the way, and still is to this day.

and the fact that you pissed off approximately every single active member.

I can probably believe that, although we were probably like 3 or 4 active members at that time, as I recall. btw it turns out I'm OCPD, so sorry about that I guess.

---

edit: Sorry, I misremembered, it was even worse than that.

You unilaterally banned me on the weight of (alleged) extensive secret evidence, bro! (The first time around.)

It of course goes without saying that if I had broken any rules, which I didn't, then you wouldn't have needed to rely on said secret evidence.

[lonjil]

When you were banned, I told you why, and it was over something you had access to at the time, and probably still do, that being DMs you had been sending to other members of the Discord. Then you invented some stuff about "secret evidence" (I have literally no idea where you got this) and decided to attack me publicly. Also, please don't blame your OCPD and say that you were faultless at the same time. If you want to blame OCPD for being as asshat, so be it, but being an asshat is precisely what got you banned.

[Hexstream]

When you were banned, I told you why, and it was over something you had access to at the time, and probably still do, that being DMs you had been sending to other members of the Discord.

It was fake shit then and it's still fake shit now. Feel free to dig whatever fake shit it was, but it won't make it real. If there had been some actual concern, you would have used an actual real ban reason. There wasn't, so you didn't.

Then you invented some stuff about "secret evidence" (I have literally no idea where you got this)

At some point right before the ban, you started "warning" me about supposedly lots of secret people being secretly very pissed off about me for secret reasons, and you somehow thought that was compelling reason for me to change my behavior, which I found deeply laughable. My understanding was that me not heeding that secret evidence was a primary "justification" (HAH HAH HAH HAH!!!) for that first ban.

Also, please don't blame your OCPD and say that you were faultless at the same time. If you want to blame OCPD for being as asshat, so be it, but being an asshat is precisely what got you banned.

We'll have to see your definition of "asshat" sometime, but I was actually damn near faultless, quite unlike my detractors.

[digikar99]

Tldr; with the current state of affairs, there is no defacto threading macro library. I don't intend to add one here until there emerges a defacto one and/or the differences are ironed out.

And to iron out those differences, one would need better guidelines / a write-up highlighting intended/good and unintended/bad use cases of threading macros, and a community willing to follow and propagate them. (Edit-2: I'd welcome such a write-up; but I lack the knowledge or the time required to gain that knowledge to do the write-up.)

---

Over a discussion with @phoe, we noted a few incompatibilities between the different threading macro libraries (there might be more!):

1. For some, the result depends on whether the diamonds appear once or more than once

(defmacro test-arrows-once (diamond-arrow-variant placeholder)
  `(let ((i 0))
     (,diamond-arrow-variant (incf i)
                     (or t ,placeholder))
     i))

(defmacro test-arrows-twice (diamond-arrow-variant placeholder)
  `(let ((i 0))
     (,diamond-arrow-variant (incf i)
                     (or t ,placeholder ,placeholder))
     i))

(test-arrows-once  arrows:-<> <>) ;=> 0
(test-arrows-twice arrows:-<> <>) ;=> 1

(test-arrows-once  cl-arrows:-<> <>) ;=> 0
(test-arrows-twice cl-arrows:-<> <>) ;=> 1

(test-arrows-once  arrow-macros:-<> arrow-macros:<>) ;=> 1
(test-arrows-twice arrow-macros:-<> arrow-macros:<>) ;=> 1

(test-arrows-once  binding-arrows:-<> <>) ;=> 1
(test-arrows-twice binding-arrows:-<> <>) ;=> 1

2. arrow-macros allow for nesting diamonds, others don't

(arrows:-<> 5 (list (list <>)))                    ;=> error
(cl-arrows:-<> 5 (list (list <>)))                 ;=> error
(arrow-macros:-<> 5 (list (list arrow-macros:<>))) ;=> ((5))
(binding-arrows:-<> 5 (list (list <>)))            ;=> error

To be fair, arrows and cl-arrows work compatibly in these use cases; however, cl-arrows lacks a license; but there's cl-arrowz - :joy: - that's intended to be a drop-in replacement of cl-arrows with a license. However, as of October 2020 quicklisp dist

CL-USER> (mapcar #'ql:system-apropos '("arrows" "cl-arrows" "cl-arrowz" "arrow-macros" "binding-arrows"))
#<SYSTEM arrows / arrows-20181018-git / quicklisp 2020-10-16>
#<SYSTEM arrows/test / arrows-20181018-git / quicklisp 2020-10-16>
#<SYSTEM cl-arrows / cl-arrows-20160318-git / quicklisp 2020-10-16>
#<SYSTEM cl-arrows-test / cl-arrows-20160318-git / quicklisp 2020-10-16>
#<SYSTEM cl-arrows / cl-arrows-20160318-git / quicklisp 2020-10-16>
#<SYSTEM cl-arrows-test / cl-arrows-20160318-git / quicklisp 2020-10-16>
#<SYSTEM arrow-macros / arrow-macros-20160929-git / quicklisp 2020-10-16>
#<SYSTEM arrow-macros-test / arrow-macros-20160929-git / quicklisp 2020-10-16>
(NIL NIL NIL NIL)
CL-USER> (mapcar #'ql:who-depends-on '("arrows" "cl-arrows" "cl-arrowz" "arrow-macros" "binding-arrows"))
(("arrows/test")
 ("cl-arrows-test" "cl-catmull-rom-spline/test" "generic-cl"
  "generic-cl.util/test" "sanity-clause" "static-dispatch")
 NIL
 ("arrow-macros-test" "cl-bson" "cl-fix" "clj" "oclcl-test"
  "software-evolution-library/components/serapi-io")
 NIL)

My understanding of this: arrows are not a defacto thing in common lisp in 2020, use at your own risk! Stick to a single variant, unless you know what you are doing (the mention of the need for a write-up above).

EDIT: Minor error; thanks to phoe for pointing out!

[phoe]

FYI, I've requested cl-arrows to be removed from Quicklisp due to the licensing issue.

generic-cl and static-dispatch no longer use it on their master branches and have switched to arrows.

I've submitted issues to cl-catmull-rom-spline and sanity-clause to note the licensing issue with cl-arrows.

[Hexstream]

@lonjil

When you were banned, I told you why, and it was over something you had access to at the time, and probably still do, that being DMs you had been sending to other members of the Discord. Then you invented some stuff about "secret evidence" (I have literally no idea where you got this)

You are being incoherent. Your first sentence pretty much directly says that I was banned due to secret evidence (since we haven't seen a single one of those alleged infringing DMs, and you said I "repeatedly violated the rules" so there ought to be many), and then in your second sentence you say that I invented some stuff about "secret evidence"... Well guess what? You did. You invented the secret evidence, and as far as I can tell, that is the official reason for my ban, to the extent that there might be one.

[phoe]

@Hexstream Apologies for the delay, this post and its requirements needed some time to get written.

It's just a meme. Chill out.

A very inappropriate meme. "So you have chosen death" came from you, a person who continuously offends people in vulgar ways; given that vulgarities like that are very close to threats on the scale of aggressive emotional reactions, it may cause people to feel threatened by you.

I've often talked about reducing the scope of bindings. Well, the ultimate form of binding scope reduction is just replacing the binding and its reference by the original expression.

Reducing the scope of bindings, depending on its extent, has both a positive effect on readability (when lexical variables are defined as close to their uses as necessary) and an immediate negative effect on readability (when lexical variables disappear altogether by being merged into inline code). I have pointed this out above.

That doesn't seem like a safe assumption to me.

Why exactly? I would like you to elaborate, since at this point you have nothing other than a simple opinional "nah" to contribute to this part of the discussion, and my point has no other points to clash against and stands unrefuted.

I'm certainly eager to see how well my coding style scales to larger projects.

What? You must have already worked on larger projects enough to be able to call yourself a Common Lisp expert. Otherwise, you simply have no experience that is required for proper expertise. So either you have actually gone and worked on projects of non-trivial size, or you are missing one of the foundations for any claims of personal expertise.

I suspect (...) that I won't suddenly find myself forced to write grotesquely huge functions.

Sorry, but if we use your above definition of "grotesquely huge functions", you already write them. Some examples are here, here, here, here, here, here, here, and here.

Each of the above examples can benefit from functional decomposition and factoring. I will take the last example and analyze it via a code review:

• having a single big function like that makes it very hard to test all the edge cases. Therefore, it should be split into pieces in order to be testable, even if only in the REPL;
• the macro has two massive branches based on the value of cachedp-place. Therefore it makes sense to split this macro into two independently testable subfunctions that take care of a single branch each;
• testvar, init-form-function, and evaluate-init-form are declared at the top, whereas they are only used in the values form at the end. Therefore they should have been declared lower in order to greatly reduce variable scope;
• do-caching is similarly defined in the middle where it should have been defined at the bottom, before generating the resulting writer and reader functions;
• correct-order has a complex expression as its initialization form that should be extracted into a separate function, according to the single responsibility principle. However, testing shows that its value can always be #'identity and this code block can be removed altogether;
• the return values are nontrivial and greatly expand the body of the values form, so exporting them into separate variable bindings or even their own functions makes sense;
• the pair of multiple-value-bind introduces ten new lexical variables, which becomes highly unwieldy in the main function in addition to the other variables. The solution is to gather setf expansions into lists via multiple-value-list and have subfunctions destructure them on demand;
• the error on new-cachedp-sp in the uncached code branch may be signaled much sooner, preferably at the same level where "cache-place must involve only one value" is handled;
• the signaled errors are of type simple-error which is unspecific; I suggest to change them into a more specific condition type, such as program-error that is suitable for errors related to invalid syntax. All three instances of error-calling in cachef are related to invalid syntax, so I think that this condition type is appropriate;
• new-cachedp-sp seems like a typo; new-cachedp-p maybe?

I have refactored this function in a way that follows all of the above and submitted a PR at https://github.com/Hexstream/place-utils/pull/2. I was able to considerably improve cachef this way; the rest of your code can be similarly improved.

An important code aspect that I would expect from code produced by any expert programmer, Common Lisp or not, is verification, since it is the main means of building trust in any codebase, no matter its size. When it comes to testware for checkf, your tests for it aren't really tests, but rather merely "featured examples". I think that such an amount of tests is not enough, given the internal complexity of cachef, as demonstrated above.

Judging by the amount of tests that were necessary to cover all argument combinations in my PR, it seems that it will massively improve the test quality of cachef and likely make it the most thoroughly tested macro across all of your available utilities. (It is noteworthy that this is only because an external contributor wrote these tests in your stead.)

The test cases I have added (62 assertions for API and 20 internal assertions in total for cachef only) are much more exhaustive than the 3 assertions from before. I consider the new tests to be production-ready.

All in all, I think all of these three points contribute negatively to the overall quality of your testware and, when considered together with the poor readability and testability of your code, greatly undermine the image of a Common Lisp expert that you attempt to create.

Additionally, you seem to use assertions from the test framework of your choice incorrectly, which is unexpected of a Common Lisp expert. Calling (asdf:test-system :place-utils) results in five kilobytes of noise being produced to standard output, from just 16 total test assertions. Here is an example single line from the output of the above command:

  0.000 ✔   (is equal '((:initial-assets (:paintings :collection) 20000 () :random-stuff 400) () 0 (:nothing-valuable () 0)) (multiple-value-list (flet ((bulkf-steal (sum-function steal-function initial-assets &rest target-assets) (let (stolen leftovers) (mapc (lambda (assets) (multiple-value-bind (steal leftover) (funcall steal-function assets) (push steal stolen) (push leftover leftovers))) target-assets) (values-list (cons (apply sum-function (cons initial-assets (nreverse stolen))) (nreverse leftovers)))))) (macrolet ((stealf (sum-function steal-function hideout &rest targets) (quasiquote (bulkf #'bulkf-steal :pass ,sum-function ,steal-function :access ,hideout ,@targets)))) (let ((cave :initial-assets) (museum '(:paintings :collection)) (house 20000) (triplex (list :nothing-valuable :random-stuff 400))) (stealf #'list (lambda (assets) (if (eq assets :nothing-valuable) (values () assets) (values assets (if (numberp assets) 0 ())))) cave museum house (first triplex) (second triplex) (third triplex)) (values cave museum house triplex))))))

I fixed the old cachef tests to not suffer from this fault; the new tests I've added do not suffer from it either.

I will not spend further time on improving your testware functions; I hope that this small demonstration is enough to show that definite improvement in your test strategy is possible, feasible, and required in order to give foundation to your idea of calling yourself a Common Lisp expert in the meritorious manner.

Admittedly, I don't really read third-party code.

Same as further above. You must have already read a large amount of code written by other people to be able to call yourself a Common Lisp expert. Otherwise, you simply have no broad context that is required for proper expertise in the topic, and you will have problems reading Common Lisp code that is not of your own making (which means: almost all Common Lisp code available, and therefore Common Lisp code in general).

Frankly, I can't really stand to read any coding style but my own.

Yes, this is evident, but additionally you seem to leave no place for any kind of variance in other people's preferences about syntax style.

I find your standards of proof wanting.

Sure, please elaborate. Anything in particular that my proof is missing? Otherwise, my point stands.

That does look ugly, but is fortunately almost completely unrelated to the original code.

This is the original code snippet that you posted, except with indentation highlighted with hashes. Let me demonstrate again, this time without removing symbols.

(a-function-with-long-name
#(function-3 arg1
#############arg2
#############(function-2 arg-1
#########################(function-1 object-of-interest
#####################################arg-2))            
#############arg4))

To me that sounds about the same as if you told me that typing on a keyboard without looking at it is inherently hard. Rationalizing a process as being hard does not make it hard.

Typing on a keyboard is a process that takes some time to get used to, just like reading Lisp code, but it does not mean that you should remove the keycap bumps from F and J keys that make touch typing easier. To invert your argument, rationalizing a process as being easy does not make it easy.

We may have wildly diverging concepts of "basic civility".

Yes, we do. Repeatedly offending people seems to be a part of your concept of "basic civility" and not a part of mine.

You are the ultimate useful idiot.

Sorry, but I strongly disagree with this statement. I am fully aware of the consequences you have on the Common Lisp community and I must honestly say that the total of them all is majorly negative. This is due to your vulgarity, aggression, egocentrism, and extreme insociability, which all negatively affect the Common Lisp community. This community, just like all other communities, is made of people, and people are in general easily harmed by all of the aforementioned qualities of yours, and therefore react to protect themselves from them by means of making it impossible for you to influence them. Hence the bans that you received.

Also, you have just called me an "idiot" yet another time, which only contributes to the harm that you apply to the Common Lisp community members.

There are very few acts more heinous than blaming the victim.

You always play the victim card by completely ignoring how obnoxious your behavior is and how much it affects other people around you. No, the Lisp community as a whole is a victim of your repeated and continuous aggression, vulgarity, and contentiousness.

The reality is, I do tend to quickly get banned from shitty corrupt places when the sociopaths/psychopaths in charge immediately detect, quite correctly, that I'm inevitably going to fuck up their cushy little cult if they don't act fast.

The reality is, your aggressive and provocative behavior gets you banned from all sorts of places that refuse to put up with you and then proclaim people insane.

I am not even banned from those places, as far as I know

Please read my posts once more. I did not say that you were banned from these places; I said that people do not want to see you or your content there. To which extent they do not want to see you there, and whether that extent includes banning - this varies, but is directly dependent on the amount of aggression and entitlement you have demonstrated in a given place.

and I don't see why I would be.

This is exactly the axis of your problem. The moment you see this, you will understand the real reason for the bans that you received so far.

Or did you just unquestioningly gobble up mfiano's shitty lies again?

You must be under the false impression that @mfiano even cares enough about you nowadays to produce "shitty lies" about you that are then somehow fed to me, and that I then consume them in any way. Both of these statements are false.

Who? Could you name me 10 Common Lispers who know WTF they are doing AND enjoy arrows?

Given that you have already completely ignored the syntactical needs of three people who have contributed meaningful matter to this issue (me, @Harleqin, and @digikar99), I do not think that typing any further names will change anything in the matter.

This is veering into malicious misquotation territory, which is surprising given your usual healthy obsession with accuracy.

I find it much easier to find the essence of your words after removing your layers of bold, italics, and capitalics in any combination. Formatting is meaningful and each change in formatting communicates a different intent to the reader. When used in amounts that you seem to enjoy, these contribute nothing to the discussion other than repeatedly interrupting the flow of the text and making it unreadable.

I do value ethics (...)

Your personal definition of ethics is in direct violation of all of the major Codes of Conduct established in the software development environment and, because of that, has already become a meme in the Common Lisp community.

(...) far higher than anybody's mere comfort including mine.

I strongly disagree. You are very comfortable in your position right now, where you think that you can be arbitrarily vulgar, repeatedly offend people, and blame it all on the imaginary Common Lisp Mafia.

Also, this is an evasive response. You did not seem to reply to my original statement, which is that it simply must be more convenient for you to rage about it all on Twitter month after month, blame it all on an imaginary Common Lisp Mafia that you summon whenever you need to cover up your own behavior, invoke your own definition of "ethics" on people who are "unethical" when they decide not to put up with your antics, or perhaps conjure yet another "policy" that serves only to further your own personal agenda rather than serve other people.

Since you did not provide any counterexamples to this statement, I may assume that my point stands unrefuted.

Now "FOUR", but you get the point.

I do not want to get your point. I want to get removed from this list.

---

Finally, I would be glad if you acknowledged that I spent one full weekend day and one whole evening of my free time in an attempt to show you where and how your actions towards the Common Lisp community cause direct harm and retaliation. I did so out of my own volition, I had no obligation to do so, I could have just ignored your post; still, I did that in simple hope that you will finally stop your ranting, think for a moment, modify your behavior, and therefore reduce collateral damage that your arrogance causes upon the Common Lisp community.

As another Lisper mentioned in another thread, "we're Lisp Hackers, and we've got each other's backs". Because of this, I cannot, and will not, hold the back of anyone who repeatedly slams the back of other Lisp Hackers with a big ole wooden stick. Your behavior is the problem, and your blindness to the fact that you are causing harm is a likely source of your behavior. Please change your behavior now or seek help that will let you change it, because patience to say "please change your behavior" is not infinite.

[Hexstream]

Frankly, I believe you have psychopathic tendencies.

I am planning to respond to this in 2021, due to a hard deadline and other much higher-priority stuff.

Do note that I have made tons of big Common Lisp systems in the past, but ultimately, I realized it was a big bag of FAIL, hence my new approach.

Dismissing my deep expertise built over nearly 15 years of hard work mostly based on an in-depth analysis of one old largely unmaintained codebase plus various insane assumptions is deeply stupid.

Yes, we do. Repeatedly offending people seems to be a part of your concept of "basic civility" and not a part of mine.

The irony of you saying this right in the middle of probably the single most offensive post I have ever been subjected to is not lost on me, but it appears it is lost on you.

For the rest, I'll see you in 2021.

[spreadLink]

Frankly, I believe you have psychopathic tendencies.

It seems like there is an unlikely high amount of psychopaths in your life. And all of them, of course, exclusively target you, and no one else, as actual psychopaths usually would. Weird.

Do note that I have made tons of big Common Lisp systems in the past, but ultimately, I realized it was a big bag of FAIL, hence my new approach.

Where?

one old largely unmaintained codebase

The last commit of you to that repository was 2 days ago, pinning it to the top of your repo-list.

Dismissing my deep expertise

I'd dismiss it as well, as there is no evidence of it anywhere. Maybe it's secret evidence. I dunno.

various insane assumptions is deeply stupid.

Exhibit N of you being unnecessarily rude for no reason, where N is many.

The irony of you saying this right in the middle of probably the single most offensive post

I like how posts from you directed to others can not be judged to be offensive by others, but posts from others to you can be judged offensive by yourself. 10/10 consistency

The energy spent by members of the CL community on keeping you in check could be so much better spent on improving CL, the ecosystem and the learning material. Please better yourself or find a different host for your shenanigans.

[phoe]

Frankly, I believe you have psychopathic tendencies.

I am sorry to hear that and I am curious to see your reasoning behind it when you finally respond. I sincerely wish you luck with your higher-priority stuff, and at the same time, I am deeply saddened that you have projects that have higher priority than replying to my post that summarizes your repeated offenses towards the Common Lisp community and attempts to confront you with them.

Since you had no problem making tens of Twitter and GitHub posts containing vulgar, offensive, and aggressive messages towards various members of the Common Lisp community, but suddenly you tell me that you want to work on higher-priority projects immediately after being confronted with a post that attempts to summarize your negative contributions to the Common Lisp community, I have no choice but to consider your response to be yet another dodge in order to try and avoid responsibility for the aggression that you have generated throughout your years of online ranting on various Lisp Hackers.

Do note that I have made tons of big Common Lisp systems in the past, but ultimately, I realized it was a big bag of FAIL, hence my new approach.

Dismissing my deep expertise built over nearly 15 years of hard work mostly based on an in-depth analysis of one old largely unmaintained codebase (...) is deeply stupid.

I am sorry, but I cannot say anything about that. I cannot see any of those systems anymore and therefore have no basis to say anything else. Since you maintain a highly online presence as a Common Lisp expert, I expect you to be able to back this claim in some way; since you have published all of your code on GitHub under permissive licenses, as you claim on your website, I expected your public code to be your business card.

I am sorry if these assumptions are wrong, but they are all based on an assumption that anyone from outside, looking for a Common Lisp expert, would likely perform very similar steps to mine, and assess your overall contributions, technical and social alike. I was unable to verify your technical contributions from an external point of view, and your social contributions to the Common Lisp community are overwhelmingly negative and aggressive with evidence stored in my previous posts.

Anyway - which public codebases of yours should I treat as your business card?

(...) plus various insane assumptions (...)

I do not yet know which assumptions and why you consider them insane and I hope to hear about them in your reply and discuss them further. Even if we put aside the meritocratic aspect of your work and therefore my issues with your Common Lisp code, and instead focus only on your behaviour towards members of the Common Lisp community, I have provided highly detailed reasoning for all of my allegations against you and I consider none of them to be insane or to be assumptions (except where explicitly stated otherwise).

I have attempted to describe everything I perceive in best faith in hope that you are able to understand the consequences of your actions and change your behavior in order to avoid getting even more people angry with your aggression; if you consider this to be insane, I am sorry, but there is nothing more that I can do.

The irony of you saying this right in the middle of probably the single most offensive post I have ever been subjected to is not lost on me, but it appears it is lost on you.

I am curious what you actually find offensive in my above post, since it is based on facts and simple analysis of your post from above. If you find reality offensive, which you seem to, I cannot help you with this.

For the rest, I'll see you in 2021.

No. Remove me from your list before 2021.

[Hexstream]

@spreadLink

I'm happy to debunk you again.

It seems like there is an unlikely high amount of psychopaths in your life. And all of them, of course, exclusively target you, and no one else, as actual psychopaths usually would. Weird.

Usually sociopaths, actually, and they harm everyone in their path but I'm just particularly adept at detecting them, and thus a threat to them, which is why they tend to target me.

Where?

Mostly there. They had been available for nearly a decade.

The last commit of you to that repository was 2 days ago, pinning it to the top of your repo-list.

It is still largely unmaintained. There has been no substantial commit in years, at least in terms of core content.

I'd dismiss it as well, as there is no evidence of it anywhere. Maybe it's secret evidence. I dunno.

There is extensive evidence of it, although it is easier to see it if you open your eyes.

Exhibit N of you being unnecessarily rude for no reason, where N is many.

I have always valued rude honesty higher than polite lies.

I like how posts from you directed to others can not be judged to be offensive by others

Why?? What?

The energy spent by members of the CL community on keeping you in check could be so much better spent on improving CL, the ecosystem and the learning material.

Actually I agree, but there is no need to "keep me in check", so they should just stop doing that instead of wasting their time.

Please better yourself or find a different host for your shenanigans.

I am constantly bettering myself, and I will likely still be part of the Common Lisp community for decades to come.

[Hexstream]

@phoe

I have no choice but to consider your response to be yet another dodge in order to try and avoid responsibility for the aggression that you have generated throughout your years of online ranting on various Lisp Hackers.

I have already extensively responded to most of your posts directed towards me (today being a notable exception), but now I'm on a hard time squeeze and I'd rather make potentially 10000$ CAD even if it means responding to your concerns later.

You should thank me for making exceptions to my long-standing policy of never arguing with insane people.

[Zulu-Inuoe]

@digikar99 I agree that a defacto standard one would be great to already have established, and I think that ironing out those differences is worthwhile, but at the same time we can encourage growth in a defacto implementation by simply choosing one that's healthy enough. Also, I like arrow macros

[phoe]

I'm just particularly adept at detecting them

Yes, you are particularly adept at detecting people who do not consider your high levels of aggression to fit within their ethical standards.

I have always valued rude honesty higher than polite lies.

There is a big difference between rude honesty and repetitive vulgar aggression and you do not seem to perceive this difference, as I mentioned earlier.

but there is no need to "keep me in check

There is a high, urgent, and continuous need to keep the Common Lisp community well-informed about the large negative impact you are having on the community - specifically, the cost of communicating with you with regard to emotional exhaustion, meritorious derailing of discussions, and the constantly looming risk of defamation by means of your Twitter feed which I have just suffered for deciding to confront you about your behavior.

I was aware that such a Twitter post or a series of posts might happen, but I decided that I am ready for paying the price of letting you know that your behavior is not okay, how exactly it is not okay, and what impact it has on people and on the community that you claim to be a part of and sometimes even represent.

Frankly, given the notoriety and persistence of your aggressive behavior, the people involved in the enterprises administered by you, such as the Common Lisp Keybase chat or the upcoming Common Lisp Revival 2020 Fundraiser, should become aware of this and many other GitHub and Twitter discussions that you participated in. I consider this to be required in order for them to be able to gather available facts, query available opinions, and come to conclusions themselves.

I am constantly bettering myself

There is no evidence for this. Your aggression has not diminished in any way since 2015, as backed by the Twitter links that you link yourself from your website.

and I will likely still be part of the Common Lisp community for decades to come.

This is your opinion and you are entitled to it, however, this is only your opinion. Many other members of the Common Lisp community already consider you otherwise and I am honestly worried that many more will join in if you continue acting the way you have been acting so far.

I have already extensively responded to most of your posts directed towards me

My main goal is not getting responses from you; my main goal is having a Common Lisp community that lives to the ideals of personal respect, civility, and non-aggression, all of which you repeatedly and deliberately violate in favor of your personal policies. Therefore, before responding to me the next time, you may instead consider becoming less aggressive and making amends to the members of the Common Lisp community which you have repeatedly defamed on the Internet, which will render all further responses to my above posts unnecessary.

now I'm on a hard time squeeze and I'd rather make potentially 10000$ CAD even if it means responding to your concerns later.

OK - wish you best of luck with this. Internet discussions are Internet discussions, but finances are the more important as they are foundation of life security.

You should thank me for making exceptions to my long-standing policy of never arguing with insane people.

You void this policy of yours yourself every time you argue with the people you consider insane by posting extensive Twitter rants about them even every month or two, therefore I find no need to thank you whatsoever. In all true honesty, I would rather thank you if you ceased your aggression towards members of the Common Lisp community, for which I already asked up above.

[phoe]

I agree that a defacto standard one would be great to already have established

@Zulu-Inuoe I think that the de-facto standard has already emerged. It is there as the lowest common denominator of all the available libraries and has the following traits:

1) Every arrow step is allowed to be evaluated (unlike in Clojure), 2) Do not use diamonds outside the outermost form (like in Clojure). 3) Do not use more than one diamond in a form (like in Clojure).

When you abide by the above rules, it doesn't matter which arrow macro library you use, since they are going to behave consistently.

So, @digikar99, I propose this to be the de facto standard listed in the library docs - you can use any arrow macro library as long as you remember about those three rules.

[Hexstream]

@phoe

Yes, you are particularly adept at detecting people who do not consider your high levels of aggression to fit within their ethical standards.

I wish it was that simple.

There is a high, urgent, and continuous need to keep the Common Lisp community well-informed about the large negative impact you are having on the community

Actually, any negative impact I might be (incorrectly) perceived as having has been constantly overcommunicated and overblown, while my HUGE positive impacts have been pretty much constantly and widely ignored. Hell, just today some deeply insane person said I'm not even a Common Lisp expert! This based on a hasty superfluous analysis of a tiny fraction of nearly 15 years of hard work. (Note that I am counting my nearly 5 years of proprietary Common Lisp work as contributing towards the formation of my expertise.)

specifically, the cost of communicating with you with regard to emotional exhaustion

HAH HAH HAH HAH!! LOOK WHO'S TALKING!!! HAH HAH HAH HAH!!

and the constantly looming risk of defamation by means of your Twitter feed

I don't count it as defamation if it's true, and there is no big risk for anyone not called Zach Beane or Rainer Joswig.

claim to be a part of

"claim to be a part of"!! :rofl:

should become aware of this and many other GitHub and Twitter discussions that you participated in

I believe most of them are already extensively aware.

There is no evidence for this.

There is extensive evidence of this, but you do need to open your eyes. It's hard to have a fair view if you automatically dismiss all the good I do and automatically obsess on what you incorrectly perceive as unacceptable transgressions.

Your aggression has not diminished in any way since 2015

My aggression has extensively diminished since the "PSA about Zach Beane" circa 2018.

I still submit all my ready-to-use libraries to Quicklisp without problems to this day.

as backed by the Twitter links that you link yourself from your website

I am still referencing this stuff because I am ethically required to do so, but note that I have mostly stopped talking about it, simply because I already said pretty much everything I needed to say about this. In fact, I have been repeatedly and unilaterally de-escalating the situation, but I'm sure you haven't noticed.

I am honestly worried that many more will join in

You are now somehow spearheading this movement of blind hatred. I hope you're proud, and I'm sure you are. But I'll give you one thing: you do at least minimally try to understand, though I wish you tried quite a lot harder. But conducting superficial analyses and "confronting me" is probably more fun than genuinely investigating.

lives to the ideals of personal respect, civility, and non-aggression, all of which you repeatedly and deliberately violate in favor of your personal policies.

I certainly don't recognize you as living by those ideals, sorry. You certainly repeatedly and deliberately violate them in favor of your own personal policies, which just happen to be very implicit.

you may instead consider becoming less aggressive and making amends to the members of the Common Lisp community which you have repeatedly defamed on the Internet

Being aggressive is a natural response to being attacked, and I am BY FAR the most defamed person in the Common Lisp community. Asking me to go make amends with my torturers is sadistic.

OK - wish you best of luck with this. Internet discussions are Internet discussions, but finances are the more important as they are foundation of life security.

Thank you. It's probably going to be either a glorious success or a terrible shitshow or both, but definitely not neither.

by posting extensive Twitter rants about them even every month or two

This is a gross overestimate.

Also note that I have virtually never argued with Zach Beane, for instance. Indeed his rather impressive extended silence over several years has been one of the key motivators for my rants about him.

A lot of people would probably quite literally lose their shit if they realized how much respect I have for Zach Beane, which is not that much but still vastly more than most of my critics would ever grant me.

One thing I've realized recently is that blaming Zach Beane for being a sociopath probably makes about as much sense as blaming me for being Asperger's. We did not choose our respective conditions, although mine is certainly much more useful. ;P

(edit: Tweeted.)

(Congratulations for pushing me yet closer to missing my potentially 10000$ deadline. ;P)

[phoe]

I wish it was that simple.

Sadly, it is.

while my HUGE positive impacts have been pretty much constantly and widely ignored

This analysis will come in a separate post for clarity. (EDIT: posted below.)

Hah hah hah hah!! Look who's talking!!! Hah hah hah hah!!

Me, one of the victims of being emotionally exhausted by reading to your posts and seeing them negatively affect the Common Lisp community.

Hell, just today some deeply insane person said I'm not even a Common Lisp expert!

I am still waiting for your refutal of the arguments that have led me to such a conclusion. So far, you have only laughed, but there is still no meritorious point against what I have said.

This based on a hasty superfluous analysis of a tiny fraction of nearly 15 years of hard work.

I have asked you for public codebases of yours that I should analyze in this repository's stead. Until I get an answer, I have no basis to make any other statement.

Note that I am counting my nearly 5 years of proprietary Common Lisp work as contributing towards the formation of my expertise.

I am sorry, but I am not aware of any such work from your side and therefore cannot attest to that. Is there any kind of public letter from your employers that can certify your claim?

I don't count it as defamation if it's true, and there is no big risk for anyone not called Zach Beane or Rainer Joswig.

Then, I do wonder why you found my post offensive; after all, it is true as well. And, even if these people are called Zach Beane or Rainer Joswig, public defamation is not an acceptable behavior in my personal code of ethics under any circumstances.

"claim to be a part of"

Yes, "claim to be a part of". I cannot assume that you are a proper part of the Common Lisp community if you constantly treat it with aggression and obscenities.

I believe most of them are already extensively aware.

I would like to ensure that they are due to the importance of the matter.

There is extensive evidence of this, but you do need to open your eyes.

No, I can see what you are talking of; I do not perceive you as a 100% evil person. Among others, you have successfully converted a large part of the Common Lisp community (including me) to use GitHub sponsors, for which I am thankful and which I assume has made the financial situation of many Common Lisp programmers better by some extent. The documentation of your Common Lisp libraries is top-notch and I can recommend the way you document your software to any Common Lisp programmer. Your format reference is useful and a one-of-a-kind resource at the moment.

At the same time, your interpersonal side and the way you treat people is abhorrent and in violation of any kinds of contemporary codes of conduct, which is why it negates most of the merit you have mentioned above and is an unacceptable transgression. This is the part that I have elaborated on before, since it is prominent and notorious enough to completely shadow your meritorious achievements in the Common Lisp community.

My aggression has extensively diminished since the "PSA about Zach Beane" circa 2018.

Your GitHub rants from 2020 contradict this statement.

I still submit all my ready-to-use libraries to Quicklisp without problems to this day.

I do not think this has much to do with the issue. I cannot speak for Xach, but I cannot rule out the possibility that he simply decided to not engage your aggressive behavior for his personal good.

In fact, I have been repeatedly and unilaterally de-escalating the situation

Your GitHub rants from 2020 contradict this statement.

You are now somehow spearheading this movement of blind hatred.

No, I am voicing my worries. Despite anything you might think at the moment, I am worried about you.

I hope you're proud, and I'm sure you are.

Your hope is void. I am not proud. I am tired, sad, and annoyed. I wish this was over, and yet your destructive behavior continues.

But conducting superficial analyses and "confronting me" is probably more fun than genuinely investigating.

I did perform genuine investigation into your behavior, I am still performing it, and I will perform more of it. I am sorry, but so far the results are overwhelmingly negative where your technical merit is shadowed by the way in which you attack people, derail threads, and descend into vulgarities.

I certainly don't recognize you as living by those ideals, sorry. You certainly repeatedly and deliberately violate them in favor of your own personal policies, which just happen to be very implicit.

I am sorry, but you are not the proper person to say that, with multiple policies of your own that you apply completely arbitrarily when they are suitable for you.

Being aggressive is a natural response to being attacked

You think you are being attacked whereas it is not the case in reality, which causes you to be aggressive in situations that do not require aggressive responses.

and I am by far the most defamed person in the Common Lisp community

No. You are by far the most defaming and aggressive person in the Common Lisp community at the moment and you are seeing the consequences of this fact right now. If you think that the consequences of your behavior is "defamation", then I am sorry, but the only person who is capable of change this state of matters is you.

Asking me to go make amends with my torturers is sadistic.

I am sorry, but they are not your torturers, as much as you attempt to make this into a reality. Instead, your behaviour towards people, including people who are not Zach or Rainer, is highly harmful and exhausting. You have much to apologize for.

This is a gross overestimate.

I can perform statistics to validate this estimate if required. It will take some effort, but it can be done.

Indeed his rather impressive extended silence over several years has been one of the key motivators for my rants about him.

As I said before, I do think that Zach's silence is an attempt to cope with your aggressive and obnoxious behavior. Countless people are able to communicate with him normally on Freenode, Twitter, mail, and via other avenues. You are the only person who has a problem with him.

A lot of people would probably quite literally lose their shit if they realized how much respect I have for Zach Beane, which is not that much but still vastly more than most of my critics would ever grant me.

Lose their shit? Why? If you have respect for Zach Beane, then I know little about it; I know how much respect you don't have for him, since you have extensively documented it on Twitter.

One thing I've realized recently is that blaming Zach Beane for being a sociopath probably makes about as much sense as blaming me for being Asperger's.

I do not blame you for having Asperger's and never will. There is no proven link between Asperger's and aggression, or Asperger's and verbal violence, or Asperger's and defaming people online, which means that these aspects of you are fully under your own responsibility to maintain.

We did not choose our respective conditions, although mine is certainly much more useful. ;P

It is not your condition that you use when it comes to harming the Common Lisp community.

Congratulations for pushing me yet closer to missing my potentially 10000$ deadline. ;P

No need to thank me, you replied here out of your own volition. This thread can wait for as long as necessary for your reply.

Again, in your above post, you still have not replied to the original allegations that I have made, which is why I still consider your above post to be an attempt to avoid the responsibility of directing years of your aggression into the Common Lisp community. Do I need to make a collection of unanswered Hexstream questions somewhere, just so they do not get lost in yet another thread derailment of yours?

[phoe]

Hokay then.

Allow me to review your claims of having a huge positive impact on the Common Lisp community. My review is based on your CV, the current Quicklisp dist, and your public GitHub activity. I assume that your next tweet will link to this post as a proof that I have done exactly what you've asked of me, and so your fans can get to know the AFAIK first public analysis and independent piece of research into Hexstream's impact on the Common Lisp community.

Once again, I am doing this in my free time, since I consider this analysis to be important for the Common Lisp community as a whole.

---

You have been self-employed for fifteen years with no commercial success and no money earned until April 2020, when, according to a tweet of yours, you got your first GitHub Sponsors donation. Therefore, looking from the financial point of view, you have been unemployed for almost 15 years and this state of matters only changed seven months ago. Your above claims of having five years of commercial experience are therefore made void by your own words, as commercial experience implies commerce, which in turn implies some kind of currency exchange.

---

You have deleted the old code that you have created by proclaiming your projects unworthy of your attention; I have no reason to doubt your instinct on this and I will therefore consider this code unessential and therefore not contributing to your impact on the Common Lisp community.

You have 30+ micro-libraries on Quicklisp that are mentioned as "my newer, suitably engineered, documented, actually worthwhile projects" on your CV page, which contradicts your claim from up above that this library is old and almost unmaintained. These libraries, if we exclude their associated test systems, are used by no other Quicklisp projects whatsoever, which means that these libraries have no public impact whatsoever among Lisp programmers who push their own code to Quicklisp.

The below code snippet should allow anyone to reproduce my findings using the standard Quicklisp dist as well as verify individual steps of this computation for correctness.

CL-USER> (let* ((repositories '("abc.hexstream.xyz" "anaphoric-variants"
                                "bubble-operator-upwards" "cartesian-product-switch"
                                "cesdi" "chat.hexstreamsoft.com" "class-options"
                                "clhs" "clos-mop.hexstreamsoft.com"
                                "common-lispers.hexstreamsoft.com"
                                "common-lisp-format-reference"
                                "compatible-metaclasses" "cv.hexstream.expert"
                                "definitions-systems" "enhanced-boolean"
                                "enhanced-eval-when" "enhanced-find-class"
                                "enhanced-multiple-value-bind" "enhanced-typep"
                                "evaled-when" "fakenil" "first-time-value"
                                "getting-started-with-the-clhs" "gitdirs" ".github"
                                "global.hexstream.dev" "Hexstream"
                                "hexstream-project-template" "incognito-keywords"
                                "its" "macro-level" "map-bind"
                                "multiple-value-variants"
                                "notes-and-tips.hexstreamsoft.com"
                                "bigname" "complex-slots" "ensure-method-combination"
                                "evaluated-flet" "explicit-bind"
                                "first-class-lambda-lists" "hexstream-html-doc-mode"
                                "inherited-values" "lispy-format" "xcall"
                                "clhs-chrome-extension" "easy-backquote-nesting"
                                "hecss" "hextml" "loopless" "map-symbol-definitions"
                                "return-values-hints" "object-class"
                                "parse-number-range" "place-modifiers"
                                "place-utils" "positional-lambda"
                                "roadmap.hexstreamsoft.com" "simple-guess"
                                "status.abc.hexstream.xyz"
                                "status-quo.hexstream.expert" "symbol-namespaces"
                                "tarballs.hexstreamsoft.com"
                                "trivial-jumptables" "with-output-to-stream"
                                "with-shadowed-bindings" "www.hexstream.expert"
                                "www.hexstreamsoft.com"
                                "common-lisp-symbols-comparison"
                                "principles-and-intents" "stream-lisp"
                                "www.stream-lisp.org")) ;; list of all repos from GitHub
                (dependents (remove-duplicates (alexandria:mappend #'ql:who-depends-on repositories)
                                               :test #'string=))
                (real-dependents (set-difference dependents repositories :test #'string=))
                (test-system-p (lambda (x) (and (= (- (length x) 6) (search "_tests" x))
                                                (member (subseq x 0 (- (length x) 6))
                                                        repositories :test #'string=))))
                (dependents-without-test-systems (remove-if test-system-p real-dependents)))
           dependents-without-test-systems)
NIL

---

The issue/PR information of the aforementioned Common Lisp repositories (7 meaningful issues in total) shows very little information that can prove real-world usage of these libraries.

I will try to filter out issues that likely did not come from using this library

• https://github.com/Hexstream/enhanced-boolean/issues/1 mentions a possible issue that likely came from a code review of this very brief library. This is likely because it came from a person experienced enough with the topic to suggest a fix, and that the issue was created the day after the repository was published.
• https://github.com/Hexstream/cesdi/issues/1 is an unanswered question related to confusion about what a library actually does.
• https://github.com/Hexstream/place-modifiers/issues/2 mentions a crash while attempting to describe the library for Lisp Project of the Day, which constitutes promotion rather than real-world usage.

This leaves us with three issues in total.

• https://github.com/Hexstream/class-options/issues/1
• https://github.com/Hexstream/place-modifiers/issues/1
• https://github.com/Hexstream/first-time-value/issues/1

This information alone is not statistically significant enough to state that there is some actual production use of these libraries.

---

You have created a list of annotated Common Lisp symbols with your personal notes, examples, and tips, which is in a mostly incomplete state, but has some nice notes.

You have created a rendering CLOS MOP specification that has several usability issues, mostly related to the presentation layer; the series of arrows and anchors in the corner is non-intuitive, a bit ugly, and has no way of being turned off. I suspect that this work would have been welcome into the ecosystem if not for the insistence, entitlement, and aggression with which you attempted to push it into the Common Lisp ecosystem and the later vulgarity that was thrown at some members of the Common Lisp community in retaliation for your contribution not being accepted due to the aforementioned aggression.

You have created a useful format cheatsheet that I consider to be your most important work so far since it duplicates no other known Lisp resource; I am not aware of any other, or better, tabular format reference. Still, it has suffered the same fate as above - an example of a fine resource sinking because of your aggressive personality and your blaming of the consequences of your own violence on Xach and the Common Lisp Mafia.

You have created a list of Common Lisp programmers that you still have not removed me from despite my repeated and explicit requests to do so, which is a strict net negative due to it basically erasing whatever trust I may have towards you as a member of the Common Lisp community.

I am explicitly skipping the EZ-Planck and TypeMatrix 2030 projects since these are mechanical keyboard projects and we are evaluating your impact on the Common Lisp community.

---

You have created 2786 commits on GitHub in your own repositories in the @Hexstream, @Hexstream-not-yet-ready, @Hexstream-not-yet-scavenged, and @StreamLisp organizations. I am explicitly counting only commits that GitHub shows as public.

You have 12 (11 official + 1 re-authored) commits in Lisp-related GitHub repositories that do not belong to you. I am explicitly skipping non-Lisp repositories since these are off-topic to evaluating your impact on the Common Lisp community.

• 1 commit in https://github.com/atlas-engineer/nyxt
• 1 commit in https://github.com/azzamsa/awesome-lisp-companies
• 3 commits in https://github.com/CodyReichert/awesome-cl
• 1 commit in https://github.com/cxxxr/lem
• 1 commit in https://github.com/froggey/Mezzano
• 2 commits in https://github.com/portacle/portacle
• 1 commit in https://github.com/quicklisp/quicklisp-projects
• 1 commit in https://github.com/ultralisp/ultralisp
• 1 commit in https://github.com/LispCookbook/cl-cookbook (re-authored)

Out of these 12 commits, 6 are related to adding crowdfunding links to the respective repositories, 5 are related to promoting your own work or groups you administer (HexStreamSoft, CLOS MOP, Keybase chat, updating tarballs on Quicklisp), and one is a typo fix.

---

You have opened 16 pull requests on Lisp-related repositories that you do not own. Counting out the 12 pull requests from above which were merged, this means that 4 of those are still open or have been closed:

• https://github.com/cbaggers/cepl/pull/329
• https://github.com/marijnh/Postmodern/pull/210
• https://github.com/sbcl/sbcl/pull/25
• https://github.com/stassats/lisp-bots/pull/6

2 of those PRs are related to adding crowdfunding links to the respective repositories, while 2 are rerelated to promoting your work (CLOS MOP).

---

You have opened 22 issues on your own GitHub repositories in the @Hexstream, @Hexstream-not-yet-ready, @Hexstream-not-yet-scavenged, and @StreamLisp organizations, and commented on 29 issues made by others in these repositories.

You have opened 40 issues on https://github.com/quicklisp/quicklisp-projects in order to maintain your libraries in the main Quicklisp dist, and commented on 23 issues made by others in this repository.

You have opened 3 issues on https://github.com/quicklisp/quicklisp-client related to various improvements in the Quicklisp client, and commented on 6 issues made by others in this repository.

You have opened 11 issues on https://github.com/ultralisp/ultralisp related to various improvements in Ultralisp, and commented on 12 issues made by others in this repository.

You have opened 48 issues in various other Lisp-related repositories and commented in that 42 issues made by others in various other Lisp-related repositories that I cannot be bothered to analyze since I have already spent too much on your time on these posts due to the effect of Brandolini's law.

I am not willing to analyze the contents of your issues or comments because I am too tired of reading your countless rants or to try and make any sense in them. If anyone else feels like having a go at it, please, go ahead; GitHub history is public.

---

There are many people in the Common Lisp ecosystem who create, maintain, and contribute to Common Lisp compilers and implementations, graphical toolkits, window managers, operating systems, game engines, computer algebra systems, database utilities, bindings to foreign libraries, knowledge-sharing, writing articles, writing books, organizing conferences, organizing meetups, answering technical and ecosystemic questions on online chats.

And there is you, with an amount of code equivalent to a single utility library of size comparable to perhaps Alexandria, except with zero of the popularity of Alexandria; a format cheatsheet that has a very nice idea but is a week's worth of net HTML work to redo from scratch; a MOP reference that is a duplicate of an already existing reference; absolutely zero interest in any codebase that is not of your own making; and, sadly but also most importantly of them all, a social apparatus that voids all of this merit by making their author impossible to tolerate.

You seem to abhor all foreign codebases. This stands out because your commits and pull requests, as few as they are, are only related to adding crowdfunding links and insistently promoting your work, with the exception of one pull request that is not even technical because it fixes a typo in a documentation file. This means that your expertise with codebases from other authors is an absolute and complete nil, and this is still before counting your unwillingness to work on them or even read their code whatsoever. This, in turn, means that your expertise with existing, real-life Common Lisp projects (which are naturally written by other people over various spans of time) is not just a nil, it's a net negative. A newbie will likely do better than you because of their lack of prejudice towards codebases written by other people or that follow different style guidelines.

At this point calling you a Common Lisp expert would be a slap in the face to all the various people I have mentioned three paragraphs above.

---

Let me summarize.

• You have had no commercial success with Lisp throughout fourteen years of doing it, with this state of matter having slightly changed only earlier this year via a single donation.
• All projects of yours that are not micro-utility libraries that were mostly single-handedly authored by you have been ineffective at making an impact in the Common Lisp community because you threw them in the trash bin.
• All projects of yours that are micro-utility libraries that were mostly single-handedly authored by you have been ineffective at making an impact in the Common Lisp community because nothing in Quicklisp depends on them and I cannot see meaningful issue/PR information that would hint for them being used. I have no other data that I can base any other assumption on.
• The two documentation projects (format cheatsheet + CLOS MOP) have been ineffective at making an impact in the Common Lisp community because of your obnoxious behavior making it impossible for many people to even think of accepting your contributions whatsoever.
• You have never contributed a body of code to a codebase that is not of your own making and, based on your previous claims, I interpolate that you are not interested in doing this in the future.
• Don't even get me started with the shitstorms you have started in GitHub issues.
• Nor do I want to dive into your Twitter archives.
• I do have to admit. You have been popularizing crowdfunding among Lispers and achieved visible success there. This is the one single thing that I can unambiguously consider a net positive coming from you.

Summarizing the summary? Given the fifteen years of experience that you claim to have, all of this is literally nothing. People are capable of creating really grand things in a tenth of time that is fifteen years. They are capable of learning Common Lisp and getting things done in it in a third of fifteen years. They are capable of making tens, if not hundreds, of meritorious PRs to various foreign codebases in a single year. Where's all that in your case? Where's a tenth of that in your case?

Your greatest personal achievement is the discord you have created in the Common Lisp community. If the Common Lisp community was a old-Linus-Torvalds-styled pure meritocracy, you would most likely get kicked out of it at the very beginning - like you were, from Lobsters.

Please feel free to refute the above arguments. To me, all of the above means that you are not a Common Lisp expert. You are not even close to a Common Lisp expert. You are a fraud.

[Hexstream]

Your posts contain countless factual, logical and other errors. I'll see you in 2021, dear.

[phoe]

I'll see you in 2021, dear.

Sorry. I'm not your "dear".

[phoe]

Your posts contain countless factual, logical and other errors.

As I said before, I am waiting for your answer providing details, just like I am waiting for answers for multiple previous statements that you have left without proper rebuttal. Instead, I got a short sentence added in a post-comment edit that basically says "you're wrong" without backing it up in any way. Again.

It is getting boring by now, you know.

EDIT: to quote my post above:

I assume that your next tweet will link to this post as a proof that I have done exactly what you've asked of me, and so your fans can get to know the AFAIK first public analysis and independent piece of research into Hexstream's impact on the Common Lisp community.

I hope that since you were bold enough to ask for my analysis, you'll perform this single feat I've asked of you in return and share the fruit of my work with your Twitter audience.

[digikar99]

I'm closing this for the time being because the discussion has become too irrelevant to the issue. I'm closing this without a proper resolution because I've more urgent tasks and no one wants to stop furthering the discussion.

Please consider settling long-standing misunderstandings over a private chat once both of you are free - or agree to disagree.

[digikar99]

Locking, but re-opening because unresolved

[digikar99]

Discussion continues over to https://github.com/cl-library-docs/common-lisp-libraries/issues/7