Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I coded something dumb and I'm proud of it

plbrault.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: I coded something dumb and I'm proud of it

#61

Post by quectophoton »

dontupvoteme wrote: post #3

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!

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

Re: I coded something dumb and I'm proud of it

#62

Post by necovek »

leononame wrote: post #9
dontupvoteme wrote: post #3

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 w…

> 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).

Re: I coded something dumb and I'm proud of it

#63

Post by eyelidlessness »

recursive wrote: post #44
pavlov wrote: post #33

Earlier quoted context omitted.

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…

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/mutra…

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 staterender abstraction, or just maintain state in the view itself, probably both”).

Re: I coded something dumb and I'm proud of it

#65

Post by fragmede »

julianeon wrote: post #47
leononame wrote: post #9

Earlier quoted context omitted.

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 w…

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.

reactj to create jira tickets, kick off PRs/builds/etc are the unsung workflow heros of slack

Re: I coded something dumb and I'm proud of it

#67

Post by tstrimple »

dclowd9901 wrote: post #51

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…

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.

Re: I coded something dumb and I'm proud of it

#69

Post by recursive »

eyelidlessness wrote: post #63
recursive wrote: post #44

Earlier quoted context omitted.

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/mutra…

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…

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?

Re: I coded something dumb and I'm proud of it

#70

Post by drfreckles »

jrochkind1 wrote: post #54

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?

You're right! I rephrased that.
Post reply on HN