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" <[email protected]> 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 > > [email protected] > > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > > > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
