diff --git a/Scala-modularization-and-classpaths.md b/Scala-modularization-and-classpaths.md
index 2375074..42afcc1 100644
--- a/Scala-modularization-and-classpaths.md
+++ b/Scala-modularization-and-classpaths.md
@@ -6,11 +6,11 @@ Scala modularization makes it necessary to deal with some existing issues that m
 
 The term "boot classpath" comes from Java's Bootstrap Classes, which are the classes that implement the Java Platform. By default, bootstrap classes are in the `rt.jar` and several other jar files in the `jre/lib` directory according to [How Classes are Found](https://docs.oracle.com/javase/8/docs/technotes/tools/findingclasses.html).
 
-For the Java boot classpath, the `scala` launcher justs puts everything in `lib/` on it.
-This is not the right thing to do because it makes available classes not on the user's classpath.
+For the Java boot classpath, the `scala` script justs puts everything in `lib/` on it.
+This is not the right thing to do because it makes classes not on the user's classpath available.
 It also forces a particular version of the config, JLine, and JAnsi libraries.
 (Currently Scala's JLine is in a custom namespace, but I believe a goal is to use the standard JLine.)
-I think it is closer to the right thing to do for the `scalac` launcher, because no user code runs and configures a particular classpath.
+I think it is closer to the right thing to do for the `scalac` script, because no user code runs and configures a particular classpath.
 (This is not strictly true with macros anymore, but I expect macros are discouraged from using JLine.)
 
 I assume the original reason for putting anything on the boot classpath is to avoid some jvm overhead somewhere, perhaps class file verification.