[swift-evolution] Should we consider Swift improvements for indie solo programmers?

[Amir Michail]

I don’t think the issue with long functions being bad is that clear. See this:

https://news.ycombinator.com/item?id=8374345

> On Dec 12, 2015, at 9:44 AM, Al Skipp <al_skipp at fastmail.fm> wrote:
> 
> I strongly support the idea of Swift being approachable to everyone, from individuals working on small projects, or learning programming for the first time, to large complex projects. To make this a possibility I believe it’s important that the language not become too big, by accumulating every conceivable feature. 
> 
> It’s not a bad thing if the language discourages certain constructs, it may seem pernicious at first, but you’re likely to thank it later. 
> 
> The trouble with exceedingly long methods is that they’re potentially easy to write, almost certainly difficult to read and a complete nightmare to change afterwards. Think about your future self, do you want to subject them to unnecessary pain?
> 
> I think it’d be doing a disservice to learners if the language encouraged quick gain, but long term pain.
> 
> 
>> On 12 Dec 2015, at 13:54, Amir Michail via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Unlike those working in teams, indie solo programmers may be happy with some non-optimal coding practices (e.g., very long methods, etc.)
>> 
>> Should we consider improvements to Swift that are of interest mostly to indie solo programmers (e.g., optional “} /for”, etc.)?
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>