DanielHB

There is this implicit debate in web application development of cascading+overriding vs non-cascading-no-overriding. A lot of people don't even realize this is where the line is drawn and mix both together. I call them "component-based", "document-based" and "mixed".

Component-based applications are usually better of with no styling cascading and no styling overriding. It makes things significantly easier because components are self contained and don't change in appearance based on styling of parent-elements on the tree (besides physical dimensions available and transparency effects of course).

Document-based applications are usually better of with cascading and overriding. Although no-cascading-no-overriding can work too, but requires more code.

Component-based is quite difficult to do without some tooling (like tailwind or css-modules, etc). Most CSS tooling support both though.

Tailwind implicitly forces you into the component-based paradigm but never explains it properly. There is a reason why people who love tailwind say it just makes things much more manageable. It is mostly because it removes the "mixed" mode that projects silently fall into[1] unless there is some guiding force towards component-based.

However component-based approach is quite doable with many different CSS solutions. Tailwind just _forces_ you into it.

For example CSS-modules component-based just means one .css file per component with only .className {} CSS selectors and not relying on cascading values from above in the tree (a few global rules can solve this).

[1]: Mixed mode as I call it is mixing hyper-local rules with cascading rules. They fall into this mode because that is how plain CSS works without extra tooling and guidelines.

One of the main problems I face is that business knowledge is not explicitly written down and formulated. No matter how much you describe something in human text format those are not formal rules about how something should work. If you can't inspect the output of the LLM you do not have full understanding of the business.

Most "classic" computer systems (code that runs on a CPU) are not strictly formal[1], but they are orders of magnitude more formal than human language.

[1] things like distributed systems, memory corruption, performance characteristics, etc can make a system behavior not predictable

I actually prefer using less powerful models most of the time, I might use a stronger model initially and then switch to weaker models as I fine tune the output.

Offloading too much of your task to models eliminates the human ownership, without ownership you can't move forward. Context sizes can't keep up with large codebases and markdown files with instructions and guidelines only take the LLM so far in the ownership aspect.

My gut feeling is that to start offloading ownership to the LLM we would need to see at least two order of magnitude increases on context size.

If the same amount of people bought your app at the same rate as if you hand-written it, then no. In fact your productivity would have grown 10x (half a day vs 1 work-week). The actual costs paid to Anthropic to make said app would have net-zero effect I believe (not an expert in macro economics).

> If junior devs are productively producing software that then goes unused then how productive were they really

Most ways of measuring productivity across an economy (in macro sense) takes into account only the transfer of capital. Meaning someone paying for something. So in this case it will be measurably zeo in most macro-economics studies.

The new coal plants are not planned to run a full capacity (or at all) they are meant for backup in case of environmental disaster and geopolitics (war, sanctions, tariffs, etc). So the actual amount of coal being burned is still going down.

Although it is highly suspicious why they are building so much unused capacity, it is as if they expect something to happen soon.

I have seen some uncensored versions of existing open models made by 3rd parties, I wonder how they actually work and in what way are the outputs different.

China has been known to set up local industry, destroy competition through subsidies, jack up prices repeatedly. US does it all the time too with tech services (uber, airbnb, are the more notorious, but all big tech is doing it now), but China is better at capex which is why they seem to be winning this race.

The main difference is that the subsidies in China usually come from the gov, while in the US it comes from VC money or anti-competition practices from established big-tech companies.

If China were setting up international funds and institutions for training with participation from other countries I would be 100% on board. Other countries could provide funding and workforce too and have a say in how the models are trained and safe-guarded. I am not saying China should bear the burden of open-weight models alone.

Ideally there would be open weight models from multiple geopolitical areas. It is not that different from telecom really, you don't want the whole world to be dependent on a single provider from a single country on this kind of stuff.

The fear is not about the models open weights it is the erosion of training capability in other countries. Why train models when they do it for free? Until they don't of course, or they start doing what the US is doing right now by locking out some models to government only or internal market only.

What people should be afraid is the rug pull.

Good point, but it could easily happen from both sides. The harness can just be default-tuned to think longer and harder on problems, or have dark UI patterns so the user _chooses_ the more expensive option even though the less expensive is available.

It just feels your own harness tuning for more token use protects these companies from audits and litigation. I mean this is exactly what is going on with this new feature.

As soon as tokens stop being subsidized I would not trust any harness made by a company that also charges for the compute.

Right now the interests align, but as soon as more tokens -> more profit (instead of more revenue and more losses) the perverse incentives will be too big to avoid.

It seems inevitable that open source harnesses will win. These companies would do better to just open source their harnesses.

It is all about the destination now where it used to be about the journey and the destination.

You don't understand what the OP said, your brain can get a intrinsic reward from seeing users use your LLM work. But LLM remove all the little intrinsic rewards from coding elegant systems to get to the point where you see users using your work.

It is all about the destination now where it used to be about the journey and the destination.

You put it in a good way, I have been saying this for my partner that I don't fear my job is at risk. I fear I am going to hate my job soon.

I am coping a bit by still doing stuff by hand, especially stuff where prompting the LLM doesn't save that much time. And what I call "adding good taste" to LLM output where I move things around to structure them in a more human-understandable way (by hand usually).

As far as I understand co-routines help don't really help with memory shared across go-routines. They only help in the fact you need to manage spawning and joining threads, making it easier to do stuff in parallel. But they don't provide thread-safety.

edit: I suppose you don't get segfaults or buffer overflows and the sort in go for accessing memory in a parallel context, you get recoverable panics. But that is still not really thread safety in my opinion, it is memory safety.

isn't it the exact same as C in this regard? The pointer being on the stack or not depends how it was originally allocated.

It also varies heavily on the kind of static analysis tools you are using in conjunction with your compiler. Some "bad" things about the language are just fine if they can be caught by the static analysis you are using.

It is a major problem with most really old languages, JS is notoriously prone to this kind of "remove the bad bits" thinking when in actuality most of those complaints are non-issues if you run a linter.

I think LLMs actually greatly improve accessibility, they are great about finding bad patterns in code.

You can literally run a "open this codebase and improve accessibility where you can" and get mostly perfectly good changes. Models and harnesses can be tuned to prioritize it by default, but usually the developer only needs to nudge it a bit to get good accessibility.

For normal OSS the only competition between contributors was for attention of maintainers to review and accept patches.

In an open-source LLM model contributors would compete with each other for computing resources for model tweaks and changes. The alternative model is that the contributor pays for the compute, but that increases the bar really high for contributions.

I think the main problem in LLM models is that you can not make a PR to an open source project to tweak some training parameters, prove it is an improvement and merge it.

If you can not run the training yourself you can not contribute. So open source contribution model does not work. All examples you gave have a fairly low threshold of capital expenditure required to be a contributor (basically a laptop).

Even back in the 90s a person could get a standard, but powerful, PC to do these things. The one exception was 3d graphics which took quite some time to become affordable and even there it was a single one-time expenditure (a workstation) per contributor.

VSCode at least prompts you to trust the project folder before running anything, otherwise it will use a globally installed LSP.

LLM corporate slop is the new version big data reports that nobody reads.

I am sad this infected code documentation and PR descriptions. This kind of stuff used to exist in order keep managers/executives busy not to keep engineers busy...

Static memory safety is a spectrum and so is code quality.

> how is that different from C?

Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.

Zig also allows optional runtime checks (at the cost of runtime performance).

There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.

Yeah this is what I meant, structs are obviously a huge step up in type-safety but the ways you can abuse or bypass the typesystem in C and Go means you still have to be super careful about the memory your code hold, receive or returns.

I think Go developers don't think this is much of a problem because most of them are working on microservices where data is not kept around for a long time (usually a single request). And of course Go makes it a lot easier to handle data-access parallelism. So the benefits of a powerful type system are somewhat diminished in this scenario.

I think it is one of the reasons why Go devs don't see much benefit in Rust, the borrow checker is just not that useful in the context of isolated requests.

The best thing React ever did to the JS ecosystem was hammer in on objects/maps/dicts being immutable. In modern JS it highly unnusual to see code modifying objects (except right after creating them) even though the language itself has no convenient means of representing that.

Yeah we had some corner case that still required eslint, although I don't remember what exactly. We also have prettier for a few file types not supported in biome.

Languages like C and Go are so weak in the type system that it barely feels better than fully dynamic languages.

In my (really large) typescript project we have like 6 static analysis tools running[1]. Steps to get the project running: install nodejs, install package manager, install dependencies, run project.

The main difference is that in the JS ecosystem it is all installed at the project level, you don't need anything globablly installed besides the runtime and package manager (and even the package manager can be auto-installed as well if you set it up that way).

[1]: eslint, biome, prettier, scass linter, graphql-codegen, tsc, tanstack-router codegen. That I remember, might be more (although codegen might not be considered static analysis, it is needed for static analysis).

Pattern matching machines seems more appropriate.