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

[Jonathan Hull]

> On Aug 31, 2017, at 8:56 AM, Alex Blewitt <alblue at apple.com> wrote:
> 
>> I have written my own library with this (it was one of the first things I wrote in swift) and there are several others available online.
> 
> OK, so link to them, and get the various parties to agree on using one definition instead of several.

So instead of “Nothing is stopping you from doing this yourself” it is “Nothing is stopping you from doing this and then getting the entire internet to somehow agree on the one true version”…  That is a much larger goal.


>> The issue is that if I want to include another framework, and that framework has also defined it (or more likely relies on another framework that defines it) then swift gets upset about the multiple definitions.  I really want to rely on those libraries, but if it makes my own framework have a danger of conflicts with other libraries then it will stop adoption of my framework as a result.
> 
> This hasn't stopped a number of others from relying on types they've defined, like the Result type, for example.

Things like Result can be differentiated by the module name in case of conflict. That isn’t possible with operators.

Also, there are now two versions of AlamoFire which need to be kept in sync depending on which Result type they use.


>> It seems extra ridiculous because those definitions are all basically identical.  Do you see the issue?
> 
> There's a difference of expectations here as to the purpose of the swift-evolution list. It's not about growing personal preferences of how to achieve that which is already available and possible to do today.


I view lack of ‘≤’ as a symptom of a much larger issue.

I know I have a different way of looking at things than most people on this list (I mainly work as a designer and teacher), but little details like this really affect the experience of using Swift, especially for beginning programmers.  One of the things that drew me to Swift was the level of thought that was clearly put into this sort of thing over the first 2 versions.  Starting with version 3, Swift has been growing much less pleasant to use over time, which makes me really sad.  I attribute that mainly to focusing only on big structural things (and functionality), and ignoring the little “insignificant” details which actually make or break the experience.

The niceties just aren’t important enough to devote any time or thought to. “Sure that would be nice, but we could use that time to do ____”.  It is funny, because people spend way more time writing up arguments for why we shouldn’t think about these things (because of lack of time) than it took to write the 6 lines of code to do them.

Every time I bring up an issue like this I get a couple of messages telling me that maybe Swift just isn’t for me, and that I should go find another language instead.  I am the only one of my friends/colleagues left on this list, so maybe I will eventually do that. But shouldn’t Swift be a language that works for people like me too?  I don’t think it should be only for hard-core compiler engineers.  I think this list would benefit from a multitude of voices with different viewpoints, but it seems to view as irrelevant and vocally chases away any viewpoint/mindset which doesn’t match the dominant one.

Thanks,
Jon

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