On one hand it is definitely a crazy idea on the other hand I wonder if wayland's API is as simple as this and also could be done in 100+ line of bash.
On one side it is true and I am actually OK with it. But my wife has iphone 12 and it was fantastic at the time and now she always complains how slow and laggy it is. I checked it myself and it is true. Of course it's been almost 4 years since the release but I don't think user software changed that much during this time.
I guess I got used to it and not it does not give me as a developer to squeeze every last bit of performance for regular day job. My apps already run at 60 fps and spending more time on optimizing it just don't more dopamine.
From product C code perspective, this code is of course bad. But here idea was to show data manipulation closer to how it is shown in documentation.
Also a lot requests have dynamic size and cannot be as easily packed and serialized to be sent over the "wire". So for example you could put pointer to string into struct, malloc required space, then assign pointer. After when you want to send data you would have to write serialization methods to put it in correct order. It is all fine and should be done when you build bulletproof system to manage X11. But here these techniques just draws too much attention away from X11.
Yes. For production, struct are obvious choice. But here arrays were similar to how documentation specified data will be on the wire. So for educational purposes (to explain protocol) it seemed like a better choice. But I might be wrong and maybe structs would have been more approachable way to understand.
Several years ago I was working a project of rendering some SVG information passed to client in json format. Unfortunately I lost time and money with this project because had some issues with the client. Then I just archived it for later use.
Now I had some free time and found that I lost the latest version but had some intermediate version. For quite some time I had crazy idea to try to render a game on a PDF. It is a crazy idea but it was itching me for several years. So I got merged some code and wrote I tiny game. The game is horrible, collisions don't work and a lot of stuff is just bad but good enough to test the idea. And here we go.
There almost no time spent on writing it properly and no optimizations done (and won't be).
I had to spend some time actually learn groovy in order to understand what is happening and have some kinds of love-hate relationship with it. One one hand it shows that java is a bit too verbose and could have had the same functionality with less hassle. One the other hand they took too far trying to look like a declarative language which creates a lot of confusion.
But the worst part is that there is no easy way to debug.
