All this is going to do is destroy one of the last remaining ways of getting an unbiased review: word of mouth. It won't make people buy more {PRODUCT}, it will just make people suspicious of every recommendation they read.
Maybe companies should focus on actually producing products that are good enough that they don't need to be covertly advertised to via CIA level psyops.
We switched my grandmother-in-law over to Linux last year and the amount of support calls I've had to do has dropped to 0. All she does is use chrome to check her email, and occasionally edit a document. A majority of the time she phoned for me to come 'fix her computer' it was just a Windows update that had reset some setting, or was trying to get her to sign up for a Microsoft account before she could log in, or some other obnoxious crap that made her think that her computer was broken.
We put her on Debian with Cinnamon as the DE, and downloaded a Windows 10 theme. We even put the Windows 10 logo as the start button. For her, she has 0 idea that she's even using Linux except for the fact that her computer doesn't randomly "break" anymore. All this with the added benefit that I can do remote support far more easily now.
The other huge benefit is when other relatives come over and start poking and prodding, it's far harder for them to do any damage. A few times I needed to 'fix' things was because her 60 year-old son (who knows nothing about computers, but is a medical doctor so he must know what he's doing) would come over and install a bunch of scammy antivirus software, change a bunch of settings, then leave proclaiming that the problem was "fixed". Switching to Linux has helped at keeping his fingers out of the pot immensely.
This is just an assumption that generally, computers are doing what they're supposed to. It doesn't mean that you can't challenge it with evidence. With the amount of evidence being submitted being increasingly digital, I'm sure the intention behind this is to stop people from jamming up the courts by calling every single digital artefact into question.
The article makes a strong case otherwise. Proving a system built and maintained by a large, well heeled entity is unlikely to be possible for all except other large, well heeled entities.
> This is just an assumption that generally, computers are doing what they're supposed to.
It's more than that. You don't have to instruct a jury that they have to accept that a person does what they're supposed to do unless proven otherwise... unless that person wrote code for a computer.
What's the solution? Just sit around and bask in how smart you are while the hoards of depth-grovellers endlessly toil away for nuggets of neoplasmid. You are smart. We are dumb. I get it.
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. Learning the command-line utilities means you have the tool-set to build your own tool-set; since it's a lot easier to using CLI tools as building blocks for larger tools.
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. And in both cases I was asked several command-line oriented questions during the interviews.
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.
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.
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.
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.
> 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.
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.
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.
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
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.
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.
That said, maybe there is no right answer here. I imagine the instructor's broader approach will make the difference, not which editor they make the class use for assignment three :)
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?
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.
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.
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.
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.
"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.
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
"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`.
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
There's a difference between a company that overextends itself and fails to live up to its own promises, and the current explosion of LLMs. Are there some snake-oily VC pitches that over-promise what LLMs can do? For sure. The big distinction is that LLMs already have a whole bunch of things they're great at while Babylon was never really able to perform even one of it's promised features very well.
> The big distinction is that LLMs already have a whole bunch of things they're great at
I would say mediocre not great, and it is up to market to decide if quality threshold is crossed. So far there is no reliable data that some LLM startup started making good money and clients didn't leave after 1 year of mediocre results.
I feel like LLMs won't find their success in this "here's a LLM product!" kind of way but more by being leveraged internally by companies to increase velocity, do more with fewer employees, etc. I've certainly gained a lot from LLMs just by getting help on my own projects.
The article suggests they really didn't make any ml based approach where they take in huge numbers of case mates to train a system, so I think it can't be used to say anything about that f that approach works.
As someone who has been using search engines since the 90's, I've found that the "old-school" way of formatting your search almost like a database query has gotten significantly worse. It seems like search engines are geared more towards natural language queries now; probably because the old Google-Fu way of doing things wasn't very friendly for people who didn't use computers regularly.
My understanding is that google went from a more traditional database style which supported such queries, to a newer "n-gram" index with a layer of semantic similarity. Notably, you can no longer put a sentence in quotes to only find pages that contain that exact phrase. Also, the order of words matters more now than it used to (where the old search engines treated a space as AND, so order was irrelevant outside of quotes)
Maybe companies should focus on actually producing products that are good enough that they don't need to be covertly advertised to via CIA level psyops.
This entire thing makes my blood boil.