A view from my small corner on the inside: taste isn't merely not incentivized, it's actively disincentivized. It's not selected for during the interview process, if you demonstrate a little of it nobody cares, if you demonstrate too much of it you clash with everyone else's priorities which quickly becomes career limiting. So people willing to fight for taste never advance.
This isn't some nefarious plot to screw over users. Taste is not prioritized because nobody has it and thus can't recognize it. Can't value something you don't even recognize. This is orthogonal to talent btw. Lots of people there who are insanely good at what they do, who produce the most hideous API specs you've ever seen, as one example.
A much more mundane (and almost certainly true) explanation is that people who put all that crap in legitimately thought it's a good idea. Taste is its own thing and it's just not in Microsoft's DNA.
A model that gets good at computer use can be plugged in anywhere you have a human. A model that gets good at API use cannot. From the standpoint of diffusion into the economy/labor market, computer use is much higher value.
I can honestly understand both positions. The U.S. military must be able to use technology as it sees fit; it cannot allow private companies to control the use of military equipment. Anthropic must prevent a future where AIs make autonomous life and death decisions without humans in the loop. Living in that future is completely untenable.
What I don’t understand is why the two parties couldn’t reach agreement. Surely autonomous murderous robots is something U.S. government has interest in preventing.
> it cannot allow private companies to control the use of military equipment.
The big difference here is that Claude is not military equipment. It's a public, general purpose model. The terms of use/service were part of the contract with the DoD. The DoD is trying to forcibly alter the deal, and Anthropic is 100% in the clear to say "no, a contract is a contract, suck it up buttercup."
We aren't talking about Lockheed here making an F-35 and then telling the DoD "oh, but you can't use our very obvious weapon to kill people."
> Surely autonomous murderous robots is something U.S. government has interest in preventing
After this fiasco, obviously not. It's quite clear the DoD most definitely wants autonomous murder robots, and also wants mass domestic surveillance.
Because the current government wants unquestioning obedience, not a discussion (assuming they were capable of that level of nuanced thought in the first place). The position of this government is "just do what I say or I will hit you with the first stick that comes to hand".
If the government doesn't want to sign a deal on Anthropic's terms, they can just not sign the deal. Abusing their powers to try to kill Anthropic's ability to do business with other companies is 10000% bullshit.
I can see both sides as pertains to Trump's initial decision to stop working with Claude, but now, this over-the-top "supply chain risk" designation from Hegseth is something else. It's hard to square it with any real principle that I've seen the admin articulate.
> What I don’t understand is why the two parties couldn’t reach agreement.
Someday we'll have to elect a POTUS who is known for his negotiation and dealmaking skills.
> What I don’t understand is why the two parties couldn’t reach agreement. Surely autonomous murderous robots is something U.S. government has interest in preventing.
Consider the government. It’s Hegseth making this decision, and he considers the US military’s adherence to law to be a risk to his plans.
Your comment reminds me of a story. John Adams and Lafayette met in Massachusetts something like ~49 years after the revolution. (Lafayette went on a US tour to celebrate the upcoming 50 year anniversary of independence.) Supposedly after the meeting Adams said "this was not the Lafayette I knew" and Lafayette said "this was not the Adams I knew".
I've been using Racket to work through The Little Learner[1] and it's been a good experience. You need minimal Racket to work through the book (lambda, let, define, map; I think that's about it). But I branched out to learn more about the language and the standard library, and it's a fun and surprisingly powerful system to explore.
The biggest downside of Racket is that you can't build up your environment incrementally the way you can with Common Lisp/Sly. When you change anything in your source you reload REPL state from scratch. After CL it feels incredibly limiting in a Lisp. Incremental buildup is so valuable, if I wanted to do any Lisp work again I'd reach for CL before Racket just for this reason.
BTW, the book is _great_. Quick, easy to get through, very easy to understand, and teaches you everything from soup to nuts. If you're familiar with lisps you can get through the book in two weeks. It's then easy to get into any deep learning tutorial or project you want, or even start implementing some papers. The book manages not to water down the material despite not using any math at all. Although if you know some linear algebra or multivariable calculus you'll appreciate the beauty of the field more.
> The biggest downside of Racket is that you can't build up your environment incrementally the way you can with Common Lisp/Sly. When you change anything in your source you reload REPL state from scratch.
I don’t quite understand… I’m using Racket in emacs/SLIME and I can eval-last-sexp, regions, etc.
Ah, I'm using racketmode which doesn't support live state buildup (and the builtin GUI doesn't either). What exactly is your setup? SLIME only has a Common Lisp backend, it doesn't support Racket to my knowledge.
EDIT: ok with geiser and geiser-racket incremental state buildup works really well. I rescind my objection!
I think that should work in racket-mode as well. You can easily send individual sexps to the repl and add to the live state. However, one thing that CL does that Racket doesn't do (afaik) is when you change a data type (e.g. alter a struct), it automatically ensures live code uses the new types. In Racket by contrast I have to either carefully go through all affected forms and send them to the repl, or send the whole buffer to the repl. This does make the whole experience feel more static than in CL.
> The biggest downside of Racket is that you can't build up your environment incrementally the way you can with Common Lisp/Sly. When you change anything in your source you reload REPL state from scratch.
I think no Lisp is a "true" Lisp if it doesn't provide two critical components of the Lisp experience:
- Live Images
- REPL-driven development
That's why Clojure/Racket and even Scheme are Lisp-y but not a true Lisp. The only true Lisp languages I've found are CL and Janet.
Is this not ultimately a late-binding issue? Maybe I'm missing something, but I've absolutely been able to incrementally build up an environment without resetting using nrepl and Clojure
The Little Learner is a great book. I tried rewriting all the code in Python/JAX while following the Scheme code style as closely as possible, and it worked out great.
The appendix on autodiff is a bit rushed, in my opinion. But in all fairness, the number of pages would probably need to be doubled to give a proper exposition of autodiff.
Yeah, it's the easiest way to get a beachhead in deep learning and then expand from there. I dislike their heavy use of currying, it's elegant in theory but bad error messages make it confusing and inconvenient in practice. But it's a small tradeoff for an otherwise excellent book.
Also ex-Stripe. This suggests an opportunity to build an exchange that addresses these problems. Could one build an exchange with deliberate "turn-based" liquidity to avoid the problem of daily stock price distraction, for example? (This is hard because there will always be secondary markets, but presumably this is already the case.)
I thought about it for only a few seconds, but here is one way to do it. Have users self-report an "addiction factor", then fine the company based on the aggregate score using a progressive scale.
There is obviously a lot of detail to work out here-- which specific question do you ask users, who administers the survey, what function do you use scale the fines, etc. But this would force the companies to pay for the addiction externality without prescribing any specific feature changes they'd need to make.
Specifying the requirement in terms of measured impact is a good strategy because it motivates the app companies to do the research and find effective ways to address addiction, not just replace specific addictive UI patterns with different addictive UI patterns.
Building measurement into the law also produces a metric for how well the law is working and helps inform improvements to the law.
This isn't some nefarious plot to screw over users. Taste is not prioritized because nobody has it and thus can't recognize it. Can't value something you don't even recognize. This is orthogonal to talent btw. Lots of people there who are insanely good at what they do, who produce the most hideous API specs you've ever seen, as one example.
A much more mundane (and almost certainly true) explanation is that people who put all that crap in legitimately thought it's a good idea. Taste is its own thing and it's just not in Microsoft's DNA.
reply