5 ms·

The coding part of the software development process. We're still writing code in a text editor like we were 40+ years ago. The editors have become more powerful

The coding part of the software development process. We're still writing code in a text editor like we were 40+ years ago. The editors have become more powerful but writing code is still very similar.

jhayward 6y ago
40* years ago I was using an IBM 029 keypunch, and sequencing my cards using an offline sequencer in case I dropped the deck. Today I use an editor that knows, semantically, the context of everything I type. It suggests nouns, and checks compatibility. It automatically shows me documentation for APIs. It knows several hundred common pitfalls to watch out for and suggests corrections for them. It even auto-formats my code so I don't have to dink around doing that. We've come a long long way in 40 years. * Ok, it was actually 1979. We got Vaxes and VT100 terminals with VMS EDIT 4 years later. The state of the art in editing was QED, a souped up version of unix 'ed', and vi hadn't really escaped Berkeley yet. Somewhere in MA and CA, some people were munging TECO to become Emacs.
xavierlint 6y ago
Besides all other points by jhayward, what kind of changes do you have in mind? From my perspective at first sight it isn't necessarily negative that we are doing the things in a pretty simlar way as to how we were doing them 40 years ago.
- geoffeg 6y ago
  A few things I've been considering for the last few years. These are just brainstorming thoughts, so I definitely haven't thought these ideas through. * Why do editors allow us to write invalid code? Most editors know the syntax of the language, many embed (or connect to) the language runtime. If the editor knows a file is going to be invalid, why allow it to be saved (allow the user to force the save, of course). * Why are editors still showing us entire files instead of functions? I usually edit code by looking at functions and how they relate to other functions. Why not show a function at a time and allow you to bring up multiple functions at a time to edit, regardless of which file it's in? Light Table (http://lighttable.com/ http://lighttable.com/) started down the path of what I was thinking, especially with the continual/inline code evaluation. Once again, these are primarily just thoughts I've been considering. I haven't found a good outlet for discussing my ideas, everyone I discuss them with seems to respond that "that's the way things are" or "that sounds complicated". I've been considering writing a little editor proof of concept to explore some of these thoughts.

jhayward 6y ago

40* years ago I was using an IBM 029 keypunch, and sequencing my cards using an offline sequencer in case I dropped the deck. Today I use an editor that knows, semantically, the context of everything I type. It suggests nouns, and checks compatibility. It automatically shows me documentation for APIs. It knows several hundred common pitfalls to watch out for and suggests corrections for them. It even auto-formats my code so I don't have to dink around doing that. We've come a long long way in 40 years. * Ok, it was actually 1979. We got Vaxes and VT100 terminals with VMS EDIT 4 years later. The state of the art in editing was QED, a souped up version of unix 'ed', and vi hadn't really escaped Berkeley yet. Somewhere in MA and CA, some people were munging TECO to become Emacs.

xavierlint 6y ago

Besides all other points by jhayward, what kind of changes do you have in mind? From my perspective at first sight it isn't necessarily negative that we are doing the things in a pretty simlar way as to how we were doing them 40 years ago.

geoffeg 6y ago
A few things I've been considering for the last few years. These are just brainstorming thoughts, so I definitely haven't thought these ideas through. * Why do editors allow us to write invalid code? Most editors know the syntax of the language, many embed (or connect to) the language runtime. If the editor knows a file is going to be invalid, why allow it to be saved (allow the user to force the save, of course). * Why are editors still showing us entire files instead of functions? I usually edit code by looking at functions and how they relate to other functions. Why not show a function at a time and allow you to bring up multiple functions at a time to edit, regardless of which file it's in? Light Table (http://lighttable.com/ http://lighttable.com/) started down the path of what I was thinking, especially with the continual/inline code evaluation. Once again, these are primarily just thoughts I've been considering. I haven't found a good outlet for discussing my ideas, everyone I discuss them with seems to respond that "that's the way things are" or "that sounds complicated". I've been considering writing a little editor proof of concept to explore some of these thoughts.