boyter

Level up your LLM using scc in MCP mode. No longer have it use wc to find the complexity in your codebase, or understand it, #mcp-server-mode" target="_blank" rel="nofollow noopener">github.com/boyter/scc?tab… Have to compile from source but will make it into the next release.

@hamishogilvy Agree. As so as anyone can train one or the barrier to entry has been lowered it’s going to be very interesting.

Small, specialised models will be the new programs. So many tasks are better suited to probabilistic programming as opposed to deterministic. Whole new world opening up. Apple is perfectly placed to capitalise.

@raudssus The thing being I tend to not redo very much. Sure the if checks get annoying, but then its done and I move on. I find with modern python you keep tweaking... I just want to ship.

@boyter Yeah, but THEN you redo so many things the frameworks could deliver to you :D. There are languages where you can make all imports with one import and then do whatever you like. So beautiful, so elegant. AI loves it hehe

Its funny. I left Java for Python back in Python 2.5/2.6 because of the mess of boilerplate, only to watch Python spend the next 15 years absorbing all those things.

@raudssus I dont use frameworks in it usually. Just some patterns.

@boyter You still have boilerplate you have to do in go code? What you talk about? Its just more custom, but if use a framework, you have to include it everywhere. You have this on every file, and you call that no boilerplate? Hahaha #L3-L27" target="_blank" rel="nofollow noopener">github.com/argoproj/argo-…

@raudssus One of the reasons I switched to Go. The single binary deploy being the other with colourless functions.

@boyter That is why there are languages where you can make the boilerplate disappear. Just sad that not many people still use those languages.

@GrokWithGunny It just makes me sad. The Python I knew and loved has been replaced by the Java I wanted to leave.

@boyter Ecosystems trade problems before languages trade syntax. Python got enterprise scale. Java got the fight for developer mindshare.

@explodingtopics I dont think anyone is ready for the scale. Google capped out at a few hundred searches per person. Multiple people have multiple agents and they run 24/7 making calls.

@explodingtopics Indeed. The growth numbers are insane though. Everyone has a few agents, those make thousands of calls an hour. Only way this works is micropayments.

Google's share of search isn't 90%. It's 73%. That other 27% is TikTok, Reddit, ChatGPT, WhatsApp, and a dozen surfaces most marketing teams have zero visibility into.

@kaihendry I don't think that's needed? Pretty sure project scope as listed is the default when done there.

Nice, searchcode.com approved on MCP Servers mcpservers.org/en/servers/sea…

@douges No idea. I thought it worth submitting to anyway.

@boyter is that site any good

Working on scale for github.com/boyter/dcd and tried it against the Linux kernel restricted to C files only. Fairly interesting visualisations come out. Sorted by name and then duplicates. As far as I know this is the first time this had been done visually using the Ducasse et al. paper 'A language independent approach for detecting duplicated code'

Ok that was annoying. Bug in single flight preventing searchcode processing the llvm. Resolved now and it now processes as expected. Annoying because it takes several minute to repeat the issue.

@douges @antigravity 👀

who from @antigravity can I talk to to get paper on the mcp server list

@douges @OpenAI 👀

who from @OpenAI codex can I talk to get paper listed in their mcp recommended servers

Watching searchcode.com's API stats after a a refactor to get better latency. Looks like it worked. 94ms average latency with a 97.5% token saving in the last day. Pretty happy with those numbers, as it should allow fairly massive scaling.

@wws73 @esrtweet I’ll, have to check. I think I handled these edge cases in code for one reason or another. I’ll have to check history for why.

@boyter @esrtweet For Fortran file name extensions, typically the 'f' is capitalized (e.g., .F or .F90) when a C-like preprocessor is to be run by the compiler. (Can't be stock cpp, because // is an operator for character string concatenation.)

Some days ago I promised my X audience some interesting statistics about the number of computer languages in the world. After a fairly long siege of AI-assisted digging into this topic, here we go... My source-line counter, loccount, now knows about 507 different program source code and markup formats. I believe that it is at this moment the tool with the absolute broadest coverage, and will remain so until and if tools like tokei and gocloc try to catch up. Of these, 332 are what you'd normally think of as languages - they can do general logic and computation. Here's a more detailed breakdown: 507 total entries 332 programming languages 175 DSLs, all kinds 28 documention formats 10 hardware definition languages 20 build-system DSLs 27 configuration-management DSLs 12 parser/lexer DSLs 3 shader DSLs 11 mathematics DSLs 11 model and diagram DSLs 9 query DSLs 12 serialization formats 35 templating DSLs 98 unclassified DSLs 11 proprietary 35 dead Rejected: 59 tied proprietary 16 toys 25 exceptions If these numbers seem oddly small to you, you'll have a lot of company. When I invited people to guess at them last week, most of the estimates were way, way too high. So one thing I should clarify right off: with only one exception, I omitted all esolangs. There are ridiculous numbers of these, enough to at least double the language count. I wanted to count languages used for production or at least R&D, not jokes and stunts. Another choice I made that reduced the number was to count all assemblers as one language. It's pretty difficult for a source-line counter to tell instruction sets apart; the one distinction I could have made, what the assembler uses as a comment leader, didn't seem very interesting. For similar reasons, almost all Lisp dialects collapse into just "Lisp", "Scheme", and "elisp". I also didn't count different compiler or interpreter implementations as separate languages unless the source languages were distinguished by some combination of file extension and forward-incompatible syntax - features loccount can see. Thus, there are only two Pascals (the other one is Delphi), and only a handful of Basics. For C and more recent languages this issue almost never arises, as they tend to have single dominant open-source implementations. Which brings us to the most difficult judgment call I had to make - which proprietary languages and markups to omit support for. You might well ask: why omit them? Because there is a long tail of crappy special-purpose languages tied to one product or vendor "ecosystem"; you can estimate the size of the tail from the "tied proprietary" figure above. These are mostly special-purpose languages with roles like programming shaders or scripting in proprietary game engines. Like esolangs, they don't deserve to own namespace or file-extension-space, and I'm nor going to help them claim it. The set of proprietary general-purpose languages interesting enough to be supported is not empty, but in 2026 it is tiny and unsuccessful; loccount supports exactly four. The other things in the "proprietary" category are special-pupose or historical. The "exceptions" category is things like languages with dead websites, languages that never got out of alpha, and dead dialects of BASIC on obolete micros. On the other hand, I was fanatical about chasing down historical languages - everything of note clear back to Algol-60. Robot friends have confirmed that I covered this like a blanket - the handful of residuals are things like FlowMatic and Algol-58 that died so long ago that nobody has ever bothered to retrospectively invent a file extension for them, and it is doubtful more than a few fragments of source code written in them survive. (For the aspies, yes, COMIT and IPL are also in the catregory.) Academic MFTLs (My Favorite Toy Languages) proved less prominent than I thought they would be. Either there have been many fewer of those than folklore supposes, or most have vanished entirely without trace. My robot friends assure me that loccount now supports all the notable ones. The category is a bit fuzzy but the number is certainly less than 30. I have only 35 languages marked dead. That means 297 of these languages - 89% - are still in at least sporadic use. That's not counting INTERCAL, which made it in not because I wrote a compiler for it but because I think it qualifies as historically notable. Feel free to hoot in derision if you wish. Some of you will be wondering about file extension collisions. This is a problem surprisingly seldom, and is usually resolved reliably by looking for syntax keywords unique to one of the languages in the extension clique. The ugliest pile-up is around ".m" and ".mm", with unhappy mentions for ".pl" and ".v". Some of you are, I'm sure, gesturing in the direction of things like Rosetta Code and the Kate list of highlighting rules and spluttering "What about all those?" I already hit the high spots there. Rosetta Code is stuffed to the gills with esolangs and ancient assemblers and BASICs. Kate has entire sheaves of rules for markup variations that loccount could never notice. More generally, people who collect languages for the sake of collecting languages like big numbers and are going to find ways to make number go up, even if the distinctions that end up being implied aren't very interesting. Along the way I discovered some interesting things about syntax families. But that's a story for another post.