4,384 karma · joined November 20, 2012
"Review <codebase> and create a spec for <algorithm/pattern/etc.>"
It gives you a good starting point to jump off from.
I've been building a programming language using Claude, and this is my findings, too.
Which, after discovering this, makes sense. There are a LOT of small decisions that go into programming. Without detailed guidance, LLMs will end up making educated guesses for a lot of these decision, many of which will be incorrect. This creates a compounding effect where the net effect is a wrong solution.
> I’m a fan of web components but it’s the React flavor that dominate and they are not accessible to the kind of developer who could productively use Visual Basic components back in the day.
I think this is the most important statement in the piece. The rest of the post explains the technical details, but this explains _why_ this exists. This is a bold statement, but I don't think he's wrong.
Now, is XMLUI the _right_ set of abstractions to help these developers? We'll have to wait an see. But I love to see the attempt!
I would argue we still need the knowledge: the principles aren't changing, and they are needed to be truly productive in certain things. But the application of those principles _are_ changing.
The section "What Even Is Programming Anymore?" hit on a lot of the thoughts and feels I've been going through. I'm using all my 25+ years of experience and CS training, but it's _not_ programming per se.
I feel like we're entering an era where we're piloting a set of tools, not hand crafting code. I think a lot of people (who love crafting) will be leaving the industry in the next 5 years, for better or worse. We'll still need to craft things by hand, but we're opening some doors to new methodologies.
And, right now, those methodologies are being discovered, and most of us are pretty bad at them. But that doesn't mean they're not going to be part of the industry.
This isn't to say we shouldn't think critically about the use and performance of models, but "Not Even Bronze..." turned me off to this critique.
https://newsletter.pragmaticengineer.com/p/code-review-on-pr...
1. Write plan 2. Ask Claude to review for understandability 3. Update as needed until it's clear 4. Execute the task(s) in the plan.
I'm finding Claude gets much further on the first pass. And I can version the plans.
Just curious why you would think this? Markets react fairly quickly to major events...
I'm ok with this... maybe I'm odd? I view my laptops like I view my cars: I expect them to be replaced after a period of time. I'm NOT trying to maintain my old 2002 Honda Civic, and I'm NOT trying to maintain my older Macbooks. Once they leave Apple Care, I expect maybe another 12 to 18 months out of them, and then I move on.
That was a huge reason JSON took over.
Another reason was the overall XML ecosystem grew unwieldy and difficult to navigate: XPath, XSLT, SOAP, WSDL, Xpointer, XLink, SOAP, XForms... They all made sense in their own way, but it was difficult to master them all. That complexity, plus the poor ergonomics, is what paved the way for JSON to become preferred.
> GPT 4o pricing for comparison: Price Input: $2.50 / 1M tokens Cached input: $1.25 / 1M tokens Output: $10.00 / 1M tokens
Their examples don't seem 30x better. :-)
We're in the US, and we're looking at a UK trip. I've lived in the UK, and we've done a fair amount of international travel. We're in the "brainstorming" mode. I'd characterize the conversation as verbal googling.
We were asking questions about distances between cities, typical ticket rates for trains, things to do in various locations, etc.
My wife and I are planning a family vacation, and we had some questions about various destinations. I opened Gemini, and we had a helpful 10-minute conversation.
If Alexa+ can provide a similar experience, I can see us having more of those voice-based sessions.
Yes, you need to care about this. But for the most part you should just follow the conventions of the language/framework, and not reinvent the wheel. Instead, you should put cycles into crafting architectures and algorithms.
I might be reading into your comment, but I agree "top-down" development sucks: "Give me a react that does X". I've had much more success going bottom-up.
And I've often seen models getting confused on versions. You need to be explicit, and even then then forget.
Maybe. My sense if we'd need to see 3 to 4 orders of magnitude improvements on the current models before we can replace people outright.
I do think we'll see a huge productivity boost per developer over the next few years. Some companies will use that to increase their throughput, and some will use it to reduce overhead.
That's interesting. I found assistants like Copilot fairly good at low level code, assuming you direct it well.
I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we needed. This is the third time I've done this, and each time I get faster and better at it.
1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach.
2. Generating unit tests is critical. After I like the gist of some code, I ask for some smoke tests. Again, peer review the code and adjust as needed.
3. Be liberal with starting a new chat: the models can get easily confused with longer context windows. If you start to see things go sideways, start over.
4. Give it code examples. Don't prompt with English only.
FWIW, o3-mini was the best model I've seen so far; Sonnet 3.5 New is a close second.
I tried it out a few weeks ago and it was extremely buggy. I'm curious how it has been for others.
I think a lot of software development is "way finding" - Experimentation to figure out an architecture, an implication, a performance improvement, etc.
We often don't a) call them experiments, and b) we don't constrain them well. I.e., we use the scope of the feature to bound the experiment, instead of taking a step back to figure out the right approach, we dive into implementation.
I'm curious if there's a more formal way to think about this all?
For context, I first tried this procession of searches on the Mac OS app.
1. "Who won the world series" 2. Who was the MVP?" 3. "Give me his bio"
My observations:
1. UX: The "search" button feels oddly placed, but I can't put my finger on it. But once I got it is a toggle, it wasn't a bit deal.
2. The first result had 3 logos, headlines and timestamps delineated, and easy to ready. The second one and third ones included a "Sources" button that opened a fly open menu. Clicking those opened a web link. The third result also included images in the fly open.
3. Citations were also inlined. The third result, for the bio, included a citation per paragraph.
4. It wasn't as fast as google. Which makes sense, given it's going through the LLM. But it will take a while to rewire my brain to expect slower responses to search.
5. Overall, I found the chat interface a very intuitive interface.
The second search I asked was "Give me a plan for a Thanksgiving meal."
I to a long response that felt like a weird mashup of LLM-generated content and search results:
1. A list of menu selections
2. Links to some recipes
3. Prepration timeline
4. Shopping list
5. Additional tips
There were 15 citations listed in the popup button, but only 3 inlined.
This was... not great. A traditional list of search results feels better here.
Overall, I like the direction. Innovation in search has been dead for close to 10 years, and this feels like I'd use it for certain inquiries.
I think there are two issues here:
1. The "truthfulness" of the underlying data set, and 2. The faithfulness of the LLM to pass along that truthfulness. Lack of passing along the truthfulness is, I think, the definition of the hallucination.
To your point, if the data set if flawed or factually wrong, the model will always produce the wrong result. But I don't think that's a hallucination.
https://www.rebol.com/docs/core23/rebolcore-16.html#section-...
> $100 + 11 $111.00
> $10 / .50 $20.00
In general, Rebol's type system was very expressive. Would love to see more libraries like this provide that type of experience.
You could be right. My (limited) understanding is that SpaceX is doing most of their R&D internally, and therefore they don't have the same oversight requirements more NASA-centric projects require. But that was based on an article about Artemis, and not Starliner.
Beyond that, the book makes a good case for how unrealistic a long-term colony on Mars is... at least in the short term (Short being the next 50 to 100 years).
My biggest take away is: for all his talk, Musk basically just wants to be the Uber to Mars: shuttling people there and back. He don't seem serious about _actually_ solving the problems of how to stay alive and thrive once we get there.
I found it sort of depressing as first, as I'd love to see people loving on Mars in my lifetime. But when I thought about it, I saw that they outlined a bunch of really important problems we should be working on as a society. The sooner we work on those problems, the better.