You're talking about this right?

> I think CS curricula should have a class that focuses specifically on these issues, on the matter of how do you actually write software?

Are you really opposed to "a class" on writing software being included in CS curricula? CS courses have plenty of writing software.

"We're going to ask you to write code for four years. Professional coding may not be the point of this curriculum but coding is still the primary way you're going to interact with it. And don't you dare take even a week to sharpen the saw out of those those four years, because that's not the point of this curriculum! Saw with that dull saw! Saw harder! Because sawing is not the point of this school, so we're not going to teach you, so just saw harder!"

How is this a sensible position? It's not even "vocational training" being called for here, it's basic fundamentals for anyone who is going to code. I can tell you from experience that data scientists could stand to be oriented on the basics of this stuff too, and it would pay off in less time than just the course that taught it, let alone the full curriculum, let alone a career.

This is agreement with you, btw. Of course the very basics of management of programming should be taught. Of course the stuff in the blog post should be taught formally in some introductory class. Who trains their football players by just having them play games over and over? Who teaches musicians by just having them play concert music? Who expects English students to improve by just writing journal articles continuously? Every field has some sort of basics to it that aren't the actual output of the field but will cause anyone who is weak in them to waste arbitrary amounts of time spinning uselessly on useless irrelevancies.

I found VSCode's remote plugins to be a really good option when the code lives on a shared remote machine over a slow connection. vim+scp is an extra step on each change, vim over ssh is just awkward, and sshfs isn't the most reliable piece of software.

> vim over ssh is just awkward

What's wrong with vim over ssh/mosh? I was taught emacs by a grad student back in college and the ability to be fully productive on any server where I can install emacs has been a huge benefit to my career. I can't imagine vim is much different in that scenario.

Most people don't use vanilla vim, from what I've seen. It's not so great, out of the box. Definitely not comparable to any remote editor these days, that also supports vim navigation, like VSCode.

What does vim lack that one might need to complete a basic programming assignment?

Integrated linters save a lot of time with their immediate feedback. Depending on the language you're working with, remote debugging can be an incredible time saver. Modern editors are aware of the structure of the code, so can do things that are impossible for default VIM to do, like find the usage of a variable, rather than text occurrences, automatically show documentation, etc. All time savings.

Agreed, good points. I guess I still wonder whether these are needed for an introductory assignment. A vim/ssh workflow seems more future-proof than any particular IDE. As an instructor maybe it would make sense to do the first assignment with low-level tools, then introduce VSCode/etc and briefly demo these things, to make the added convenience even more visceral to the novice.

> would make sense to do the first assignment with low-level tool

Sure, but if the goal is to teach programming, I think vim massively confuses a beginner. vim is hard for beginners, famously so. Something like VSCode, used as a remote text editor, is trivial and familiar to anyone who has used at MS Word. I agree it should be introduced, but there's definitely some cargo cult around vim and "the old ways".

Idk, if we're working on a remote machine already, it's not the student's first day. The bar to basic editing with vim is pretty low. Mode switch with i and esc, :x to save/exit, navigate where your fingers already are, slash to find. That all fits on a sticky note if it isn't already memorized in the first 30 seconds. They've likely played video games their whole lives, I struggle to see how mapping buttons to behaviors is a foreign or difficult concept.

As you say we're teaching programming. The ability to pick up an unfamiliar tool and get to know it on the fly is critical and the only way to develop it is practice.

These days you don't edit things on servers. The most you might do is edit a file and change a single option. You can do that in vi, vim or nano. Certainly you don't get to install you favorite editor (and version) and the .config folder an every server.

Most of the time you'll be editing config locally on your laptop and it'll get pushed to the servers via config management or whatever.

Your laptop is the place for your tricked-out IDE with 27 plugins

I learned vi on a Tandy Model 16 running Xenix. The Xenix console driver, for whatever reason, throttles comms to the display to 9600 baud. It was fine. Today a "slow connection" is megabytes per second. Latency may be an issue, but otherwise vim, or any terminal-based editor, will run nicely over any modern connection.

By contrast, VS Code needs to inject itself, plus any plug-ins, over to the remote side. Wanna know how long that can take if the link isn't decently fast?

I don't think he was shitting on command line tools; he was shitting on the remote machine his child was having to use, which was slow and unreliable.

> Also big disagree on the final statement of the article. CS is not a vocational major, nor should it be. There are plenty of good post-secondary schools that focus on writing code and the tools you use to do so; CS curricula should not be focused on producing programmers, it should be focused on producing computer scientists. The recent insistence that we turn CS programs into job-mills is one of the big reasons for declining quality in my opinion, my local university CS program was recently told to "push more people through" and to make the curriculum "less theoretical" and more "career oriented". If you want that kind of stuff, go to a career college.

Colleges should make this distinction clearer as well. I got a CS degree, and my belief was that I was being taught how to become a software engineer.

This. Software engineering needs to be a separate field from CS, as mechanical engineering is a separate field from physics.

But maybe it's good that you were taught how to become a software engineer. My guess is that 90-95% of CS grads will actually work as software engineers.

But, a question if I may: How good of a software engineering training was the CS degree? Would a real software engineering degree have done a better job?

> But, a question if I may: How good of a software engineering training was the CS degree? Would a real software engineering degree have done a better job?

In my opinion, it was pretty bad. We didn't get to write much code after CS 101, and we only had one group project in a class that I cannot remember - so there wasn't much opportunity to learn how to develop in a collaborative environment.

What this meant for me is that I learned on the job, and my first job was at a very small PHP/JS shop where I learned some very bad habits that I didn't know were bad habits at the time.

I think a software engineering degree would have been significantly more useful, and I don't think the CS portion of it would have had to suffer much. I think the college even offered that degree at the time; I'm not sure why I didn't switch.

Software engineer training without engineering training is just programming training. Doing a CS degree does not automatically entitle one to call themselves an engineer. You're a programmer, not an engineer.

This discussion has been hashed out many a time. While they may not be an engineer by designation (PEng), the word is used often enough to refer to programmers that it is pedantic to reiterate the fact that they aren't "real" engineers.

> I don't think he was shitting on command line tools

Yes he is; he put "You can't do good work with bad tools" in bold.

Well you'd find it hard to do good work with a hammer made from cardboard but that doesn't mean all hammers are bad.

If the short term goal is to finish a project by a deadline, just use vscode. Teach yourself vim and scp later.

I think this type of attitude doesn't stop here. Vim is the topic but if you also are taking the easy paths you tend to get stuck. Sometimes you have good tools you just don't know how to use them. That doesn't mean you should throw out the tools you have and buy new ones immediately though. This can work for vim but in general reaching for something that is easy is not always the right solution especially while in college you hace classes yes but you don't have the pressure of actual deadlines and deliverables where you don't have the time to learn

Real life example I have a guy at work who didn't have the time to learn git beyond git clone. He's not a software engineer but his workflow to get things to "work" was to create a new directory everyday and clone the repos he needed. The next day he'd do the same thing again and again until his disk drive was full and than he'd delete the old directories because he thought he didn't need them anymore. This work style was ludicrous but he didn't have the time. 1, 1hour tutorial on git he nows safes the 5 minutes it takes everyday to clone the repo, and the hours lost when he deleted something he needed.

People can learn vim, and git, and insert tool here but we need a culture of teaching and a culture of asking questions. I'd argue the person in question didn't feel comfortable with sharing because they didn't want to look dumb and computer science departments tend to breed that what you can't do it mentality? That causes this problem like I mentioned and the hours of wasted time using vim and scp when you don't know how.

"At both of the last jobs I've held, it was rare that you would be in an environment where you had a full IDE."

Are you writing space robot surgery AI big data containerized event-drive sixth-generation F-99s? Just curious.

I absolutely disagree with you by the way - most people don't use vim, ever. I mean, it's a cute flex, which is what I imagine is happening here.

Just to stay with the analogy: For something to "pay dividends", you need to have some starting capital first. =)

It's much slower to gather the capital when you're starting with zero and you spend weeks just fighting the tools. It's a lot more effective to gather some capital with easier tools (IDE + press F5 to run) and then move in to the low level stuff.

This is a great take. Just like learning anything else, getting context and foundational software engineering knowledge helps accelerate further learning.

I would never counsel a beginning programmer to learn vim first, but after 6 months or so when they have their bearings, it can help text editing speed immensely. Is that the biggest problem a new dev has? It depends, but probably not. Their time is probably better spent getting up to speed on software engineering concepts and practices.

"Text editing speed" is my per peeve in this field.

If your productivity is mostly limited by your typing speed you're either deluded or the greatest 1000x coder in the world.

I spend most of my time thinking and slowly prototyping the issue. It's not like I have the code 100% ready and my mind and just need to type it out as fast as possible and it'll Just Work after that.

And if it's speed of generating code you want, you can use templates in IDEs for it instead of going ":as12#:asd" in vim. Or use Copilot or a similar system to generate the rough outline and finish it up yourself.

Theory vs career training in college is not a simple issue. In reality many students are going to college because they want a job, that’s the goal, that’s why they’re there, that’s why they’re paying. Employers want graduates with practical skills.

This is a huge divergence from the University landscape in the 20s for example, where the purpose really commonly was “we’re here to think thoughts, for their own sake.”

I don’t necessarily mind the latter, it has a role and purpose for humanity, but it’s also not compatible with the existing paradigm that every HS grad has to go to college and accumulate debt to have any chance at a career.

Colleges do need to get real about their contemporary role or accept massive scaling back. Right now college enrollment is shrinking because of these issues.

And trade school enrollments are up. https://thehustle.co/04242023-trade-school-enrollment/

Universities will need to get used to smaller enrollments.

https://www.bestcolleges.com/research/college-enrollment-sta....

Everyone going to trade schools is just as stupid a line of thinking as everyone going to college, and yet I hear the former now all the time.

What if we combined universities and trade schools then we kill two birds with one stone.

That’s already happening in many cases as universities launch their own clock hour programs.

The human tendency to decree how large scale, complex systems ought to be never ceases to amaze me. Everyone thinks they understand and have the right opinion about problems that have been with civilization for 5 thousand years or more.

The very nature of economics and education paradigms means the continuous adjustment is the correct process. Yet all sorts of people who never had to be responsible for more then a household and some team of workers think they have the answer.

> This is a huge divergence from the University landscape in the 20s

we're still in the 20s

"dividends payed out" yeah no. crusty editing utilities don't give you superpowers, sorry. it's fine to learn them if you're interested but if you read the short intro docs on VS code and print out the 1 page keybinding cheat sheet you're going to be extremely effective without wasting time learning a bunch of quirky bullshit and coping with bad design for "muh historic reasons". and you can get learn you need to know about scp from `tldr scp`.

> I really have to disagree with the disparagement of vim/scp at the beginning. It's a bit slower to start if you begin with command-line tools, but the dividends payed out by learning the standard command-line utilities are huge.

No, it simply doesn't. And certainly not in the timeframe of a single semester course.

The best things to get someone through a CS program today are VSCode and Python.

VSCode works. VSCode has lots of tutorials. VSCode has other users near you you can ask for help. VSCode works great on Windows. VSCode is useful in practically every course.

Python works. Python has lots of tutorials. Python has other users near you you can ask for help. Python works great on Windows. Python is useful in practically every course.

Notice a trend?

A fledgling programmer will get WAY further leaning into VSCode as their IDE and using Python as a replacement for command line tools everywhere. And they'll be able to use them all on Windows, macOS and Linux.

Finally, I'm sorry but the unix command line tools suck. The command line shells suck worse. There are litanies of things you have to remember to not blow both feet off with your shells. And the command line arguments between utilities have zero consistency merely for starters.

Yes, me being able to knock out that 4 terminal line pipeline is clever and super-fast, but a newbie needs things to be stable, observable and debuggable. And command line shells and utilities are notoriously none of those.

Even if you use VS Code, learning and using VIM bindings can make much much faster and reduce risks of and even help existing repetitive stress injuries.

(Speaking from personal experience)

In my current job I was forced to learn Vim and a lot of the other Unix command-line tools as we mainly do embedded Linux development. For a while I scraped by with VSCode and it’s integrated debugger as a crutch, and I do still use it via the SSH remote extension but some systems I work on are just too lightweight on resources to set that up, particularly for shorter tasks.

My advice to other novice programmers would be to learn the tools that your job requires when it becomes a priority, but always keep yourself at least somewhat familiar with tools outside of the scope of your current task. You never know when you will need to quickly get up to speed with a new tool set or language. Part of the keys to success is also gaining an intuition of when the need to learn new tools and skills is on the horizon and when to start practicing in anticipation of needing to use them.

For a vast majority of programmers today, CLI editors are not "the standard". Sorry, they're just not. The world has moved on.

To your 2nd point. Why shouldn’t CS students learn how people build software?

Computer science isn’t separate from actual programmers and some knowledge of the day to day jobs of programmers could inspire advances in Programming Language Theory or VCS

Are the dividends that significant over using CUA shortcuts* that usually are available in most other places?

I've done some reading and I'm considering diving into Vim, but I'm not sure, at least without much experience the surface level feels achievable by 2 keystroke combos and the mental overhead of getting used to using vim style bindings in some places but not others feel like exactly the kind of friction the article is trying to avoid

* Like navigating using Home, End, PgUp/Dn, moving between lines by Ctrl+arrows, Ctrl+X'ing for yanking etc

As someone who is a die-hard vim user, I agree with the article.

The amount of time over the last nearly 40 years of using vi, which I've spent messing around with vim configs and plugins, trying to get a smarter editor, has been amazing.

Over the last year I've switched to LunarVim, which is a pre-packaged vim setup with all the plugins and configs, and an LSP and TreeSitter, and it's been amazing. All the "IDE-like" setups I had done in the past either were half-baked or ended up breaking in obtuse ways fairly quickly.

LunarVim is giving me great code suggestions from the LSP and really is a game changer from my various older vim setups. I catch so many errors I would have run into at runtime now that I'm getting python type annotation messages right in my editor.