diff options
| -rw-r--r-- | content/en/blog/news/20201024-why-better.md | 14 |
1 files changed, 8 insertions, 6 deletions
diff --git a/content/en/blog/news/20201024-why-better.md b/content/en/blog/news/20201024-why-better.md index 4a8afac..89091a0 100644 --- a/content/en/blog/news/20201024-why-better.md +++ b/content/en/blog/news/20201024-why-better.md @@ -82,11 +82,12 @@ for (int i = 1; i <= 10; ++i) { The reason it is considered bad practice, is based on years of programming experience: thousands of programmers noticing that such -constructs often lead to bugs and lower maintainability. I would argue -that the Internet is full of this kind of bad practices -- it doesn't -take a huge stretch of the imagination to take the example above as an -analogy for Network Address Translation. Only instead of being seen as -bad practices, they are taught as indispensible networking technologies. +constructs often lead to bugs and lower maintainability[^3]. I would +argue that the Internet is full of this kind of bad practices -- it +doesn't take a huge stretch of the imagination to take the example +above as an analogy for Network Address Translation. Only instead of +being seen as bad practices, they are taught as indispensible +networking technologies. And that's why I think Ouroboros is a "good" network model. If the minimal necessary and sufficient conditions for networking are @@ -112,4 +113,5 @@ better: [^1]: I came across this when thinking about the limits for the timers for retransmission. A DTN is basically two layers, one without retransmission on top of one with retransmission at very long timeouts. -[^2]: Of all the comments from peer review, not a single one has addressed any technical issues -- let alone correctness -- of the model. Most are that I fail to justify why the reviewer should bother to read the article or make an effort to try to understand it as it doesn't fit current engineering workflows and thus has little chance of short-term deployment. Sorry, but I don't care.
\ No newline at end of file +[^2]: Of all the comments from peer review, not a single one has addressed any technical issues -- let alone correctness -- of the model. Most are that I fail to justify why the reviewer should bother to read the article or make an effort to try to understand it as it doesn't fit current engineering workflows and thus has little chance of short-term deployment. Sorry, but I don't care. +[^3]: With modern programming languages leaning more and more towards discouraing mutables alltogether. |