the article talks a lot about the parentheses but honestly i have to think that’s the wrong way to go about it. when i write lisp in stock vim i type a lot of i()ESChi. then i don’t even have to think about the parentheses. it’s a pain in the ass to do it that way obviously which is why most lisp developers use plugins. but with the right formatting you read it just like python. control flow is a problem for me in some lisps though. for what it’s worth, i thought the error the article had with the missed parenthesis was pretty noticeable.
also maybe more importantly, i kinda don’t think the proximity argument holds water. plenty of languages use all sorts of spacing to delimit arguments and none of them are harder to read than c. smalltalk comes to mind, which the stackoverflow annual survey once had as its most beloved language of the year. objective-c had similar syntax but with square brackets. i don’t think either one was particularly hard to read, just unfamiliar to c-only programmers. obviously that was a problem for a “language” that just bolted a new thing onto c, but i don’t think it’s a problem in general.
i don’t. more importantly, my package manager doesn’t. that is, every package manager i can think of references git commit hashes in its build system. the end user trusts that when they build from commit
xxxxxxxx, they’re getting the exact same code as everyone else. what exactly is being signed in these build systems i don’t know, but whatever scott or linus or anyone else wishes would happen, in the real world, commit hashes are a part of the trust chain.then again, a lot of package managers just use tags. so maybe in practice, they do trust microsoft.