> you can streamline the process a lot by just starting with a template and let students fill in the gaps. So you don't necessarily make them spend time on "public static final void main", but setup a project in which students can type code, build and see results.
By all means, if you think you can come up with a way to teach Java to children that's fun and efficient be my guest. We've been trying for decades and haven't cracked the code, so to speak. A lot of professional developers who have no interactions with children have "thoughts" about teaching programming to children, and when those thoughts meet reality, they often find out its not so easy as just writing a little class wrapper and that's all it's going to take. The abstractions of your template designed to hide all of the complexity are going to leak very quickly, I think you will find.
> Matlab is really not a good example imo because if you start wanting to do a bit more, even if it's just to organize the code in better logical blocks, it bad design and lack of OOP gets in the way and makes further progress slower especially for the more talented students.
I've gotta ask if you've actually taught any students using Matlab (or Java for that matter). By what metric do you say it's a bad design? Are you speaking from the perspective of a professional programmer who uses tools to write professional software? Or are you speaking from the perspective of someone who teaches children regularly and are critiquing its design from that perspective?
Because in my experience Matlab has a great design for teaching. It has a ubiquitous data structure, a table, which can store any kind of datatype without having to specify it. You don't have to know about ints, longs, floats, shorts and chars -- all you need to know are there are numbers, and sometimes strings, but mostly just numbers. And the tables/arrays start at index 1. That's a huge deal for teaching students but programmers hate it. They call starting at 1 bad design, but starting at index 0 is definitely an example of something that gets in the way and makes further progress slower for children. But I've gotta say your statements about "especially for the most talented students" rings especially untrue to me because the most talented students are really never slowed down IMO.
Moreover the REPL interface of Matlab allows them to play with their code as they develop it. JAVA doesn't have a REPL and the write-compile-run loops is too long that students lose interest in the coding and debugging phase. Kids love to pair program with a REPL. They are engaged as the interactivity gives them constant incremental feedback. The write-compile-test loop of Java is long enough that pair programming isn't fun for kids. I'll put it this way: for kids, pair programming in a REPL is like playing a game, pair programming in an IDE has all the fun and excitement of writing a book report. Exploratory programming is a sad story in Java, but it's Matlab's raison d'etre.
> Sure it requires some investment on your side, but your students benefit from being able to start picking up a more marketable skill.
Here's the thing, and this is the big problem with AP CS, and why I believe that Java is still taught in this class. People think that teaching kids Java is doing them a favor because they're "giving them a marketable skill" meaning that they will be able to apply to work at Java shops after high school. From my experience they still need a good 2+ semesters with programming before anything they learn is marketable. But developing marketable skills is not really what AP CS is about anyway. All AP classes are really about getting college credit and getting a 5.0 GPA for top colleges. So the skills kids learn there are not being marketed toward companies looking for OOP programmers, they're being marketed toward colleges looking for students. And from our perspective, the perspective of college admissions boards and professors, we don't care about what language they're learning or what "paradigm" they're using whether that's OOP or what have you.
> lack of OOP gets in the way
It floors me that you say a lack of OOP gets in the way, because from my experience it just doesn't. That's completely not what I have found. OOP concepts get in the way far more than anything else. Children just do not organize the world in their brains using class hierarchies (even though that's how their social world is arranged). The original conception of OOP as message passing is far more understandable to children. Like I said my research is still ongoing, but I've gotten middle school children writing more sophisticated asynchronous and parallel code than professional developers with years of experience just through smart language design. When the language gets out of the way and kids are just allowed to think, then they can do pretty amazing stuff. Seymour Papert had kids doing advanced physics with LOGO just by framing the program from the perspective of the turtle.
> what you said isn't worth bashing the language for in general terms.
I don't think I bashed it in general terms (although you won't catch me using it, I'll bash it for other reasons in general terms that are far beyond the scope of teaching children), I am bashing it in the context of teaching children. Sorry if I offended!