I strongly dislike flexible input like
__Unambiguous___, *Unambiguous*
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
I’m developing on an Nvidia Orin which requires Ubuntu 22.04. Snaps are broken on this platform. I used an alternative ppa that provided a chromium.deb.
It’s kind of interesting relating this to LLMs. A chef in a kitchen you can just say you want PB&J. With a robot, does it know where things are, once it knows that, does it know how to retrieve them, open and close them. It’s always a mystery what you get back from an LLM.
I find dark mode much easier to read and far less eye strain. I guess it just shows that users should be the ones to set the preference. There are studies on monkeys showing light mode leading to myopia. Although lately I have come to learn there are lots of poorly done studies.
I tried this recently with what I thought was a simple layout, but probably uncommon for CSS. It took an extremely long back and forth to nail it down. It seemingly had no understanding how to achieve what I wanted. A couple sentences would have been clear to a person. Sometimes LLMs are fantastic and sometimes they are brain dead.
When I wrote my very first Rust code, I was trying to write to a socket. I got stuck on this task with misleading error messages for the longest time. I finally realized I had not made the socket object mutable. I’m used to Posix where you have an integer file descriptor and I don’t tend to think of socket write as a mutable operation. At least it doesn’t mutate state that my app manages. Perhaps something in the kernel gets mutated. I believe the socket interface may have been intended to support queuing which is perhaps why it needed to be mutable. I might have needed a lower level api. I just mention this because I think it’s interesting as to how it should be typed when mutation is external to the app. I didn’t follow through on using Rust and this was long ago so I’m sure some details are wrong.
`std::net::TcpStream`? Interestingly, it doesn't need to be mutable if you know the trick.
* It implements `Write` for `TcpStream` which is likely what you were using. And `Write` requires `&mut`, probably because the same trait is used for writing to application buffers (e.g. through `BufWriter` or just to a `Vec`). So this doesn't compile: [2] I think the error message is pretty good; maybe it's improved since you tried. It doesn't though suggest the trick below.
* It also implements `Write` for `&TcpStream`. So if you use the awkward phrasing `(&stream).write_all(b"asdf")`, you don't need mutable access. [3] This allows you to use it with anything that takes the trait, without requiring mutability. You might need this if say you're reading from the socket from one thread while simultaneously writing to it from another thread.
It's a vaguely similar situation with the most common async equivalent, `tokio::net::TcpStream`. The most straightforward way to write to it is with a trait that needs mutable access, but it is possible to write to a shared reference by not using a trait. They also have these `split` and `into_split` methods to get mutable access to something that implements the read traits and something that implements the write traits.
I also found it really unintuitive what needs to be made mutable. And still do to some degree.
When I first had learned that rust had this concept of “opt-in” mutability, I thought that it must then be an accepted pattern that we make as little as possible be mutable in an attempt to help us better reason about the state of our program. I had come to rust after learning some clojure so I was like “ahh! Immutable by default! So everything’s a value!”
But in reality it feels like rust code is not “designed” around immutability but instead around appeasing the borrow checker - which is actually pretty easy to reason about once you get the hang of the language. But it’s a ton to learn up front
I think this is different. It’s a statement that this product is not qualified to perform that function(autonomous killing decisions). I think it is pure madness to think AI is currently up to this task. I also think it should be a war crime. I think congress should pass a law forbidding it.
There seem to be two separate lines of thought in this conversation: first, that the AI tech isn't smart enough for us to trust it with autonomously killing people. Second, even if it was smart enough, maybe such weapons are immoral to produce?
The first line of thought is probably true, but could change in the next 5 years-- so maybe we should be preparing for that?
The second line of thought is something for democracies to argue about. It's interesting that so many people in this thread want to take this power away from democratic governments, and give it to a handful of billionaire tech executives.
It’s not clear to me that the AI itself will refuse. You could build a system where AI is asked if an image matches a pattern. The true/false is fed to a different system to fire a missile. Building such a system would violate the contract, but doesn’t prevent such a thing from being built if you don’t mind breaking a contract.
Yes, if you modify a nested dict/list entry, all nodes above it will be cloned. Here's an example:
x = [1, [2]];
var y = x;
set y.[0] = 3; // clones the outer array, keeps a reference to inner array
set y.[1].[0] = 4; // clones the inner array here. Outer array is now exclusive so it doesn't need another clone.
var z = x;
set z.[1].[0] = 4; // clones both arrays at once
I’m reminded of the time Microsoft allowed mistakes in html writing. They attempted to parse a wide variety of common user errors. The effect of this was no standard and nobody else able to write a Microsoft compatible parser.
I dislike Nim lang because of this. At least Nim defined the specification. Still though I think it creates more cognitive load learning every legal variation and it makes searching more difficult.
I think to authors point if Markdown actually had a strict simple definition with one way to do it and no embedded html we would be better off.
reply