> 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!
Sure! My mother is preparing a book detailing recipes, ingredients, foraging,
how to eat, when to eat and so on which will be released this year. Basically,
we follow the seasons and there are 4-5 "dishes" each season with some overlap.
The "dishes" are templates filled in with whatever is available at the time.
For instance, when chestnuts are in season they enter soups, casseroles, roasts,
salads and on their own drizzled with olive oil and salt. When they finish,
something else is in season and the dishes change again.
There's a very brief period of overlap where the staple summer vegetables
(tomatoes, eggplants, peppers, zucchini) and chestnuts are available at the
same time. These vegetables stuffed with a mix of brown rice and chestnuts and
baked in the oven is heavenly.
Instead of thinking about recipes and then obtaining ingredients to make them,
start with the ingredients and make it up as you go. Things that are in season
together typically go together. We base everything on olive oil, alliums, some
sort of legume or grain and seasonal greens, nuts, fruits and vegetables.
My great grandparents didn't follow recipes per se. When they made a soup they
used what they had and due to lack of refrigeration and ultra-processing
everything they ate was local, seasonal and fresh.
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!
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.
It’s not necessarily smooth sailing for sure. But in my (limited!) experience, there is a noticeable difference, so that’s what I wanted to note.
There indeed can be a gap between “it works in my head” and convincing the machine to do it, and sometimes the gap is wide. For example, type-theoretic way of looking a things (as customary in Lean) might not match the idioms in the paper proof, or some crucial lemmas known to be true might have never been formalized. Or the tactics to prove some piece are getting too slow. Or you got the definitions wrong or they’re annoying to deal with. So that is its own set of difficulties.
Even with that, the nature of difficulties feels different from much of software work to me. In software, I find that “divide and conquer” rarely works and I need to “grow” the program from a primitive version to a more sophisticated one. But in proofs, “divide and conquer” actually sort of works — you gain some assurances from making a high-level proof with holes in the middle, then filling in those holes with more intermediate steps, and so on. You can actually work “top down” to a meaningful extent more than in software.
To put it another way, with proofs, you can work top-down and bottom-up at the same time, making real progress while a bunch of steps are stubbed out. In programming, “stubbing out” non-trivial parts of the program is often annoying or impossible, and you can only make progress on a smaller (but complete) piece of it, or a less ambitious (but still complete) piece of it. This is because you can’t run an incomplete program, and there’s a set of knowledge you only gain from running it. But you absolutely can check an incomplete proof, with arbitrary granularity of incompleteness.
So I agree with you it’s not necessarily linear. But it’s also not exactly like software, and analogies from software work don’t apply 1:1.
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.
The OP1 is a genius piece of design tbh. It is very flexible and powerful for its small size, and devices in its category were very rare when it first came out (it helped define the modern incarnation of that category).
It was pricy but still under the $1k mark - pretty standard for a piece of consumer creative gear.
The design made it extremely approachable, which means a ton of techie people who wouldn't be into music gear otherwise still wanted to grab one just to try it and who knows, maybe it'd turn them into musicians.
So yeah, fantastically designed piece of kit. Lots of respect to TE for having brought that into the world.
I think a lot of the frustration directed at TE more recently is due to the fact that that base equation around price/features/quality of the product, which was very good for the OP1, has only gotten worse for later products.
And the OP1 itself, despite being an almost 15 year old product, has gone up in price A LOT (and the 1f upgrades don't justify the bump).
I fell in love with the OP1 when I first saw it many many years ago. A few years back I took some of my bonus and finally got one, despite the price being a little higher than launch (I want to say maybe $1500?).
It’s an amazing little piece of gear and is super fun - it’s definitely not for everyone, and requires a different approach to music making that (for me) focuses less on the functional, reproducible aspect, and more on an ephemeral journey that might end in a new track or might just be a jam, but I hardly ever fire it up and walk way not having a good time.
Currently have it wired to a Deluge and a POM-400, and mostly I send some MIDI notes to the OP1 for some added depth. But the synth engine feels so rich and powerful for such a little bugger!
10/10 would recommend and also there’s probably a lot more bang for your musical buck out there (cough couch Deluge)
It's not particularly expensive for professional music gear, which enough professional musicians use it as that I think I have to consider it that as well. Whatever else teenage engineering sells I don't really have an opinion about but that thing gets serious use by serious professionals so I feel obligated to take it seriously. Compared to a nord piano or a cello or a rhodes or a stage mixer or whatever it's not among the most expensive pieces of gear you will routinely see on a stage.
> ... 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.
Well the entirety of my music gear is a 1994 p-bass and a mediocre amp I've been running it through since around the same time so I get it.
And yeah a musician friend of mine we have a running joke where we'll say something is "a software engineer pedal." Meaning you see them in the home studios of people who make good money doing something else, while working musicians get by with the nearest Boss equivalent.
I've never used an OP-1, wouldn't know how to use one or evaluate it. But I've been on stage with enough of them to get the sense that, if used fully, they can for some approaches to some styles of music, fill the role of several other pieces of gear that would each cost more than what it costs.
So I think this one is both. It's a software engineer's toy, and it's also a workhorse tool for professionals. Honestly an impressive achievement, not a lot of things end up being both in any discipline.
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.
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 don't see why it would be a universal truth that a good programmer is someone who invests in their tools.
I have never said that. However, since you decided to go that direction. I can bite and entertain you. Here is a list of programmers, some of them I'm sure you'd even recognize. Donald Knuth, Rob Pike, Ken Thompson, Steve Yegge, Gary Bernhardt, Paul Graham, Rich Hickey, Bram Moolenaar, Richard Stallman, Anders Hejlsberg, Guido van Rossum, John Carmack, Tim Pope, Drew Neil, Sindre Sorhus, TJ Holowaychuk, Guillermo Rauch, Ryan Dahl, Fabrice Bellard.
The pattern is clear: many of the best programmers are also prolific tool-builders.
I don't even understand what point you are making. The essence of programming is tool making. Of course the best programmers make tools as do the worst. Are you seriously comparing making a terminal hot rod configuration app to, say, creating Tex?
> Being a programmer is not about configuring your development environment.
My point is that being a programmer is also about configuring one's development environment. Exactly because like you said: "the essence of programming is tool making". I just don't understand how it is different - configuring a tool, extending its functionality, adding more features to it from developing a [different] tool from scratch? Both is programming. Shit done by programmers. You don't call one bunch "pseudo-programmers" and the other "alpha-programmers" or some shit like that, right?
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.
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.
Kevin Buzzard said something like the PL proofs are about deep structures on simple objects (mostly integers), while modern math mainly concerns complex objects. If you already have the definitions, the properties usually don't involve a lot of recursion and case analyses.
Those who recall cars with fm radios and gsm phones will have heard something similar if their car had a random compartment right below the stereo.
When a call came in, before the phone would ring, the radio would emit this very clear tri di di dit dah dah. But only when the phone was very near the radio.
Yes kinda, I would say network activity rather then traffic. Audio signal is going to be in scale of 48Khz while measuring ethernet signal at scale of 100Mhz. At that rate it wouldn't even get more then 1 sample from a full size packet. So really it's polling 48Khz whether or not there was activity during that period. The gimmick is that it uses some analog components. Fully digital you could craft a meaningful audio signal that represents traffic.
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!