Re: [MirageOS-devel] How to implement protocols?

[Jon Crowcroft <Jon.Crowcroft@xxxxxxxxxxxx>]

different abstractions have 
different cognitive overhead, 
different time overhead and a
different runtime overhead - 

we're driven by tradeoffs
in systems programming goals and
in a real world project resources (human programmer time) which 
may mean we choose something that takes 
less time to write, and is less generic - 
it can be made more generic later (with more work)
we might choose something that has a steeper learning curve
(sockets won as an abstraction of internet protocols over other
APIs/services because  they were easier to learn - they are a pain in
other regards) - 

and (as discussed and thanks to jeremy et al for pointers)
some language features have more or less compile v. runtime - even at
the trivial function level, inlining might work - templates in C++
looked good at the time, but require peppering the declartion with all
sorts of quid pro quos about the type assumptions (hard to write,
hard to read) but compile to  faster code than functors (an old
polymorphic type systems design tradeoff etc etc...

more readable doesn't mean more writeable;)

> On 2015-11-18 14:08, Daniel Bünzli wrote:
> 
>     Le mercredi, 18 novembre 2015 à 02:26, Nik Sultana a écrit :
> 
>         For one thing, chosen abstractions are partly a matter of taste 
> -- one
>         person's abstraction is another person's abomination...
> 
>         For another, abstractions are devised based on what's suitable at 
> the
>         time for a project. We have to be pragmatic.
> 
> 
>     Abstractions, understood as mechanisms to structure data and
>     computations, also have *properties* and some abstractions may have
>     bad properties in the long term e.g. with respect to maintenance, code
>     evolution and understandability. So it's not only about taste or
>     what's suitable at the time, it's also about thinking about the future
>     readers and maintainers of the code â?? something that is too often
>     misregarded both by programming language designers and programmers.
> 
> 
> 
> Cant blame them entirely. Despite the best of intentions, designers and
> programmers alike don't know what the future's going to bring. Occam's
> razor can get flicked long before the future becomes the present. Surely
> the hubris about long-term thinking should be a thing of the past by now.
> 
> 
> 
> 
>     This sentence in the document is as useless as misguided as it will
>     wrongly be understood (see my first message). Maybe it simply wants to
>     say write code that is readable and understandable, but it fails at
>     doing so â?? and then why repeat here is anyway in the programming
>     guidelines of the language you program in [1].
> 
> 
> 
> Well if it can lead to a better sentence, I don't think it would have been
> so useless after all.
> 
> 
> 
> 
>     Best,
> 
>     Daniel
> 
>     [1]
>     
> https://ocaml.org/learn/tutorials/guidelines.html#Generalguidelinestowriteprograms
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel