Readit News logoReadit News
hbrn commented on Ask HN: How can I get better at using AI for programming?    · Posted by u/lemonlime227
ImPostingOnHN · 4 days ago
> this blast furnace would cost a fraction of other blast furnaces

Totally incorrect: as we already mentioned, this blast furnace actually costs just as much as every other blast furnace to run all the time (which they do). The difference is only in the outputs, which I described in my post and now repeat below, with emphasis this time.

Let's also imagine that the blast furnace changes behavior minute-to-minute (usually in the middle of the process) between useful output, useless output (requires scrapping), and counterproductive output ——>(requires rework which exceeds the productivity gains of using the blast furnace to begin with)<——

Does this describe any currently-operating blast furnaces you are aware of? Like I said, probably not, for good reason.

hbrn · 3 days ago
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 commented on Ask HN: How can I get better at using AI for programming?    · Posted by u/lemonlime227
ImPostingOnHN · 5 days ago
> Let's go with blast furnaces. They're definitely tools. They change over time - a team might constantly run one for twenty years but still need to monitor and adjust how they use it as the furnace itself changes behavior due to wear and tear (I think they call this "drift".)

Now let's make the analogy more accurate: let's imagine the blast furnace often ignores the operator controls, and just did what it "wanted" instead. Additionally, there are no gauges and there is no telemetry you can trust (it might have some that can the furnace will occasionally falsify, but you won't know when it's doing that).

Let's also imagine that the blast furnace changes behavior minute-to-minute (usually in the middle of the process) between useful output, useless output (requires scrapping), and counterproductive output (requires rework which exceeds the productivity gains of using the blast furnace to begin with).

Furthermore, the only way to tell which one of those 3 options you got, is to manually inspect every detail of every piece of every output. If you don't do this, the output might leak secrets (or worse) and bankrupt your company.

Finally, the operator would be charged for usage regardless of how often the furnace actually worked. At least this part of the analogy already fits.

What a weird blast furnace! Would anyone try to use this tool in such a scenario? Not most experienced metalworkers. Maybe a few people with money to burn. In particular, those who sing the highest praises of such a tool would likely be ignorant of all these pitfalls, or have a vested interest in the tool selling.

hbrn · 4 days ago
> 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 commented on Just talk to it – A way of agentic engineering   steipete.me/posts/just-ta... · Posted by u/freediver
bdangubic · 2 months ago
every one of the snarky comments like this on myriad of HN threads like this:

1. assumes most humans write good code (or even better than LLMs)

2. will stick around to maintain it

after 30 years in the industry and last 10 as consultant I can tell you fairly definitively that #1 cannot be further from the truth and #2 is frequent cause of consultants getting gigs, no one understand what “Joe” did with this :)

hbrn · 2 months ago
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 commented on Show HN: Specific (YC F25) – Build backends with specifications instead of code   specific.dev/... · Posted by u/fabianlindfors
hbrn · 2 months ago
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 commented on React is winning by default and slowing innovation   lorenstew.art/blog/react-... · Posted by u/dbushell
b_e_n_t_o_n · 3 months ago
The third example is missing the data binding that you get automatically with React. It should look more like this:

   function increment() {
     count += 1;
     dispatchEvent(new CustomEvent(
       "count-incremented", 
       { detail: { count } }
     ));
   }
I think I prefer not having to manage events all over the place.

hbrn · 3 months ago
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 commented on React is winning by default and slowing innovation   lorenstew.art/blog/react-... · Posted by u/dbushell
gloosx · 3 months ago
React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls.

In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on top of JS. No one wakes up saying "please let me write control flow in XML today"

The compiler tricks are neat, but React feels natural because it never asks you to stop writing JavaScript.

hbrn · 3 months ago
> 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 commented on Python type hints may not be not for me in practice   utcc.utoronto.ca/~cks/spa... · Posted by u/ingve
IshKebab · a year ago
> intention behind them was to contribute to readability

This is provably wrong. See https://peps.python.org/pep-3107/#use-cases

hbrn · a year ago
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 commented on Python type hints may not be not for me in practice   utcc.utoronto.ca/~cks/spa... · Posted by u/ingve
sethammons · a year ago
My previous unicorn rose despite the initial tech, not because of it
hbrn · a year ago
I gave you a selection of top 50 startups out of thousands funded by YC. You're giving me one anecdote.
hbrn commented on Python type hints may not be not for me in practice   utcc.utoronto.ca/~cks/spa... · Posted by u/ingve
IshKebab · a year ago
Proper engineering isn't that much of a concern when you have 0 customers, and by the time you have some it's too late to change.

Besides nobody is claiming that it's impossible to build a successful products with dynamic typing. It's just not as good. You can build a successful product with zero comments in your codebase, doesn't mean it's a good idea.

hbrn · a year ago
> 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 commented on Python type hints may not be not for me in practice   utcc.utoronto.ca/~cks/spa... · Posted by u/ingve
junyjujfjf · a year ago
They are likely leveraging Django/Rails which treads the beaten path for Startups.

Startups are also more likely to do monoliths.

For Enterprise & microservices, you will start to see more Java/Go/C#.

hbrn · a year ago
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.

u/hbrn

KarmaCake day1375July 27, 2022View Original