Hacker News Reader

Comment by vladms | Hacker News Reader

The advantage of frameworks is to have a "common language" to achieve some goals together with a team. A good framework hides some of the stupid mistakes you would do when you would try to develop that "language" from scratch.

When you do a project from scratch, if you work enough on it, you end up wishing you would have started differently and you refactor pieces of it. While using a framework I sometimes have moments where I suddenly get the underlying reasons and advantages of doing things in a certain way, but that comes once you become more of a power user, than at start, and only if you put the effort to question. And other times the framework is just bad and you have to switch...

View on HN

I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts. Just fully explained it, how it all worked, how to get started working on it locally, the nuance of the old code, pathways, deployments using salt-stack to AWS, etc.

I don't think the moat of "future developers won't understand the codebase" exists anymore.

This works well for devs who write their codebase using React, etc., and also the ones rolling their own JavaScript (of which I personally prefer).

> I used Claude to document, in great detail, a 500k-line codebase in about an hour of well-directed prompts

Yes, but have you fully verified that the documentation generated matches the code? This is like me saying I used Claude to generate a year long workout plan. And that is lovely. But the generated thing needs to match what you wanted it for. And for that, you need verification. For all you know, half of your document is not only nonsense but it is not obvious that it's nonsense until you run the relevant code and see the mismatch.

Yes, since I spent over 10 years writing it in the first place it was easy to verify!

This is a key piece of information you left out of your original post.

To make a parallel to actual human language: you can understand well a foreign language and not be able to speak it at the same level.

I found myself in that situation with both foreign languages and with programming languages / frameworks - understanding is much easier than creating something good. You can of course revert to a poorer vocabulary / simpler constructions (in both cases), but an "expert" speaker/writer will get a better result. For many cases the delta can be ignored, for some cases it matters.

Hey, I also sent this to feedback@nugget.one, but just in case it doesn't arrive:

I wasn't able to get into your 'startup ideas' site.

Signing in with google led to internal server error, and signing in with a password, I never received the verification email.

Thought I would let you know. Can't wait to get those sweet startup ideas....!

Thanks, I've been very focused on lightwave and as a result let that one slide a bit. I'll try to get it working in next week or so.

If your project is on Github, you can also use https://deepwiki.com/. I have used it to get an overview of a new codebase quickly.

This - I even ran Claude to produce a security eval of openclaw for fun and it was mostly spot on - https://sriku.org/files/openclaw-secreport-claude-13feb2026....

How did you vet the quality of the documentation? I have no doubt that an LLM could produce a great deal of plausible-sounding documentation in short order. Even assuming you’re already completely familiar with the code base, reading through that documentation and fact checking it would take a great deal of effort.

What’s the quality like? I’d expect it to be riddled with subtly wrong explanations. Is Claude really that much better than older models (eg. GPT-4)?

Edit: Oops, just saw your other comment saying you’d verified it manually.

The problem with this is that it means you have to read guides which it seems no one wants to do. It drives me nuts.

But ya, I hate when people say they don't like "magic." It's not magic, it's programming.

Most however are surely capable of understanding a simple metaphor, in which "magic" in the context of coding means "behavior occuring implicitly/as a black box".

Yes, it's not magic as in Merlin or Penn and Teller. But it is magic in the aforementioned sense, which is also what people complain about.

Oh no! Reading!

Sorry for the snark but why is this such a problem?

Because people won't do it.

Sounds like a them problem. If they can't be bothered to learn how to use their tools, it won't be a surprise that they then won't know how to use them. A free advantage to those of us that do dedicate the time to read the docs I guess.

At least in web development it really seems to have become widely accepted, at least at many places, that people aren't expected to be anywhere near experts in the tools they use every day.

Magic refers to specific techniques used in programming, an people generally dislike these techniques once they have formed any opinion.

do people generally dislike magic once they have formed an opinion, or is it just that people who dislike magic are more prone to voicing that opinion, why, if magic is disliked by people experienced enough to form opinions, does it keep coming back around?

I would suppose the people who create "magic" solutions have at least voiced an opinion that they like magic and the people who take up those solutions the same, for the record I too dislike magic but my feeling is that I am somewhat in the minority on that.

There is a HUGE difference between framework/library "magic" and business logic "magic." When framework/library "magic" is documented it's awesome, you just need to take the time to learn it.

https://medium.com/luminasticity/laborers-craftsmen-and-arti...

in my experience among personality types of programmers both laborers and artists are opposed to the reading of guides, I think the laborers due to laziness and the artists due to a high susceptibility to boredom and most guides are not written to the intellectually engaging level of SICP.

Craftsmen are naturally the type to read the guide through.

Of course if you spend enough time in the field you end up just reading the docs, more or less, because everybody ends up adapting craftsmen habits over time.

I don't disagree, but the fact that it's not required to border on expert, or be willing to put in the work to get there, of a framework or library you are going to be working heavily in a pretty broken thing about our industry. But you know, as people have been posting lately: not AI therefore irrelevant.

It's funny how Lisp has been criticized for its ability to create a lot of macros and DSLs, then Java & JavaScript came along and there was an explosion of frameworks and transpiled languages in JVM, Node or the Browser.

"The problem with Scheme is all of the implementations that are incompatible with one another because they each add their own nonstandard feature set because the standard language is too small." Sometimes with an added subtext of "you fools, you should have just accepted R6RS, that way all Schemes would look like Chez Scheme or Racket and you'd avoid this problem".

Meanwhile in JavaScript land: Node, Deno, Bun, TypeScript, JSX, all the browser implementations which may or may not support certain features, polyfills, transpiling, YOLOOOOO

So, use the framework for the prototype and maybe thru v1.x, then after you have better understanding of how it is actually used in the field and what architecture and patterns would work best in your team's situation, fully write the real app yourself (or, if the framework really works best, keep using it).

I've found taking the throwaway approach a bit further down the line pays big benefits; delaying full commitment to a particular path until you have a lot more information tends to work better.

Reply on news.ycombinator.com