Shared publicly  - 
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...
Tomas Pollak's profile photoEmily Soldal's profile photoBrian Harris's profile photoMichael Leuthold's profile photo
... though I'll admit to be tempted by Dart's pragmatic type system.
Just started reading it, but I +1'd as soon as I saw: Cow #1: source code is ASCII text on disk.
+1 for suggesting an xml based language! </sarcasm>
You basically say VI and Emacs could one day be deprecated... The harshest holy war in the history of computer science will now enter a truce and the fighters will join forces against you. Expect a rough ride. :)
These days, what with the rise of bitbucket and github, I don't think you're really going to get anywhere with a language that doesn't interact well with existing VC systems. I think as a pragmatic measure this then limits your on-disk source format to something like directories of XML or YAML, and implies that you are going to need to consider how to present the difference between two versions of the codebase carefully. (That is, if you insist on a GUI code editor, you also desperately need a GUI differ and merge tool)

I'd be interested in languages designed with social coding of the bitbucket/github kind as an explicit goal; a good diff and merge tool is a prerequisite so that your new language ends up no worse than traditional languages at social-style coding, but I wonder if there aren't better ways to explicitly plan at the language level for social features.
Note that the features needed for good social coding are a superset of those needed for effective code review. (Another explicit language design goal I'd like to see)
These days, what with the rise of bitbucket and github, I don't think you're really going to get anywhere with a language that doesn't interact well with existing VC systems. I would have said exactly the opposite actually. To me the fact that GitHub spread like wildfire is an indication that developers were not locked into a specific version control system. Asking whether they're locked into a specific code representation (flat text files) is the next logical step.

I'd go further and say that GitHub is your best point of entry: extend Git to support your rich code format and you immediately get hundred of thousands of users. As for merging/diffing/reviewing, a richer format could be at least as efficient as what we have today -- just convert to the user's favorite text representation beforehand. Where it could shine, though, is if killing this sacred cow allowed you to discover new/better ways to explore/diff/merge/review/analyze code.

Moving beyond flat text files has the potential to make languages development-tool-aware. This is a very hard idea to propose given how the most brilliant programmers really enjoy being "close to the metal": flat text file, emacs et al. But personally I believe Josh has hit the nail on the head.
For the IDE-requiring points I would point him towards the aspectj community and then let him try to convince me required, good quality IDE integration is a reasonable thing to require and won't kill your language from lack of adoption.
+Josh Marinacci True, but the benefits have to be huge to get people to be willing to consider dropping their favourite IDE in order to use your language. Code editor wars are big for a reason; telling people they need to use a specific IDE is like telling a painter they have to use a specific brand and type of paint brush, and that doesn't typically doesn't go over well.
Cow #1, the idea is good, strange that nobody tried this before.

The only problem with it I see: I prefer to have my code always as I left it (visually), of cource unless someone else changed it.
Will IDE be able to do that, if it basically generates the final view based on templates? Sure there are multiple solutions, like view cashing or no off template editing, but it can get messy.
Also, if you follow a strict coding style (as you should :)) then you should be able to code it in the IDE renderer.
Anyone who worked with LINQ - which is btw. one of the killer features of c#, will understand me.
Add a comment...