HN2new | past | comments | ask | show | jobs | submit | smrq's commentslogin

You might wish to do some cursory research before arguing further. For example, as a starting point, the Wikipedia page on civil disobedience has an entire section labeled "Action" listing counterexamples.

Why is this approach better than the author's?


Alright, I'll bite. What about imperative programming fixes the scaling issues you're describing?

Typically programming scale is regarded as a benefit of FP over imperative programming, as the lack of mutable state results in less moving parts to reason about.


Part of it is solved by how longer files are much more readable in imperative setups and can benefit from things like an editor/IDE being more able to jump around within the file since it’s not a big tangled up deeply nested chunk and developers can add things like titled section dividers for the editor to latch onto.

And no language will fix all these woes on its own, but problems take a lot longer to crop up with a disciplined team in an imperative app compared with a declarative one.

FP probably does scale better when we’re talking about the nuts and bolts under the hood, but I don’t believe it’s well suited for UI except in the simplest of cases. There’s too much in that domain that’s at odds with the nature of a declarative/functional approach.


How often do you suppose they will be re-checking your ID? Once every... never?


They need to have an always-on camera looking at the person using the device. No camera, no discord.


This may seem like hyperbole, but this is the reality for students and test-takers every day in virtual environments now.

I assisted as TA in a virtual learning environment. While we didn't make it strictly mandatory to keep the camera on, our learners were encouraged to do it, and we kept tabs on who was "engaged" and present, because at the very least, we needed to tabulate an attendance roll for every day.

If you're taking a standardized test, whether you're at home or in a controlled lab, the camera will always be on. Multiple ones. Not optional.

There is a large storm of controversy on college campuses about adapting young students early to surveillance cultures. I attended a community college about 7 years ago, and I felt I'd be a second-class citizen without a smartphone and an SMS'able mobile.

We weren't surveilled through smartphones at the time. But there was an app to receive campus alerts about public safety and other crisis events. And our virtual class sessions had various ways of ensuring we were human, and awake.

Taking finals and certification exams, I was often sat in a special-purpose testing center, and Step One was showing ID; Step Two was surrendering my watch, my phone, my wallet to place in a locker outside. So, students simply become accustomed to showing ID and being on-camera, and it becomes a fact of life before you graduate.


"My Toyota Corolla struggles to drive up icy hills." "It doesn't struggle, you struggle." ???

It's fine to critique your own tools and their strengths and weaknesses. Claiming that any and all failures of AI are an operator skill issue is counterproductive.


Vue and Svelte both introduce too much mystery-symbol syntax for my taste, and two way data binding has felt bad since Angular 1.


"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.


I'm going to start using this logic whenever my wife talks about my office.


Give your user NOPASSWD if it's really that bothersome. You can also potentially set it up to use a fingerprint reader if you have that hardware.


Yep on the terminal that would work... though I still think it should be the default.

On the other hand I'm not sure NOPASSWD would affect desktop environments - any desktop stuff goes via PolicyKit or whatever the latest systemd iteration is and I doubt it's smart enough to read Sudo's config (and there's an argument it shouldn't - if anything it should be the other way around, a system-wide generic "this is single-user machine, the only user is effectively root anyway" flag that both Sudo and Polkit should obey).

In both cases yes it's solvable, but I wish it became the default if there are no other interactive user accounts, or at least be easy to configure - if anything, by a simple "don't ask me again" on the permissions popup.


I mean, you get what you signed up for. If you wanted total stability and infrequent updates then why would you use Arch? (If the answer is "I didn't know what I signed up for" then that's fair. Simply understanding the practical differences between distros is a huge hurdle.)


I love how the opening paragraph makes a good canonical explanation for what are otherwise continuity errors!


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

Search: