HN user

nz

1,102 karma

Feckless Gadabout, Systems Programmer

webpage: https://galacticbeyond.com

github: github.com/galactic-beyond

github-legacy: github.com/nickziv

Posts107
Comments124
View on HN
openthemagazine.com 9d ago

The Second Life of Sanskrit

nz
3pts0
github.com 10d ago

Micro-JavaScript: A pure Python JavaScript engine, inspired by MicroQuickJS

nz
3pts0
users.ece.cmu.edu 2mo ago

Reflections on Trusting Trust (1984) [pdf]

nz
2pts0
www.minimalfab.com 2mo ago

Minimal Fab Promoting Organization

nz
8pts1
ecf.ca8.uscourts.gov 2mo ago

United States of America vs. Matthew David Keirans [pdf]

nz
3pts0
www.buzzfeednews.com 3mo ago

Silicon Valley Is Turning into Its Own Worst Fear (2017)

nz
1pts0
web.archive.org 4mo ago

Riau Indonesian: The Simplest Language in the World?

nz
1pts0
www.biyubi.com 4mo ago

Familia Toledo: Desarrollos Tecnológicos

nz
3pts3
www.krsaborio.net 4mo ago

Larry McVoy Interview by KernelTrap

nz
1pts0
localroger.com 4mo ago

The Metamorphosis of Prime Intellect (1994)

nz
2pts0
www.youtube.com 4mo ago

Novelist interview-Chuck Palahniuk [video] (2024)

nz
2pts0
archive.computerhistory.org 6mo ago

What a Programmer Does (1967) [pdf]

nz
100pts16
www.laphamsquarterly.org 6mo ago

Web Du Bois on the beauty of sorrow songs (1903)

nz
1pts0
en.wikipedia.org 6mo ago

Star Guage

nz
1pts0
www.reuters.com 1y ago

China to publish policy to boost RISC-V chip use nationwide

nz
6pts0
en.wikipedia.org 2y ago

Kenning

nz
4pts1
nautil.us 2y ago

The Kekulé Problem

nz
3pts0
plato.stanford.edu 3y ago

Combinatory Logic (2020)

nz
119pts21
hcibib.org 3y ago

HCI Bibliography: Human-Computer Interaction Resources

nz
32pts1
plus.maths.org 3y ago

What Is a Square?

nz
1pts0
jhiblog.org 3y ago

‘Restoring Beds, or Wombs’ and a Feminist-Materialist Quest for Everlasting Life

nz
3pts0
threadreaderapp.com 3y ago

Thread About Space Based Solar Power

nz
3pts0
tedgioia.substack.com 3y ago

The Remarkable Diaries of Composer Ned Rorem

nz
2pts0
www.erasmatazz.com 3y ago

What Is the Essence of Computing? (2017)

nz
44pts20
www.erasmatazz.com 3y ago

We Don't Understand Computers (2017)

nz
15pts3
web.archive.org 3y ago

Why Software Sucks

nz
3pts2
web.archive.org 3y ago

The Evolution of Stories

nz
4pts0
web.archive.org 3y ago

History of Thinking

nz
2pts0
ia801603.us.archive.org 3y ago

In Praise of Idleness and Other Essays by Bertrand Russel (1915) [pdf]

nz
1pts0
medium.com 3y ago

Pipino: Gentleman Thief

nz
1pts0

With the exception of _one_ company that I worked at, pretty much every[0] company was a struggle between engineering and management. Engineering wants to get the software correct, and management wants to fire-hose features into the market. Most of the time (so more than half, at least), management tends to have a compulsion to mindlessly imitate what other companies/competitors are doing, usually without prioritization (so even if feature-parity is a good idea, usually management will want to prioritize whatever the newest feature is, and to put existing work on the back-burner). It very frequently feels like management is making strategic decisions after snorting a long line of social-media-psychosis and TED talks. It is remarkable that investors have any faith in such founders/entrepreneurs at all.

[0]: Various people I know do not even have the luxury of that one good company. Also, it -- unbelievably -- sounds much worse at other companies.

Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment.

The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.

It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.

Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.

I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).

[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.

[1]: You can find a (fair warning: long) PDF here: https://galacticbeyond.com/pdf/two-percent-programmer.pdf

[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).

Yeah, that is situation 2 mentioned above. A Chomsky Grammar is also a generator. So it can generate valid inputs, and then turn them into valid outputs -- and it can do the first part stochastically/randomly.

So, take a look at my previous comment (I am sibling, not parent). The pencil pushers are still being manufactured by the educational system itself, but they major in Business now, not Social Sciences or Education. This is due to government policy from 1980s incentivizing the creation of more business entities (they each need accountants, and managers, and so on), which caused a few generations of people to go down that route. The tragedy here is that these generations have internalized the idea that the practical and profitable is more valuable than the aesthetic and beautiful. Instead of cultivating human beings that can contemplate and appreciate, we are cultivating human beings that can analyze and optimize (this is fine, but it is possible to have too many of them, which creates a competitive dynamic that _everyone_ has to participate in, that _nobody_ can opt out of, and that most people (80% or more) -- even very capable and strategic people -- are likely to lose).

What I am saying is that the paper pushers are allocated elsewhere, they are more miserable and shallow minded now, and they have a corrosive long-term effect on society and culture, even though they contribute positively to economic growth. In way, it is trans-generational debt with extra steps.

And, in case anyone needed proof, this is reflected in the US degree-completion-data, when measured as a percentage (https://galacticbeyond.com/two-percent-programmer/plots/over...), and when measured as a derivative of percentage (https://galacticbeyond.com/two-percent-programmer/plots/deri...). That green top-line, is business-majors, and those two lines that declined from top to average are social-sciences and education (all data from 1970 to 2011). In 1970 1 in 10 graduates were in business, 1 in 5 were in education and in social sciences. By 2011, 1 in 5 (or 2 in 10) were in business, and 1 in 10 were in social sciences and 1 in 20 were in education. Healthcare went from 3 in 100 to 1 in 10.

and we got “Greed is Good” Geckos running things since

This phrase is the opposite of an exaggeration. It sounds like it should not be true, but it really, really is. To be fair though, if you told me in 2015 what the headlines for the 2020s would look like, I would assume you are some kind of satirist or comedian.

As someone who does a lot of genetic programming (like, old-school, without AI/LLMs, etc), I can confirm that the fitness function is very difficult to get right, especially if you are trying to evolve programs that have "adversarial fitness" -- you'd need to maintain a hall-of-fame, and that just makes the runs take _much_ longer, because, chances are, your fitness function is the bottle-neck.

So, it is very hands-off, but also very expensive, and it is never clear if optimizing the fitness function is worth it, because the fitness function itself may be insufficiently or incorrectly specified.

However, I do think that people should try, even with just a whiteboard or a notebook, to design a fitness-function, for their problem, as if they were going to try to evolve it, because (1) it forces them to explicate their correctness constraints, and (2) they may discover that the program that they are trying to write _is equivalent_ to the fitness function.

I'll give you an example for point 2. Many years ago, I had to parse a gnarly language, and I chose to do it via Chomsky Grammars (that automatically build a tree based on the grammar-spec). Chomsky Grammars are cool, in that they are basically just a state-machine, but they are incredibly difficult to debug: when they work, they might work incorrectly (malformed tree), and when they fail, they give no reason for failure (because even with a trace, you are trying to figure out which backtrack should not have happened). So, out of desperation, I started to consider using genetic programming to just evolve a correct Chomsky Grammar. It became clear that there are only 2 possible fitness functions (1) a function that tests a hand-picked input against a hand-crafted tree-output (which is vulnerable to over-fitting), and (2) a function that is not (well, is much less) vulnerable to over-fitting, but is effectively a pre-existing, correct grammar that can produce those trees.

If you are in situation 2, then the genetic programming is not necessary, unless you are trying to create an optimized (or obfuscated) parser, and even then the optimization may be overfit to the test-inputs (even if they are generated test-inputs from the grammar itself). If you are in situation 1, then you are better off re-evaluating your approach (I abandoned the Chomsky Grammar notation, and invented one that is much easier to understand and debug, without losing any of the expressiveness -- it also happens to be slower, but fast-and-broken is worthless compared to not-so-fast-and-works-fine).

One place where genetic programming has been consistently awesome, is in parameter-search style problems (e.g. your genome is a long list of floats, representing weights and/or anti-weights, and you need to find out which weights give you more fitness (or less error)). I hear good things about variable-neighborhood-search, but have yet to try it.

Disclaimer: I have never applied nor worked at oxide, but nevertheless have a bit of an odd thought.

Having looked at the process (RFD 3 and original post on dtrace.org), and contextualizing it with the oversubscribed-problem (which was mentioned somewhere else in this thread), I cannot help but think that there is a kind of solution that can help both the applicants and oxide and (yes) the industry as a whole.

The kinds of materials that the RFD asks for, seems like it would make for very interesting reading, regardless of whether it is read by a hiring-manager or a computer nerd. So why not, instead of (or in addition to) writing 11 pages, and sending them to the inbox of someone who (even without the additional responsibility of sorting thousands of applications in order hire-ability) is already extremely busy (this is, after all, a very demanding job), you publish them on your webpage?

In addition to taking some of the pressure off the oxide hiring-pipeline, you also get more exposure to people, who may work at organizations that would benefit from such a pipeline, but cannot afford to burn the political capital to replace the old pipeline. In a way, people who would appreciate your materials would, over some amount of time (and time should not be an issue, because it seems like it takes (at least sometimes) a long time for oxide to respond anyway), find them and possibly reach out.

I am basically a nobody, but if people started publishing things in the format of an oxide application, I would _totally_ read them. I am not saying I would necessarily _like_ them, but I would certainly read them[1]. Also, if disclosure is an issue, people can be published pseudonymously.

[1]: If for no other reason, than to see the multitude funny ways in which other people are wrong ;)

You might be surprised just how durable the effects of 40-year-old decisions are. You can actually see changes to the very degree completion-rates, when partitioned by field of study. Particularly, education and physics fields (as classified by NCES), have absolutely cratered from the mid 70s to the mid 80s, while business fields became dominant. And if you need data, I actually published an entire (and entirely too long) essay, analyzing the NCES data from 1970 to 2011 (a sequel post for 2011 to present is planned), yesterday[0][1]. Healthcare tends to boom and bust[2] in cycles, and those cycles are _inversely_ correlated with engineering, informatics (the most elegant term for what we call "computer and information sciences"), and business.

[0] https://galacticbeyond.com/two-percent-programmer/

[1] https://web.archive.org/web/20260620162923/https://galacticb...

[2]: In both the economic sense, and in the completion-rate sense, because those two things are correlated. And they have been correlated since the 1980s, because a lot of the healthcare industry became de-regulated and more profitable as a result, since at least 1978 (when hospitals were de-forbidden from making profits).

πFS 1 month ago

You, and the HN users, `lojban`, `klingon`, `ido`, `brithenig`, `solresol`, `babm`, and `tokipona`, may want to start a club. Amusingly, nobody seems to have registered the `esperanto`, `volapuk`, `interslavic`, `balaibalan`, and `dothraki` usernames.

An alternative to a capped income, would be that every income gets "inflated" by as much as needed until it reaches parity with big-tech incomes, which would require a kind of transnational union, but would have the effect of reversing the direction of extraction. Also, printing that money to inflate the income, would also cause asset-inflation, which also benefits people who own a life-changing amount of capital/assets. But _if_ you could cap asset-prices, then the inflation strategy might work. Note that I have not modeled this particular scenario yet.

Each of those employees is a liability, for various reasons, not just financial. Even if their salaries were completely subsidized by the state, there are many problems that come from having a very large number of employees. Firstly, there is more coordination overhead, and that is not great. Secondly, people are very political and very envious, and that has a corrosive effect on, well everything. Thirdly, people are (justifiably) afraid of getting laid off, which results in decisions that are sub-optimal or even illogical. Fourthly, people tend to only spend a few years at companies before moving on (for a pay-increase), which disincentivizes companies to hire more, and it incentivizes companies/management (and even employees) to engage in a kind of performative conformity designed to signal replace-ability (this effectively means that many companies are going to choose to do whatever everyone else is doing, instead of the unusual thing that will likely work better -- think of it as cargo-cult entrepreneurship/management/engineering). Fifthly, those engineers that leave take with them the knowledge and technology that they built up at a different employer and launder[1] it to their next employer. Sixthly, larger teams tend to produce more code per feature, and tend not to abstract/compress aggressively (which requires actually having a holistic understanding of the product), which means that team-sizes are likely to keep growing until the company's revenues stop growing. Put differently, enshittification and sloppification naturally emerge from the dynamics of how the majority of the industry works, and LLMs have simply automated it[2].

The solution may be to modify the incentives. Maybe federally cap all salaries to 90k or so, to filter out the serial job-hoppers and con-artists, and to also prevent poaching and "nerd-hoarding"[3]. Has the additional benefit of forcing rents and property prices to go down, and stops gentrification in its tracks (I mean I would expect this to be partially true, though it might force people to instead seek massive loans to compensate -- which should also be capped by salary to prevent it). And since we are already talking about federal limits, maybe a federal guarantee that covers healthcare and housing would further improve things.

[1]: This depends on context. If the IP is already open source, then there is no laundering. But I know people who have been building the same software system for the last 3 employers, and they do it (ostensibly) from scratch each time (but in fact they are permuting/improving the old version -- which does not actually belong to them -- and are over-reporting how much time they spent working on it). My point here is not that employees are ruthless rogues, but rather that the incentives are set up in a way that encourages the rapid dilution of the value of IP (it is effectively non-exclusive, which makes industrial espionage _unnecessary_), and discourages any kind of mutual responsibility between employer and employee (in a different knowledge-work field, I hear from a friend, seniors give juniors only minimal training because they do not expect to have to deal with them in two years -- and this was true since at least 2017, and has only gotten more true since 2020).

[2]: With or without LLMs, the biggest winners of this dynamic are the quasi-monopolies (or, more precisely oligopolies and duopolies), like MSFT, GOOG, META, etc. Everyone else will lose, and if they happen to win, they will get acquired (not for the tech, which is probably slop anyway and cannot run at hyperscales, but for the clients/customers/users -- why else would MSFT buy LinkedIn and GitHub, why else would startup incubators like YC be such a huge success (I doubt YC would have been possible in the 70s or 80s)). Software is awesome, and I love it, but the software _industry_ has always been an operation designed to extract money and data from the populace, using deceptive and predatory practices (see: Uber, Theranos, Celsius, Alameda for outright fraud, and Oracle for mere deception and plunder).

[3]: Sorry, could not think of a better term. The idea is basically the corporate equivalent of nerd-sniping, but instead of sniping by offering interesting problems/puzzles, you snipe by offering large paychecks and golden handcuffs.

I have been saying things to this effect for a few years now, and have literally been laughed at. I feel like that guy that suggested that doctors should wash their hands before operating on patients -- they laughed at him too, before they put him in an asylum. What's going to happen, is that everyone who realizes that these policies are a mistake, is going to quietly retcon their own role in that mistake, while scapegoating everyone that they don't like.

Also, would bet money that the derived data from the meeting-summarizers is being sold to hedge-funds, to give them a bit of an edge.

No, that would be a strict improvement. The AI note-takers can easily "mishear" or "misreport" non-existent illegal and unethical things. It also seems to easily mess up numbers (which is big problem, because a lot of decisions hinge on precise numbers -- imagine inflating an inventory by an order of magnitude, and then imagine having to pay a tariff on something that never existed).

I have a friend who works at a large-ish company that imports and manufactures things (in one of the clerical/quantitative professions). A few years back, they had the IT department go on a kind of "inquisition", wherein they forced employees to disable the summarization function that came with MS Teams, and threatened to fire them if they did not. The resistance to this demand was surprising -- most people are clueless about the cost of their own convenience. Worst of all, people would zone out of meetings, because the AI was producing summaries, which they would then never read.

The effect of the technology was that it made meetings infinitely more expensive, because the supposed benefit of meetings was nullified by complacency, _and_ it made the meetings a liability (incorrectly summarized meetings, that could be used in the discovery process, sure, but could also be sold by MSFT as a kind of market-research-data to competitors in the space).

Nothing illegal has to happen in these meetings at all, for this tech to cause an infinity of problems for the corporation. Every employee that uses these is effectively an unwitting spy. And if that is the case, then the meetings might as well be recorded and uploaded to YouTube (or whatever people watch these days)[1].

[1]: Maybe this is the future. Which I am okay with, but only if the entire planet has to do it, and the penalties for not doing it are irrecoverably severe.

This is interesting. I have always preferred to make my personal projects single-file (or at least few-massive-file)[1]. I noticed that teams in general, strongly dislike this style of programming (even before LLM-coding-assistants, as far back as 2020).

I wonder how much of the multi-file (and increasingly multi-repo) code-organization is just a manifestation of Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law).

[1]: It makes navigation and iteration much faster, and obviates the need to use indexers. It also forces you to only put _orthogonal_ programs in external files (I recently had to write a kind of quasi-SAT-solver, and that was code that was complex enough to require its own "namespace", and it was also something that was reusable across projects). One thing I noticed, maybe in 2025, is that LLMs struggled to navigate large single-file programs, but were quite good at navigating multi-file programs. It is interesting that they (according to my 2025 experience and the quote you give) prefer to _write_ code in ways that make it difficult for them to _read_ code.

What will it mean when I can no longer tell the difference?

It just means that you will have to evaluate prose on its own merits (aesthetic, logical, etc).

The main problem with LLM-assisted writing is that effort-to-write is now much lower than effort-to-read -- the LLM-prose-style is simply an imperfection that can sometimes help the reader bail on a piece (and there might be false-positives).

Most people are already biased against reading long pieces, and seem to skim them more often than not. These people are _probably_ a little worse off than before, but they are not paying full-price for being hoodwinked. The people who end up paying full-price are probably going to become more sophisticated in how they choose what to read. I can't tell if this will be good/bad for publishers and/or advertisers.

There is a universe out there, where most of the world is reading Solaris man pages, instead of Linux man pages. Whatever your thoughts on the Solaris OS, I think it is fair to say that no operating system has ever matched the quality of its man pages.

Interestingly, I also converged on the "reverse dictionary" usage of LLMs, in around 2024[1], mostly to indulge in (human) language-learning.

An excerpt from the post below:

``` It is a phenomenal reverse dictionary (i.e. which English words mean "of a specific but unspecified character, quality, or degree"). It not only works for English, but also for Esperanto (i.e. which Esperanto words mean "of a specific but unspecified character, quality, or degree"), as well as my own obscure native language. This is a huge time-saver when learning languages (normal dictionaries won't cut it, and bi-lingual dictionaries are limited, if they are available at all). Even if you are just using a language you are fluent in, a reverse-dictionary-prompt can help you find words and usages, and can also help you find "dark spots" in the language's lexicon. ```

[1] https://galacticbeyond.com/chat-room-dispatches-intelligence...

I don't know how to tell you this, but people have been writing custom software for personal use for decades. I've been doing it since at least 2009! I find it hard to believe that there is a demographic of people that were yearning to write code, but simply could not because they lacked LLMs. Is it the price? Are people simply too cheap to buy books? Or have they simply "forgotten" how to patiently and thoughtfully read them? Or has the quality of tutorials/documentation of languages/libraries/framework online decayed in the last decade? Or is it really that people have struggled to type characters of code into their text editors[1]?

Basically, I am prepared to accept that there is a friction that LLMs lubricate away, but what is the source of the friction, and why am I (and a bunch of other colleagues) not feeling that friction daily in our practice?

[1]: And if so, where did we programmers and computer scientists go wrong? Were subroutines and macros not sufficient for automating all of that excess typing? Were Emacs and Vim simply not saving enough keystrokes? Did people forget how to touch-type?

People (well, American people (disclosure, I am an American)), used to be scared/worried that Silicon Valley will eventually move to Bangalore or Shenzhen, because of wage-discrepancies, and so on -- and it is not a totally unreasonable concern, considering that the _Silicon_ part of Silicon Valley has been slowly relocated to Taipei, Seoul, Tokyo, and a few others. At this point, maybe we should start pushing that the _rest_ of Silicon Valley gets relocated somewhere else, too.

It's a breeding ground for Edisons and Morgans, not Teslas. It is profoundly depressing that SV is doing everything it can (knowingly or unknowingly, not sure which is worse) to get the entire planet to stop taking it seriously and to shun it.

We should start a support group.

I feel like LLMs[1] are going to cause a kind of "divorce" between those who love making software and those who love selling software. It was difficult for these two groups to communicate and coordinate before, and now it is _excruciating_. What little mutual tolerance and slack there was, is practically gone.

Open source was always[2] a fragile arrangement based on the kind of trust that involves looking at things through one's fingers (turning a blind eye may be more idiomatic in English), and we are at the point where you just have to either shut your eyes, or otherwise stop pretending that the situation can be salvaged at all.

Just a thought I had: some people think that LLM-shaming is declasse, and maybe it is, but I think that perhaps we _should_ LLM-shame, until the AI-companies train their LLMs to actually give attribution, if nothing else (I mean if it can memorize entire blocks of code, why can't it memorize where it saw that code? Would this not, potentially, _improve_ the attribution-situation, to levels better than even the pre-LLM era? Oh right, because plagiarism might actually be the product).

[1]: Not blaming the tech itself, but rather the people who choose to use it recklessly, and an industry that is based almost entirely on getting mega-corporations to buy startups that, against the odds, have acquired a decent number of happy-ish customers, that can now be relentlessly locked-in and up-sold to.

[2]: I mentioned a specific example of good old fashioned, pre-LLM, human plagiarism here: https://news.ycombinator.com/item?id=46540608

DeepSeek v4 3 months ago

Just to add some perspective to this comparison: the US massacred four _million_ people in South East Asia, during the Vietnam war. That is 2/3rds of a holocaust. The Iraq War (second one), cost between half a million and a million lives (estimates vary, and it only includes violent deaths directly caused by American troops -- the war itself caused an increase in crime and murder and out-migration).

I could go on, but Tienanmen does not compare to most of the things the US has done outside of its own borders from 1946 to the present. And no, we (I am American) cannot justify a body count in the millions, just because our victims are communist/authoritarian/theocratic. Note also that we only number 5% of the world's population, and that if we compared body-counts as percentage of populations, instead of as absolute numbers, I doubt we even have enough people to settle that debt.

Even worse, if the world internalizes that it is fine to murder millions of foreigners, just because they are oddballs that their citizens cannot empathize with, the _we_ are going to have a big problem -- we appear much more odd to the world than the world does to us.

I am surprised that our shenanigans have been tolerated for nearly a century.

DeepSeek v4 3 months ago

And the US massacred four _million_ people in South East Asia, during the Vietnam war. That is 2/3rds of a holocaust. The Iraq War (second one), cost between half a million and a million lives (estimates vary, and it only includes violent deaths directly caused by American troops -- the war itself caused an increase in crime and murder and out-migration).

I could go on, but Tienanmen does not compare to most of the things the US has done outside of its own borders from 1946 to the present. And no, we (I am American) cannot justify a body count in the millions, just because our victims are communist/authoritarian/theocratic. Note also that we only number 5% of the world's population, and that if we compared body-counts as percentage of populations, instead of as absolute numbers, I doubt we even have enough people to settle that debt.

Even worse, if the world internalizes that it is fine to murder millions of foreigners, just because they are oddballs that their citizens cannot empathize with, the _we_ are going to have a big problem -- we appear much more odd to the world than the world does to us.

I am surprised that our shenanigans have been tolerated for nearly a century.

The following happened to a friend.

Around the time of the pandemic, a company wanted to make some Javascript code do a kind of transformation over large number of web-pages (a billion or so, fetched as WARC files from the web archive). Their engineers suggested setting up SmartOS VMs and deploying Manta (which would have allowed the use of the Javascript code in a totally unmodified way -- map-reduce from the command-line, that scales with the number storage/processing nodes) which should have taken a few weeks at most.

After a bit of googling and meeting, the higher ups decided to use AWS Lambdas and Google Cloud Functions, because that's what everyone else was doing, and they figured that this was a sensible business move because the job-market must be full of people who know how to modify/maintain Lambda/GCF code.

Needless to say, Lambda/GCF were not built for this kind of workload, and they could not scale. In fact, the workload was so out-of-distribution, that the GCP folks moved the instances (if you can call them that) to a completely different data-center, because the workload was causing performance problems, for _other_ customers in the original data-center.

Once it became clear that this approach cannot scale to a billion or so web-pages, it was decided to -- no, not to deploy Manta or an equivalent -- but to build a custom "pipeline" from scratch, that would do this. This system was in development for 6 months or so, and never really worked correctly/reliably.

This is the kind of thing that happens when non-engineers can override or veto engineering decisions -- and the only reason they can do that, is because the non-engineers sign the paychecks (it does not matter how big the paycheck is, because market will find a way to extract all of it).

One of the fallacies of the tech-industry (I do not mean to paint with too broad a brush, there are obviously companies out there that know what they are doing) is that there are trade-offs to be made between business-decisions and engineering-decisions. I think this is more a kind of psychological distortion or a false-choice (forcing an engineering decision on the basis of what the job market will be like some day in the future -- during a pandemic no less -- is practically delusional). Also, if such trade-offs are true trade-offs, then maybe the company is not really an engineering company (which is fine, but that is kind of like a shoe-store having a few podiatrists on staff -- it is wasteful, but they can now walk around in white lab-coats, and pretend to be a healthcare institution instead of a shoe-store).

Personally, I believe that the tech industry sustains itself via technical debt, much like the real economy sustains itself on real debt. In some sense, everyone is trying to gaslight everyone else into incurring as much technical debt as possible, so that a way to service the debt can be sold. Most of the technical debt is not necessary, and if people were empowered to just not incur it, I suspect it would orient tech companies towards making things that actually push the state of the art forward.

It seems that many high-quality things (or otherwise aspirational things) take on Esperanto names (disclosure, I am an Esperantist). While Monero is no doubt a cool crypto-currency, it is even cooler that it has inspired some crypto-curious people to learn Esperanto[1] instead!

While I am here, I might as well give you a brief Esperanto lesson. Mono = money, ero = piece/quantum. So, "pano" = bread, "panero" = bread-crumb. Thus, "monero" = coin.

Many previous international currencies (all of them created with Swiss involvement), were also given Esperanto names: Spesmilo (thousand speso's (speso is analogous to "penny")), Stelo (star).

There is even a luxury watch-brand (from Switzerland) called "Movado", which is Esperanto for "Movement" (made back when watches were made with mechanical movements).

And I also learned, from the linked thread (disclosure, I am a participant), that there is a soft-drink called "Mirinda". This is an adjective that means "awe-worthy".

[1] https://www.reddit.com/r/Esperanto/comments/1sobiko/comment/...

Back in 2014, I did an analysis of (single threaded) CPU-efficiency and RAM-efficiency of various data-structures (skiplists, slablists, avl-trees, rb-trees, b-trees):

https://nickziv.wordpress.com/wp-content/uploads/2014/02/vis...

I used whatever I could find on the internet at the time, so the comparison compares both algorithm and implementation (they were all written in C, but even slight changes to the C code can change performance -- uuavl performs much better than all other avl variants, for example). I suspect that a differently-programmed skip-list would not have performed quite so poorly.

The general conclusion from all this, is that any data-structure that can organize itself _around_ page-sizes and cache-sizes, will perform very well compared to structures that cannot.

Slop Cop 3 months ago

I've taken to telling people, that if they see me write a long piece, that lacks em-dashes, then they should assume that I am under duress, and send help.