Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
vacuity
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
30 ms
·
421.
▲
by
vacuity
2y ago
But you're waiving implementation/design (which is not just particular coding choices) and pointing out how a highly simplified, high level concept is useful. But what makes Kubernetes or Linux useful is that there is a concrete i
422.
▲
by
vacuity
2y ago
We should be rational creatures first. That isn't really achievable, and I resent that, but I think it's still a goal worth having. And of course one needs power in some form or another, whether that's the capacity for physic
423.
▲
by
vacuity
2y ago
I think both of you are building up the notion that we are built for bullying, which I say is true. We are social and emotional creatures first and rational creatures second. The solution requires people standing up and being firm but respe
424.
▲
by
vacuity
2y ago
I have some issues with the sentiments in this thread, which seems to be saying that stories are good in real life discourse too. To some extent I agree, but I think it is overexaggerated. TL;DR: This is all well and good in current society
425.
▲
by
vacuity
2y ago
> Why we would assume that it functions differently is beyond me. The cognitive bias to put some people on a pedestal and worship them for being extraordinary. The perceived rareness and specialness of absolute pitch.
426.
▲
by
vacuity
2y ago
I think your points are mainly issues with determining that an experimental treatment actually has a significant effect. They aren't as relevant to explaining how the control group experiences an impact. I've heard that patients a
427.
▲
by
vacuity
2y ago
Also, we know placebos exist and in fact are expected to exist in medical trials, but...how? Why? Can we control this? Evidently we're seeing something , and we've incorporated it into scientific understanding, but only at a high
428.
▲
by
vacuity
2y ago
Indeed, although I think people "on the right side of history" (whoever they may be, fill in the blank yourself) would (could) do a bit better to ensure they use violence as a last resort. Never too late is crucial, but never too
429.
▲
by
vacuity
2y ago
I think you're both right in that we need standards, and we'll get them but with fractures, but at the same time we could try harder to reduce the incidence of fractures. Because at the end of the day this is all a social problem,
430.
▲
by
vacuity
2y ago
I've thought that we should be able to move so fast with software, and sometimes I see that successfully, but usually it seems like we leverage computers' superior performance poorly. To pick on frontend, it's trivial to crea
431.
▲
by
vacuity
2y ago
The biggest roadblock is, as always, backwards compatibility. The second biggest is getting people to agree to standardization and documentation, solidifying the expected base of knowledge. All in all, I don't have much hope for mainst
432.
▲
by
vacuity
2y ago
It's you again! Hi. We talked about capabilities a while back. > I am not sure yet how to handle this in a suitable way within a process If this is about implementing capabilities, I think partitioned capabilities should be the defa
433.
▲
by
vacuity
2y ago
Common resources lead to a free market failure exactly in the sense that they are not considered property: instead, they are free for the taking. Or perhaps it's your use of the word "proper" that is crucial here. Also, how d
434.
▲
by
vacuity
2y ago
And yet we see a lot of instances in free market economies. If you're going to talk Marxism, address actual criticisms (of which there are plenty) and not reactive Red Scare-type boogeymen.
435.
▲
by
vacuity
2y ago
Counterpoint: the OS should indeed do its job of scheduling, but applications sometimes know better (the ones specifically implemented by programmers who know better). The OS and application must cooperate to do big jobs like scheduling.
436.
▲
by
vacuity
2y ago
> Signals are of two forms: the one is asynchronous, the other synchronous. The one should be replaced with a generic message queue in a technical debt free design. The other is debatable. Unfortunately, sychronous signals of some form a
437.
▲
by
vacuity
2y ago
Which is why parent is calling for standardization, so that people don't usually need to be experts. I reject that there are a diverse range of async abstractions that are all justified such that a given OS only supports some well. Mor
438.
▲
by
vacuity
2y ago
This is wishful thinking. It would be nice, I agree, but. Even "guaranteed lower bound of optimization" for general purpose programs is off the table. Our tools for programming should be such that easy problems are easy to solve,
439.
▲
by
vacuity
2y ago
~1h a day, so half a month. I use my laptop far more often, so naturally it's a lot different than a phone in when I use it and for how long, and of course what I'm using it for. On most days my overall screen time (phones, comput
440.
▲
by
vacuity
2y ago
I agree that China should be regarded as a particularly problematic country, but I would like the US to have a more comprehensive and introspective attitude. The US can stop the mutual bullying and take the high ground. That doesn't ch
441.
▲
by
vacuity
2y ago
To be fair (?), the title seems like classic clickbait. The thesis seems to just be > While I agree that epoll doesn’t come close, I think that’s actually a feature that has lead to a much more flexible and composable design. You could r
442.
▲
by
vacuity
2y ago
I don't know that there were relevant changes between the advent of each, so much as kqueue just didn't have existing features in mind. I assume GP is referring to the ring buffer design and/or completion-based processing, as
443.
▲
by
vacuity
2y ago
I too would like to know more about @karaterobot's specific circumstances here, because while I understand your sentiment, it's a numbers game for SWE applicants like me. Of course there are some companies I would prefer to work a
444.
▲
by
vacuity
2y ago
Perhaps, but isn't it flexible because complexity was hidden?
445.
▲
by
vacuity
2y ago
To add on to your great comment, I've read a few papers that justify your remarks, but some have paywalls and I'll try to condense them anyways. Parnas' criteria for when to split code into modules[0] is very compelling: modu
446.
▲
by
vacuity
2y ago
I agree with what you're saying, and I would phrase it as "write the abstractions that reflect the essential complexity". The whole program should minimally reflect the essential complexity of the problem. Of course actually
447.
▲
by
vacuity
2y ago
As someone who has little experience in this topic but has come to a similar conclusion, I think the main downside of this strict separation you're recommending is performance/efficiency. Have you noticed that to be a problem in p
448.
▲
by
vacuity
2y ago
Initial implementation and maintenance need to keep design in mind, and there should be more clarity around responsibility and costs of particular designs and how flexible the client is with the design at a given point in time. It's an
449.
▲
by
vacuity
2y ago
In Rust, crates and not modules are the unit of compilation. Hot reloading is a whole other problem for the Rust ecosystem. You'd probably have to build it yourself or buy into a whole engine.
450.
▲
by
vacuity
2y ago
I think you forgot the analogy. Why is it bad to have semicolons in programs then? > You become keenly aware of the fact that 90% of your mental effort is going not towards actually solving the problem at hand, but appeasing the compiler
More ›