[Roadmap] Does Exercism Teach Everything I Need to Know?

先阅读 v3 roadmap issue (#690)、docs/concept-exercises.md 和 languages/csharp/reference/out-of-scope.md。确定 roadmap 文档是否应定义 concept exercises 的作用、Exercism 的范围、术语以及对工艺质量的期望。当预期的指导和边界已经记录得足够清晰，能够指导 exercise 和 after.md 的决策时，即视为完成。

This is feedback on the v3 roadmap (#690) and the first few sections of the Concept Exercises document.

Role of Concept Exercises

I wonder if it would be possible to say something in the roadmap-type docs about the role of concept exercises in the student’s wider learning experience. Do we think that following the track of a language could lead to fluency on its own (i.e. with provided links but without additional tutorials)? Or is it more a companion resource as it is for v2. In specific cases this can inform the discussion of how hard we have to try to squeeze things into an exercise. It informs trade offs between a providing compelling exercise story and a comprehensive explanation of a topic.

In particular, knowing Exercism’s intention in this area will provide some guidance about the tone and contents of each exercise’s after.md document and the degree to which multiple concepts are combined in an exercise. If the aim is more that of a tutorial then it makes a lot of sense for an individual exercise to be a gentle introduction to a number of concepts. If the intention is to act as a companion to other material then covering ground in depth for a single topic and having an after.md document that is a good reference for that single topic may be a better approach.

Exercism’s Ambition

I think it is also important to say something in the roadmap-type docs about the limitations of exercism's ambition. This would provide justification for the sort of document we have in the csharp track, https://github.com/exercism/v3/blob/master/languages/csharp/reference/out-of-scope.md. For instance if we are not teaching the student about package managers (for practical reasons) which are essential to the craft then why should we worry too much about a less used part of the language such as C#’s unsafe code.

Minor Wording Issues in (#690)

each exercise should be focussed on getting someone to use a concept for the first time

I interpret this as meaning that the exercise should concentrate on a concept. If addressing more than one concept is acceptable then we should mention that and perhaps say something about how such concepts should be related. There are pedagogical tensions here which I am happy to elaborate. We should say something about the extent to which a student should be stretched by an exercise. “for the first time” gives the impression that we should “go easy” on them which would not fit with the intention that the student should be a seasoned coder in another language.

We discuss fluency but not the extent to which a language track is intended to be exhaustive or comprehensive. Incidentally I think you can be fluent in the core of the language without knowing sone quite large areas).

I know I’m not the only one to have struggled slightly with Fluency vs. Proficiency. I think “fluency” is a near-perfect term hinting at ideas idiomatic usage, craftsmanship etc. it’s better than “mastery” which is the other term that comes to mind. “Proficiency” doesn’t work as well. I would be happy to be called proficient in any endeavour but I know what you mean. I work sporadically on a massive PHP code base but would not consider putting PHP on my CV. I think PHP is a fine language and environment and one of its strength is its accessibility to the casual coder but I have no incentive to learn it to a degree of fluency - I can hack it. I thought of “adequacy” or “effectiveness” but I don’t think that they cut it. Perhaps don’t try to encapsulate the point in a single term. Exercism's point is that software engineering goes far beyond effectively communicating with a machine. There is a difference between the level of knowledge and skill that might enable a power user such as a quant analyst or a data scientist to make a computer sing and what is required of a good software developer.

Craftsmanship

One aspect of “fluency”, particularly in an OO language like C# or Java, is principle based programming, some aspects of craftsmanship, good practice, etc. This is partly because the languages are busy evolving in a functional direction which is at odds with their OO roots. It would be good to have Exercism acknowledge a trade-off between illustrating language and library features and the application of good practice even if it’s to say language tracks should make up their own minds on this. In C# we sometimes decide to avoid bad practice (or jump through hoops to avoid it) and sometimes (usually in less severe cases) allow it.

Meta

I think Visiony / Mission Statementy type documentation as above can be useful. They may not get widely read but when propagating culture to contributors by way of code review it is essential to have anchors of authority from which to kick off discussions about a particular approach. These cascade into style guides and documentation guides but a layer above that is helpful where subtleties of interpretation are involved.

Core team members have a “natural” authority which derives from having developed the ideas in the first place and being so invested in the project. Casual players need to be able to appeal to an agreed authority.