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
