[Roadmap] Who is the student? or: Don't Repeat Instruction

[coriolinus]

This is feedback on the v3 roadmap (#690).

---

One question that comes up quite a lot as the other Rust maintainers and I consider potential concepts is whether the target student is learning the language, or learning to program from scratch. The former group can safely be assumed to know what a conditional is, what variable assignment is, common numeric primitives, etc; at most, they need a very brief introduction to the syntax used, and can move directly on. The latter group needs much more guidance through all these concepts.

Concepts form a DAG, not a tree. However, we've all been thinking so far as though it's a very tree-like DAG, with a single root node. This has led to some discussion in the past about whether a "fundamentals" metaconcept is desirable. What if we allowed more than one root? The most basic UX for this would be students who start a track could have a radio box to select between "I have programmed before" and "I am brand new to programming"; the users who choose the first option start at a concept root which gives a faster-paced introduction to the track's syntax.

It just feels tedious to force everyone to learn, once again, what is a function, what is a struct, what is a test suite, what is an integer, what is a float, what is a conditional, what is a for loop, and so on. The more we can abbreviate the concepts which are common across languages, the lower the barrier to entry for people who are not brand-new to programming.

[SleeplessByte]

After reading your idea a few times, I do understand that you want to "make it so that students don't go through the same thing over and over", and I would ❤️ it if we could come up with something that solved that. I'm not against solving that in principle.

---

Exercism caters to current programmers. Not brand new users. It hasn't during v2 and it won't during v3. We often refer people to freecodecamp and other resources.

the target student is learning the language, [...] can safely be assumed to know what a conditional is, what variable assignment is, common numeric primitives, etc; at most, they need a very brief introduction to the syntax used, and can move directly on.

This assumption feels to me both privileged and incorrect. Apart from syntax and its usage being vastly different across various programming languages, some don't exist even in "popular" languages. Do I think we should go into detail on explaining computer science subjects? Absolutely not. This is why there is a distinction between "concept" and "Concept":

• Don't explain what a string is, explain how you use it.
• How to use strings might be considered common knowledge, but the fact that rust has both a mutable an immutable variant is already different than say javascript. Ruby for example, based on the runtime, has different properties for strings. For example, in certain versions of mri, they are "copy-on-write", and only heap allocated if they go over 23 characters. C doesn't even have strings at all!
• Various languages only have one or two numeric primitives (javascript), or no primitive at all (ruby). Yeah it might be obvious that they exist coming from c# or java, but not so much coming from any other dynamically typed programming language, among others.

In the examples above, I'm not talking about "what is a string, what is a number", I'm pointing out that they are different across languages and therefore these differences, when they are important, should always be taught. The v2 rust track for example is completely inaccessible for people who don't go out of there way to read other resources and don't come from a low-level language background.

Concepts form a DAG, not a tree. However, we've all been thinking so far as though it's a very tree-like DAG, with a single root node. This has led to some discussion in the past about whether a "fundamentals" metaconcept is desirable. start at a concept root which gives a faster-paced introduction to the track's syntax.

There is no such thing as a fundamental metaconcept, because we will never agree what is considered a fundamental. That said, no one has said that there should be a single "concept" each student starts on.

It just feels tedious to force everyone to learn, once again, what is a function, what is a struct, what is a test suite, what is an integer, what is a float, what is a conditional, what is a for loop, and so on. The more we can abbreviate the concepts which are common across languages, the lower the barrier to entry for people who are not brand-new to programming.

I want to focus on what seems to be the goal of this idea:

the lower the barrier to entry for people who are not brand-new to programming.

Doing the work is apparently considered a high barrier of entry. Well. I quit the rust track specifically because the barrier of entry is too high. I would have loved if both exercises and mentors took more time explaining things incrementally. bob is a ridiculously hard exercises to do idiomatically but for some reason it's considered "oh just fundamentals"?

---

Concept exercises should be trivial to complete. If they are trivial to complete there shouldn't be too much "barrier" to entry. In fact, you'll probably be able to quickly do them in the web interface, and then you get to the good stuff.

If anything what we could consider is unlocking concepts across tracks. It's something I would personally be okay with. It also removes the determination of "metaconcepts", and it removes the privilege of thinking that you know what other people should know. It's more work, but it's going to give us a whole lot less false positives. However, it might surprise you how often you can't mark something in another track. TypeScript's argument types can only cross of those languages that use the same syntax and rules. Kotlin's return types are probably the same as TypeScripts, so that would be a candidate. But Ruby conditionals aren't the same as JavaScript's.

[tehsphinx]

Even if someone knows about strings from x different languages and they start learning Go, it would be good to get to know about the strings package with all the string related functions. Or the fmt package with the string formatting related functions.

[iHiD]

There's a few different things in your post. I'll try and pick them out.

whether the target student is learning the language, or learning to program from scratch.

We are targeting people who are learning the language, and have some (3months?) programming experience in any other language we support. At some point, we will add support for beginners but this will be a separate system, which doesn't come into consideration for v3 tracks.

Concepts form a DAG, not a tree. However, we've all been thinking so far as though it's a very tree-like DAG, with a single root node.

I don't know what a DAG is, but from googling I'm presuming you mean it's a Directed Acyclic Graph, which Wikipedia tells me is "a topological ordering of a directed acyclic graph: every edge goes from earlier in the ordering (upper left) to later in the ordering (lower right). A directed graph is acyclic if and only if it has a topological ordering." and looks like this:

Presuming that's what you mean (and I'll delete this bit if not) then that is not how concepts will work. So let me clarify a bit more, with a few points, and you can tell me if there is a better word to describe this.

• There is no starting exercise. There will be linking me multiple first exercises someone can take. You can see this already at C#'s track.
• Concepts do not converge. You would be able to unlock some of the most advanced, complex Practices exercises without every having do have done any exercises on strings.
• Some early concepts will be commonly used (e.g. loops, numbers, strings, conditionals), but they don't form a hierarchy where they all have to be learnt to progress. There are not "layers".
• I have described this as multiple intertwining trees. That might be a bad way of saying it, but visually that's how it feels to me. A few original stating points that lead to a large amount of different end points.

It just feels tedious to force everyone to learn, once again, what is a function, what is a struct, what is a test suite, what is an integer, what is a float, what is a conditional, what is a for loop, and so on. The more we can abbreviate the concepts which are common across languages, the lower the barrier to entry for people who are not brand-new to programming.

No exercise should teach what a number is, or what a string is. You'll see from the C# examples (Numbers and Strings) that we are defining what those concept are in that language. In C# a string is a sequence of Unicode characters, in C it would be an array of chars, in Ruby, it is an object. SleeplessByte explains this well above so I won't repeat it. Similarly the exercises themselves should demonstrate how to create, use and manipulate strings in a language. And that's really different. No-one coming to Ruby from most other languages looks for ends_with? as the way to look at the last character, or delete_suffix! to remove the ending of a string. In fact, most developers have no idea that those methods exist and that's the key thing. You don't know what you don't know.

I don't know Rust, but the Rust docs tell me that in Rust: "a String is made up of three components: a pointer to some bytes, a length, and a capacity. The pointer points to an internal buffer String uses to store its data. The length is the number of bytes currently stored in the buffer, and the capacity is the size of the buffer in bytes. As such, the length will always be less than or equal to the capacity. This buffer is always stored on the heap. You can look at these with the as_ptr, len, and capacity methods". It also tells me some stuff about dereferencing strings: "This will create a &str from the String and pass it in. This conversion is very inexpensive, and so generally, functions will accept &strs as arguments unless they need a String for some specific reason.". I don't understand what any of that means.

So when I do the Rust track, I'm looking for one or more exercises that are going to cement all this in my mind in a meaningful way. But I don't want to have to go through those exercises before I can play around with the parallelisation of Pythag Triplets. They are separate concepts, separate "trees". Sure, a future Concept Exercise might rely on both strings and numbers, and then the track-designer is choosing to connect those trees up later, but that's not something we're encouraging. We'd much rather have a Practice Exercise rely on both, and become unlocked when both sets of concepts are learnt, but not stop someone who wants to just do scientific programming in Rust not have to learn a load about string processing.

---

Does that clear things up?

[tehsphinx]

@iHiD: To make this more concrete an example of current Go "multi-tree": https://github.com/exercism/v3/issues/212 (see picture)

Numbers is currently the only starting point.

Conditionals is based on numbers because we will use numbers to compare as conditions. Would you say that numbers is a prerequisite?

Or iteration is doing some for loops (for i:=0; i <= n; i++) which of course has numbers involved. Would that be dependant on numbers?

Or bytes and runes are basically numbers (uint8 and int32). Should this depend on numbers?

Or functions will deal with input parameters, multiple return values etc. but will use numbers to show this. Should this be dependant on numbers?

Because if we go this way, in the end there will be only a few fundamental concepts that represent entry points and all the rest is depending on these fundamentals directly or through other concept exercises.

[iHiD]

@tehsphinx So you might end up with a single starting node, but then a dozen layer-2 nodes, each with spawn their own trees, many (most?) of which will overlap later, but some (e.g. more advanced number exercises) which may never be a prerequiste of another exercise outside of that subtree.

That said, I'm not sure what the problem we're trying to solve here is. I don't think it matters whether we have a DAG (which I probably don't understand the definition of), a tree, a load of subtrees, etc. I'm not sure how it affects what we're doing or changes how maintainers make the first Concept Exercises. What am I missing?

[tehsphinx]

@iHiD sounds good to me. From #695 (comment) I had the impression that I am creating too many dependencies. But if that is not the case, I'm all good 😄

I think the main point of this issue was to discuss a potential later entry point for advanced users. From my point of view most were not in favour. I think this is something we could discuss again once v3 is launched and we get complaints about too many simple exercises at the beginning.

[iHiD]

@coriolinus and others. Is there anything else to discuss here? Or do you feel like the question(s) have been answered?

[workingjubilee]

I have described this as multiple intertwining trees. That might be a bad way of saying it, but visually that's how it feels to me. A few original stating points that lead to a large amount of different end points.

What you are thinking of is in fact a directed acyclic graph. The DAG you looked at was just one DAG, it was not an actually exhaustive depiction of one. Let me explain: since trees in computing are generally directed (technically not a requirement of trees, merely true in practice), the trees we work with are generally DAGs, but the definition of a DAG is less restrictive, as it only implies

1. direction (so child nodes do not refer to their parent nodes)
2. no cycles (there are no loops, you never return to a previous node)
3. it is a graph (which trees are)

If you have two trees, let's call them Blue and Red, they cannot be a "tree" taken collectively because they violate the requirement of a single root node (they would be a forest!). However, trees in the computer science context generally retain direction and are acyclic. Assuming that, then if tthese two trees eventually have a node that they meet at, which we call Purple, they still constitute a single graph. If they are otherwise still trees, then they are a multitree.

Based on what you have said this is what you are describing but there has been a fair amount of confusion regardless. It does seem more confusing than illuminating to say there are not "layers" when a single exercise that depends on having another exercise completed, and cannot itself be picked as a starting point, constitutes a second layer.

[iHiD]

Assuming that, then if these two trees eventually have a node that they meet at, which we call Purple, they still constitute a single graph.

They don't meet. Some concepts might have a single dependency (which might be on "layer one") and then have no other dependencies. Some concepts might have 30 dependencies. So they are a multitree?

So the following might be true. @workingjubilee Maybe you could draw it for me using the software you've drawn above, and we can then have a clear scenario that we can put whatever name/description to that people find helpful?

a->b->c
d->e
a->f->g
b+f->h
c+f->i
g+i->j
k->l
k->m
n
g+o->p

As I've said previously, I'm still not sure what the purpose of this discussion is in terms of how any of this affects anything we're doing. But if it's helpful for people then I don't mind continuing :)

[workingjubilee]

Oh, I pulled that off Wikipedia honestly, but I'll be happy to slap together a quick sketch in Figma later ~today.

I think this is mostly a quest for conceptual clarity that will help actually implementing the goal, borne out of, presumably, a desire to not accidentally reimplement the issues of v2, namely "all the language self-study courses are the same even though they are trying to teach very different subjects".

[iHiD]

Oh, I pulled that off Wikipedia honestly, but I'll be happy to slap together a quick sketch in Figma later ~today.

Thank you - that would be very helpful :)

I think this is mostly a quest for conceptual clarity that will help actually implementing the goal, borne out of, presumably, a desire to not accidentally reimplement the issues of v2, namely "all the language self-study courses are the same even though they are trying to teach very different subjects".

Thanks for clarifying :)

The problem with V2 was there was no design though - we just reused V1 exercises, which we by nature ~identical across tracks. So I don't think problem will reoccur. I also don't believe trying to map out a large concept-tree will be a good method for achieving this, and the tracks that are making the most forward progress so far aren't trying to take that approach - they're just making exercises for the concepts and then seeing how they fit together, which is working well

[workingjubilee]

Ehhh, I think there's a lot of noise in track progress based on community engagement to rate much based on track approaches. I don't think the relative quietude of the x86-64 Assembly track is based on an insufficiently freewheeling approach. ^_^

I appreciate that you are trying to say that there was no conscious choice in the design of v2 by saying "there was no design" but that effectively means that it did have a design, that was implicit rather than explicit, based on mimicry and the natural self-reinforcing tendencies of systems. If we cannot introspect a process we cannot verify that it is not going to generate the same results without just colliding headfirst. I don't think any such conversation should stop anyone, mind, just not all human thought cycles are fungible and so there is some spare time for reflection to allocate.

Here is an illustration of the relationship of the multitree and forest you described:

This is what you intended, yes?

[iHiD]

@workingjubilee Great, thanks. So yes. That's what I imagine topics will look like on V3. So is that a DAG and is there a "correct" way of describing it that makes sense to people with more mathematical language/knowledge than me? :)

[coriolinus]

is that a DAG

Yes!

is there a "correct" way of describing it

I'd go with "DAG", but clearly that wasn't sufficient.

---

The question I wanted to ask, at the topic head, was this. Let's use the DAG above for illustrative purposes. If a, f, and g represent concepts like "conditionals", "functions", "integers"--stuff that broadly are similar across languages--and p represents a genuinely language-specific concept. Is there a reason not to give users the option to start at o instead of a?

[iHiD]

Is there a reason not to give users the option to start at o instead of a?

Yes, because although I understand functions and conditionals, I have no idea to use functionals or conditionals in Rust, so would need to go from a. But if I did know those in Rust but wanted to jump forward, the exercises should be designed only take 5mins each and be useful as a refresher, so it won't be annoying to do them.

The only way that works is if every exercise is optional and users can just pick and choose what they want. Because we have no way of knowing what someone's experience in Rust is.

[iHiD]

To refer back to what I said earlier in this thread as an example. I know strings. I've been using strings for 25yrs.

How Rust docs define strings and how to work with them does not feel familiar or comfortable to me:

a String is made up of three components: a pointer to some bytes, a length, and a capacity. The pointer points to an internal buffer String uses to store its data. The length is the number of bytes currently stored in the buffer, and the capacity is the size of the buffer in bytes. As such, the length will always be less than or equal to the capacity. This buffer is always stored on the heap. You can look at these with the as_ptr, len, and capacity methods". It also tells me some stuff about dereferencing strings: "This will create a &str from the String and pass it in. This conversion is very inexpensive, and so generally, functions will accept &strs as arguments unless they need a String for some specific reason.

So I need to do an exercise on Strings for Rust. Even though I have used strings in numerous over languages over nearly 3 decades.

[workingjubilee]

Yep, just to reaffirm and conclude the graph theory bit: that is in fact a directed acyclic graph or "DAG". It is directed because the arrows have a specific direction associated with them. It is acyclic because no node points back to its parent or any parent, as you don't learn a lesson, then learn the second lesson, then go back to the parent lesson to relearn it. It is a graph because it is in fact a collection of vertexes (or nodes) and edges (here, arrows).

Because {a, o} have their child nodes join into a single graph, they are also a "multitree".
Collectively, the entire set of all the root nodes can be called a "forest", because they do not all join together in a single graph, but each can be considered a (multi)tree, even node n.

Although it is a forest, arguably there is a root node which is "the language itself".

So I think here the kibitzing and fiddling with graphs has led me to a bit of a realization, which is that this graph itself could be considered a subgraph of programming itself, which as mentioned is above and beyond the scope of Exercism. However, in this case, while Exercism is a DAG internally, it might be easiest to reinforce that programming itself is out of scope by collecting and pointing to useful generic CS resources, ideally the most digestible, that multiple tracks can refer to. Not all tracks will want to use the same ones and that's fine, but tracks will definitely feel some pressure to introduce CS fundamentals as well as introduce the language's specific concepts and syntax, especially the ones that are more "close to the metal" like C, Rust, and Assembly, or are theory-heavy like Haskell, and by providing a stepping-off point it can minimize the felt task and keep tracks more focused on introducing the language in question.

[iHiD]

@workingjubilee Thanks for the extra info :)

it might be easiest to reinforce that programming itself is out of scope by collecting and pointing to useful generic CS resources, ideally the most digestible, that multiple tracks can refer to. Not all tracks will want to use the same ones and that's fine, but tracks will definitely feel some pressure to introduce CS fundamental

Yep! That's exactly the aim of the reference bit of this repo. Additions of good resources would be super welcome :)

[workingjubilee]

Hmm... I will have to think about that.

For now, I will note I have really enjoyed Vaidehi Joshi's writing on a lot of CS concepts, as she makes them very approachable, and hey, she even has an article on DAGs. Though apparently she would disagree that learning is non-cyclic!

[ghost]

Summarizing salient points of the thread to reinforce my understanding of this discussion.

• A student can start at any point within a track. By keeping Exercism Concept exercises succinct, the annoyance caused by 5min * n exercises should be minimal.
• We can use the term DAG to describe Exercism Concepts. It is a tool for maintainers and students and contributors need not worry about it.
• Using the term in the Rust track helps us maintainers discuss the big picture of how everything fits together. But we should not try to do this in advance of creating concept issues and exercises because tracks that have progressed most have first established concept issues and implemented exercises.
• Exercism Concepts contextualize learning for a given programming language. @iHiD's example of Rust's documentation for String exemplifies this point. That documentation, written for Rust programmers, has a different goal. Our goal will be to make learning about String comfortable and empowering for non-Rust programmers. Whilst growing them into a Rust programmer 😄.
• the flexible nature of tracks equips students to self-direct their learning. Such self-direction provides the student with a positive experience while reducing the workload of track maintainers.

I believe the main question has been answered and so we can close the issue.