I'm not sure I'd consider a decision to move from Java to JavaScript an improvement. They are going from a bloated syntax to a bad-habit goldmine. Why not go Java -> Python instead?
Besides, everyone in a CS program these days gets a shell account, right? I mean, login from home using whatever SSH client is hip on Windows these days and then it's just a matter of doing:
javac YOURFILE
java YOURFILE
No complex environment to set up at all, although even setting up a Java IDE is not that hard (my friend's HS students do it with little problem).
Besides, you don't need an IDE for Java, it's just that most people use one. I personally use gradle and vim when progamming Java.
GOROOT and GOPATH are set automatically by default, you don't need to mess with these unless you want to.
> I think it's about the same as Java in terms of complexity.
Even if GOPATH/etc weren't set automatically, you still need to learn Maven and Gradle and friends. I've been programming for a decade or so, and every time I try to play with Java I have such a hard time getting projects set up. I don't know if the tooling is really so complex or if the happy path is just poorly documented (perhaps because everyone assumes you're using an IDE?). A few things I had trouble with: - Getting the Gradle server set up so I didn't have to wait for the JVM to boot every time I wanted to compile anything - Configuring Gradle to compile a native dependency like OpenGL - Configuring Gradle to produce a fat jar - Configuring Gradle for unit testing
By comparison, with Go does all of that out of the box (`go build` doesn't have a VM to warm up, and Go's tooling supports native dependencies, static compilation, and testing by default).
I don't think this is a big problem if you already understand Java's ecosystem or if you have someone to hold your hand until you get a project set up, but I had a terrible time finding the right documentation.
> Besides, you don't need an IDE for Java, it's just that most people use one. I personally use gradle and vim when progamming Java.
Last I checked (a year or so ago), there were no reasonable vim plugins for Java. Certainly nothing as mature as vim-go.
Where is the mkdir icon on my windows desktop?
I bet they don't, though :/
Of course your conclusion that IDEs are more somehow productive than text editors is completely baseless (or perhaps only based on experience with Java and the like).
There are two possible reasons for this I can see:
1. Go is so awesome that unlike any other language I've used in my multi-decade carrier, it can not be improved with an IDE. It's just an ideal and any attempted improvement would just spoil it.
2. There's no decent IDEs for Go and Go developers are forced to do with what they've got.
My experience shows the former is much more probable than the latter.
> Developing Go without an IDE is quite feasible
Of course, people programmed when ed was an IDE, and before that. It's humanly possible. Is it better? I highly doubt it.
> The particularities of IDEs which make them more productive than text editors are artifacts of the poor project system found in most languages
I'm sorry but this statement sounds both misinformed and fanboyish. There are tons of benefits to IDE which have nothing to do with "poor project system" - from module management to task management to refactoring to keeping integrated information about the project to code assist, etc., etc. I could spend an hour writing them. Claiming that Go "fixed" need for IDE sounds, excuse me for being blunt, laughable. It's like when iPhone was first released, I heard some fanboy claim that iPhone interface is so intuitive one doesn't need copy-paste (first version didn't have it). Of course, next update added copy-paste and iPhone users (including the said fanboy) are happily using it ever since.
> or perhaps only based on experience with Java and the like
Yes, it is based on almost 30 years of experience with programming in multitude of languages and environments, and this experience is why I find claims that Go is so awesome it needs no IDE so laughable. I'm sorry to look self-aggrandizing here, but you asked about it so I have to say it I guess.
Fanboyish? Quite a statement from someone arguing that IDEs are necessary--my position is that they're optional. Misinformed? The features you list aren't particular to an IDE--they're available in any pluggable editor, which is a repackaging of my point. I don't mind a rude rebuke, but you're not even vaguely correct. Forgive me for basing my decisions off experience and not your misinformed speculation. ;)
Javascript might have its hassles, but even when you get to dealing with npm it's still more of a self contained thing.
But if you're introducing people to programming, letting them know command line exists may also be not that bad of an idea :)
Ideally they would all learn about computer architecture and memory management at some point. But at least with this course motivation and interest is a big problem, and producing confident Python programmers seems a better result than terrified students who can't produce competent C.
Our final project is a memory Allocator (Malloc, Realloc, Free). By the end, students really do grasp computer organization and architecture.
Not that JS is optimal for any of those use cases.
"According to research published by Philip Guo on the ACM (Association for Computing Machinery) website in 2014, Python is now the most popular language for teaching introductory computer science in the United States.
Eight of the top 10 U.S. computer science departments, and 27 of the top 39 (69 percent) use the language to teach the fundamentals of Computer Science."
I think ES5 would be a legitimately better first language. Now that ES6 is everywhere though, javascript is a really terrible first language, certainly worse than python... the online learning material for a `for` loop, for instance, is now split between `for(var ii = 0; ...`, `for(let ii = 0; ...`, `for(var x in obj)`, `for(const x of obj)` (but make sure that something called `webpack` is set up with something called `babel` so that all of these will actually work). You'll find similar confusion when approaching variable declaration, module imports, etc.
Signification white-space should actually help students when programming because it forces code to be properly indented instead of having an indentation disaster or misplaced braces.
One-line lambdas and decorator functions are no worse than JavaScript's.
The tuple syntax is clunky, but there is an important distinction between it and lists: mutability of the list itself.
Frankly no one should be using `global` without a very good reason.
The split between 2 and 3 is hardly worth mentioning. 2 is the legacy version. 3 is actively maintained and most major libraries have supported 3 for a while. Very little changed syntax wise between them. The split was necessary because of a fundamental improvement and disambiguation between textual and binary strings.
As for magics, don't see why it would be an issue either. For a beginner, it's a magic incantation just like any other, for more advanced student, it's a callback/override just like any other. You can argue that this system has its disadvantages, but if you understand enough to argue about such matters, your education as a beginner is a definite success.
2/3 gap is an issue, yes. Fortunately, one can just teach python3 and leave python2 for advanced studies. It's not like students would be deploying in industrial production right after the class...
That's precisely why I think it's a good idea: with proper instruction, you can teach people good habits from the start.
I mean, the majority of these students will have to write JavaScript sooner or later. Better they learn it in a controlled environment.
You also can't really teach only an opinionated subset of the language, since students use all kinds of material to learn. Material about JS is often steeped in environment details (browser, nodeJS, JQuery, ...), and thanks to transpilation right now multiple versions are popular, which makes it even more confusing.
It wouldn't be impossible to teach a good intro course with JS, but I don't see any benefit in doing so, and it wouldn't make the students very effective JS programmers.
That's what the instructors are there for...
You can tell them, yes. But as you rightly say, an important thing is to experiment and (IMHO) to see for yourself what works and what doesn't. And that part works best if it fits their abilities. Experimentation should lead them past what they've learned from you, but not into to much confusion, which for absolute beginners can be incredibly demoralizing.
More talented students will go into different languages and weird stuff anyways, I'll help them when they ask questions or I see something they are doing I can contribute to, but I can't run a course matching their abilities as an intro-course.
Again, I'm not saying you can't do it in JS, but it's not a decision of "let's use JS because I want people to learn JS". And if having JS in there is the goal, nothing wrong with running a course using multiple languages and using JS as one of the later ones. Ideally, after a good set of intro courses your students have seen enough that they can pick up most languages relatively easily, and then, when they need them, learn what current best practices and their ecosystem are.
Remember, we're talking about intro languages here. It's a much better idea to teach languages that encourage good habits because then going to "wild west" languages like javascript is much easier.
Very few people formally learn JS. It's usually more of a read up on syntax, read documentation of a library, apply concepts.