default-kramer

Lay people certainly might bookmark a medication they buy often, and if "the smart website silently replaces the correct drug with something similar but wrong" they might end up accidentally ordering and even consuming it.

> It was okay until someone wrote a thing in php (!!) in a day that would be have taken at least a month in Java. Maybe two. I understand the "good" of Java, but for me personally, the cost of that good is just incredible tedium. This is personal and I understand that.

You understand that this has everything to do with Java and nothing to do with the JVM, right?

Reading the open letter, I don't think they are concerned with AI compositions dominating the charts. The open letter mentions "massive quantities of AI-created 'sounds' and 'images' that substantially dilute the royalty pools" and "We must protect against the predatory use of AI to steal professional artist' voices and likenesses, violate creators' rights, and destroy the music ecosystem."

So I think the more realistic threats are things like: Generating drum samples instead of buying them. Generating jingles/ads instead of hiring a composer. Spoofing a famous person's voice/likeness for some promotional blurb instead of paying them.

Yes, people who don't understand SQL databases can easily create "F-" situations. The problem is that people who are great at SQL databases can't do any better than a C+ because that's as good as SQL gets.

Two links away is the answer: https://github.com/SixArm/usv/tree/main/doc/faq#why-use-cont...

> Often wondered if that would work at all, but it would have to be secret or if ever found out it would be pilloried for being 'manipulative'.

Why would it have to be secret? All major governments do plenty of manipulation, and it's not even really a secret. The specifics may be a secret, but the fact that they are doing it is just business as usual.

Whether or not a certain religion is "proven false" is generally not a productive question. But many religious people would proudly state that they would continue to hold whatever sacred belief they have even if it were proven wrong. So I think the popularity of religion does show that people want to believe false things, regardless of whether the religion is true or false or (most commonly) unfalsifiable.

SQL is indeed pretty terrible IMO. Here's my favorite source to trot out when people inevitably disagree: https://www.scattered-thoughts.net/writing/against-sql/

Yeah, kind of. I have seen Escape From New York but I don't really remember it. I was more aware of the character via the reference/homage in Metal Gear Solid 2. In any case, I don't love the name but the obvious choice (Racquel) was already taken and "Plisqin" had zero Google results so I said "meh, good enough."

You might be interested in my attempt: https://docs.racket-lang.org/plisqin/Nullability.html

I think it handles all the 3VL problems I've encountered in SQL, but that doesn't mean it handles all possible 3VL problems. It also might not make any sense to anyone except me.

What do you think is incorrect about the code here which produces 1/2 if Monty randomly chooses? https://news.ycombinator.com/item?id=39515082

I disagree. If Monty always reveals a goat, there is no tension. You know exactly what is going to happen. Maybe it could be used a way to pad the running time of the show, but it would not add tension. "Coming up next: Monty reveals what's behind one of the other doors!" seems like something a game show would do. Whereas "Coming up next: Monty reveals a goat!" does not.

I had a similar thought when C# introduced async/await. "Why all this complexity? What was wrong with good old fashioned blocking calls?"

I don't know the answer, but I would like to. I think it has to do with the limit on the number of processes/threads that the OS/framework can manage. Once you reach this limit, using async/await somehow allows the OS/framework to secretly use your (technically not) blocked threads to do some other work while they are (technically not) blocked.

> easy way to enforce modularity and does not require the strict discipline required in a monolith

In my experience, microservices require more discipline than monoliths. If you do a microservice architecture without discipline you end up with the "distributed monolith" pattern and now you have the worst of both worlds.

Having fewer bricks could be considered a feature. There are definitely situations in which more constraints can increase creativity and happiness. For a long time, I preferred Dragon Quest Builders 1 (a Minecraft-style game) over its sequel for this reason. It's not unreasonable for people to be overwhelmed or put off by the tremendous variety of Lego available today.

First the authors show that for certain use cases, a single query is not ideal. Either the result set will be larger than it needs to be, or it will have to use something like ARRAY_AGG which "discard[s] all schema and relational information on the way." So let's assume that we are in a situation where a single query is not desirable.

Then the authors show ways to use multiple queries (in section 3, "SQL-BASED REWRITE METHODS"). Each method has its drawbacks. If you've done enough SQL, these patterns will look familiar to you. Compare the syntax needed here vs the proposed "SELECT RESULTDB" syntax in Listing 3 and you should see that their proposal is easier to write. Then in section 4, the authors "present an algorithm that can be integrated into a DBMS to efficiently compute the result set of our SELECT RESULTDB queries." Presumably this would be more efficient than any of the alternatives from section 3.

I don't remember the exact quote, but I saw a talk where he said something like "People want big/verbose/explicit syntax for the languages features they don't understand, and small/terse/implicit syntax for the language features do understand." It made me realize that many of my language design opinions at that time were a matter of personal preference.

But the 2400 blunders the queen in the opening for seemingly no reason? Then Magnus gives it back to be nice? I don't know what's going on there, maybe they're both hammered.

Of course I enjoy leveling up and choosing skills and exploring dungeons, but plenty of games implement those same mechanics at least as well as DQ. For me, the distinguishing feature of the Dragon Quest franchise (today*) is its charm: The charismatic cast of endearing enemies. The regional accents of the NPCs. The wordplay, the art, the music. Even the venerable hanging leather sack is enough to make me smile.

*I say "today" because earlier translations were not very good, as the article mentions. As I recall, even DQ7 on PS1 was pretty rough. But the English localization of DQ8 in 2005 was a masterpiece, and I think this is the one that set the bar for the future of the franchise (including remakes of earlier entries).

I guess I was assuming the LLM would be wrapped into some larger goal-seeky thing. Explaining the goal seems like the easy part; it could be as simple as "Make it possible for execution to reach this function."

Very cool.

I wonder if this kind of work is something that LLMs will be good at someday. (Has anyone trained an LLM on machine code yet?) Is it reasonable to hope that 20 years from now you'll be able to say "Hey CodeGPT, this binary doesn't run on Windows 17, can you make a patch?" The deep understanding and creative thinking that Nathan Baggs demonstrates here seems far beyond the capabilities of any tool I'm aware of; on the other hand, even a relatively dumb AI supplemented by brute force might be good enough.

A sibling comment mentions why this isn't likely (half of them are still sitting in storage). But I love this theory anyway - with some more creative liberties, you could write a script to rival The Big Lebowski!

You're right. And I realize I can't answer the question. But I wonder how much it matters? If a colleague and I disagree on whether some authorization logic counts as business logic or not, what is at stake?

Yeah that kind of stuff can definitely scare people away. I don't know what a monad is and I've stopped pretending to care. For me immutability and pure functions are the only important concepts; everything else is a bridge too far for practical corporate use. Still, I think that while null is commonly called "the billion dollar mistake", I wonder... I think that going back in time and making C# and Java immutable-by-default would have a bigger impact than adding null-safety. Maybe not a panacea, but FP does seem to set a pretty acceptable lower bound on how terrible a codebase can get in my experience.

I mostly agree with you. But I'd guess that at least 10 of those 100 developers might say something like "business logic belongs in framework-agnostic pure functions, unless you have a good reason not to." And many of the remaining developers would say "what is a pure function?"

I'm not claiming that FP is always the answer, but it's a great technique that somehow is still very under-utilized despite being enshrined in popular frameworks like React (I think). I don't mean to criticize developers who are unaware of FP - I graduated in 2008 but didn't learn FP until 2014, and I still can't believe that I was ignorant of it for so long. And I can't believe how many developers are still ignorant of it. Unless I'm wrong and FP actually sucks, there is an education problem.

I guess I've been lucky to work for companies that don't try to squeeze their developers so much. In my career, there has usually been time available to do things "the right way" (up to reasonable constraints of course).

> You have to clarify where you find the time to do all that "above-and-beyond" stuff because it's either normal work done on normal company time, which surely doing the normal/bare minimum is not proof of not being lazy, or it's going the extra mile, which is certainly not done during normal office hours.

At every company I've worked for, I've had time for "above-and-beyond" stuff during normal office hours. That's just how low expectations are in my neck of the woods. Or maybe I'm outrageously talented and I would still excel working on some elite FAANG team... but I doubt it.

From the article

> I routinely come across developers who are the real deal: they’re conscientious and judicious in an unwavering way. They set a standard for themselves and do not compromise on it. Whether that’s a deliberate thing or whether they’re just built that way, it’s humbling to witness. If there’s a flaky test, they investigate it and fix it. If there’s a bug they spot in the wild, they make a ticket, and maybe even fix it then-and-there. If a new feature doesn’t gel well with the existing code, they refactor the code first rather than hacking the feature in. They’ll dive as far down the stack as necessary to get to the bottom of something. None of these things are necessary but great developers know that if they don’t address a problem early, and properly, it will only cost them more time in the long run. [... and more.]

This sounds like a great definition of not-lazy, and it does not mention long hours anywhere. My anecdotal experience is that I usually only have 20-35 not-lazy hours to give per week; any further hours per week are much less potent. Right now I'm working 24 hours per week and I think my employer is getting a great bargain: they don't have to pay me for hours that would likely be lazy.

"ERROR: Mono: Core API hash mismatch." is a strong clue that it's using C# instead of GDScript. (I was on the lookout because the same error appears in my own game. Apparently it's benign.)

Early in my career, I just moved the mouse to my left hand and kept everything else the same. It was super easy to get used to and easy to replicate whenever I have to use some shared workstation.

Using FQL instead of SQL seems to be a pretty big difference too.