I completely agree. IDEs obscure the behavior of tools and languages. It's the last thing a student needs. I've been talking for a while about writing a course that teaches programming in 2 or 3 languages side by side to basically so the opposite of this. The specific quirks of languages or the things they obscure with magic melt away when you look at languages side by side. I wish university would teach in this way.
UCLA has a class that does this, you have 10 weeks to learn 5 languages and write a non trivial assignment in each: http://web.cs.ucla.edu/classes/spring20/cs131/syllabus.html http://web.cs.ucla.edu/classes/spring20/cs131/homework.html The languages change over the years, but the goal is to have them touch different programming paradigms.
Don't Make Students Use Eclipse
141–150 of 255 posts
Re: Don't Make Students Use Eclipse
#142Earlier quoted context omitted.
UCLA has a class that does this, you have 10 weeks to learn 5 languages and write a non trivial assignment in each: http://web.cs.ucla.edu/classes/spring20/cs131/syllabus.html http://web.cs.ucla.edu/classes/spring20/cs131/homework.html The languages change over the years, but the goal is to have them touch different programming paradigms.
Thats a different argument, and a much stronger one. "Universities should offer a class on comparative programming languages and language tooling." is much different than "Intro-to-programming classes should not have a strongly-recommended IDE"
Re: Don't Make Students Use Eclipse
#143> ... it insulates the student from the javac command line program, and the command line environment itself Such a misguided article. The Java language has (quite literally) nothing to do with `javac`. In fact, there's a lot of other compilers out there. Taking a Java class should not focus on the intricacies and weirdness of Java compiler command line interfaces. It seems pretty amateurish to argue in favor of it. C…
Re: Don't Make Students Use Eclipse
#144I completely agree. IDEs obscure the behavior of tools and languages. It's the last thing a student needs. I've been talking for a while about writing a course that teaches programming in 2 or 3 languages side by side to basically so the opposite of this. The specific quirks of languages or the things they obscure with magic melt away when you look at languages side by side. I wish university would teach in this way.
CS50 looks quite like what you're describing. One learns: - C - Python (+ Flask) - JavaScript - SQL I think this was the order. They learn C the most.
Re: Don't Make Students Use Eclipse
#145Earlier quoted context omitted.
> And to this day I find junior devs struggle with the same things unless they have a maven/gradle project all set up for them. Personally I’m still shocked that learning the common build tools for whatever language is used for a CS course is not the standard. If you’re teaching Java you should be teaching Maven, if you’re teaching C++ you should be teaching CMake. Not to the “I can write my own plugins/macros level”…
> If you’re teaching Java you should be teaching Maven no you shouldn't, because the premise is invalid. A university student shouldn't be "learning java". They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language. None of this requires maven, build tools or any tool chains beyond some unit testing framework (and GUI framework if displays are necessary). D…
Re: Don't Make Students Use Eclipse
#146This can fuck right off. My elitist university decided that if it wasn’t pure C built on a Linux box, then it wasn’t worth using. Consequently, I never learned how much more enjoyable and quick programming could be until I used VS at my first job. Even worse, I was a VS novice, struggling to perform even the most rudimentary of debugging techniques, despite being fairly fluent in GDB/Valgrind.
Re: Don't Make Students Use Eclipse
#147> The issue is, as Kevlin Henney is fond of saying, “Software is nothing but the details.” When students don’t understand what a file is, or haven’t ever edited text in anything but Microsoft Word and don’t realize they can edit code outside of an IDE3, they will not be able to do the crucial work of self-directed learning that is a hallmark of all computer science success. Not sure why the aggressive comments here,…
An IDE is fine to hide programming related magic for a beginner, but if it needs to hide things like a filesystem, file extensions, navigating through advanced options in simple software like word and internet browsers, or how to use google to help diagnose technical issues, that person is in way over their heads.
Re: Don't Make Students Use Eclipse
#148I think that this is mixing up two different skills. The first skill is learning to program, and in particular learning to program data structures, or algorithms, or whatever. For this you don't care at all how your code builds, you care about correctness and easy to use testing infrastructure, and an IDE like IntelliJ or Eclipse is going to be almost frictionless for that. Teaching command line necessities together…
This is absolutely spot on. I used IDE Good/IDE Bad mostly as a way to get people to think about this, and clearly it worked :)
Re: Don't Make Students Use Eclipse
#149I agree that the file system is not emphasized enough anymore, and I've met a fair share of students who struggle with file paths. Also, in the last section: > or UC Berkeley (oh, I’m sorry, “Cal”) A bit off-topic, but as a Berkeley student, I was a bit amused/confused here, what's the sarcasm in the parenthetical about? According to our official branding guidelines[1] both are acceptable, though Cal is mostly used i…
Mostly a dig at the UCB faculty and admin, who act like they're better than the rest of the UC. (I'm a UCSD brat.)
Re: Don't Make Students Use Eclipse
#150Earlier quoted context omitted.
IDEs are convenience layers, compilers are essential abstractions - if you don't know how it works underneath the GUI layer you will get stuck really fast and won't be able to troubleshoot when you eventually run in to inevitable problems with IDE, build, compiler.
What makes the CLI interface to the compiler more essential of an abstraction than a GUI interface to the compiler? Just that it is simpler, or that it's been around for longer? A GUI isn't necessarily just calling CLI apps in the background, it could be using programmatic interfaces too.
Build and CI systems don't go through a GUI IDE, making it required for developers to understand the CLI anyway.