Should we consider Swift improvements for indie solo programmers?

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.)?

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Even when not working in teams developers should maintain a good code
structure & practices.

   - They may revisit the code after a long time has passed and then need
   to understand it again.
   - They may join a team some day and then carry over the the
   bad/"non-optimal" practices over.
   - Many developers start learning programming or a new language in solo
   projects. They should learn a language along with good practices.
   - They tend to underestimate that quick & dirty coding causes technical
   debt over time and will some day bite them.

Also if they really do not want to follow good practices then there's no
need for something like "} /for". They could just use "} // for".

···

On Sat, Dec 12, 2015 at 2:54 PM, Amir Michail via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

You’re not going to find me arguing with John Carmack! But I don’t think his argument was suggesting long functions are a panacea. If you’re dealing with lots of mutable state, it’s perhaps not a bad idea to do that all in one place. If possible, have less mutable state ; )

Incidentally, he’s since warmed to the idea of a functional approach being practical:

Regarding Swift, it can't attempt to support every syntactic construct. It’s great that everyone can now make their proposals for what they think is important. The difficulty is how to juggle all these different proposals, good luck Apple folk!

···

On 12 Dec 2015, at 16:14, Amir Michail <a.michail@me.com> wrote:

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

John Carmack on Inlined Code | Hacker News

On Dec 12, 2015, at 9:44 AM, Al Skipp <al_skipp@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution