And these were also automatic. Looks very likely that the team didn’t give a damn about top basic security and good practices.

Like a house made of paper wouldn’t be an example of the insecurity of the construction industry.

Anyone who studied software engineering, should know that specification doesn’t bother with implementation details of the underlying technology.

Things such as quite specific engine are used, are the contents of an encapsulated subsystem.

Proper software engineering specification is incompatible with a hacker culture and picking technology beforehand is a bad practice. It’s much closer to waterfall than to C4.

However, the last 20 years we got software building blocks which impose system architectural restrictions: frameworks. And also pieces of software which are half cooked systems.

Far are the days of requirements, preconditions, postconditions and invariants, network diagrams and entity relationship models.

I think they got just cheaper marketing since jobs died. No focus or brand protection.

Docker made convenient distribute some functionalities which were planned as stack of services rather than packaging appropriately for each distribution and handling to an administrator the configuration. That’s it. And it has many inconveniences. And Linux as well as BSD had containers before and chroots and many other things.

Uncertainty is one of the largest perceived threats by the human brain, it’s normal you feel it like a threat, it can even cause you anxiety and force you to take severe and unnecessary decisions. If that’s the case talk to a mental health professional because it is not an issue.

However if mental health is not an issue, try some of the many techniques that are there on how to handle uncertainty psychologically, you may start with stoicism (a modern book is fine) and with distribution of risk only of the threats that are an actual problem to you and you have any little of control over them

Better usage of resources and it always allows a parent style agent do complex queries (e.g: intersection of two different actors data doesn’t need to fetch all, copy and do it in buggy non sql code)

“The current interface was designed for internal use in Lean and should be considered unstable. It will be refined and extended in the future.“

My point is that in order to use these problem provers you really gotta be sure you need them, otherwise interaction with an external ecosystem might be a dep/compilation nightmare or bridge over tcp just to use libraries.

This happened to me with idris and many others, I took some time to learn the basics, wrote some examples and then FFI was a joke or code generators for JavaScript absolutely useless.

So no way of leveraging an existing ecosystem.

> Is there any formal language that is usable as general-purpose programming language I don't know of?

That’s sort of my point, the closest thing to a rich type system yet pragmatic enough is to me F# and it’s still falls short as formal verification and ecosystem integration.

I think eventually, we should invest into this direction so LLM production can be trusted, or even ideally, producing or helping with the specific specifications of models. This is yet to be done.

I don’t want to make a prophecy, but the day, ergonomics and verification meet in an LLM automated framework, this new development environment should take over everything previous.

It will have access to the original runtimes and ecosystems and it can’t be tampered, it’s well tested, no amount of forks and tricky indirections to bypass syscalls.

Such runtimes come with a bill of technical debt, no support, specific documentation and lack of support for ecosystem and features. And let’s hope in two years isn’t abandoned.

Same could be applied for docker or nix Linux, or isolated containers, etc… the level of security should be good enough for LLMs, not even secure against human (specialist hackers) directed threads

IMHO It’s irrelevant it has a slightly better typesystem and runtime but that’s totally irrelevant nowadays.

With AI doing mostly everything we should forget these past riddles. Now we all should be looking towards fail-safe systems, formal verification and domain modeling.

compressing the kernel loads it faster on RAM even if it still has to execute the un compressing operation. Why?

Load from disk to RAM is a larger bottleneck than CPU uncompressing.

Same is applied to algorithms, always find the largest bottleneck in your dependent executions and apply changes there as the rest of the pipeline waits for it. Often picking the right algorithm “solves it” but it may be something else, like waiting for IO or coordinating across actors (mutex if concurrency is done as it used to).

That’s also part of the counterintuitive take that more concurrency brings more overhead and not necessarily faster execution speeds (topic largely discussed a few years ago with async concurrency and immutable structures).

But that was just said by crappy influencers whose opinion doesn’t matter as they are impressed by examples result of overfitting

- fable would 100% detach from dotnet - keeps up yo the LLM rush, specially vibe coding on cursor

Last LLM experience it generated obsolete grammar (not much but a bit).

Such la gauges are key for vibe coding experience and modeling.

Comments URL: https://news.ycombinator.com/item?id=42967620

Points: 10

# Comments: 1