That would require every bit of software that presents this program not only to understand my programming langauge, but also to have enough context on the rest of the program to actually recognize the function and know what each parameter represents.

Not to mention, code is itself a presentation layer. Why would you put some presentation concerns in one layer (e.g. identifier names, indentation&styling), but others in another presentation layer?

this is true actually. every place we read code needs to also parse the code. it’s already happening today, that’s how you get syntax highlighting. the future of all code review in the browser is a more similar experience to coding in an ide. and eventually the browser will replace the ide (and you could say this is already happening too)

> every bit of software that presents this program not only to understand my programming language

You can either change your program to fit existing tools, or you can build smarter tools. I prefer the latter.

> code itself is a presentation layer

Not for the tool it isn't

edit: I think we can all agree that ideally we fix this in the language itself by adding optional named parameters

No matter how smart the tool is, unless it can see the definition of the function, it can't guess the parameter name. Code is often shared on mail, chat programs etc, requring me to send compilable code snippets to get nice presentation out of a blob of text would be significant overkill...

Your IDE could automatically add those annotations as rich text or embedded HTML when you copy the source code out from the IDE into the E-Mail.

Would it be rich text when I copy to WordPad and HTML when I copy to a web page? Would it also support Markdown and maybe wiki ML? Would IntelliJ know that when I'm pasting code to an Emacs buffer in java-mode it should paste plain text, but when I'm pasting to an Emacs buffer that is an email, it should instead add org-mode annotations?

Overall this concept of copy/pasting with context is nice, but it only works for applications that have a defined API between them, such as MS Office OLE objects. In all other cases, pasting plain text is better than any "smart" solution.

So your solution is to write code that is currently hard to read in the hope that someone will make a tool that presents it nicely in 10 years?

OTOH, programming for the human and not for the computer, included caring about presentation. I could say there's nothing right with the model either - a non-issue, personal preference.

... An older presentation issue is the tabs versus spaces flamewar. At least that one has burnt out. Maybe because of the rise of IDE's?

> ... An older presentation issue is the tabs versus spaces flamewar. At least that one has burnt out. Maybe because of the rise of IDE's?

My guess would be not IDEs but autoformatting tools, especially when communties like Go all follow one style.

> The point is that this is a presentation issue.

I think the point was that it shouldn't be.

> There is nothing wrong with the model

Seems to me there is.