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'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.
"I am Jack's ALU"
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 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.