Replying to
@shanselman@hachyderm.io You figured it out in only 2 hours? That still sounds like a win, compared to some other personal equipment debugging sessions I've had.
Remote
Jonathan Schuster
@jschuster@hachyderm.io
mastodon 4.7.3Software design education at Google. Programming languages PhD. Career goal: to give software developers knowledge and tools to help them reason about their programs.
Posts reflect my personal thoughts and opinions, not those of my employer.
111 Followers
216 Following
19 Posts
Joined October 17, 2023
Website:
Yesterday: "It's such a beautiful day, and summer is going by so fast. I wish I didn't have work today."
Today: Take the day off. Go for a couple of bike rides around town. Read in the hammock. Get a good sandwich at a local cafe and eat outside. Swim, relax, and read some more at the public pool.
Yeah. That's the way to do it. 😌
I love Rust for what it is, but this is spot on. Don't reach for the hair shirt of borrow checking unless you're confident you really need that low level control.
Replying to on beige.party
@Lana@beige.party "Correlation is not causation" is the best because most fallacious reasoning mentions a correlation.
RE: @jenniferplusplus@hachyderm.io
Jennifer mentions anchoring and (exhaustion of our) vigilance as two risks of LLM-based tools, at least for software development. I've definitely seen both of those from some coworkers. Definitely on my list of concerns with these tools.
A reflection on LLMs and understanding:
Maybe you've been in this situation before: you ask someone about their work, and they go on a long technical ramble about the intricate details of what they do. Then at the end you respond "Wow, I didn't understand any of that. You must be really smart".
I used to think like that as well. But then in grad school, I learned that such a ramble signals a lack of skill rather than an abundance of intelligence. Anyone can ramble at length about whatever is on their mind in whatever form they think about it. But when someone really, deeply *understands* an idea, they can communicate it in a way that other people can understand, too.
So when I hear people at work say things like "I don't really understand this, but I fed it to the LLM and I was really impressed by the response", you can understand my concern.
Replying to
@shriramk @lindsey @cross @krismicinski @jfdm @csgordon @jeremysiek LLM-based code generation reminds me of some of Bret Victor's talks: there are some cool ideas and convincing demos, but also a lot more work to do before one can say "we've solved all of the problems; everyone should be doing this all the time now".
Replying to
@pence Sounds like crystalized intelligence: https://en.wikipedia.org/wiki/Fluid_and_crystallized_intelligence
Replying to
@shriramk @jfdm @cross @lindsey @krismicinski @csgordon @jeremysiek ah, I see. I was thinking more like expressing structural constraints in UML and passing those as extra constraints to the LLM, along with the rest of the prompt/spec.
100% idle speculation for me, I haven't dived too deep into this yet.
Replying to
@shriramk @cross @lindsey @krismicinski @jfdm @csgordon @jeremysiek yeah I would have sworn I saw him make a diagram like that too, but I don't see it now in the World and the Machine paper.
Thinking back to that era: maybe we'll see the resurgence of parts of UML? Perhaps this new loop is the right feedback loop to make some of those ideas work
Replying to
@cross @shriramk @lindsey @krismicinski @jfdm @csgordon @jeremysiek My understanding is that Waterfall in the most extreme sense means you can't go back to a previous phase (hence the name waterfall: it only goes in one direction). So in a technical sense, that feedback cycle isn't taking us back to waterfall.
But will LLMs encourage a doc/spec-heavy style of development? Most people I know seem to think yes. In particular, the software architecture folks I know are excited about having a space to talk about architecture again. But what exactly those "specs" look like and how similar they will be to our current docs and specs is very much up for debate.
Replying to
@shriramk @lindsey @cross @krismicinski @jfdm @csgordon @jeremysiek To be fair: The LLM tooling is certainly more capable overall than the Bret Victor stuff. But I'm not yet convinced coding is 100% solved.
Replying to
@shriramk @cross @lindsey @krismicinski @jfdm @csgordon @jeremysiek Yeah, particularly the parts of UML about structure. The more behavioral parts always seemed like a clumsy PL to me, but the parts that constrain the architecture seem like a good starting point if we want to (semi) formalize the requirements we give to LLMs.
Replying to
@jfdm @shriramk @cross @lindsey @krismicinski @csgordon @jeremysiek Fair! I like those types also (Mailbox Types is what I wish my dissertation had been). My experience has been that source code->UML diagram works well in some cases, but not the other way around. But happy to be proven wrong.
EDIT: He may not have passed away, see quoted post.
Farewell to a legend of the computer science community. I've known his name since some of my earliest days in CS, and I remember being starstruck when he was the first (and I think still only) Turing award winner I saw in person. Thank you for everything. Rest in Peace.
RE: @benfry@information.garden
Yes, I've been thinking this for a while. There's some real value in LLMs (ignoring actual costs and externalities for the moment), but I believe a large part of the hype and business spend on AI right now is because many business leaders don't fully appreciate the gap between a flashy demo and an actual product.