Some of us went to college before version control was widely known. Backups will also work, if you do them. I remember staying all up all night trying to fix an assembly language program that...
Some of us went to college before version control was widely known. Backups will also work, if you do them.
I remember staying all up all night trying to fix an assembly language program that broke after I decided to rename all the registers for neatness. Fortunately, the TA took pity on me.
I did, but after using version control I could not go back to home rolling my own backups. Being able to bisect is just too valuable when trying to track when when a regression was introduced.
Some of us went to college before version control was widely known. Backups will also work, if you do them.
I did, but after using version control I could not go back to home rolling my own backups. Being able to bisect is just too valuable when trying to track when when a regression was introduced.
This all sounds like it was written from someone who hasn't actually seen how colleges actually teach students. Yes, coding classes do start off in IDEs and abstracting away the cruft that is...
This all sounds like it was written from someone who hasn't actually seen how colleges actually teach students. Yes, coding classes do start off in IDEs and abstracting away the cruft that is involved in real programming projects. But that's a very narrow view of the entire experience because most of that other content is placed in other classes. I'm a student at a college working on a Computer Programming degree and I can tell you that my programming classes did not cover operating systems and databases, but that was because those were taught in entirely dedicated classes.
Beyond that, some of his examples of things not being taught are fairly irrelevant. Developers are going to use maven or Gradle more often than javac. The fact of the matter is that programmers are more than likely to be using an IDE of sorts, so if they can all automatically figure out how to build and diagnose your code, why would it matter if you don't know the command line compiler syntax? Oracle's own Java tutorials tell you to use NetBeans for their example code instead of teaching you to use javac.
The thing I am most baffled about is what the author described as "bespoke educational libraries". I can't for the life of me understand why a professor would teach with their own libraries rather than the multitude of existing commonly used libraries.
Looking at the author's about page, she seems to be a computer science student too. There are also a lot of places (Unis, colleges, bootcamps, etc) teaching coding around the world, so your...
This all sounds like it was written from someone who hasn't actually seen how colleges actually teach students.
Looking at the author's about page, she seems to be a computer science student too. There are also a lot of places (Unis, colleges, bootcamps, etc) teaching coding around the world, so your experience needn't be the same as the authors.
The thing I am most baffled about is what the author described as "bespoke educational libraries". I can't for the life of me understand why a professor would teach with their own libraries rather than the multitude of existing commonly used libraries.
You're underestimating the ego of a lot of teachers in a lot of schools and often times they are far removed from the realities of real-world software development. A lot of these teachers have also been teaching the same course for several years, It is not too hard to imagine a professor who wrote a bespoke library to explain, say some data-structures. Used his library to create notes and use it in his lectures. A decade later, the teacher could still be using that library to teach linked lists or queues.
The article is also opinionated, with statements like:
Ultimately, my core belief is this: Students need to know how to use computers before they can program them in a serious way.
And I can sympathize with that. I definitely had a much better understanding of how software works after taking a course on micro-controllers and learnt about ALU's, registers and other nitty-gritties about CPUs, even though I had been programming in C for several years by then.
I have no problem telling @tindall that they are wrong. In all seriousness though, I was hoping to generate conversation and having access to the author is a great bonus.
I have no problem telling @tindall that they are wrong.
In all seriousness though, I was hoping to generate conversation and having access to the author is a great bonus.
I admit that I may be tainted by my perspective; even though I am a student I am not an average one. I'm doing this in my free time as a personal goal to get a paper that tells me that I have...
I admit that I may be tainted by my perspective; even though I am a student I am not an average one. I'm doing this in my free time as a personal goal to get a paper that tells me that I have skills I gained years ago.
It still doesn't quite make sense to me. One of the great things about using an IDE is that you can click on a call to a library and in most cases you will get the source code to the library so...
It still doesn't quite make sense to me. One of the great things about using an IDE is that you can click on a call to a library and in most cases you will get the source code to the library so you can see exactly what is happening.
But I don't think you are describing the same thing as the author because I was getting the idea he wanted students to know how to do the housekeeping before being taught how to live in the house.
I don't think you need an IDE to teach Java, I definitely was taught using a text editor for my first few courses, although that was 14 years ago. Most universities were teaching C++, and ours was...
I don't think you need an IDE to teach Java, I definitely was taught using a text editor for my first few courses, although that was 14 years ago. Most universities were teaching C++, and ours was one of the first to switch their beginner curriculum to Java.
Our professor had us use Notepad++, which didn't have any fancy linting or static analysis to tell us if there was a missing semicolon somewhere or a typo in a variable name. We definitely spent some time during the course talking about why packages need to be in the correct directory, what does public static void main even mean, and how add a library .jar to your project. None of our assignments had more than ~15 files in them, so it was pretty easy to manage without and IDE.
We would type up some section of the code, then attempt to build it, then fix the ~100 compiler errors (the compiler was also a lot dumber back then, and would generate a ton of errors for something like an unclosed parenthesis or a missing bracket), then run that section of the code and check for correctness. At some point in the second semester we were taught how to use JUnit to check our classes without having to write test code in the Main method, but again this was all a manual process.
Moving on from the Java courses, I remember a few highlights. We had a C++ Linux course where the professor taught us all vim, an assembly course where no IDE would have been able to help, and a statistics course where we all learned R mostly by using it as a shell. I don't think we ever used an IDE in any class until senior year when the projects started to get huge.
Nowadays there are much better editors and tools available without having to go full Eclipse or IntelliJ. I would think VSCode would be plenty for beginner courses.
I'll push back slightly here; I don't know if there's good evidence that points to IDE vs. terminal as a source for imposter syndrome, though there's good evidence that IDEs and terminals often...
Another possible explanation may be the message conveyed to students by their faculty. Lewis found that a prevalence (77%) of computer science faculty believe that not everyone can succeed in CS. If this belief is conveyed to students, it may cause anxiety in those students as to whether or not they have that inherent knack for computing.
Generally, folks point to fixed vs growth mindset and structural pressures and inequities (see several bullshit biological arguments about why some population is less predisposed to computer science), probably some other stuff that I'm forgetting.
I'd agree though, the emphasis on programming over problem-solving practices definitely doesn't help. Some folks in the computing education space are pushing for centering self-regulation and self-regulated learning in CS, but it's hard to get folks to redesign their courses around that.
My formal programming education did something like this. The first introductory course was on how to set up a Linux VM in virtualbox, since all the school's computers were standard Education-issue...
Provide a standardized environment - as a VM, perhaps, or using something like repl.it or ideone - perhaps a similar software designed specifically for education.
My formal programming education did something like this. The first introductory course was on how to set up a Linux VM in virtualbox, since all the school's computers were standard Education-issue Windows it was easy enough to do as a general course but from there on out we would do almost all of our classes on some flavor of Linux VM. The school recommended Mint for ease of use but we were free to experiment as long as we understood that:
Teachers didn't have the time to 'catch us up' if we strayed too far off the path, it was our own responsibility to make sure we had at least one working VM to fall back on during class
If you did anything which broke rules or actual laws the school would immediately suspend you or hand you over to the authorities, no room for negotiation
And to this day I still liked the way we did it1. The curriculum started with VMs, UNIX command-line, then moved into general programming concepts, database theory and SQL, before finally doing formal programming with Java. We only used Eclipse briefly in order to learn how to integrate Maven and Gradle and were allowed any choice of IDE or software for the end-term project, which was a simple exercise in implementing a system using a design pattern of choice. The only thing I didn't quite like was how the Python course happened much later in the year, I felt like that could have been moved forward.
Oh and the PHP course, that one was bad. But the fact that we all passed the exam with flying colours because we had just finished a course on basic security and exploited a vulnerability2 on the teacher's exam server to get the correction is still really funny to me.
[1] Mint is still my distro of choice, purely for this reason.
[2]For those who are curious: the PHP system he had us design would display pages by getting the files through a GET command, and he had not hardened the server. We were able to GET things like ?file=/etc/shadow and so just had to print his directory structure and guess where he had stored the answers to the exam.
I had the opposite experience when learning programming with IDEs. IntelliJ in particular was my first pick cause Eclipse is a pile of hot garbage, and it got out of my way and let me write code...
I had the opposite experience when learning programming with IDEs. IntelliJ in particular was my first pick cause Eclipse is a pile of hot garbage, and it got out of my way and let me write code and test it pretty quickly. Did I totally understand how exactly projects worked and all the extra neat features of the IDE that I never used in my sub 200 lines first semester homeworks? Of course not. But I filed those away in my brain under "professionals use those" and only used them when DuckDuckGo results told me that a feature of my IDE I was not aware of solved my problem. I got by selecting all the default options.
My lecture dealing with programming only explained concepts and the practical part basically told us "We use Eclipse, use whatever you want."
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. In none of the curricula I’ve seen, through personal experience or reading syllabi provided by other students, is there a place for students to get past the myriad of barriers that constitute the use of a computer in the modern day.
What exactly do you understand under using a computer in the modern day? In my opinion that's not what Computer Science should teach you, using a computer should by now be a basic skill, especially by someone interested in CS. The inner workings of an OS and what problems arise by using it are usually covered in a different class and in almost every case the covered OS is Linux coz it's OSS. Of course those classes don't teach you how to use Linux, but at least at my uni there's an optional class on practical Linux basics.
I get where you're coming from, but a lot of stuff in CS is just intertwined like that and I don't know if it's possible to solve that knot in any practical way.
But why is this relevant in intro (I'm assuming 1st semester) CS courses? Those are usually focused on the basics of programming, control flow of code and usually related math and...
And yet. And yet, as I mention in the post, plenty people in intro CS courses don't know what a file is, or whether or not filenames are case sensitive on their system, or how what an executable is. This is because operating systems purposely obscure this, especially mobile operating systems (and MacOS).
But why is this relevant in intro (I'm assuming 1st semester) CS courses? Those are usually focused on the basics of programming, control flow of code and usually related math and electronics/hardware courses.
Reading and writing files yes, but file handling from a code perspective does not require deeper OS knowledge, you just need to know the libraries. Knowing NIO is different from knowing how the OS...
I think it's very relevant. If you don't get into reading/writing files, for instance, in the course of the first semester, I'd argue that a critical part of the basics of programming has been missed.
Reading and writing files yes, but file handling from a code perspective does not require deeper OS knowledge, you just need to know the libraries. Knowing NIO is different from knowing how the OS does its filesystem. My point was that you get to know NIO during the first semester in later programming homeworks, and in-depth OS workings in a separate class.
Furthermore, a major point I make in the post is that the use of complex development environments that don't leverage standard tools actually makes it harder to learn about these basic elements.
I disagree here. Nothing's simpler than opening IntelliJ (or Visual Basic) with a new project, writing your first-ever code and then hitting that big ass green play button to make it all crash (or run, sometimes). You don't need to write in cmd, you don't need to worry about adding javac to path or whatever, you can just write Hello World.
Is the interface intimidating? Of course. But the text window is clearly the main focus, which makes it easy to hit the ground running.
Your approach with teaching your students probably also works well! I think we're just arguing for different ways to teach, either from a top-down style (say starting in an IDE with a high-level language) where you start simple and get into details later, or bottom-up where you start nitty and gritty and slowly work yourself up (starting with a low-level or older language with just a basic text editor).
I would not consider accessing files to be a basic programming skills even though it feels like it should. For one thing, files are handled differently depending on your context. And in many cases...
I would not consider accessing files to be a basic programming skills even though it feels like it should.
For one thing, files are handled differently depending on your context. And in many cases direct file access is not a requirement for any given application.
That being said, I would absolutely agree with what you said earlier that students should understand how filesystems work.
I think file-access is a very important piece of the puzzle on how applications work. Pretty much any external interaction your code is going to do is through a file. Getting a user input? You are...
I think file-access is a very important piece of the puzzle on how applications work. Pretty much any external interaction your code is going to do is through a file. Getting a user input? You are reading from a file, Network access? you are essentially reading/writing to a file, etc.
Granted a lot of languages/frameworks abstract this underlying concept away from the developer (and rightfully so), but for someone who is learning how to write programs, I think it is an important concept to learn.
However, I think you're right that it's debatable if it should be taught in a intro level course, more so if the language being taught is something like python or Java.
I strongly disagree with everything in this post. In my opinion teaching fledgling CS students the Unix command line and all its flawed philosophies is responsible for the poor state of usability...
I strongly disagree with everything in this post. In my opinion teaching fledgling CS students the Unix command line and all its flawed philosophies is responsible for the poor state of usability in software today. Once you get down to the nitty gritty and use that every day, you start to assume that everyone else can work like that, too, so you start to design your applications that way. It's a never-ending cycle of extending the CS priesthood to the detriment of actual users.
I had a professor that taught us kernels and system programming with Inferno OS, which is based on Plan 9. Is that what you're hoping for? The system design is far more elegant than Unix.
I had a professor that taught us kernels and system programming with Inferno OS, which is based on Plan 9. Is that what you're hoping for? The system design is far more elegant than Unix.
I say that because Unix is a very specialized interface that's intended for working with (mainly text) files with minimal (or, ironically maximal) display of data to the user. You pipe data from...
I say that because Unix is a very specialized interface that's intended for working with (mainly text) files with minimal (or, ironically maximal) display of data to the user. You pipe data from one program to another, often without being able to see what's happening between them. When everything lines up it's very efficient. And when the slightest thing goes wrong, it's incomprehensible unless you've spent years learning how to understand it.
I still remember being set down at a Unix shell for the first time. I had no idea what any of the commands were, so I did what any sensible person at a command line would do and typed "help". And the response from the computer was basically, "Fuck you!" Despite that, I went on to become a Unix sysadmin, then a professional software engineer, and I have worked for a few different Unix vendors. Unix is one of the most user-hostile systems I've encountered. It's industrial strength and works very well for processing and serving up data, but it's terrible for actually using unless you love memorizing obscure trivia.
As for alternatives, I think IDEs are a great way to make some of the language stuff less of a hurdle to students learning this stuff for the first time. I think IDEs have some great tools for learning how things work. Knowing a bunch of command line arguments isn't a transferable skill since every single command on Unix has a different set of arguments. Knowing how to step through your code in a visual debugger is a transferable skill, and it's likely how you'll debug programs when working professionally. It doesn't matter if you're running Eclipse, VSCode, Xcode, or some other IDE. They all allow you to step through your program a line at a time, seeing which line of code is currently executing in the context of the surrounding code, with a stack display next to it to see how you got there. Debugging with gdb, for example, was next to useless. If I recall, it would show the single line of code you were on, and nothing else. That's a far worse experience.
That sounds interesting! But a nicer command line is still a command line. There's nothing that makes a command line necessary when building an application. That's just how a few systems decided...
there is a lot of work in the Rust community to build nicer command line interfaces that take advantages of colors, mouse controls, and fuzzy language processing
That sounds interesting! But a nicer command line is still a command line. There's nothing that makes a command line necessary when building an application. That's just how a few systems decided to do it. When I was in college, I did a lot of Mac programming back before they were based on Unix. The compilers were not command line compilers because there was no command line. And they were far easier to understand because all of the options were laid out in front of you (when you needed them), and their possible values were often very clear.
the power of composability that GUI apps just can't touch.
I don't agree that's the case. I don't think typical users need composability, but there's nothing stopping you from making a GUI for composable apps.
I don't have any problem with exposing students to these sorts of systems, especially if they're interested in them. But it shouldn't be the default for first year CS students like it was when I went through it. And I don't think there's anything inherently better about forcing students to learn these sorts of things.
By a few, you actually mean 'The most popular operating systems for running server applications to the degree that other OS options are basically a rounding error.' The vast majority of...
That's just how a few systems decided to do it.
By a few, you actually mean 'The most popular operating systems for running server applications to the degree that other OS options are basically a rounding error.' The vast majority of programming is done for server-side programs.
When I was in college, I did a lot of Mac programming back before they were based on Unix. The compilers were not command line compilers because there was no command line.
I don't agree that's the case. I don't think typical users need composability
Typical users may not...but CS and IT folks certainly should. Doing anything more advanced than using a web browser, a file browser, and a video player often benefits from knowing a command line shell, especially one more advanced than cmd. If shells weren't immensely useful to power-users, Microsoft wouldn't have ever invested the time to develop Powershell or WSL.
there's nothing stopping you from making a GUI for composable apps.
Actually there is: Command line programs are virtually infinitely configurable, because you can chain outputs from one program to another in a huge variety of ways. It's almst impossible to chain together output from different GUI programs into each other. Shells also make it trivial to execute commands against hundreds or thousands of machines in the time it would take to load a GUI on one machine and click through it.
But it shouldn't be the default for first year CS students like it was when I went through it. And I don't think there's anything inherently better about forcing students to learn these sorts of things.
I'm of the reverse mindset...It should be a per-requisite before any programming course. Hell, many of the first programming exercises are command line programs for a reason, because it's far easier to make a useful command line program than a GUI.
That's irrelevant to whether that's what the students plan to do or not. Ha! MPW was quite expensive and most Mac developers outside of Apple were not using it. They usually opted for Think C and...
The vast majority of programming is done for server-side programs.
That's irrelevant to whether that's what the students plan to do or not.
The other major programming environment included a command line.
Ha! MPW was quite expensive and most Mac developers outside of Apple were not using it. They usually opted for Think C and later Metrowerks CodeWarrior. Far more were using those than using MPW.
Doing anything more advanced than using a web browser, a file browser, and a video player often benefits from knowing a command line shell, especially one more advanced than cmd. If shells weren't immensely useful to power-users, Microsoft wouldn't have ever invested the time to develop Powershell or WSL.
None of which is relevant to teaching beginning CS students how to program, which strikes me as the point of the article. Those are all things that can and should be learned at some point. But they shouldn't be forced on beginning CS students when they're trying to wrap their head around programming languages, and algorithms.
Actually there is: Command line programs are virtually infinitely configurable, because you can chain outputs from one program to another in a huge variety of ways. It's almst impossible to chain together output from different GUI programs into each other.
Not really. It's not currently done much because, as mentioned, it's not that useful for most users. But it's fairly easy to do for a GUI. One simple example I can think of is Apple's Automator.
Shells also make it trivial to execute commands against hundreds or thousands of machines in the time it would take to load a GUI on one machine and click through it.
First, it's not trivial at all. It takes quite a bit to make it work on a command line, and it could be done for a GUI too, if the will were there.
it's far easier to make a useful command line program than a GUI.
It's odd that you use this reasoning after arguing that students should be forced to do the harder things first.
Yes, Java has a rather unfortunate toolchain since both Maven and Gradle are difficult for even experienced programmers to understand. If teaching students something about a toolchain is...
Yes, Java has a rather unfortunate toolchain since both Maven and Gradle are difficult for even experienced programmers to understand. If teaching students something about a toolchain is considered important, it would be better to teach one that's good like Go.
I think students should be taught Java in my area because that’s were the jobs are. I just don’t think it has any place on introductory classes. Saying that as a student. The whole experience is...
I think students should be taught Java in my area because that’s were the jobs are. I just don’t think it has any place on introductory classes.
Saying that as a student. The whole experience is just ugly and convoluted.
These days I'm wondering if a browser-based system like repl.it or observablehq.com might make more sense as a first environment. If you can write a program and share it with people you know to...
These days I'm wondering if a browser-based system like repl.it or observablehq.com might make more sense as a first environment. If you can write a program and share it with people you know to use "for real", that's enough to get started. And it should still be useful for sketching out prototypes after you move on to some other environment. (That is, assuming they survive. Sometimes it's hard to tell what will last.)
There is a lot to learn and you don't have to learn everything at once.
Definitely seems like something worth looking into. I've personally found repl.it to be useful when figuring out a new language. I feel like it provides a slightly tighter think-write-compile-run...
Definitely seems like something worth looking into. I've personally found repl.it to be useful when figuring out a new language. I feel like it provides a slightly tighter think-write-compile-run loop than when one is remoted in to a student machine or running a new compiler setup on a personal machine. It definitely abstracts away a lot of the complexity of files, editors, etc.
Question: Far are you in your CS degree? I graduated last year with my CS degree from a relatively small Uni in the Midwest US, and while many of the first and second year classes where somewhat...
Question:
Far are you in your CS degree? I graduated last year with my CS degree from a relatively small Uni in the Midwest US, and while many of the first and second year classes where somewhat like you described (use of IDEs, no explanation of how computers work), my third and fourth year classes definitely covered that.
We had to program in assembly, which gives you more details on how a computer works (registers, processor operations). We had edit BMP images using C, which certainly helps you understand what a file is (headers, bytes, etc).
Hell, my senior year I had to write an FTP application in C by sshing into a Linux server and using only the command line in my networking class.
In the CS program I went through we covered just about everything you mentioned in your piece, and I don't think my uni has a particularly renowned program so I was surprised to hear that your experience has been so different.
Wow... that's... just wow. I'm sorry to hear that you weren't provided with some of those important aspects in your program. I didn't realize that other Comp Sci programs were so different than...
Wow... that's... just wow. I'm sorry to hear that you weren't provided with some of those important aspects in your program. I didn't realize that other Comp Sci programs were so different than mine. Your article makes a lot more sense now.
I'd seen what you described in some CIS programs, but I didn't realize that there were some full on Comp Sci programs that took that path.
Low-level programming should be definitely dealt with at some point, but I don't know if I'd jump straight to Assembly from Java... At uni we had a related course in 3rd semester which dealth with...
Low-level programming should be definitely dealt with at some point, but I don't know if I'd jump straight to Assembly from Java... At uni we had a related course in 3rd semester which dealth with C and Assembly (I mean it was pretty bad because they tried jamming C and Assembly into the same course for same reason).
In general though, you don't want to scare away students with Assembly straight away so I'd say it's fairly standard these days to get started with a high-level language and work from there.
Some of us went to college before version control was widely known. Backups will also work, if you do them.
I remember staying all up all night trying to fix an assembly language program that broke after I decided to rename all the registers for neatness. Fortunately, the TA took pity on me.
That was a lesson.
I did, but after using version control I could not go back to home rolling my own backups. Being able to bisect is just too valuable when trying to track when when a regression was introduced.
This all sounds like it was written from someone who hasn't actually seen how colleges actually teach students. Yes, coding classes do start off in IDEs and abstracting away the cruft that is involved in real programming projects. But that's a very narrow view of the entire experience because most of that other content is placed in other classes. I'm a student at a college working on a Computer Programming degree and I can tell you that my programming classes did not cover operating systems and databases, but that was because those were taught in entirely dedicated classes.
Beyond that, some of his examples of things not being taught are fairly irrelevant. Developers are going to use maven or Gradle more often than javac. The fact of the matter is that programmers are more than likely to be using an IDE of sorts, so if they can all automatically figure out how to build and diagnose your code, why would it matter if you don't know the command line compiler syntax? Oracle's own Java tutorials tell you to use NetBeans for their example code instead of teaching you to use javac.
The thing I am most baffled about is what the author described as "bespoke educational libraries". I can't for the life of me understand why a professor would teach with their own libraries rather than the multitude of existing commonly used libraries.
Looking at the author's about page, she seems to be a computer science student too. There are also a lot of places (Unis, colleges, bootcamps, etc) teaching coding around the world, so your experience needn't be the same as the authors.
You're underestimating the ego of a lot of teachers in a lot of schools and often times they are far removed from the realities of real-world software development. A lot of these teachers have also been teaching the same course for several years, It is not too hard to imagine a professor who wrote a bespoke library to explain, say some data-structures. Used his library to create notes and use it in his lectures. A decade later, the teacher could still be using that library to teach linked lists or queues.
The article is also opinionated, with statements like:
And I can sympathize with that. I definitely had a much better understanding of how software works after taking a course on micro-controllers and learnt about ALU's, registers and other nitty-gritties about CPUs, even though I had been programming in C for several years by then.
I have no problem telling @tindall that they are wrong.
In all seriousness though, I was hoping to generate conversation and having access to the author is a great bonus.
I will gladly take that part back; it was quite a reactive comment on my part.
I admit that I may be tainted by my perspective; even though I am a student I am not an average one. I'm doing this in my free time as a personal goal to get a paper that tells me that I have skills I gained years ago.
It still doesn't quite make sense to me. One of the great things about using an IDE is that you can click on a call to a library and in most cases you will get the source code to the library so you can see exactly what is happening.
But I don't think you are describing the same thing as the author because I was getting the idea he wanted students to know how to do the housekeeping before being taught how to live in the house.
I don't think you need an IDE to teach Java, I definitely was taught using a text editor for my first few courses, although that was 14 years ago. Most universities were teaching C++, and ours was one of the first to switch their beginner curriculum to Java.
Our professor had us use Notepad++, which didn't have any fancy linting or static analysis to tell us if there was a missing semicolon somewhere or a typo in a variable name. We definitely spent some time during the course talking about why packages need to be in the correct directory, what does
public static void maineven mean, and how add a library .jar to your project. None of our assignments had more than ~15 files in them, so it was pretty easy to manage without and IDE.We would type up some section of the code, then attempt to build it, then fix the ~100 compiler errors (the compiler was also a lot dumber back then, and would generate a ton of errors for something like an unclosed parenthesis or a missing bracket), then run that section of the code and check for correctness. At some point in the second semester we were taught how to use JUnit to check our classes without having to write test code in the Main method, but again this was all a manual process.
Moving on from the Java courses, I remember a few highlights. We had a C++ Linux course where the professor taught us all vim, an assembly course where no IDE would have been able to help, and a statistics course where we all learned R mostly by using it as a shell. I don't think we ever used an IDE in any class until senior year when the projects started to get huge.
Nowadays there are much better editors and tools available without having to go full Eclipse or IntelliJ. I would think VSCode would be plenty for beginner courses.
I'll push back slightly here; I don't know if there's good evidence that points to IDE vs. terminal as a source for imposter syndrome, though there's good evidence that IDEs and terminals often aren't inclusively designed. Imposter syndrome is super prevalent in CS, some think that it might be in part the messages that students receive from their instructors. Leo Porter's lab offers:
Generally, folks point to fixed vs growth mindset and structural pressures and inequities (see several bullshit biological arguments about why some population is less predisposed to computer science), probably some other stuff that I'm forgetting.
I'd agree though, the emphasis on programming over problem-solving practices definitely doesn't help. Some folks in the computing education space are pushing for centering self-regulation and self-regulated learning in CS, but it's hard to get folks to redesign their courses around that.
Happy Saturday!
My formal programming education did something like this. The first introductory course was on how to set up a Linux VM in virtualbox, since all the school's computers were standard Education-issue Windows it was easy enough to do as a general course but from there on out we would do almost all of our classes on some flavor of Linux VM. The school recommended Mint for ease of use but we were free to experiment as long as we understood that:
And to this day I still liked the way we did it1. The curriculum started with VMs, UNIX command-line, then moved into general programming concepts, database theory and SQL, before finally doing formal programming with Java. We only used Eclipse briefly in order to learn how to integrate Maven and Gradle and were allowed any choice of IDE or software for the end-term project, which was a simple exercise in implementing a system using a design pattern of choice. The only thing I didn't quite like was how the Python course happened much later in the year, I felt like that could have been moved forward.
Oh and the PHP course, that one was bad. But the fact that we all passed the exam with flying colours because we had just finished a course on basic security and exploited a vulnerability2 on the teacher's exam server to get the correction is still really funny to me.
[1] Mint is still my distro of choice, purely for this reason.
[2]For those who are curious: the PHP system he had us design would display pages by getting the files through a GET command, and he had not hardened the server. We were able to GET things like
?file=/etc/shadowand so just had to print his directory structure and guess where he had stored the answers to the exam.I had the opposite experience when learning programming with IDEs. IntelliJ in particular was my first pick cause Eclipse is a pile of hot garbage, and it got out of my way and let me write code and test it pretty quickly. Did I totally understand how exactly projects worked and all the extra neat features of the IDE that I never used in my sub 200 lines first semester homeworks? Of course not. But I filed those away in my brain under "professionals use those" and only used them when DuckDuckGo results told me that a feature of my IDE I was not aware of solved my problem. I got by selecting all the default options.
My lecture dealing with programming only explained concepts and the practical part basically told us "We use Eclipse, use whatever you want."
What exactly do you understand under using a computer in the modern day? In my opinion that's not what Computer Science should teach you, using a computer should by now be a basic skill, especially by someone interested in CS. The inner workings of an OS and what problems arise by using it are usually covered in a different class and in almost every case the covered OS is Linux coz it's OSS. Of course those classes don't teach you how to use Linux, but at least at my uni there's an optional class on practical Linux basics.
I get where you're coming from, but a lot of stuff in CS is just intertwined like that and I don't know if it's possible to solve that knot in any practical way.
Yeah, I have to say that throughout this discussion, I've felt really really gross defending using Eclipse. It is awful.
But why is this relevant in intro (I'm assuming 1st semester) CS courses? Those are usually focused on the basics of programming, control flow of code and usually related math and electronics/hardware courses.
Reading and writing files yes, but file handling from a code perspective does not require deeper OS knowledge, you just need to know the libraries. Knowing NIO is different from knowing how the OS does its filesystem. My point was that you get to know NIO during the first semester in later programming homeworks, and in-depth OS workings in a separate class.
I disagree here. Nothing's simpler than opening IntelliJ (or Visual Basic) with a new project, writing your first-ever code and then hitting that big ass green play button to make it all crash (or run, sometimes). You don't need to write in cmd, you don't need to worry about adding javac to path or whatever, you can just write Hello World.
Is the interface intimidating? Of course. But the text window is clearly the main focus, which makes it easy to hit the ground running.
Your approach with teaching your students probably also works well! I think we're just arguing for different ways to teach, either from a top-down style (say starting in an IDE with a high-level language) where you start simple and get into details later, or bottom-up where you start nitty and gritty and slowly work yourself up (starting with a low-level or older language with just a basic text editor).
I would not consider accessing files to be a basic programming skills even though it feels like it should.
For one thing, files are handled differently depending on your context. And in many cases direct file access is not a requirement for any given application.
That being said, I would absolutely agree with what you said earlier that students should understand how filesystems work.
I think file-access is a very important piece of the puzzle on how applications work. Pretty much any external interaction your code is going to do is through a file. Getting a user input? You are reading from a file, Network access? you are essentially reading/writing to a file, etc.
Granted a lot of languages/frameworks abstract this underlying concept away from the developer (and rightfully so), but for someone who is learning how to write programs, I think it is an important concept to learn.
However, I think you're right that it's debatable if it should be taught in a intro level course, more so if the language being taught is something like python or Java.
I strongly disagree with everything in this post. In my opinion teaching fledgling CS students the Unix command line and all its flawed philosophies is responsible for the poor state of usability in software today. Once you get down to the nitty gritty and use that every day, you start to assume that everyone else can work like that, too, so you start to design your applications that way. It's a never-ending cycle of extending the CS priesthood to the detriment of actual users.
I had a professor that taught us kernels and system programming with Inferno OS, which is based on Plan 9. Is that what you're hoping for? The system design is far more elegant than Unix.
Generally kernels and system programming are not introductory CS courses, so no I'm definitely not hoping for that.
I say that because Unix is a very specialized interface that's intended for working with (mainly text) files with minimal (or, ironically maximal) display of data to the user. You pipe data from one program to another, often without being able to see what's happening between them. When everything lines up it's very efficient. And when the slightest thing goes wrong, it's incomprehensible unless you've spent years learning how to understand it.
I still remember being set down at a Unix shell for the first time. I had no idea what any of the commands were, so I did what any sensible person at a command line would do and typed "help". And the response from the computer was basically, "Fuck you!" Despite that, I went on to become a Unix sysadmin, then a professional software engineer, and I have worked for a few different Unix vendors. Unix is one of the most user-hostile systems I've encountered. It's industrial strength and works very well for processing and serving up data, but it's terrible for actually using unless you love memorizing obscure trivia.
As for alternatives, I think IDEs are a great way to make some of the language stuff less of a hurdle to students learning this stuff for the first time. I think IDEs have some great tools for learning how things work. Knowing a bunch of command line arguments isn't a transferable skill since every single command on Unix has a different set of arguments. Knowing how to step through your code in a visual debugger is a transferable skill, and it's likely how you'll debug programs when working professionally. It doesn't matter if you're running Eclipse, VSCode, Xcode, or some other IDE. They all allow you to step through your program a line at a time, seeing which line of code is currently executing in the context of the surrounding code, with a stack display next to it to see how you got there. Debugging with gdb, for example, was next to useless. If I recall, it would show the single line of code you were on, and nothing else. That's a far worse experience.
That sounds interesting! But a nicer command line is still a command line. There's nothing that makes a command line necessary when building an application. That's just how a few systems decided to do it. When I was in college, I did a lot of Mac programming back before they were based on Unix. The compilers were not command line compilers because there was no command line. And they were far easier to understand because all of the options were laid out in front of you (when you needed them), and their possible values were often very clear.
I don't agree that's the case. I don't think typical users need composability, but there's nothing stopping you from making a GUI for composable apps.
I don't have any problem with exposing students to these sorts of systems, especially if they're interested in them. But it shouldn't be the default for first year CS students like it was when I went through it. And I don't think there's anything inherently better about forcing students to learn these sorts of things.
By a few, you actually mean 'The most popular operating systems for running server applications to the degree that other OS options are basically a rounding error.' The vast majority of programming is done for server-side programs.
That's only true if you only did HyperCard programming. The other major programming environment included a command line.
Typical users may not...but CS and IT folks certainly should. Doing anything more advanced than using a web browser, a file browser, and a video player often benefits from knowing a command line shell, especially one more advanced than cmd. If shells weren't immensely useful to power-users, Microsoft wouldn't have ever invested the time to develop Powershell or WSL.
Actually there is: Command line programs are virtually infinitely configurable, because you can chain outputs from one program to another in a huge variety of ways. It's almst impossible to chain together output from different GUI programs into each other. Shells also make it trivial to execute commands against hundreds or thousands of machines in the time it would take to load a GUI on one machine and click through it.
I'm of the reverse mindset...It should be a per-requisite before any programming course. Hell, many of the first programming exercises are command line programs for a reason, because it's far easier to make a useful command line program than a GUI.
That's irrelevant to whether that's what the students plan to do or not.
Ha! MPW was quite expensive and most Mac developers outside of Apple were not using it. They usually opted for Think C and later Metrowerks CodeWarrior. Far more were using those than using MPW.
None of which is relevant to teaching beginning CS students how to program, which strikes me as the point of the article. Those are all things that can and should be learned at some point. But they shouldn't be forced on beginning CS students when they're trying to wrap their head around programming languages, and algorithms.
Not really. It's not currently done much because, as mentioned, it's not that useful for most users. But it's fairly easy to do for a GUI. One simple example I can think of is Apple's Automator.
First, it's not trivial at all. It takes quite a bit to make it work on a command line, and it could be done for a GUI too, if the will were there.
It's odd that you use this reasoning after arguing that students should be forced to do the harder things first.
Stop making students use Java! (half joking).
A funny statement considering the half-assed implementation of generics in Java.
Yes, Java has a rather unfortunate toolchain since both Maven and Gradle are difficult for even experienced programmers to understand. If teaching students something about a toolchain is considered important, it would be better to teach one that's good like Go.
I think students should be taught Java in my area because that’s were the jobs are. I just don’t think it has any place on introductory classes.
Saying that as a student. The whole experience is just ugly and convoluted.
These days I'm wondering if a browser-based system like repl.it or observablehq.com might make more sense as a first environment. If you can write a program and share it with people you know to use "for real", that's enough to get started. And it should still be useful for sketching out prototypes after you move on to some other environment. (That is, assuming they survive. Sometimes it's hard to tell what will last.)
There is a lot to learn and you don't have to learn everything at once.
Definitely seems like something worth looking into. I've personally found repl.it to be useful when figuring out a new language. I feel like it provides a slightly tighter think-write-compile-run loop than when one is remoted in to a student machine or running a new compiler setup on a personal machine. It definitely abstracts away a lot of the complexity of files, editors, etc.
Question:
Far are you in your CS degree? I graduated last year with my CS degree from a relatively small Uni in the Midwest US, and while many of the first and second year classes where somewhat like you described (use of IDEs, no explanation of how computers work), my third and fourth year classes definitely covered that.
We had to program in assembly, which gives you more details on how a computer works (registers, processor operations). We had edit BMP images using C, which certainly helps you understand what a file is (headers, bytes, etc).
Hell, my senior year I had to write an FTP application in C by sshing into a Linux server and using only the command line in my networking class.
In the CS program I went through we covered just about everything you mentioned in your piece, and I don't think my uni has a particularly renowned program so I was surprised to hear that your experience has been so different.
Wow... that's... just wow. I'm sorry to hear that you weren't provided with some of those important aspects in your program. I didn't realize that other Comp Sci programs were so different than mine. Your article makes a lot more sense now.
I'd seen what you described in some CIS programs, but I didn't realize that there were some full on Comp Sci programs that took that path.
Low-level programming should be definitely dealt with at some point, but I don't know if I'd jump straight to Assembly from Java... At uni we had a related course in 3rd semester which dealth with C and Assembly (I mean it was pretty bad because they tried jamming C and Assembly into the same course for same reason).
In general though, you don't want to scare away students with Assembly straight away so I'd say it's fairly standard these days to get started with a high-level language and work from there.