d-us-vb

erase the context, perhaps? Deny access to Gemini associated with that google account? These kinds of pathological AI interactions are the buildup of weeks to months of chats usually. At the very least, AI companies the moment the chatbot issues a suicide prevention response should trigger an erasure of the stored context across all chat history.

The deadpan irony is on point. Something it seems the Norwegians have perfected.

Another one of my favorite examples of this (an ad for Oslo tourism): https://www.youtube.com/watch?v=8vhD59ac7nw

My breakfast recipe this morning, thanks to this article:

- 1/4 c. milk

- 1/2 c. flour

- 4 eggs

- 1/3 c. sugar

- some salt

- cinnamon

- cloves

- nutmeg

- poppyseeds

Did the first two cakes without baking powder, turned into something between a crepe and a tortilla. Did the last two cakes with baking powder and they were just a very squishy pancake.

As others have mentioned, SPICE is the traditional answer to that question. But SPICE feels more like a macro-assembler for circuits.

One project that comes to mind for high-level programming style circuits-as-code:

https://github.com/atopile/atopile

Show HN: https://news.ycombinator.com/item?id=39263854 More recent HN thread: https://news.ycombinator.com/item?id=44548449

Probably not much: the requirement is exact equivalence of program inputs to outputs, and as such the agents are performing very mechanical translation from the existing C++ code to Rust. Their prompts aren't "implement X browser component in rust", they're "translate this C++ code to Rust, with these extra details that you can't glean from the code itself."

Iverson's point is more regarding semantics than syntax, though. The only mention of syntax suggests its better for it to be simple (presumably so that the semantics are closer to the surface). Every programming language is a notation for describing computation; notation is a catch all for all three levels: orthography, syntax, and semantics. APL is interesting because it not only uses an unconventional syntax, but also an unconventional orthography (obligate usage of special symbols), and its semantics are different as well from most languages (array programming). Iverson's point is that APL as a notation is valuable for making the structure of certain computations obvious, and that this point generalizes across programming languages.

GingerBill's article is making a narrower claim: that semantics are what determines a good notation usually, not syntax.

Breadboard is an excellent name for this project: it tells me that I can snap preexisting components (analogous to ICs) onto a grid and make connections (analogous to wires) between them.

Context, as always, is everything. I don't think that anyone is mistaking Peter Thiel for one of the elves of Valinor.

It is never wrong to be considered untrusted. It is only occasionally right to be considered trusted. Especially in zero-risk relationships that is the default on the anonymous internet.

“can” has multiple meanings in English. It can express both epistemic (describing the world accurately as is) and dynamic (describing the capabilities and attributes of an object) modes. If used epistemically, then parent’s phraseology makes perfect sense since his epistemology makes no claim about an object’s variability across time.

It depends on the language, paradigm (or lack thereof), quality/accuracy of the names.

My work’s codebase is 30 years of never-refactored C++. It takes an exceptional amount of focus and thinking to get even a cursory understanding of anything a particular method or class does or why it’s there.

But for languages like C, I agree with you (as long as function pointers aren’t used abused).

Because codepens can run javascript. And if a page has 50 of them, it might make the page load time much longer. I know that all these examples are pure CSS, and maybe there is a setting in codepen to disable the "Run" button and automatically run it. Still, getting to decide is generally a better pattern than presuming that that's what the user wants, especially when the fact that the code is inside a codepen makes it explicitly not an integral function of the page. "I thought this was just a blog, and now you want me to run all this javascript??" -- some JS hater, probably.

I appreciate getting to choose as much as possible when code runs.

It's easy enough to interpret Peanuts as being that. But Charles Schultz was not trying to present that. He was presenting the world as it is, and how one person can still maintain his optimism in spite of all that. This is made abundantly clear in some of the other strips, like the Father's day strip where he explains to Violet that no matter what, his dad will always love him, and he doesn't care that Violet's dad can buy her all the things.

Schultz was a relatively devout Presbyterian (though still very much a free thinker and criticized the direction American Christianity was going and its attitude about the various wars during the 60s-80s). He was incredibly optimistic about humanity, but he showed in Peanuts the reality of our "default" state, especially among kids.

Keep in mind that these are all 2nd and 3rd graders in the story.

Calvin is such an interesting character. He never "learns", similar to Charlie Brown, but his outlook is that of a scientist who just wants to "see what'll happen". Anything to occupy his hyperactive mind, whether it be spaceman spiff or a trip to the Triassic, or closer to reality, pranking Susie Derkins or trying to get the better of Moe (or Hobbes for that matter). He's not optimistic, but cynical. But his cynicism is irrelevant because he's driven by his avoidance of boredom.

Today I learned that I would make a terrible detective!

When I watched Broadchurch with my family, I thought he was doing a fine job at getting to the bottom of the case. Goes to show much crime drama I watch.

I see now that Tennant's character's actions are a plot device to reveal the drama amongst the other characters, not the workings of a good detective.

Notice that I never once in this discussion claimed that it was a "good idea". This is about research and experimentation. The blog post has the title because of the Haskell documentation. Also, claiming that the lack of an argument is evidence to the contrary is argument from silence, a logical fallacy.

The good idea surrounding this isn't about treating functions as data, but maintaining the purity of the type system allowing the implications of the type system to run their course. You seem to be a very pragmatic programmer and so the way Haskell builds up its own universe in terms of its own type system and Hask (the pseudo-category of Haskell objects) probably seems pointless to you. I can't say for certain, though.

I completely reject most of your claims because they appear to be incoherent within the framework of type theory and functional programming. It looks like you're using reasoning that applies only to procedural programming to attempt to prove why an idea in functional programming is bad.

It is clear now that you don't understand the claim. It sounds like like you're conflating pure and impure functions. It's obvious from context (did you even read the blog post?) that the title of the blog post is referring to pure functions.

You obviously can't treat an impure function as an array and no one would ever claim that. The blog itself isn't claiming that either given that the author is commenting on a nugget from Haskell documentation, and the author is explaining design choices in his own pure functional language.

Your three points only make sense if you're definition of "function" allows side effects. If we're talking about pure functions, then due to referential transparency, arrays are in fact equivalent to functions from contiguous subsets of the integers to another type, as the Haskell documentation indicates.

> One doesn't have to presume anything, there are general principles that people eventually find are true after plenty of experience.

I guess I just disagree with you here. Plenty of programmers with decades of experience have found no such general principle. There is a time and place for everything and dogmatic notions about "never conflate X and Y" because they're "fundamentally different" will always fall flat due to the lack of proof that they are in fact fundamentally different. It depends on the framework in which you're analyzing it.

> It isn't worthwhile to ponder because this doesn't contradict or even confront what I'm saying.

This is a non sequitur. What is worthwhile to ponder has no bearing on what you say. How arrogant can one person be?

> It might be personal research, but people have been programming for decades and this stuff has been tried over and over.

Decades? You think that decades is long enough to get down to the fundamentals of a domain? People have been doing physics for 3 centuries and they're still discovering more. People have been doing mathematics for 3 millennia and they're still discovering more. Let the cycle happen. Don't discourage it. What's it you?

> You're mentioning things that you expect to be self evident, but I don't see an explanation of why this simplifies programs at all.

It may not simplify programs, but it allows for other avenues of formal verification and proof of correctness.

----

Do you have other examples of where concepts were conflated that ended up "burning" the programmer?

> No, the best thing you can do for simplicity is to not conflate concepts.

This presumes the framework in which one is working. The type of map is and always will be the same as the type of function. This is a simple fact of type theory, so it is worthwhile to ponder the value of providing a language mechanism to coerce one into another.

> This is cleverness over craftsmanship. Keeping data and execution as separate as possible is what leads to simplicity and modularity.

No, this is research and experimentation. Why are you so negative about someone’s thoughtful blog post about the implications of formal type theory?

Trial and error is necessary and beneficial, but not after the student becomes frustrated or anxious/bewildered by the complexity. The research shows that striking a balance between teacher intervention and trial and error is the optimal approach. If a teacher notices that a student is way off course but they keep persisting in one branch of the trial-and-error search space, it’ll be best if they intervene and put the student on the right branch. The student can still use the knowledge of what wasn’t working to find the solution on the right branch, but just persisting would be ineffective.

Gaining true understanding/insight is necessarily trial and error. Teachers cannot teach insight. But they can present the optimal path to gain insight.

As a young Linux user I always hated the experimentation aspect because usually it meant just straight up getting the command wrong 5 times before trying to read the man page, thinking I understood what the man page meant, trying again another 5 times and then giving up.

This idea of experimenting and getting instant feedback is just survivorship bias for a certain type of person, not “the way we ought to teach Unix shell”

This view is corroborated by the research summarized and presented in the programmer’s brain by Felienne Hermans.

The curse of knowledge really. Or perhaps more accurately “awareness”.

You know about things that are to others unknown unknowns. Since ignorance is bliss, it definitely feels like a curse to you, and since what one doesn’t know can hurt them, others would see as a blessing.

Funny world we live in.

I think about this often as an org mode user who uses it exclusively for journaling with none of the GTD features. Org mode was released before markdown by over a year, but never saw the uptake like markdown did, despite being a more featureful syntax. I think that's because org mode was originally a GTD framework for emacs, and the syntax of org files was incidental to doing GTD in plaintext. It didn't get popularized as an alternative to other markup languages until long after markdown became popular.

I don't really know. I wasn't around back then to watch it unfold. But I still much prefer org mode due to better emacs support and (IMO) more intuitive syntax for things.

He's talking about "wonder bread" and other factory breads that have had much of their nutrients stripped and some put back, to the detriment of their absorption. Some also are concerned with artificially included preservatives and the unknown unknowns of putting them in places (even if there's a common natural source in another food).

Homemade bread is certainly not ultraprocessed (especially if made with unbleached flour or even better, whole wheat flour), but factory bread most certainly is considered ultraprocessed.

I appreciate when "Woe is Me" style comments are knocked down a notch when they conveniently ignore half of the world. The activity surrounding the discussion is indeed using networked applications, of which the web is only one.

So I don't think they were being needlessly pedantic, nor do I think they didn't understand what the parent meant by internet in the colloquial.

Lots of different ways one could take this: maybe whom they were responding to is just being lazy, that the good parts of the internet are there for them to explore, but they are beholden to their web browser and their favorite loathed platforms that 'make the internet suck'.

Or maybe whom they were responding to really has gone the rounds and really has considered all the options and bemoans how difficult the non-web internet services are to use, and how inelegant they can be at times and what a pain they are to maintain if it isn't your full time job.

There can be so many ways to take written material on the internet; more often even pedantic comments at least let us ensure we aren't simply reaffirming our own biases.

From your other responses in this thread, it looks like you do concede that e is useful in symbolic computation, and others use the phraseology "how the function is implemented", which is quite a silly thing to say in a classical math context, but not in a computational context.

I didn't understand immediately that you were talking about using values related to e in a computational context. But your comment about "brainwashing" seems a bit off. Are you saying that programmers bring e and ln with them into code when more effective constants exist for the same end? That's probably true. But brainwashing is far too strong, since things need to be taught in the correct order in math in order for each next topic to make sense. e really only comes in when learning derivative rules where it's explained "e is a number where when used as the base in an exponential function, that function's derivative is itself." Math class makes no pretense that you ought to use any of it to inform how you write code, so the brainwashing accusation seems off to me.

Unfortunately, I live in the US, and so a plug in induction range can deliver at most 1800 Watts. Though maybe it would be worth it for unlocking new techniques that require its fine grained control.

But I agree, if I am ever in a position to choose my cooktop technology, it will definitely be induction.

The real problem is with trust and encroachment. I think a lot of people that spend a fair amount of time on their computers start to feel like their OS is their home and they go on excursions through apps. Previously, ads were limited to apps you had to go to yourself. Ads showing up as wallpaper in your house would be unsettling, and it reveals that your homeownership was illusory from the start: you never really controlled anything.

Yes, you can use cleanup software to fix the symptoms, but that's not the real issue here.

Edit: further research revealed my original first point was a false assumption.

Good sir, have you ever used an electric stove? Every gas stove I've ever used excels only at precise and immediate control of heat and totally sucks at actually delivering heat. making bagels on a gas stove is such a pain in the neck because even the "power" burner can barely keep a large dutch oven of soda water boiling. The small burner on the electric stove? I have to keep at half power otherwise the starchy water boils over.

I've never used an industrial gas stove, only residential. But comparing apples to apples, residential electric ranges obliterate gas when it comes to power delivery.

Cannot speak for induction as I've never used one, but I'd expect it to be the best of both worlds based on the physics.

Room temperature ketchup is always suboptimal in my opinion. It's fine if I have to open a fresh bottle, but room temperature ketchup is like room temperature milk to me: consumable, but a bit unsettling.

As others have said, you're missing the author's point. The author is claiming that the act of writing software is getting industrialized by LLMs. LLMs will produce small, useful, but completely disposable programs that under the previous "artisanal" model would normally take me or another programmer an hour or so to write or debug. Or for something a bit more complicated, it can be vibe coded in 10 minutes, whereas it otherwise would have taken 10 hours to write and debug. You wouldn't want to use this sort of software extensively or for very long, just like you probably wouldn't frame a photo posted on social media. It might just be something to do some random task with your computer that is nontrivial that no other software tool does out of the box.

I think the author's analogies are on point.