3 ms·
Love this article. I gave an internal talk recently that was about the sad state of programming right now. How we used to set a variable in assembly language:
by bcheung 8y ago
Love this article. I gave an internal talk recently that was about the sad state of programming right now.
How we used to set a variable in assembly language:
mov [foo], ax
How we do it in React / Redux
// constants.js
export const SET_FOO = 'SET_FOO'
// actions.js
import { SET_FOO } from './constants'
export const setFoo = foo => ({ type: SET_FOO, payload: foo })
// reducer.js
import { SET_FOO } from './constants'
const initialState = { foo: 0 }
const reducer = (state = initialState, action) => {
const { type, payload } = action
switch (type) {
case SET_FOO:
return { ...state, foo: payload }
default:
return state
}
export default reducer
// Component.js
import { connect } from 'react-redux'
import { setFoo } from './actions'
class Component extends React.Component {
handleSetFoo = foo => {
this.props.dispatch(setFoo(foo))
}
}
export default connect()(Component)
I don't understand how people don't see something is horribly wrong.
- commandlinefan 8y agoDon't forget Enterprise Java: public class VariableSetter { private String variableName; private String variableValue; private VariableSetter(); public VariableSetter variableSetterInstance() { return new VariableSetter(); } public void setVariableName(String variableName) { this.variableName = variableName; } public void setVariableValue(String variableValue) { this.variableValue = variableValue; } public String getVariableName() { return this.variableName; } public String getVariableValue() { return this.variableValue; } } public class VariableSetterFactory { private VariableSetterFactor() { } public static getVariableSetterFactory() { return new VariableSetterFactory(); } public VariableValueSetter getVariableSetter() { return VariableSetter.variableSetterInstance(); } }
- sha90 8y agoThis is extremely hyperbolic, and I'm sure you know this. Here's how you set a variable in React: const foo = 1; What you're doing in your complicated sample is not _just_ setting a variable, you're also exposing it to a KVO subscription system that you could never represent succinctly in ASM. What's sad is how programmers communicate programming concepts right now, with quick digs and hot takes and zero actual critical thought to what is being compared. I'm disappointed that you're spreading FUD in your internal talks.
- JoeAltmaier 8y agoYes, still its a way to set a value. And don't be so sure you can't make an entry in a KVO subscription system in asm - of course at bottom that's exactly what's happening. I'm disappointed at the zero-attempt-to-understand-the-point digs made on hacker news (like the one I'm responding to). The point is, how is multi-layered abstraction an unalloyed good? Its heavy, slow, complicated to author and explain, and not doing all that much of value.
- bcheung 8y agoYes, it's an apple to oranges comparison, but the point is more why are we using an orange when an apple will suffice? The real question is, is all that really needed? We keep building abstraction layers on top of abstraction layers when often times, there is already tried and proven solution that works and is much simpler. I've been doing some experimenting creating a single page application (SPA) without a web framework and turns out you can get 90% of what React offers with a tiny amount of code. https://github.com/brennancheung/volgenic/blob/master/13-IDE-components/src/components/Overlay.js#L51 https://github.com/brennancheung/volgenic/blob/master/13-IDE... My current iteration is just to do a: State.update(() => { state.foo = 123; state.other = 456; }) I just use plain javascript objects to store data and wrap it in a function that will trigger re-rendering the VDOM / repaint. And even if we do need that additional layer of abstraction we can always make it appear simpler and provide a cleaner interface to the programmer. A Proxy object setter could be used to eliminate the boilerplate of State.update. Good abstractions simplify the problem by creating a mental paradigm that is closer to the problem domain. Poor abstractions do the opposite, they take away what is needed to solve the problem and create additional steps that are not really germane to the problem. Many abstractions are well intentioned, but after we toss layer on top of layer, we often get so far removed from the problem domain, we have to ask ourselves if it is not simpler to just build up another set of abstractions that allow us to get closer to the problem domain (i.e., "First Principles").