thepicard
What is interesting is that the operating system virtualizes a machine that doesn't actually exist: fake "hardware" that can execute syscalls like read/write/exit. A VM in the contemporary sense has the exact same functionality, with a different interface. Rather than read/write as syscalls, you have to send SATA commands to disk, or commands to a network card, or whatever. Instead of an exit system call as an interface you work with a hardware interface that powers down the physical machine.
Containerization is actually a logical next step from this. Why virtualize a REAL hardware interface only to virtualize a fake one on top of it? The only reason to do that is if you want multiple fake interfaces, eg Linux and Windows. When virtualizing a bunch of Linux machines, mostly you really just want isolation of your processes. Virtualizing real hardware is a hack because Linux was not capable of isolating processes on its own, so you had to run multiple copies of Linux! Now with cgroups and other resource namespacing in the kernel, it can isolate resources by itself.
This has already been done, so you are obviously wrong.
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect.
Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has detailed descriptions of its possible throws, you won't get devs to read all the documentation for every function in some piece of code that needs a small fix.
The only thing that is substantially different between any of these is the engine/protocol/adapter/whatever section. Perhaps that field should always refer to the protocol type and not the driver, but I consider that problem pretty negligible.
The author also addresses the importance of history. Voodoo knowledge _does_ pervade modern computer science, and I for one am happy to see something different.
Now, on my Mac, I do exactly zero multimedia related things. So I agree that the multimedia thing isn't necessarily true, but that's what I hear about Macs from not-technicals.
"Poe's law, named after its author Nathan Poe, is an Internet adage reflecting the idea that without a clear indication of the author's intent, it is difficult or impossible to tell the difference between an expression of sincere extremism and a parody of extremism."
Edit: excerpt
Can't we all just agree that Google is pretty great, but going through an annoying phase right now? Google _is_ taking advantage of the fact that most users won't leave, and I don't appreciate that. But at the same time, we are all slowly losing our patience, and in the long run this behaviour could hurt Google. I hope for everyone's sakes that this all settles down.
> From the development perspective Postgres was a necessity. Not a slam dunk but objectively a better tool for our use case.
In what way?
> And if we have countless reasons, all good, but they’re nuanced and technical and tricky to impart to a non-technical audience, where does that leave us?
HN would be interested in those reasons, I know I am.
> The vast majority of the company probably still doesn’t get why we went through this painful contortion at the expense of doing, well, a lot of other things.
Neither do I, since none are given.
Though I also understand that the point of the post was about trust. It's great that there is that trust within SparkFun, I would love such an environment.
Brain... brain stahp...
I also think a lot of people like rails because they find ruby extraordinarily beautiful. As much as I like JS, beautiful syntax is not its strong suit.
Distrokid also does multiple services in one go.
A person who just knows it's "bad code"--but not why--is almost certainly going to leave other bad code from lack of understanding. To pull an example from the slides, the virtual destructor: making that class virtual when it shouldn't is a waste of CPU cycles _and_ bad documentation for future developers.
If this works, people all over Russia will likely try stuff like this. Banks will have to check every contract with every customer ridiculously carefully until they can roll out a global solution. While fine print is sub-optimal and irritating, forced mass reform has serious short-term repercussions.
I would imagine the rule is not used extensively in practice because it exists as a preventive measure should such a thing ever come up.
#include <Python.h>
int main() {
Py_Initialize();
PyImport_ImportModule("necromancy"); greaterThan(100, 5);
//=> true
That is, l is greater than r, and to then properly curry the arguments do need to be flipped such that maybeGT(5) results in a function that returns whether the argument is greater than 5. function double(n) { return 2*n; }
map(double, [1,2,3])
//=> [1, 4, 9]
should be => [2, 4, 6] function greaterThan(l, r) {
return l > r;
}
greaterThan(5, 100);
//=> true
should be => false maybeGT(5)(10000000);
//=> false
Based on your earlier declaration of greaterThan this result is actually correct. The curried application ordering is also correct and flip is unneeded. schonfinkel(function(a1,a2) {return [a1,a2];})(1)(2);
//=> [1, 2]
I would proofread the rest but I am about to be late for class! =OEdit: since i'm going to complain I might as well say something nice as well. I did like this article example correctness aside, and I hadn't seen that implementation of pipeline before! Much awesome. =)