Open lucaferranti opened 3 years ago
Thank you for taking the time to take a look at this lesson.
I share your concerns and for 1. I think it will get a lot better if we add a picture of a trebuchet (cf. #10).
But for complete beginners this lesson is probably a bit much. I planned it for people who have some experience to programming in another language and I am all for renaming the repository (e.g. there is a shell-novice
and a shell-expert
lesson IIRC).
I am also in for helping in making a second lesson. Someone in @Jdbeck66 suggested in #3 to build that similar to python-novice-inflammation
which wouldn't hurt I guess.
maybe this could be called julia-intermediate
? I think this lesson is about at the same level of this talk from last year juliacon.
Not qualified to comment on the specific of Julia but I can clarify as @lucaferranti requested, and perhaps provide some additional guidance.
We certainly allow for multiple lessons that teach with the same tools e.g. programming language. Indeed, another lesson repository for a Julia-based lesson already exists in the Incubator: https://github.com/carpentries-incubator/julia-data-workflow. I encourage community members to collaborate wherever there is a large overlap between the visions of individual members for the lesson they want to develop. But there will be times when, for the benefit of the lesson(s), it will make more sense for people to work on separate projects, e.g. see this early issue thread where we discussed the creation of two separate lessons for Julia, which led to the creation of that second repository I linked to above.
While it is true that the choice of a data set/example used in the lesson is likely to be inaccessible to some audiences, it is very difficult to find good examples that will be meaningful and feel authentic to all people. There is a conflict in lesson design between choosing authentic tasks to use when teaching (which increases the learners' motivation to learn the skills being taught) and demotivating them by using examples that are not relevant to their work/assuming prerequisite knowledge that they do not have.
Consider, for example, Software Carpentry's Programming with Python lesson, which uses an example data set of measurements of arthritis inflammation. There are plenty of audiences who we could expect to want/need to learn the skills taught in that lesson who are not familiar with/interested in working with data like this. As such, you are absolutely right to frame this as a question of target audience. What I would like to encourage you to do is to try to identify a (realistic and specific) audience for your lesson and design/write the lesson for them, rather than trying to make a lesson that is "all things to all people."
Lesson looks great. It seems it would fit well into Software carpentry. The novice lessons typically assume no programming experience. The current lesson is great for someone who has some programming experience and wants to learn Julia. It will be really great for those in scientific computing who have used Python/Matlab/Octave/Scilab and want to use Julia - this is likely the current largest audience for Julia, though Julia is also great for data science.
The programming with R and Python lessons in software carpentry are skewed towards people doing programming for data analysis and have much content overlap with those in data carpentry. This is likely the largest audience for those doing carpentry workshops who are likely not going to be full time programmers, but using programs to accomplish some task.
This lesson looks great, it has a lot of interesting content and funny applications, I am just wondering: what kind of audience is it targeting? From the name, "julia-novice" I am assuming the lesson targets novices, i.e. people who have zero to little coding experience before, in which case I am a little afraid the lessons might be ovewhelming, particularly:
2.I think some lessons digress from the lessons topic, for example
In the same lesson you also introduce the concept of gradient, but I think concepts from calculus are a little too much for someone who is probably supposed to write their first loop. Also, what if you have people from digital humanities (e.g. human-computer interaction background, with a focus on the psychology side)? I think having a physics based example is not inclusive for them.
I fully understand that it's tempting to get excited and start adding more content, especially when you teach something you are truly interested in. I do this mistake way too often in my own teaching 😄
If the course is targeting programming novices, then I think it should be recalibrated and I will be happy to open as many PRs as needed to achieve this, we can also get on a call to plan it, if you think that's more productive than github asynchronous workflow (personally, I do).
If the course targets people who have previous programming experience and come from a quantitative background, than my issue is fairly useless and I apologize for the noise.
Finally, I am not sure about carpentries policy (cc @tobyhodges ), but I would guess there's nothing against having more lessons on the same programming language? Maybe julia-novice could target people new to programming coming from whatever background and in addition to that we could have a "julia for scientific computing" (or whatever) targeting people who already have some programming experience and work in a quantitative field, for which the current structure of this lesson would then be very good?