Just because these hostnames point to FB IP addresses does not mean they're owned and operated by FB.
> 0-1.fb.me
> 0-7.fb.me
> ...
This lists a bunch of subdomains, ideally only the second-level domain names that can be owned by FB should be listed. Because anything under that is obviously FB.
> Consider git – it only ships the diffs, yet it produces whole and consistent repositories.
IIRC git does _not_ ship diffs. It copies whole files even for the tiniest change. The compression layer handles the de-duping, which is a different layer.
I still find myself confused at this one. Did people in 1970s not imagine that any particular program or database would "survive" for 30+ years? Was the expectation that programs written in the future could set the epoch to a later date?
Now that I think about it, I also find it interesting that the epoch date isn't configurable in any system that I'm aware of.
Unix timestamps can represent dates *before* 1970, by using negative numbers.
Dennis Ritchie has said that he picked signed 32-bit values with an epoch of 1/1/1970 because that would comfortably represent dates exceeding his life - before he was born until after his (expected) death.
Nobody expected Unix timestamp to survive so long when it was designed, and norm was to use different format in databases that would care about dates beyond 2038
Not just bits - unix timestamp ossified as 32bit value on PDP-11, and handling longer timestamp would involve a lot more code to implement arithmetic on larger than 32bit values, plus also would complicate C language
All computer evolution up to that day happened in the 30 years prior, so how on earth could they possibly expect that their system would last such a long time?
I do recall from the time frame mid-eighthies to mid-nineties that three year old computers were obsolete. Ten year old stuff was ancient history. Never would I have imagined to be able to use Linux for 30 years.
IBM's promises, largely delivered to this day, that their System/360 computer hardware and future generations would be compatible, as was that line of computers except for the lowest end special case? All the effort IBM put into emulation of their older machines in the microcoded models (all but two high end ones)?
Some time before then it was realized we had a "software crisis" as outsiders put it, and IBM realized they were spending too much money supporting many different designs, some evolutionary with minor changes?
Many ideas behind systems like Linux go back to the 1960s as well, see Multics, the primary inspiration for UNIX but ultimately a closed source dead end.
For the original question we have to realize how very small many old computers were. UNIX started on small DEC minicomputers, it would have made almost no sense at all back then to allocate more than 32 bits when your maximum data address space was 56KiB and your CPU was 16 bit (the PDP-11 family where UNIX became big following an incompatible DEC predecessor).
> I'm essentially a believer in You Aren't Gonna Need It — the principle that you should add features to your software — including generality and abstraction
YAGNI is not a principle. It is a contextual thumb rule. A codification of expert intuition. Exceptions to thumb rules are quite the norm.
Conflating thumb rules with principles is a sign of sloppy thinking.
Often engineers will misuse terminology thinking that it "doesn't matter". But it does. Think twice before claiming that something is a principle.
The words you use highly influence your thought process[0].
> Conflating thumb rules with principles is a sign of sloppy thinking
Multiple dictionaries and thesauruses would disagree with you there. Rule of thumb is often defined in terms of "rules, procedures, principles, or... ...derived from..."
Some sources say that "rule of thumb is a principle or procedure...""
So, you know, going straight to "sloppy thinking" reminds me of OldManYellsAtCloud.jpg.
Anyway, I'm really not sure what difference you perceive - principles are often derived from experience, as well as theory, and they often have exceptions too.
Many people have a principle of not committing violence, for example. _Except_ when (multiple clauses follow).
That they include "rules" and "procedures" indicates those definitions are based around the "what" rather than the "why". A rule of thumb is something passed down, while a principle is something you come to from experience. A rule of thumb likely started as a principle from someone else.
Rules and procedures are a further watering down of the original idea, where even the rule-of-thumb's justification isn't paid attention to or even has been lost over time.
Your definitions are very interesting there mate. In some contexts, yep, what's often called a rule of thumb (for example, sparkies use a multitude of <X>-hand rules[0][1] and call them rule of thumb, because you know, there's a thumb involved) are passed down.
But people are entirely able to derive their own rules of thumbs, if we hark to the common definition that a rule of thumb is a principle/procedure/process derived from practical experience.
For example, I rapidly developed a rule of thumb when dating post-divorce that any person who said "I hate drama" in their dating profile is in actual fact the source of any drama, but it took me a couple of disastrous dating attempts to develop that rule of thumb.
Pragmatism vs Dogmatism. For example DRY vs YAGNI. The first is more dogmatic: refactor everything that can be refactored, while the second is more pragmatic. The refactor is probably not necessary and might turn out not to be necessary. An even more pragmatic rule is the You Aint Gonna Need It Yet.
> Pragmatism vs Dogmatism. For example DRY vs YAGNI.
DRY often has exceptions to the "rule"/"principle" too though. And people often blog on these exceptions.
And pragmatism and dogmatism aren't a xor, they're just convenient labels for the -X and the +X ends of the axis.
(Admittedly, the fact that I've seen more "It's okay to have exceptions to DRY" blog posts than "It's okay to have exceptions to YAGNI" indicates you're right about their relative weighting on that axis.)
Your semantical argument of "principle" vs "contextual rule of thumb" is incorrect. They mean the same thing in almost every context, according to any dictionary/thesaurus you find out there.
In fact, the ultimate defining characteristic of a "principle" is that it has exceptions and should not be used as the "ultimate word of God".
Even in Physics, where most would think a "principle" means something "without exception", they are only ever currently without exception according to current evidence. There has been countless times where there has been a scientific principle only to be disproven later on.
Lastly, you link Sapir–Whorf, which, quite ironically, is considered a "principle" yet has had much criticism over time, which contradicts your own argument.
However, I will agree with you that one should always be careful of the language they use since it can affect how others view your thoughts, feelings, and intentions.
> The words you use highly influence your thought process
Given that the article is literally about exceptions to YAGNI, and explicitly calls out that there are probably more, their use of the term "principle" doesn't appear to have caused them any harm.
> The words you use highly influence your thought process[0].
Yet in the very article you link it says (emphasis mine)
> The strong version, or linguistic determinism, says that language determines thought and that linguistic categories limit and determine cognitive categories. This version is generally agreed to be false by modern linguists.[3]
> The weak version says that linguistic categories and usage only influence thought and decisions.[4] Research on weaker forms has produced positive empirical evidence for a relationship.[3]
Your use of 'highly' would suggest a strong relativity, but that's discredited. Signed, a disgruntled linguist who's tired of people banging on about Sapir-Whorf.
If Baghdad is city your users destroy most often, I would allow a destroyBaghdad() function that calls destroyCity() with all parameters set correctly.
My point was that neither routune should ever be written and the Middle East would've been much better off if the world had started an all-out economic war against the US in 2003.
In case you are wondering, I'm Russian, have friends in the Ukraine and destroyed Kiev is the last thing I want.
Jokes about destroying Baghdad are just callous. Especially coming from Americans.
> This can apply to protocols, APIs, file formats etc. It is good to think about how, for example, a client/server system will detect and respond to different versions ahead of time (i.e. even when there is only one version),
A blogpost/article about YAGNI manages to suggest a rather nuanced feature should always be included, that isn't needed, right up front.
Indeed. A rule of thumb is something you're supposed to use, at most, in the absence of any better information. I've written abstractions that didn't end up needed, sure. I've also written abstractions that I've been extremely glad for in hindsight.
Gauche scheme is a very "scripting-focussed" implementation, with some niceties inspired from scsh. I've used it's repl as a shell of sorts for a short while, just to see if I could.
Janet is a new lisp (heavily inspired by Lua, not surprising given its author had previously started fennel, a lisp which compiles to Lua) which fits a smiliar "scripting" niche. An extension has been made for it (janetsh) to make it suitable as a shell replacement.
In a similar vein, racket has rash.
And if you consider tcl as a "lisp for strings", then it's almost a shell right out of the box. I've used jimtcl (again, like gauche, with a heavily customised shell-focussed lib of my own) as an interactive shell.
Lot's of choices out there, if one is willing to roll one's sleeves up ;-)
Actually there exists a shell, "scsh", which uses the Scheme language, i.e. a LISP variant.
"scsh" is less convenient for interactive use than bash or zsh, because it is more verbose, but it was quite good for scripts, certainly more convenient as a replacement for shell scripts than Python or the like (because it had a better syntax for the equivalent of a POSIX command list, with pipes, and/or lists, redirections and parameter expansions).
Many years ago, I have written and used with good results a lot of "scsh" scripts, for things deemed to be too complex for POSIX shell scripts.
However, AFAIK, "scsh" has not been updated in recent years, so I do not know how good it would still be today.
Murex comes across kinda lisp-y with the keyword-less, prefix-notation #'if statement. Emacs also offers a unique (and very lisp-y) shell syntax within #'eshell.
