Question: is teaching Compose to first time progra...

# education

[Sam Stone]

Question: is teaching Compose to first time programmers a bad idea?

I am a big believer in goal-oriented learning - learning by making programs that are personally meaningful and provide value and benefit - as a way of maintaining motivation for first-time programmers. To that end, Compose mobile apps seems like an easy way to give learners a constant and palpable reminder of the benefit of their programming.

However, I am concerned that because there is so much "magic behind the scenes", they will not learn how to "do it themselves", and if their initial exposure to programming is Button("Hello") { println("Hello") }, imperative business logic will be unfamiliar and uncomfortable to them, and their mental model of how the compiler works will be skewed.

If this isn't a concern, what would be the best sequence to introduce imperative programming in? First go through the syntax, then Compose, or learn concepts as needed while building a real mobile app? Thoughts?

[Anastasia Birillo [JB]]

From my perspective, students like to learn programming on some exciting projects, even if they didn't implement the entire application from scratch. It seems to me that developing several applications with some pre-implemented components can work well here, and students only add part of the functionality while learning the basics. Then, after gaining enough experience in the language, they can move on to more complex topics in more independent projects. In addition, you can always provide students with ideas on how they can improve such an application on their own.

I can give my specific example in two courses - 1) https://plugins.jetbrains.com/plugin/21067-kotlin-onboarding-introduction and 2) https://plugins.jetbrains.com/plugin/21913-kotlin-onboarding-object-oriented-programming
In the first part, students have to implement six console applications from scratch, learn the basic concepts, create interactive applications, and write all the code themselves. The second part assumes knowledge of the concepts from the first part and contains four web projects in which the client is already implemented, as well as the client-server interaction, is implemented too, and students, step by step, add the necessary functionality to make the application work. I talked with students who have completed both parts, and they really like this project-based approach. They are happy with the problems with some results in the shape of completed apps. However, since the first part involves creating projects from scratch on simple topics, projects sometimes seem boring to implement. In the second part, there is no such problem. Various ideas are also added on how to change the project at the end of the implementation of each of them - changes that affect only the server logic and which the student can make without knowledge of the client-server architecture, but also offers options for how the game can be improved if the student is familiar with the client-server architecture. But many students noted that they were interested in taking this course precisely because they did not need to study everything at once but at the same time get a working application. That is why the next part that I am currently working on in this Kotlin Onboarding course is also built on exciting web projects. At the same time, we are giving this course along with the materials that were presented at the live stream on Wednesday, but we also already had classes on the advanced part of the course, where students had to implement various applications from scratch when they already had Kotlin experience with pre implemented ones, including applications with a client-server architecture

[Sam Stone]

@Anastasia Birillo [JB] amazing advice!

[Sebastian Aigner]

To add to Anastasia's reply – with Compose, you're definitely setting them up for success when it comes to real-life frontend development. While its obviously a bit of a different paradigm to traditional imperative or even functional development, the declarative paradigm is now found everywhere, whether it's React, SwiftUI, or Compose.
During workshops we've held, we usually provide some kind of skeleton application where learners fill in the parts of the business logic, while the parts that may be unfamiliar to them or not related to the subject currently discussed are encapsulated away. With such a clean separation (e.g. implementing the business logic of a view model), we found that even when learners aren't familiar with the UI toolkit, they can focus on the imperative parts – writing some imperative logic in a function body – while still seeing the code in the context of a "real" application.