Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tools: Code Is All You Need

lucumr.pocoo.org

Post reply on HN
Print view View original

181–190 of 234 posts

Re: Tools: Code Is All You Need

#181

Post by jrm4 »

mumbisChungo wrote: post #168
sizzle wrote: post #166

Earlier quoted context omitted.

Ahh yes let’s get the next generation addicted to literal screens strapped to their eyeballs for maximum monetization, humanity be damned. Glad it’s a failing bet. Now sex bots might be onto something…

It may or may not be a failing bet. Maybe smartphones are the ultimate form of human-data interface and we'll simply never do better.

I'll take your argument a bit further. The thing is -- "human-data" interfaces are not particularly important. Human-Human ones are. This is probably why it's going to be difficult, if not impossible, to beat the smartphone; VR or whatever doesn't fundamentally "bring people closer together" in a way the smartphone nearly absolutely did.

Re: Tools: Code Is All You Need

#182

Post by alganet »

It's finally happening. The acceleration of the full AI disillusionment:

- LLMs will do everything.

- Shit, they won't. I'll do some traditional programming to put it on a leash.

- More traditional programming.

- Wait, this traditional programming thing is quite good.

- I barely use LLMs now.

- Man, that LLM stuff was a bad trip.

See you all on the other side!

Re: Tools: Code Is All You Need

#183

Post by zahlman »

jasonthorsness wrote: post #9
mindwok wrote: post #3

More appropriately: the terminal is all you need. I have used MCP daily for a few months. I'm now down to a single MCP server: terminal (iTerm2). I have OpenAPI specs on hand if I ever need to provide them, but honestly shell commands and curl get you pretty damn far.

I never knew how far it was possible to go in bash shell with the built-in tools until I saw the LLMs use them.

Possibly because most people who could mentor you, would give up and switch to their preference of {Perl, Python, Ruby, PHP, ...} far earlier.

(Check out Dave Eddy, though. https://github.com/bahamas10 ; also occasionally streams on YouTube and then creates short educational video content there: https://www.youtube.com/@yousuckatprogramming )

Re: Tools: Code Is All You Need

#184

Post by mumbisChungo »

jrm4 wrote: post #181
mumbisChungo wrote: post #168

Earlier quoted context omitted.

It may or may not be a failing bet. Maybe smartphones are the ultimate form of human-data interface and we'll simply never do better.

I'll take your argument a bit further. The thing is -- "human-data" interfaces are not particularly important. Human-Human ones are. This is probably why it's going to be difficult, if not impossible, to beat the smartphone; VR or whatever doesn't fundamentally "bring people closer together" in a way the smartphone nearly absolutely did.

VR may not, but social interaction with AR might be more palatable and better UX than social interaction while constantly looking down at at a computer we still call a "phone" for some reason.

Re: Tools: Code Is All You Need

#185

Post by zahlman »

forrestthewoods wrote: post #31

Unpopular Opinion: I hate Bash. Hate it. And hate the ecosystem of Unix CLIs that are from the 80s and have the most obtuse, inscrutable APIs ever designed. Also this ecosystem doesn’t work on Windows — which, as a game dev, is my primary environment. And no, WSL does not count. I don’t think the world needs yet another shell scripting language. They’re all pretty mediocre at best. But maybe this is an opportunity to…

> Python environment is a clusterfuck. Which UV is rapidly bringing into something somewhat sane.

Uv is able to do what it does mainly because of a) being a greenfield project b) in an environment of new standards that the community has been working on since the first days that people complained about said clusterfuck.

But that's assuming you actually need to set up an environment. People really underestimate what can be done easily with just the standard library. And when they do grab the most popular dependencies, they end up exercising a tiny fraction of that code.

> But I’d definitely be more interested in “replace yourself with a UV Python script” over “replace yourself with a shell script”.

There is no such thing as "a UV Python script". Uv doesn't create a new language. It doesn't even have a monopoly on what I guess you're referring to, i.e. the system it uses for specifying dependencies inline in a script. That comes from an ecosystem-wide standard, https://peps.python.org/pep-0723/. Pipx also implements creating environments for such code and running it, as do Hatch and PDM; and other tools offer appropriate support - e.g. editors may be able to syntax-highlight the declaration etc.

Regardless, what you describe is not at all opposed to what the author has in mind here. The term "shell script" is often used quite loosely.

Re: Tools: Code Is All You Need

#186

Post by zahlman »

forrestthewoods wrote: post #70
lsaferite wrote: post #43

Earlier quoted context omitted.

Python CAN be a "shell script" in this case though... Tool composition over stdio will get you very very far. That's what an interface "from the 80s" does for you 45 years later. That same stdio composability is easily pipe into/through any number of cli tools written in any number of languages, compiled and interpreted.

Composing via stdio is so bloody terrible. Layers and layers of bullshit string parsing and encoding and decoding. Soooo many bugs. And utterly undebuggable. A truly miserable experience.

And now you also understand many of the limitations LLMs have.

Re: Tools: Code Is All You Need

#187

Post by benreesman »

threetonesun wrote: post #149
benreesman wrote: post #113

Earlier quoted context omitted.

I said as concerns the economics. It's clearly more popular than the Oculus or whatever, but it's still a money bonfire and shows no signs of changing on that front.

LLMs as we know them via ChatGPT were a way to disrupt the search monopoly Google had for so many years. And my guess is the reason Google was in no rush to jump into that market was because they knew the economics of it sucked.

Right, and inb4 ads on ChatGPT to stop the bleeding. That's the default outcome at this point: quantize it down gradually to the point where it can be ad supported.

You can just see the scene from the Sorkin film where Fidji is saying to Altman: "Its time to monetize the site."

"We don't even know what it is yet, we know that it is cool."

Re: Tools: Code Is All You Need

#188

Post by lsaferite »

wrs wrote: post #86
lsaferite wrote: post #35

Earlier quoted context omitted.

No. You are giving textual instructions to Claude in the hopes that it correctly generates a shell command for you vs giving it a tool definition with a clearly defined schema for parameters and your MCP Server is, presumably, enforcing adherence to those parameters BEFORE it hits your shell. You would be helping Claude in this case as you're giving a clearer set of constraints on operation.

Well, with MCP you’re giving textual instructions to Claude in hopes that it correctly generates a tool call for you. It’s not like tool calls have access to some secret deterministic mode of the LLM; it’s still just text. To an LLM there’s not much difference between the list of sample commands above and the list of tool commands it would get from an MCP server. JSON and GNU-style args are very similar in structure.…

Not strictly true. The LLM provider should be running a constrained token selection based off of the json schema of the tool call. That alone makes a massive difference as you're already discarding non-valid tokens during the completion at a low level. Now, if they had a BNF Grammer for each cli tool and enforced token selection based on that, you'd be much better off than unrestrained token selection.

Re: Tools: Code Is All You Need

#189

Post by macleginn »

SatvikBeri wrote: post #173

I use Julia at work, which benefits from long-running sessions, because it compiles functions the first time they run. So I wrote a very simple MCP that lets Claude Code send code to a persistent Julia kernel using Jupyter. It had a much bigger impact than I expected – not only does test code run much faster (and not time out), but Claude seems to be much more willing to just run functions from our codebase rather th…

"Claude seems to be much more willing to just run functions from our codebase rather than do a bunch of bespoke bash stuff to try and make something work" -- simply because it knows that there is a kernel it can send code to?

Re: Tools: Code Is All You Need

#190

Post by diggan »

nartho wrote: post #177
shepherdjerred wrote: post #170

Earlier quoted context omitted.

Are fractals or x86 assembly representative of most dev work?

I think it's irrelevant. The point they are trying to make is anytime you ask a LLM for something that's outside of your area of expertise you have very little to no way to insure it is correct.

> anytime you ask a LLM for something that's outside of your area of expertise you have very little to no way to insure it is correct.

I regularly use LLMs to code specific functions I don't necessarily understand the internals of. Most of the time I do that, it's something math-heavy for a game. Just like any function, I put it under automated and manual tests. Still, I review and try to gain some intuition about what is happening, but it is still very far of my area of expertise, yet I can be sure it works as I expect it to.

Post reply on HN