Shared publicly  - 
 
My mind is sort of blown by the idea that my IDE could just display the particular whitespace/bracket/paren/line-length/syntax that I prefer, so I would never again have to argue about style in code reviews (but we can still argue about naming). It might even convince me to use an IDE. Wait, what am I saying?!? LONG LIVE EMACS!!!
 
This is the 21st @#!% century!!

Josh's post on programming languages is perfect. It's why I have trouble getting excited about Scala/Clojure/Go. They didn't kill enough sacred cows.
An open letter to language designers: Kill your sacred cows. An open letter to language designers: please, for the good of humanity, kill your sacred cows. Yes, i know those calves look so cute with b...
3
Emil A Eklund's profile photoDutch Meyer's profile photoOjan Vafai's profile photoDavid Nesting's profile photo
5 comments
 
I can't say I agree with point 2 though, being able to use standard unix utils like grep, awk, sed and friends on code is incredibly value, at least to me.
 
are you suggesting that emacs isn't an IDE?
 
Meh. I think I disagree with nearly every point here. Living in a world where I have to used a bloated IDE to touch code is not worth the benefits of not having to worry/think about syntax.

I maybe agree with points 6 and 7, but they're mostly to vague to agree or disagree with. It's an interesting idea to give hints to the GC system what behavior you want, e.g. I could imagine giving hints to V8 about which objects will be long-lived, or which classes are fixed types.
 
Just make the Abstract Syntax Tree your canonical "code". If you want to work in text, a tool (perhaps built into your IDE or VCS client) translates the AST to text, in the programming language, dialect and style of your choice. Type/variable/class names are pretty much the only thing you'd want to preserve, but there's no reason you have to have exactly one of them if you wanted to translate to multiple languages.

Regarding #5, I'd actually love to see a type system augmented with a description of /what/ is stored in that type. Meaning shouldn't be hidden away in camel-case variable names; I should be able to say "this is a credit card number" in a globally unique, machine-readable way.
Add a comment...