Hacker News new | past | comments | ask | show | jobs | submit login

After using vim for a few years now, I noticed how I changed from thinking about text as characters to thinking about text as lines, which lets me create much cleaner code (independently from pretty printers).

When I selected code via mouse in the past, I selected it from character to character. In vim I tend to think line-wise so I can yank, paste, delete code per line which makes sense in many scenarios.




I have been noticing this effect as well, and I was thinking that there needs to be a change in how we design programming languages. The old programming languages are treating characters or words as atomic units, but human mind does not really work at words. We work at sentences or lines. Each line can have its own context and can host more flexible syntax. On one hand, the programming languages can be more expressive when designed toward line units -- lines naturally can host more vocabulary than isolated words; on the other hand, the compilers and parsers can actually be simpler or smarter, as lines pose boundary of syntax and errors may be confined and easy to recover.


Lisp?


Yes and no. In my experience vim is great for manipulating s-expressions because it has expressions like da( which means "delete everything between the parens wrapping the cursor".

But no, many lisp dialects have a tendency towards nesting expressions which will force them accross many lines which doesn't match up with ^^'s idea of keeping lines context free.


Sure, but then you just say that the atomic unit is not the line, but rather a list.


BASIC, surely? (-:


For mutating programs (as opposed to general text-editing), this text-centrism seems to me like a limitation. I use a combination of IntelliJ & emacs, and the former's deeper model of the programming language syntax definitely leads me to me thinking in terms of a syntax tree units rather than 'text', such that programming in emacs feels like going down a cognitive-abstraction step. The gap can probably be bridged with language servers (I haven't spent the time to look into what's available for the languages I use).


In general, I agree that a syntax-tree would make more sense, but I think the text centrism is some sort of greatest common denominator as that approach works for many languages (more or less). A syntax tree on the other hand, would work better but probably required some sort of training for every new language :-/


Sure, but I wasn't making a unicorn pitch. My point is that IntelliJ's relatively deep code insight nudges things in that direction right now, to an extent that makes coding in traditional editors (emacs being my favourite of these) feel a little primitive. In emacs, to change a function signature, I operate on lines of text, often across multiple files. In IntelliJ, I work on the level of the function signature, and only incidentally interact with it as 'text'.

This is partial and patchy at best, but IMO a move in the right direction (towards affording higher levels of cognitive chunking when coding). Some languages have elements of this kind of thing working with traditional editors (eg Go Doctor for golang), and I'd ultimately prefer this less monolithic approach, but it's not really there yet.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: