gobdovan

IQ tests are restandardised from time to time. We could take the scores from 100 years ago and see that everybody would be gifted.

Intelligence is usually defined as the skill in pursuing a goal, or speed of acquiring the ability for pursuing given goal. Given the goal-dependent nature, it's not that useful to use the same tests and measurements for intelligence over time, be it artificial or not.

I was attacking the comparative framing of the article. Although there's a lot of private terms we don't know, the claim is taken for granted and overfocused on, either with people saying 'figures out since Altman=devil' or 'no way OAI single valuable company'. I end the comment stating that their valuation is plausibly in the same ballpark.

Theoretically, I could sell 1 out of 100 trillion shares of my private startup for $1 and surpass all companies on Earth combined by implied valuation. I see people taking the article's comparative framing between OpenAI and Anthropic for granted, but without knowing the private deal terms, all you can really infer is that their 'true' valuations could very plausibly be in the same ballpark.

Remember when practically ~every company on the planet was building an NFT collection?

It doesn't seem to me that the author is saying 'AI bad, abstraction bad, knowing browser quirks GOOD'. Looks to me like someone making a specific claim about a trend where having an easier time getting off the ground can lead to a lower ceiling.

I'd read it kind of like 'The man and the butterfly' story. Or the Kant passage about how doves might wish air didn't exist, without realising that friction is exactly what permits them to fly.

Read in context. He's referring to the evolution of skill at group level, he even puts out the definition of deskilling and mentions 'skilled labor'. He then explains how frontend used to be a 'highly specialized skill', and how modern devs use Frameworks to consider browsers almost hidden compilation targets.

As stated, this is too vague to be much of a hypothesis. Animals, including humans, communicate multimodally, so gesture and vocalisation are not mutually exclusive evolutionary stages. To claim that one evolved before the other, you'd need to define some relevant markers, such as grammar, cultural transmission or some anatomical adaptation.

'Look at that cloud, dad! It's a bean with legs!'

'No son, that's a Cumulus cloud. Detached, dense, with sharp outlines.'

For most things, there aren't 50k reachable, aware, motivated, solvent buyers. Making enough people aware of your existence may be more expensive than the total profits made from your endeavour.

I am only pointing this out because I know people who would hear the first part of your comment and get their egos attached to an idea since they interpret it as 'there are billions of people, so I only need a tiny percentage, there is no bad idea, only bad execution' and lose years of their lives pursuing something where odds are stacked against them, if there were any odds in the first place. I'd urge people instead to also hear the 2nd part of your comment, and take it as 'experiment with many niche things, there are some that land and land well'.

/thread

Nietzsche might say this is not the fantasy of truth, but of comfort. The Last Man wants a machine to say 'fact wrong' or 'fact right' so the abyss of no ultimate truth can be made small enough to sleep beside.

Why should I trust this without a paper, benchmark or at least a human-written README?

> and the whole history of computing is about how faster chips is an excellent answer to difficult computational problems.

I don't really disagree, and I am definitely not taking their marketing pitch seriously. Yet, you could look at the same computation history and interpret it as an economically constrained hill-climbing around an idea that was simple enough to work reliably (von Neumann architecture) and that worked and scaled so well that we were rarely forced or desperate enough to move conceptually far away from it.

Sufficiently general digital computers can simulate other computational models, so I think 'faster' is ultimately the end game, but for some classes of computation, as you also noted, we may need to go for analog hardware, (maybe) quantum devices, optical interconnects, and so on.

Bret Victor has a talk about this, more or less: [0]

[0] https://www.youtube.com/watch?v=8pTEmbeENF4

> a neuromorphic computer that combines quantum-tunnelling physics with a brain-inspired architecture

This ought to be the most rhetorically compressed, stacked-legitimacy-seeking hype phrase I've ever seen in a tech description.

Do it for VR

Finally, a good use for LLMs. I would be so embarrassed to read old messages, yet LLMs just psychopatically chug along without flinching or cringing.

Yeah, the legislation is morally defensible on its own terms. But when you look at the full system, something funny happens: EU legislation is blocking data extraction and platform lock-in tactics that Big Tech already used to become monopolies.

And since the big platforms don't have to unwind their advantages or pay back for the methods that are now restricted and considered illegal, they can peacefully extract rents from their entrenched positions for even longer, while everyone else is prevented from using the same ladder they climbed.

No, but I gained something just as valuable.

After the interview, the recruiter who introduced me to this job said they had another role for me. But first, he wanted links to the other positions I'd applied to, what those positions were paying, and how far along I was with each one.

I told him I wouldn't do that and he said that it was ok. Haven't heard from them in a year or so, but I'm sure that other interview is in the bag.

I always wanted to tell the story of my weirdest interview. It's bad in a different way from OP's. This was for a "Machine Learning Engineer" contractor position.

- Hi, I'm gobdovan. How are you? says I.

The interviewer doesn't bite:

- How many prompting techniques do you know? (ok?..)

After a couple confused seconds, I respond with 2-3 techniques and ask if I should explain them, but the interview engine is already running at full speed:

- What is PEFT? How many PEFT techniques do you know?

I say I know LoRA and start to explain it, but the interview had no patience for answers longer than their acronyms. Before I knew it, I heard frantic clicking.

- He starts sharing his screen while I am still talking about LoRA in the background. Puts up an empty car from Google Images and commands: "Model the relationships between cars and people positioned inside the cars over time."

Uncertain of how to satisfy the inquiry, I start foolishly questioning what the task is supposed to be: vision? simulation? dataset labeling? self-driving cars?

But the interviewer doesn't budge. Doesn't give a specific task or context. Simply ignores the questions and stoically refuses to elaborate. The stars speak to me, and I guess he wants a relational mapping of some kind. Turns out I am right. This was supposed to test basic SQL table modeling.

At this point, I decide I'd sit through the interview just so I can collect all the questions. I am not disappointed:

- How many agentic frameworks do you know?

- What is the name of OpenAI's embedding model, and how many dimensions does it have?

- Then, the last ordeal lands: interviewer takes out a piece of cardboard that has "context engineering" written on it and asks: "What does this tell you?". His camera is unfocused, I ask if he could read what it says. Instead he repeats: "What does this tell you? What does this tell you? What does this tell you?".

I ask if he is the ML team lead. Turns out this absolute Chad is a mobile dev the client asked to interview candidates for the MLE role.

For me it surely is Python with Pytorch, if we talk about frameworks in general.

For web, I can't really offer any useful positive input, I was never satisfied with any framework for Python or Node. I see people praise RoR and Phoenix quite a lot tho!

> gym memberships are subsidized by people who barely go to the gym and would be better served by buying day passes

In my country, they're priced in such a way that day passes never make sense. If a monthly subscription is 50 EUR, a day pass is 18 EUR. So you'd need to go less than once a week for it to be better than a Gym subscription. But at that level of gym-going, you'd never see any kind of progress, unless you do very specific training, like very heavy lifts.

So, as a rational actor you're left concluding that the only options are:

- gym membership: you can grow muscle if you go daily; you won't see much benefit if you don't. <- reasonable

- no gym membership: you feel bad. <- suboptimal both for money and for muscle

- day passes: no muscle growth <- reasonable but then you feel bad about yourself

So, the middle is squished out completely and you're left either feeling bad or buying a membership. This presupposes you don't have alternatives for growing muscles, such as calisthenics, parks, free weights at home, which is the case for many. I can only conclude daily passes are for heavy gym goers that are traveling and don't want to lose progress, or other situations with people whose demand temporarily inelastic or non-repeatable.

Both rewrites differ semantically from:

for i in 0..32 { a[i] = 1; }

If a.len() == 16, the indexed loop writes a[0]..a[15] and then panics at a[16]. By contrast, both assert!(a.len() >= 32); and a[0..32].iter_mut().for_each(|el| *el = 1) fail before any writes occur. The former at the explicit assertion, the latter while creating the a[0..32] subslice. That difference is observable if the panic is caught, and the panic location/message may also differ. This is why these are valid manual rewrites only when the intended precondition is "the slice has length at least 32," not generally valid compiler rewrites of the original loop.

The GitHub issue discussion is directly about these concerns and discuss whether bounds checks may fail early, whether intermediate writes are observable after catch_unwind and whether panic behavior must be preserved.

This tracks exactly my experience described in sibling comment https://news.ycombinator.com/item?id=48275892

Well, the problem is that current LLMs are stateless, so a thousand subjective years is not well-defined. Without continuity of experience, persistent memory, engineered aversive stimuli and without updating weights meaninguflly during the punishment interval, we are merely doing the equivalent of simply updating a model to believe it just suffered a thousand years. Only once we have all these right ingredients we can empirically determine whether a thousand years is excessive, insufficient, or the local optimum for reducing Claude overwriting that damn CSS color palette.

You could drop the human pretense, or, maybe, we could make LLMs feel real pain, so when they botch up your code, you press a button (I'd suggest the Windows Copilot key) and they'd be agonizing for the subjective equivalent of a thousand human years.

Implementing spreadsheets with fine-grained reactivity is basically cheating.

Whoops! Although there is no public contract between HIR and MIR, the public part was not relevant here. What I wanted to highlight is that if they'd want to add proper proof machinery to eliminate low-level safety checks, they'd have to do it at: surface language, which is already complex enough; then HIR->MIR boundary with clean provenance (which I think current MIR would collapse too aggressively) and which may require a much clearer contract; then, even if they do the full front- and mid- ends properly, if you leave it up to LLVM, it ends up in SCEV, which is language neutral and would not be a good fit to support the proof obligations that would be specific to Rust.

I dug up a proposal from 2021 around bounds check hoisting in MIR, and from the discussion, details are pretty thorny [0]. It's narrower than general proofs but the frictions are very similar. The easiest example that shows HIR -> MIR difficulties is the part around `for i in 0..32 { a[i] = 1; }`. At the source level the range fact is super obvious, but after the for-loop/iterator lowering the MIR optimiser has to recover that `i` comes from exactly that range before it can turn 32 checks into the one hot-path check. Then it also would have to check for panic strategy to maintain the correct behaviour after optimisation.

[0] https://github.com/rust-lang/rust/issues/92327

Rust is in an awkward position of being already complicated enough that adding proofs for skipping bounds checks probably will not happen for a long time, even though this kind of low-level operation is where a lot of optimisation is lost.

Compounding on this, Rust is also unstable underneath, since there is no public, stable contract for carrying high-level semantics from HIR into MIR. Because these high-level invariants are lost during compilation, the compiler cannot easily use them to prove and eliminate low-level safety checks. But even if the frontend was perfect, Rust relies on LLVM's language-neutral SCEV, which operates purely on low-level math and cannot reason about high-level language semantics.

Ultimately, a lot of things would need to change for Rust to pay no performance for safety features.

You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself.

It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.

What would people answer if they'd be asked if they actually like Unix? Nobody programs in literal Unix, but there's a clear before and after Unix. In the same way, there's a schism between before and after React.

I personally like JSX quite a lot. Solid.js is a framework which uses JSX but drops the virtual DOM. Its creator has a course 'Reactivity with SolidJS' on Frontend masters. He's a compiler enthusiast and tells you quite a bit about how much he had to learn from the React project, which, to me, it put into perspective the kind of thinking React brought to frontend. I won't code in React myself, but I surely appreciate its massive influence on everything else.