My books are definitely aimed at the “long haul” of a full semester (or two) of courses. They would not be ideal for something shorter than 30+ contact hours.
Just a little comparison:
- Introduction to the art of programming using scala, mark c. lewis
Someone should read 887 pages of theory which I am sure quite boring for true beginners- automate the boring stuff with python
Someone should read 123 pages of theory, the other 320 pages are about interesting practical tasks
My book is intended to be covered over two semesters at the college level and includes topics from conditionals up to spatial trees. You are comparing apples and oranges here.
I am sorry, It seem that my post has been incorrect.
I did not try to compare books. It is more likely beginners comparison.
How many beginners will be able to successfully complete this course without a good teacher in the world for example?
I’ve been teaching my oldest son Scratch since he was six or seven. Now he is nine and taking a programming class at school, where they use Python using IDLE as an IDE. He likes it.
I’m assuming beginners today would typically go through these stages:
(1) REPL or similar
(2) IDE with no dependencies
(3) IDE with dependencies
(4) build tool
I totally agree, but I believe Scala just has too much overhead for that task. Not only that it suffers from the more cumbersome ecosystem of Java, but it requires a project setup using a build tool. I don’t expect students to use the REPL all day. Python for instance is much more straightforward.
I take it that you aren’t familiar with Scala’s scripting environment. There is no overhead. The student puts println("Hello World!")
in a text file and the executes scala HelloWorld.scala
and it runs.
I would much rather beginners to learn the usage of collections with Java rather than Scala
Personally, I think that Sets should have operations like union and intersection, but perhaps we disagree on that. I find the Scala collections to be great for beginners as they give them a lot more power to do things that are interesting quickly. Java’s collections feel very poorly thought out and limiting to me whether for my personal programming or for teaching. Again you run into things like why do you have String[]
and int[]
that are accessed with arr[i]
but you when you use ArrayList
you can do ArrayList<String>
but need ArrayList<Integer>
and then you need to use get
and set
for accessors.
Most of the other things that you describe as being problematic in Scala never come up in a CS1 course and they don’t force themselves on the students either. I can see this being hard to imagine when you deal with these things daily, but if you actually spend time teaching beginners to code and you think about the curricula, you will find that Scala can be taught very much like a statically typed Python. Whether the issue of learning types is worth the challenge is something we might just have to agree to disagree on. The reality is that types still matter in Python, but they are more hidden and become run time errors instead of syntax errors. One of the fundamental rules of teaching is the early feedback matters. I think that applies to errors in programming as well. The earlier a student knows there is an error in their code, the more likely they are to learn from it.
@odersky, up until this semester we did the full first semester in nothing but the scripting environment. We demonstrate things in the REPL, but then write scripts for everything else. This year we decided to move some OO into CS1 and as a result we pulled in sbt for the first time. This happens nine weeks into the semester and I gave them a full setup with sbt and had them use VS Code and Metals. I used to only do that in the second semester when they also learn how to use git. There is overhead in this, but by giving them the code (they actually just pull it from a repository set up using GitHub Classroom) they don’t notice much. They just know they run things with sbt
instead of scala
at the command line.
Self-thought is about 70%
How many of those are new to programming? I’d guess that the vast majority who participated already had programming experience (like I did when I took one of these courses).
Both of these arguments regarding collections are particularly related to the functional approach to them. It is not necessarily part of the basis to understanding them, nor is it necessarily all that intuitive for beginners in programming.
I was actually not familiar with it, and it’s actually great! I’m assuming it gets harder when there are multiple files with dependencies between them, but that’s a good start (and certainty better than Java).
I agree it ain’t perfect, but I still prefer it to Scala’s (for teaching, not for my own usage). For starters, Scala has a Seq
instead of a List
. Then there’s all the monadic operations like map
and flatten
, along with strictly functional-oriented methods such as head
and tail
. Java’s API is a lot cleaner and focused on that matter. Oh and immutability – it’s an important concept, but I feel like it’s very unintuitive for beginners and should be regarded as an advanced topic.
I guess
You can get quite far with Scala REPL and Scripts using Ammonite: being able to pull in third party libraries and split a script into multiple files is a game changer. The main thing you lack is deployment-related stuff like building pre-compiled jars, running test suites, defining asset pipelines, but maybe for introductory material that doesn’t matter. IntelliJ integration works moderately well (though not as good as Mill or SBT). Cold compiles are slow, but iterating on a script with --watch
is as fast as any build tool.
I have quite a lot of real-world code running on Ammonite scripts: building docsites, auto-publishing OSS libraries, rendering my personal blog. You can get quite far before reaching for a “real” build tool, and with a bit more work on Ammonite we could probably push the envelope of usability further out
Writing “Hello, World!” to the console is easy. How about writing it to a file?
In Python, you open the file, write, and close.
In Java/Scala, using only standard library, there are multiple slightly convoluted ways. For example, you can create a file output stream and then either create a Writer or convert your String to an array of bytes.
It gets easier using Better Files, but that’s a third-party library.
Ammonite comes with OS-Lib bundled, for good reason
os.write(os.pwd / “file.txt”, “Hello World”)
OS-Lib/Ammonite provide easy access to subprocesses, shell commands, and also comes bundled with requests-scala and uJson which gives easy access to 95% of public APIs and services
It’s pretty great, and is rock-solid code you can grow and deploy to production environments, so not just a toy for learning
(also, third party libraries are just as easy to use in Ammonite as the standard library. It’s all just a single import
away)
Provide a one-click set-up-and-go. I mourn the loss of Lightbend’s Activator project: while it was imperfect, its heart was in the right place, and it was a step in the right direction. When we are running ScalaBridge, we often spend hours getting the students up and running – it is by far the biggest pain point, and a huge hurdle for people dipping their toe in the water.
If there was a one-click installer, that provided the JVM, Scala, sbt and (in a perfect world) VSCode + Metals / Scala 3 (or an equivalent Ammonite-based environment), it would make that introductory experience far more pleasant, IMO. Not by any means a trivial project, but I think it would do a lot for Scala’s image if we could get people going without all the pain…
If there was a one-click installer, that provided the JVM, Scala, sbt and (in a perfect world) VSCode + Metals / Scala 3 (or an equivalent Ammonite-based environment), it would make that introductory experience far more pleasant, IMO.
Yes, that’s exactly what I would like have as well. There’s some good basis in that it is possible to get and install VSCode + JVM in one bundle. Then, you’d need to get Metals in the VSCode marketplace, or ideally in its own bundle with VSCode + JVM. But Marketplace is probably OK. And that should be it, hopefully.
This is a surprising statement. Collections are IMO one of the best aspects of the Scala experience. The implementation can certainly be complex and hairy but for the most part a complete beginner can use them easily because they just work. The API is homogeneous, with descriptive names, and rich enough that you can remove tons of boilerplate needed in other languages and replace it with meaningful, declarative built-in method invocations.
Also there seems to be the idea that a beginner has to master the whole language, or understand implementation details before he/she can be productive. That’s definitely not the case in Scala.
The API is not just “rich enough” but is humongous; for instance, Scala Seq
has about 180 methods where’s Java (8) List
has about 30. Most of these methods are irrelevant for beginners. They do not need boilerplate-free code, they need to understand the very basics of what’s going on. I would also guess that the homogeneous API is due to all of these methods which are not the core of these collections, and might even make students miss out the differences between the collections.
In my experience students will not just sit idly and use only the methods you ask them to. They will explore independently, and the more they are exposed to the greater the risk they’ll confuse themselves. If you give them a rich and easy to explore tool (aka software) they might very well get carried on with it and abuse it.
Yeah, so teach the simplest, most generic ones?
Scala’s collections hold things and do things for you.
Java’s collections are dumb bags of stuff. They hold things but don’t do anything useful. Even those 30 methods contain some weird choices, like retainAll
, and some kinda-broken stuff like subList
(broken because it returns List<T>
, so you lose your collection type).
Are you sure you’re not coming in with the mindset of a Java-expert where you go, “Oh, in order to do anything at all with a collection, I need to understand all the methods in detail, because I’m going to have to use a bunch of them to assemble a solution to my problem!” And then you get overwhelmed by Scala’s collections’ profusion of methods.
Suppose you have a bunch of strings, but you only want the ones before “stop” occurs.
You might be expecting to write something like this, after marshaling your knowledge of how collections can be turned into iterators, and knowing that Java Iterators have a pretty simple interface:
List<String> answer = new ArrayList<String>();
ListIterator<String> i = xs.iterator();
while (i.hasNext()) {
String s = i.next;
if (s.equals("stop")) break;
else answer.add(s)
}
Or you might use the collection directly, like so:
List<String> answer = new ArrayList<String>();
for (int i = 0; i < xs.length(); i++) {
String s = xs.get(i);
if (s.equals("stop")) break;
else answer.add(s);
}
Or maybe you also want to leverage your knowledge of streams and collectors and spliterators and…er…no, maybe not, as a beginner.
In Scala, you should be just thinking, “I only want the elements until I find the word ‘stop’”.
xs.takeWhile(_ != "stop")
This isn’t overwhelming. This is easy.
A newcomer needs a little bit of guidance to find the high-value methods like map
, take
, filter
, and so on. After that, collections are easy and super-awesome.
If students don’t do filter
followed by map
and instead notice collect
and use that? Awesome! If they get confused by something (e.g. partial function notation), a tiny bit of guidance to “go use this core set of methods” should be all that’s needed.
So, in conclusion: Scala collections have lots of methods, including lots of high-value ones. Java’s collections have far fewer, and miss out on basically all high-level functionality. Yes, it does take a bit more effort to learn how to use lots of powerful stuff. It’s worth it, starting after like two minutes.
That argument that types should have only a few methods so that beginners who explore by themselves don’t get lost makes zero sense to me. If students want to explore, they will not be limited to looking only at the methods of one type, they can easily also look at any other type as well. Standard Java comes with thousands of types, so plenty of opportunities to get lost in.
If we take that argument seriously, then the ideal programming language for beginners must be Scratch.
To be fair, we should be starting exposure to programming early enough that this is the case.
FYI, as a web IDE it already exists in Scala 2 thanks to tgodzik in Eclipse Theia on GitPod via: Dashboard.
It’s related to an issue I created to make Metals available on Eclipse Che. Add plugin support for Eclipse Che (Online IDE) · Issue #46 · scalameta/metals-feature-requests · GitHub
This entire article is based an assumption: the learning curves of Python and JavaScript are smooth and Java’s is steep. It also implies Scala might have a steeper learning curve than Java, though the author believe Scala is still worth to learn even if it is harder.
From my point of view, the assumption about learning curve is totally BS. For example, I learned to use Jupyter for writing experimental Python code from a pre-installed Python environment from Anaconda easily, then I immediately got stuck when I tried to create a simple one source file library. I tried virtualenv, venv, setuptools, pip, pipenv, anaconda-project and combination of them, but still could not create a reproducible cross version project like sbt does. Even if sbt is wrong in some design choice, it is still 100x better than any Python build tools.
I help run an after school code club for 10-11 year children. Approx 1 hour a week during school term time.
We start by teaching Scratch, and following a worksheet they are normally able to create/play a new game (entirely coded from scratch) each week!
After 1.5 terms of scratch, we introduce them to Python, but at this stage they start to lose interest. It is much more verbose to type out python than drag and drop code blocks together, and to do anything interesting is a lot more difficult, and takes too much time.
So, yes, I think that Scratch is a very good beginners language, particularly for children.