I had a sophomore level class that covered about 2/3 of that list. The only big thing I think it missed was version control, although back then it would have been CVS. It did cover group dynamics and management, which seems to be missing in the link. The school was trying to prepare students for the numerous group projects they were about to be assigned in the junior and senior year.
In retrospect they could have put more focus on debugging tools as well. But since they didn't mandate one particular system--we had projects where every kid was using their own development environment, from VS on Windows 95 to vi, gcc, and Make on FreeBSD all developing on the same codebase. It sounds like development hell, but it made porting the app to all of the target platforms a breeze.
When working on a group project how do you divide up your work. How to keep track of everyone's progress so you don't have 3/4 of the project done only to discover that one of the members has not even started on his piece yet. Basically how to work in groups. This is one thing that many students struggle with and if you don't do it you'll often find group projects where one person did like 90% of the work because nobody knew how to coordinate.
...that doesn't sound helpful, to be honest. My experience with group projects wasn't that nobody knew how to coordinate, but that people didn't -want- to. The person who was content to take a C on the project would just not do anything they were responsible for. The person who wanted an A would end up doing it. The professors had no formal method for checking in with the team, nor any real teeth for those who dodged their responsibilities, so even if it was communicated and the slacker(s) took a grade hit, it wasn't much.
(For reference, I had that happen at least twice in school, where the group of us broke up the work and scheduled check-ins, and by the end of it only I had done my part...though being cynical, as the team missed check-ins with various excuses, I had also done everyone else's because I cared about my grade)
Unlike the real world, where if someone is allocated work, and doesn't do it, a manager deals with it. Professors are not interested in being managers.
That said, it DOES sound useful for the real world, where the incentives are better aligned.
At Kent State (graduated 2004) I had to take "Social and Ethical Issues in Computing". It was a very easy "writing-intensive" class, where we had some group discussions of the contents of our textbook, and then had to write a few 5-page papers talking about the content.
The only thing which stuck with me was the Therac-25 story. Everything else was just pretty much "don't deliberately use your powers for evil" type thing.
I've said it before but I hard disagree on this. I would hate my money to go towards ethics in a field where that's not a universal requirement. You have to know algorithms etc to get into anywhere from the red cross to facebook, but not ethics. That would be fine as an optional elective
IMO that's exactly why we need good ethics courses. If ethics isn't treated as a priority in university, it won't be treated as a priority by companies.
And you can take a look at the ethics of the rich and powerful to see how much financial and non-financial gain comes from being unethical. I'm not at work for fun or to change the world, I work strictly to make money. If facebook or an autonomous fighter jet company offered me an opportunity to do my current job at whatever crazy salaries they pay, I'd start yesterday. If I could press a button and have them change into companies that raise orphan puppies or something (while preserving my salary), I'd press that button yesterday. If I woke up to 10MM in my bank account, I'd retire yesterday. Until one of those scenarios happens, I need a job and the best-paying one I can get.
It's easy to talk about professional ethics and choosing good over income on an internet forum when the impact it has on someone else's life has no impact on yours. If I left a FAANG to work for peanuts at some volunteer agency, I suspect you wouldn't be there to chip in when my loved one needs support and suddenly my ethics can't foot the bill like my old salary could. You have no idea the impact a FAANG salary would have on my life and my loved ones', so it's not very thoughtful to suggest that somebody who has to prioritize financial gain is unable to see good other than financial gain.
Maybe I'm an idealist, but university should be more than learning algorithms so that you can pass a coding test and get a job. As others have already commented, if you want to learn work skills, go to a trade school.
I was happy to see my alma mater introduce a class called "CS 193 Tools" that is taken by all freshmen. I never took it, but it started when I was a junior or so (~2014). A friend of mine pushed to create the course and helped TA it for a few semesters. Here's the course description:
Learning Outcomes:
1. Understand Unix/Linux commands for navigating directories and files and manipulating files and folders.
2. Understand terminal commands for searching and input/output redirection.
3. Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
4. Understand debugging via print statements and general debugger concepts.
5. Understand version control via Git and Github, source control, workflow, commit, collaboration, pull, push, create and pushing a new repository, cloning, branches, merging, and conflicts.
6. Understand vim including mouseless navigation, normal/insert mode, copy/paste, search/replace, and saving/quitting.
Learning the basics of shell scripting has been super valuable to my career.
The only time I found it to be a liability was when I was pair programming. My pair couldn't read a shell script to save their life & had very little interest in learning. When I tried explaining it line by line, they stopped wanting to pair because I was apparently making them feel stupid. They actually reported me to management for being an arrogant mansplainer. I'm pretty sure that was the beginning of the company deciding I was not a culture fit :P I had to learn how to, and how not to, work with someone less experienced in a certain topic after that.
This seems like its more of a hacker vs non-hacker mindset. Those of us that grew up with messing with computers and such daily, if we didn't know what the script did, would probably really appreciate someone giving an in depth explanation of the script line by line. People that want to just be hand held, and are not interested in how things actually work, wouldn't appreciate that. Sounds like the pair programmer was the latter.
I would love to hear how that resolved ultimately. And yet I am also a little bit scared as well. I feel like there are at least two or three stories simmering under the surface of that incident.
Like any story like this, you needed to be there to get the context.
One of the downsides of pair programming is that it's great when you both have complimentary skillsets. It's less productive when no one knows what the heck is going on. In this case, the task was to benchmark how many writes one could make to Kafka using our monolith. They wanted to see at least 10K/writes per second. The only problem was no one knew how to use Kafka (well), including the person who was asking for it.
So I wrote some gnarly looking Bash code to fire up Kafka, Zookeeper, the app, etc. Some people wanted to use Docker, but I didn't see the value in using a slower VM w/ limited resources. I wanted to use as much CPU as possible. My pair didn't know Docker, Bash, or Kafka. I lost my pair somewhere around talking about having to clean up zombie processes.
Thanks for sharing. Man I always love working with people smarter than I am, although I always feel a little bad for them. But it’s like leaving money on the table to not learn these things.
There was that incident when my students marched off to the Dean, complaining that I learned them too much. The kids have been screwed over by persistent underfunding of public schools and insist that they continue to be screwed further - what they want isn't an education but a degree certificate.
Yes, cultural fit is real, and it isn't always about white men drinking craft beer.
Could be more about how you communicate rather than what you are communicating. I love it when people explain difficult or unknown things to me, but if some one sounds like I'm burdening them or that they are incredibly displeased then it becomes a different experience.
I'm aware that the other person in your story could easily be the 'difficult one', but your post doesn't make it clear that you understand the way you communicate can be super important too. Not trying to accuse you of anything, just want to point out a super easy avenue of mistake.
I agree that build systems like CMake should be taught, but I'd put them in a course on C/C++ programming, not on a general course about Unix and the command line.
Builds work quite different in Java, for instance.
I broadly agree with having courses to teach the topics listed, but:
> Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
I was taught csh as an undergrad. A complete waste of time, in my opinion, akin to teaching BCPL rather than C. Just teach bash, and perhaps sh. To my knowledge, just about nobody writes scripts in csh, ksh, tcsh, or zsh. You use bash for portability across Unix systems, sh for even better portability across Unix systems, or you use a modern scripting language like Python3.
Students may benefit from learning zsh for interactive use, but I don't think there's enough benefit there to justify spending time teaching it.
I'm guessing the csh curriculum was just old. csh was developed as an improvement to sh (just like bash) that some circles coalesced around before everyone chose bash. I doubt it was that they saw everyone using today and said, fuck that, let's use csh.
My company still does intro lessons with ksh because it's set as the default shell on all of our servers.
If I had to guess, putting all those shells in the same basket sounds like they're focusing on the universal functionality. Such as pipes and redirection.
That's what I would imagine. I think think shells other than sh or bash are listed more to make students aware of their existence and to reinforce that, in unix, even something as seemingly fundamental as your shell is a self contained tool that can be swapped out for a variety of alternatives.
To extend to your comment, lightly examining a number of shells could also serve a few additional pedagogical functions:
* Showing students that there are many shells that they could encounter.
* Highlighting the differences.
* Showing that there is a long history.
* Showing that the history is still alive.
* Showing that there is no one right way.
Most of the places I've ended up working used tcsh (holdovers from Unix days). Both interactively and a large pile of small scripts. A few of us who were willing to troubleshoot ourselves would use Bash, Fish, or another shell interactively. None of the libraries were set up for Bash/sh so it was difficult to write scripts that weren't for personal use. It was an April Fool's joke that we were moving to Bash and I was bummed. I spent some personal time making our libraries agnostic (a bulk of the code was Python, but environment stuff shelled out or inherited from the tcsh scripts).
I think it's worth focusing on Bash, but at least contrasting it with csh and pointing out the lineage and other options. Perhaps spending some time writing some scripts in sh since there is a large install base of outdated or missing Bash.
I have no idea what schools think about this. I generally prefer deep knowledge in a single language, but there is value in learning a bunch of languages so picking up yet another new language is trivial. When I've spent too much time in one specific language I've found it harder to switch around.
I preferred Zsh for a long time because it was much nicer to program in than Bash. But Bash has since then picked up all of the Zsh features I cared about and is installed by default most of the time so I switched.
In my company the default shell in the UNIX accounts is csh, and tcsh is recommended as a "nicer" csh. They do have bash if you want to use it, but they only "support" csh and tcsh. As a result, many important scripts by engineers are written in csh/tcsh. People who've never used bash. Very annoying, as for those who choose to use bash are often told they have to go into tcsh to get a given program to work, etc.
I think it's more suited for informal study groups. To learn glue scripting and debugging you need playtime. What happened to MIT, students are too overworked to play?
To become a mature mathematician you need interaction with other mathematicians. To become a passable bash programmer a book and a jar of aspirin is enough.
I think that's right if you already know how to use a shell, but if you don't yet know how to use any shell, or even know what a shell is, the bash book is not going to do you any favors.
Imagine handing this to a person who's never heard of a shell, doesn't know how to `cd` or `ls`:
> At its base, a shell is simply a macro processor that executes commands. The term macro processor means functionality where text and symbols are expanded to create larger expressions.
> A Unix shell is both a command interpreter and a programming language. As a command interpreter, the shell provides the user interface to the rich set of GNU utilities. The programming language features allow these utilities to be combined. Files containing commands can be created, and become commands themselves. These new commands have the same status as system commands in directories such as /bin, allowing users or groups to establish custom environments to automate their common tasks.
In school we were programming in Turbo-Pascal, so I had some exposure and then took a week-long Unix evening course at my university's computer center. So that was helpful. But you are right, for someone who hasn't done much hands-on computering a semester-long introductory lab to get everyone to the same speed.
My undergraduate advisor said since the second-semester lab was the basic lab, the first-semester lab had to be the basement lab.
I taught intro programming twice this year. Having never taught a CS class at all (I am a math phd)... I would just like to point out that at least at "satellite state U", most students are not like you.
The class almost went off the rails the first time before I realized half the students didn't know what a text editor or shell was. I ended up writing a document at a slightly lower level than this "missing semester" course (though taking some inspiration from it).
If I teach the course again, I plan to do one week shell bootcamp with "get to know your system" exercises spread throughout.
I wouldn't make it a degree requirement. A lot of student may already know a lot of it or may be fine with picking it up on the side. But I don't really have an issue with presenting everything you need to know about programming 101 for people entering CS who don't have a lot of experience with using computers under their belt. If someone really doesn't have experience, they also don't really know what they don't know.
College is in large part about covering (4) and turning it into (2) or (1). You're describing turning (2) into (1) - you need to know what to Google in the first place.
I've heard some courses require submitting assignments via git, and that's something that makes a lot of sense. I wish everywhere would do that.
Even if (at first) students just do a single `git add --all && git commit -m "finished project"` it goes a long way to just exposing people to the concepts. Provided the infrastructure is in place (eg GitHub or gitlab instance), it really isn't much different than dealing with a zip file, but provides 10x the educational value.
Bonus points to the prof that builds assignments that involve git branching from an earlier assignment.
All freshmen? Or only CS candidates? If it's the former, that seems like a giant waste for most of the people in the class and requiring any additional basic sciences or math course would likely be more beneficial.
Maybe it's my smug sense of intellectual superiority, but if I could go back and do university again, I'd still rather learn language theory and discrete algebra than how to use vim and tmux (neither of which I use more than once a month).
I didn't study Computer Science to learn how to write bash scripts.
The good ones are really CS + one extra year worth of projects and practical coursework, like learning what Agile is, Source Control, Build Systems and so on.
So I actually took this class in 2018. Unfortunately I don’t think it’s good enough just yet.
CS 193 was a very low effort class (1cr), where you could follow the command by command instructions and perform all the tasks necessary to pass.
Unfortunately tools like git, vim, and shells all possess philosophies and concepts that are very hard to grasp without context, and constant use.
We were on multiple occasions told the mantra, add-commit-push, which I will say is enough for basic git usage, but since pretty much none of the subsequent classes used git to any capacity, I would assume many students lost all familiarity within the next semester (Makefiles that automatically git added and pushed code were used for submitting code).
I also think most people were hindered by vim, lacking sufficient instruction but still being presented it as the primary option.
I think if you’re going to implement a similar class / program, the tools really have to have uptake beyond a single course.
Sidenote, the different shell types weren’t covered in my semester, we just used bash / dash.
That’s interesting (and definitely unsurprising) to hear! I think freshman year might be a bit too early to appreciate the curriculum, before students have seen how ubiquitous some of these tools are in engineering jobs. Maybe it would be better spread out over time.
I think the trade-off on timing here is with internships during the summer after freshman year. I think you’ll have a much better chance of success if you’re at least roughly familiar with these workflows vs. interns who are totally unfamiliar with version control systems, for example. And perhaps that’s all the course is meant to accomplish at 1cr.
Seems like these are more subjects for "software engineering" or some other kind of pre-professional major, as opposed to CS. Obviously not every program makes that distinction, but personally I like the idea of CS being primarily academic.
Yes, that is a good point. But by analogy, should an English major receive credit towards their major for a course in word processing, or is it just something that they should be expected to pick up along the way?
It wouldn't be a bad idea to teach kids how to create a professional environment on their computer, but at the same time, the tooling around programming environments is much more complicated than a word processor and it's extremely valuable to teach the basics for credit.
There might be issues of access. It may be possible to go through school without ever having to break out of a GUI to do CLI commands, whereas it may be impossible to graduate from high school without ever typing an essay on word/docs/etc etc.
I don't think the emphasis of something like this is about writing code in a work environment but to help productivity for CS students when they write code in an academic environment - I would imagine that even highly theoretical/maths oriented courses CS courses still involve a lot of coding - mine certainly did.
The only thing that seems missing is document preparation - presumably using LaTeX (we had to use troff, which was 'fun').
roff et al are about the only thing I don't miss about early Unix. I had a job in the late 80s doing document editing/preparation for a CS professor, and some was TeX and fun and some was nroff or some such and not fun. Even had some special transforms you had to hook into the generate output pipeline.
That'd be a great distinction to make, but as far as I can tell, 90%+ of colleges offer and treat CS and "the degree you take to become a professional programmer." I feel it does a disservice to both CS as a fascinating academic discipline and Software Engineering as an important career-oriented discipline, but until more places start offering both, I think CS programs can really benefit from more SE content like this.
Good point. I think it is pretty common for schools (particularly community colleges or regional universities that primarily serve commuters) to offer programs in "Information Technology," but these may be substantially less rigorous than what might be required for a career as a programmer. It would be great to have more programs to serve the gap between IT and academic, research-focused CS. Right now this seems to be filled by master's degrees that come after a CS education and focus on pre-professional skills (based on the resumes I see).
The CS vs Software Engineering distinction make sense, but we're at a point where even the most hard-core academic theoretical CS types are writing large quantities of code. I've worked with professors who desperately needed to take this kind of course, let alone undergrads.
I enjoyed these over several lunch breaks last year. Recommend it for both beginning and experienced developers/CSers. It’s casual and highly approachable.
I still remember being in my AI class and having the teacher say "This course is taught in LISP. We'll be spending one class on the peculiarities of our system, but otherwise you're on your own. If you don't learn it, you'll fail."
They did eventually realize that teaching some of the basics would actually make for more successful students, and better alumni donations.
In the end, the CS Dept. started offering these things as zero-credit courses as a way to square the circle.
It’s funny - I can’t think of an equivalent for that sort of thing in any other major. Of course, most other students don’t go in to their major with as much knowledge and experience as a good portion of CS students do.
The one big exception I can think of is the arts. But they usually require an audition or portfolio for acceptance. CS majors take anyone but then not until first week of classes is it clear how much pre-reqs are expected.
My experience was the opposite. The learning curve for CS classes is steep, but you can go in with zero knowledge. When I took music theory, there was a hard requirement for vocal training experience and I was rather shocked that such an important and uncommon thing was just taken for granted.
Oh, music majors in particular are a really good comparison. Though at least music instruction is available in most US school systems over a span of several years, as an ordinary during-school-hours class. Then again if that's the only instruction you've had, you're probably still starting out (maybe hopelessly) behind those who had private lessons outside of school, who are likely the real intended candidates of such programs, and you might not even be able to get into a good program.
[EDIT] incidentally, the arts are also infamous for being dominated, at a professional level, by kids with artist parents and kids with rich parents (who can bankroll years of private lessons and then years of little-to-no income while paying for access to career-makers) so... there's that.
My freshman year of college I took a music course - 'music 101' or something like that. I'd played sax, then guitar and piano, for ... 5-6 years, could read music, write a bit (notation, etc) - took a music theory class in high school - wanted to dive in more.
Of the 22 people in the class, 21 of them were singers - everyone except me. Much of the class was around singing - singing scales, etc. I saw nothing in the syllabus that required singing, but... you had to learn to sing stuff by sight reading, and... I'm not a singer. It was embarrassing for me (and probably for others). I think I managed to drop out before losing all my money on that, but... frustrating. Could also tell most of these people had had voice lessons for years, and were all taking this class as a way of getting in to theater work, not... to play an instrument.
You can get accepted to a music degree for some majors such as composition without prior proven knowledge but you'd need to do a summer class or similar to learn music theory. It would be rough if you think to learn in a couple of months what most musicians take years, but a friend of mine managed and 2 decades later he's head of the school.
All liberal arts degrees at UVA require 2 writing courses. The first course is required to be taken in your first year. The second is strongly encouraged to be taken in your second year.
That feels roughly analogous to a CS department requiring a "*nix skills" course or similar, as most liberal arts degrees require a substantial amount of writing.
I assume music (and possibly some fine arts) would require some background in those subjects. They often require a portfolio or audition before entering the program.
Do engineering programs expect students to have taken calculus?
Though with music (and possibly engineering), you likely have to prove ability prior to being accepted into the program.
It struck me in college that CS departments are getting away with assuming a lot of background familiarity with computers from their incoming freshmen, picked up on those freshmen's own time, in a way that I don't think any other departments do.
I don't know how people coming in not having sunk thousands of hours into computer crap before entering a CS major don't drown in a hurry. It'd be like starting a creative writing degree in a world where reading & writing aren't taught in school, except maybe as a one-semester high school elective, and you're just expected to have picked them up on your own time by age 18, if you're going to be a creative writing major. "OK, you're familiar with stories from watching TV, but now you're going to need to read and write them. If you can't read them here's a book(!) to help you learn to read, in you own time. Good luck anyone who wasn't already a long-time reading-and-writing nerd before choosing this major".
I felt very out of place in my college CS classes. I picked up programming my freshman year and switched to CS from my original major. I was completely green while so many other students - what felt like a majority - had been programming for years and were already extremely familiar with many of the concepts and tools that I was just being introduced to. It was rough for me to feel like I was starting out at such a disadvantage.
I was just thinking about this more, and CS programs kinda remind me more of college sports programs than traditional college majors: if you haven't spent years playing the sport before going to college, you're probably gonna have a bad time. Can you still do it? Maybe, but... damn, it's going to be hard, and take some unusual levels of determination.
Of course some of the problem is that CS programs use computers so much. Which I know may seem like a silly complaint, but I think the fundamental issue is CS-the-science being mashed together with what's really a vocational program (which is what 99+% of students and employers actually want out of it, and its being "real" CS is mostly just an IQ filter). I imagine if you go into, say, a junior college HVAC program not knowing which is the business end of a screwdriver, you'd also be at a big disadvantage compared with most of your peers, and probably feel really out-of-place for quite a while.
Sports or the arts. You probably don't major in music in college if you've never touched a musical instrument.
I took MIT's "Intro" to Programming and Algorithms I think it was called (6.001). I'm not a professional developer but I've written a fair bit of code including Python which is what the class used. I'm pretty sure that, as an undergraduate, had I never seriously used a computer command line before, there is no way I could have gotten through that course.
The same dynamic is largely missing from other engineering courses, as well as the sciences, which don't really expect more than high school classroom work, an interest, and general aptitude.
And it's certainly true that CS (the math degree) gets munged with CS (the engineering degree). MIT's a bit more engineering focused (the degree is in the engineering school). There are also some variants of the degree that are more or less engineering-centric.
To dip my toe into somewhat-dangerous waters, I suspect that if there's a major and highly effective filter other than simple interest (as some data re: more- and less-restrictive societies suggests) keeping women out of CS, it's mainly this preference (by CS programs) for experienced long-time computer geeks in CS freshmen classes, and hostility to those who aren't. Which is still, kind-of, an interest-related filter, but a bit of an odd and harsh one that punishes not having taken a strong interest very early.
You're not going to meet that kind of abrupt and early resistance on the path to becoming a doctor because you didn't spend tons of your free time as far back as junior high reading anatomy books or practicing dissection, for instance.
I don't think it's the only factor but it's been my belief for a long time that it's one factor. If you assume 18 year olds entering CS programs started to widely use computers and game consoles as kids in the mid to late 80s, that lines up well with the decline in women entering CS. [1]
Again, there are almost certainly other factors, and correlation is not causation, but there is at least logical correlation.
To your broader point, a lot of kids enter college with only a broad idea of what they want to do. And high school courses don't really offer much guidance. High school science classes have very little to do with their counterparts at good colleges.
Right, agreed on that not being the only factor, but I do think it's suspiciously-sufficient-looking to explain why CS was becoming a boys' club even as women were reaching parity with men in terms of proportion-of-the-sexes in medicine and law, and to some extent business more generally. "Computer nerds are so remarkably and uniquely sexist that they not only avoided this trend, but sharply reversed it" has never... quite rung true to me. Again (because you have to over-specify on this topic or risk angering people) not because there's no sexism among computer nerds or computer companies, but just because I don't get why programming/CS would be uniquely afflicted with that, to such an apparently huge—in order to explain the sharp difference—degree.
Meanwhile there are definitely a lot of gatekeeping-assumptions about childhood interests in modern CS programs, which one would expect to have gotten stronger as more and more freshmen actually could have had experience with computers on their own—so, starting with late-80s freshmen, mostly, with the effect getting stronger fast after that. That lines up so well with the data on CS-program-enrollment-by-sex that it seems to me like the factor to examine before we go looking for other explanations. Again, to be excessively explicit due to the topic, I mean this in terms of accounting for the gender gap in programming, not in terms of addressing any other issues of sexism in the industry, which I am not denying exist.
There are some fields--notably within engineering, mechanical engineering--where women have historically had low participation. But one probably doesn't need to examine gender stereotypes too deeply to see why that might be the case. But there haven't been the large shifts there we've seen with CS.
> You're not going to meet that kind of abrupt and early resistance on the path to becoming a doctor
It's much more inclusive indeed. If you can afford the mandatory completely unrelated undergrad you need to have completed to even apply to med school and the travel fees to attend your in-person interviews of course.
Yeah, the educational commitment is definitely much higher. I just mean they don't expect you to have put hundreds of evenings, Saturdays, and Summer afternoons into wholly-self-motivated learning about the field by the time you're 18, or else have a very rough first couple years.
> I just mean they don't expect you to have put hundreds of evenings, Saturdays, and Summer afternoons into wholly-self-motivated learning about the field
No, instead it's unrelated to the field so you can grind fractions of GPAs against other applicants. At least, CS is kind enough to let everyone try the real thing.
> I'm pretty sure that, as an undergraduate, had I never seriously used a computer command line before, there is no way I could have gotten through that course.
I'm very well familiar with the firehose :-) But mechanical engineering there, for example, did not require anything more than 1.) The ability to get into MIT and 2.) The normal high school curriculum. It didn't require years of experience in stripping down engines and rebuilding them. and, OK, 3.) Dealing with the firehose. :-)
> I picked up programming my freshman year and switched to CS from my original major. I was completely green while so many other students - what felt like a majority - had been programming for years
There's been some research on this and places like Harvey Mudd solve this basically by dividing the incoming freshmen into 'has any experience at all programming' and 'completely new', which was like 50-50 if I recall. And then tweaking assignments to not be video game focused -- pulling in problems & themes from bioinformatics and other fields instead.
>And then tweaking assignments to not be video game focused
Our only program of any significance in CS101 was a space invaders clone, but because we were so inexperienced, they provided a project template where we really just had to fill in some methods with a bunch of for-loops. When we got to the later courses and had to write our programs from scratch, we really had no idea where to begin because the 101 coursework had done all of that for us.
The video game assignments were asinine because they were beyond our skill level to do from scratch, so their templates handled all the I/O for us and that part of the program was treated like a bunch of magical incantations. As a result, we never fully internalized how all the moving parts fit together, and it kept us from learning useful stuff like how to read/write from files or execute system commands.
More generally some departments, including CS but not only, get away with picking above average students in a given college and letting other departments get the below average students, through things like "weed out courses" or not teaching actually 101 courses but "assuming a lot of background familiarity with computers", to quote what you say.
Difficulty of any given program at the undergraduate level is completely dependent on university policy. Maybe at the research level, you truly need to be more intelligent / harder working / whatever to succeed in math than in art history, but at the college level, you could do for instance:
- cram all that is taught in current undergrad, MA, and PhD (including the thesis) for art history in 4 years
- let CS students graduate if they can write any working program in any language of their choice
Tada! Art history is now the hardest degree in the college where only the best students aren't weeded out out; and CS is the easiest degree there is.
My point being that CS departments assuming prior levels of CS unlike other departments is merely an instance of a larger pattern.
When I was undergrad, I took a Fortran course. It was basically an intro programming course for non-CS engineering majors. I had taken some BASIC senior year of high school but this course was really literally: We assume you have never touched a computer before. It was 1976, so not a bad assumption.
I'm sure it would be considered a laughable course to teach at an elite school today. (OK. It was a bit harder because we were using punch cards and we had to beg for more computer cycles if we made too many typing errors, but still.) But I'm pretty sure it wasn't because we were a lot dumber back then.
I agree with your basic point though some students do freeze up with even relatively easy math. But, yes, you could put together a relatively easy programming course and call it CS. And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
> I agree with your basic point though some students do freeze up with even relatively easy math.
That's the opposite of my point, really.
> And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
My point was about the "within university" variance of student levels rather than the "between university" variance. I have no doubt that a liberal arts programs in a good university is more selective than the CS program at a particularly non selective university. However, within any given college, I'd be surprised if the liberal arts program manage to get the above average students and the CS/Math/... programs get the below average students.
Yeah, I had a friend in college who switched majors after constantly comparing themselves to the rest of the class, when a good chunk of us had been programming since our early teens and they had never written a line of code before their first class. It was a bit sad because they were actually doing fine (IMO), but always felt behind because they were comparing against students with years of head start.
I added cs as a second major in my junior year, and I felt that way at first in the java based 101 course. I had actually been using linux since I was a freshman in highschool (before graphical installers were around), and had picked up emacs to use tex-mode for my philosophy papers. But using Java in Eclipse felt completely foreign to me, and I wasn't sure I was going to like CS because of it.
It wasn't until I got past the first few java heavy intro courses that I realized I had a huge leg up on a lot of the other students that only had experience with Windows or Mac. Before that I felt like I was behind behind the curve because I was stubbornly writing Java in emacs because I couldn't stand how dogshit slow Eclipse was, so I didn't have the advantage of the code-completion or project management features.
Looking back on it, the curriculum was actually just holding most students back even further and by using emacs and managing my projects from the command line, I was just increasing the lead I already had over students that didn't have linux experience.
It makes complete sense depending on the time. My first advisor in grad school was a more traditional "cog sci / comp sci" phd and then I took a "data mining" grad-level course, but aside from that I'm a complete outsider to the field, but here's my take:
Since the 70s, AI was dominated by lisps and nearly everybody was driving at "general" AI by emulating or even attempting to simulate human thought processes.
In the 00s people started putting more weight behind statistical / stochastic methods for arriving at answers without necessarily trying to use any model of human cognition. This was called "data mining" and then "machine learning" (partly, I presume, to distance it from the 40 years of academia's dismal failure to produce working AI) and only in the last ~5 years has it come around to people starting to use the term "artificial intelligence" again.
In the early days of the revamp, it was common to see janky perl and fortran and not much structure holding it all together. Lately, I gather, the ecosystem is nearly entirely python-centric, but this is due to the gravity well around pandas. There's nothing in particular about python that makes it suitable to the task, though it is happily more approachable/accessible for academics than if a pandas equivalent had instead evolved in C++ or Java.
Lol.. I had the same version of that class but in Haskell. There were basically zero books on the topic at the time too and we didn't have internet in our dorm rooms. It was a mess.
I actually hold the opposite opinion: For an advanced class such as AI (I assume you at least need to work on Data Structures before that), students should be comfortable to learn whatever language and tools they need to succeed in a couple of weeks, and even less if needed. They should be able to grasp the basic in a few days and gradually improve their knowledge about the tools and languages along the way. After all I have never seen a univeristy course that assumes excellent grasp of a language.
It is very sad that we need to take two entry level programming language classes in the first year. My university does not allow me to remove it as it's the pre-requisite of pretty much everything else. And I can't "prove" that I know Java, which I didn't but I'm confident that I can get the basics going in one day and the basic-medium stuffs in a week because I already know some C, C++ and Python.
The only class that I think should teach programming languages should be a PL class. An introductive one usually teaches three or more languages in one shot with each an example of a paradigm.
BTW the zero-credit courses sound like an excellent idea. Students do not get credits but still get education out of them. It's a great practice.
The college I went to they would bundle these sorts of classes into other ones. For example my 'C' class was also a how to get around in unix class and it was 1 day a week. But they also had pre-reqs so you had to have the 3 other classes first before you could do that one. So they could assume a particular level of education. When you are on your 2nd or 3rd language sometimes you are not sure what is important in a new one. So sometimes it takes a bit longer to learn. Now having a few under my belt I have a good idea which bits to look at first in a language. If all you knew was java and it was 1-2 classes of it, then being dumped into lisp and picking it up in 2-3 weeks would be a challenge for many.
Java as a language is actually tiny. So are most languages. Most of the pain is in the tools, build chains, and libraries that go along with them. Also sometimes what works very well in one lang is a pain in another. For example the dictionary in python has no real equivalent in C, unless you use some lib or write something yourself. In java you would need a map or hashmap class and knowing it exists sometimes is the biggest hurdle. But at least it is in the std library. So sometimes those sharp edges bite students as they are first starting with new langs and have decent exp in another language.
I agree with you to an extent, but learning lisp is a bit more involved than just picking up another programming language; it's learning to program in a completely new paradigm. I think it's perfectly reasonable to expect students to pick up things like syntax and standard libraries on their own, but to expect everyone to seamlessly pick up the functional paradigm with no help from the instructor is a bit much. For something like this there should be at least one lecture that goes over some of the fundamentals of functional programming and gives students the vocabulary they'll need to find the solutions to any roadblocks they run into.
> "This course is taught in LISP. We'll be spending one class on the peculiarities of our system, but otherwise you're on your own. If you don't learn it, you'll fail."
SCIP (well loved on HN) was designed for as the introductory class for freshpersons who'd never seen a computer before (which was the default case when the course was designed).
The first lecture was about how to program in lisp, using the example of symbolic differentiation. That one lecture was 100% of the introduction to computers and programming: the rest of the semester was spent on computer science.
This is a great list of things which you do use a lot as you get into a job, but not at all when doing class work.
Version control is the most common thing I have to teach interns in general & that too remote version control usage - particularly my "oops, I dropped my laptop after 3 weeks" story.
Git makes that curve a lot less complex to deal with (no server setups).
The other bit I tend to drill down into is about writing graphviz files for everything.
Mostly what I do is generate code and documentation out of one system - but often, I dump out things in some arbitrary format, only to process it in python in to a graphviz diagram or in some cases some more fancy svg stuff (outputting direct D3.js is better, for something like a Sankey diagram for data-flows).
Like this[1] is a way to discuss a problem with a cycle in a DAG, instead of whiteboarding it out, particularly if your work-mates are going to be remote.
At my school (Macalester), we use git(and GitHub classrooms) in the intro class. It doesn't have to include the more complex stuff like rebase, merge conflict.
This way, as a TA, I can also code review them and it also deters plagarization.
If I may nitpick (and really, if you can't nitpick on HN, where can you?), their definition of Metaprogramming seems weird. The subheadings are build systems, package management, and CI/CD, whereas I've always heard "metaprogramming" as a general term to cover reflection, macros, introspection, and similar concepts. Have I got the wrong definition or do they?
You don't have the wrong definition, I had the same thought as you. They are definitely using a non-standard definition of that term, although I suppose it makes some sense if you look at it the right way (sort of like "metadata" in a way).
I thought that was a peculiar choice of words as well. I would understand these things under the banner of "Build Engineering", or even just "Tooling". I couldn't figure out the distinction they wanted to make by calling it "Metaprogramming".
I majored in Chemistry, and we had a similar course on how to use library resources and tools to research. Since it was not directly Chemistry, the advisor said you could wait until your senior year to take it as an easy final semester credit, and that is when I took it.
I should have taken it first semester, freshman year. It was full of invaluable meta information which would have made my four years not only easier, but more productive. I may have even stayed in Chemistry if I had the correct tools from the start.
I am largely self taught when it comes to CS, and so I learned these tools first from a practical application. I didn't have anyone to set up a dev environment for me; I had to do it myself. I am always shocked when I work with new grads from top CS schools who have almost no knowledge of basic tools like grep or how to use an interactive debugger.
Theories and academia are nice, but are a fair stretch from the real world in any field. If we really want to require an advanced degree to enter the work force, then we should abandon the idea that most students attend college for a liberal education and accept they reality that students attend college for workforce preparation.
This should be one of the FIRST classes for anyone in the sciences, not just CS. Biology, Physics, Mechanical Engineering, etc.
A couple areas I would add
* How to ask questions [1]
* How to debug problems, control, hypothesis, baseline
* Reproducible research [3]
* The Art of Doing Science and Engineering - Learning to Learn, Richard Hamming [4]
* How to Solve It, George Polya [5]
* How to work in teams, collaborate?
I fully agree. During my own studies of computer science the common excuse / pretext for not lecturing such useful things was that tools get outdated quickly.
Now that I am back again in university (of Applied Sciences) as a lecturer, I dedicate a whole lecture for such things. Students' and alumni's feedback was quite positive so far.
> A lot of it isn't "computer science." But until you get this stuff down you won't be doing day-to-day development very well.
This is the main issue in my view. CS isn't development. CS is research, development is application. I'm a software engineer and I would never call what I do CS. Things are going to be clunky and awkward until schools split CS from Software Engineering, like they do with other sciences and their applications.
They won't split those until employers start favoring SE degrees over CS degrees for actual SE jobs. I don't expect them to do that as long as CS is regarded as more difficult and CS degree-holders remain in plentiful supply, as they're more interested in the degree's utility as a candidate filter than what the students learn. Probably a good SE program would produce candidates far more valuable to these companies, as far as what the classes teach, except that the best candidates will keep going into CS for (valid!) signaling reasons.
They do at San Jose State University. CS is part of the college of science, as is math. The college of engineering offers both computer engineering and software engineering majors.
This is fantastic. When my alma mater asked for feedback on my education received, I had let them know it would be helpful for students to learn about exactly the topics listed in this course (though I was already quite familiar with a lot of those topics as I self-studied programming at an early age), in addition to theory. It tends to be more valued in the workplace once you get past the DS/Alg interview gates.
An immediate flaw with this course is only suggesting VIM. Why not Emacs and Nano? I despise VIM and absolutely adore Emacs, but after getting emacs pinky have transitioned to nano for light editing needs, Sublime for universal productivity, and Intellij for Java development.
If you're only going to teach one editor, why an editor that's so arcane in comparison to something similar to a text editor like Sublime or Atom? If you're going for a terminal-compatible editor, why not Emacs or Nano? If you want the most workplace-ready tool, why not Intellij or VS Code? And my main question, why not at least teach a few and empower the users to really explore and find the best tools for them? To me this smells of people who don't want to help students equip themselves for success and instead want to teach them the "right" way to do things.
I had some emacs pinky and for a while had a script setup to make the spacebar plus a key act as control (releasing spacebar without a key pressed would just be a space). Eventually I recovered and learned to be more gentle with my pinky.
Ah, I didn't look at the dates. For those who don't know, IAP is Independent Activities Period and there are lots of talks, credit and non-credit courses and mini courses, other activities and so forth. So this is a perfect thing to slide in there.
Back in my day we were "real programmers" and edited files by precisely waving magnets over our hard disks. Sure we still had some dinosaurs around that longed for the days of swapping out sector gears on their difference engines, but they were harmless enough so we kept them around for the amusement.
If you read the article, you'll see their explanation: Vim is the most popular command-line editor (from a Stack Overflow survey) and all of the instructors know how to use it. The course is pretty *nix based so it makes sense to pick a command line editor and focus on it.
Pragmatically, Emacs is usually not installed by default on Linux systems and Nano sometimes isn't. If you had to pick a command-line editor to teach, Vi/Vim is probably the safest bet.
Emacs is where ever I control the base images. But yeah, vi (if not vim) is ubiquitous. And honestly, the "time to be able to edit basic files and do basic stuff" is shorter for vi than emacs. If only because emacs documentation wants you to understand their 1980s conceptual framework before telling you the keystrokes you need.
Emacs is like 10x the size of Vim (and also a lot bigger than nano). It’s rare that I ship a editor unless the OS already had one installed, but I don’t think I’d ship emacs if I needed one.
(Unless you mean for workstations or servers people constantly log into, as I’m thinking of containers).
And that isn't even an issue in practice for emacs users. We're going to use tramp for most things, and are comfortable enough with vi or nano to do any quick edits over shh. But having students try to learn emacs while setting up tramp is a bit much to ask when learning the basics of ssh and vi works just fine. It also doesn't risk students getting confused about the unix fundamentals by throwing emacs–a lisp machine masquerading as an editor–into the mix.
My wife had been a software engineer in the 90s and now is a painter. When we met, she had a brief idea to return to programming (she is PhD physicist also, so certainly smart enough). I had only recently met her, and I was so happy, I set up emacs, scheme, and the Structure and Interpretation of Computer Programs for her and tried to explain how awesome and sensible it all was. Not a good idea, we barely survived that relationship error. She did laugh at it recently (about 7 years later). I still maintain that SICP is essential reading, but only say it at parties.
I learned emacs over some months; I had a job as the IT support guy and I wanted to become a Unix C developer, so I grabbed an unused HPUX workstation, sent all my email to emacs, and then spent months learning how to use it. Probably six months before I was using it decently well.
Yeah, I feel like a lot of us emacs users have been using it for so long that we don't even realize how different even the basics feel to people that are used to doing things the 'new fashioned' way. I picked it up after reading all of Steve Yegge's emacs blog rants, so I already had my interest peaked and had a good idea what I was getting myself into. I also wasn't expecting to get any serious work done with it, I was just curious about lisp and functional programming and wanted to dick around with emacs to see what all the fuss was about. After that I was hooked. I count all the hours of rewriting my emacs configs from scratch or typing in every function from SICP as time well 'wasted', but I fully understand why not everyone considers that type of thing to be something fun to do on a lazy Sunday.
Well, for containers, I'll read the source code/Dockerfiles in my local emacs, and download the logs from where ever, so yeah I don't put emacs into the containers. But I maintain VM base images and they all have emacs. In the container, I like to put in tcpdump and strace and like tcptraceroute and that sort of thing. But hoping for a life where containers never need checking on their compute/network/memory issues.
The elisp concepts are good, but which things are windows and frames and buffers is just a bit esoteric now. And they are dogmatic in tone that you shouldn't be able to work without passing some sort of worthiness test.
I wouldn't say they're esoteric, but there is a learning curve because they're incongruent with the UI we've been taught by our graphical desktop environments. I do concede the somewhat dogmatic tone, but that's honestly just par for the course with any GNU software, though emacs is for sure one of the worst offenders. I still love it though, but wouldn't recommend it to anyone that isn't already expressing interest in giving it a try.
The point of the course is to teach CS students how to use their tools. Are they expected to only use tools available on every single linux system by default? Are they also expected to not download anything else that isn't universal across unix systems? Not being aggressive, just pointing out how I think it's still a biased choice. I despise Vim but I wouldn't teach Sublime-only, I'd give a brief overview of vim, emacs, sublime, vs code, and let students choose.
Wild guess: the purpose of that module is to learn how to use a real editor on the command line. Which is available everywhere and has been installed by default on nearly every environment I've ever logged in to. Not to broadly introduce the many editors we have available in the world.
Well, they answer this:
"Visual Studio Code is the most popular editor. Vim is the most popular command-line-based editor.... All the instructors of this class use Vim as their editor. Vim has a rich history; it originated from the Vi editor (1976), and it’s still being developed today. Vim has some really neat ideas behind it, and for this reason, lots of tools support a Vim emulation mode (for example, 1.4 million people have installed Vim emulation for VS code). Vim is probably worth learning even if you finally end up switching to some other text editor."
So, basically, it's popular, useful, and they know it. But, even before saying that they provide this caveat: "As programmers, we spend most of our time editing code, so it’s worth investing time mastering an editor that fits your needs." Then they devote a little of time explaining how to best learn any editor.
Also, in the QA they say "The three of us use vim as our primary editor but Emacs is also a good alternative and it’s worth trying both to see which works better for you.... An advantage of using Emacs is that extensions can be implemented in Lisp, a better scripting language than vimscript, Vim’s default scripting language."
There are vim bindings in most (if not all) popular IDEs so learning the base keystrokes can be lifted up to these at a later point.
They did explain that they based there decision based off the most popular command line editor (based on a stack overflow survey). Although it would probably be good to at least reference other popular / useful ones for exploratory purposes, for a quick overview course I think focusing on vim makes ample sense.
Emacs bindings are also included by default in unix and Mac across all text fields, including browsers. Not arguing, just pointing out that I still think it's intellectually lazy. I detest vim every time I use it, and even when I was a CS student it wasn't that difficult to just learn how to use emacs or notepad++. The hard part is gaining the awareness, and that's what I would imagine one of the goals of teaching should be.
In the last two lectures (Potpourri, Q&A), they actually have a grad student that uses Emacs go over it as well. The TA that was in charge of the editor section was just a Vim user and he wanted to show what kind of things are possible with a highly configurable editor like Vim/Emacs, so he naturally was going to use what he was most comfortable with. He even mentions that Emacs is capable of doing pretty much everything that he goes over in his demo and that it's mostly a matter of personal preference.
I suspect I'm not the only one who was introduced to vim because it's the default for git. This alone makes it good CS101 stuff.
I don't think they really advocate for vim to be your daily driver for all editor needs. Just a "you should know a thing or two about what this is because you're going to be lost the first time git shoves you into a vim editor" sort of thing.
It's a student run course, so I assume one of the reason they selected VIM is that instructors were proficient in it.
It's also one of the few modal editors out there, and that's a different paradigm students might not have been exposed to. In comparison, Emacs is much more similar to Sublime or VSCode (always insert, functions invoked via shortcuts).
Later in life I took a coding bootcamp as part of a career change.
One of the students I was friends with was much younger than me, smart kid, very good in the camp, still college age / situation in life, and after the bootcamp he decided to go back to school for a CS degree after some "hey you're more than capable of qualifying for a lot of scholarships" type discussions.
Anyway we met up a while later and he described how he was in these classes with theory and various languages and so on.
Then the students would do projects together and they'd look at him like he was a wizard with what were fairly rudimentary debugging but still similar skills to what us described in 'the missing semester of CS education', or at the very least the ability / lack of fear to pick them up fast (something that if you're good at it is super handy in a fast moving boot camp).
I remember when I was in college (dropped out for a variety of reasons) I really hated theory or 'just learn this focused thing you'll understand later' type classes when I just couldn't see ... the end use / test that end use in front of my face.
It occurred to us that a sort of 'full stack light' boot camp almost would be a good intro to some of these deeper programs. Even if just to give some level of ... practicality / way of testing / seeing output ... etc.
No doubt that many schools / departments would be averse to such a system for a lot of reasons. Even the bootcamp I went to was hosted by the same large university... but was sourced bought from some outside company and had NO association with the CS and similar departments.
I think we are at the tipping point where for many roles in many organizations a Bootcamp grad is no longer just an alternative pipeline to hire with some caveats but increasingly the better hire.
At a larger tech co I am consistently seeing boot campers coming in better prepared and with more hustle than CS grads. It would be interesting to see if their acceleration through the ranks is on average faster. It definitely is from my anecdotal experience.
What I've seen with Bootcamps is that they know one stack and how to do one thing only. They are really productive in that one stack but lack the more fundamental understanding that CS grads have.
When it comes to learning a new stack, technique or solving harder problems, the CS students run in circle around bootcamp grads. But to the non-technical manager, they see the bootcamp kids writing code on day one so they naively assume they are better.
Well, the parent did add a "for many roles" caveat. A CS degree is almost certainly better for a multi-decade career arc, and it's a solid foundation for many different career paths, but I don't think you need to have people with CS degrees in every role that involves writing code.
I'd be surprised if the bootcamp hires weren't better in the short term for specialized lower-level roles using newer tech. But many of the bootcamp learnings will be obsolete in 5 years; CS fundamentals are obviously more timeless.
I would push back a bit on this. Bootcamps are established and have records going back about a decade now. While I am sure some never re-skill. I don't think it is an endemic problem to bootcamps more than other backgrounds.
I know bootcamp grads that are now staff level engineers at FAANG or equivalent companies (based on levels.fyi pay bands). The money is in the bank. The RSUs are vested. They are only in it because they want to be at this point
Obviously not most boot campers but most engineers of any kind regardless of background wont reach that level.
In my experience that is not the case. Increasingly the CS grads know a lot of CS and related trivia while the bootcamp grads are fearlessly able to jump into things and figure it out. Most of what BigTechCos use is non-standard anyway. BigQuery, Scala, GCP, etc. people who bias towards a FFIO mindset will be better and often Bootcampers (especially the ones solid enough to get hired) have that in spades and are hungry.
I have never seen a CS student "run circles" around a bootcamp grad after equivalent experience.
It is telling that "The Missing Semester of CS ed" would be laughably basic to most boot campers and last I checked would be done as part of the pre-work to get into the bootcamp to begin with.
Side note: The bootcamps around today are much much better than 5 years ago. They are iterating rapidly.
To clarify I think the biggest driver is how driven and self-taught the individual developer is. I don't think going through the paces of a bootcamp or CS degree is a great indicator in and of itself and all else equal IMO the bootcamp wins there.
The best people I have worked with have been HS dropouts (fully self taught), MIT and a CMU grad who were very self taught before their program, and bootcamp grads who pivoted from other fields (oddly music, fine arts, and a standup comic. Maybe because in those fields being "good" is completely insufficient and they bring a "must be the best" mindset?)
A similar issue: I have seen multiple bootcamp grads get stuck for days on things like a bug caused by the difference between deep/shallow copy because they were never exposed to that basic CS concept. To their credit as soon as I explained what the difference was they seemed to get it immediately (identifying where to fix the bug on their own), but it's like... Only learning just what they needed for the bootcamp left a lot of gaps and a lot of them just seem to have no idea how much is out there.
i.e. the crap I have to teach (or tell to self-teach) 95% of people who are taking on a programming role.
While I understand the value of distinguishing between CS and software engineering, not being comfortable with basic shell commands, installing programming language tools, compiling something using those tools, or source control means that there has been a huge gap between theory and practice in their education, which hurts understanding of both.
Particularly when interacting with senior CS students, they'll spend 6 months just getting comfortable doing very basic things like installing and running Python, using ssh with a VM, and using the command line. They try to do productive work, but their unfamiliarity with the basic tools of making software means they actually spend their time learning that.
Actually, this also applies to the basics of just writing a functioning library or piece of software, or being familiar with async vs. sync programming, etc etc. It would be better if they could dip their toes into these things while learning about, say, algorithms, because identifying the slow step in its execution context and designing a better algorithm requires knowing this stuff. Or even better, before doing any of that. I've met people with 6+ years of CS or CS-related educational background who don't know how to do basic problem solving / troubleshooting of their work because they've only done toy coding for coursework.
In some ways it's easier to teach a good language to someone that has been automating everything they touch with shell scripts/Excel formulas/weird python/VBA/javascript than to light a java programmer on fire with the belief and confidence that all tasks are automatable and all problems boil down to bits on a disk or bits in a packet.
While i was in college one of my main "teaching" moments were with people getting comfortable with the scary idea of using gdb.
There was such a lack of understanding when it came to debugging that many people graduated still not knowing how to print a register. I worry about them because a lot of man hours were wasted in stupid errors, they would come to me after struggling for several hours. I'd take their applications, compile, run it once, see how it failed; then ran gdb and each and every time it took less then 15 minutes to find the issue.
They called me "The Woz 2.0" (my first name is shared with the brilliant man associated with that nick) but it wasn't difficult or some great feat; i literally just used a debugger, like anyone should know how to do.
It was a sobering realization for sure. The future of application development lie in the hands of many who are not only scarred of debuggers, but only ever know how to use them in an IDE
But most people study computer science in order to work as software engineer, not computer scientists. Particularly at the undergrad level. This massive hidden subsidy to computer science also results in graduates who don't have a proper background in software engineering and at some point both government officials and the public at large is going to figure out that these are different skillsets with different curricula, and that we need to hire professors who can teach good software engineering principles and practices in our universities rather than just focusing on the computer science aspect and forcing the graduates to figure the engineering out for themselves on the job.
Vim and git aren't Software Engineering either. They're just tools that some people (really) like. They aren't truly industry standards, especially Vim. Universities shouldn't be producing graduates who are dependent on specific tools.
Learning how to use professional tools is just scratching the surface of what should be taught. How to design a program, how to document a program, software design patterns and methodologies, how to refactor, secure coding patterns including at a minimum authentication, authorization, and audit systems, how to work with bug tracking systems and repositories, IDEs, unix and shell scripts, how to debug code, etc. Then they should display proficiency with assembly, c or c++, at least one scripting language and at least one higher level OO language and one functional language. Then they should also work on large software projects for practice. Then for electives they can focus on different areas of emphasis such as real time systems, AI, systems programming, database design, networking, web applications, etc.
Imagine you study civil engineering but all your classes are taught by physicists and mathematicians, and you are studying physics. Yes, this is all important foundational knowledge for engineering, and you can't be a good engineer if you don't know any physics. But engineering is not physics and to graduate civil engineers without actually teaching them engineering seems like a massive fail. Adding a "missing semester" in which they learn how to use some engineering software is just scratching the surface of what an civil engineering degree should require. That we have gotten away with this in CS-land is just because of the immaturity of the field, not because this is a good way of producing the software engineers that society needs.
5 different programming paradigms. A single language can have multiple paradigms.
Do you think there are tradeoffs worth considering between language paradigms? Is there a reason why you might want to write something close to the metal, vs something in a scripting language? Is there a reason you might want FP over OO for certain problems?
I mean...my curriculum didn't explicitly call out languages anywhere, but along the way I picked up Python (intro class), Java (most classes), C and an x86 assembly (embedded class), C++ (graphics class)...and within two years of graduating I was wanting to learn a functional programming language, and changed jobs just to do it. Had I gone AI track I would have picked up a Lisp. It's not really that big an ask.
When you put it that way, I sort of agree with you. I don't think whether a language is close to the metal or high level is an important distinction to be made in the context of learning computer science, but I do think that learning about different programming paradigms and concepts in the abstract is important.
Learning x86 assembly for the sake of it isn't useful or educational. However, building an x86 compiler (or in my case JVM compiler) as part of a languages and compilers course is something worth doing.
Well, I will say that the class that had us learn assembler started with (software) FPGAs, then assembler, then C. The idea being that it demystifies a lot of what is going on underneath your code. Does it actually help you write better code in most instances? Probably not. It's helpful if you're writing embedded things (and that was the whole gist of the class), but for many devs it's not that useful. But that knowledge is still comforting; I've met devs who didn't have it, and they felt a little uncomfortable that they didn't understand how the code they wrote actually affected the underlying machine. shrug Certainly, "our CS degree is good for anything that isn't too low level" isn't the vibe most universities are going for.
Every developer should learn an installed-by-default POSIX standard text editor, when you need to make remote changes to a box (yes, cattle not pets, but the build server is probably a pet. Your personal workstation is probably a pet. Etc).
Every developer should learn to work with an SCM tool.
Yes, Vim and git are specific choices, but they are reasonable, extremely popular defaults. The first will work basically everywhere, the latter at least gets you the concepts necessary to quickly learn and use something else if needed (while being the most popular of its kind)
Right, and that's my point. Almost no one gets a CS degree to be a computer scientist. They get a CS degree to be a software engineer. So dontcha think we might want to teach them what software engineers do, rather than what computer scientists do? We don't require civil engineers to get a degree in physics and then pick up civil engineering on the job site. Why do that to software engineers?
Why write compilable code at all then? Teach everything in a hypothetical language like (M)MIX, like Knuth does in the Art of Computer Programming. Why bog students down with engineering 'details', like actually compiling their code and getting it to run, or stepping through a debugger, or any such thing. That's not computer science.
Perhaps an unpopular opinion but I don't think these concepts should be taught as part of a BS program for Computer Science.
Teaching tools of the trade is, well, a trade school thing. I suppose you have to decide if the degree program is more like "Prep school for FAANG" or a program to teach people how to be computer scientists. When I see classes like this I flashback to the required "Problem Solving" class I had to take as part of my CS degree which was a full semester of "How many windows are there in NYC?" or "How many bowling balls fit inside a Boeing 747?" Biggest waste of time considering Google and the like had moved on to HackerRank/LeetCode style questions years ago.
Coming from a school that's known as a good technical/engineering school I found the CS program to be a bit lacking on the "CS" part. Lots of outdated classes on "how to develop for the web/mobile" and such.
This general idea is something I've been sitting on for a while so I don't have full thoughts.
These skills (VCS, debugging, etc.) are incredibly important in being a software engineer and could certainly have a place. I think I'm likely to fall on either side of the fence depending on how things are implemented in any given case.
I have a bit of "PTSD" so to speak from my degree program. Lots of checkboxes for focuses in your major or minors to be awarded for taking a bunch of outdated classes that were largely things like "How to use Android Studio" rather than a more generalized class on "programming for mobile".
I think what happened in my program is the department saw things students needed in order to be successful in the field: learning to program for mobile/web, cyber security, etc. And instead of putting together good classes on the theory and backbone of those areas they created a bunch of "trade" electives that got outdated before they printed the syllabus.
Also the vast majority of students took an internship in the field myself included, and on the job was where I learned a lot about trade related concepts like VCS, flavor-of-the-week Agile, etc. I just don't want to see CS degree programs become expensive and outdated bootcamps and that's the direction I feel my alma mater's CS program was heading in a lot of ways.
I disagree. These are tools that are useful in school. Luckily I took a Unix class early on and learned shell tools, scripting, and vim, but I certainly wish I knew about version control earlier.
> Teaching tools of the trade is, well, a trade school thing
I disagree. So much of our computing literacy is in how to _use_ the systems, and understanding concepts of using the shell, debuggers, source control, etc.
I see these kind of classes as more similar to the foundational courses in math you take before you dive into Calculus. If you haven't studied algebra, or memorized arithmetic facts, it's going to be very rough if you start into graph theory and Calculs I. Math and science majors already have students who have spent literal years being exposed to concepts before they get to college.
Maybe what you want is for astronomy to be about looking at stars, not building telescopes.
Less flippantly: I think everybody knows that "computer science" BA/BS programs are feeders for the industry (almost exclusively in both directions -- it's hard to get an industry job without a BSCS and the overwhelming majority of BSCS go into industry instead of academia, more so than other bachelors programs).
There are people who wish there were separate tracks for academic-minded folks and industry-minded folks, but young industry-minded folks generally don't want to go to a "trade school"s, they want to go to college and enjoy college culture before they go into industry.
I said this in another comment less succinctly but I think I'm sensitive to these types of classes because my degree program was chock-full of electives that were basically outdated bootcamps for web dev, mobile dev, cyber security, etc.
So I'm generally hesitant to classes that can easily become "Here's how to use Android Studio".
this is not an official course; it's taught during January which is a "free" month between semesters. And it was written and run by students, not faculty.
This type of stuff was required like second semester undergrad at my school back in the late nineties, albeit with CVS instead of Git. Everything was Solaris back then- we got our first Windows lab just as I was leaving, and it was mostly used for telneting to the Solaris boxes. I wonder if they dropped the requirement at some point as Windows took over, or if they maintained it as 'this is how real computers work'
Not exactly the same but my university had a similar quarter called "Software Engineering" or something vague like that with a similar hodgepodge of useful topics. I think it also had common design patterns, and uml, although I understand why uml is missing.
does it cover build systems/makefiles? I usually spend some time fighting them, on the other hand there are so many different build systems, so that i can't blame them for not choosing any particular build system. Correction: there is some coverage of makefiles in https://missing.csail.mit.edu/2020/metaprogramming/
189 comments
[ 2.9 ms ] story [ 247 ms ] threadIn retrospect they could have put more focus on debugging tools as well. But since they didn't mandate one particular system--we had projects where every kid was using their own development environment, from VS on Windows 95 to vi, gcc, and Make on FreeBSD all developing on the same codebase. It sounds like development hell, but it made porting the app to all of the target platforms a breeze.
Can you share more info on that?
(For reference, I had that happen at least twice in school, where the group of us broke up the work and scheduled check-ins, and by the end of it only I had done my part...though being cynical, as the team missed check-ins with various excuses, I had also done everyone else's because I cared about my grade)
Unlike the real world, where if someone is allocated work, and doesn't do it, a manager deals with it. Professors are not interested in being managers.
That said, it DOES sound useful for the real world, where the incentives are better aligned.
The only thing which stuck with me was the Therac-25 story. Everything else was just pretty much "don't deliberately use your powers for evil" type thing.
It's easy to talk about professional ethics and choosing good over income on an internet forum when the impact it has on someone else's life has no impact on yours. If I left a FAANG to work for peanuts at some volunteer agency, I suspect you wouldn't be there to chip in when my loved one needs support and suddenly my ethics can't foot the bill like my old salary could. You have no idea the impact a FAANG salary would have on my life and my loved ones', so it's not very thoughtful to suggest that somebody who has to prioritize financial gain is unable to see good other than financial gain.
my favorite software ethics framework so far is https://ethicalos.org/
Learning Outcomes:
1. Understand Unix/Linux commands for navigating directories and files and manipulating files and folders.
2. Understand terminal commands for searching and input/output redirection.
3. Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
4. Understand debugging via print statements and general debugger concepts.
5. Understand version control via Git and Github, source control, workflow, commit, collaboration, pull, push, create and pushing a new repository, cloning, branches, merging, and conflicts.
6. Understand vim including mouseless navigation, normal/insert mode, copy/paste, search/replace, and saving/quitting.
https://selfservice.mypurdue.purdue.edu/prod/bwckctlg.p_disp...
The only time I found it to be a liability was when I was pair programming. My pair couldn't read a shell script to save their life & had very little interest in learning. When I tried explaining it line by line, they stopped wanting to pair because I was apparently making them feel stupid. They actually reported me to management for being an arrogant mansplainer. I'm pretty sure that was the beginning of the company deciding I was not a culture fit :P I had to learn how to, and how not to, work with someone less experienced in a certain topic after that.
One of the downsides of pair programming is that it's great when you both have complimentary skillsets. It's less productive when no one knows what the heck is going on. In this case, the task was to benchmark how many writes one could make to Kafka using our monolith. They wanted to see at least 10K/writes per second. The only problem was no one knew how to use Kafka (well), including the person who was asking for it.
So I wrote some gnarly looking Bash code to fire up Kafka, Zookeeper, the app, etc. Some people wanted to use Docker, but I didn't see the value in using a slower VM w/ limited resources. I wanted to use as much CPU as possible. My pair didn't know Docker, Bash, or Kafka. I lost my pair somewhere around talking about having to clean up zombie processes.
It went downhill from there.
Yes, cultural fit is real, and it isn't always about white men drinking craft beer.
Builds work quite different in Java, for instance.
> Understand shells such as sh, csh, ksh, tcsh, bash, zsh.
I was taught csh as an undergrad. A complete waste of time, in my opinion, akin to teaching BCPL rather than C. Just teach bash, and perhaps sh. To my knowledge, just about nobody writes scripts in csh, ksh, tcsh, or zsh. You use bash for portability across Unix systems, sh for even better portability across Unix systems, or you use a modern scripting language like Python3.
Students may benefit from learning zsh for interactive use, but I don't think there's enough benefit there to justify spending time teaching it.
My company still does intro lessons with ksh because it's set as the default shell on all of our servers.
I think it's worth focusing on Bash, but at least contrasting it with csh and pointing out the lineage and other options. Perhaps spending some time writing some scripts in sh since there is a large install base of outdated or missing Bash.
I have no idea what schools think about this. I generally prefer deep knowledge in a single language, but there is value in learning a bunch of languages so picking up yet another new language is trivial. When I've spent too much time in one specific language I've found it harder to switch around.
In my company the default shell in the UNIX accounts is csh, and tcsh is recommended as a "nicer" csh. They do have bash if you want to use it, but they only "support" csh and tcsh. As a result, many important scripts by engineers are written in csh/tcsh. People who've never used bash. Very annoying, as for those who choose to use bash are often told they have to go into tcsh to get a given program to work, etc.
IMO it’s better to focus on fundamentals like math/algorithms that can be applied in multiple areas rather than specific tools.
Everything in a CS curriculum is easily Google-able.
Being functionally illiterate at the command line is harmful for productivity, so I think it's deserving of some in-class attention.
Imagine handing this to a person who's never heard of a shell, doesn't know how to `cd` or `ls`:
https://www.gnu.org/software/bash/manual/html_node/What-is-a...
> 1.2 What is a shell?
> At its base, a shell is simply a macro processor that executes commands. The term macro processor means functionality where text and symbols are expanded to create larger expressions.
> A Unix shell is both a command interpreter and a programming language. As a command interpreter, the shell provides the user interface to the rich set of GNU utilities. The programming language features allow these utilities to be combined. Files containing commands can be created, and become commands themselves. These new commands have the same status as system commands in directories such as /bin, allowing users or groups to establish custom environments to automate their common tasks.
"Macro processor?" "Expressions?" "Unix?" "Command interpreter?" "GNU utilities?" "Directories?" (you mean folders?) "/bin?" "Environments?"
My undergraduate advisor said since the second-semester lab was the basic lab, the first-semester lab had to be the basement lab.
Not in my experience, it isn't. Maybe for the first two years of undergrad but after that I've found that Google rapidly becomes useless.
The class almost went off the rails the first time before I realized half the students didn't know what a text editor or shell was. I ended up writing a document at a slightly lower level than this "missing semester" course (though taking some inspiration from it).
If I teach the course again, I plan to do one week shell bootcamp with "get to know your system" exercises spread throughout.
There are four quadrants of knowledge:
1) What you know you know
2) What you know you don't know
3) What you don't know you know
4) What you don't know you don't know
College is in large part about covering (4) and turning it into (2) or (1). You're describing turning (2) into (1) - you need to know what to Google in the first place.
Even if (at first) students just do a single `git add --all && git commit -m "finished project"` it goes a long way to just exposing people to the concepts. Provided the infrastructure is in place (eg GitHub or gitlab instance), it really isn't much different than dealing with a zip file, but provides 10x the educational value.
Bonus points to the prof that builds assignments that involve git branching from an earlier assignment.
I didn't study Computer Science to learn how to write bash scripts.
The good ones are really CS + one extra year worth of projects and practical coursework, like learning what Agile is, Source Control, Build Systems and so on.
CS 193 was a very low effort class (1cr), where you could follow the command by command instructions and perform all the tasks necessary to pass.
Unfortunately tools like git, vim, and shells all possess philosophies and concepts that are very hard to grasp without context, and constant use.
We were on multiple occasions told the mantra, add-commit-push, which I will say is enough for basic git usage, but since pretty much none of the subsequent classes used git to any capacity, I would assume many students lost all familiarity within the next semester (Makefiles that automatically git added and pushed code were used for submitting code).
I also think most people were hindered by vim, lacking sufficient instruction but still being presented it as the primary option.
I think if you’re going to implement a similar class / program, the tools really have to have uptake beyond a single course.
Sidenote, the different shell types weren’t covered in my semester, we just used bash / dash.
I think the trade-off on timing here is with internships during the summer after freshman year. I think you’ll have a much better chance of success if you’re at least roughly familiar with these workflows vs. interns who are totally unfamiliar with version control systems, for example. And perhaps that’s all the course is meant to accomplish at 1cr.
I don’t have to regularly look up how to bold text even in Markdown, but I do have to regularly look up various Bash-isms.
It's like an English major who can read and analyze the classics and nothing else - and cannot write at all outside of abstract poetry.
The only thing that seems missing is document preparation - presumably using LaTeX (we had to use troff, which was 'fun').
They did eventually realize that teaching some of the basics would actually make for more successful students, and better alumni donations.
In the end, the CS Dept. started offering these things as zero-credit courses as a way to square the circle.
[EDIT] incidentally, the arts are also infamous for being dominated, at a professional level, by kids with artist parents and kids with rich parents (who can bankroll years of private lessons and then years of little-to-no income while paying for access to career-makers) so... there's that.
Of the 22 people in the class, 21 of them were singers - everyone except me. Much of the class was around singing - singing scales, etc. I saw nothing in the syllabus that required singing, but... you had to learn to sing stuff by sight reading, and... I'm not a singer. It was embarrassing for me (and probably for others). I think I managed to drop out before losing all my money on that, but... frustrating. Could also tell most of these people had had voice lessons for years, and were all taking this class as a way of getting in to theater work, not... to play an instrument.
That feels roughly analogous to a CS department requiring a "*nix skills" course or similar, as most liberal arts degrees require a substantial amount of writing.
I assume music (and possibly some fine arts) would require some background in those subjects. They often require a portfolio or audition before entering the program.
Do engineering programs expect students to have taken calculus?
Though with music (and possibly engineering), you likely have to prove ability prior to being accepted into the program.
I don't know how people coming in not having sunk thousands of hours into computer crap before entering a CS major don't drown in a hurry. It'd be like starting a creative writing degree in a world where reading & writing aren't taught in school, except maybe as a one-semester high school elective, and you're just expected to have picked them up on your own time by age 18, if you're going to be a creative writing major. "OK, you're familiar with stories from watching TV, but now you're going to need to read and write them. If you can't read them here's a book(!) to help you learn to read, in you own time. Good luck anyone who wasn't already a long-time reading-and-writing nerd before choosing this major".
Of course some of the problem is that CS programs use computers so much. Which I know may seem like a silly complaint, but I think the fundamental issue is CS-the-science being mashed together with what's really a vocational program (which is what 99+% of students and employers actually want out of it, and its being "real" CS is mostly just an IQ filter). I imagine if you go into, say, a junior college HVAC program not knowing which is the business end of a screwdriver, you'd also be at a big disadvantage compared with most of your peers, and probably feel really out-of-place for quite a while.
I took MIT's "Intro" to Programming and Algorithms I think it was called (6.001). I'm not a professional developer but I've written a fair bit of code including Python which is what the class used. I'm pretty sure that, as an undergraduate, had I never seriously used a computer command line before, there is no way I could have gotten through that course.
The same dynamic is largely missing from other engineering courses, as well as the sciences, which don't really expect more than high school classroom work, an interest, and general aptitude.
And it's certainly true that CS (the math degree) gets munged with CS (the engineering degree). MIT's a bit more engineering focused (the degree is in the engineering school). There are also some variants of the degree that are more or less engineering-centric.
You're not going to meet that kind of abrupt and early resistance on the path to becoming a doctor because you didn't spend tons of your free time as far back as junior high reading anatomy books or practicing dissection, for instance.
Again, there are almost certainly other factors, and correlation is not causation, but there is at least logical correlation.
To your broader point, a lot of kids enter college with only a broad idea of what they want to do. And high school courses don't really offer much guidance. High school science classes have very little to do with their counterparts at good colleges.
[1] https://www.aei.org/carpe-diem/chart-of-the-day-the-declinin...
Meanwhile there are definitely a lot of gatekeeping-assumptions about childhood interests in modern CS programs, which one would expect to have gotten stronger as more and more freshmen actually could have had experience with computers on their own—so, starting with late-80s freshmen, mostly, with the effect getting stronger fast after that. That lines up so well with the data on CS-program-enrollment-by-sex that it seems to me like the factor to examine before we go looking for other explanations. Again, to be excessively explicit due to the topic, I mean this in terms of accounting for the gender gap in programming, not in terms of addressing any other issues of sexism in the industry, which I am not denying exist.
It's much more inclusive indeed. If you can afford the mandatory completely unrelated undergrad you need to have completed to even apply to med school and the travel fees to attend your in-person interviews of course.
No, instead it's unrelated to the field so you can grind fractions of GPAs against other applicants. At least, CS is kind enough to let everyone try the real thing.
They don't call it the firehose for nothing. [0]
[0] http://hacks.mit.edu/Hacks/by_year/1991/fire_hydrant/
There's been some research on this and places like Harvey Mudd solve this basically by dividing the incoming freshmen into 'has any experience at all programming' and 'completely new', which was like 50-50 if I recall. And then tweaking assignments to not be video game focused -- pulling in problems & themes from bioinformatics and other fields instead.
Our only program of any significance in CS101 was a space invaders clone, but because we were so inexperienced, they provided a project template where we really just had to fill in some methods with a bunch of for-loops. When we got to the later courses and had to write our programs from scratch, we really had no idea where to begin because the 101 coursework had done all of that for us.
The video game assignments were asinine because they were beyond our skill level to do from scratch, so their templates handled all the I/O for us and that part of the program was treated like a bunch of magical incantations. As a result, we never fully internalized how all the moving parts fit together, and it kept us from learning useful stuff like how to read/write from files or execute system commands.
Difficulty of any given program at the undergraduate level is completely dependent on university policy. Maybe at the research level, you truly need to be more intelligent / harder working / whatever to succeed in math than in art history, but at the college level, you could do for instance:
- cram all that is taught in current undergrad, MA, and PhD (including the thesis) for art history in 4 years
- let CS students graduate if they can write any working program in any language of their choice
Tada! Art history is now the hardest degree in the college where only the best students aren't weeded out out; and CS is the easiest degree there is.
My point being that CS departments assuming prior levels of CS unlike other departments is merely an instance of a larger pattern.
I'm sure it would be considered a laughable course to teach at an elite school today. (OK. It was a bit harder because we were using punch cards and we had to beg for more computer cycles if we made too many typing errors, but still.) But I'm pretty sure it wasn't because we were a lot dumber back then.
I agree with your basic point though some students do freeze up with even relatively easy math. But, yes, you could put together a relatively easy programming course and call it CS. And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
That's the opposite of my point, really.
> And liberal arts courses are not necessarily easy today--especially at a good school. You'll be doing lots of reading and writing.
My point was about the "within university" variance of student levels rather than the "between university" variance. I have no doubt that a liberal arts programs in a good university is more selective than the CS program at a particularly non selective university. However, within any given college, I'd be surprised if the liberal arts program manage to get the above average students and the CS/Math/... programs get the below average students.
It wasn't until I got past the first few java heavy intro courses that I realized I had a huge leg up on a lot of the other students that only had experience with Windows or Mac. Before that I felt like I was behind behind the curve because I was stubbornly writing Java in emacs because I couldn't stand how dogshit slow Eclipse was, so I didn't have the advantage of the code-completion or project management features.
Looking back on it, the curriculum was actually just holding most students back even further and by using emacs and managing my projects from the command line, I was just increasing the lead I already had over students that didn't have linux experience.
Since the 70s, AI was dominated by lisps and nearly everybody was driving at "general" AI by emulating or even attempting to simulate human thought processes.
In the 00s people started putting more weight behind statistical / stochastic methods for arriving at answers without necessarily trying to use any model of human cognition. This was called "data mining" and then "machine learning" (partly, I presume, to distance it from the 40 years of academia's dismal failure to produce working AI) and only in the last ~5 years has it come around to people starting to use the term "artificial intelligence" again.
In the early days of the revamp, it was common to see janky perl and fortran and not much structure holding it all together. Lately, I gather, the ecosystem is nearly entirely python-centric, but this is due to the gravity well around pandas. There's nothing in particular about python that makes it suitable to the task, though it is happily more approachable/accessible for academics than if a pandas equivalent had instead evolved in C++ or Java.
It is very sad that we need to take two entry level programming language classes in the first year. My university does not allow me to remove it as it's the pre-requisite of pretty much everything else. And I can't "prove" that I know Java, which I didn't but I'm confident that I can get the basics going in one day and the basic-medium stuffs in a week because I already know some C, C++ and Python.
The only class that I think should teach programming languages should be a PL class. An introductive one usually teaches three or more languages in one shot with each an example of a paradigm.
BTW the zero-credit courses sound like an excellent idea. Students do not get credits but still get education out of them. It's a great practice.
Java as a language is actually tiny. So are most languages. Most of the pain is in the tools, build chains, and libraries that go along with them. Also sometimes what works very well in one lang is a pain in another. For example the dictionary in python has no real equivalent in C, unless you use some lib or write something yourself. In java you would need a map or hashmap class and knowing it exists sometimes is the biggest hurdle. But at least it is in the std library. So sometimes those sharp edges bite students as they are first starting with new langs and have decent exp in another language.
SCIP (well loved on HN) was designed for as the introductory class for freshpersons who'd never seen a computer before (which was the default case when the course was designed).
The first lecture was about how to program in lisp, using the example of symbolic differentiation. That one lecture was 100% of the introduction to computers and programming: the rest of the semester was spent on computer science.
Version control is the most common thing I have to teach interns in general & that too remote version control usage - particularly my "oops, I dropped my laptop after 3 weeks" story.
Git makes that curve a lot less complex to deal with (no server setups).
The other bit I tend to drill down into is about writing graphviz files for everything.
Mostly what I do is generate code and documentation out of one system - but often, I dump out things in some arbitrary format, only to process it in python in to a graphviz diagram or in some cases some more fancy svg stuff (outputting direct D3.js is better, for something like a Sankey diagram for data-flows).
Like this[1] is a way to discuss a problem with a cycle in a DAG, instead of whiteboarding it out, particularly if your work-mates are going to be remote.
[1] - https://gist.github.com/t3rmin4t0r/6991ce21b41b2558c5362455c...
This way, as a TA, I can also code review them and it also deters plagarization.
The answer is basically "sure, but we explain what we mean in the lecture."
I should have taken it first semester, freshman year. It was full of invaluable meta information which would have made my four years not only easier, but more productive. I may have even stayed in Chemistry if I had the correct tools from the start.
I am largely self taught when it comes to CS, and so I learned these tools first from a practical application. I didn't have anyone to set up a dev environment for me; I had to do it myself. I am always shocked when I work with new grads from top CS schools who have almost no knowledge of basic tools like grep or how to use an interactive debugger.
Theories and academia are nice, but are a fair stretch from the real world in any field. If we really want to require an advanced degree to enter the work force, then we should abandon the idea that most students attend college for a liberal education and accept they reality that students attend college for workforce preparation.
A couple areas I would add
[1] http://www.catb.org/~esr/faqs/smart-questions.html https://wiki.c2.com/?HowToAskQuestionsTheSmartWay[3] https://esajournals.onlinelibrary.wiley.com/doi/full/10.1002...
[4] https://www.youtube.com/playlist?list=PL2FF649D0C4407B30
[5] https://en.wikipedia.org/wiki/How_to_Solve_It
It's not sexy. A lot of it isn't "computer science." But until you get this stuff down you won't be doing day-to-day development very well.
This is the main issue in my view. CS isn't development. CS is research, development is application. I'm a software engineer and I would never call what I do CS. Things are going to be clunky and awkward until schools split CS from Software Engineering, like they do with other sciences and their applications.
If you're only going to teach one editor, why an editor that's so arcane in comparison to something similar to a text editor like Sublime or Atom? If you're going for a terminal-compatible editor, why not Emacs or Nano? If you want the most workplace-ready tool, why not Intellij or VS Code? And my main question, why not at least teach a few and empower the users to really explore and find the best tools for them? To me this smells of people who don't want to help students equip themselves for success and instead want to teach them the "right" way to do things.
Time. It's supposed to be over their IAP which is about 4-5 weeks or so.
This is a continued course just put together by a bunch of grad students of things they have to learn on the side or not emphasized enough.
Pragmatically, Emacs is usually not installed by default on Linux systems and Nano sometimes isn't. If you had to pick a command-line editor to teach, Vi/Vim is probably the safest bet.
(Unless you mean for workstations or servers people constantly log into, as I’m thinking of containers).
I learned emacs over some months; I had a job as the IT support guy and I wanted to become a Unix C developer, so I grabbed an unused HPUX workstation, sent all my email to emacs, and then spent months learning how to use it. Probably six months before I was using it decently well.
which is honestly fair because emacs is essentially a full-on lisp machine with a set of excellent text editing utilities.
So, basically, it's popular, useful, and they know it. But, even before saying that they provide this caveat: "As programmers, we spend most of our time editing code, so it’s worth investing time mastering an editor that fits your needs." Then they devote a little of time explaining how to best learn any editor.
Also, in the QA they say "The three of us use vim as our primary editor but Emacs is also a good alternative and it’s worth trying both to see which works better for you.... An advantage of using Emacs is that extensions can be implemented in Lisp, a better scripting language than vimscript, Vim’s default scripting language."
They did explain that they based there decision based off the most popular command line editor (based on a stack overflow survey). Although it would probably be good to at least reference other popular / useful ones for exploratory purposes, for a quick overview course I think focusing on vim makes ample sense.
I don't think they really advocate for vim to be your daily driver for all editor needs. Just a "you should know a thing or two about what this is because you're going to be lost the first time git shoves you into a vim editor" sort of thing.
It's also one of the few modal editors out there, and that's a different paradigm students might not have been exposed to. In comparison, Emacs is much more similar to Sublime or VSCode (always insert, functions invoked via shortcuts).
Similar concept, but targeted towards non CS majors
I saw a lesson on R, for example, which is probably not too useful for a webdev or mobile app developer.
One of the students I was friends with was much younger than me, smart kid, very good in the camp, still college age / situation in life, and after the bootcamp he decided to go back to school for a CS degree after some "hey you're more than capable of qualifying for a lot of scholarships" type discussions.
Anyway we met up a while later and he described how he was in these classes with theory and various languages and so on.
Then the students would do projects together and they'd look at him like he was a wizard with what were fairly rudimentary debugging but still similar skills to what us described in 'the missing semester of CS education', or at the very least the ability / lack of fear to pick them up fast (something that if you're good at it is super handy in a fast moving boot camp).
I remember when I was in college (dropped out for a variety of reasons) I really hated theory or 'just learn this focused thing you'll understand later' type classes when I just couldn't see ... the end use / test that end use in front of my face.
It occurred to us that a sort of 'full stack light' boot camp almost would be a good intro to some of these deeper programs. Even if just to give some level of ... practicality / way of testing / seeing output ... etc.
No doubt that many schools / departments would be averse to such a system for a lot of reasons. Even the bootcamp I went to was hosted by the same large university... but was sourced bought from some outside company and had NO association with the CS and similar departments.
At a larger tech co I am consistently seeing boot campers coming in better prepared and with more hustle than CS grads. It would be interesting to see if their acceleration through the ranks is on average faster. It definitely is from my anecdotal experience.
That's a stretch.
What I've seen with Bootcamps is that they know one stack and how to do one thing only. They are really productive in that one stack but lack the more fundamental understanding that CS grads have.
When it comes to learning a new stack, technique or solving harder problems, the CS students run in circle around bootcamp grads. But to the non-technical manager, they see the bootcamp kids writing code on day one so they naively assume they are better.
I'd be surprised if the bootcamp hires weren't better in the short term for specialized lower-level roles using newer tech. But many of the bootcamp learnings will be obsolete in 5 years; CS fundamentals are obviously more timeless.
I know bootcamp grads that are now staff level engineers at FAANG or equivalent companies (based on levels.fyi pay bands). The money is in the bank. The RSUs are vested. They are only in it because they want to be at this point
Obviously not most boot campers but most engineers of any kind regardless of background wont reach that level.
I have never seen a CS student "run circles" around a bootcamp grad after equivalent experience.
It is telling that "The Missing Semester of CS ed" would be laughably basic to most boot campers and last I checked would be done as part of the pre-work to get into the bootcamp to begin with.
Side note: The bootcamps around today are much much better than 5 years ago. They are iterating rapidly.
The best people I have worked with have been HS dropouts (fully self taught), MIT and a CMU grad who were very self taught before their program, and bootcamp grads who pivoted from other fields (oddly music, fine arts, and a standup comic. Maybe because in those fields being "good" is completely insufficient and they bring a "must be the best" mindset?)
I like how fundamental knowledge is treated as trivia. It's an interesting perspective.
> Side note: The bootcamps around today are much much better than 5 years ago. They are iterating rapidly.
Citation Needed here. Almost once every two weeks there are testimonies from Lambda's students that beg to differ.
While I understand the value of distinguishing between CS and software engineering, not being comfortable with basic shell commands, installing programming language tools, compiling something using those tools, or source control means that there has been a huge gap between theory and practice in their education, which hurts understanding of both.
Particularly when interacting with senior CS students, they'll spend 6 months just getting comfortable doing very basic things like installing and running Python, using ssh with a VM, and using the command line. They try to do productive work, but their unfamiliarity with the basic tools of making software means they actually spend their time learning that.
Actually, this also applies to the basics of just writing a functioning library or piece of software, or being familiar with async vs. sync programming, etc etc. It would be better if they could dip their toes into these things while learning about, say, algorithms, because identifying the slow step in its execution context and designing a better algorithm requires knowing this stuff. Or even better, before doing any of that. I've met people with 6+ years of CS or CS-related educational background who don't know how to do basic problem solving / troubleshooting of their work because they've only done toy coding for coursework.
There was such a lack of understanding when it came to debugging that many people graduated still not knowing how to print a register. I worry about them because a lot of man hours were wasted in stupid errors, they would come to me after struggling for several hours. I'd take their applications, compile, run it once, see how it failed; then ran gdb and each and every time it took less then 15 minutes to find the issue.
They called me "The Woz 2.0" (my first name is shared with the brilliant man associated with that nick) but it wasn't difficult or some great feat; i literally just used a debugger, like anyone should know how to do.
It was a sobering realization for sure. The future of application development lie in the hands of many who are not only scarred of debuggers, but only ever know how to use them in an IDE
Imagine you study civil engineering but all your classes are taught by physicists and mathematicians, and you are studying physics. Yes, this is all important foundational knowledge for engineering, and you can't be a good engineer if you don't know any physics. But engineering is not physics and to graduate civil engineers without actually teaching them engineering seems like a massive fail. Adding a "missing semester" in which they learn how to use some engineering software is just scratching the surface of what an civil engineering degree should require. That we have gotten away with this in CS-land is just because of the immaturity of the field, not because this is a good way of producing the software engineers that society needs.
So graduates are expected to show proficiency in a minimum of 5 different programming languages? That sounds like an enormous waste of time.
Do you think there are tradeoffs worth considering between language paradigms? Is there a reason why you might want to write something close to the metal, vs something in a scripting language? Is there a reason you might want FP over OO for certain problems?
I mean...my curriculum didn't explicitly call out languages anywhere, but along the way I picked up Python (intro class), Java (most classes), C and an x86 assembly (embedded class), C++ (graphics class)...and within two years of graduating I was wanting to learn a functional programming language, and changed jobs just to do it. Had I gone AI track I would have picked up a Lisp. It's not really that big an ask.
Learning x86 assembly for the sake of it isn't useful or educational. However, building an x86 compiler (or in my case JVM compiler) as part of a languages and compilers course is something worth doing.
Every developer should learn to work with an SCM tool.
Yes, Vim and git are specific choices, but they are reasonable, extremely popular defaults. The first will work basically everywhere, the latter at least gets you the concepts necessary to quickly learn and use something else if needed (while being the most popular of its kind)
This isn't something you do in CS ever. If you want to learn a technical skill like system administration or git, great. It isn't CS though.
Teaching tools of the trade is, well, a trade school thing. I suppose you have to decide if the degree program is more like "Prep school for FAANG" or a program to teach people how to be computer scientists. When I see classes like this I flashback to the required "Problem Solving" class I had to take as part of my CS degree which was a full semester of "How many windows are there in NYC?" or "How many bowling balls fit inside a Boeing 747?" Biggest waste of time considering Google and the like had moved on to HackerRank/LeetCode style questions years ago.
Coming from a school that's known as a good technical/engineering school I found the CS program to be a bit lacking on the "CS" part. Lots of outdated classes on "how to develop for the web/mobile" and such.
Where do you draw the line? If you don't have tools and knowledge of tools you're not going very far in a "pure CS" degree, either.
I'm watching the git/VCS one now and it's still touching a great deal on CS concepts, so it's not just "here's 10 git commands"
These skills (VCS, debugging, etc.) are incredibly important in being a software engineer and could certainly have a place. I think I'm likely to fall on either side of the fence depending on how things are implemented in any given case.
I have a bit of "PTSD" so to speak from my degree program. Lots of checkboxes for focuses in your major or minors to be awarded for taking a bunch of outdated classes that were largely things like "How to use Android Studio" rather than a more generalized class on "programming for mobile".
I think what happened in my program is the department saw things students needed in order to be successful in the field: learning to program for mobile/web, cyber security, etc. And instead of putting together good classes on the theory and backbone of those areas they created a bunch of "trade" electives that got outdated before they printed the syllabus.
Also the vast majority of students took an internship in the field myself included, and on the job was where I learned a lot about trade related concepts like VCS, flavor-of-the-week Agile, etc. I just don't want to see CS degree programs become expensive and outdated bootcamps and that's the direction I feel my alma mater's CS program was heading in a lot of ways.
I disagree. So much of our computing literacy is in how to _use_ the systems, and understanding concepts of using the shell, debuggers, source control, etc.
I see these kind of classes as more similar to the foundational courses in math you take before you dive into Calculus. If you haven't studied algebra, or memorized arithmetic facts, it's going to be very rough if you start into graph theory and Calculs I. Math and science majors already have students who have spent literal years being exposed to concepts before they get to college.
Less flippantly: I think everybody knows that "computer science" BA/BS programs are feeders for the industry (almost exclusively in both directions -- it's hard to get an industry job without a BSCS and the overwhelming majority of BSCS go into industry instead of academia, more so than other bachelors programs).
There are people who wish there were separate tracks for academic-minded folks and industry-minded folks, but young industry-minded folks generally don't want to go to a "trade school"s, they want to go to college and enjoy college culture before they go into industry.
So I'm generally hesitant to classes that can easily become "Here's how to use Android Studio".