<div><span style="color: rgb(160, 160, 168);">On Friday, 20 February 2015 at 17:39, e@bestmx.net wrote:</span></div>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div><br></div><div><br></div><div>On 02/20/2015 05:27 PM, Rad Gruchalski wrote:</div><blockquote type="cite"><div><div>On Friday, 20 February 2015 at 17:06, <a href="mailto:e@bestmx.net">e@bestmx.net</a> wrote:</div><blockquote type="cite"><div><div>frameworks massively fail at the task of abstraction -- knowing</div><div>"specification" is never enough for a "framework".</div></div></blockquote><div>Knowing specification is one thing, rejecting some common solutions, sometimes worked out for years of repetitive problem solving, is another thing. I think you are possibly a bit extreme in your judgement.</div></div></blockquote><div><br></div><div>i can not recognize an objection to my statement.</div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    There was none. Just a hint that “a framework” (or a library) is not always claiming to be “the only solution, otherwise there be dragons”. Some of them encapsulate some knowledge, is it wise rejecting on a basis “it’s a framework"? Sometimes a framework is a great learning source, for example - how to handle a protocol correctly.</div>