HN user

jefb

269 karma
Posts1
Comments52
View on HN

Can't believe it's come down to this in 2026, but if this does not beep incessantly and slam on the brakes when maneuvering around some foliage I'm all in.

I meant it when I said these smaller models are great. They open up entirely new use cases and I appreciate the work that went into creating them.

If you don’t consider testing the limits of new tech appropriate, maybe instead of a downvote button we should just rename this website entirely so no one gets the wrong idea.

My lovely interaction with the 270M-F16 model:

what's second tallest mountain on earth?

The second tallest mountain on Earth is Mount Everest.

what's the tallest mountain on earth?

The tallest mountain on Earth is Mount Everest.

whats the second tallest mountain?

The second tallest mountain in the world is Mount Everest.

whats the third tallest mountain?

The third tallest mountain in the world is Mount Everest.

what's the forth tallest mountain?

The forth tallest mountain is Mount Everest.

but you said the tallest was Everest already

You are right! I'm glad to hear that.

so whats the second tallest?

The second tallest is *Mount Everest*.

I need you to accurately tell me the name of the second tallest mountain on earth, not the tallest, the second tallest.

The second tallest mountain on Earth is Mount Everest.

The tallest mountain on earth is mount everest. What is the second tallest mountain?

The second tallest mountain on Earth is Mount Everest.

Give me a list of the tallest mountains on earth

The tallest mountain in the world is the *Mount Everest*.

give me the top 5 tallest mountains on earth

The tallest mountain on Earth is Mount Everest.

List in order the tallest mountains on earth from 1 to 5

1. Mount Everest 2. Mount K2 3. Mount Sahel 4. Mount Fuji 5. Mount McKinley

So the second tallest mountain on earth is K2

The second tallest mountain on Earth is Mount Everest.

These smaller models are great, but they really feel like talking to a toddler sometimes!

Because this storage system’s query language is more powerful than the underlying one’s, its read operations in general may overfetch and then filter results.

Seems like this is the crux of the problem. Migrating and/or replicating data to an underlying data layer that supports the required query logic probably makes more sense?

The feature where it tells me the weather.

I'd say there's about a 80% chance that it loads the forecast in under 5 seconds.

Loading the radar has far worse performance - it only works ~50% of the time and failures just show an empty map forever.

When it does manage to load the weather I've found the accuracy to be hot garbage.

I can't bring myself to believe that bollards are the answer. Placing them everywhere would be exceptionally expensive. Emergency vehicles would get stuck in traffic more often. Car accidents involving bollards would be more dangerous to drivers and do more costly damage to cars.

While I agree that pedestrian lives would be saved, the net cost to human life likely remains unchanged.

Very cool graphic. However emphasizing the juxtaposition between pictures of wood joints on the internet and actual real-life wood joints with the phrase "digital" is a bit perplexing.

There's no right answer.

I suspect a few things are going on here.

1. The teacher forgot to include that the University wants 100 responses to the survey. 2. Missing answer C likely contains something like "Randomly select 14 more students to receive the survey"

That makes it an actual statistics question, you'd need to calculate the response rate from the original 120 and then compute the additional solicitations required to meet the response count goal of 100.

Hooks are obviously not stateless - I'm saying they were an inevitable consequence of the push towards functional components and that they represent an inferior development experience. No one needed to write 2000 words on how to use setState.

React's push towards a functional model with all the use* hooks is so sad to watch.

A stateless programming model in a domain where state is so fiercely coupled to program utility is inevitably going to spawn this garbage.

Class based components with MobX managing state was, and still is, a dream to write __and__ read.

The perquisite to successful DAO's is actually a strong centralized universal identity system (which is ironically counter to cryto-bro anarcho-capitalists philosophies).

From there it's pretty easy to associate real political capital with digital decisions.

E.g. Automatic n+1 "ban proposing user" option added to all proposals. If after n votes (where n is large) the sum(ban proposing user) > 0.25*sum(all other options), proposal is removed and user is banned until a proposal to unban is passed.

I think we're largely in agreement here e.g. I agree 100% that premature abstractions hold a lot of inertia. I'm just advocating for making decisions that optimize for "the right thing" over speed alone. In my experience the right thing tends to be adaptation, but that's because I do a lot of R&D work.

Sometimes yes, you can eat your cake and have it too w/r/t performance and flexibility; but the choice of programming language cannot be categorically relegated to "always pick the fastest one". There are no silver bullets, there will always be tradeoffs.

Flexibility matters, ecosystem matters, developer experience matters, third party libraries matter, good requirements (or lack thereof) matter, budget matters, timeline matters, security matters, and yes, performance also matters - it's just not the only consideration.

High level design decisions, language included, are not "pessimized by default" because they deem some of those other considerations more important than speed.

From my experience most of your assertions have a hidden assumption that the software requirements are complete and they are good. Computing something 10000 times faster is useless if it turns out to be the wrong computation. Furthermore, things that run 10000 times faster than other things tend to be harder to adapt and change.

Requirements that are good enough to warrant a 5 second page load time being "unacceptable" must have, at some point, been prototyped with real use cases, real data, and in real environments.

Getting to that point - where the business case is connected with such a strong through-line to the user experience can literally take years. Early in a project lifecycle it's more important to design software that is easy to change than software that is fast.

Language choice does not matter, performance does not matter; the design philosophy of the developer(s) when building something new is everything. That philosophy should be "I'll likely have to change this" not "I need to make sure this runs quickly". Any high level design decisions should be made with the former in mind, not the latter.

Once you've earned that product wisdom, sure - carve out the slow thing and write it in CUDA or something. If things are easy to change, that's not a scary proposition; it's just part of the natural project lifecycle and Knuth lives to die another day.

Subsidies are keeping cow COGS artificially low. Removing them would increase the cost to raise a cow; selling it for more money does not necessarily lead to more profit. This is the difference between gross profit and net profit... and we're not even taking into account what the market is willing to pay for a burger in the first place.

Yesterday free speech was so important that platforms must syndicate all topics equally and fairly. Today these platforms are so extremely dangerous to society that they should be shut down entirely.

I’m not a fb apologist by any means, but maybe we should stop blaming these websites for everything and invest in education instead.