I coded something dumb and I'm proud of it(plbrault.com) |
I coded something dumb and I'm proud of it(plbrault.com) |
I've done the same during a refactoring of a side-project recently. It handles the input/output to a MIDI controller with many buttons, knobs and matching LEDs. Instead of computing what LED should change at regular interval, I am switching to recomputing the whole state each time. No more complex logic, no more mutable data. Only a pure function that outputs the desired LED state based on software internal state. Then a diff is computed and only changes lead to MIDI messages. Code is less efficient (for 100-ish LEDs) but much more straight forward.
Where it goes awry and gets complicated is that web developers want to modify the input state directly within the same functions that produce the output state, and they also want to trigger side effects after the output state has been completed, requiring another pass.
I’ve built a React variant for video compositing. Since it renders at a steady frame rate, there’s no reason to ever trigger re-renders. The useState() and useEffect() hooks are practically useless. To my personal taste it’s a sweet spot for React, and I wonder if some kinds of web apps might benefit from similar simplification to the state approach.
React's render loop, and even JSX itself, makes plenty of sense when the data is just fed in and rendered. It falls apart really quickly when data is being changed from inside a component rather than must firing events, leaving us with a decade worth of duct tape trying to find a solution that works long term.
A grimacing emoji when a process is thrashing, a fire emoji when it's eating CPU, a sweating smile emoji when the process is running longer than expected, etc etc etc.
It sounds dystopian in a way but also useful - neat seeing them used here!
"I am Jack's ALU"
I just had a nice word with my browser with the 200+ tabs open, I now know how it feels.
Only upgrade I'd make is how fast my "task switching" is, I'd like to think it was subsecond, but it's not.
If you haven't played give it a shot. Then play the insane mode, with all the cores and memory it's pretty amazing to keep it all running.
As to your code, pretty interesting idea. As noted (above?) I've also done control work, we only send a message to update the display when the value actually changes. Since we are on something like a CAN bus, we can't hog things making display changes at the expense of sensor readings.
You could modify the quicksort in python like this:
def quicksort_with_steps(arr: [Process]):
# Standard Quicksort operations
if len(arr) <= 1:
yield arr
return
pivot = arr[len(arr) // 2]
left = [process for process in arr if process.sort_key < pivot.sort_key]
middle = [process for process in arr if process.sort_key == pivot.sort_key]
right = [process for process in arr if process.sort_key > pivot.sort_key]
# the magic happens here:
# sort each half and pass through the intermediate results of the "sub-sorters" to our own caller,
# after modifying them so they contain the entire array again:
# left half:
left_final = None
for left_intermediate in quicksort_with_steps(left): # we're iterating over the "yield" calls here, not the sorted array.
yield left_intermediate + middle + right # pass on the intermediate result to our own caller.
left_final = left_intermediate # the last iteration has the "final" result for the left side, so store it.
assert left_final is not None # the generator always yields at least one result, so this shouldn't happen.
# right half: (shorter because we don't have to store anything)
for right_intermediate in quicksort_with_steps(right):
yield left_final + middle + right_intermediate
# the last "yield" returns the fully sorted array.
I'm pretty sure, if you're insane enough, you could also whip up something using async/await where the algorithm literally "awaits" the end of the animation...
It is exactly the correct approach — especially with the dataset potentially changing at each iteration, treating it as a contiguous sequence of executions is wrong anyways. Plus, you should always strive to reduce state as much as possible.
I was thinking of a way to quantify "complexity" in a process by a sort of "reference counting" style metric, where the moment you have to reference some other location to figure something out, you add 1 to a number and if that number gets above some figure, it's too complex.
https://en.wikipedia.org/wiki/Cyclomatic_complexity
But I don't think that captures most of the "too clever" stuff I typically see. That's usually some abomination of a one liner that does way too much. Those won't get picked up by cyclomatic complexity measurements. Furthermore, I find cyclomatic complexity tends to come from less experienced developers rather than experienced developers trying to be clever.
If you're genuinely wondering if something is too clever, ask that junior dev to explain it to you. After all, they will probably be the ones to end up maintaining it later.
A random nit as we like:
> I needed to somehow create a function that performs a single step of the algorithm, then gives back control to the main loop (which ironically sounds just like an OS' preemptive scheduling)
That sounds more like cooperative scheduling, no?
I like them in chat though.
Edit: to clarify, e.g. the process list makes it harder for me, because there are emojis on every process. I'd find it a tad more helpful if there were only emojis on processes with events and healthy processes would just have nothing (like the hourglass only being present in some processes). Color coding the background also makes it much more difficult to distinguish the emojis for me.
I personally don't like them in chat too much either: I much prefer ":)" or ":(" or ";)" than actual visual it gets turned into — emojis being so colorful call the attention to them, whereas I simply want to signal the tone in a message — emoticon/emoji is not the core of the message unless that's the only thing I put out.
But I am trying to go with the times (not that I had much choice as typing regular emoticons usually gets converted into emojis these days).
How many years will it be before the Oxford English Dictionary begins listing definitions for individual and groups of emoji? In 100 years they will just be an ordinary feature of language somewhere between a word and a punctuation mark.
Many years ago I built an elaborate dashboard/status page that was a front-end for a dozen or so CLI processes that did the heavy lifting for our video->VR->CDN->website->SEO link farm.
I used very simple "error codes" to flag when/where in the process errors would happen. 5 shapes, 5 colours, and 1-5 in numbers Square, Star, Circle, Triangle, Exclamation mark. Black, Blue, Grey, Yellow, Red 1,2,3,4,5
Different people/departments would be check on different aspects of deployment. This prevented the glassy eyed blank stares when I would ask: What was the error code. Me and the other IT folks knew what each stage meant, along with the colour codes and severity number would allow us to pinpoint where in the process this happened. So this was a form of emojii, and it was VERY helpful. I would have preferred error codes/server number/step number but Bob in Marketing would just ignore that. He never could remember 'what it said'. But he always remembered "Red Square and #5"
Symbols that are __EASY__ to identify (especially when attention spans are short) are tremendously helpful. [See Traffic signs as an example]
Esoteric symbols that can change meaning and/or have no meaning in the context are HORRIBLE. I'm on the spectrum, I can't tell what any "face emojii" mean.
Then again, about 3% of all people are color blind.
Warning Emoji, a weight, phone emoji ... people see them every day and understand them immediately.
https://emojipedia.org/warning
Granted silly emojis, those that imply other things, eggplant. Not so much. And the burrito is just for developer type stuff.
This is especially true when you have repeated communications with someone and come to understand how and when they use certain emojis.
For this same reason, I don't think they are great for technical information. They feel antithetical to the purpose of conveying exact information. You can use them as iconography, but purpose-made iconography is still superior, in my view.
Poor utilization of emojis, put simply, is using them all the time in ways that don't actually enhance the attention or meaning of the surrounding text.
The problem with emojis is people like them too much, and I have little faith that they would be used wisely by most programmers if some influential figure like Uncle Bub Martin told everyone to start using emojis for all the things.
There is an art to using them to enhance a message instead of obscuring it, though.
(It's more dystopian, because the computer has to know when you're asking it to do something stupid. Even more dystopian: It gives you the roll-eyes when you ask it to do something that it doesn't want to do.)
> a fire emoji when it's eating CPU
Fire emoji obviously signals that everything is going nice and smooth tho.
> etc etc etc.
Or the bottom/submissive emoji when you're in root/privileged mode.
Or the ok_hand emoji when there's something wrong (see ASL, and also The Expanse).
/s
In this case I understand the author's point is to have something visually interesting to show the work being done.
But they aren’t perfect either. And perhaps worse than the ’default’ way.
The fundamental problem is a lot of state is local and doesn’t need to leak outside of the view (for example, is the mouse hovering on a button or not). Yet it can be hard to tell when that’s the case—imagine if hovering on a button now needs to call some logging code or update some status UI elsewhere on the page.
If we were to store all that globally then it allows for pure rendering but it becomes unwieldy and hard to maintain. But if we don’t then you get the duct tape system.
That's reall interesting though, I run into plenty of problems with shared state but don't actually remember having any real issues with local state. I haven't seen too much of a problem with components changing local state as long as nothing else can change it. Even if that local state is passed down to child components, changes would only happen in the one place and it should only cause a single re-render cascade.
Where sate in react has really bitten me is when multiple components all try to read/write the same state, especially when some of it is async. Patterns can be used to hide or try to isolate it, but I've never seem it done in a way that feels cleaner or more fool proof than the idea of a state machine running entirely outside of react's component tree.
"Kinda like mediaglyphs except they're all black, and they're tiny, they don't move, they're old and boring and really hard to read."
-- The Diamond Age (Neal Stephenson)
"Goodbye" = "God be with ye" for example
You don't think "will not" when you say "won't", "won't" is just a word you use with a meaning you understand long before you can write.
i.e. a handful of emojis to explain the state of a machine is no more expressive than using a handful of colors to do the same thing. In that situation you'd react the same way to an emoji that I've thrown at you for the first time as with a color I've thrown at you for the first time. Suddenly the indicator is violet, or the indicator is smileyface emoji with big hearts for eyes: the question is what that meant to the programmer, and the emoji doesn't give any more indication than the color. "Are you trying to tell me that the server really loves my new blouse?"
Anyway I did take a look at Mutraction and it looks great actually. I've just made a lot of abstractions at work, and always been a little surprised by how hard it is for people to get used to them. Of course maybe I'm just bad at it. But ultimately it's made me kind of anti-abstraction all around. If everyone was as good with vanilla HTML, CSS, and JS (actually I'll approve TS) as they are with React, the web would be a better place </opinion>
But you're right though. I still understand my own library better. However, I've really made an honest try to understand react (at least the client&DOM parts) as much as I practically could.
I think I'm on-board with your anti-abstraction POV too.
Where React differs isn’t immutability, but where the mutation of state/effect boundary is (at the component/hooks-rules, versus something more fine grained).
In every possible approach, a state change needs some orchestration to produce rendering updates. The approach taken here looks like a subset of a common reactive approach, not dissimilar to say Solid with its createMutable Proxy-based store. That’s much more palatable to me (and I expect it would be to even a lot of React devs) than a less disciplined free-for-all mutability take (which effectively devolves to “build your own state<->render abstraction, or just maintain state in the view itself, probably both”).
Really, I think the main difference is that there's nothing in mutraction like a virtual DOM. Conceptually, it's dead simple. There are only real DOM nodes. This eliminates most of the use case for DOM refs as used in react, As you can just assign a JSX expression straight to a variable.
I've seen the word "orchestration" used before with respect to UI framework architecture. I must confess, I don't understand what it means. By default, in mutraction, most mutations are immediately applied to the corresponding DOM elements. You can wrap blocks in transactions, but probably most of the time, you wouldn't. Is that orchestration?
On the contrary! That alone is cause for me to give it another look. Stuff like state history is sorely lacking in the industry in general, and can enable powerful things like time travel debugging. I’m super curious to look into how it works when I get a chance.
> Really, I think the main difference is that there's nothing in mutraction like a virtual DOM.
Clarification (as I presume you know this, but in case anyone else isn’t familiar): this is also how Solid works.
> I've seen the word "orchestration" used before with respect to UI framework architecture. I must confess, I don't understand what it means. By default, in mutraction, most mutations are immediately applied to the corresponding DOM elements.
That’s exactly what I meant in this context. Without something like reactive Proxy tracking and binding to the produced DOM nodes, you’ll have:
1. Some mutable state, like objects and arrays and reassignable variable bindings.
2. Some view DOM.
3. Some code that manually assigns 1 to 2.
4. Some code that manually handles events in 2 and applies mutations to 1.
5. Recurse.
This can be as “bare metal” as direct DOM interaction, but usually tends to look more like jQuery. As popular as that is in HN comments, it’s really hard to manage in applications beyond a certain level of complexity (interactivity, feature scope, etc).
You can break 'be with ye' into 'b', 'y', and 'e', and drop the rest. In languages like Chinese which do not have a phonetic writing system, you cannot drop individual sounds within a word/character in a rule-based way like contractions.
Emojis are not a phonetic system, so unless you created an emoji for "they're", separate from the emojis for "they" and "are", you wouldn't have it as a word.
For instance, both Chinese and Japanese use kanji/hanzi, but Chinese is monophonemic, and does not have a phonetic alphabet that characters can be broken into (radicals aside, which are not related to sound). Japanese does (kana).
As a result, combining 2 characters in Chinese never changes the sound of some sub-portion of a character; it's either the whole sound that changes, or nothing. In Japanese, on the other hand, individual kana within a character can change (e.g. Rendaku), so for instance 'hito' (person) put twice in a row becomes hitobito instead of hitohito, because hito is comprised of 2 kana characters: 'hi' and 'to', and 'hi' becomes 'bi'.
Emoji have no subcomponent characters, so you either would need an emoji for a contraction word in addition to the source words, or, more realistically, you just wouldn't have them at all.
In Chinese, there is shorthand slang, but not shortening of words in writing based on spoken sounds (since it's not phonetic).
So even if "wo shi" (I am) might be spoken more quickly, there's no way to write that shortened version out in Chinese. You will actually see Chinese speakers use Latin characters and Arabic numerals for phonetic shorthand, (e.g. '88' for "bye bye", because 8 is pronounced 'ba'/'bai'.