[HN Gopher] I coded something dumb and I'm proud of it
___________________________________________________________________
I coded something dumb and I'm proud of it
Author : drfreckles
Score : 134 points
Date : 2024-05-15 12:58 UTC (10 hours ago)
(HTM) web link (plbrault.com)
(TXT) w3m dump (plbrault.com)
| Idiot211 wrote:
| FYI: The link to "You're the OS" points to localhost OP :)
| ryankrage77 wrote:
| https://plbrault.itch.io/youre-the-os
| drfreckles wrote:
| Oof! I was definitely tired! Thank you!
| Idiot211 wrote:
| All good! We all have those moments!
| dontupvoteme wrote:
| 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!
| AnimalMuppet wrote:
| 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.)
| leononame wrote:
| 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.
| colechristensen wrote:
| The young will use and understand them much more.
|
| 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.
| acheron wrote:
| "What are letters?"
|
| "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)
| ang_cire wrote:
| How would they have learned a contraction if everything
| is based on glyphs/ images?
| DEADMINCE wrote:
| Because it wasn't always.
| colechristensen wrote:
| Plenty of words are contractions or otherwise
| combinations of other words that you don't know about
| unless you're particularly interested in language.
|
| "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.
| thfuran wrote:
| You don't need to know how to write to speak.
| bee_rider wrote:
| Haven't read it, but society is quite changed in The
| Diamond Age, I think. In the protagonist even speaking
| English? If not, we could assume it is sort of
| "translated" into English (in the sense that most fiction
| that doesn't take place on modern day Earth is).
| pessimizer wrote:
| I don't think they will. The problem with them isn't that
| people don't understand what they mean, it's that they
| require a lot of context to understand even when they are
| used naturally and freely. There's a reason why languages
| have grammar. They're really used for decoration, or to
| disambiguate between a short list of expected responses
| already established in the past by using words.
|
| 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?"
| deredede wrote:
| 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.
| thfuran wrote:
| There are also occasionally significant visual differences
| between the platforms. Like, a squirt gun and a handgun just
| aren't the same thing.
| julianeon wrote:
| 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.
| fragmede wrote:
| reactj to create jira tickets, kick off PRs/builds/etc are
| the unsung workflow heros of slack
| Levitz wrote:
| 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.
| necovek wrote:
| > I like them in chat though.
|
| 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).
| UI_at_80x24 wrote:
| Yes and No.
|
| 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.
| mr_mitm wrote:
| > I'm on the spectrum, I can't tell what any "face emojii"
| mean.
|
| Then again, about 3% of all people are color blind.
| drfreckles wrote:
| That's precisely why I added emojis. In early versions of
| the game, the starvation levels were only represented by
| colors.
| ravenstine wrote:
| 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.
| reidjs wrote:
| Agree, especially for conveying tone, eg, happy, frustration,
| danger, etc, especially in dialog.
|
| There is an art to using them to enhance a message instead of
| obscuring it, though.
| duxup wrote:
| When used thoughtfully, I find my clients love emojis on some
| things and they seem to work better than many web icons.
|
| 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.
| deadbabe wrote:
| Emojis are incredible for variable names in code, it solves the
| hard problem of naming things.
| thfuran wrote:
| Most importantly, they help make code easier to read than to
| write.
| deadbabe wrote:
| omg yes
| devmor wrote:
| 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.
| scubbo wrote:
| https://en.wikipedia.org/wiki/Chernoff_face supports your take
| - humans are hard-wired to recognize and parse faces, why
| wouldn't we make use of that shortcut!?
| bitwize wrote:
| cdparanoia used to use ASCII emoticons as status indicators --
| :-) for when things were going well for instance.
| nvartolomei wrote:
| You'll love to learn more about Chernoff faces!
| https://en.wikipedia.org/wiki/Chernoff_face
| quectophoton wrote:
| My reaction: _:skull_emoji:_ _:skull_emoji:_ _:skull_emoji:_
|
| > 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
| syndicatedjelly wrote:
| I played this game a few months ago and it was a lot of fun. Nice
| work :)
| leononame wrote:
| I don't think it's dumb. After all, the array can change in
| between renders, so you kind of have to start from scratch
| anyways. And for a list of <1000, who cares?
| drfreckles wrote:
| Exactly :)
| cratermoon wrote:
| If you didn't care about efficiency, why not use bubblesort?
| drfreckles wrote:
| Because the animation needs to pretend to use something more
| efficient.
| jandrese wrote:
| Ironically the particulars of this implementation make it
| much less efficient than a dumb bubble sort. Many Quicksort
| implementations have the worst performance on already sorted
| data, and in this case it will be run a lot on data that is
| already mostly sorted. It won't matter here because the data
| size is always trivially tiny, but it is something to
| consider in the real world.
| drfreckles wrote:
| Again, the need was not to implement an efficient sort. It
| was to implement an _animation_ that pretends to execute an
| efficient sort. Also, quicksort gives a more interesting
| result visually.
| cratermoon wrote:
| There's also the overhead of quicksort compared to
| bubblesort, making it a poor choice for tiny sets of data.
|
| In this case I understand the author's point is to have
| something visually interesting to show the work being done.
| gumby wrote:
| > you are the operating system of a computer.
|
| "I am Jack's ALU"
| timetraveller26 wrote:
| "I am AMD's idle cpu cycles"
| zwirbl wrote:
| I am Jacks branch prediction vulnerability
| jimt1234 wrote:
| I just wanna throw this up here, because I found it to be a
| fascinating take on 'Fight Club':
| https://www.youtube.com/watch?v=wHE7oBvOk9U
| kettro wrote:
| Well done!
|
| 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.
| mjmdavis wrote:
| Honestly this comes across as a smart solution, not a dumb one.
| You big smartie. Such a smart guy. Geez. You're so smart, you're
| very productive and are helping advance society. Thank you.
| tleb_ wrote:
| 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.
| pavlov wrote:
| 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.
| recursive wrote:
| 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.
|
| [1] https://github.com/tomtheisen/mutraction
| p2edwards wrote:
| This is awesome. Thanks for making it.
| eyelidlessness wrote:
| To be fair, this (like many applications of reactivity) is
| conceptually very different from embracing mutability. And
| at least at a glance, it looks conceptually much closer to
| React than that.
|
| 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").
| recursive wrote:
| Solid's proxy-based approach was indeed one of the major
| influences. It's also similar to reactive() in VueJS.
| There's one novel thing in mutraction that's not in
| either though, which is the undo/redo log. It might not
| be very useful in practice. I'm not under the impression
| that I really created anything fundamentally new here. I
| just scratched my own itch.
|
| 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?
| 1-more wrote:
| This is roughly The Elm Architecture https://en.wikipedia.org
| /wiki/Elm_(programming_language)#The...
| _heimdall wrote:
| 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.
| willhackett wrote:
| You know what, this is spot on! And, I'm happy you're proud of
| it.
| ww520 wrote:
| Actually it's clever not dumb. It partial evaluates to the first
| change then stops. It does the job and no more. Very insightful.
| I'm stealing this idea. :)
| AstroJetson wrote:
| 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.
| dclowd9901 wrote:
| It's honestly one of the hardest things for me, trying to explain
| to more junior developers that clever almost is never better.
| Does anyone have any good litmus or heuristic for figuring out
| when something is "too" clever?
|
| 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.
| sgarland wrote:
| If I don't understand something I wrote a month later, it was
| too clever.
|
| Unfortunately, this is a massively lagging indicator.
| tstrimple wrote:
| There's the cyclomatic complexity which I think gets close to
| your reference counting example.
|
| 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.
| jrochkind1 wrote:
| This is kind of fun.
|
| 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?
| drfreckles wrote:
| You're right! I rephrased that.
| fragmede wrote:
| Yay! This game didn't get much traction the first time it got
| posted so I'm really glad it's getting some more attention.
___________________________________________________________________
(page generated 2024-05-15 23:01 UTC)