5 ms·
This comment resonated a lot with me. Here's something I was thinking about recently: 1) I also started programming very young, maybe eight or nine years old.
by subjectsigma 6y ago
This comment resonated a lot with me. Here's something I was thinking about recently:
1) I also started programming very young, maybe eight or nine years old.
2) My first language was Python and I still program in Python today, the programming language with the motto "there's only one way to do it". At some point I had to write Perl for a summer job and it's TMTOWTDI attitude and many symbols nearly broke my brain, I hated it for most of the summer.
3) I used vim and then emacs for a very long time, and recently started using Visual Studio Code and Pycharm. This made me realize that one of my favorite features of any editor was actually the minimap VSC provides on the side by the scrollbar (which Pycharm does not by default provide). Not having it, having it, and then not having it again made me realize I utilized it a surprising amount even though it's a seemingly trivial feature compared to, say, code completion or syntax highlighting. It was just very fast for me to jump around a large file by clicking on the minimap; I knew where to click to jump to the function or class I wanted.
4) I am a vicious style guide zealot. I got poo-poo'ed once by a coworker for submitting a large commit where the only changes were renaming things to snake_case. But the code just looked wrong to me, I had to do it. I write C/C++ in K&R style and find it difficult to read code not indented as such.
I was sitting on my lunch break and all these things kind of crashed together into a great epiphany - maybe the reason I program in this specific way is because the code has to look a certain way in my head. Like I'm literally imagining a sort of minimap in my brain and if the syntax, conventions, order, spacing, etc. are wrong it screws up my very visual model because it literally looks wrong. The more rigidly the code follows the rules, the more visually consistent it is and the easier it is to structure.
Your comment makes me wonder if there really is some semi-visual, semi-textual model that certain programmers form of their code, which is ever-present but really hard to express in other ways. I also wonder if this is a common thing, and if it helps or hurts when programming.
- neolog 6y agoI love the way you've put this.
- TeMPOraL 6y agoI'm like you - except I started with C++ (and prior exposure to Basic, Pascal, and VBA). The code has to "look right"; it's a visual thing, but there's no describable or drawable "shape" I could point to. I've been through the "code case and bracket style must match" period, but eventually my brain abstracted over it, and it's now a free variable - I can work with any style, but it must be consistently used, or else it'll trigger that visual feeling of literal ugliness. I also had a visual enlightenment with Lisp code, where one moment, I thought it was clumsy, and then something clicked, and ever since I consider a (properly formatted) Lisp code beautiful.
- bitwize 6y agoI understand this phenomenon all too well. I experienced another, similar phenomenon, albeit not with the code itself. I've done literally all my best work for the past 25 years in Emacs. Recently I decided to switch to Visual Studio Code because "that's where the momentum is now". Well, it lasted a few weeks and then it was back to Emacs. I wondered why this was. I realized that despite using Borland and Microsoft IDEs in the 90s, I never acclimated to the way IDEs in general handle small tasks like bracket matching and indentation. Emacs does these things right in a way that virtually every other IDE-like editor does wrong. I can work with vim, but working with VSCode has a sort of tactile (instead of visual) "ugliness" about it that increases friction and makes me actually less productive. That and the wrong way VSCode handles File / Open by default made me frustrated enough to go back to Emacs.
- jodrellblank 6y ago> Emacs does these things right in a way that virtually every other IDE-like editor does wrong. ? > the wrong way VSCode handles File / Open by default ?
- bitwize 6y agoRight: Electric indent. Tab at beginning of line automatically indents line to desired depth. Editor's guess at indentation level is almost never wrong, and the exact level is configurable. Wrong: Hit return and the next line is automatically indented; other than that you're on your own. Right: Flash the opening bracket or quote when you type the closing bracket or quote. Wrong: "Helpfully" close opening brackets or quotes, but do not provide Paredit-like structured editing features, leaving the user to accidentally type spurious extra brackets/quotes. (Some IDEs skip over the preinserted closing mark when you type the same mark with point on the closing mark. But they're woefully inconsistent about this and Visual Studio Code does not do this.) Right: Visiting a file does not otherwise affect editor state. Wrong: All state for the editing session in the current window is clobbered when you do File / Open from the menu. User must spawn a new window in order to preserve editing state in this window.
- ChrisMarshallNY 6y agoI can relate. Speaking only for myself, I’m a wee bit “on the spectrum,” and basically work in some kind of “symbolic IDL,” inside my head. As long as I never need to verbalize my design, I can keep a pretty massive architecture completely unwritten, in my mind. This makes it possible to work extremely quickly, with big “on the fly” changes to my implementations; performed “inline,” as I work. The moment that I need to verbalize or “overall” document things, though, the whole gravy train comes to a screeching halt, as my brain needs to do some kind of “context switch.” BTW: my code is pretty “anal.” Highly formatted and documented. I actually feel physically uncomfortable, if it isn’t formatted the way I like.