I'm going to use Kotlin in a new Intro Programming...
# random
e
I'm going to use Kotlin in a new Intro Programming course with 100+ students this fall at Mills College in Northeastern. Any suggestions of fun libraries that are well-maintained and well-documented to use in assignments? One I'm looking at is #tornadofx. I think Android development would be too ambitious.
o
If you want to cover UI development, I‘d recommend Compose Desktop, once you familiarize yourself with it. A Singleton consisting of
MutableState
properties as a source of truth would ease understanding. That combination could provide a good basis for getting a glimpse on how attractive UIs are created today.
🙏 1
🙏🏾 1
4
y
I would say though to maybe start with simple console apps just so that the compose stuff doesn't distract. I'd say that maybe start for the first couple of lessons with console, then gradually introduce some simple compose and provide the students with the UI code (and maybe provide some resources so the ambitious ones can explore). Then later on, once they have a good programming foundation, go deep into compose and how it all works (It pains me that I'm writing this because personally I dislike when courses give you some code without deep diving into how it all works, but for the average student they won't be ready to explore that deeply. But please, do provide some initial resources for the really-curious students so that they can challenge themselves)
🙏 1
o
That's what I was initially thinking: Stay with the console to keep things easy. On the other hand, I guess folks would be much better motivated once they discover, hey, I can build stuff I'm experiencing every day on my phone! UIs have generally been so messy that it's almost unbearable. 30 years of failed abstractions. Everyone understands view and model, but no one ever made sense of controllers and other in-between stuff going by different names. And then there's endless wiring and re-wiring of components until you have finally succeeded to entangle yourself. Now there's Compose, which unloads much of the messy stuff from your mental model. It admittedly has lots of black magic behind the scenes, so understanding its complete mechanics with a beginner's background is too much to ask for. But you can provide a good setup (single state model, primary window, Material theme, not forgetting a proper Gradle configuration) to start with. Then you'd introduce a minimal set of Compose components, hopefully enabling an initial feeling of empowerment. After that, you might add selective animations for some Wow! effects. A curated list of which parts of the Compose documentation to look into and what to ignore might be useful. For example I'd favor skipping everything performance-related (recomposition, etc.).
e
Thank you. I'll definitely start with console apps, as @Youssef Shoaib [MOD] suggests. Actually, I'm going to start with REPL apps.
A colleague suggested an approach like @Oliver.O’s where I would create the GUI for Wordle, and students might implement the model. There are some Kotlin implementations of Wordle on GitHub that I could start from, although I haven't found any yet that seem very clean. One of the purposes of the class is to teach programming paradigms. (It's usually taught in the Racket dialect of Scheme.) Having a declarative GUI would support that. Are there any #compose-desktop tutorials, books, or documents that you'd recommend? I haven't used Compose (on either Android or the desktop). Maybe I should ask in that group.
o
There is Getting Started with Compose Multiplatform, which covers Compose for Desktop. From there, you'd pick the relevant parts of (Android's) Jetpack Compose documentation, in particular the chapters "Foundation" and "Design". While you'll be using Jetpack Compose components on Desktop, be sure to skip everything mobile, such as the older View system, Activities, Intents and such. Desktop-specific components are covered here. Good code examples are often hard to find. There is lots of over-engineering and many old paradigms slip into code supposedly written for modern ecosystems (a recent example on design patterns: https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1660305278067369). Hopefully, you won't need a super-sophisticated UI as the main focus is on general programming. Where the UI's purpose is to visualize and motivate, it should never become that complex to distract from the main goal.
🙏 1
e
Thanks so much, @Oliver.O! I found a snake game by @Arkadii Ivanov that I've been playing with and think I'll use.
🙂 2
o
Looked into it briefly. Seems like a viable option. One remark: If I am not mistaken, the game will replace the entire board (model) on each step, causing a recomposition of the entire tree of Composables. That's not necessarily a bad thing in an educational context where UI programming is not the focus. Personally, I'm always a bit wary of planting concepts in people's minds which might not be a good fit in production. But as long as you are mindful of the applicability limits, it may be entirely OK to ignore such concerns.
a
Compose should propagate diffs down the tree, comparing parts of the game's big state by equality. Only changed parts should be actually recomposed. Also recomposition doesn't imply re-rendering. Should be pretty efficient.
o
True, recomposition does not imply re-rendering. However, the entire tree does recompose: Compose cannot infer that the board's rows and colums haven't changed. I have checked this with
Modifier.recomposeHighlighter()
on
Row
, which will quickly color the entire board in yellow to red (source code). An alternative would be a
Board
comprising an array of cells, each cell having a mutable state, and then using a
Cell
Composable enclosing the different cell types. Only the mutable state on the cell level would then change, allowing Compose to skip everything but the
Cell
Composable. Again, it's not necessarily a problem in this case, but when introducing UI concepts or showing examples to newbies, I'd start with habits that avoid common problems. In this case, pushing state reads down the tree as far as possible (also recommended in Compose best practices). When to short-cut such practices would be the topic of a later lesson.
a
@Oliver.O I would disagree here. Having the main
Board
class at the very top and passing sub-parts down the tree aligns with the state hoisting principle and SSoT. The fact that in this particular case Compose cannot infer that some sub-parts have not changed is another concern. I believe this could be solved by using immutable persistent collections or maybe by using special Compose annotations. But unless the performance is affected, I would not over-engineer the code. Again, recomposing is usually fast and doesn't imply re-rendering. Also in the future, composition should run on a background thread, this should further improve the performance. Here is another example of having one single state object with lots of data. The performance is very good there as well. https://github.com/arkivanov/compose-3d
o
It's OK if we come to different conclusions. The alternative I suggested would also have an SSoT at the very top, it's just mutation that would happen at lower levels. I have used such a model for a maze-solving visualization, which seems simple enough and restricts recomposition to actual cell changes. I'm also not in favor of premature optimization and other over-engineering, I'm just arguing to choose a simple yet safe path for beginners as long as they are not familiar with details and trade-offs.
o
Kotlin with all it's flexibility, might not be the best language for an introductory course.
o
Given it's about an introductory class for university students, what's the reasoning behind this statement? Would you dispute that one could 1️⃣ start with simple, zero-overhead, procedural concepts, 2️⃣ cover data structures and algorithms, 3️⃣ introduce object-orientation, 4️⃣ touch functional programming with the help of standard library collections, 5️⃣ explore the declarative world of DSLs, 6️⃣ enter manageable concurrency with coroutines, and 7️⃣ master modern, reactive UI programming – all in an evolutionary fashion, staged over a series of classes? Which language would be easier to learn at the start, yet offer state-of-the-art productivity later on?
y
In fact, I think Kotlin's flexibility is very managed because it's contained in a small amount of features. Those features all interact with each other, obv, but knowing each individual one usually means that there interaction is easy to understand. Kotlin usually goes the route of finding a bigger and simpler umbrella feature to include instead of making a million tiny features, meaning that it's much easier to grasp how the language works.
3
o
At my uni we started with Assembly (with a very basic simulated instructionset), then moved to Pascal for structural programming, then Java for object orientated programming. Then Lisp and Prolog for AI/Functional programming. Kotlin will of course work, but exposing the students to different tools might be beneficial. If your only tool is a hammer, every problem is a n.... Besides all the syntactic sugar and general flexibility in Kotlin might be a problem from a teaching perspective, at least stick to some rules for the students.
o
Thanks for sharing your perspective! Of course, students would benefit from guardrails initially. I'd say a major strength of Kotlin in education is its support for many relevant paradigms in a cohesive ecosystem. So you have more time to learn the concepts than having to invest in the quirks of yet another language with similar capabilities, but a subtly different syntax and ecosystem. Plus, Kotlin's conciseness and lack of ceremony makes it a very productive tool. At some point, you might want to expose people to some purely functional language, so that they get the idea what it is like if you cannot break out. But for people to justify dedicating part of their lifetime, learning any other tool should provide significant extra value, not just more of the same.
👍 1
o
What kind of IDE are they going to use? And are the students on a engineering/computer science track?
e
The students will be using IntelliJ. We may also use repl.it for in-class activities. As mentioned, the main campus uses Racket (a dialect of Scheme) in the intro course for majors, Fundamentals of Computer Science. My new employers encouraged me to use Kotlin. I don't know all of their reasons, but I assume one is that it's closer to Java, which is used in the subsequent two courses. The class is more of a programming paradigms course than a Kotlin course. I prefer to teach programming paradigms at the upper-division, not in an intro course, but that is not up to me. I'll probably drop out of this thread, since I need to focus on the course, which starts in a few weeks, and I do not have the power to make major changes. I really appreciate being pointed to Compose for Desktop and having found @Arkadii Ivanov’s code, which looks like it will be great for our purposes.
👍 3