[swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols
cocoadev at charlessoft.com
Tue Aug 29 20:50:06 CDT 2017
> On Aug 29, 2017, at 8:25 PM, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
> But the question is, why does this need to affect the code base?
> In the article you attached, they mention the antiquated one-line calculator display. The issue with that display is not the data stored in the calculator; it’s the display itself. An upgrade to (say) a Texas Instruments Inspire or whatever the newest TI calculator is (in my day we used an 83 or 84) only changes the display of the data; after all, you input that data will old fashioned buttons as well. The calculator isn’t doing any magic with the data itself in order to display that. If you want nicely formatted fractions, square roots, or matrices, go to WolframAlpha and type in your expression in ascii; you’ll see nicely formatted output.
> Which is all to say, if you want pretty graphics in your code, all you need is a better front end. The backend can — and in absence of a better argument, should — remain unchanged.
Heck, we have a bit of this already, when you consider things like Xcode’s image literals. Said literals can also illustrate some of the dangers of going too far with fanciness in the text editor, as anyone can attest who’s named a graphic “info” and then had it auto-complete every time they wrote a closure containing the “in” keyword followed by a carriage return.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution