Book making use of amber features

[Ethan McCue]

> Nice! Why not go ahead and change all System.out.println to IO.println?

I'll do that once it's either totally set that they are doing plain println
and I just need to deal or they make IO.println function.

> I read through your transition to multiple files. It isn't clear to me
whether up to this point, students always name their program Main.java.
Maybe add a note that in general the name of the implicit class is the file
name.

Noted. I'll reread what I got with that in mind. What I noticed the most is
kids with a mega vs code project where they name the files just whatever.

I also don't think that the implicit class is supposed to have a defined
name, so...hmm.

> Just tell students to import module java.base when they use multiple
files. I wouldn't get into import static java.io.IO.*. That's a lot of
complexity just to save "IO." for three methods.

Haven't had a need to yet. Some of this seems to be feedback to those who
can actually make these choices. I'll re-add amber dev

> Another unrelated point: Why cover arrays before array lists? Lists are
more regular. No special syntax, just method calls. And in practice, arrays
aren't all that common. Students hate gratuitous choice. When my students
asked me when they should use an array and when an array list, I always
told them: Use an array list unless your professor, or an API, insists you
use an array.

Yeah so when I was a student I had the same frustration. Why even bother
with arrays? Just show me List!

I think what I'm realizing is that I wasn't actually annoyed with arrays, I
was shown both arrays and ArrayList before I had enough knowledge to
understand why to use which.

The rough order now is
* Cover arrays first. Let's us do that deeply. All we really care about
early on is grinding methods and loops so it's all the same.
* Cover ArrayList as useful if "you want basically an array that you can
.add to"
* (To be done) Cover List and frame List as an abstraction over different
kinds of lists including ArrayList + you can turn an array into a List with
Arrays.asList + if you don't need to add or set you can use List.of

So basically I just think I can build up to a non hand wavey answer to
those questions.

> Also consider covering maps early on.

I am very frustrated with courses that don't teach people maps so 100%
going to do it. I have a commented out "build your own hashmap" section
just like the "build your own ArrayList" but I might replace it with just
"here is a Map/hash map" or... I'm not sure yet.

But I don't see a pedagogically sensible way to get them in real early
unless I front load Object, generics, etc or start hand waving.




On Sun, Nov 10, 2024, 2:53 AM Cay Horstmann <cay.horstmann at gmail.com> wrote:

> Nice! Why not go ahead and change all System.out.println to IO.println?
>
> It's shorter. It's consistent with other methods such as Math.sqrt and
> Integer.parseInt. It works in JShell.
>
> I read through your transition to multiple files. It isn't clear to me
> whether up to this point, students always name their program Main.java.
> Maybe add a note that in general the name of the implicit class is the file
> name.
>
> Just tell students to import module java.base when they use multiple
> files. I wouldn't get into import static java.io.IO.*. That's a lot of
> complexity just to save "IO." for three methods.
>
> Another unrelated point: Why cover arrays before array lists? Lists are
> more regular. No special syntax, just method calls. And in practice, arrays
> aren't all that common. Students hate gratuitous choice. When my students
> asked me when they should use an array and when an array list, I always
> told them: Use an array list unless your professor, or an API, insists you
> use an array.
>
> Also consider covering maps early on.
>
> Cheers,
>
> Cay
>
> On 09/11/2024 18:01, Ethan McCue wrote:
> > Hi all,
> >
> > I've shared this with some folks separately, but it's at the point where
> it's "partially topic complete" enough that I think I can share it more
> widely.
> >
> > I have been writing a book for covering Java as a first language
> assuming all the anonymous main class changes have landed.
> >
> > https://javabook.mccue.dev <https://javabook.mccue.dev>
> >
> > I still need to go back and integrate println, readln, etc. (and
> obviously go further)
> >
> > I am sharing it here partially because I assume some general interest,
> but mostly to highlight the section where I transition from single files
> with anonymous main classes to full classes in their own files.
> >
> > https://javabook.mccue.dev/multi_file_programs <
> https://javabook.mccue.dev/multi_file_programs>
> >
> > If it's going to be how this goes, I think I need advice on how to also
> include enough pre-work so that import static java.io.IO.*; and import
> module java.base; won't be a jumpscare.
> >
> > This blurb from my README I think suffices for additional context
> >
> > My primary goals with this are
> >
> > * Get the ordering of topics right. By this I mean that every topic
> covered should have had its prerequisites covered in the topics previous.
> While "lesson 1: Inheritance" is clearly wrong in this regard, some things
> are more subtle.
> > * Be a template for other people. This is a book. Not everyone likes
> books, some like youtube videos, some like over priced udemy courses, some
> attend College, etc. Everyone has different learning paths. I hope this to
> be of use to anyone looking to make a more up to date Java curriculum and
> hope that the vague order of things (which I consider superior to the
> content
> > produced with the Java of years' past) is carried through.
> > * Write as if the newest Java wasn't new. It's obvious when a book was
> written before Java 8
> > because it always has newer additions with "addendum: brand new stuff in
> Java 8." But
> > the order language features were introduced is hardly a good order to
> teach them. You have
> > to pretend that Java 21 has always been *the* Java. Does it really make
> sense to show terrible
> > C-style switch statements way before switch expressions?
> > * Write as if the words Object Oriented Programming, Functional
> Programming, etc. didn't exist.
> > While I understand that these all have definitions and are useful
> concepts to know about, introducing them early seems to lead to either
> dogma, rejection of said dogma, or some
> > mix thereof. None of them are actually needed to understand the
> mechanics of and motivation
> > behind what we would call "object oriented" or "functional" techniques.
> They certainly don't
> > work as justification for adding getters and setters to every class.
>
> --
>
> Cay S. Horstmann | https://horstmann.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241110/e439a28f/attachment-0001.htm>