Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!

Subject: Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2017-10-12 04:47:44

2017-10-09 22:18 GMT-03:00 Vinnie Falco via Boost <boost_at_[hidden]>:

> I'll try to provide more clarity. `beast::basic_parser` is designed
> with standardization in mind, as I intent to eventually propose Beast
> for the standard library.

A standard library is a library where we cannot have the luxury to make
mistakes.

If you make a mistake, the API will carry the technical debt forever.

I have made the interface as [...]
> [...] tradeoffs are made. [...]
> [...] One can only measure the relative
> success of designs based on the feedback from users. They opened
> issues [...]
>

So... it solves the problem for N users... therefore it'll solve the
problem for N + Z users too? Do you see how this looks like to me? If I
take the guess that the problem is the inductive reasoning that I
criticized all along in the previous tutorial I've linked, would you think
that this would be a wild guess or a reasonable guess? Can you understand
why I see the situation as such?

However, I'll pretend that I've chosen the optimistic vision this time.
I'll pretend that you've started to grasp the critics and you're here
explaining how you've developed Boost.Beast parser (i.e. the approach used
to tackle development) to justify your design.

For a moment, let's ignore the “justify the design” and focus on the
approach to the development (because the way you presented is not a
discussion of design). What you're doing is applying a heuristic. I do know
and use this heuristic (directly and indirectly). But there are two points
that I want to add here.

The first point is: do not be a slave to a single one heuristic. I also
mentioned one heuristic in the tutorial I've linked previously, the Occam’s
razor https://vinipsmaker.github.io/asiohttpserver/#_footnote_8

When you say “we need to be careful interpreting results”... how does
someone who lacks the tools in the cognitive repertory will interpret these
results? Can you describe/use me your other tools? I'm not the one who will
praise you if you answer quickly. Take your time (people rarely listen to
this advice).

The second point is: here, you need to go *beyond* the heuristics. This is
a point that depends entirely on you. I cannot explain you how you go
beyond the heuristics. You've just got to do it.

I'll try a new approach here. Given some of the ideas weren't well received
by you, I took the liberty to convert the Tufão project that you've
mentioned to use the Boost.Beast parser:
https://github.com/vinipsmaker/tufao/commit/56e27d3b77d617ad1b4aea377f993592bc2c0d77

Would you say you like the new result better? Would you say that I've
misused your parser to favour my approach? How would you have done it in
this case? Would you go beyond and accept the idea that the spaghetti
effect is inherent to the callback-based approach of push parsers? Or maybe
would you say that the spaghetti effect is small and acceptable here?

What do you think about the following links?

   - https://github.com/google/pulldown-cmark
   -
   https://www.ncameron.org/blog/macros-and-syntax-extensions-and-compiler-plugins-where-are-we-at/
   - https://github.com/Marwes/combine

Let's try yet another way to approach the problem (a different perspective
again). We talked about heuristics and I begged you to go beyond. But there
is one vision/perspective of this problem that may help you. Reason +
logic: wouldn't you agree that `basic_parser<T>::eager(false)` is just a
hacky way to implement a pull parser? Why? Remember to pay attention to the
*why*. I'm not interested in the yes/no.

[...] no one has asked for [...] If this becomes something that users
> consistently ask for, it can be done by [...]

“if you do not give a try to enter in the general problem and insist
on a *myopic
vision*”
  — https://vinipsmaker.github.io/asiohttpserver/#_implementing_
boost_beast_parser_interface

Why do you only solve the problem that is immediately in front of you?

You're not serious about standardization (consult my comment on technical
debt right at the beginning of this email) if you're unwilling/afraid to
let go of this modus operandi. There is a bright mind hiding behind this
robot. Let us see it.

There is a talk that is pure design, “understanding parser combinators - a
deep dive”[1]. How do you use *any* of your currently presented
lens/perspectives to judge the ideas of this talk? “Look, the idea of
composability here is wrong because he hasn't filled a project with 100
issues at Github”. It's just pathetic. I'm not entering in this
leads-to-nowhere line of reasoning, so please just stop.

What would you use as an example of design discussion? The tutorial I've
linked previously[2] or the conversation we're at now?

How wrong was I... I just thought you were ignoring the ideas all along.
How wrong was I... You just don't understand the subject at hand.

“There are these two young fish swimming along, and they happen to meet an
older fish swimming the other way, who nods at them and says, "Morning,
boys, how's the water?" And the two young fish swim on for a bit, and then
eventually one of them looks over at the other and goes, "What the hell is
water?"”

You don't know water, do you? Nor inductive reasoning, nor myopic vision,
nor Occam’s razor and the list goes on...

It's so frustrating... you can't imagine. You just have no idea. Sorry
about the trouble caused so far. I'll meditate on this matter and try to
learn something out of this episode.

“A cat approaches a dog and says “Meow.” The dog looks confused. The cat
repeats, “Meow!” The dog still looks confused. The cat repeats, more
emphatically, “MEEOW!!!” Finally, the dog ventures, “Bow-wow?” The cat
stalks away indignantly, thinking “Dumb dog!””

Thank you for the useful research that you've done. I'll surely use it (and
learn from it).

[1] https://vimeo.com/171704565
[2] a tutorial that I've done in a rush and I'm not very proud of, but it
still touches design

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/