HackerTrans
TopNewTrendsCommentsPastAskShowJobs

hbrn

no profile record

comments

hbrn
·há 4 meses·discuss
>all you need to do to make an agentic RAG is to have the LLM be able to write/rewrite its own search queries (possibly in multiple passes)

I think this is a huge oversimplification, the term "search query" is doing a lot of heavy lifting here.

When Claude Code calls something like

  find . -type d -maxdepth 3 -not -path '*/node_modules/*'
to understand the project hierarchy before doing any of the grep calls, I don't think it's fair to call it just a "search query", it's more like "analyze query". Just because text goes in and out in both cases, doesn't mean that it's all the same.

When you give the agent the ability to query the nature of the data (e.g. hierarchy), and not just data itself, it means that you need to design your product around it. Agentic RAG has entirely different implementation, product implications, cost, latency, and primarily, outcomes. I don't think it's useful to pretend that it's just a different flavor of the same thing, simply because at the end of the day it's just some text flying over the network.
hbrn
·há 4 meses·discuss
While it's true that people are naturally predisposed to invent the "secret quantizing" conspiracy regardless of whether the actual conspiracy exists or not, I think there's more to the story.

I've seen Sonnet consistently start hallucinating on the exact same inputs for a couple hours, and then just go back to normal like nothing ever happened. It may just be a combination of hardware malfunction + session pinning. But at the end of the day the effects are indistinguishable from "secret quantizing".
hbrn
·há 4 meses·discuss
> it's ridiculous to reserve the term "RAG" for just the earliest most basic implementation

Whether we like it or not, dumb semantic search became the colloquial definition of RAG.

And when you hear someone saying "we use RAG here" 95% of the time this is exactly what they mean.

When you inject user's name into the system prompt, technically you're doing RAG - but nobody thinks about it that way. I think it's one of those case where colloquial definition is actually more useful that the formal one.

> doing it properly doesn't require a fundamentally different technique

But agentic RAG is fundamentally different.
hbrn
·há 7 meses·discuss
The furnaces I'm comparing are Claude Code vs hiring more engineers. Not Claude Code vs Codex vs Gemini. If $20/mo makes an engineer even 10% more productive, purchasing Claude Code is a no-brainer.

Most engineers feel like Claude Code is a multiplier for their productivity, despite all the flaws that it has. You're arguing that CC is unusable and is a net negative on the productivity, but this is the opposite of what people are feeling. I am able to tackle problems I wouldn't even attempt previously (sometimes to my detriment).
hbrn
·há 7 meses·discuss
> What a weird blast furnace! Would anyone try to use this tool in such a scenario? Not most experienced metalworkers.

Absolutely wrong. If this blast furnace would cost a fraction of other blast furnaces, and would allow you to produce certain metals that were too expensive to produce previously (even with high error rate), almost everyone would use it.

Which is exactly what we're seeing right now.

Yes, you have to distinguish marketing message vs real value. But in terms of bang for buck, Claude Code is an absolute blast (pun intended)!
hbrn
·há 9 meses·discuss
1. Humans are capable of writing good code. Most won't, but at least it's possible. If your company needs good code to survive, would you take 5% chance or 0% chance?

2. Even when humans write crappy code, they typically can maintain it.
hbrn
·há 9 meses·discuss
Funny, I've spoken about something like this to a colleague couple weeks ago. This could be a future of software development we're headed towards, if the DX is done right.

There are definitely cases where the spec is much easier to understand than the code that implements it.

Think systems with complex lifecycles or lots of required boilerplate.

Have you thought of embedding the specs into existing code?

E.g.

  # @spec: if any method takes longer than 1s to execute, a warning must be logged

  class X: ...
hbrn
·há 10 meses·discuss
Third example was supposed to be Svelte.

Vue also isn't too far:

  function increment() {
    count.value += 1
  }
In 2025, React state management is complete shitshow compared to Svelte and Vue.

How in the world people are claiming "React is just Javascript" is beyond me.
hbrn
·há 10 meses·discuss
> React feels natural because it never asks you to stop writing JavaScript

I want to increment some counter on the webpage. Which approach feels natural?

  increment = () => {
    this.setState((prevState) => ({ count: prevState.count + 1 }));
  };

  const increment = () => setCount((count) => count + 1);

  function increment() {
    count += 1;
  }
No one wakes up saying "please let me mutate simple state with function calls".
hbrn
·há 2 anos·discuss
Have you read the whole section?

> Documentation for parameters and return values ([23])

> Let IDEs show what types a function expects and returns ([16])

> For example, one library might use string-based annotations to provide improved help messages, like so:

  def compile(source: "something compilable",
    filename: "where the compilable thing comes from",
    mode: "is this a single statement or a suite?"):
hbrn
·há 2 anos·discuss
I gave you a selection of top 50 startups out of thousands funded by YC. You're giving me one anecdote.
hbrn
·há 2 anos·discuss
> It's just not as good

Again, the evidence (as limited as it is) suggests otherwise. You are more likely to succeed if you're going with dynamic language and not doing "proper engineering". This has been widely accepted before type-checker era, and I see no reason why it would be different now. Utilize type checker when it's free, but don't waste time on type puzzles.

"Proper engineering" doesn't get you to product-market fit faster. All it does is tickle your ego.
hbrn
·há 2 anos·discuss
I would expect dynamic type crowd to embrace microservices first, given how everybody says that dynamic codebases are a huge mess.

Regardless, to me enterprise represents legacy, bureaucracy, incidental complexity, heavy typing, stagnation.

I understand that some people would like to think that heavy type-reliance is a way for enterprise to address some of it's inherent problems.

But I personally believe that it's just another symptom of enterprise mindset. Long-ass upfront design documents and "designing the layout of the program in types first" are clearly of the same nature.

It's no surprise that Typescript was born at Microsoft.

You want your company to stagnate sooner? Hyperfixate on types. Now your startup can feel the "joys" of enterprise even at the seed stage.
hbrn
·há 2 anos·discuss
Large programs are harder to maintain because people don't have the balls to break them into smaller ones with proper boundaries. They prefer incremental bandaids like type hints or unit tests that make it easier to deal with the big ball of mud, instead of not building the ball in the first place.
hbrn
·há 2 anos·discuss
How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go?

https://charliereese.ca/y-combinator-top-50-software-startup...
hbrn
·há 2 anos·discuss
> Most code with type hints is easier to read

That has not been my experience in the past few years.

I've always been a fan of type hints in Python: intention behind them was to contribute to readability and when developer had that intention in mind, they worked really well.

However, with the release of mypy and Typescript, engineering culture largely shifted towards "typing is a virtue" mindset. Type hints are no longer a documentation tool, they are a constraint enforcing tool. And that tool is often at odds with readability.

Readability is subjective and ephemeral, type constraints (and intellisense) are very tangible. Naturally, developers are failing to find balance between the two.
hbrn
·há 2 anos·discuss
What's even worse, when typing is treated as an indisputable virtue (and not a tradeoff), pretty much every team starts sacrificing readability for the sake of typing.

And lo and behold, they end up with _more_ design bugs. And the sad part is that they will never even recognize that too much typing is to blame.
hbrn
·há 2 anos·discuss
> Writing software without types lets you go at full speed. Full speed towards the cliff.

Isn't it strange that back when Python (or Ruby) didn't even have type hints (not type checkers, type hints!), it would easily outperform pretty much every heavily typed language?

Somehow when types weren't an option we weren't going towards the cliff, but now that they are, not using them means jumping off a cliff? Something doesn't add up.
hbrn
·há 3 anos·discuss
> he already added unforeseen couplings that could get out of hands if it was a big codebase

And one should be able to fix things that get out of hand when they start getting out of hand. Architecture should be based on current facts, not on our fantasies about the future.

For some reason we're always making this weird assumption that future engineers working on a problem are going to be less capable than us. So we decouple things in advance for them. Those future idiots won't know how to architect for scale, but we, today, with our limited domain expertise, know better.

The reality is that in most cases we are those future engineers. And, unsurprisingly, "future we" tend to know more, not less.
hbrn
·há 4 anos·discuss
> would it also be able to scale with increase in visitor traffic? would it be able to deal with increase in media uploads

Yes.

It's not a social network / advertising machine. Hosting is a tiny fraction of Wikimedia spending: a mere $2.4M in 2021. I was surprised to learn they spend more on awards and grants than on hosting.