[swift-evolution] Should we consider Swift improvements for indie solo programmers?
a.michail at me.com
Sat Dec 12 10:14:34 CST 2015
I don’t think the issue with long functions being bad is that clear. See this:
> 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
More information about the swift-evolution