Whoah, that interpretation seems pretty wild to me. They put a lot of effort into building a pizza oven and someone else tore it down, and they should feel nothing about this?! If an artist sells their painting they shouldn't care if the new owner paints over a section?
Beyond the sentimental attachment to the pizza oven, I'd be bothered by the sheer inefficiency of it.
Reminds me of the tale of the guy who was told by his realtor that he could put $20k in new windows and sell the house for $50k more. He did and it sold, and was immediately torn down.
Been renovating an old house with a large garden for almost ten years now. I tell myself this is better than building something from scratch, but it definitely doesn't always feel more efficient. It helps that I didn't have the option back then, but now maybe I do? Sometimes it's also hard to tell, in the moment, which things to keep and what to rip out.
https://mgsloan.com - 11 posts about unorthodox computer ergonomics. 6 posts about Haskell ideas / weird tricks. Haven't posted in a couple years but would like to get back to it. Notable HN discussions:
Same path for me, I like the v-moda headphones a lot, but the hinge mechanism is way too fragile, and the charge port broke, so the bluetooth pair was my last v-moda headphone. I also switched to beyerdynamic and have been very happy with them. Only downside of this durability is that they are not foldable - would be great to have headphones with a high durability folding mechanism
I love this concept! When I got tired of replacing headphones in the past I got some beyerdynamic dt770 modded by jfunk.org. They are repairable and durable. Though they are not natively bluetooth, can use a short cable + qudelix 5k to make them wireless. No noise cancelling.
Would be very nice to have durable / repairable noise cancelling headphones. These headphones from fairbuds look great overall, but I'm skeptical of the durability of the hinges.
In my experience with languages that lack concise sum types and pattern matching, you end up with data types that have lots of implicit invariants. If you find yourself writing docs or thinking in your head things like "Field X is only set if field Y is true" or "If field X is non-null then field Y must be null and vice-versa", then these are indications that sum types would model the data better. Then these invariants can be followed by construction, and it becomes clear what's available at data access - great for interface clarity, robustness, dev tools, morale, etc.
Relatedly, storing booleans is a smell, imho typically an enum or sum type is always better in languages that have concise syntax for these. True and False are meaningless without context, and so can easily lead to errors where they are provided to a different context or generally misused due to a misunderstanding about the meaning.
> if your type-system is sufficently strong to express this
No fanciness needed, just plain old sum types. It is certainly possible to express those invariants directly in languages with a dependent type systems or refinement types like in liquid haskell - see https://ucsd-progsys.github.io/liquidhaskell-tutorial/Tutori.... It's typically much easier to reason about and use sum types, though.
Of course these examples are trivial and silly, but I see instances of these patterns all the time in big co software, and of course usually the invariants are far more complex but many could be expressed via sum types. I've seen loads of bugs from constructing data that invalidates assumptions made elsewhere that could have been prevented by sum types, as well as lots of confusion among engineers about which states some data can have.
> Field X is only set if field Y is true
Original gnarly C style pattern:
struct TurboEncabulatorConfig {
// When true, the turbo-encabulator must reticulate splines, and 'splines'
// must be non-null. When false, 'splines' must be null.
bool reticulate_splines;
struct Splines *splines;
};
> If field X is non-null then field Y must be null and vice-versa.
Original gnarly C style pattern:
struct TurboEncabulatorConfig {
// When non-null, lunar_waneshaft must be null.
struct Fan *pentametric_fan;
// When non-null, pentametric_fan must be null.
struct Shaft *lunar_waneshaft;
};
Type systems are of course not the only possible mechanism that can enforce these kinds of invariants. In dynamic languages, schema style solutions (eg malli or spec in Clojure) have advantages: they have more expressivity than typical type systems, you can manipulate them as data, you can use in contexts that are not statically verifiable, like at the data interfaces of yuor app.
I agree it has more flexibility, but more expressiveness is a double edged sword. Type systems are often not Turing-complete, or at least they are limited in some ways. A language being very expressive means it cannot be run at compile time, sine we cannot know if it terminates.
If we cannot run it at runtime now we need tests to hit that path or to test it manually to actually know if it works.
One idea I really like for avoiding VCS operation anxiety for beginners and experts alike is a filesystem layer that allows revert to any historical state. You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so. Unfortunately I do not know of a nicely packaged way to do this, or how to do it at all with OSS tools (but I bet it is feasible!).
> You just have your bash prompt output the current snapshot number, and then can use that as the revert target if there's a botched rebase or so.
That is what the ref-log is designed to do, but in my experience with git the risk is not about getting historical content, because git is very good about that: it's the current operation that's the risk
If I had any advice for beginners, it'd be to commit early and often, because git is disciplined about managing commits, but is a razor blade about anything in the working copy. There is no ref-log for "but I just typed that..." unless you told git to save it in something with a sha
Yeah, but ref-log is scary to beginners (I suppose rebase is too!). Rebase was a poor example, but even so, it is way easier to copy a snapshot number out of your cli and restore than it is to dig through your reflog for the right sha
ref-log doesn't save you in so many situations. As you point out, you have to commit all the time for it to save you. Even then, git repo corruption is possible and then you are hosed.
For example:
* a hard reset clears your working copy changes
* you pop a stash you didn't mean to, atop your working copy changes. Now your working copy changes are intermixed with the stash and you have to manually decouple them.
* you accidentally stage hunks to your index and its tricky to unstage them because they are adjacent to other hunks
Such a tool also saves you from accidentally saving over your work in the text editor. It generally makes it so that you don't need to be as careful.
So, generally, git commands that affect your working copy are not undo-able and can be very time consuming to undo if you have no proper time machine underneath your repo. I happily have experienced the bliss of having this reassurance, but it is only within a proprietary env.
I've had VCS operation anxiety since the days of CVS. With Subversion it was largely a non-issue but Git made it return with a vengeance. This tool will presumably calm my frayed nerves.
If your fs already supports snapshots/versioning it might be convenient, but it doesn't solve the actual hard part which generally comes after changes have been merged upstream.
If we're only concerned with local changes I'd rather introduce beginners to `reset`, experts will already be doing something similar dependent on circumstance.
git reset --hard
git tag BEFORE
git reset --hard BEFORE
git reset --hard ORIG_HEAD
git reflog
git reset --hard HEAD@{<N>}
For a while I had a misting setup during the summer, at my deck desk. I didn't have any trouble with electronics. These days I'm in Colorado which tends to be relatively dry.
Beyond the sentimental attachment to the pizza oven, I'd be bothered by the sheer inefficiency of it.