valenterry

Scala has dependant types (though inferior than Idris ones) and has the whole jvm ecosystem.

Ideally, sure, but the reality is just that some entities are not only reputationally, but also legally required to bear the liability for account takeovers.

Seems like an absolutely rare edge case to me. Or maybe even just a misunderstanding. I doubt there is a law that says that. If anything, I could imagine a law saying that a company has to take "sufficient precautions".

But even if what you say were to be true - that's not something to solve with tech. That means the law should be changed.

Hm, I disagree. I prefer if the user has the freedom to choose how they want to do things. At the cost of some users choosing the wrong way and then getting problems. It's a question of balance, but when I look at recent tech/internet history, I tend to not want to give central authorities any more power than they already have.

This is emphatically not fundamental to LLMs! Yes, the next token is selected randomly; but "randomly" could mean "chosen using an RNG with a fixed seed."

This. Thanks for saying that, because now I don't need to read the article, since if the author doesn't even get that, I'm not interested in the rest.

It's still in the standard. They could remove it, but they don't, so from my perspective it's just like how Google wasn't evil. Until they decided otherwise.

Sure, but then you still need a protocol between user agent and website.

Yes of course. Just like you do for passkeys.

Passkeys can in fact be backed by exactly this, i.e. a HMAC-only stateless implementation backed by a single password: https://github.com/lxgr/brainchain

No, not quite. It's written on there:

"Login" with your passphrase, and you can create non-discoverable WebAuthN credentials (don't call them passkeys, but definitely be reminded of them) at ~all~ some websites supporting them (...)

That's the thing: with passwords, a website/app cannot prevent you from controlling the password yourself. With passkeys and attestation it can.

It should be noted that that is not an inherential advantage of passkeys over passwords. It is possible to achieve the same with passwords, e.g. by using a hash-cascade.

Then you should write assembly only. Like `MOV`, `ADD`... can't really get simpler than that.

Problem is, that makes every small part of the program simple, but it increases the number of parts (and/or their interaction). And ultimately, if you need to understand the whole thing it's suddenly much harder.

Surely you can write the same behaviour in "clever" (when did that become a negative attribute?) or "good" way in assembly. You are correct. But that's a different matter.

By that definition you will be stuck on the first language you love.

And someone will be stuck not to do anything because they are unsatisfied with all languages. :-)

Shameless plug: learn your tool. Don’t approach Postgresql/Mssql/whathaveyousql like you’re a backend engineer.

Erm, knowing and understanding how to use your database is a bread and butter skill of a backend engineer.

Google isn't even good at engineering great software.

They have some good people working on some good projects. If you look at the relation between software-quality of their average product and number of developers they have... yeah I don't know. Maybe hiring tons of new-grads that are good at leetcode and then forcing them to use golang... is not what actually makes high quality software.

I could believe that they are good at doing research though.

Static types, algebraic data types, making illegal states unrepresentable: the functional programming tradition has developed extraordinary tools for reasoning about programs

Looks like the term "functional programming" has been watered down so much that now it is as useful as OOP: not at all.

Look, what matters is pure functional programming. It's about referential transparency, which means managing effects and reason about code in a similar way you can do with math. Static typing is very nice but orthogonal, ADT and making illegal states unrepresentable are good things, but all orthogonal.

I think so too.

However I think there is a misunderstanding between being "deterministic" and "unambiguous". Even C is an ambiguous programming language" but it is "deterministic" in that it behaves in the same ambiguous/undefined way under the same conditions.

The same can be achieved with LLMs too. They are "more" ambiguous of course and if someone doesn't want that, then they have to resort to exactly what you just described. But that was not the point that I was making.

Yes, you are right. I was mostly speaking in theoretical terms - currently people don't work like that. And you would also have to use the same trained LLM of course, so using a third party provider probably doesn't give that guarantee.

But it would be possible in theory.

C can absolutely be ambiguous: https://en.wikipedia.org/wiki/Undefined_behavior

Why not?

Here's a very simple algorithm: you tell the other person (in English) literally what key they have to press next. So you can easily have them write all the java code you want in a deterministic and reproducible way.

And yes, maybe that doesn't seem much different from a programming language which... is the point no? But it's still natural English.

What would you say if someone has a project written in, let's say, PureScript and then they use a Java backend to generate/overwrite and also version control Java code. If they claim that this would be a Java project, you would probably disagree right? Seems to me that LLMs are the same thing, that is, if you also store the prompt and everything else to reproduce the same code generation process. Since LLMs can be made deterministic, I don't see why that wouldn't be possible.

That last step is still pure, because it's still just return a value. A data-structure. You did Haskell, so you should know how it works.

Nope, that is precisely what pure functional programming is about: to turn actions like "draw something to the screen" into regular values that you can store into a variable, pass around, return from a function and so on.

It's not an utopia. It will eventually happen and it will replace how react.js currently works. effect.website will probably be the foundation.

From what I remember, it turned out that the electronics were sufficient. Though the chance of issues (e.g. in case of a software but) were/are increased.

Right. I mentioned the suboptimal 60 degrees because many people hang it from the balcony (90 degrees) and the tilt it a bit, but usually not too much. From what I've seen 60 degrees seems like a good average number.

A 400W half decently oriented panel (i.e. south facing balcony, 60 degree angle) is sufficient to run your AC to cool your 50sqrm apartment during summer for free.

Do these setups have auto shut off if they see no other power on the plug they are on?

Yes. This is Germany we are talking here. I doubt any other country has higher (and more annoying) safety standards.

Not really.

Now imagine you run two AIs (like ChatGPT) on your machine or on a server. You maybe even want them to cooperate on something. How do you do that? Right, you cannot, there is no standard, no interoperability, nothing.

In general the security model of desktop operating systems is woefully inadequate for the modern era. Given the sheer volume of software known to do things not in the user’s best interest it’s borderline insanity that we hand it the keys to the kingdom without so much as a second thought with such frequency.

This. It must be the problem of having grown up with it that makes people not realize it.

Software will need to operate like people in the real world. You can give your friend power of attorney, but usually you don't, you find a better way to get things done.

This. The mere fact that it's much easier to find deleted/impacted entities is worth it.

It's like listening to a politician or lawyer, who might talk absolute bullshit in the most persuading words. =)

I'm thinking what is the missing piece here

First, it's cool that you work on it. Creating a new language is not an easy task.

I would suggest to try to stand on the shoulders of giants instead of trying to come up with a completely new thing.

Have a look at dhall: https://dhall-lang.org/ - it is a language that was created for cases like yours. Or, if you want to make POML a fully fledged language (and turing complete, with for-loops etc.) then it would be advised to use an existing programming language and create a DSL-like library.

See react. React did it right JSX. It might look like XML, but that's just the syntax part. You can create components in pure javascript syntax, because JSX is just the wrapper. You could do the same with POML. That will future proof it and relieve you from a lot of headache when people will ask you for more features, but without breaking backwards compat.

Yes it does. Apache ant did that... many many years ago.

Creating a new language that looks like XML but is not XML is... kind of unforgivable. I'd go as far and call it amateur-like. We already have good configuration languages (such as dhall-lang) and when more power is needed, then just use a real language and provide a DSL inside of it.

Yeah. I judge the maturity by that. If there's only a javascript/node and python sdk, that means I'll stay far away from it for the time being.