nrub

I think this overlooks the full picture. It's not about the this one pin prick relating to their license. It's that working with Microsoft in any capacity is filled with paper cuts like this, annoyances, bad design, and overt errors. Every single day.

They're a User hostile company and they make a buck by doing just enough to convince non-experts to keep their enterprise licenses.

This is exactly what Taalas has already done, and the reason they got quickly acquired by AMD. Their chip runs Llama 3.1 8B at 17k tok/s, and even if llama 3.1 is dated, I can think of many problems I could use it for, especially at those speeds. They're certain to be working on a newer set of weights by now.

Right, but the point is that you can't conclude that a model is necessarily bad because it's not hitting the same scores on benchmarks. I just don't agree with lacker's conclusion, because their logic doesn't seem to consider that. Scoring lower on a benchmark doesn't strictly mean they have a bad model, but it may be the case. Like you said it's one data point, but being the easiest, and obviously most gamed, means you should probably weigh them less heavily.

Or they spent time optimizing their model to real world problems they're facing and didn't waste time trying to game a benchmark.

That's true, but that's just one model that has some easier setup in the ecosystem. It's not easy to get a consumer gpu that has 128Gb of vram, so while the Halo chip isn't as performant, the ceiling for running larger models is higher.

In opencode you can get granular, allow `git log *`, deny `git add *` and `git commit *`

> simple chart specs can be reliable, but generated charts are often of low quality due to reliance on system defaults; - complex chart specs with explicit details can produce good-looking charts, but they are verbose and agents can struggle with reliability

N of only a few of us working on an analytics agent, I don't think we've been finding this to be the case. We've been impressed with just how good LLMs (even smaller open weight models) are at using Python and R for visualization. Often any shortcomings go away if we iterate a bit to about ambiguity. Are there any threads of research that could better support this claim or highlight where issues might be?

Just because they don't know how to use a computer well, doesn't mean you can't teach them.

I no longer keep my dotenv files in plaintext. I use `sops` to keep an encrypted env around and you can use tools like direnv to make them available to your shell while you're working. Obviously the LLM could print any of these secrets, but it's less likely. Additionally I find that at least claude seems to avoid reading the dotenv. And lastly, don't make any local secrets that important. Limited scope, dev accounts, etc.

No, they're not there. Did you read my comment? It's not just flawed or limited implementation, those are things that python just doesn't have.

Yeah, that's cool, but it would be almost completely unnecessary if python just had actual private methods/classes/properties. It's a lot like pydantic, which is completely unnecessary if you had strong typing.

Yes, but: a) they're a second class citizen, not guaranteed to be used in whatever niche of the python ecosystem you find yourself in and there's already an n+1 problem with multiple type checker written by third parties, rather than having 1st class language support tool that's consistent. You're not going to get it by default, you're usually going to have to do some configuration (and maybe bike shedding) to get it working; b) they completely negate the idea of python being "easy to read", your code is now littered with `if TYPE_CHECKING:`, `Literal`, `TypeAliasType` and any number of workarounds needed to make your hints work out. Unfortunately the syntax was just not designed with typing in mind, and I think it shows; c) the idea of "hinting" rather than enforced type checking means you have no guarantees that a type is what you need it to be, you have to do a lot of boundary work to make sure the edges of your code are coercing things to the right type. While I love pydantic and find it to be an excellent library, to me it's the kind of code smell you get in languages without strong typing. Also you're going to get a lot of spurious type errors along this path as well;

I will gladly use python's type hints, it's a whole lot better than nothing (IMHO better than typescript), but in it's current form it will always fall short of a language that was designed with strong typing in mind.

You joking?

- strong typing - real concurrency (heaven forbid you want a background task without having to spool up an external message queue and worker) - immutability - limitations in error handling (sort of just typing really) - limitations in nullability (also typing) - memory layout is usually hidden or abstracted away - no actual private methods or classes

That's far from a complete list, but maybe you're taking for granted the typical pythonic conventions that many practice. It requires a ton of work to design and architect python systems of any non-trivial size for maintainability and understanding. No language is perfect, but there are plenty of languages that make supporting complex systems easier than python.

You have literal Stockholm syndrome. Not joking.