Huh. I thought hosting one's own databases was still the norm. Guess I'm just stuck in the past, or don't consume cloud vendor marketing, or something.

Glad my employer is still one of the sane ones.

Local inference users are all about sampling, but users addicted to commercial inference services are wary of sampling, because they have to pay by the token.

The author speculates that bigger/smarter models interpreting vague directives to utilize general-function tools will outperform more precise and detailed directives to utilize narrow-function tools:

> Granted to use a skill the agent needs to have general purpose access to a computer, but this is the bitter lesson in action. Giving an agent general purpose tools and trusting it to have the ability to use them to accomplish a task might very well be the winning strategy over making specialized tools for every task.

Well, that's just great.

The academic community has been using the term "skill" for years, to refer to classes of tasks at which LLMs exhibit competence.

Now OpenAI has usurped the term to refer to these inference-guiding .md files.

I'm not looking forward to having to pick through a Google hit list for "LLM skills", figuring out which publications are about skills in the traditional sense and which are about the OpenAI feature. Semantic overload sucks.

How do we deal with this? Start using "competencies" (or similar) in academic papers? Or just resign ourselves to suffering the ambiguity?

Or maybe the OpenAI feature will fall flat and nobody will talk about it at all. That would frankly be the best outcome.

Skills are an Anthropic feature

Whoops, you are right. I misread the article.

What about open? Or ai? Neither is really what they are offering. Open they are not (weight doesn't count) and don't get me started on that statistical machine they call artificial intelligence. Misleading through and through.

Yes, you will need to employ someone with basic system administration competence. That's a given.

Cloud infra is touted as obviating the need to hire system administrators, but that's a marketing fabrication. Trying to manage infrastructure without the necessary in-house skills is a recipe for disaster, whether it's in the cloud or on-prem.

Senior software engineer with 46 years of experience (since I was 7). LLM inference hasn't been too useful for me for writing code, but it has proven very useful for explaining my coworkers' code to me.

Recently I had Gemma3-27B-it explain every Python script and library in a repo with the command:

$ find -name '*.py' -print -exec /home/ttk/bin/g3 "Explain this code in detail:\n\n`cat {}`" \; | tee explain.txt

There were a few files it couldn't figure out without other files, so I ran a second pass with those, giving it the source files it needed to understand source files that used them. Overall, pretty easy, and highly clarifying.

My shell script for wrapping llama.cpp's llama-cli and Gemma3: http://ciar.org/h/g3

That script references this grammar file which forces llama.cpp to infer only ASCII: http://ciar.org/h/ascii.gbnf

Cost: electricity

I've been meaning to check out Aider and GLM-4, but even if it's all it's cracked up to be, I expect to use it sparingly. Skills which aren't exercised are lost, and I'd like to keep my programming skills sharp.

Thank you for this. Used an LLM to summarize some key files of an old project of mine and the summary was excellent. Saved me a ton of time for analyzing my own code :)

After having worked on accounting software for a living, which did need to precisely take into account the variable nature of time measurements, I greatly appreciate that Numbat has decided not to open that can of worms.

Using averaged constants like this isn't applicable to all use-cases, but has the virtues of being simple and easy to reason about.

IMO they did exactly the right thing by not trying to shoehorn an endless supply of complexity and pain into their language's type system. Users who do need to deal with date math can use a library.

Working with Perl, two things spoiled me for other languages: JSON and DBI/DBD.

In Perl, everything serializes to JSON without fuss. It can be "lossy"; objects without an explicit JSON serialization method and coderefs can't be deserialized, but serializations at least have placeholders for them.

Compare to Python's json module, which doesn't try very hard to serialize things and throws exceptions every time it runs across something new. It's very frustrating to use.

Perl's DBI provides a universal API for all databases, with implementation-specific details in an underlying DBD module (which both provides glue between the DBI abstraction and programmer access to features specific to different database systems).

Compare to Python, where you need to import a different module and use a different API for every different kind of database. As I increasingly use Python for a living, I frequently wish they'd follow Perl's example with this.

Ruby, being a Perl-inspired language, has `.to_json` built in. You can do

```rb

   # hashes
   { foo: 'bar' }.to_json
   
   # numbers
   28.to_json

   # anything really
   ['hello', 42, { lorem: "ipsum" }].to_json

```

That’s simply not true. This method is monkeypatched by json gem

JSON was added to Ruby stdlib in ruby-2.0.0 (2013), and has been a default gem since ruby-2.3.0 (2015).

This is pretty close to "built in", I think.

You're both right, I think.

Funny enough, but I've come across some really nice Perl code in the wild at work. I was used to the vendor providing some 40 class Java monstrosity to do something that should take like a page of code, so I was pleasantly pleased to find a contractor who provides an extremely well commented page of code to do something simple, yet critical to operations. The way Perl calls the OS to do something and glue everything together was pretty elegant.

> Compare to Python, where you need to import a different module and use a different API for every different kind of database.

You... don't. Python has a unified DB api (DBAPI 2.0) which drivers usually support. They often also provide a lower-level API specific to the DB.

You might really like Ruby! It's part descended from Perl and maintains a lot of the nice things about perl such as json, and the amazing string functions.

I tried very hard to like Ruby. "On paper" it looks great, but I had a lot of trouble getting used to the syntax.

I ended up going deep on the D programming language for my "new language". As a statically typed language it's not as expressive as the Python/Ruby/Perl contingent, but it's a lot more expressive than most static languages, and its C-like syntax "clicked" with me in a way Ruby never did.

It also can approach C-like run-time performance and memory footprint at times, which I appreciate. As much as I like developing in Python and Perl, I frequently wish they had better run-time performance and a smaller memory footprint. D gives me that, at the cost of a little expressiveness.

The only thing about the JSON package though, when things go wrong, it is very unhelpful about where it goes wrong.

I usually end up always wrapping the json_decode in an eval to catch the error and handle it in an easier to understand fashion.

But I agree though, its nice how json and perl data objects pretty much map to each other. It's great.

Omg the python stdlib json / simplejson both refuse to support custom serializers for keys only, as an explicit design decision. It is justified as "JSON keys must be strings", but JSON values can only be string/float/book/null so it seems a bit arbitrary. Leads to annoying gymnastics if you want to enforce "strong typing" of keys with Enum/pydantic/etc.

> In Perl, everything serializes to JSON without fuss. It can be "lossy"; objects without an explicit JSON serialization method and coderefs can't be deserialized, but serializations at least have placeholders for them.

> Compare to Python's json module, which doesn't try very hard to serialize things and throws exceptions every time it runs across something new. It's very frustrating to use.

Sounds kinda backwards to me. I thought the fact that throwing exceptions (or "making a fuss," if you will) is better than silently producing incorrect (or "kinda lossy," if you will) results wasn't controversial anymore in 2023.

> universal API for all databases

Go has this too, very handy:

https://godocs.io/database/sql

> Proposing "fall back to Usenet" in 2023 makes about as much sense as "folks who use Slack should just use IRC".

Hey! :-( IRC is still alive and kicking, thank you very much!

> Are you just blanking out on the whole of the 1965-1980?

If you have to dig back half a century to make your point about contemporary events, you have effectively ceded the point.

It was one of the politically violent periods that people are still alive, and it happened recently enough still working, from. I really don't think using the most extreme period in very recent history is ceding any point....

Well it is if we're talking about online abuse and the role of social media in enabling real life violence. Last I checked there weren't too many social media users back in 1965-1980.