Guys, I’m in the process of delving into promises, and I really think the intro to promises should be broken down into simpler parts. I find this exercise too difficult to understand, and I don’t think it’s me. There should be some simpler exercises before this one.
I’ll make some suggestions based on what I’ve understood from multiple sources so far; I may be wrong.
Maybe start with an exercise that introduces async/await (which are not even mentioned at the moment) because it’s an easy transition from synchronous programming, aiming to teach that everything that depends on a promise (and thus must be awaited) is also a promise (hence must also be awaited) so it’s only promises from that point onwards. This is the first new concept.
Then you can introduce promise chains using the “traditional” syntax, without the error handling, aiming to show how the above principle translates into the new paradigm: Everything that needs the result of a promise goes in the first part of the promise’s then method, which also returns a promise. That’s also not a trivial step. The chain should end with a simple operation like some_list.push(...) or console.log(...) to ground the new concept through familiar functionality.
Lastly, you can introduce the fact that a promise can be rejected. This concept should be introduced at a point where the student already understands what a promise chain is.
I mean, arrays are a much simpler concept, but in most learning tracks their various functionalities are introduced through multiple exercises. So, if the concept of arrays is worth breaking into parts, then the concept of promises definitely should be!
Firstly, although many tracks, including the JS track, have a learning syllabus, Exercism isn’t aimed as a learning resource for complete beginners so we tend to not fall into details. Also, unlike the concept of Arrays, Promises are unique to JS so it’s not as easy to convey what a promise is and how it works.
I had to refresh my memory of the Promises concept (I’m assuming you’ve read that and this is what you’re referencing) and I can’t say that I agree with all your points.
For example, to understand that async/await is pretty much just a simplification of the regular promise syntax, you should already be familiar and somewhat comfortable with Promises and rejecting/resolving a promise. Hence the concept explains this first and gives you lots of links to other, more detailed explanations.
It’s no good if we teach you that a tool exists and how to use it but we don’t explain how the tool works.
All that being said, I don’t want to discourage you from learning and trying to make things better, so if you think you have a suggestion for additional learning exercises about the Promise concept, we can discuss.
I had some idea about promises because I had used async/await in a programming game (Bitburner) a couple of years ago. It was through playing this game that I learned a bit of Javascript, but then I abandoned it. I thought I understood promises then, because I could get correct results, even if I was missing some functionalities. When I came here, I was thoroughly confused, and I only started making some progress when I went and looked at the code I had written back then.
I’d like to draw a parallel between using async/await in Javascript and using scanf() when first learning C. Usually, they teach you how to use scanf()before they tell you what a pointer is, even though you have to use pointers in the syntax of scanf(). This is because teaching you about pointers when you first start learning C, before you have even touched the keyboard, would be an unmanageable info-dump. It’s better to temporarily accept a strange syntax without explanation so you can get used to writing simple programs and familiarise yourself with the basic concepts involved.
You are right that, unlike arrays, promises are unique to Javascript; and that’s part of my point. Asynchronous programming, generally speaking, needn’t be complicated. For example, C++ also has a framework for asynchronous programming (future is somewhat similar to Javascript’s promise), but it’s significantly more straightforward to use. It’s promises in particular that seem complicated (and I’m still unsure if this complexity is a tradeoff for some advantage).
Tell you what… I’m going to be cheeky and claim that no one has found this exercise helpful. If even one person posts in this thread saying that they succesfully learned about promises from this exercise, before getting relevant mentoring, I’ll admit I’m wrong.
Like I said, Exercism as a platform isn’t meant for beginners or ‘learning to code’. It’s much more about learning the specifics of a certain language, solving practical exercises and getting mentoring when you need it. For beginner friendly way to learn some programming (and JS) might i suggest Jiki which is a platform much like this one, made by the same people, but much easier and with lot’s of hand holding.
I don’t want to be confrontational with anyone, so I really don’t care to prove you wrong. The important part is, that you found the exercise unhelpful and you posted about it here, so we can talk about that. Which part of the concept was unclear? Did you read the whole thing? Did you explore any of the additional resources provided? If yes to all, how do you think it can be improved?
I’m not saying that the track should be geared towards beginners in programming. But since it’s a learning track, it’s meant to be for beginners in Javascript. Everything else except promises was introduced adequately, with an explanation and fitting exercises. Then with this concept there is this sharp spike in difficulty. The pacing here needs to slow down to match the rest of the track.
I made a somewhat provocatory statement to argue that the problem is the concept exercise, not me. I’m not new to programming, I didn’t have any difficulty with the rest of the track, I didn’t skip any text in the intro to promises, and I’ve read the tutorial on MDN (which was indeed more helpful). I’m still not sure how to use promises. So I double-dare anyone to come forward and say “No, the exercise is fine, I learned promises from it, you’re just stupid”. My point being, it’s not fine. It’s too loaded, without simple enough examples, and tests too many things at once so I don’t even know which part I got wrong.
Incidentally, note that the MDN tutorial introduces rejection only after explaining promise chains, separating the concept into two smaller chunks. This really did help.
Perhaps I’ll start a please-help-me-debug-type thread where we can talk about my code specifically and where it likely goes wrong (I’m going to have to take another look) and perhaps you or others can clarify things for me and I can start getting results. But even if I personally get unstuck, this exercise is still an inadequate intro to promises, and future learners will encounter the same problem.
Then again, maybe I can be of more help here once I’ve properly understood this concept and revisit this thread. I guess I’ll go look for something like “promises for dummies”
Dude, no one is saying you’re stupid or inadequately prepared and no one wants that type of discussion, so let’s drop it. We can focus on more productive talks, like discussing if the exercise needs correction, or the concept or potentially both/none?
You said that you’ve read the concept and various other tutorials, yet you still find it difficult. What part was difficult? Why? Did you request mentoring on it? If you haven’t, then why not?
Because I’m not meant to request mentoring before I’ve found a correct solution to the exercise.
BTW I just discovered this article and the first thing he mentions is the Event Loop. This is a more sensible order of things, starting with a key characteristic of Javascript (which I feel like I should have known from the start). It’s always useful to know the mechanisms by which processes communicate.
There currently is a gap that’s hard to bridge between Promise and the rest of the syllabus
There is no doubt that experienced programmers have a hard time understanding Promises (including me, having spent a long time writing event-based JavaScript programs beforePromise / async / await was introduced to the language)
The question about “What would fit in the gap to help bridging it” is not yet answered clear enough to actually go forward with changes
So I’d start by suggesting a high-level walk-through from “single code path execution” to “Promise” before making concrete concept or exercise suggestions:
Introduce JavaScripts single-threaded Event Loop model using event-based coupling of students code to test code. This re-uses the understanding of “writing code here that is executed somewhere else” from Callback, Closures and Functions. It puts all this into a new asynchronous execution model using Events as invocation triggers, allowing us to shuffle Event triggering to experience real unpredictable asynchronous execution
Use the Event Loop knowledge about async execution to introduce async / await as a means of “trigger some remote operation while doing my own business until I need the result”. This closes the current gap that triggering Events does not give me a result of the execution
Build on top of that a positive execution chain using Promise (no rejection yet). This separates out the “what to do with a result can be triggered by the event of getting the result” part of Promise from the whole big chunk
Add rejections and catch-all pathes to the whole picture
Would that ease the learning? Should there be more steps? Are there gaps in the walk-through?
(No, I have no concrete ideas for concepts or exercises)
