I'm on board with Java not being a great first language but I'm pretty tired of posts constantly citing ancient unidiomatic Java to prove how bad of a language it is. Their file i/o example could just as easily be<p><pre><code> import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
public class fileIO {
public static void main(String[] args) throws IOException {
Files.copy(Paths.get("test.txt"), System.out);
}
}
</code></pre>
Granted that Files utility was added in 2011. Even in 2010 there were plenty of better ways to write that example.
I would partially agree with this even though Java is a great language.<p>I can firmly recall in my CS 101 class where they were teaching basic programming using Java, and the teacher seriously told us "just put static in all of your method declarations, don't worry about why yet otherwise you won't be able to use them in your main".<p>...didn't fully learn what static meant until over a year in my programming career.
What's the point in hiding the fundamentals of OOP, rather than starting with them very quickly? You can't get very far before you're calling methods on the strings you're printing.<p>I'm genuinely curious, I sat through an intro to programming & follow-up course in PHP and that line of thinking seemed to confuse the students. They weren't sure of what a function was even though they were using functions! The professor never got around to explaining OO or any fundamentals.
He's deliberately made the java example of file input too busy, it's poorly written. And added multiple exception handling to make it longer than it needs to be (in its context).<p>I started in BASIC as a kid. The barrier to entry was minimal and fun for a few hundred lines of code.<p>To manage the complexities of a large code base, you need to have supports and infrastructure and information hiding to structure it neatly. That adds extra code, but contains it in a way to makes sense of it all.
Logo[0] was my first programming language on an Apple IIe. I was in 2nd grade and I loved it. You had subroutines, but that's it. Essentially all state was visible (although you could do increasingly more magical-seeming things the more state you hid - a truism that has held since then). It was a lovely way to see the thread of execution.<p>What an amazing experience to read Papert's[1] Mind Storms[2] as an adult to understand the profound thinking behind Logo.<p>Why not teach Logo as the first programming language?<p>0. <a href="https://en.wikipedia.org/wiki/Logo_(programming_language)" rel="nofollow">https://en.wikipedia.org/wiki/Logo_(programming_language)</a><p>1. <a href="https://en.wikipedia.org/wiki/Seymour_Papert" rel="nofollow">https://en.wikipedia.org/wiki/Seymour_Papert</a><p>2. <a href="https://en.wikipedia.org/wiki/Mindstorms_(book)" rel="nofollow">https://en.wikipedia.org/wiki/Mindstorms_(book)</a>
One thing to consider when picking a language for someone's first programming experience: students like the 'language du jour' - it motivates them.
I like the idea of using Basic/Pascal/Blockly/etc (and students like how easy those are) but about 3-4 weeks in they'll start to ask "Sooooo.... does anyone actually use this for real, in industry?". This tension between wanting something easy enough that students can handle it vs. wanting something that 'real' programmers use is common.<p>Picking a language like Java (and handing out starter files to overcome the required verbosity) is a nice way to go - it reduces the cognitive load to something they can reasonably handle AND it keeps the motivation of using a "real world language"
Disagree 100% and that's because I've helped and seen many juniors who learn ruby or JavaScript first not actually understand what they're doing. More so ruby, FWIW.<p>Examples: in junior ruby engineer, even some mid level, the confusion between local variables and attributes causes huge amounts of confusion. I don't know how many times I've asked "why is this an instance variable?" to a response being the sound of crickets.<p>Things like attr_* in ruby cannot be appreciated until you know why they're there. In more verbose languages like Java you're forced to understand from the beginning. Yes, there's more to learn before you get started but once you've learned it you're capable.<p>Learning Java was a huge "aha!" moment for me after having spent years with ruby. I've known others who express the same.<p>I think developers who don't learn a language like Java first hit a very hard and tall walls at some point in their learning and advancement.<p>Java also is much better, IMHO, language to learn design patterns in, because there is often no shortcuts provided by syntax to "prevent" or circumvent them. Also an added bonus is that the example you're reading is likely to be in Java.<p>I used to think scripting languages were great for learning to program but my tune has changed as I've progressed over the last decade. I now think they inhibit learning at a certain point because they lack the rigidity needed to demonstrate more advanced techniques to the learner.<p>I love ruby, it's in my damn username, I just don't like it as a first language these days.
I disagree.
Yes, Java is verbose, but all this verbosity makes sense.<p>I think it is better to write more code, but be able to understand it and reason about it, than write one line and rely on all magic under the hood (having no idea how it works).
Or for younger programmers (pre-college) a learning oriented language like Processing where you can gently move into java, and get to do graphical and interactive programming quickly seems to be a better option. As a teen, the lack a excitement from learning to write to files and handle text input killed my initial enthusiasm for programming and had me go first into the sciences instead. Whereas, I still find it very satisfying to be able to make interactive graphics in a few lines of code in a way that text output or static webpages never will for me.<p>For the college level, I agree with the writer's suggestion of Python, not just for its ease of learning, but its breadth of libraries making it useful for many science and engineering courses. However, I think that for getting advanced (fun) features early on by picking and getting the right library (working) may still be a bit too much unnecessary friction to do 'fun' programming to get earlier students engaged. Learning extra tooling and library systems is 'trivial' if you code regularly, but is still a surprising amount of work when you're new to programing and gets in the way of early feedback. (I have had colleagues in the sciences hesitate at the sight of import statements, dealing with multiple libraries, and new IDE's when suggesting using something like sci-py/python over Matlab for projects, for these sorts of reasons.)
The examples the author cites of having to write a great deal of code that one does not understand is the motivation for Racket's language levels [0].<p>However, it is not just a matter of Java having a syntax that imposes a lot of cognitive load on novices. It is about being able to talk basic programming language features independently from advanced languages features. This is independent of both syntactic and semantic complexity. Python's clean syntax, for example, masks some really complex semantics.<p>Neither Java and Python are poor programming languages, but their overriding design goals are to be languages that proficient programmers can be very productive in. The pervasive mistake in CS education seems to be that these languages are therefore great choices for teaching programming to non-programmers. They are almost certainly not.<p>I really hope that the discussion of languages for CS1 can move beyond this. There are many languages whose overriding design goal is to be phenomenal for introductory computing education. They are designed by computer science educators, and are shaped foremost by the observed successes and difficulties of actual students that are learning to program with them. They provide answers for educators beyond just a syntax and semantics; frequently, they come battle-tested textbooks and teaching materials.<p>[0] <a href="https://docs.racket-lang.org/drracket/htdp-langs.html" rel="nofollow">https://docs.racket-lang.org/drracket/htdp-langs.html</a>
This isn't a bad idea (Python not Java for a first language makes sense on a number of levels) but the example is setting up a straw-man. Why is the Java code handling exceptions when the Python code isn't? Why is the Java code reading the file line-by-line and the Python code isn't?<p>Further, you could easily write a simple file library in almost any language that abstracts over the difficulty of using the full file library if you're looking to ease people into programming.<p>All that being said, Python is a pretty good first language and there's a reasonable chance that someone who does one course in Python might be able to do simple tasks later on, which is nice. I think first languages should generally either be simple scripting languages or 'hazing' languages (i.e. something weird to put everyone on a more level playing field).
If you're going to take CS AP classes in high school, it's gonna be Java. This probably explains why a lot of people learn Java as a "first" language. (And no, not everybody started programming when they were five.)<p><a href="https://apstudent.collegeboard.org/apcourse/ap-computer-science-a/course-details" rel="nofollow">https://apstudent.collegeboard.org/apcourse/ap-computer-scie...</a><p><a href="https://en.wikipedia.org/wiki/AP_Computer_Science" rel="nofollow">https://en.wikipedia.org/wiki/AP_Computer_Science</a>
So we should start to teach ppl to fly planes by first teaching them to ride a bike? Riding a bike will not help you fly. Programming isn't hard but if "public static..." melts your mind, software may not be for you.<p>Also the classic file read idiom (the C one) teaches some of the most basic things <i>every</i> programmer should undertand:<p>. file encoding (which you ignore)<p>. buffer sizes<p>. error handling (likely 80-90% of production code)<p>Your python example ignores these basic instructive points. Why is there no "String str=String.read(file)"? Because it's seldom useful in production (see points above).
I disagree with this.
The second course most [software] engineering students at my university are exposed to, after basic MATLAB and C programming, is 'Object Oriented Design', which teaches the fundamentals of OOP using Java.<p>It's very useful to have a consistent mental model of classes, methods, variable lifetimes, etc. early on.<p>Of course, if you're teaching yourself to program (or recommending a language for self-teaching) then Java probably isn't the way to go. However, with a competent teacher, fundamental Java knowledge can be invaluable.
Currently learning Java in AP Computer Science in highschool.<p>I have past experience with Java/C/programming, so it's not too difficult, but a lot of my classmates struggle due to the complexity of Java. Thankfully, the AP test is mostly logic focused, but the amount of time we spend going over Java is less time we can talk about problem solving. (And the amount of time we go over topics like what "static" means is substantial)
Seems like if you did spend the time and effort to understand all the parts of the Java example, you'd be well on your way to being a coding badass. But it's important for someone forming their first impressions to be able to have a quick turnaround from having an idea, to telling the computer to do something, to having the computer do it. That's the part that gets 'em hooked!
I teach Java in my "Intro To Programming For NonMajors" class. I get around the problem of "lots of boilerplate code required" by giving them a file with the boilerplate code, and then have them start writing their code in main(). It works well enough (certainly as well as having them write 10 PRINT "Hello, World!") and the students are fine with it.
I think the first language course should not be any single language but a language sampling course. Students learn the concept of variables, switches, loops and subroutines, then they learn how it is used in all common languages. And for homework, they are allowed to pick their favorite.<p>For starting programmers, language is not important, concepts are. Any specific language will skew the concept.
Any easy and quick language will do.<p>I started with Visual Basic in high school, it was a great base and kept things interesting. Our teacher did a great job of giving us fun projects to develop and I think that was way more important than the language chosen.
In my high school we learned Pascal first. OOP Pascal Second. C++ third. and C last. I am forever grateful to have learned programming in this order. It has enabled me to jump into any language and just "get things done".
Java is my favorite language now, but its power comes with a lot of potentially confusing constructs. The sheer complexity of the syntax is bad for beginners as well.<p>It's harder to create program that compiles and runs, at least until you understand compiler and syntax errors well enough to avoid them.<p>I learned Java as my second language after Perl and I remember how horrible it was to grok all the concepts at once.<p>At the same time, like I said, it's my favorite language now. The syntax, constructs, and standard library are built in a very sensible way. There's nothing I can look at in Java and say "wow this really fucking sucks" which is rare among languages. C# is the only language I can think of that definitely has cleaner design.