Live data from Hacker News

Software disenchantment

tonsky.me

51–60 of 98 posts

Re: Software disenchantment

#51
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.

Re: Software disenchantment

#52
post #25

I agree that something is out of whack. In-house plane-jane CRUD development used to be pretty simple and quick in the 90's. One could focus on the domain analysis side instead of micromanage tech. The IDE products had glitches, but got better every release, including deployment. The Web bleeped it all to heck and back, and nobody seems interested in promoting the standards to fix it. We toss in JavaScript gizmos to…

> We toss in JavaScript gizmos to attempt to improve the UI to desktop standards, but these gizmos are clunky and browser-version-sensitive.

Agreed! doesn't anyone know how to write vanilla JavaScript anymore?

relevant: http://vanilla-js.com/

Re: Software disenchantment

#53
post #51

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' c…

Don'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();
    	}
    }

Re: Software disenchantment

#55
I think this is a symptom that, as engineers we are now relegated to a second plane, our focus is just to accomplish the next task set by people who doesn't care or understand a bit about software engineering.

You can read it here multiple times "we are pay to make features", the not so passive sentiment that we should be relegated to code monkeys that accomplish business objectives is just so sad to me.

Re: Software disenchantment

#56
post #25

I agree that something is out of whack. In-house plane-jane CRUD development used to be pretty simple and quick in the 90's. One could focus on the domain analysis side instead of micromanage tech. The IDE products had glitches, but got better every release, including deployment. The Web bleeped it all to heck and back, and nobody seems interested in promoting the standards to fix it. We toss in JavaScript gizmos to…

I think this is what pisses me off the most. The frontend is a complete clusterfuck, but the serverside is almost as bad. Everything is just half-assed and you end up spending most of your time fighting the tech. The worst thing is people who have drunk the Kool-Aid and just stare you, uncomprehending, when you complain that lunatics are running the asylum and the only way to win is to not play. Or at best agree but have ended up silently accepting the situation as a coping mechanism of some sort, like people in abusive relationships. "It's not that bad, there are good moments too, and besides, I'd have nowhere to go anyway."

I think I'm done with the tech industry. 98% of the sort of programming people actually pay you for is about as pleasant as a root canal. I'm currently on a sick leave and seriously entertaining the idea of changing careers to something entirely different. Like gardening.

Re: Software disenchantment

#57
I put some of the blame on an unhealthy insistence of code reuseability and sticking to paradigms. The result is so much code that is just abstractions piled onto abstractions piled on to more abstractions until you get the famous FizzBuzz Enterprise Edition [0] that I'm sure we've all seen by now.

Nobody wants to just write some god damn code anymore. They include entire frameworks instead of just writing a couple helper functions.

[0] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Re: Software disenchantment

#58
Great article! I've been thinking about this problem since 2006, and there are probably a hundred reasons why things are as bad as they are. Many commenters here have hit upon some: misuse of abstractions (they should be used to save time, NOT save knowledge), insistence on code reuse, etc. To add a few more: treating programming like a form of manufacturing instead of an art, believing that the latest language/tool/process is a silver bullet (and even believing that it's new!), not realizing/accepting that constant refactoring is vital, worshiping teams at the cost of individuals, not letting teams form themselves, and a huge one is this: trying to eliminate problems and/or complexity instead of mitigating them with tools and skill-building. If you try to eliminate a problem or complexity, you will succeed, but at the cost of creating at least as many other different problems than you had before, and you'll just end up moving the complexity to another place. Later, when you realize you still have problems, you'll try the eliminate them too, and do the same thing all over again. Building layer after layer, always increasing your problems and complexity while attempting to reduce them. (This is exactly the same as government controls breading more controls, and it happens for the same reasons.)

When I first started out, if you were programming computers at all (microcomputers, anyway) you were someone who was naturally curious and probably had a high IQ. If you continued programming, it's because you really enjoyed the process and had a knack for it. You understood how the computer really worked, and that didn't scare you, it thrilled you. We didn't have "testers" and "UX Designers" and "QA people" back then, so if you produced a good program at all, it's because you had a high level of conscientiousness. Today, that description fits only a tiny minority of the programmers that I know, just like it fits only a tiny minority of the general population. Those programmers all have the same complaints that you do, and they all have side projects that they work on because the work in their day jobs is unfulfilling.

As someone here pointed out, this is a relatively new industry, and I think we're just seeing the same thing that plays out in any industry once "everybody" starts doing it. Just like vacuum cleaners, mattresses, doctors, or oil paintings, there are a handful of great ones, a whole bunch of mediocre ones, and some really awful ones. The bell curve has arrived and is here to stay!

My belief is that if you want to have great software, then make it yourself. Don't wait for the majority of others to produce it, because they never will.

Re: Software disenchantment

#59

I share the sentiment, but I also appreciate the truth. > Text editors! What can be simpler? On each keystroke, all you have to do is update tiny rectangular region and modern text editors can’t do that in 16ms. I use text editors with syntax highlighting. Also IDEs with completion, error highlighting, etc. Assuming we are talking about those, updating a rectangular region is not "all you have to do". (Though it is t…

  I'm failing to see the problem with that dialog
To me, the problem is that you are made to choose that one set of changes must be lost. A better design would be (1) save, (2) revert to original, (3) accept other change version instead, or (4) put me into a diff/merge process so I can control which changes (from both sources) are to be posted.

Re: Software disenchantment

#60
post #38

1) some of these complaints are invalid: yes Linux kill a "random" process when there is no more memory available, but except in 'static' configuration where everything has a known size, what's the alternative? You can have a misbehaving application use lots of memory but it's a normal application whose memory allocation fail, what do you do? 2) this bloat isn't new: I remember being amazed by BeOS responsiveness com…

1) Don’t promise memory you don’t have. On windows VirtualAlloc will fail if it doesn’t have enough page file space to satisfy the request. This allows the application to do something smarter than with the false promise it gets from mmap.

2) Really depends. Applications spend a lot of time in syscalls.

Post reply on HN