Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler.
Starting out, or only ever leaning a compiler is also hiding a lot of things from you.
Now, I am familiar with assembly, I live and breathe it honestly, but I don't gatekeep and say "you're not a real programmer unless you've written your own assembler macros". Some people are happy in their IDEs and see no reason to move to the lower-level of abstraction in their tooling. I don't see why we should fault or shame them for that.
Personally, I see shell as a poorly-designed, very error-prone language and I think we should move past it, onto far better tools.
I'm talking about the befits of knowing more stuff.
I'm not arguing against IDEs, I'm only arguing about the benefit of also knowing other stuff.
Better tools: I'm very interested in, what I would in lieu of a better term describe as, Bret Victor's ideas and the example of Swift playground. At the same time, I'm very sceptic against everything that isn't a simple, human readable Textfile underneath. One thing I keep thinking about is making diagrams executable, but I haven't seen a graphical programming language that convinced me. Still, I think this could happen some day, if someone finds the right design.
Is "gatekeeping" now just another word for making people feel bad? Like "pretentious" or "elitist" has become? Nobody is saying that people with crutches shouldn't be allowed to walk.
edit: It's so strange to not only demand the right to not know how to do something without a complicated tool (a right which is inalienable and not threatened), but to also demand that people who do know how to do that thing not think that it is better to know how to do that thing. I get that when one has invested their time into a tool they want to defend its usage, but people who aren't dependent on a particular vendor's tool have also invested time, and should be able to think it's better to not be dependent on a particular vendor without it being considered violence or bullying (in the modern twitter sense.)
I mean shouldn't you feel bad if you're trying to discourage active engagement in a topic if one doesn't do it in a specific "correct" way?
Personally I've found a diverse set of viewpoints to be incredibly valuable on the teams I've been a part of. I have my own biases on testing, stability, performance and seeing how others approach it has broadened my understanding of how to build software.
To put it another way, the parent could have said "IDEs are awesome and I've found when you combine that with an understanding of the CLI you have an awesome set of tools at your disposal that are greater than the sum of their parts" instead of making it an exclusive trade off or implying that IDEs are limiting.
> instead of making it an exclusive trade off or implying that IDEs are limiting.
But that would be a completely different argument. Their whole point is that there /is/ an exclusive trade-off, which is different from what they're trying to say.
If you want my opinion, they both piss me off, just in different ways. The IDE requires me to use my mouse, even with the best Vim impersonation plugins. I hate that, but I put up with it because the autocomplete, syntax completion and indexing just works so much better than the Vim equivalents which fall apart under heavily load. And conversely, trying to edit remotely complex projects is a nightmare with Vim, no matter which distributions I use.
Which maybe is a different tone of saying exactly what you are saying.
I literally said that "IDEs are great tools" and my whole argument was that people can broaden their understanding by also learning some shell in addition to their IDE.
I'm sure that was your true intent, but the way you framed it made it seem like it was in exclusion(the dismissive "Cool." at the top didn't help).
At the risk of sounding patronizing as much as we'd like to everything to be binary pass/fail and survive on the technical merits or semantic details, how you frame things and driving communication in an inclusive way is important of you want to convince people that something is worthwhile.
I agree, but I can only control how other people understand my words to some degree, especially in a fast paced, low effort forum conversation. The prejudice of the reader will drive their interpretation more than my actual intent.
You can read my comments as gatekeeping or as the exact opposite - an invitation to come through the gate and see what you can learn here and take what is useful to you.
I didn't mean to frame the IDE as a crutch, I'm merely saying that you should try to not let it become a crutch aka. overly rely on it.
I recently worked with a colleague who couldn't run the python program he wrote without the IDE. The IDE was not installed on the PC we were testing the program on.
He is a better programmer than me.
And I'm not saying "people who are using IDEs don't know anything".
I'm literally only talking about the benefits of also knowing some basic shell and CLI stuff.
For a lot of people, the IDE does end up being a crutch. I was one of those people, and I can honestly say that over reliance on IDEs really held me back. I became a much stronger programmer when I ditched the IDEs for most tasks. I'll still use IDEs for a few select things, but overall they tend to hide a lot from you and you end up learning the IDE instead of the concepts of whatever language or framework you're working in.
> Some people are happy in their IDEs and see no reason to move to the lower-level of abstraction in their tooling.
True but you're also at the mercy of whatever company is responsible for developing those IDEs. I'm not advocating everyone do development in shell but I feel like you should know what's going under the hood when things go wrong.
I mean, we know the answer to this as it started the argument, right?... vim, emacs, and a handful of programmer-oriented GUI text editors such as Sublime Text (or whatever; I don't use them so I might be mixing up "what's cool" or be so out of date as to be laughable).
its always beneficial to learn technology at a lower level. if you are running Windows, its good to learn Powershell. if you have a refrigerator, it is good to know how to change your water filter, clean your fan etc. the purpose of the article is simply stating that familiarizing yourself with posix shells is beneficial to a modern day programmer and I don't think anyone can argue with that.
> Still, a lot of people start out programming with complex compilers and end up being unable to hand-write their assembly code in pure HEX without the "help" of their compiler.
I will reply with a car analogy. You can be a professional driver even if you don't know how to write the chemical formula for the combustion in your motor. You can not be a good professional driver if you don't know how to change a flat tyre or check your oil. No matter how good your driving is, if you cannot change the oil you are an incompetent driver. Maybe in the future, cars will not need oil. So good, but today they do and you need to deal with it.
Likewise, today's computer systems rely on the shell. If you are shell-illiterate, you are an incompetent programmer, no matter how good your programs are.
Starting out, or only ever leaning a compiler is also hiding a lot of things from you.
Now, I am familiar with assembly, I live and breathe it honestly, but I don't gatekeep and say "you're not a real programmer unless you've written your own assembler macros". Some people are happy in their IDEs and see no reason to move to the lower-level of abstraction in their tooling. I don't see why we should fault or shame them for that.
Personally, I see shell as a poorly-designed, very error-prone language and I think we should move past it, onto far better tools.