Xen project Mailing List

Forgot to add....language tools change (especially at module level, as per c++ or OCaml toolchains) and contributor skill levels grow, so all choice of abstraction level is an ephemeral compromise...

On 18 Nov 2015 14:51, "Jon Crowcroft" <Jon.Crowcroft@xxxxxxxxxxxx> wrote:

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

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