Absolutely. And ironically one thing I discovered while trying to use AI is that it applies to programming too.
I'd heard that one-shot a project with AI, you need a fairly complete design document instead of a short prompt, so I tried to write one.
In doing that, I'd include the unhappy paths as well, e.g. in describing a list/detail interface: the list shows the X's (I thought: but in what order?) in alphabetical order; when an X is selected, the detail is displayed in the detail pane; (lists should work with multiple selection, so) multiple items may be selected at once, in which case the detail pane should display "N items selected" instead of the interface to edit the items; (a list starts empty, so) if no items are selected, the detail pane should display "No items selected", etc.
Laying out the entire system in plain English helped me have the whole thing inside my head, and see cases where presumptions about how the system would work wouldn't actually hold in practice because they weren't even holding in the text I was writing. So I had to edit the draft to fix my wrong assumptions until it made sense.
And of course the AI managed to do a pretty terrible and disappointing job at it in the end, because it made mistakes in the parts I didn't specify, or placed widgets in the wrong places because the layout that was difficult to explain in text, etc. It's somewhat impressive that anything ambiguous is a spot where AI can make the worst assumption imaginable, like it doesn't have the capacity to intuit "oh, we are making THIS sort of app, so it should look like this". But it was a good learning experience.
I suppose it's a great idea to write out what you're about to do before you set out to do it, because it helps you think about it in whole and in detail. It would be terrible if people stopped doing that.
The biggest issue with emoji is that it's not an actual glyph. Just think about the gun emoji. It was supposed to be a gun. It changes from actual gun to toy gun to space gun depending on the platform and year.
Imagine if you wrote the word "gun" and then 5 tech giants decided it was their job to change the "g" to a "b". It's ridiculous how lightly we take preserving messages when the whole industry is supposed to be about data.
They are also not specific enough to encode what they are meant to convey. People pick emojis for what they look, and if they look even slightly different the message changes, yet platforms are allowed to design them however they want and then change the design year after year. The letter "a" is still going to be the letter "a" no matter what. The same can't be said for "emoji covering their own mouth" which either looks shocked or mocking you depending on how it's designed.
Why https://gpui.rs/ doesn't have a single screenshot of how it actually looks?
The first thing anyone would want to know when choosing a GUI framework is how it looks by default. Every major GUI toolkit has screenshots on their websites.
This happens so often it makes me wonder if people just don't know how to take a screenshot and put it in a webpage with .
gpui is meant to be a fairly low level library. If you want screenshots check out zed, but be aware that for many use cases you'll have to roll your own widgets.
gpui-kit (formerly gpui-component) provides a richer set of widgets and a Javascript shell. Screenshots can be found here:
I don't know about you but I _want_ all UIs to look identical - specifically I want them to look like they belong on the platform I use, not the fever dream of some product person.
The only thing I know is that if I wanted to learn how to program, I have thousands of tutorials on the Internet and Youtube teaching everything from if/else to data structures and big O.
But if I wanted to learn software design and architecture, I'd probably not even know where to start.
Wait, how do you create programs then? How do you compile?
That doesn't even make sense, to be honest. Interpreted languages like Python aren't running machine code. They are taking data and executing machine code based on the data. Is Python safe?
According to Wikipedia, Modified Harvard Architecture is a common thing and appears to have properties of both Harvard and Von Neumann architectures. It's probably worth discussing a specific device, OS, and programming language rather than having a vague discussion where both parties are constantly describing different goalposts.
It's not that hard to imagine that in a specific embedded device the kernel / compiler have access to write to the instruction memory space while user space programs don't have any API / permissions to do that.
I see. I guess this does solve the issue of a program managing to insert arbitrary machine code on an address and point the CPU at it, or replacing the memory where the machine code already exists. But I think there already exists OS-level protections against writable executable memory?
It also doesn't solve one important attack vector: the existing executable has logic that can be used maliciously (e.g. a function that sends a file to the internet), and this logic is executed based on data on memory. In this case you only need to manipulate the data, without manipulating the "code", in order to exploit it.
I'm not sure I understand why would you need special hardware for that.
I think that the principle of "code is data" is that data influences the algorithms either way, so there is not much of a point in separating the two.
> I think that the principle of "code is data" is that data influences the algorithms either way, so there is not much of a point in separating the two.
This is clearly wrong in the sense that you allow your users to submit data to your website via a form, but you shouldn't trust that data in an `eval(...)` statement.
There is value in logically separating data / instructions. Having a physical separation may reduce some categories of bugs / security problems. Obviously as you rightly point out that the memory full of instructions has to get populated sometime, but when, how often, by whom, and with what safeguards are all relevant questions to the overall security of the model.
I think we generally agree, but you are taking the "code is just data" entirely too far to the point that you are blinding yourself to the value of the gradations in the middle.
This sort of thing is much more common in microcontrollers, where the code is cross-compiled on another computer and written to flash memory through a debug interface.
In practice, it's usually possible to write to the embedded flash memory via software, but it's much more difficult and disruptive than a simple CPU memory access.
A compiler writes machine code do a file. The OS then loads the code from the file into executable memory before it runs the program. The compiler isn't actually trying to execute the machine code it produces. This is why a JIT wouldn't work - the JIT bypasses the interpreter and produces machine code _that executes directly on the CPU_ inside of the same app.
I don't know any details about Python's architecture, but it's totally possible to write an interpreter for machine code; that's basically what an emulator is. The trade off is that pure interpreters tend to be very slow.
Yes, and that's my doubt. Compiling is turning data (text) into code (something executed by the CPU). I thought the point of the hardware is that data can't become code. If data can become code, then data is code, and it doesn't matter if the data is compiled first or interpreted at runtime. There doesn't seem to be a way to prevent "data" from becoming "code".
I don't think this is the issue. Most people are mediocre mathematicians, too, yet the companies have selected well enough for math literacy in training data (presumably). I think its a matter of training - they are often post trained by other agents (which read everything), human reviewers not paid enough to care (easily wowed by 10 paragraph length essay with correct punctuation), and deterministic scripts (checking for presence of a specific point, so agents are incentivised to write as much as possible to have more chances of hitting the unknown thing the script is looking for)
As far as I know labs try to train the other way, else we'd have monstrously long and useless outputs, but its hard to overcome these natural biases for length
I don't think that's a suitable mental model of how LLMs work. Their output is not just the statistical average of all the training data. If it was then the output would be quite useless.
An LLM trained on the entire internet incorporates essentially all (human-known) aspects of things.
Like a superposition of all kinds of writing styles, all perspectives on every topic and all kinds of ways to do things right and wrong.
In post-training (and of course already by sensibly curating the input data in the first place), people try to select useful submanifolds from that.
Ideally, you get a combination of all the extant strengths of people combined into one model. Self-improvement then leaves the sphere of human capability for good.
What difference does 24 make when nobody is even sure what is being charged and some of these products burn thousands of tokens just to display a status message.
I'd heard that one-shot a project with AI, you need a fairly complete design document instead of a short prompt, so I tried to write one.
In doing that, I'd include the unhappy paths as well, e.g. in describing a list/detail interface: the list shows the X's (I thought: but in what order?) in alphabetical order; when an X is selected, the detail is displayed in the detail pane; (lists should work with multiple selection, so) multiple items may be selected at once, in which case the detail pane should display "N items selected" instead of the interface to edit the items; (a list starts empty, so) if no items are selected, the detail pane should display "No items selected", etc.
Laying out the entire system in plain English helped me have the whole thing inside my head, and see cases where presumptions about how the system would work wouldn't actually hold in practice because they weren't even holding in the text I was writing. So I had to edit the draft to fix my wrong assumptions until it made sense.
And of course the AI managed to do a pretty terrible and disappointing job at it in the end, because it made mistakes in the parts I didn't specify, or placed widgets in the wrong places because the layout that was difficult to explain in text, etc. It's somewhat impressive that anything ambiguous is a spot where AI can make the worst assumption imaginable, like it doesn't have the capacity to intuit "oh, we are making THIS sort of app, so it should look like this". But it was a good learning experience.
I suppose it's a great idea to write out what you're about to do before you set out to do it, because it helps you think about it in whole and in detail. It would be terrible if people stopped doing that.
reply