That extension doesn't follow. It is possible to verify if software works without knowing how it works internally. This is true with many things. You don't need to know how a plane/car/elevator works to know that it works when you use it.
I would actually argue that only a small percentage of programmers know what happens in code on an instruction level, and near none on a micro-op or register level. Vibe-coding is just one more level of abstraction. The new "code" are the instructions to your LLM.
> You don't need to know how a plane/car/elevator works to know that it works when you use it.
I'm sure the 737 MAX seemed to work just fine to Boeing's test pilots. Observing the external behavior of a system is not a substitute for understanding its internal workings and the failure modes they carry.
[put my hand up]. I recently had to/wanted to convert my lecture slides from latex-beamer/lyx into html/reveal.js. I did a couple of slides per hand, and then asked AI to convert the rest, following my example. Saved me hours of tedious and boring work.
I think it's a trick. It seems to be the article is just a series of ad-hoc assumptions and hypotheses without any support. The language aims to hide this, and makes you think about the language instead of its contents. Which is logically unsound: In a sharp peak, micro optimizations would give you a clearer signal where the optimum lies since the gradient is steeper.
> In a sharp peak, micro optimizations would give you a clearer signal where the optimum lies since the gradient is steeper.
I would refuse to even engage with the piece on this level, since it lends credibility to the idea that the creative process is even remotely related to or analogous to gradient descent.
I wouldn't jump to call it a trick, but I agree, the author sacrificed too much clarity in a try for efficiency.
The author set up an interesting analogy but failed to explore where it breaks down or how all the relationships work in the model.
My inference about the author's meaning was such: In a sharp peak, searching for useful moves is harder because you have fewer acceptable options as you approach the peak.
Fewer absolute or relative? If you scale down your search space... This only makes some kind of sense if your step size is fixed. While I agree with another poster that a reduction of a creative process to gradient descent is not wise, the article also misses the point what makes such a gradient descent hard -- it's not sharp peaks, it's the flat area around them -- and the presence of local minima.
I see your point. I'd meant relatively fewer progressive options compared to an absolute and unchanging number of total options.
But that's not what the author's analogy would imply.
Still, I think you're saying the author is deducing the creative process as a kind of gradient descent, whereas my reading was the author was trying to abductively explore an analogy.
True, but my point is that not only does the analogy not work, the author also doesn't understand the thing he makes the analogy with, or at least explores the thought so shoddily that it makes no sense.
It's somewhat like saying cars are faster than motorbikes because they have more wheels-- it's like with horses and humans, horses have four legs and because of that are faster than humans with two legs. It's wrong on both sides of the analogy.
I think you’re after something other than immutability then.
You’re allowed to rebind a var defined within a loop, it doesn’t mean that you can’t hang on to the old value if you need to.
With mutability, you actively can’t hang on to the old value, it’ll change under your feet.
Maybe it makes more sense if you think about it like tail recursion: you call a function and do some calculations, and then you call the same function again, but with new args.
This is allowed, and not the same as hammering a variable in place.
for (0..5) |i| {
i = i + 1;
std.debug.print("foo {}\n", .{i});
}
In this loop in Zig, the reassignment to i fails, because i is a constant. However, i is a new constant bound to a different value each iteration.
To potentially make it clearer that this is not mutation of a constant between iterations, technically &i could change between iterations, and the program would still be correct. This is not true with a c-style for loop using explicit mutation.
I argue in your example there are 6 constants, not 1 constant with 6 different values, though this could be semantics ie we could both be right in some way
Even if it was better than lima (and the builtin posix/unix environment), which: it ain’t, it doesn’t nearly make a dent in the mandatory online account, copilot shit and all the rest.
If you like Windows, you’ll find it better with WSL2. In fact, I see many developers at my org who claim they’ll switch to Windows (from Mac) when we make it available internally.
However, if you love Mac, you'll never find Windows palpable no matter what.
You may like Windows better, but WSL2 is just a virtual machine with all the downsides (slower, no docker) that brings . In fact, on my windows PC I still use WSL1 for that reason.
The voltage is always going to be the same because the voltage is determined by the transformers leading to your service panel. The breakers break when you hit a certain amperage for a certain amount of time, so by installing a bigger breaker, you allow more amperage.
If you actually had an electrician do it, I doubt they would've installed a breaker if they thought the wiring wasn't sufficient. Truth is that you can indeed get away with a 20A circuit on 14 AWG wire if the run is short enough, though 12 AWG is recommended. The reason for this is voltage drop; the thinner gauge wire has more resistance, which causes more heat and voltage drop across the wire over the length of it, which can cause a fire if it gets sufficiently hot. I'm not sure how much risk you would put yourself in if you were out-of-spec a bit, but I wouldn't chance it personally.
You can, 240V on normal 12/2 Romex is fine. The neutral needs to be "re-labeled" with tape at all junctions to signify that it's hot, and then this practice is (generally) even code compliant.
However! This strategy only works if the outlet was the only one on the circuit, and _that_ isn't particularly common.
Although this exists, as a layperson, I've rarely seen it. There is the NEMA 6-15R receptacle type, but I have literally none of those in my entire house, and I've really never seen them. Apparently they're sometimes used for air conditioners. Aside from the very common 5-15R, I see 5-20R (especially in businesses/hospitals), and 14-30R/14-50R for ranges and dryers. (I have one for my range, but here in the midwest electric dryers and ranges aren't as common, so you don't always come across these here. We have LNG ran to most properties.) So basically, I just really don't see a whole lot of NEMA 6 receptacles. The NEMA 14 receptacles, though, require both hots and the neutral, so in a typical U.S. service panel it requires a special breaker and to take up two slots, so definitely not as simple of a retrofit.
(Another outlet type I've seen: I saw a NEMA 7 277V receptacle before. I think you get this from one phase of a 480V three-phase system, which I understand is ran to many businesses.)
If you drive an electric car in a rural area you might want to carry around 6-30 and 6-50 adapters because most farms have welders plugged into those and that can give you a quick charge. And also TT-30 and 14-50 adapters to plug in at campgrounds.
NEMA 6 is limiting because there’s no neutral, so everything in the device has to run on 240V. Your oven and dryer want 120V to run lights and electronics, so they use a 14 (or 10 for older installs) which lets them get 120V between a hot and the neutral.
Oddly, 14-50 has become the most common receptacle for non-hardwired EV charging, which is rather wasteful since EV charging doesn’t need the neutral at all. 6-50 would make more sense there.
Reasons why it's nice to have a 14-50 plug in your garage rather than a 6-50:
1: when an uncle stops by for a visit with his RV he can plug in.
2: the other outlets in your garage are likely on a shared circuit. The 14-50 is dedicated, so with a 14-50 to 5-15 adapter you can more safely plug in a high wattage appliance, like a space heater.
1 is why we ended up with 14-50 as the standard, too. Before there was much charging infrastructure, RV parks were a good place to get a semi-fast charge, and that meant a charger with a 14-50 plug.
2 is something I never thought of, I’ll have to keep that in mind.
NEMA 6s are extremely common in barns and garages for welders. 6-50 is more common for bigger welders but I’ve also seen 6-20s on repurposed 12/2 Romex as the parent post was discussing used for cheap EV retrofits, compressors, and welders.
It's niche /for development work/. Being used by a developer doesn't make it used for development. Or the most used developing tool would be the toilet.
It's not. I use vim on a daily basis, but all I do with it is writing commit messages. The rest I do with an IDE or different editor. I'm surely not alone with that.
Even I switch to VSCodium when I write Go, for example, because the Go extension is just so good. I use it for medium- and large-sized projects, when I have to navigate through multiple files. There are ways to do it in Vim (I configured it), and Emacs, but sometimes it really is just easier to click since I am already using the mouse for stuff. There are people who never use their mouse, in which case I can imagine they use Emacs or Vim only.
Unfortunately, very true. I think Canada ranks last in the G7 on GDP-percentage science funding. Salaries seem to be OKish, maybe similar to Germany, but cost of living (mainly housing, food is comparable cheap) in Vancouver and Toronto is very high.
UK salaries are atrociously bad. Not sure about funding, but it doesn't seem to be great.
I would actually argue that only a small percentage of programmers know what happens in code on an instruction level, and near none on a micro-op or register level. Vibe-coding is just one more level of abstraction. The new "code" are the instructions to your LLM.
reply