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

I recommend dialing in a mill before claiming there’s no craft in CNC.


It's a different craft. The whole thread is about the loss of the craft of coding, to be replaced with something else different.

The craft of blacksmithing is certainly different to that of dialing in a CNC, even if the outcome is both nails.


When LLMs transition from predatory pricing to rent seeking, the enthusiasm will evaporate.


CSS does suck because of the globals. Class names, ids, z index values are all areas where one commonly bumps into other developers in sometimes confusing ways.

But to the point of the article, it’s a technology one has to learn. There are name spacing solutions in css (layers) and around css (css modules, panda, tailwind, etc).

I think another challenge folks may have with CSS is thinking visually. It’s not automatic. In art school one learns both how to see and how to render, and generally learning how to see clearly is a bigger challenge than learning how to render.

Practice your craft.


I just heard about a related device from a family member who is an endocrinologist.

https://www.fda.gov/news-events/press-announcements/fda-clea...

First off, he had discomfort with the study methodology. Didn't go into details, but was surprised that the FDA was less conservative than himself in this case.

Secondly, it has been common in his practice for someone to have an unusual event. Someone does something out of the ordinary, they have an unusual circumstances, they don't adjust their treatment, and something goes wrong.

His question was -- does the device have a reset button? Is there a way to restart the management and learning? The answer is no -- the device will learn! But there's no way for the patient or the physician to adjust the treatment. So his answer is -- he would never recommend this device, not the way it's currently setup. It's opaque and there's no means for a person to influence the device's learning.


This is just monitoring, not a pump. There is no learning or tuning or dosing. If it’s anything like the Freestyle I wore for a while there’s a self calibration process that takes a couple hours, but that’s per-sensor, and those get changed out every two weeks.


You are correct, I think he was talking about a different device:

https://www.fda.gov/news-events/press-announcements/fda-clea...


I will point out the obvious tensions between these legitimate concerns and the usual HN "we demand full unfettered access to all the firmware knobs all the time" groupthink.


> But there's no way for the patient or the physician to adjust the treatment.

This does not parse. This device is for patients that are managed with oral meds and not insulin. Yes, sulfonylureas carry some risk of hypoglycemia, but not as much as insulin proper and its fast- and slow-acting friends.

If someone is on a pump, they sure as heck will be using prescribed equipment.


Note that one big database can decimate productivity as well.


Is it about process space and programming languages? Or is it about source control and CI architecture?

How is a monolith different from a monorepo?


It works extremely well for ux development ;-)


He's been slightly famous for technical writing for a long time

https://en.m.wikipedia.org/wiki/Eric_S._Raymond


This seems a very nostalgic take.

So long as websites pretend they are documents, they will remain bloated poorly performing synchronous applications.

Accept that websites are distributed applications and deliver great experiences.


> So long as websites pretend they are documents, they will remain bloated poorly performing synchronous applications.

I disagree.

Most websites (99%) are just barely interactive documents with buttons.

The bloat we suffer today is because we ship them and design them as full interactive App when it's absolutely not needed.

Why this happened ? Because the current tooling make it easy. Not because it is the right design.

The "distributed application" is just a bullshit fashion of a time. very little applications require the current level of complexity compares to the features they give.

They are like they are because "create-react-app" and "npm install world" is easy.


I agree with you. However, making a great single-page app takes a lot of experience and work, a bit less so with current frameworks, but still. A lot of in-house SPAs are truly terrible, with bad performance and broken navigation, you wish the developers wouldn’t have bothered. Multi-page apps might be a bit harder to screw up as badly.

So maybe the user experience hierarchy goes something like: great SPA > MPA > average SPA?

This would mean there’s still a place for MPAs, at least with certain budget constraints.


> “However, making a great single-page app takes a lot of experience and work, a bit less so with current frameworks, but still.”

So what? Get experience. The days of a plucky developer throwing together some simple page he built over a weekend while reading a programming book and having that be good enough for millions of people around the world are over.

Users will require richer and deeper experiences and that will breed a demand for some developers who actually know what they are doing, and possess a vast experience to draw insights from.


It depends what the app is, surely? The problem is too many things that should just be displaying a single document instead produce a bloated SPA with worse usability. Medium is probably the archetype of this.


And I think all apps and websites should work like that.

Currently the web doesn't work without JavaScript, which I find very alarming.


Don't debate coding standards beyond the 2 pizza rule. No more than 8 engineers per service.


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

Search: