I regard Scala’s collections as a jewel in the language.
Using Scala’s collections I am often able to simply and clearly express the intent of what I’m trying to achieve with only a few lines of code.
Most other imperative languages that I am familiar with have collection libraries that provide the tools necessary to write bespoke (and sometimes logically flawed) versions of an equivalent algorithm. I.e. the code expresses the “how” not the “intent”.
I don’t think there is any argument that Scratch and similar tools are ideal for starting kids out young and should be used for that purpose. The post I wrote has a fair bit of text dedicated to describing the context I’m arguing from, which is CS1 in college. I think that Scala is a great choice there. Between those, for courses in High School, I’m not certain what I think is the ideal. A streamlined Scala or Kotlin could be. I have significant fears of students picking up bad habits in dynamically typed languages like Python. JS is worse in many ways. Java using Greenfoot also works really well. There is a part of me that would love to have a tool like Greenfoot for Scala. Depending on the application, notebooks could also be useful. That reminds me that I really need to take some time to explore PolyNote over this coming break.
I’d argue against Scratch being ideal for young learners. My son hated his initial experience with it, the UI is bad from a Fitt’s law point of view. REPLs have a lot less extraneous BS to deal with; he was fine with python hooked up to minecraft, for instance. Now he uses repl.it in the browser to program javascript games. Both python and javascript are trash in a lot of ways, but at that age interest level beats any other considerations.
For highschool, there’s nothing that compares to How to Design Programs, the quality of that book beats any language considerations. Do I wish it existed in SML or a similar language? Yeah, but at the time the authors found the understandability of type errors in all available languages to be a hindrance. Maybe someone could recreate it in Elm at this point.
I completely agree that the non-advanced parts of Scala are a great choice as a first CS course in schools/college.
I also completely agree that learning a dynamically typed language, or a basic imperative language (such as C) can teach lots of bad habits. E.g. I think that C illustrates nearly all of the bad points of static typing (e.g. extra verbosity) and none of the benefits (e.g. program correctness and safety).
My person opinion is that folks like languages like C and Python because they perceive them as being simple languages, but at the cost that it is much harder to write correct program (particularly in C).
Scala is a different beast, I think that it has higher initial complexity, but is easier to write correct complex programs. The second issue that I have with Scala is that sometimes it can be hard to know how to model something (e.g. should I use sub-typing, or should I use type-classes). This seems to sometimes cause bikeshedding. The final issue I seem to have with Scala is that many of my colleagues just don’t want to learn it, but they all happily learn Python. If I have written a utility in Scala then they would rather rewrite it in Python than learn Scala!
When it comes to my children, I will probably mainly teach them Python, because that is what their course work will be, and that is what their peers will probably be learning. If they show an interest, then I will also try and illustrate why they might want to learn a language like Scala.
@koeninger, how old was your son when he started? I will agree that there isn’t a one size fits all introductory language for kids. My daughters enjoyed Scratch and Alice when they were 7-10.
What would you think about “How to Design Programs” in Scala? I could talk to the people involved with that effort and see if they would be open to it. It is definitely something that I would consider putting some time into writing.
As a language itself, Scratch is pretty crude. The attractive part is that it sits on top of a full-fledged game engine, moving around sprites, with collision detection, sound, sprite editor, etc.
Hooking Minecraft to Python sounds exciting - my son is totally into Minecraft. I wonder if you can hook up Mincraft to Java or Scala? After all, Minecraft is written in Java.
I learned some of my programming using Logo, moving the turtle around. Turtle graphics hooked to Scala REPL would be an awesome learning tool.
@MarkCLewis If you end up working on htdp in Scala I’d be happy to help.
Regarding age, he was younger than that. My first encounter with programming was logo in 1st grade.
I used to run an open source Minecraft Server (Spigot) on a Raspberry Pi 3 for my children. It worked fine (in 1GB), and IIRC is hackable.
There is already a Spigot Scala library, so I presume that some folks are writing Minecraft plugins in Scala …
FWIW, a lot of Minecraft plugins use Scala, though many only do so indirectly: the widespread Minecraft Forge plugin-managing-plugin has a Scala library dependency. (And a delimited continuations dependency (?!?!).)
So this indicates a pedogogical error, IMO, and that relates to all the comments about “Scala is too big/complicated”.
A good programming course, especially an introductory one, should be opinionated. It shouldn’t be “here’s a language, go do whatever you want” – it should provide strong guidance on good practice, and should teach a relatively specific style that works. It should teach certain features, but intentionally exclude many others.
That’s part of why I love Creative Scala: it’s aimed at absolute beginners, and it is extremely opinionated – it is teaching a very specific Scala style, in a way that is relatively easy to pick up and produces visible results quickly. The result is, from what I’ve seen, satisfying and pleasant for the beginning learner. (Aside from the fact that setup is often a hassle – see discussion upthread.)
More advanced engineers should go have fun exploring all the ins and outs, of course. But we’ve been discussing this topic for, what, north of ten years now, and always circle back to the fact that it is just plain dumb to try to learn or teach all of Scala at a shot. You should always focus on well-defined subsets, with clear and explicit goals of why you are including any given element in each subset. That’s as true for teaching as it is for training.
(None of this is peculiar to Scala, mind: it’s just plain good educational practice.)
Everyone seems to have forgotten the Odersky Levels, which came out of the original round of this debate, back on the original Scala mailing list. They’re pretty outdated at this point, and could use a heavy revamp – if nobody else does that soon, I might take a stab at a strawman for debate sometime…
Odersky’s Levels are not forgotten. I mentioned them in a podcast recording this morning with Lightbend that should be coming out soon. I point to one of the strengths of Scala as the fact that these levels are so separate and you can do so much in the first level without the others leaking in. That isn’t true in many other languages. Primitives in Java mean you can’t ignore the concept of boxing. Similarly, in C++ you can’t ignore the memory model. These are important concepts for students to come to understand eventually, but early on they only muddy the waters. My experience with Scala is that while there are many advanced features/concepts that could muddy the waters, in practice it is easy to teach the concepts that I want without having to include too many things that I don’t want.
Thanks for reminding me that when I refresh my résumé, I have to bump my Odersky level.
Unfortunately, I have no idea how they map to Dotty levels. I suspect that, as when a company is acquired, the title stays the same but the pay is cut.
And that’s exactly why they are a good tool to learn how to program. You are not given any shortcuts or magical operations; you are forced to think on the more basic way of manipulating data. Sure, when you go on to learn much more advanced concepts, they are quite the hindrance; that’s true in general. But we’re talking about beginners here.
This is easy to write, not easy to understand. Beginners may very well not have the capacity to understand the abstraction that is happening here. They need a more explicit and low-level view of what’s actually going on here.
You’re thinking of “beginners” as “senior programmers who are beginners in Scala / functional programming”. Actual beginners of programming will be heavily confused by this unless they are given quite a lot of guidance. I’m not saying functional programming shouldn’t be taught, but that it is an advanced topic and needs to come much later on. It should definitely not be the first experience of beginners with collections.
Um - no. That may be the way you learned, but it is not absolute truth. We’re finding that, for a lot of true beginners, who have never encountered imperative programming, FP is a relatively easy way to start out, provided it’s done properly step-by-step. It’s only when they have imperative techniques wired into their brains that it becomes “advanced”.
This is the usual mistake that experienced programmers make during paradigm shifts: they complain that the new approach is terribly hard, that beginners can’t do it, and that only “advanced” programmers could possibly master it. I listened to exactly the same arguments 25 years ago, when OO was new, and the C programmers (much less the COBOL ones) would talk about how mentally challenging it was to think in objects in C++ or Java. But it wasn’t difficult then, and it’s not difficult now – it’s just different, and calls for teaching appropriately. And it is usually much easier to learn when you are starting out, before your habits have set in stone.
It does not change the fact that FP is the next level of abstraction.
May be I am getting old. But I think the measure of good skill is understanding
If we say about the stones young people should learn algorithms. And they is classically written in imperative languages.
I am sure that real practice with languages like
Can develop a brain even better than any universal high level language.
Languages and technologies always change nevertheless healthy way of thinking can help you in any situation. Can scala guarantee that you cannot catch bad habits?
Actually, no it can not. Because if you aim to develop linux core high level abstractions will not help you at all.
A leaky abstraction is always mentally challenging.
If you take wrong tool you highly likely will get leaky abstraction.
Can OO \ functional style be leaky abstraction. Of course it can.
People just don’t discuss an ability to write micro services or drivers in scala. They prefer Go and C
If there are no ideal language for programming. Why should there be ideal teaching language?
That’s a fair question, and I agree: different levels of abstraction are good for different problems.
That said, I originally learned to program in raw assembler, back in the 70s (well, that and BASIC), about as far down the abstraction tree as you can get, and very little of what I learned through that is remotely useful to me today as an application architect. So this argument cuts both ways: the best things to learn depend on what you plan to do.
I’m willing to grant that “ultimate teaching language” is hyperbole, and I’m not really defending that; I’m mainly pointing out that claims of Scala being too hard for beginners are empirically incorrect.
The important point is that Scala is a good introductory language, which works well in practice when used in a well-designed course, and can teach a wide range of good application-level programming practice if you do things in the right order. Given how viscerally some people seem to be opposed to that idea, it suggests that we need, within the community, to communicate better about how best to teach it…
May be I am wrong. But I have not seen here objection against this statement.
It seems for me that the discussion is about what is well-designed course and for whom.
There are
I can see a good well-designed course for university.
But there are so many difficulties to the third group.
IMHO it is complex and difficult question for the third group.
It contains such question as
You’d might be surprised, but the first ever language I studied was Logo (MSWLogo). I then proceeded with procedural Pascal, then FP with Scheme, and then back to Pascal. That was all in mid-high school. I can say that most of my “colleagues” found procedural programming much easier.
Other than my own curiosity of implementing “Game of Life” in C++ with a bit of classes, I had no OOP experience until a year or so later in my extremely intensive and comprehensive course in the army, where I studied Python, C++ and Java (among other topics in Linux, mathematics and telecommunications).
OOP can be considered as advanced as FP, I’m not denying that, but there are plenty more basic topics in programming best learned at the start.
No one is denying that. The argument is that there are better languages for that purpose (except perhaps for FP topics).
Functional programming is relatively simple if your problems are all of the form “given this data, calculate that data”. Once you start interacting with files, databases or other external services or with users, you either have to leave the FP paradigm or become fairly advanced or complex.
@eyalroth
And that’s exactly why they are a good tool to learn how to program. You are not given any shortcuts or magical operations; you are forced to think on the more basic way of manipulating data. Sure, when you go on to learn much more advanced concepts, they are quite the hindrance; that’s true in general. But we’re talking about beginners here.
This is an interesting discussion in the philosophy of teaching. What you are describing here becomes a really strong argument for starting in C, where there are no nice libraries and everything has to be done down at the lowest level. The thing to keep in mind with a CS program, which is what I’m normally concerned with, is that students will take courses over 4-years. CS1 isn’t their only course, but it lays a foundation. It also needs to keep their interest. If you teach in C or use Java in the way you are suggesting here, you can only go so far in terms of interesting problems. If it takes 500 lines to do anything interesting, that becomes the final project in CS1 and everything up to that is less interesting. I like Scala collections in CS1 because they allow students to do interesting things early. They will learn other languages, like C and C++ later where they have to understand the mechanics of what is happening in map and filter (actually I often have them write those methods on their own collections in CS2), but I prefer to stay higher level in CS1 so that we can solve bigger problems without having to force the students to write all the details. Of course, that is just my opinion, and I can easily see the argument for wanting to start with the low-level code. I just think that can cause you to lose more students if they don’t find it interesting.
I also agree with @jducoeur that it is easy for people to fall into the trap of thinking that the way they learned things was inherently the “right” way. That also means they bring the preconception that paradigms other than the one they started with are harder. If you go to the academic literature you will find that whatever paradigm a student starts with, they pick that up and find it harder to think in terms of others. I personally view the multi-paradigm side of Scala as a benefit here. I’m not indoctrinating students into one single paradigm by using a language that absolutely forces them to work that way. I like functional approaches and generally prefer them. However, if I limited myself to only covering immutable lists then topics like binary search can’t really be covered.
This is the real key. Learning to program should be about learning concepts, not learning languages. The languages are vehicles for the concepts. So which language is actually ideal depends on which concepts a program wants to put in their introductory course. @AMatveev brought up the issue of people learning on their own without a teacher. I’m not certain how different that is. In that case, the “teacher” is whatever prepared materials they are going off of. They lose the ability to ask questions. They also need a higher level of motivation to push through because it will be harder to get over any hurdles. Often this group gets focused on learning a language and doing one particular project. While that can be good for motivation, I don’t know if it lays the ideal foundation for understanding CS as a whole. Everything has tradeoffs.