schwartzworld

What if that data isn’t publicly posted? For example, copilot regurgitating code from private repos, complete with comments.

> Being wrong or lying is almost universally bad and unproductive

Sure, but there are cases where rightness isn’t a thing.

Don’t get me wrong I’m not an AI Stan, it has real problems, but it’s also not going anywhere. Eventually the bubble will pop and we’ll see which applications of AI turned out to be useful and which didn’t.

It's bad at

- Actually knowing things / being correct - Creating anything original

It's good at

- Producing convincing output fast and cheap

There are lots of applications where correctness and originality matter less than "can I get convincing output fast and cheap". Other commenters have mentioned being able to vibe-code up a simple app, for example. I know an older man who is not great at writing in English (but otherwise very intelligent) who uses it for correspondence.

> Didn't google just prove there is little to no environmental harm

I'd be interested to see that report as I'm not able to find it by Googling, ironically. Even so, this goes against pretty much all the rest of the reporting on the subject, AND Google has financial incentive to push AI, so skepticism is warranted.

> I don't ask a lot of race-based questions to my LLMS I guess

The reality is that more and more decision making is getting turned over to AIs. Racism doesn't have to just be n-words and maga hats. For example, this article talks about how overpoliced neighborhoods trigger positive feedback loops in predictive AIs https://www.ohchr.org/en/stories/2024/07/racism-and-ai-bias-...

> Copyright never stopped me from saving images or pirating movies.

I think we could all agree that right-clicking a copyrighted image and saving it is pretty harmless. Less harmless is trying to pass that image off as something you created and profiting from it. If I use AI to write a blog post, and that post contains plagiarism, and I profit off that plagiarism, it's not harmless at all.

> I also grew up being told that ANYTHING on the internet was for the public

Who told you that? How sure are you they are right?

Copilot has been shown to include private repos in its training data. ChatGPT will happily provide you with information that came from textbooks. I personally had SunoAI spit out a song that whose lyrics were just Livin' On A Prayer with a couple of words changed.

We can talk about the ethical implications of the existence of copyright and whether or not it _should_ exist, but the fact is that it does exist. Taking someone else's work and passing it off as your own without giving credit or permission is not permitted.

Inserting the LLM into the process exponentially increases the energy expenditure, and it may be confidently wrong in its analysis of the results. What is the upside? Do you just want a chat interface on everything?

Using a 1 pound coin is basically saying “it costs a pound to take this and not bring it back.” It works for lazy returners, but makes blatant theft quite easy.

> I think it has replaced search quite quickly.

I really don't get this one. Between the ludicrous energy waste and answers that are confidently wrong, I don't see why anybody would prefer to get their information from am LLM.

Voice recognition is an apt example though. It has it's place, like texting my wife from the car without having to look at my phone, and it's obviously a boon to accessibility, but I wouldn't want to have it needlessly jammed into every workflow. I don't get people's willingness to place so much trust in a statistical language model that does a pretty good job of pretending to know things.

It might depend a little on the poker variant. Holdem (the most popular variant) uses shared cards, which gives you a fair amount of information.

> NL Holdem poker is absolutely a game of skill with an element of variance aka luck/lack-there-of.

I’ve played a lot of Holdem, and I’m not sure I agree. A lot of what passes for skill is just an innate understanding of the odds.

John Scarne writes about gambling that a good bet isn’t one you are likely to win, but one where the payout is enough to be worth the risk. The best players know the odds of pulling a straight and can do math to figure out if it’s worth chasing one.

Local storage is a poor example because it updates in the background and wouldn’t necessarily change your UI much. But if a design calls for a search to be made while a user types that would get janky fast.

React in particular is data driven so in the above example, if you make the api call on each keypress, and save it into state or whatever, the UI will update automatically. I can type 70 words per minute. Nobody wants the search results to update that fast. (Should we be building searches that work this way? Often you have no choice.) A slow network + a short search string + a not top of the line device like a cheap phone means a really janky experience. And even if it’s not janky, its a waste of your users bandwidth (not everybody has unlimited) and an unnecessary drain on your server resources.

Even though we say “update as the user types” people type in bursts. There’s no reason not to debounce it, and if you can make the debounce function composable, you can reuse it all over the place. It’s a courtesy to the users and a good practice.

For the kind of behaviors they are describing it would. An extra 250ms waiting for an app to load is a lot, but for something like the described autosave behavior, waiting for a 250ms pause in typing before autosaving or making a fetch call is pretty snappy.

This is great and will be an excellent source of samples

I’d go further and say that writing code for a living requires a great deal of self-teaching regardless of your background. CS degrees typically don’t teach you how to build software, and even if they did, the problem space is huge. There is a lifetime of self-teaching to do from the moment you take your first job.

I think that my being self-taught helped my career quite a bit. It did make it harder to get in the door, but that was just a one-time problem to solve.

They already built the app for rebooting relationships. A few times. A lot of the enthusiasm about web2.0 sites like MySpace and Facebook came from the ability to reconnect with people from your past. If they’d kept Facebook what it was in 2007 it would still be a useful tool.

what you’re saying is on par as “kids can’t learn as well typing their work as they do with a pen and paper” or “video games bad”. I’m not saying I disagree with the idea that an AI can’t replace a real human connection, but it’s more complex than you state.

Loneliness is an umbrella term. You could have friends but be single and feel lonely. You can be married, surrounded by family and be lonely. It doesn’t necessarily mean the same thing as solitude, as many people are alone all day without feeling lonely.

> connect component to external changing data. The only way you can do is by using useEffect incorrectly.

You mean correctly. That’s was what it was for. Syncing with external systems.

I've been using Typescript for years and while I love it, it's far from the magic bullet. No, you'd need something more opinionated and actually typesafe, and now you're writing a different language that compiles to JS. There's a bunch of these, and they haven't caught on for a reason. Eventually you're going to need JavaScript.

There are more opinionated UI frameworks (angular) and frameworks with less magic baked into them (svelte, solid). React gives you the freedom to architect your app the way you want, for better or for worse. It was made by functional programmers to allow them to use composition and other FP paradigms in UI development. If you don't understand those concepts, or you just don't care for them, you're going to be swimming against the tide. Lots of tooling has been created to help those who do (Redux, for example).

Maybe you're right and "you're holding it wrong" isn't a valid answer, but it's not React's fault it took over the world. It was made to do a certain thing, and it's pretty good for that. That thing requires a way to create side effects (useEffect) and a way to provide referential stability (useMemo, useCallback). The React team has done a lot to document the right way to use these tools.

If it's not someone's thing, that's cool. If they are forced to use it at work, might as well learn a little FP and make life simpler.

> but the language, API or framework does not make it conducive to easily writing correct code

The language is sort of settled. The browser runs JS, so for most projects, it's the right choice.

> If your large, complex, react app is slow - what is easier? Fixing the data architecture or adding a useMemo?

It might be easy to add useMemo, but it doesn't work. People using a tool for the wrong thing because they don't understand it isn't a problem with the tool. It's unfortunate that a tool with a steep learning curve is the "default" for many devs now, but again that isn't a problem with the tool. I don't have any guardrails keeping me from using my saw as a hammer, it just doesn't work.

> because something about language/framework/api makes doing the proper thing hard or unclear.

It's unclear because it was built on functional programming concepts and most devs aren't taught that way. If you are familiar with those concepts, the whole thing is quite simple.

> The question is "how easy to do it correctly?"

It’s quite easy. The complaints people have about it are due to friction from using it wrong.

The issues with useEffect come from a misunderstanding of how data is meant to flow in react, the fundamental concept on which the whole thing is based.

It’s not complicated at all.

> While this is nice enough, it bothers me that these don't look much like "art".

The author didn't invent this style. The first thing I thought of was the poster for the Truman Show. https://artofthemovies.co.uk/products/the-truman-show-1998-m... The site seems to make that happen quite well.

Even younger now. Initial screening is done at like 8 weeks by extracting the mothers blood and examining the chromosomes in the fetal cells.

> That is: you're left with a bunch of skeleton issues filed only for the sake of shoving it into a TODO comment

Nobody says it needs to be one ticket per TODO. For example, I usually maintain a CSS punch list ticket to avoid too much yakshaving when developing functionality. Not only will it be more likely to get scoped and done, but another dev will know exactly where the fixes are needed by grepping for the ticket number.

But the other upside is that if it's really not worth filing a ticket for, why not just do it? I'm curious what scope of work you think is worth tracking in TODOs but not tickets. If it would be a point of work it probably deserves a ticket. If it's less than a point of work, shouldn't you just do it?

> Those tickets end up getting auto closed after X time anyways.

That feels like it reinforces my argument to me. If you can't make time for it when it's a ticket, how would you make time when it's just a comment? At least if the team decides in grooming that the work doesn't really need to be done, it's a group decision and not just me passing the buck.

> If you keep outdated comment or documentation in your code without anyone noticing, I'd say you have a pretty big issue with your review process.

Its easy to say that, and probably true, but in a large company with a shared codebase, you don't always have that kind of control. Someone intends to fix something, then the work gets deprioritized or they leave the company or forget.

Maybe you've never seen a comment and realized that the code that goes with it isn't there anymore, but I have. Comments and documentation are important but there's a spectrum of usefulness. On one end it "TODO: Fix this later" and on the other end are comments that are really important with a whole range in between.

The reality is, tickets are the way of making sure work gets scoped and accounted for. If your company measures velocity, having the actual amount of work you do represented in tickets is the way you show what you are actually doing all day. Why wouldn't you want future work to be ticketed? Who does it help?

I have a single rule: Every todo needs the ticket number included.

// TODO: improve the routing https://jira.com/whatever/TIX-1234

This rule is important because comments can get orphaned. Just leaving a comment is a recipe for a comment nobody knows why it’s there. Just make a ticket or do it now.

I was at a hotel recently with packaged snacks on a tray, cookies crackers etc. There was a sign clearly explaining that moving anything off the tray results in an automatic charge. Thank god we didn’t have the kids with us.

That was my thought. Magic Jack basically does the same thing but cheaper and better.

Doesn't work for Armenian.

Well that’s pretty clean.

I’m curious what your diet is like, especially at the end of the week when the medicine is weakest. If I eat dairy, sugar, etc in the day or two before my semaglutide, I feel similarly.