1,154 karma · joined August 25, 2010
webpage: https://galacticbeyond.com
github: github.com/galactic-beyond
github-legacy: github.com/nickziv
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 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.
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.
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 ;)
[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).
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.
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.
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.
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.
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.
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...
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?
Just to emphasize my point, China is not being deprived of chip _designs_ (via export bans of ASML-made lithography equipment), but rather of the actual physical machines that rearrange the atoms.
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.
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
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.
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.
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.
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/...
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.
I do understand where the revulsion comes from, however. My own family, on my mother's side, during WW2, was reduced in size. Four out of every ten were liquidated by the occupying Nazis, and then two out of every ten (or one out of every three, if you adjust the denominator) were liquidated by the triumphant communists (to say nothing of battlefield deaths in-between, and the blanket dispossession that those left alive experienced).
That said, I do think that ideas and ideologies should be evaluated on their own merits, and should not be reactively shunned, because of an atrocity that happened generations ago. The reality, is that good ideas get hijacked and used by opportunists to benefit themselves at the expense of their neighbors. By being so vehemently against an _idea_, you create new opportunities for these kinds of pathological opportunists -- you create an entirely new category of scapegoats, whose pleas and screams and tears you can ignore, while they get dragged away, and separated from their homes and their families and their friends.
I'm not saying that you should cuddle up next to a communist, but I am saying that you should evaluate all people and communities in a nuanced and thoughtful way, befitting a member of _this_ community of absolute oddballs.
It is the difference between "safety" and "liveness" (the two kinds of correctness guarantees in computer programming). Communist societies are, at their extreme, "safety" societies: they try to guarantee that nothing bad ever happens. Capitalist/market societies are, at their extreme, "liveness" societies: they try to guarantee that something good/interesting _eventually_ happens (even if bad things have to keep happening).
A "safety" mindset is sympathetic to cloning, because it does not have to deal with much uncertainty. A "liveness" mindset is not sympathetic to cloning, because it has already been done, and profit/monopoly opportunity is minimal.
Even though lobbying is not _technically_ illegal, we should probably learn to treat companies that engage in it (to the detriment of society) as if it were. Avoid their products if you can, and get your friend-group to do it as well. Build off-ramps. Maintain and share lists of executives who work at these companies (to put pressure on their reputations -- after all, what is wealth worth, if ordinary people refuse to take your money, or to give you any of their attention?). The market's distinctive feature is that it makes things fungible: currency, goods, and even people. Eliminate or reduce fungibility, and you get a very different kind of dynamic, one that has the potential to reverse the trend of rising inequality (and rent-seeking behavior, and unfair one-sided arrangements, etc) over night.
In fact, the strategy of any company is to find a way to make an entire class of companies/merchants (not competitors) fungible, while making themselves non-fungible. Most moats are built out of the pieces or remnants of someone else's moat.
Maybe. Maybe I'm wrong. Maybe I'm too hung over to tell.
https://matthewjbrown.net/teaching-files/philtech/winner-art...