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

71–80 of 88 posts

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

#71

Post by Arrath »

sgarland wrote: post #59
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…

If I don't understand something I wrote a month later, it was too clever. Unfortunately, this is a massively lagging indicator.

Yeah that's the textbook example of closing a barn door after the horse gets out, eh?

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

#72

Post by zeroonetwothree »

_heimdall wrote: post #60
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…

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…

Many people use flux-variants like redux which is basically what you say.

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.

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

#73

Post by resonious »

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…

One problem with this that I've found through similar endeavors is: the act of making the library results in you knowing how it works on a deep level. It's likely you don't know React on such a level. This inflates your perception of how easy to use it is. If you did know React that well, you'd probably be able to use it very effectively!

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

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

#74

Post by lmm »

thfuran wrote: post #38
deadbabe wrote: post #32

Earlier quoted context omitted.

Emojis are incredible for variable names in code, it solves the hard problem of naming things.

Most importantly, they help make code easier to read than to write.

Those who forget APL are doomed to reinvent it, poorly.

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

#75

Post by xmprt »

UI_at_80x24 wrote: post #10
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!

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

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.

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

#76

Post by recursive »

resonious wrote: post #73
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…

One problem with this that I've found through similar endeavors is: the act of making the library results in you knowing how it works on a deep level. It's likely you don't know React on such a level. This inflates your perception of how easy to use it is. If you did know React that well, you'd probably be able to use it very effectively! Anyway I did take a look at Mutraction and it looks great actually. I've just m…

Before I built this, I spent a couple of weeks reading the react source code. Of course, it's huge, and I didn't touch most lines. Probably never saw most of them. But it was enough to understand dispatchers, work scheduling, and fibers.

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.

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

#77

Post by _heimdall »

zeroonetwothree wrote: post #72
_heimdall wrote: post #60

Earlier quoted context omitted.

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…

Many people use flux-variants like redux which is basically what you say. 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…

Yeah I did actually try a few flux-like libraries early on. I actually used redux for state management in an Angular 2 app. It worked better than I would have expected, but async was always a problem - at the time thunk and sagas were the solution and both were painful IMO.

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.

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

#78

Post by rasz »

tleb_ wrote: post #27

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

While this sounds elegant, its also computationally more expensive.

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

#80

Post by skydhash »

_heimdall wrote: post #77
zeroonetwothree wrote: post #72

Earlier quoted context omitted.

Many people use flux-variants like redux which is basically what you say. 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…

Yeah I did actually try a few flux-like libraries early on. I actually used redux for state management in an Angular 2 app. It worked better than I would have expected, but async was always a problem - at the time thunk and sagas were the solution and both were painful IMO. 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 st…

That’s what I try to do with every declarative UI i’ve worked on. Hoist all the logic that act on state outside of the view modules. Then you plug it in via functions. A list component may have only one hook (useItems) that take in a filter/search state and another (useSelection) that is dependent on the first. This ensures a clean relationship graph. Having everything in a smart component is where you got the spaghetti nightmare of relationship graph.
Post reply on HN