[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

[John McCall]

> On Sep 1, 2017, at 2:33 PM, David Sweeris <davesweeris at mac.com> wrote:
> 
> 
>> On Aug 31, 2017, at 6:27 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I would argue that there is a much broader philosophical truth here.  Programming is not, and never can be, a pure exercise in mathematics, and the concepts necessary for understanding programming are related to but ultimately different from the concepts necessary for understanding mathematics.  That is, Dave Sweeris's mathematicians and physicists are almost certainly misunderstanding their confusion: saying that the syntax is wrong implies that there could be a syntax that could be right, i.e. a syntax that would allow them to simply program in pure mathematics.
> 
> I don't think any of them claimed that any particular programming language's syntax was wrong, just that they were confused by it. I only have a clear(ish) recollection of one of them -- the others were too long ago -- and he said something along the lines of "Mathematica is as close as I get to programming because I don't have time to learn how the CS people write things" (and I think his hand was forced WRT learning even just that, because Mathematica was part of a class he was teaching). Anyway, at the time, his sentiment struck me as "not unique", so I'd guess that it tickled a memory of someone(s) expressing somewhat similar views to me before. To be clear, I'm not claiming that view towards programming is common in the general mathematician/physicist population... When I find out someone's an expert in some field in math or physics, I'll probably talk to them about that; programming isn't a subject I'd be likely to raise unless their area of expertise is "Computational Whatever". So not only is my dataset far too small, and merely anecdotal, it also suffers from selection bias.
> 
> Anyway, the point I'm taking my own sweet time getting to is that if Swift's goal is world domination, I think a good place to start with the scientific community could be to let them use the same syntax they learned while spending the better part of decade or more studying. Obviously, Swift already goes a long way towards that goal by allowing custom unicode operators and such, but if you're telling me that getting prettyprint might be in-scope(ish), too...

Pretty-rendering of expressions and/or formula editing ultimately feel like editor features to me.  If there's something you'd specifically like from the language to assist with that, that's in scope to discuss.  As someone else pointed out, a language feature here isn't strictly necessary: existing formula editors typically render on-demand from a textual representation of the formula instead of storing layout information in the source.  Now, I could imagine an editor wanting some way to embed structured rendering hints in the source without affecting compilation; that seems like a reasonable feature to request.  However, we'd want to make sure it was actually going to be used, which means we'd want to be collaborating on it with someone working on an actual editor, not just designing it in the abstract; and of course we at Apple would not be promising that Xcode would actually adopt any of those hints.

John.

> Well, I still think that in the long run that problem should to be solved by the OS so that whatever data that ends up getting prettyprinted as "x²" will render that same way in every application, even when sent to the console via `print()` or `cout`. In the meantime I won't complain if the first step towards that goal is getting it in the editor, but I worry that such an approach would lead to us creating the 15th standard (https://xkcd.com/927/ <https://xkcd.com/927/>). And it's like my momma always said, "you should be part of the solution, not part of the precipitate".
> 
> - Dave Sweeris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170901/b7a509a8/attachment.html>