Another way to describe what has been done: implement a pure function and avoid storing additional state. It sounds way less dumb that way. It is not really a pure function but the spirit is here.
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.
This is how React works, or at least the illusion it presents to the developer.
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.
I've also struggled with React's insistence on immutability. What if mutability was the only way to update state? I implemented a JSX-powered react-alike that explored the concept[1]. To my lack of surprise, I found the resulting environment easier to get stuff done in. I'm not subjecting my employer to this, but I would totally use this on a solo project that I had to support.
IMO react made way more sense when it was used only as the view layer. What react really needed was a separate paradigm for business logic. Having a state machine tied into react is really interesting to me though I haven't seen many try it, and I personally don't use react often enough to give it a go.
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.
In my MIDI controller case, the "compute state and send update" code takes about 8µs, up to a spike of 15µs. The worst case of the code in article is a sort on each frame on a 100ish array, it sounds safe to ignore. Profile before optimizing.
this is an evil take but i think emojis are massively, massively underrated for use in signaling information (and massively overused in git readmes)
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!
Personally, I disagree. I'm probably in the minority, but emojis don't helot me much when conveying information and I see them more as visual clutter that makes it difficult to distinguish what's going on. This is especially the case when there are a lot of emojis (or other icons for that matter) instead of text, e.g. in menus. It makes it much harder for me to distill the information and it takes me longer to grok what's going on. Maybe I'm just a less visual type than others, but emojis actively make my experience worse.
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.
Not to mention, they don't translate well to spoken word and are not easy to type on a keyboard either.
"Why is svchost panting sweating red emoji CPU usage" is as stupid as it sounds.
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.
Incidentally in Slack you can easily set up a workflow where "emoji response -> text macro" (aka more information, a text supplement to your emoji). Very useful if you have a Slack channel that is deluged with questions.
Yeah, emoji on top of color is redundant and less legible. I find that people that use emojis for dashboards and the like tend to overuse them, but I agree with GP in that a single (well aligned and on an adequately colored background for contrast) emoji per item can convey a lot of info quite efficiently.
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.
The problem is that symbols are also easy to misremembered or misidentified. It's easy to identify a red square but if Bob accidentally recalls a blue square or a red triangle, then all of a sudden you're looking for an error that didn't happen.
Emojis are great for conveying the wide and varied levels of human emotion that differ from person to person that may type the same exact sentence with an entirely different meaning.
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.
Emojis can be done properly. Infrequent use with good contextual positioning can break a person's preoccupation and direct their attention when it counts.
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.
More dystopian (and maybe more useful): A roll-eyes emoji when you're asking it to do something stupid.
(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.)
Just spent 15 mins working as the OS, it's much harder than it looks.
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.
I know this is exactly the opposite of the point OP wanted to make, but wouldn't this be the perfect use case for generators?
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.
Then if you call the function, it will return an iterator over all the steps of the algorithm. You could either put it in a for loop like in the recursive calls, or "manually" advance it one step using python's next() function, e.g. inside a frame callback.
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.
Readit News
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.
[1] https://github.com/tomtheisen/mutraction
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 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
"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:
Then if you call the function, it will return an iterator over all the steps of the algorithm. You could either put it in a for loop like in the recursive calls, or "manually" advance it one step using python's next() function, e.g. inside a frame callback.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.
Deleted Comment