> Lightning Fast. Local processing means instant results without internet dependency or delays.
> Always Available. Works offline, on flights, in coffee shops, anywhere you write.
Two of your 4 questions were answered in the first content block
This pseudocode is "Validate" for at least 3 reasons:
Forgetting to check:
this check is fragile: it’s extremely easy to forget. Because its return value is unused, it can always be omitted, and the code that needs it would still typecheck.
Repeatable/redundant checks:
First, it’s just annoying. We already checked that the list is non-empty, why do we have to clutter our code with another redundant check?
Second, it has a potential performance cost. Although the cost of the redundant check is trivial in this particular example, one could imagine a more complex scenario where the redundant checks could add up, such as if they were happening in a tight loop.
Not using the type system:
Use a data structure that makes illegal states unrepresentable. Model your data using the most precise data structure you reasonably can. If ruling out a particular possibility is too hard using the encoding you are currently using, consider alternate encodings that can express the property you care about more easily. Don’t be afraid to refactor.
> How do you know PARSE_ERROR is not email_t
It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead.
This is validate, not parse.
> It has to be for it to compile, right? Which means that email_t is the type which represents both valid and invalid emails. How do you know if it's valid? You remember to write a check for it. Why not just save yourself some keystrokes and use char* instead. This is validate, not parse.
I feel this kind of fundamentalism is letting the perfect be the enemy of the good.
Every C programmer is already doing it the 'good' way (validation), so this article doesn't really add anything.
The only fundamentalism involved in PdV is: if you have an email, it's actually an email. It's not arbitrary data that may or may not an email.
Maybe you want your emailing methods to accept both emails and not-emails in your code base. Then it's up to each method to validate it before working on it. That is precisely what PdV warns against.
There's a huge difference. One is an email_t to validate and one is a char* to validate.
As established, head is partial because there is no element to return if the list is empty: we’ve made a promise we cannot possibly fulfill. Fortunately, there’s an easy solution to that dilemma: we can weaken our promise. Since we cannot guarantee the caller an element of the list, we’ll have to practice a little expectation management: we’ll do our best return an element if we can, but we reserve the right to return nothing at all. In Haskell, we express this possibility using the Maybe type
^ Weaken the post-condition. In some contexts null might be close enough for Maybe. But is Maybe itself even good enough?
Returning Maybe is undoubtably convenient when we’re implementing head. However, it becomes significantly less convenient when we want to actually use it! Since head always has the potential to return Nothing, the burden falls upon its callers to handle that possibility, and sometimes that passing of the buck can be incredibly frustrating.
This is where the article falls short. It might be good (the enemy of perfect), but it ain't PdV.
Another example was High Sierra. They completely swapped out the file system on that release, focusing primarily on under-the-hood changes, and imo was also one of the most stable macOS releases to date.
Jeans were almost invented for this kind of thing. I'll always cringe at the idea of wearing them wet though—
"Looking to provide its sailors with durable clothing that could be worn wet or dry, the navy began in the 16th century to equip sailors with Genoese-produced denim jeans, and in doing so became one of the driving forces behind the adoption of the clothing" https://en.wikipedia.org/wiki/Genoese_navy
Flawless, it's really easy to wrap your head around (especially if you grok Go).
I would recommend spinning up the most basic site from scratch to give it a try, takes minutes tops and its got a built in dev server to see your site.
It pretty much all rapidly clicked into place from there. The idea of adding content as markdown is so easy and appealing, and the flow is so logical. The build times make me smile. Everything feels so rapid and under my control.
Mac isn’t really BSD, it’s a common misconception. It shares some of the userland code, but it’s a vastly different kernel (derived from the Mach microkernel). The userland has diverged quite significantly now too. Though, I guess it probably is closer to BSD than Linux
Mac OS X was essentially a continuation of NeXTSTEP, which is BSD with a new novel kernel. In fact, if you look into the research history of the Mach kernel at the core of XNU, it was intended as a novel kernel _for_ BSD. NeXT went and hired one of the key people behind Mach (Avie Tevanian), and he became one of the core systems guy that designed NeXTSTEP as a full OS around Mach.
Early in the proliferation of the Unix family, member systems went in one of two directions -- they based their OS on upstream AT&T Unix, or they based it on Berkley's BSD, and added their own features on top. NeXT was one of the latter. Famously, the original SunOS also was.
While Sun would eventually work closely with AT&T to unify their codebase with upstream, NeXT made no such change. NeXTSTEP stayed BSD-based.
The other extant BSDs like FreeBSD and NetBSD were also based directly on the original BSD code, through 386BSD.
If I have my history correct, Apple would later bring in code improvements from both NetBSD and FreeBSD, including some kernel code, and newer parts of the FreeBSD userland, to replace their older NeXT userland which was based on now-outdated 4.3BSD code. I think this is where the confusion comes in. People assume MacOS is a only "technically" a Unix by way of having borrowed some code from NetBSD and FreeBSD. They don't realize that it's fully and truly a BSD and Unix by way of having been built from NeXT and tracing its lineage directly through the original Berkeley Software Distribution. That code they borrowed was replacing older code, also BSD-derived.
Yes, but since it was initially created I believe a lot of it has been rewritten. Eg, the filesystem. I suspect the memory system is different these days too, since macOS handles compressed memory quite differently (though not sure how that gets implemented under the hood).
FreeBSD is like a great grandparent, related but still very different.
Every extant Unix has been rewritten since the original AT&T code, Ship of Theseus style. We still consider them members of the Unix family, because they can trace their lineage directly. One could built a Git repo showing every code change from the original Unix release through modern day BSDs, if only we had granular commit info going back that far.
We could in principle do something similar for Darwin (if we had enough of the historical code), which is the core of MacOS, which is based on NeXT, which was based on BSD with a new kernel. That makes MacOS every bit as much a member of the Unix/BSD family as FreeBSD is.
No one really cares about the kernel internals, its origin or the license of it. What is prominent is the user-space components (i.e. shell and other binaries). macOS is closer to other BSDs than Linux is, as Linux usually ships with GNU libs and utilities.
You hardly notice the binaries though, especially since gnu cmd line utils are so similar anyway. You’d expect the c libs to be similar, but they’re not really (about as different as Mac to Linux anyway).
GNU utils are not similar to BSD utils. My hardest time adjusting to macOS was learning that some command line options I was so used to didn't exist or didn't work the same way.
Sure, you have ls and df, but they behave similarly only on the surface.
Excited to try this out. I recently used lit for a complex SPA (everything from routing through to page templates and smaller components). Overall I found lit just as productive as react, which was unexpected but appreciated.
The OpenBSD devs continue to outdo themselves for hw support. First Broadcom drivers, then Apple Silicon (working with the Asahi devs), now Qualcomm. Very impressive
Two of your 4 questions were answered in the first content block