270 karma · joined May 6, 2013
[ my public key: https://keybase.io/jaccarmac; my proof: https://keybase.io/jaccarmac/sigs/wfT7ILIs1wAwGEodEeUYGMB6L2KNBTcPayCvAcCUc84 ]
https://findkismet.com/: 0c450486af0df24c41506f8391f15cc85e7667fbfdb6668fee8987bdbc4aba5a
"Crashing is loud" below is a phrase to combine with "remote error recovery" from the link above. Erlang/OTP wants application structure that is peculiar to it, and makes that structure feel ergonomic.
> If I ship a feature that has a type error on some code path ... How is "let it crash" helpful to my customer?
The crash can be confined to the feature instead of taking down the entire app or corrupting its state. With a well-designed supervision structure, you can also provide feedback that makes the error report easier to solve.
However, while a type error in some feature path is a place that makes type annotations make sense, type annotations can only capture a limited set of invariants. Stronger type systems encode more complex invariants, but have a cost. "Let it crash" means bringing a supervisor with simple behavior (usually restart) or human into the loop when you leave the happy path.
But while I have had a broad interest in compilers for years and years, it feels difficult-to-impossible to actually complete any of it. Part of it's general depression and time management, part is looking at the long story of these projects and the lack of progression: Stuck in a rut of mediocrity.
https://github.com/rkoeninger/ShenSharp https://github.com/jaccarmac/junkcode/tree/79ea647d4ddbe41cf...
Hey, that's (close to) the traditional Smalltalk introduction-trick! And this has been available since 1.1? How does one concretely do that in Java and why is it not widely known?
https://www.dmagazine.com/frontburner/2024/04/a-voters-guide...
But I'll start with the simple version of the critique. Individual commuters make their decision about whether to make a trip based in part on the time that trip will take (a function of road congestion). Thus, adding road capacity will temporarily lower the cost of a trip, allowing more people to make it until congestion reaches the pre-expansion level. Housing does not have this problem because consumers make decisions about where to live much more infrequently.
As you can tell, "induced demand" is a bad if rather catchy name. To be fair to urban planners, the throughput of an expanded road does increase. However, the experience of using it stays the same or gets worse, and the cost (both $ and space) is disproportionate. Is the pro-transit argument, which I subscribe to.
Of course, the real world includes large real estate firms which are making frequent decisions on housing stock. So I agree that the build-more-housing-and-everything-will-improve crowd is wrong. But I don't think YIMBY/transit and anti-transit are the only choices. The former is a common archetype these days.
https://github.com/7max/log4cl/issues/41 https://github.com/sharplispers/log4cl/issues/45
> And I think [starting with anthropology] makes zero sense, since the goals, structure and size of hunter-gatherers bands and large work organizations are not even remotely comparable.
The relative size of these groups are obviously different.
The relative structure is exactly what is under discussion.
Relative goals: Now we're getting somewhere. There may be some people who "just want to code or get my brilliant ideas accepted without further discussion", but that doesn't seem particularly interesting to me. I - and I believe many other people - are interested in a society which achieves goals other than individual aggrandizement or increased production. Anthropology provides a perspective on what groups of people valued and to which degree they flourished. I suppose I might just be a simpleton, but supporting the weak and elderly read to me as rather worthy pursuits, not to mention hard problems.
> In this particular article, the hunter-gatherer remote work/lifestyle parallel is so forced as to be simply puzzling. First, hunter-gatherer groups were small and required very little coordination, whereas modern companies, when they are larger than a few hundred individuals (I am generous, I might say larger than a few dozen) require coordination overhead--being "on the same" page is quite important--which completely changes group dynamics.
I think that's part of the point. We've moved to a society where large-scale coordination is the norm, but, just like distributed computing, that coordination is a hard problem to solve. Who's to say that the management techniques we tend to implement are the best ones? There are certainly many workers who feel as if work is getting worse, and metrics which point to certain things getting worse or plateauing while capital-P Production rises.
I'm suspicious of easy answers about when humanity had it figured out or simple prescriptions, but if we are interested in evaluating the relatively young modern regime, there are worse places to start than anthropology.