There are good reasons to object to using "literally" as a meaningless filler word instead of, say, to mean "this sounds like hyperbole but it isn't". First, there are times when you need to indicate "this sounds like hyperbole but it isn't", and there really isn't a great alternative. Second, there's no point to having a meaningless filler word. If a sentence means exactly the same thing with and without the "literally", why is it there?
She said she purposefully wrote in a simplistic style to mimic the traditional epics she was familiar with, like Beowulf. The books were supposed to have a wide appeal, and evoke that sense of the archetypal struggle between good and evil.
I personally love the style, even as an adult - it's a very easy read, but the world of earthsea, true names, and it's daoist philosophy is very appealing to me. It was the first of its kind, and really established the idea of "balance" in the fantasy genre.
The books definitely do get more sophisticated, though, both thematically and stylistically. But ultimately it's going to be a purely subjective experience, as these things always are.
I didn't realize it was intentional! Though, I think Beowulf is notable to a significant degree for its historic context...
I think the mention of daoist philosophy is interesting. Those works are very direct too, but I think (from a Western perspective) there's a huge amount "between the lines", both due to missing cultural context and refinement over generations of tradition, which means that while the writing is simple the meaning and implications are vast and complex.
Aside from the name thing though, I'm not sure I got that from the first book. Especially since most of the actions listed in it are very concrete.
In my C code, I implement undo/redo using write protection (mprotect).
First you mark all of your app memory as read only, so that you can define a SIGBUS handler when attempts are made to write to it.
Then when you detect a write to a page in the app memory, you append a copy of that page's memory to a stack, and then mark the page as writeable so that the page can be updated.
Then undo is simply a matter of popping the stack and overwriting the app memory with the copy stored on the stack entry.
This means you don't have to explicitly write "actions" for everything you want to undo/redo. All in-memory actions are handled automatically.
Obviously this means that things like FS changes or network IO changes aren't captured, but sometimes that's fine, and I'm sure there's a way to extend this scheme to handle those things somehow
That's great until your manager says something like: please group undo actions such that typing a word+undo will remove the entire word, not just one character at a time. Or show "Redo" in the menu after the undo.
Anyway perhaps there's a place for your solution at the compiler/language level, at various granularities. I've played with the thought, but considered it impractical so far considering those always changing requirements. Also, memory use might go through the roof for some applications.
Besides memory use I'm not sure why his approach isn't easy for everything you suggested.
Want to group undo actions? It's pretty easy to define arbitrary grouping algorithms on the sequence of recent state snapshots, which yields...a smaller sequence of state snapshots :-) a nice composeable idea.
To show redo after an undo, store recent undo triggers in the state, and if there is undo in current state, show redo with a list of older mem states to jump to. This repr also makes it easy to wipe out redos when doing a redo-breaking operation like editing the doc.
Memory use can indeed become a problem. But if/when it does, there is probably some obvious trait of the sequence of recent states that makes it easy to compress. Like for example that it's 99% the same contents, after a small edit. Or that one edit type dominates. Or that folks don't often care if they can't Ctrl+Z through 8GB of typing.
I think most programmers would gain by not dismissing simple approaches out of hand as too simple.
If writing it off for memory, write out the math for the size of the state and the allotted memory. This is not the era of computers that our languages were invented in; the page size your CPU fetches from insanely fast SSDs can be 4kb. And it can do a lot of that in a blink. Trying to shift runtime work (that the computer does) back to compile/design time (that the dev does) can cripple a system's performance in the short run (for coding/delivery time) and long run (for performance after pointer chasing)...luckily most of the time it doesn't matter anyway :-)
I honestly can’t tell if that’s an elaborate joke response or if that’s really something that works. If it does:
* How do you make sure you capture all mapped memory within a process? Walking something like /proc/self/maps?
* Does this include the stack and if so, doesn’t this cause havok when you write back. And if it doesn’t include the stack, can’t run things out of sync easily?
* This is then a page sized undo/redo, so it isn’t atomic with regards to actions triggered. Wouldn’t partially undoing such changes easily cause an invalid state?
I can't speak to every use case but it's been working great for my game:
1. I don't heap allocate anything after init. All allocations are custom allocated from this memory. I use a linear allocator, but could use some other scheme.
2. I don't account for the stack at all, but it doesn't mess anything up. The only important memory is the app memory, and that persists across frames.
3. It is, but you're computing deltas across frames, so they are atomic wrt user input. It's true that if multiple changes are made to the same page in the same frame then undoing that page undoes all of the changes, but that is often desirable from the user's perspective.
Thanks for your response. Interesting. I can see that working with these restrictions. This basically also assumes the data within that memory area only has pointers to either somewhere else in that area or to static structures outside, correct? Also the write rate is probably quite low as I imagine constantly handling SIGBUS would quickly slow things down? Did you look into userfaultfd?
As a frontend engineer, I see the proclivity frontend engineers have for fully rewriting their codebase in a new framework for literally no reason all the time. It drives me absolutely bananas. This would never happen in game dev.
that question comes up all the time for some reason but supabase does not support offline or sync, only some form of subscription updating, but this has nothing to do with having sync or local data.
In your opinion, why is Dart a better TypeScript? Interested to hear your view, because my experience was quite different. When I learned Dart, I was mostly annoyed because it was almost exactly the same as TypeScript, but just different enough that I had to look up how to do everything again. Like, I understand that Rust is different from other languages because it brings in a totally new approach to software development, which has its use cases. But when I used Dart, I just wondered why Flutter didn't just use TypeScript, since it looks basically the same to me.
One of the really nice things about Dart in addition to the fact that it’s an AOT compiled language with truly excellent tooling and documentation is the fact that because it’s not a superset of JS it can skip a lot of the messy parts while keeping the best bits.
One good example I like to point to is the idea of mixins.
I’ve read about these concerns but my kid is 11 and on there all the time, often with me over her shoulder, and I’ve never seen any sign of it.
It’s a huge platform for kids so I’m sure there are some creeps but there are plenty of controls in place to deal with that and even so, again, I’ve never seen it.
The creeps are only part of the problem. The platform itself is deeply exploitative and harmful. It's full of "you can make games and get rich" messaging that's just a lie. To say nothing of even if you are successful, they will take a staggering cut, and may not pay at all.
What's wrong with Qt?! I love it. KDE has long been my desktop of choice and Qt is my go to GUI framework for application development.
Qt Creator makes it so easy to whip together a UI that you can easily write code for. It's an absolute pleasure compared to alternatives (at least the ones that I've tried).
i exclusively contribute non UI stuff to kde because i could never get the hang of qt.
I'm a weird contributor tho. i only focus hard on one annoyance for a couple hours and convince myself i can code a solution by just looking at the project code... it mostly works but not for kde apps UI.
it doesn't help either that qt (or maybe its a kde thing) keep changing the base ui code. qml, designer, widgets... it's a dozen frameworks instead of one. not to mention most apps are usually in a mixed abandoned-migration state.
well, they just green ligthed a goal to make kde app writting easier. hopefully we will get a one stop place to read how to accomplish things.
reply