Are you making a counterpoint to the author's premise that smart glasses are an "intolerable intrusion?"
I'm having trouble understanding the purpose of your comment since it seems like you're just saying the ray ban glasses are bad for a different reason.
Not the original commenter, but I have faced similar friction from people who are not grandmas or quarterbacks. I don't particularly agree with its tone, but I agree with the original commenter's general message.
I won't be so confident to identify what it is, but there is something that causes "end users" to bristle at Zulip.
Where I'm coming from, everyone uses Slack. I spearheaded an effort to switch to Zulip because our Slack server is on a free plan and our messages get sucked into the void after 60 days now. Everyone agrees that this is bad, and that we don't have the money for Slack premium (we're an academic organization, so AFAICT we wouldn't even have to self-host to avoid paying), and yet so many people do not want to switch. Here are some common responses I've gotten:
* I refuse to use another messaging app and Slack is nonnegotiable for some of my collaborators.
* I don't want to learn a new UI.
* I don't want to learn a new UI that isn't basically the same as Slack.
* I will only switch if everyone else switches.
This is half a social problem ("I will only be receptive if everyone is using this"), but I do think there is some legitimate friction in Zulip's UI. I am fairly confident that we could successfully switch to Zulip if the Slack dissenters could be convinced to use Zulip --- or if Zulip could somehow be coerced into being more Slack-like.
As the "agent of change" at my organization, I felt like the resources Zulip provides are lacking in what I really need. Like I know there are technical details on how to move to Slack (https://zulip.com/help/moving-from-slack), but what I really need is help with the above: convincing people to try and acclimate to the UI. And yeah, I kind of agree that a 2 minute video on how to use Zulip is not the resource I need since it presupposes a degree of openness and cooperation that I don't have access to.
These are somewhat disorganized thoughts, but happy to expand upon anything if you're interested. I really do want to successfully move our org to Zulip since I'm tired of our messages disappearing.
Cool stuff! I'm not as lucky to be surrounded by (affordable) fresh, seasonal produce, but I'll keep your seasonality tip in mind. We do have farmers' markets where I am, although their prices are unfortunately at a bit of a premium. Maybe I'll just buy some quantity of whatever's freshest one of these days and try to improvise as you do.
LMK if there's a mailing list or something I can get on for your mom's book!
> adopting instead, the diet of my great grandparents: Plants; local, seasonal and whole.
I saw some mention of the same on the website for the farm. Care to share any recipes? Or even just names of dishes? I quite enjoy foods from the Mediterranean and I'm interested in trying more!
I don't really see there being much of a difference between the modeling surprises and last-minute surprises only uncovered when the program runs. If the gist of what you're saying is that an experienced proof engineer should have fewer modeling surprises than an experience software engineer has last-minute code execution surprises, then I can sort of agree. But the "contours" of a proof you're describing are basically analogous to decomposing an application into individual components (modules/functions) --- and if you do this and test your components you should expect your software to not have any "last minute surprises" except for modeling failures as well.
I guess the point I mostly disagree with is the feasibility of what you describe here:
> In particular, if you get definitions right and if your plan actually makes sense mathematically (i.e. the proof is possible using your planned breakdown), you have a much more linear sense of progress.
This presupposes that you know how the proof should be written, which means that you not only have an understanding of the proof mathematically (whatever your definition of "mathematically" is), but you ALSO know how to warp that understanding into a machine proof. The author notes that the "getting the definitions right" part is slower than them writing out the definitions themselves for a variety of reasons which ultimately mean they had to carefully comb through the definitions to make sure there were no logic errors.
So I don't really disagree with your overall point (which is that the author can probably be trusted to say they are actually at 50%), but I think you oversell the assurances granted by formal verification when compared to software engineering.
> ... enough professional musicians use it as that I think I have to consider it that as well.
While not a bad proxy, I would say it is a sufficient but not necessary condition. Especially since many pros have the money to blow on overpriced gear (but perhaps you do too).
My own anecdote: as a kid I wanted to learn electric guitar and, of course being a kid, I shopped with my eyes. My dad bought me a $1.2k guitar. It's still a respectable guitar to this day, don't get me wrong. But if he had instead taken the old electric in the garage (bought for probably $500) and spent a hundred bucks on getting it set up, I would've had a guitar just as good. I know because I dug it out recently and I actually think it is quite nice.
Not to defend Teenage Engineering, but I have seen a surprising number of OP-1s in music videos/live performances of bands I respect. Does that justify its price tag? I feel somewhat certain in saying "no," but I have no expertise. Love its aesthetics though.
I heard Woz give a talk (or Q&A?) at a conference and it was very enjoyable, even for someone who doesn't know much about Apple's history.
If we are to believe his word about not selling out, then I must assume that https://www.efforce.io/company also brings him more smiles than frowns. I suppose if you change the definition of "sell out" you can conventionally sell out without meeting your own definition. That said, I am reluctantly open to being shown evidence that the company isn't a grift.
The constant use of metaphor and simile drove me crazy. I had suspected this might be AI due to the frequency as well as absurdity of some of the comparisons (Talmudic scholars? Renaissance cardinals??) but humans also write dumb things like this that make them feel smart more than they serve rhetorical purpose. Or so I think.
I mean just look at this. I didn't even need to look through more than a few paragraphs to find:
> But the subscription traps are where the real extraction occurs—and here we encounter the kind of business model innovation that would make a mobster tip his hat in professional admiration. Customers complain of being locked into year-long commitments they can't escape, like hotel California but with erectile dysfunction pills. Better Business Bureau complaints reveal the pattern with the reliability of a Swiss timepiece: ... Picture ordering a 3-month hair loss kit only to find Hims has shipped and charged for a fourth without consent, like a pharmaceutical version of that friend who keeps ordering shots when you've already said you're driving.
BTW, where's the referral URL you speak of? I didn't realize there was a smoking gun.
Then I misunderstood your comment. I read it as "not invested in their tools => not a good programmer."
Reading the replies to my sibling comments, I don't think we really disagree but we probably have different pictures in our heads when reading the context of this thread.
That's kind of a weird point to make. I don't see why it would be a universal truth that a good programmer is someone who invests in their tools.
I could just as easily say that good programmers are the ones who don't have sophisticated tooling setups because it means that they spend more time programming.
I'm inclined to agree with other comments that the baseline for productivity is probably lower than we think. It's fine to enjoy the process of making a perfect setup, but I don't see it as a prerequisite or strong indicator for being a strong programmer.
I wouldn't be too surprised if PL proofs were simpler to start with. Part of what I hear people say is that they also are a lot more routine. Do structural induction, apply the IH to show an invariant holds, continue. I haven't done much theorem proving, nor have I done any "mathematical" (e.g. analysis) proofs with a theorem prover, but it makes me wonder how much skill transfer there is between them if "mathematical" proofs require a much different approach.
I will also mention Software Foundations in Rocq (perhaps there is a Lean port). I worked through some of the first parts of it and found it quite pleasant.
It's a weird coincidence to see this post since I only occasionally remember about Hook Theory and binge it, but I remembered earlier this week.
Many of you have probably heard the Axis of Awesome four chords song (if not, look it up, it's great), but it's fun doing the same thing with other songs.
Like, did you know that you can sing the chorus of Numb by Linkin Park over the chorus of...
* I Hate Everything About You by Three Days Grace
* Immortals by Fallout Boy
* Cheap Thrills by Sia (swung Numb lol)
(+ the bridge of The Rock Show by Blink 182)
Numb has a pretty common chord progression so I could pick songs with the exact same chords, but there are also some oddly specific finds like this video game (?) song that inexplicably has the same relative chord progression as Hotel California https://www.hooktheory.com/theorytab/view/zun/reincarnation#...
However when you put that query into the normal search box, it does match a lot more songs, showing that there is a i III _ VII trend, just that i III vi VII is strange (which I guess makes sense). Perhaps my lack of music theory makes it harder to normalize my queries, but it's also possible that (1) there isn't enough data or (2) there is inconsistency in how people annotate the pieces (some songs will have II II II II, for example, following the rhythm, whereas some songs will have just a single II).
Another happy doom user (and formerly unhappy vim configure-er).
Although the objection I see is more like "Why bother learning to use emacs/vim when VSCode is free and does everything I care about and my friends use it?" Which, to be fair, the emacs/vim learning curve isn't for everyone. I sometimes wish they had less "leet programmer" cred, though, since what is cred to the leet programmer is (in this case at least) stigma to the majority.
I'm having trouble understanding the purpose of your comment since it seems like you're just saying the ray ban glasses are bad for a different reason.