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 <email@example.com> 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