Hello again. I had to focus on few other things outside of Exercism over the last week, but whenever I had a moment I kept looking at the Lasagna exercises to build a better picture of the “problem”. I have now done this exercise in 10 languages on 10 tracks including Python, Ruby and JavaScrip as all were brought as examples above.
I now know what I like and what I don’t, exactly, but that’s just my opinion. I’d love to be able to do some “proper” user research into this, but for now here is what I think:
The Lasagna exercise is a very special case. In all tracks I have explored it comes right after the Hello World, and so, it is the first exercise where we have do anything more than change Goodbye, Mars! to Hello, World!. It is where we first actively engage with a new language on Exercism. We come to this point with varying levels of knowledge of the language and experience of programming, but with a shared desire (in my opinion) to try something new. And so, I think the exercise should be a small step in complexity and effort (reading can be an effort) to get to that dopamine hit - yes, I’ve done it! And it works! And I have learnt something new… what’s next?
Is reading difficult? Does it have to be? I argued above how we could change wording to make it more inclusive and perhaps appealing to wider range of experience. As it happened since I wrote it I ended up in a meeting of British Computer Society Digital Divide Specialist Group. It reminded me that there is so much more to it and to inclusivity in general. So much discussion about programming is in English, but for so many of us English is not our first language. The accidental complexity quickly piles on top of the essential complexity of the exercise.
And I know we can get through it. We are all here, discussing the finer details. But there is, in my opinion, great value of lowering the barrier of entry to allow others, with different backgrounds, with different personal circumstances to learn, to contribute to software.
We should also remember that learning a new programming language is to some extent similar to learning foreign languages. Learning 5th, 10th is easy. But the second? Those who tried learning a second language as adults will know how difficult it is to figure out what’s important and what is just “nice to have” and how important it is to start using it rather than read about it.
OK, enough of the philosophy. What could we do to the Lasagna exercise in practice to make better act as the step after the Hello World?
- Reduce in code comments to bare minimum, to show how comments look like, to guide the implementation a little, but not to be a block of text with every possible feature of doc strings. Personally I find Elixir version of the exercise far less intimidating than
- Reduce the introduction text. Python version has almost 300 lines of text (with very good information). Ruby
only 20% of that with just under 60. I think there is value with basic information at this stage, but there is also value in getting people to do the exercise quickly and getting them to that feeling of “I can do it!”
Now, to the specific I promised to answer @SleeplessByte
You provided a relatively long list of “must know” things depending of where we come from. I think some of this information is already captured in the track info. Most languages have good Wikiipedia pages and a lot of resources online to which the introduction could link. But in the end I think it comes down how the information is presented and what is in the focus. Currently the Python track reads in a very encyclopaedic way. This allows a knowledgable person learn more and gather more information, but it doesn’t necessary allow for quick progress. I would suggest more outcome based description of the same topics.
Examples - the introduction
Python is a dynamic and strongly typed object-oriented programming language. It employs both duck typing and gradual typing, via type hints. Imperative, declarative (e.g., functional), and object-oriented programming styles are all supported, but internally everything in Python is an object.
This concept introduces 4 major Python language features: Name Assignment (variables and constants), Functions (and the return keyword), Comments, and Docstrings.
I would change this to
In this exercise you will explore 4 features of Python: name assignments of both variables and constants, functions with their input and returns, comments and docstring.
Then in the section about assignments and re-assignments we have
In Python, there are no keywords to define variables or constants. Both are names that help programmers reference values (objects) in a program and are written differently only by convention. On Exercism, variables are always written in snake_case, and constants in SCREAMING_SNAKE_CASE.
Names are assigned to values using =, or the assignment operator (<name> = <value>). A name (variable or constant) can be re-assigned over its lifetime to different values/object types.
I would try something like this instead
In Python we can reference values with programmer defined names (variables or constants).
To define a variable you may write number_of_chefs = 5 where number_of_chefs is the variable name in snake_case, = is the assignment operator and 5 is the value. From now one number_of_chefs refers to value 5 until you change it by another assignment, for example number_of_chefs = 6.
Constants, in Python, are variables which are not meant to be re-assigned with a different value and so always should have the same constant value. To show that intent we write them in SCREAMING_SNAKE_CASE.
If you tried some other languages before you might notice that in Python you don’t have to declare variable types or use any keywords to declare variables.
I think both variants of the text convey the same message but the second one might be more actionable and more approachable.
And maybe this exercise is special, as it’s the first one and so the one that most people will need a good onramp via, and it’s also the one that gets the most feedback as a result.
