Frankly, it's usually just gatekeeping (or just being threatened) hiding behind some moral system they just assume you should share with them.
23,138 karma · joined December 5, 2014
some src @ https://github.com/rdaum/
If you're looking to hire a systems software engineer w/ 25+ years of experience, me a ping. Contract/consulting or full time for the right gig. Mainly Rust. Also C++, etc.
https://timbran.ca/
Frankly, it's usually just gatekeeping (or just being threatened) hiding behind some moral system they just assume you should share with them.
They've also done so many pivots on AI, all of them weakly and annoyingly done. They couldn't even pull of FiTM copilot well, they were super late on it and it had all sort of bugs.
They could have just taken the loss and written an amazing GUI coding agent that integrated well with their IDE -- amazing integrations with their refactorings, etc. -- but that played well in other people's ecosystems but they refused and tried to own the whole pipe. Or something. They just confused me.
Their latest attempt is to allow you to connect to and run other people's agent harnesses inside the IDE and it works well enough but it wasn't enough to grab me since I (like you) use herdr on another machine to do the coding.
I've been using their products since ~IDEA 3.x. Almost my entire 25+ year career really. My fingers are wedded to their keystrokes.
Commenter is self-promoting their "graph DB" related product.
"Yeah, well, you know, that's just, like, your opinion, man"
In my own experiments I confirmed the same thing. Just using explicit free lists / allocator techniques was far more performant.
And actually-existing LeanStore on github doesn't use it, anyways. And strangely never has (looking through git history). Even though the paper (2018) describes it. Maybe Leis or Alhamsi can explain.
Curious if Umbra and the CedarDB stuff that came from it do use this approach, too. I seem to recall the Umbra talk speaks about using it.
As a lazy "eventually reclaim when I've got free cycles" technique maybe ok? But revealing that the actual LeanStore C++ code never does it.
But this is about humans malevolently using AI as a tool, not about AI autonomously doing "its own thing" (ahem David S Pumpkins) against "humanity."
It is instead already existing anti-social elements within human civilization harnessing machinery to accomplish their own selfish and destructive aims, regardless of the broader cost. Which is nothing new -- it's the story of all the horrors of the 20th century, as well.
Ask yourself who benefits from ideological attempts to hide the human driving the process from the agent doing its work for them.
If we imbue these machines with apparent autonomy, this is nothing more than an attempt to hide the man behind the curtain.
That's a perhaps overly optimistic view, but feels like one worth aiming for.
In reality we're so far from consciousness and independent goal-directedness in AI -- let alone any kind of energy and real computational efficiency... I agree with LeCun in broad strokes. I think he's overly dismissive of LLMs perhaps but I do think he's right that talk of "wiping out humanity" is theatre for people playing corporate power games.
There's likely all kinds of internal competition and disagreements and dysfunctions.
So there's that.
But in the last instance, revenues win. OpenAI and Anthropic have to fight for new revenue sources while Google already has a firehose. The motivations are fundamentally different.
Google gains very little by having us use their models for coding. It doesn't help them in their core mission ("to organize the world's information and make it universally accessible and useful ^W^W^W^W^W^W[and turn it into ad revenue]"), nor would it be anything close to substantial revenue compared to the ads revenue firehose they already have.
They will push AI in a direction that serves their existing goals and service the coding agent model only as is necessary.
Yes, he was talking about safety, but IMHO they're likely already IMHO pushing the boundaries of cartel type behaviour. And they will use safety as the cover to make it happen.
I suspect we'll see serious price fixing and the DOJ do nothing about it because of the inroads these people have with the Trump regime.
Whether that survives contact with Chinese open weight models is hard to say.
Huge misstep releasing it.
Will see if this remedies things.
One is:
1) Complex IDE integration where our AI model is called to assist users in making decisions, assisting them to do the things they already intended to do. It appears more as a function of the IDE rather than something separate. It shows off the intelligence of the model but doesn't show off any autonomy.
2) A separate tool that can be branded Anthropic. It takes over completely. It advances the narrative that we've already been spreading that AI is going to make some human jobs obsolete. It looks to employers (the actual people who spend money) like it replaces an expensive developer even if at first it requires one. It has minimal to no integration point.
Which do you think they'll approve. I think it has less to do with the user motivation and more with the producer's.
And I don't think it was ever necessary to go to the point where people just gave up authorship. These were choices made by adopting the "I'll do everything for you" agentic "harness" model that shipped with Claude Code but it was never inevitable.
e.g. we completely dropped fill-in-the-middle completion OG CoPilot auto completion model. That combined AI authorship with a human always in the mix and I actually really enjoyed it. It's just that the models involved were pretty stupid. We totally could have had IDE / shell / tooling integration that kept people in the driver's seat while automating parts of the drudgery away. Instead what we got was a simple chat loop with "oh, whatever, you go do it" being the ultimate result. Cuz, you'll totally review everything after and understand it, right?
The things should end by quizzing you on what was just made and if you don't pass, just throw it away. That'd be funny to watch.
Which is really the same problem with coding.
The agentic model of it just taking over and doing everything is poisonous to effective long term team work.
We're well past the point where it's about the quality of the work they produce. It's the way they integrate (or rather, don't) into human practices.
It absolutely was. Simply on account of the name on the grey box.
If it hadn't been IBM, maybe somebody like DEC may have gotten their shit together to take the market instead of farting around with overly high margin products and eating themselves from the inside.
But the way "business" culture was in the 80s the "respectable" productivity machine could not have come from the games/"home" market. Apple maybe but they opted instead to go close off the Apple II line (which in fact had a strong productivity sector thing going on, especially in schools) and push the Macintosh which was a good product but started off weak in terms of capability and costly on price.
In the early to mid-80s it was either going to be a CP/M machine or a CP/M-like machine (like the PC). These are Visicalc/Lotus-123/WordPerfect machines to their customers, and they cared not at all about graphics capabilities until later. Just needed 80 columns, floppies, and reasonable amounts of memory.
Hell there was terror in the microcomputer market when IBM made moves to go "downmarket" into it with the PCjr (which was a flop). The hype leading up to it, and the noises about how it would be a Commodore and Atari killer was insane.
Graphic fidelity on the 16-bit machines was great. Latency was sometimes bad, depending on how much they were trying to do in the game loop.
Looking back 68000 had little business in video game type machines. I like the 68000 from a programming POV but it's faster for doing a pile of fast integer calculations than it is at moving memory around and responding to interrupts.
But Atari and Commodore were also imagining their machines to be targeting productivity more than games, so.
Once clockspeeds got up to what the Falcon could do, it was unnecessary. But again, too late.
You might be interested in my lang/environment "mica" which attacks this same dimension of problems from a relational/datalog angle and then makes object/prototype identity hopefully emergent out of that: https://github.com/timbran-project/mica -- relational dispatch feels like a broadening of multiple dispatch.
I feel like I may have ended up at a similar place as Korz without realizing it. I will need to dig into this paper.
Speaking also of multiple dispatch and prototypes, there's also this paper from an old acquaintance: https://www.cs.cmu.edu/~aldrich/courses/819/salzman-pmd.pdf which I used to find interesting (and built my first version of "mica" back then around the idea).
Also I was an Atari ST user back then, and loved it. But the Tramiel's didn't "get" software in the early days. They failed to make the right investments to keep TOS/GEM actively developed (e.g. as a Mac alternative) until it was too late (they hired Eric Smith to work on MiNT and then MultiTOS in the early 90s but they were already done as a company by then).
And then three fundamental hardware mistakes with the ST were:
1. not shipping it with the Blitter from the start so it couldn't compete on games, obviously with the Amiga but even with 8-bits of the time
2. forcing the ROM size down to 192kB so they had to size optimize the crap out of GEM before shipping (waste of precious development time), especially including tossing away all of GDOS (which had support for proportional fonts and printer drivers etc). A 256kB or 512kB ROM would have solved a lot of problems with what I'd think wouldn't have been an insane BOM cost bump.
3. Minor but long term annoying -- tying the cartridge port to only have 128kB of address lines. If they had given it 256kB or 512kB address ability their later expansion issues (OS upgrades etc) would have been much improved.
As for the Amiga, great machine but a) it cost too much at the start so failed to catch immediate fire (the 500 rectified this to some degree) b) interlace.
And Dario and Sam have already made it clear that it's America First.
The rest of the world isn't going to accept a regulatory regime which imposes American hegemony. Maybe when Silicon Valley was playing all utopian like they used to. Not now.
Open weights is the most reasonable counter-power we have.
Notably, the definition given by Marx and other 19th century socialists (worker controlled production) is doesn't even have to involve government or the state at all. It just came to mean that once proximity to power came into play. The "soviet" word merely meant local worker councils, not a state form, for example. But once the Bolsheviks took state power, the power of the actual soviets was successively demolished in favour of a centralized one party state.
So, notably: Self-called "Marxist-Leninists" in the USSR, and Social Democrats (or "democratic socialists" in the US), and Right-wingers all far prefer the term to mean "government controls things." The latter because they can then point fingers and call things authoritarian (but somehow exempt corporate power from critique).
But it is not at all clear that 19th century socialists .. from Proudhon through Marx etc -- who coined the term -- meant this at all.
Also this hard line between "communism" and "socialism" is fictitious and very schematic. All communists call themselves socialists, and almost none of them agree on what that means.
Social democrats trying desperately to sound respectable clearly want a nice hard line there. But they also have no intention of bringing about socialism.