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.
I carry this thought process over into my current life. When I start with a new technology/language/etc. I try to start barebones command line, text editor.
I transition quickly into more visual / abstracting tools, but that first foray into the guts really helps ground me with a better understanding of what's actually happening.
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"
I was referring to the second part of his post. Also this class is not introduction to programming it is upper division and considered one of tougher classes in terms of workload.
The assignments aren't trivial. Take look at them:
I agree. The intro class should use whatever IDE & config will most enable them to teach the fundamentals.
Understanding the details of packages and javac and other things should be left for a later class which can put them in the context of other languages.
Oh I had a very interesting class in eng. school about programming languages paradigms. About subtle differences between different implementations of the same concept. Ada, C++, Java, C# (could've gone to functional languages but the lesson was painful enough with these 4). Type-erasure, explicit/implicit/partial template instantiation, visibility rules. And then design patterns, in all those languages. How a singleton makes no sense in a language that's not 'full' object and has 'packages' (not the java ones), how GC/RAII/controlled-types change the patterns. It was both a course on 'using language concepts correctly, picking them carefully for a specific need and not 'to avoid writing 3 more lines of code' and also a lesson in 'how can you paint yourself in a corner and prevent yourself from handling the simplest of requirements change'...
Very interesting to see how our mind is shaped by the tools we use.
My small liberal arts school has this as well. It's a great idea but, at least for me, it was hamstrung by the professors being too reliant on their IDEs.
I can see the merit of this, but as an anecdotal counterpoint my first programming class was Fortran 77 using gedit (in the late 2000s). The delayed feedback of whitespace and syntax errors at compile time was painful, slowed down my learning process and distracted from the principles we should have been learning.
University programs exist to prepare workers for the industry, as a general goal. A subset of students are either already hardcore or will become hardcore developers, cum computer scientists. How should a university 'optimize' their pedagogical approach so that all students are maximally rewarded by their education?
There is no question in my mind that you are correct, in principle. But I wonder if what you propose would in fact result in higher attrition rates. With the current approach, the majority benefit from an IDE that reduces the 'cognitive surface' of the "programming environment", and for those who prefer or gravitate towards the underlying layers, no one will prevent them from firing up e.g. Vim and maven.
That said, yes, don't make students use Eclipse. Make them use IDEA or VS something. /g
It is in my country. We routinely attend jobs fairs put on by their CS departments alongside every other software dev firm, we take on interns in their 2nd CS year, etc. etc.
Hell, they're even learning version control (mainly Git, some SVN) in CS degrees now, which was a nice change to see start coming through in the grads we interview.
Although we're seeing universities now start offering Engineering degrees in software with a far more "real-world" requirement including mandatory internships and an industry sponsored research project.
University programs as I know them prepare the enrolled for a career in science and are typically far removed from concerns of practicability or applicability.
Not hugely, although the current Labour led coalition is trying to make them more widely used. They used to be common place, I'm not really sure what happened.
And even then, we only have them for the trades - plumbers, sparkies, joiners etc.
That sounds wonderful! A real overview of the programming landscape, and definitely a good start assuming they follow my other points as well. I'd love to take that course.
As someone who started with C and then made a really hard effort to become an expert C programmer, when later in life I was introduced to Smalltalk and Lisp, I was angry that C had warped my brain and I could only think of programming in the context of a physical machine. I feel it would have been much better to go in the opposite direction.
> ... 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. Case in point: back in high school, I learned C++ using a Borland compiler (and I haven't touched `bcc` in the 15 years since then, even though I've written plenty of C++ in the meantime).
> ... imports and file naming requirements.
These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
> And of course, mathematics is the foundation of computer science.
Stuff like this can be misleading and even though not completely wrong (discrete math, logic, metalogic, mathematical logic are sorta' kinda' similar), it's just wrong enough[1] to lead people astray.
it's a regular issue, the more layers between the actual tool (JVM) the less you will need to master, but at the same time the first thing you'll learn is to forget how to use javac or any compiler and just import projects configs or let tools infer stuff for you.
In my personal case, knowing about classpaths the hard way was my only path to salvation. Otherwise I was blindly tweaking IDEs project configs without any idea what was happening.
The point of the article is the very concept that the compiler and the Java runtime environment are not the same thing (which an IDE obfuscates to some extent) is what he wants students to learn early on. (And details like that). This leads into a lot of important concepts around how programming languages are seen by the computer.
> ... how programming languages are seen by the computer
Learning a programming language has nothing to do with how it's seen by a computer. That's a different class (a class on compilers, maybe). You can even turn Java into Javascript if you want to[1]. The fact that the compilation/transpilation flow here is Java -> Java Bytecode -> JS is meaningless in the context of learning Java.
But learning Java is only useful in the context of programming computers, for which you need to know practical things like files and compilers, which I think is the point of the article.
>Learning a programming language has nothing to do with how it's seen by a computer.
Learning the syntax of a progaming language might not have much to do with how it's seen by a computer but it's important if you want to learn how to use a language properly. If you don't know how Java(or any language) works fundamentally, the code you write may work, but it'll likely be more inefficient both in terms of program and programmer speed.
Debugging sessions will be more frustrating and take longer and generally the quality of the programs you write will be lower compared to programs written with a language's quirks and peculiarities taken into account. Which you learn by understanding how a language works.
I'm not saying they should be able to write a Java compiler or interpreter, but they should have a decent idea how they work at least fundamentally.
It's harder to learn this when it all happens at the push of a button and you never learn to appreciate that button because you've never had to do it yourself and if something goes wrong with that button for some reason, you won't understand how to fix it or work around it.
You have completely missed the author's point. The issue is not "how can we help students learn to code" the issue is "how can we help students understand the systems that they are coding on since that affects how they code"
Knowing Java runs in a VM very much affects how you have to code. Sure, when you are learning in a 100/200 level class it doesn't, but by the time you graduate if you don't understand the implications, that is bad. Why not make a very simple change early on that gives context for students later on? We shouldn't be teaching students that Java runs in a virtual machine in a 200/300 level class, by that time we should have moved on to why that matters.
Forcing students to continually use java/javac will make them start learning the concepts on how a computer actually processes their program. It makes them think a bit more about it and the concepts are not foreign when they learn it in a full class. The IDE just turns the whole process into a single button with little context.
It is a way better way of learning the concept through practice, rather than having students memorize it for a multiple choice section on an exam, then forget it.
A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn't know any tooling. They couldn't compile, run, test, or source control their code if the professor didn't set it up for them.
Yes, tools change, but the knowledge from one tool is almost always transferable. Once you're comfortable on the CLI and understand the concept that Java source is compiled to bytecode and then run on a VM, it's easy to switch to a new compiler.
If you only want to know the absolute bare minimum, go to a boot camp. People go to college to learn, and being comfortable with tools is an essential part of being a developer that students need to learn.
In particular, command line compilers have been used virtually the same way since the first command line interfaces, so knowledge of javac is definitely transferable.
I agree that many developers are not very adept with tooling, but is that because they don't use the CLI? Or is it just that they aren't interested in those parts of software engineering? Eclipse is a tool too, and not a simple one either.
The author is specifically talking about students. The emphasis at this stage plays a key role in whether they'll have that interest or not. Knowing is a prerequisite to developing interest.
GUI tooling almost entirely uses the command line layers under the hood, so it is strictly more complicated while hiding more of the real process - the worst of both worlds.
My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).
EGit doesn't call the git command line application, it uses a Java implementation of git. Although I can agree it's debatable whether they have improved on the command line interface or not.
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.
> 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
It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.
The CLI is more explicit than a GUI. In a GUI, compiling / running / testing your code is an afterthought that happens at the click of a button.
In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it.
The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.
I don't see the distinction. I started my career using command line tools and am completely comfortable with them. Yet for more recent projects I stay within the IDE (usually Visual Studio).
It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover.
It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.
It could be - but in the majority of cases it isn't - and you will need to fall back to CLI and UNIX abstraction layers when the IDE breaks - because that's the way it's been done since forever and if you want to work with existing (and probably future) tooling and be able to solve the problems when they happen in the layer above you will need to learn the interface used to expose all the functionality to the tools under the hood.
> It could be - but in the majority of cases it isn't
I don't think that's really true, at least for the Java ecosystem which is implicated here. Eclipse does not call out to command line tools for most things, as far as I've seen
Agreed. The least effective developers I’ve had the displeasure of working with never understand how their code executes end-to-end. And the best ones have a deep knowledge of it.
This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge.
More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it.
(And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)
eh, I understand the sentiment - but it's a little overkill. Junior programmers can be code reviewed and taught these things over time, and also be wildly productive in a production setting.
Sure you can teach junior programmers all kinds of stuff that they should have already learned or should know how to learn, I do it all the time. I'm arguing that this is crucial information that even entry-level engineers should know. If they don't, then I give them a link to the relevant documentation and politely ask them to read it. It's a prerequisite.
Are there any books or articles that go through the things that you’ve mentioned like how the class loader works etc? Most of the tutorials or books I have seen do not even touch this aspect and I want to get better at it.
Oracle documentations typically. And javadoc for those classes.
But I don't think it is such a key to anything. It is sort of stuff that is easy to learn when you need it, easy to forget and not useful most of time. It makes sense to read when you done learning other things, but not for beginners.
I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.
I haven’t taken an introductory CS course since the mid 90s, so I don’t have enough knowledge to know whether I agree or disagree with you. What was the base level of knowledge like when you were in introductory courses? Back in the day, you couldn’t guarantee that everyone could even turn a computer on, so for loops were a second midterm thing.
Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)
Isn't eclipse a piece of tooling? I mean I think the best argument against teaching eclipse is IntelliJ is much better, imo, and is more widespread than eclipse at this point. Student should have a module/class whatever about command line tools as well. I this comparison is comparing two things that aren't comparable, an IDE vs learning the CLI. I also think you contradict yourself in your last sentence. Teaching an IDE in class should help people be comfortable with their tools but at some point they might need to know what the tool is doing under the hood.
> but at some point they might need to know what the tool is doing under the hood.
The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE.
However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.
I haven't really played around with java since the 90's, and I bought a Java book and tried hopping back in. It was really frustrating because the book uses 8 and I downloaded 9 and Eclipse was slightly diffferent, something with modules blah blah.
Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...
> 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.
Eh, javac is the reference implementation and the language specification makes several references to it, it's also by far the most widely used. It's also good to understand what goes on behind the scenes in your IDE because the IDE is even more removed from the language than the compiler. C++ is somewhat different because it does not have a reference implementation and has a somewhat more diverse set of implementations. Though I think it's still very useful know your way around the gcc or clang command line.
> These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
Imports and naming are not implementation details... they are defined in the specification.
As a former student who had to use eclipse, I think the ide dramatically slowed my understanding of what was actuay happening in my projects. A command line and a few commands however really makes things simple and clear.
The only thing you need an ide for is autocomplete and refactoring, and in a small project like you have in school, it’s simpler to use a text editor imho and you can fully understand your project that way too
The thing is, early in their study, students are learning that compilers exist at the same time that they are learning a language. They should become familiar with a compiler, and in the case of Java that it generates class files, that they pass them to a JVM, to inform them of the state of the art of tooling architecture, or even to help them imagine that they could change some pieces or swap them out.
Using the tools directly serves to re-enforce all these concepts.
They can get to know other tools for that same language like in your Borland example, sure. But if you didn't know the compiler existed, you would be in trouble. And in C you will also want to understand the preprocessor and linker.
I think there's great value in learning to use a lightweight editor, a compiler or interpreter, the command line, etc.
I also think that Java is perhaps the worst possible choice for that.
It's a language created with the "build once run anyway" mentality that tries to abstract away the system, it's the poster child of languages married to an IDE, and verbose to the point that forcing people to write java code without autocompletion features probably violates the Geneva convention.
At this point in time if you want your students to learn about tooling it would be more useful to teach them to use chrome's JavaScript console than to teach them to use a Java compiler through the command line.
>verbose to the point that forcing people to write java code without autocompletion features probably violates the Geneva convention.
I'm happy to use just emacs. The naming conventions make it easy enough to remember. I've never been a fan of heavy IDEs. Maybe that is just me as a solo developer/entrepreneur, but I don't think that I am the only one.
Once you decouple yourself from the IDE and all of the bloated enterprizey (ahem spring) frameworks, it is actually pleasant to work with. Most of that stuff is superfluous when you have a command of the environment.
I think there's a bit of personal preference. As a student I hated IDEs, because I couldn't tell what was actually happening. To this day, I avoid using and IDE or other tool for git/version control, because I can't tell what it is doing.
There's more typing with a text editor and javac, but it's much simpler to understand IMHO.
All of this must be understood in the context of first year programming. For my class, there were no libraries that one needed, and at most 10 or so java files to compile. The classpath would never need to be more than the working directory.
I thought it was obvious that the author means javac as a stand-in for the general idea of compiling and running code from the command line rather than having an IDE do everything for you. Her arguments apply to any Java compiler.
Once students finally graduate they might be unlucky enough to land a job as a Java developer. Here they will live and breathe continuous integration where its essential to write build scripts that can be exported to other environments, and the only way to do this is to use command line recipes.
If there is one thing that Eclipse doesn't do is insulate anyone. Half of Java Enterprise development involves various concoctions of Eclipse projects.
I'm not sure what the difference is between a student learning about Eclipse idiosyncrasies or .DS_STORE files. One topic is as pointless as the other.
I like the idea of starting in a browser. It is a more familiar way to get people used to the concept of text controlling behavior. The jump to compilation and executables might still be difficult, but it’s way better than students on their second year who only know how to run their programs by clicking a green triangle.
Harvard's CS50 does a great job at this. My first intro to CS was through this course, and I'm grateful I did it this way rather than wait till I was taught in the "broken" way at college.
I 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 in athletic contexts.
I tend to agree, but I wonder how many in the "IDE bad" camp would agree that in order to obtain your drivers license, you must pass the drivers test on a manual transmission?
Since I got my driver's license over a decade ago, I've had to parallel-park less than ten times. I've probably changed a flat tire more often.
I think you would find that the vast majority of drivers in the US don't parallel park even once per year. Furthermore, an increasing fraction of new cars can park automatically.
The chief value of having a road test, in my mind, is to force most teens to learn to drive in a structured program that introduces rules of the road and safe habits. Parallel parking is rare and not dangerous, so we shouldn't waste the limited hours that teens spend with professional driving educators on it.
> I think you would find that the vast majority of drivers in the US don't parallel park even once per year.
In the UK, I had the exact opposite experience. Immediately after passing my test, I was parallel parking daily, and I've frequently been in situations where parallel parking is the only way to find a parking space. IMO it _would_ have been dangerous had I not learnt how to do it and was confident doing it. I'd have likely have been too distracted thinking about what I'm trying to do rather than paying sufficient attention to my surroundings. I know I was when I was first learning, and I failed my first driving test because I didn't adequately check my surroundings before starting to reverse.
Why? I would expect manual drives to diminish in popularity over time. It's harder to use, and does not give any benefits at all, other than a slightly cheaper price, and a slightly higher performance if the user is knowledgeable.
An auto transmission is so much better in every respect, and the performance improvements in manual hardly comes into play during every day use.
I consider the ability to use manual transmission vehicles, of which there are many, a benefit. Last year I visited my aunt for a week and traveled around the state with her in her car. I couldn't share in the driving, because she has a manual transmission.
At least here in Sweden, manual and automatic transmissions have different driver's licenses, a manual license lets you drive both. Since getting the license is pretty expensive to begin with (with no difference between the two), people tend to prefer getting the manual one.
I think it might be more fair to say the "IDE bad" camp is comparable to folks that would say you shouldn't be able to press the "auto parallel park" button on your smart car to pass that part of the test.
Well, considering being able to parallel park is a really insignificant part of being a good driver, and the biggest complaint I hear on the internet is people apparently not knowing where the turn signal is on their car, perhaps people should be required to know more about the buttons on their car.
Agreed! I can't think of many professional trades where you aren't required to know certain fundamentals just because there are higher level tools available. A trained cabinetry carpenter, for example, likely knows how to make a fancy cabinet door without a CNC router, even if that's how they mostly do their work. I'd venture a guess that statisticians could calculate variance, t-score, f-score, z-score, etc by hand.
I'm not saying you can't be a productive professional without knowing lower-level fundamentals, though I don't think you legitimately lay claim to be an expert in the field without them.
How much of a difference does learning on a manual actually make? I learnt in the UK, where it's the norm to learn in a manual, and I know after about 5 lessons, it's not really something I thought about. It became habitual very quickly (other than _occasionally_ on steep hills, which took a few lessons longer), and it's something I picked up whilst learning other things anyway.
I'm not sure I agree much with this. When I first started learning Java I had six or seven years of programming experience and I still found dealing with matters of classpath and javac remarkably complicated. I had things down well enough with the tools I used before, but it all seemed so foreign in the Java world.
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.
I'm all for folks learning these skills eventually, but in a first-year CS class I'd really rather students worry about the language and general concepts of writing software.
Lots of javascript tutorials start off with opening and browser's javascript console and typing out some simple stuff and I don't think people would tell them they need to jump straight into node.js and webpack.
All the other intricacies of writing systems will come to them but I find something uniquely wonderful about sitting and writing code, and if we're lucky we'll find students who can have that same experience. I'd rather meet them where they are and talk purely of the language and core concepts, and introduce them to the ugly details as their progress dictates.
Especially if it is their first experience writing code. Until a student learns to tolerate the discomfort of "the machine isn't doing what I want for some inscrutable reason", it makes no sense to throw them into package-management errors.
Actually I agree for the Java world here. Thanks to the design of Java and many Java libraries you cannot write a little more complex Java code from your mind. Even importing all this nested OOP libraries is complicated without an IDE. For me Java is really a language which is impossible or too time consuming to master without a good IDE.
Working for many years in the python world professionally some people are still amazed that I'm essentially using more or less a normal text editor. IDE is optional for many languages but for some languages it's a strong requirement.
When I was teaching myself to code I started writing Java in Notepad. Not Notepad++, just Notepad.
And it was as painful as you'd expect, put me right off Java (most of my learning was in Python), and didn't really teach me much that I now use as a developer in a JVM shop.
Java is special since the whole compile/link/run loop is relatively slow and there's no REPL. In Nodejs or python you are expected to just run your code. Any error like a bad import/require statement you can correct quickly and re-run. Maybe even add/remove print statements while at it. And it's not just dynamic languages! You can have the same experience in Haskell.
> 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” necessarily but at least to “I can create a project that will build without my specific IDE or needing to recite compiler arcana”.
Nobody in their right mind works without these things, and while knowledge isn’t going to directly transfer from one to the next you should at least have enough to know where to look in the documentation for “how do I specify dependencies”, “how do I tell it where to find my source”, etc.
For a first year course where you aren’t pulling in the kitchen sink the IDE project format works well enough, but if you’re entering the workforce you should know damn well how to create a basic project in the standard tools of your language of choice.
> 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).
Don't teach "industry standard tools" to a uni student learning CS.
I would not expect a new graduate to know maven, or know the intricacies of the spring framework. That's something to be learnt on the job. I expect them to be capable enough to learn this on the job - given that they're well versed in the theoretical aspect of computer science. It's easy to explain maven's core by telling them that it's a directed graph of dependencies.
A student that just learns the "industry standard tooling" should need a bootcamp, not uni degree.
>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.
What is the real world difference between "learning java" and "learning programming, theory of computing (and algorithms etc), using java as the language"?
Surely to learn all that shit (using java as the language) you at some point have to, you know, learn java?
Was about to reply to GP similarly, but after rereading it - I think they just expressed the sentiment badly. Note the single sentence they quoted in the reply - about teaching Maven.
Pretty sure they're reading "learn java" as "learn the language + the common build tools + more", instead of just the language, as we are.
Almost all beginners absolutely need to be taught the language first (so they have something concrete to mentally latch on to), not concepts and algorithms. However, Maven is not one of those things - either a GUI with a compile button or "javac" is sufficient at that level.
CS students should be learning those fundamentals by programming, and so they should be taught enough tooling to program without tripping over themselves all the time. Programming without a build system, a version control system, or a reasonably intelligent editor is unnecessarily difficult and gets in the way of the concepts being taught.
It’s also a pretty decent representation of stuff they will be expected to learn and deal with on the job. I can’t imagine programming without dependency/build tools, and yet I also often struggle with them. It seems dishonest and impractical to me to only focus on core concepts. Students should also be exposed to real life!
> Programming without a build system, a version control system, or a reasonably intelligent editor is unnecessarily difficult and gets in the way of the concepts being taught.
Programming with a build system, with a vcs and/or an editor with intellisense features will unnecessarily burden the student with learning these extra things. vanilla java, taught using a pure text editor (like pico, or notepad++, that has a simplistic syntax highlighting), and make sure the students type out their own imports, etc, is going to teach them more basics.
Until the day you need to build actual working software to ship to people, there's no need for a build system, and until they need to work in groups, there's no need for VCS. And until they start writing something _very_ complex, like a full game using many libraries, they don't need intellisense.
Most CS exercises fit in one class. And when it comes time to design something reasonably complex, the student would've learnt all the fundamentals (like 6 months in), and can move to using an IDE with little issue. And then when group projects come, the students can learn VCS as it makes group work simpler. But till then, showering the first year student with these tooling is just noise.
Compile errors due to misspelling and "what was that function called again?" expeditions are distractions. My department did us a great disservice by never even hinting to students (at any level) that tooling can make them go away. It was almost painful, working on group projects, to see my classmates struggling so hard just to move around the code. Being unable to seamlessly work your editor and navigate your codebase is just as crippling as hunt-and-peck typing. Is it worth a lecture? No. But a mention? Absolutely.
VCS is essential in a solo project of any real complexity because you will reach intermediate milestones, go off on tangents that don't pan out, and then desperately wish you had a way to get back to the working state you had hours previously. A true VCS with branching and merging is technically overpowered, since you could just make copies of the source for each "commit," but you may as well just use Git.
Build system is not about shipping to people, it's about running what you just wrote on your own machine when it's bigger than one unit of compilation (C file, Java class, whatever). You don't need anything fancy, can just be Make or a shell script, but building and running the whole project should take no more than a few keystrokes. Kids should be fumbling with GCC flags for maybe one assignment, not 4 years.
On the very first day of programming, all you need is a REPL. But once students are doing programming projects of nontrivial size, they should be invited to try incorporating the tools that make them manageable.
> Don't teach "industry standard tools" to a uni student learning CS.
This is the critical point. By the time a curriculum is in place around one set of "industry standard" tools, new tools will have come out, in a lot of fields (see, for instance, `npm` and `yarn`.)
> They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language.
I would argue that using Java as the language for introductory CS courses is not a good idea. We have better, simpler languages to teach foundational functional (Racket, Scheme) and imperative (Python) languages.
There's nothing wrong with Java in general, but if your goal is teaching "programming, and theory of computing (and algorithms etc)", there's nothing that Java can do that Python can't that helps with that goal.
In fact, I'd give my optimal progression of languages as starting with Python for basic imperative and OO programming, or Racket for basic functional programming, then switching to the other one, and then looking at Kotlin (or Java if you really must) for advanced OO programming and C (or, in a few years, maybe Rust) for systems programming.
> ...if you’re teaching C++ you should be teaching CMake.
I've been programming very advanced C++ for close to 20 years now.
Never had any reason to use CMake.
Plain old make for when you just want to build something without expending effort and brain cells, or (nowadays) nix if you're putting together an industrial-strength build environment.
CMake is the worst of all worlds, and provides no benefit unless you really want to build Windows exe's with Microsoft's proprietary tooling. (And let's face it, Windows is a legacy dying platform here in 2020.)
> I'm all for folks learning these skills eventually, but in a first-year CS class I'd really rather students worry about the language and general concepts of writing software.
This is a big part of why I recommend that another language should be used to teach introductory level courses. Java has too much additional complexity. That complexity has benefits in production, but not for first-year undergrads.
> I still found dealing with matters of classpath and javac remarkably complicated.
I started my programming career writing C and C++ using the cli and a text editor.
Some years later I ended doing some Java and to me I found it quite easy as I could see similarities with things I had learned writing C and C++.
I could see the classpath and jar files where roughly equivalent to the concept of libraries and libpath found in the C and C++ linker (only much easier to use) and the javac was roughly equivalent to the gcc or g++ command line compilers.
> Most importantly, though, it limits the ability of their peers to learn. If a 300-level software engineering class which budgeted a week to teach basic version control skills has to take a two-day detour to teach the Windows users how to get rid of the CRLFs in their commits, and teach the Mac users to remove the .DS_Store files from their repositories, and get everyone set up in Eclipse EGIT, that’s wasted time. If the professor has to schedule time with students outside of class to demonstrate their code because so many students aren’t able to submit their code in a form that successfully runs on the professor’s computer, that’s wasted time for both professors and students, and it undermines important lessons about portability and good practices.
This is might be an argument against a particular IDE setup for a class, but it isn't an argument against IDEs in general. Instead it is an argument for providing a config file to make these problems go away.
> When students have only ever programmed in Java using some bespoke learning library provided by their professor, it will take them much longer than necessary to figure out other languages, other libraries, and other approaches.
The article doesn't support the case that an intro class using an IDE prevents students from learning anything else. The class doesn't set people back--it merely fails to move them forward in that way. I agree that it is important to teach this eventually. But it should be through teaching it deliberately. (EDIT: Someone else posted a link to a class which compares different languages and their tooling side-by-side. That sounds fantastic.)
I have yet to see a class which can do a good job of teaching how package management works to a degree that the student can then confidently debug weird setuptools errors.
Defering learning of implementation details is virtuous and on the plus side, intellij IDEs have state of the art static analysis that show to the coder anti patterns and help it rewrite them in a cleaner way, and with an explanation.
Autocompletion and integrated documentation do increase discoverability and learning of the language, not the reverse.
Yeah I found Eclipse a pain to set up for python the first time I tried. Kept throwing weird Java errors and GUI glitches. Abandoned that plan very fast
People who learn the tool alone are substantially unhireable.
When you hire a developer you usually need them to also be at least be something of an expert computer user, especially if they're going to be working on a small team without 20 other experts to micromanage them.
Over-reliance on the IDEs leaves people appliance operators that are lost when there isn't a magic button to press.
It isn't just an issue in the job market. "Programmers" who aren't sufficiently advanced computer users can't advance their own projects in academia either-- they're stuck working on precooked assignments. I suspect this is one of the forces that has resulted in academic research being utterly starved for competent software engineering (though the main one remains that competent software engineers can get stable high paying jobs, and academia provides them with neither).
Always good to get students to dig deeper, even if it's for their initial 1st/2nd semester, and especially if they're going to be programming long term. But ofc let them have the freedom to choose afterwards.
I guess the sentiment is more like "Don't make students start programming in IDEs first"
I get it. It shields them from understanding what's happening underneath. But not everybody is interested or needs to know all the things happening underneath, and its okay. If they're going to learn the whole stack, they will.
Even for someone who is interested in knowing what happens underneath. To succeed at actions, it important not to expand the scope of what you're trying to do too broadly.
I agree, and it has been going on for a very long time. I have coworkers who's productivity (if you can call it that) would slide to zero if you took away Eclipse. If it isn't implemented in an Eclipse plugin, well forget it. Setting up the deployment environment is so far outside of their capability as to be a joke. And these people have been out of college for over a decade.
This 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.
I had the opposite experience. My university decided that they would standardize student development environments on vanilla Visual Studio, put everything that students would ever want into a single header (i swear it was something like "header.h") that you copy/pasted into your project folder and that was it. We didn't even use the terminal.
It was tedious as hell to learn everything else in real world development, like static versus dynamic linking, include/linker paths, make, system libraries, and so on. Like as in myself nor my classmates would have any idea those things existed after two semesters of C++ programming courses.
The moral here is that education needs a degree of breadth. Teaching CS students involves three concepts - Computer Science, Writing Code, and Writing Software. The dependency graph between those topics on what knowledge and tools are needed contains cycles.
I'm sorry you had that experience, but you'll note that this isn't what I'm actually suggesting; my suggestion is Python or another dynamic language on any platform so long as it's standardized and accessible, for which I give the example of Ubuntu, but I also mention that Windows with Powershell is an option.
> What they can’t do, unless they’ve figured it out on their own, is operate a computer outside of the confines of the IDE they’ve been taught.
Understanding what a file is and what a text editor should be prerequisites for entering a computer science department. Someone who doesn't understand these concepts has no business learning to program.
At my "not MIT" school, it was expected that most incoming CS students understood some basic programming before they entered school.
A CD department that tolerates students who don't know what a file is probably has other problems.
That excludes a huge number of students who will have never had the experience to try programming before university.
I never did any programming before my first year, I was planning on going into economics. But then I took an elective in CS and it became my major. I wasn’t alone either, most of the students were not programmers previously.
> At my "not MIT" school, it was expected that most incoming CS students understood some basic programming before they entered school.
At Cambridge (UK), this is _not_ the case. They merely note that "some knowledge of procedural programming is useful"[1] and "[n]o prior knowledge of programming is required"[2]. The main thing they are looking for, in terms of qualifications, is mathematics, so you'd typically see an A-level in mathematics plus two further ones in further mathematics, the physical sciences, or computing depending on what your school offers.
At interview (for two colleges), I was not asked about programming - the first was purely mathematics based, and the second was primarily maths based with some CS concepts introduced to see how you thought about and were able to manipulate the information given in the interview. It's not something you were necessarily expected to know.
Until this year, the introductory CS modules (making up 25% of the first year's content) were available to natural sciences students, so you would have students from a fairly wide range of backgrounds _successfully_ learning CS and to program (the maths modules, also making up 25%, are still shared, for what it's worth).
>Using Java or Python in a professional IDE like IntelliJ IDEA, NetBeans, PyCharm, or Eclipse is not a good first introduction to programming for computer science students, whether they’re in the field to become web developers, systems software engineers, or academic computer science researchers. //
So "for computer science students".
Which seems like too major a thing to miss out of the title.
Also, how does webdev fit in here: seems like webdevs should probably be using IDEs from lesson 2. And I say that as someone who started their web content production path writing HTML in pico.
The author brings this up as a reason for using an IDE:
> This is valuable in an introductory course, as it avoids wasting class time and lowers the barrier to entry
and then proceeds to argue why other things are more important than that.
I don't like Eclipse or other IDEs, having watched my fellow students get stymied by basic issues that I could resolve with one or two relatively simple instructions on the command line. I think IDEs can be a crutch that programmers ought to learn to do without. Learning what the "real" tools are will pay dividends—quickly too.
That being said, I think it's important that the barrier to entry be low. Java almost necessitates the use of an IDE. There's so much "enterprise" cruft involved in doing the simplest things that, unless you have an IDE to hide it, you're going to confuse beginners.
A better choice of language and tooling can help here. I think starting off with something like Racket would be best. Those who need an IDE (out of laziness, familiarity, whatever) can use DrRacket, and then switch to running their programs from the command line shortly thereafter with next to no transition overhead.
i agree with everyone saying you shouldnt use IDE as a crutch.. but as a seasoned Java dev, it is probably my main exception to the rule as well. I would just recommend intellij over eclipse for beginners, but its better than nothing.
I agree with sentiment of this. I meet a lot of developers that cannot function outside of the IDE (in my case Visual Studio). As a consequence they struggle when the IDE fails.
> 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, but I agree with this. IDE for learning programming ends up shielding you from reality that you should probably understand before you use an IDE.
People who don't know what a file is need to take a computer literacy class before they can jump into something like programming.
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.
254 comments
[ 4.9 ms ] story [ 248 ms ] threadI transition quickly into more visual / abstracting tools, but that first foray into the guts really helps ground me with a better understanding of what's actually happening.
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.
"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"
The assignments aren't trivial. Take look at them:
http://web.cs.ucla.edu/classes/spring20/cs131/homework.html
Understanding the details of packages and javac and other things should be left for a later class which can put them in the context of other languages.
Very interesting to see how our mind is shaped by the tools we use.
There is no question in my mind that you are correct, in principle. But I wonder if what you propose would in fact result in higher attrition rates. With the current approach, the majority benefit from an IDE that reduces the 'cognitive surface' of the "programming environment", and for those who prefer or gravitate towards the underlying layers, no one will prevent them from firing up e.g. Vim and maven.
That said, yes, don't make students use Eclipse. Make them use IDEA or VS something. /g
I don't think that it's true that the general goal of University of CS programs is to prepare students for the software dev industry.
Hell, they're even learning version control (mainly Git, some SVN) in CS degrees now, which was a nice change to see start coming through in the grads we interview.
Although we're seeing universities now start offering Engineering degrees in software with a far more "real-world" requirement including mandatory internships and an industry sponsored research project.
University programs as I know them prepare the enrolled for a career in science and are typically far removed from concerns of practicability or applicability.
And even then, we only have them for the trades - plumbers, sparkies, joiners etc.
- C
- Python (+ Flask)
- JavaScript
- SQL
I think this was the order. They learn C the most.
she[0], but yeah.
[0]: https://twitter.com/noradotcodes
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. Case in point: back in high school, I learned C++ using a Borland compiler (and I haven't touched `bcc` in the 15 years since then, even though I've written plenty of C++ in the meantime).
> ... imports and file naming requirements.
These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
> And of course, mathematics is the foundation of computer science.
Stuff like this can be misleading and even though not completely wrong (discrete math, logic, metalogic, mathematical logic are sorta' kinda' similar), it's just wrong enough[1] to lead people astray.
[1] https://www.scott-a-s.com/cs-is-not-math/
In my personal case, knowing about classpaths the hard way was my only path to salvation. Otherwise I was blindly tweaking IDEs project configs without any idea what was happening.
Learning a programming language has nothing to do with how it's seen by a computer. That's a different class (a class on compilers, maybe). You can even turn Java into Javascript if you want to[1]. The fact that the compilation/transpilation flow here is Java -> Java Bytecode -> JS is meaningless in the context of learning Java.
[1] https://github.com/google/j2cl
Learning the syntax of a progaming language might not have much to do with how it's seen by a computer but it's important if you want to learn how to use a language properly. If you don't know how Java(or any language) works fundamentally, the code you write may work, but it'll likely be more inefficient both in terms of program and programmer speed.
Debugging sessions will be more frustrating and take longer and generally the quality of the programs you write will be lower compared to programs written with a language's quirks and peculiarities taken into account. Which you learn by understanding how a language works.
I'm not saying they should be able to write a Java compiler or interpreter, but they should have a decent idea how they work at least fundamentally.
It's harder to learn this when it all happens at the push of a button and you never learn to appreciate that button because you've never had to do it yourself and if something goes wrong with that button for some reason, you won't understand how to fix it or work around it.
Knowing Java runs in a VM very much affects how you have to code. Sure, when you are learning in a 100/200 level class it doesn't, but by the time you graduate if you don't understand the implications, that is bad. Why not make a very simple change early on that gives context for students later on? We shouldn't be teaching students that Java runs in a virtual machine in a 200/300 level class, by that time we should have moved on to why that matters.
Forcing students to continually use java/javac will make them start learning the concepts on how a computer actually processes their program. It makes them think a bit more about it and the concepts are not foreign when they learn it in a full class. The IDE just turns the whole process into a single button with little context.
The author, Leonora Tindall, is a woman.
A lot of my peers in college were very bright and could write great code, but they were absolutely useless as developers because they didn't know any tooling. They couldn't compile, run, test, or source control their code if the professor didn't set it up for them.
Yes, tools change, but the knowledge from one tool is almost always transferable. Once you're comfortable on the CLI and understand the concept that Java source is compiled to bytecode and then run on a VM, it's easy to switch to a new compiler.
If you only want to know the absolute bare minimum, go to a boot camp. People go to college to learn, and being comfortable with tools is an essential part of being a developer that students need to learn.
being a useless developer doesn't make it not computer science. not all of computer science is software development.
IDEs change more frequently.
My point about Git is an example of this. Teaching Git is hard, partly because Git's command line UX is bad, but layering the complexity of, e.g., EGIT on top doesn't really remove most of that and makes it harder to teach (because expressing what to do in a GUI is strictly harder than communicating text commands, among other things).
It's not simpler! It's way more confusing to figure out that your make file told your compiler to run a command with some unknown set of obscure options that are causing an error than to just have the IDE pop a dialog and tell you in plain words, or better, not even let you set an option incorrectly in the first place.
In the CLI, you have to be explicit about what actions are taking place. You have to physically type in what command you want to run and the different arguments to it.
The convenience of a GUI is fantastic, but the abstraction makes it a very bad learning tool. Being able to open up a terminal and fix the inevitable git / build / configuration errors is a very valuable skill that developers should have.
It doesn't matter whether I tick a checkbox for compiler warnings or add that option to the command line. The only difference is the IDE makes options easier to discover.
It's the same for Git. A decent GUI gives you a much better visual picture of the state of your working copy.
Build and CI systems don't go through a GUI IDE, making it required for developers to understand the CLI anyway.
I don't think that's really true, at least for the Java ecosystem which is implicated here. Eclipse does not call out to command line tools for most things, as far as I've seen
This is no fluke! If you don’t know how a classloader works with the Java classpath, how to set various JVM flags for operating the JVM, etc., then I’d argue that you’re an amateur, and I wouldn’t trust you to write correct code in a production setting. It’s critical knowledge to know how your code runs, and if you don’t know that, then stay away from production systems. If the goal of these courses is to teach students enough about Java to use it in a professional setting, then knowing how classfiles are produced, bundled, distributed, loaded, and executed by a JVM is critical knowledge.
More succinctly, if you don’t know how your code makes it to a production server and gets executed, you’re not ready to work on it.
(And if the goal isn't to teach students how to use Java in a professional setting, then why are they learning it at all? Use a teaching language so students can focus on the concepts instead of Java's idiosyncracies.)
But I don't think it is such a key to anything. It is sort of stuff that is easy to learn when you need it, easy to forget and not useful most of time. It makes sense to read when you done learning other things, but not for beginners.
I’d agree that some focus on that in CS programs would extremely valuable. Maybe things are better now, but when I went in 2008-2012 git wasn’t even mentioned and basically all tooling was learned on your own.
Edit - I should mention that my last sentence was the perspective of 18 year old me. I was 18, but in my defence I was 18. :)
The problem is the IDE makes it so easy to never have to look under the hood, to the point when people take a peek the get overwhelmed and quickly return to the comfort of the IDE.
However, in real world of production environments there will be no IDE holding your hand and as such you can't get away without a good understanding of the engine under the hood.
In real world, you always use tools and in real java world there is always ide or application server or something.
Plus downloading the actual Java SDK was confusing, the versioning, it not being free anymore...
> These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
In Java, these are language details. You cannot write Java without following them.
Eh, javac is the reference implementation and the language specification makes several references to it, it's also by far the most widely used. It's also good to understand what goes on behind the scenes in your IDE because the IDE is even more removed from the language than the compiler. C++ is somewhat different because it does not have a reference implementation and has a somewhat more diverse set of implementations. Though I think it's still very useful know your way around the gcc or clang command line.
> These, again, are (compiler) implementation details and should not be part of a generalized Java curriculum.
Imports and naming are not implementation details... they are defined in the specification.
The only thing you need an ide for is autocomplete and refactoring, and in a small project like you have in school, it’s simpler to use a text editor imho and you can fully understand your project that way too
Using the tools directly serves to re-enforce all these concepts.
They can get to know other tools for that same language like in your Borland example, sure. But if you didn't know the compiler existed, you would be in trouble. And in C you will also want to understand the preprocessor and linker.
I also think that Java is perhaps the worst possible choice for that.
It's a language created with the "build once run anyway" mentality that tries to abstract away the system, it's the poster child of languages married to an IDE, and verbose to the point that forcing people to write java code without autocompletion features probably violates the Geneva convention.
At this point in time if you want your students to learn about tooling it would be more useful to teach them to use chrome's JavaScript console than to teach them to use a Java compiler through the command line.
I'm happy to use just emacs. The naming conventions make it easy enough to remember. I've never been a fan of heavy IDEs. Maybe that is just me as a solo developer/entrepreneur, but I don't think that I am the only one.
Once you decouple yourself from the IDE and all of the bloated enterprizey (ahem spring) frameworks, it is actually pleasant to work with. Most of that stuff is superfluous when you have a command of the environment.
There's more typing with a text editor and javac, but it's much simpler to understand IMHO.
All of this must be understood in the context of first year programming. For my class, there were no libraries that one needed, and at most 10 or so java files to compile. The classpath would never need to be more than the working directory.
http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...
I'm not sure what the difference is between a student learning about Eclipse idiosyncrasies or .DS_STORE files. One topic is as pointless as the other.
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 in athletic contexts.
[1] pg34-35, https://brand.berkeley.edu/wp-content/uploads/2019/07/Berkel...
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.)
U.S. drivers licenses are too easy to get as it is... I don't think my sister even had to parallel park on hers.
I think you would find that the vast majority of drivers in the US don't parallel park even once per year. Furthermore, an increasing fraction of new cars can park automatically.
The chief value of having a road test, in my mind, is to force most teens to learn to drive in a structured program that introduces rules of the road and safe habits. Parallel parking is rare and not dangerous, so we shouldn't waste the limited hours that teens spend with professional driving educators on it.
In the UK, I had the exact opposite experience. Immediately after passing my test, I was parallel parking daily, and I've frequently been in situations where parallel parking is the only way to find a parking space. IMO it _would_ have been dangerous had I not learnt how to do it and was confident doing it. I'd have likely have been too distracted thinking about what I'm trying to do rather than paying sufficient attention to my surroundings. I know I was when I was first learning, and I failed my first driving test because I didn't adequately check my surroundings before starting to reverse.
An auto transmission is so much better in every respect, and the performance improvements in manual hardly comes into play during every day use.
I consider the ability to use manual transmission vehicles, of which there are many, a benefit. Last year I visited my aunt for a week and traveled around the state with her in her car. I couldn't share in the driving, because she has a manual transmission.
I'm not saying you can't be a productive professional without knowing lower-level fundamentals, though I don't think you legitimately lay claim to be an expert in the field without them.
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.
I'm all for folks learning these skills eventually, but in a first-year CS class I'd really rather students worry about the language and general concepts of writing software.
Lots of javascript tutorials start off with opening and browser's javascript console and typing out some simple stuff and I don't think people would tell them they need to jump straight into node.js and webpack.
All the other intricacies of writing systems will come to them but I find something uniquely wonderful about sitting and writing code, and if we're lucky we'll find students who can have that same experience. I'd rather meet them where they are and talk purely of the language and core concepts, and introduce them to the ugly details as their progress dictates.
Especially if it is their first experience writing code. Until a student learns to tolerate the discomfort of "the machine isn't doing what I want for some inscrutable reason", it makes no sense to throw them into package-management errors.
Working for many years in the python world professionally some people are still amazed that I'm essentially using more or less a normal text editor. IDE is optional for many languages but for some languages it's a strong requirement.
And it was as painful as you'd expect, put me right off Java (most of my learning was in Python), and didn't really teach me much that I now use as a developer in a JVM shop.
For other languages, e.g. go, which i currently like, I don't use an IDE because I don't feel like I need one.
In my opinion IDEs are often just a crutch for bad languages and I can understand the sentiment in the article, but yeah, java.
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” necessarily but at least to “I can create a project that will build without my specific IDE or needing to recite compiler arcana”.
Nobody in their right mind works without these things, and while knowledge isn’t going to directly transfer from one to the next you should at least have enough to know where to look in the documentation for “how do I specify dependencies”, “how do I tell it where to find my source”, etc.
For a first year course where you aren’t pulling in the kitchen sink the IDE project format works well enough, but if you’re entering the workforce you should know damn well how to create a basic project in the standard tools of your language of choice.
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).
Don't teach "industry standard tools" to a uni student learning CS.
I would not expect a new graduate to know maven, or know the intricacies of the spring framework. That's something to be learnt on the job. I expect them to be capable enough to learn this on the job - given that they're well versed in the theoretical aspect of computer science. It's easy to explain maven's core by telling them that it's a directed graph of dependencies.
A student that just learns the "industry standard tooling" should need a bootcamp, not uni degree.
What is the real world difference between "learning java" and "learning programming, theory of computing (and algorithms etc), using java as the language"?
Surely to learn all that shit (using java as the language) you at some point have to, you know, learn java?
Pretty sure they're reading "learn java" as "learn the language + the common build tools + more", instead of just the language, as we are.
Almost all beginners absolutely need to be taught the language first (so they have something concrete to mentally latch on to), not concepts and algorithms. However, Maven is not one of those things - either a GUI with a compile button or "javac" is sufficient at that level.
Programming with a build system, with a vcs and/or an editor with intellisense features will unnecessarily burden the student with learning these extra things. vanilla java, taught using a pure text editor (like pico, or notepad++, that has a simplistic syntax highlighting), and make sure the students type out their own imports, etc, is going to teach them more basics.
Until the day you need to build actual working software to ship to people, there's no need for a build system, and until they need to work in groups, there's no need for VCS. And until they start writing something _very_ complex, like a full game using many libraries, they don't need intellisense.
Most CS exercises fit in one class. And when it comes time to design something reasonably complex, the student would've learnt all the fundamentals (like 6 months in), and can move to using an IDE with little issue. And then when group projects come, the students can learn VCS as it makes group work simpler. But till then, showering the first year student with these tooling is just noise.
VCS is essential in a solo project of any real complexity because you will reach intermediate milestones, go off on tangents that don't pan out, and then desperately wish you had a way to get back to the working state you had hours previously. A true VCS with branching and merging is technically overpowered, since you could just make copies of the source for each "commit," but you may as well just use Git.
Build system is not about shipping to people, it's about running what you just wrote on your own machine when it's bigger than one unit of compilation (C file, Java class, whatever). You don't need anything fancy, can just be Make or a shell script, but building and running the whole project should take no more than a few keystrokes. Kids should be fumbling with GCC flags for maybe one assignment, not 4 years.
On the very first day of programming, all you need is a REPL. But once students are doing programming projects of nontrivial size, they should be invited to try incorporating the tools that make them manageable.
This is the critical point. By the time a curriculum is in place around one set of "industry standard" tools, new tools will have come out, in a lot of fields (see, for instance, `npm` and `yarn`.)
> They should be learning programming, and theory of computing (and algorithms etc), and perhaps use java as the language.
I would argue that using Java as the language for introductory CS courses is not a good idea. We have better, simpler languages to teach foundational functional (Racket, Scheme) and imperative (Python) languages.
There's nothing wrong with Java in general, but if your goal is teaching "programming, and theory of computing (and algorithms etc)", there's nothing that Java can do that Python can't that helps with that goal.
In fact, I'd give my optimal progression of languages as starting with Python for basic imperative and OO programming, or Racket for basic functional programming, then switching to the other one, and then looking at Kotlin (or Java if you really must) for advanced OO programming and C (or, in a few years, maybe Rust) for systems programming.
I've been programming very advanced C++ for close to 20 years now.
Never had any reason to use CMake.
Plain old make for when you just want to build something without expending effort and brain cells, or (nowadays) nix if you're putting together an industrial-strength build environment.
CMake is the worst of all worlds, and provides no benefit unless you really want to build Windows exe's with Microsoft's proprietary tooling. (And let's face it, Windows is a legacy dying platform here in 2020.)
This is a big part of why I recommend that another language should be used to teach introductory level courses. Java has too much additional complexity. That complexity has benefits in production, but not for first-year undergrads.
I started my programming career writing C and C++ using the cli and a text editor.
Some years later I ended doing some Java and to me I found it quite easy as I could see similarities with things I had learned writing C and C++.
I could see the classpath and jar files where roughly equivalent to the concept of libraries and libpath found in the C and C++ linker (only much easier to use) and the javac was roughly equivalent to the gcc or g++ command line compilers.
This is might be an argument against a particular IDE setup for a class, but it isn't an argument against IDEs in general. Instead it is an argument for providing a config file to make these problems go away.
> When students have only ever programmed in Java using some bespoke learning library provided by their professor, it will take them much longer than necessary to figure out other languages, other libraries, and other approaches.
The article doesn't support the case that an intro class using an IDE prevents students from learning anything else. The class doesn't set people back--it merely fails to move them forward in that way. I agree that it is important to teach this eventually. But it should be through teaching it deliberately. (EDIT: Someone else posted a link to a class which compares different languages and their tooling side-by-side. That sounds fantastic.)
I have yet to see a class which can do a good job of teaching how package management works to a degree that the student can then confidently debug weird setuptools errors.
I've been looking for such a class since 2009.
Autocompletion and integrated documentation do increase discoverability and learning of the language, not the reverse.
BTW intellij has launched an IDE specialized for teaching: https://blog.jetbrains.com/idea/2019/10/intellij-idea-edu-ea...
When you hire a developer you usually need them to also be at least be something of an expert computer user, especially if they're going to be working on a small team without 20 other experts to micromanage them.
Over-reliance on the IDEs leaves people appliance operators that are lost when there isn't a magic button to press.
It isn't just an issue in the job market. "Programmers" who aren't sufficiently advanced computer users can't advance their own projects in academia either-- they're stuck working on precooked assignments. I suspect this is one of the forces that has resulted in academic research being utterly starved for competent software engineering (though the main one remains that competent software engineers can get stable high paying jobs, and academia provides them with neither).
I get it. It shields them from understanding what's happening underneath. But not everybody is interested or needs to know all the things happening underneath, and its okay. If they're going to learn the whole stack, they will.
It was tedious as hell to learn everything else in real world development, like static versus dynamic linking, include/linker paths, make, system libraries, and so on. Like as in myself nor my classmates would have any idea those things existed after two semesters of C++ programming courses.
The moral here is that education needs a degree of breadth. Teaching CS students involves three concepts - Computer Science, Writing Code, and Writing Software. The dependency graph between those topics on what knowledge and tools are needed contains cycles.
Understanding what a file is and what a text editor should be prerequisites for entering a computer science department. Someone who doesn't understand these concepts has no business learning to program.
At my "not MIT" school, it was expected that most incoming CS students understood some basic programming before they entered school.
A CD department that tolerates students who don't know what a file is probably has other problems.
I never did any programming before my first year, I was planning on going into economics. But then I took an elective in CS and it became my major. I wasn’t alone either, most of the students were not programmers previously.
At Cambridge (UK), this is _not_ the case. They merely note that "some knowledge of procedural programming is useful"[1] and "[n]o prior knowledge of programming is required"[2]. The main thing they are looking for, in terms of qualifications, is mathematics, so you'd typically see an A-level in mathematics plus two further ones in further mathematics, the physical sciences, or computing depending on what your school offers.
At interview (for two colleges), I was not asked about programming - the first was purely mathematics based, and the second was primarily maths based with some CS concepts introduced to see how you thought about and were able to manipulate the information given in the interview. It's not something you were necessarily expected to know.
Until this year, the introductory CS modules (making up 25% of the first year's content) were available to natural sciences students, so you would have students from a fairly wide range of backgrounds _successfully_ learning CS and to program (the maths modules, also making up 25%, are still shared, for what it's worth).
[1] https://www.cst.cam.ac.uk/admissions/undergraduate/entry
[2] https://www.undergraduate.study.cam.ac.uk/courses/computer-s...
So "for computer science students".
Which seems like too major a thing to miss out of the title.
Also, how does webdev fit in here: seems like webdevs should probably be using IDEs from lesson 2. And I say that as someone who started their web content production path writing HTML in pico.
> This is valuable in an introductory course, as it avoids wasting class time and lowers the barrier to entry
and then proceeds to argue why other things are more important than that.
I don't like Eclipse or other IDEs, having watched my fellow students get stymied by basic issues that I could resolve with one or two relatively simple instructions on the command line. I think IDEs can be a crutch that programmers ought to learn to do without. Learning what the "real" tools are will pay dividends—quickly too.
That being said, I think it's important that the barrier to entry be low. Java almost necessitates the use of an IDE. There's so much "enterprise" cruft involved in doing the simplest things that, unless you have an IDE to hide it, you're going to confuse beginners.
A better choice of language and tooling can help here. I think starting off with something like Racket would be best. Those who need an IDE (out of laziness, familiarity, whatever) can use DrRacket, and then switch to running their programs from the command line shortly thereafter with next to no transition overhead.
"public static void main string bracket bracket args"
"public static void main string bracket bracket args"
kind of sad that my first exposure to programming of any kind at University was just repeating that mantra.
Not sure why the aggressive comments here, but I agree with this. IDE for learning programming ends up shielding you from reality that you should probably understand before you use an IDE.
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.