Hacker Newsnew | past | comments | ask | show | jobs | submit | joshfee's commentslogin

I see both sides of this argument and am really not sure which side I land on. But I wonder if this fits into things like driving, where hey - done recklessly this is dangerous to yourself and others around you, so we require some level of targeted education (e.g. a license). Then if you choose to be reckless anyway its a bit easier to say "it was your own fault".

I bet you credit providers would even front the cost of such a course, since at the end of the day they're still likely to make that money back no matter what.

I think the part that I struggle with is the hard reality that we are largely _not_ teaching people these practical skills in our education system and then expecting them to not get screwed.


In my mind, the externalities of reckless driving are much greater than getting credit on bad terms.


Until, of course, tens of millions of people are taking BNPL loans with 20% interest rates willy nilly. Then when they default, it triggers an economic crisis that affects every single person in the country.


For those interested in leveraging AI to build circuit boards, check out https://tscircuit.com/

I have no affiliation to the project, just someone that's done some hobby PCB design in the past and a couple weeks ago was exploring what's available in age of AI. Flux looked expensive and unimpressive. While it definitely burned through some tokens, I was able to get a seemingly functional PCB meeting my design requirements and was able to iterate on it using my existing Claude code subscription. I did use Gemini for some of the initial design research and parts selection since I find its search a bit better, but was overall impressed. I think with some tuning of the Claude skills to have it do a bit less guess-and-check it could be a nice workflow. Definitely better than the either really dated or really expensive PCB design tools in the market.


How about doing it properly and without a bunch of poor design decisions ?


Isn't that true for any scenario previously unencountered, whether it is a digital simulation or a human? We can't optimize for the best possible outcome in reality (since we can't predict the future), but we can optimize for making the best decisions given our knowledge of the world (even if it is imperfect).

In other words it is a gradient from "my current prediction" to "best prediction given my imperfect knowledge" to "best prediction with perfect knowledge", and you can improve the outcome by shrinking the gap between 1&2 or shrinking the gap between 2&3 (or both)


It is great being able to generate a much larger universe of possibilities than what they can gather from real world data collection, but I'd be curious to learn how they check that the generated data is a superset of the possibility-space seen in the real world (e.g. confirm that their models closely match what is seen in the real world too)


It is actually one of the few cases where I don't actually really care about independent upgradability. In my experience I find that I pretty much always upgrade my CPU and my RAM in tandem. New CPU architectures sometimes force it (e.g. need DDR5 instead of DDR4), and as long as you don't severely undersize your initial RAM choice I find that I run out of CPU headroom before I run out of RAM headroom.

So if there's performance gains to be had by co-locating RAM with the CPU in a single package, it makes sense to me to do so


> and as long as you don't severely undersize your initial RAM choice

That's the problem though. when dealing with used machines (because new ones are beyond your budget), you get cheaper hand me downs, and those are going to be of your undersized RAM variety. In the socketed days, you could get a five year old laptop, replace the existing RAM with the biggest sticks you cloud get your hands on, and get a few more years of life out of the machine. A laptop stuck at four gigs of ram these days isn't going to be great for much web browsing, but is also basically stuck at four gigs.


But you are also only a camera without LIDAR or RADAR, and you apparently navigated that situation successfully...


You can use a string union to discriminate when it makes sense, but that's not the only way to discriminate and in this case you'd instead use the presence of the items themselves (essentially duck-typing with strong type guarantees)

Typescript playground: https://www.typescriptlang.org/play/?#code/C4TwDgpgBACg9gZ2F...


Now you run into the issue I mentioned in GP, where you end up writing `if (blah)` everywhere, even though you know that `blah` is definitely present.


How you define "external stuff" matters though. As soon as your function is calling another function, your test can be argued to be an "integration test", as you're now implicitly also testing the logic of the other function.

Alternatively you mock _everything_ and then your "unit test" ends up just being a tautological test asserting that "the code I wrote executes in the way I wrote it". (Not to mention that every time you mock something you are also implicitly asserting what the expected behavior of that thing is).

The only truly reliable tests are E2E tests, but they are too expensive to cover all possible permutations as there are just too many.

This is the catch 22 with testing, and we're always forced to make pragmatic choices about where to draw our boundaries to maximize the value (i.e. actual bugs caught) of them.


Functions, in the sense that there are global variables, is strongly discouraged by the language. It's usually much easier to define a type so there is a clear delineation.

That is, from Mongo, you use Serde and wind up with only valid records operated upon, of a table of such values.


By external I mean anything outside the compiled executable.

Or anything that you have to use ipc like sockets or shared memory.


The problem with enforcing "freedom of speech" on private parties is that it essentially the same as infringing the speech of that private party.

The only issue I have is when companies can play both sides and in one breath claim they're neutral for the purpose of section 230 protection, and then in the next breath take part in censorship because it's better for business.

Pick a lane, either lane, but you shouldn't get it both ways


> The only issue I have is when companies can play both sides and in one breath claim they're neutral for the purpose of section 230 protection, and then in the next breath take part in censorship because it's better for business.

The entire point of §230 is to immunize companies for the consequences of that which you decry as censorship (i.e., moderation).


Forget about reading articles even... the supreme court decision itself is not long, is written in understandable language, and breaks down point by point the things that they had to consider, why they had to consider them, and the outcome of that consideration.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: