Hacker News Reader

Comment by turbinerneiter | Hacker News Reader

Cool.

Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE.

Starting out, or only ever leaning an IDE is also hiding a lot of things from you.

For me, knowing the shell isn't about IDE vs. shell tooling, it's about, whatever you use, be aware and knowledgeable about the foundation and being able to do stuff even if there is no IDE. An IDE is a great tool, but it shouldn't be a crutch.

And vim without extensions - I'm pretty sure that's a rare thing among programmers.

View on HN

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.

Where did I fault anyone, where am I gatekeeping?

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.

By framing the IDE as a crutch, that's very much in the gatekeeping category.

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.

So not sure what your point is.

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.

> True but you're also at the mercy of whatever company is responsible for developing those IDEs.

With all the IDE companies being so ruthless, I wonder where are all those screwed-over IDE users running to.

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.

>> Still, a lot of people start out programming with complex IDEs and end up being unable to run their code without the "play" button of their IDE.

Yep. Another thing I hate is IDEs that build their own project files that tie you to them. A good IDE works with standard tooling, not as a replacement.

I could not agree with this more. I've worked on projects with some unholy combination of (gnu) Makefiles and VS Solutions. I've never "got" Visual Studio and have always found it very jarring -- but I mostly don't use windows much, and that always feels like it has a way of thinking that is...very orthogonal to mine. KDevelop has honestly been the best "not in your face" IDE I've personally found. I mostly do not do any MacOS programming, but when I have occasionally played, I've realised that xcode is brilliant but it seems like it utterly reinvents itself every major revision number. Eclipse, something I rarely-if-never used has sunk from a popular zeitgeist without a trace. Many of my colleagues (in a medical imaging setting) use jupyter, RStudio or Matlab, occasionally venturing into julia.

The winds shift, and the ship of progress sails a direction that is difficult to chart, but vim....vim never changes, and for that I am very glad.

I'm not really an IDE person but I find native Netbeans projects easier to understand than Maven ones.

Cant we make this argument for any level of abstraction?

A lot of people start out with shells and end up being unable to understand how to construct a switch or adder in logic gates. A shell is a great tool but shouldn't be a crutch.

Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate".

At the same time, I know that's extremely unreasonable to expect. I guess for the shell and editor, you can argue you ought to understand it stripped of abstractions, since it's actually the level you're working at, while most people don't work at the logic gate level.

As an EE and compsci major, I loved knowing how to form a transistor with n and p types, how to form NAND gates, how to deal with clocks and timing (ok, that’s a lie), how to make vhdl turn into fab rules, how cpu and system design influence compilers, how to write a compiler, various programming languages, np completeness (ok, eh), program design, architecture, distributed systems, machine learning (getting there).

The usefulness of knowing the whole stack has diminishing returns though.

It can be helpful in a large company where I can make connections that others can’t, but in a small company it’s less relevant unless I were solely focused on one specific connection (say, how machine learning using math as designed in an ALU inside a CPU or GPU is ludicrous—go analog and get four orders of magnitude speed up, all that time waiting for carry bit propagation, yuck!)

Your time is probably better spent learning to be a good generalist or specialist in your field, rather than knowing inside so many layers of abstraction.

Another book recommendation: "Elements of Computing Systems" by Noam Nisan and Shimon Schocken.

It doesn't go all the way down to the physics of semiconductors, but it goes down to logic gates and all the way up to tetris (there's a related course/website called nand to tetris: https://www.nand2tetris.org/)

If you want to go further down, check out Jeri Ellsworth's old videos where she built a transistor at home: https://www.youtube.com/watch?v=w_znRopGtbE

You may like "The Secret Life of Programs" by Jonathan Steinhart.

It starts at boolean logic and works up to a web browser and then some other stuff.

Edit: It's a high level covering of each topic of course, it does have to fit in a book. It's ~444 pages.

>Emotionally, I actually agree with this. I'd love for at least a basic understanding of computers down to boolean logic and the very basics of semiconductors up to the OS level and beyond to be "widely known" by programmers and "computer literate".

cf. https://www.pbs.org/show/crash-course-computer-science/

No, it won't give you the level of understanding that an actual comp sci/engineering degree will (after all, it's just a couple dozen ~10 minute videos), but it does touch on all the major concepts and through the series builds on concepts presented earlier.

> At the same time, I know that's extremely unreasonable to expect.

However, that's exactly the path every Electrical & Electronics Engineer classically took.

Yea, this was basically my computer engineering curriculum. Start at solid state physics, build a transistor, boolean logic, digital circuit design, cpu design, operating systems and device drivers, and then software engineering.

Most people in my class ended up at the top of the stack (operating systems and software engineering) since the jobs are more numerous and the pay is better.

> Cant we make this argument for any level of abstraction?

We could also make the opposite argument for any level of abstraction: can you really say that someone who buys apps for their iPhone and runs them is less of a programmer than someone who actually programs? If programming is just getting a job done, and being a good programmer is just picking the right tool to get the job done...

The real question is pragmatic, not theoretical. Does your dependence on a tool sometimes make easy things impossible or encourage misunderstandings about lower level processes that lead to bugs or inefficiencies? Is it simply too big or expensive to run in all of the places you might want to program? Does the tool make up for that lack of flexibility with increased productivity? Those are real questions that you can ask about any specific tool (including the shell.) It doesn't mean anything to ask them about tools in general, and the idea that sacrifices and benefits must all come out even in the end is just the law of averages.

Absolutely true! Ordered an FPGA dev kit last week for this reason.

Perfect world, you know everything.

In reality, you can't and don't need to. Knowing some shell stuff will be useful for most if not all programmers.

You know nothing..the vhdl to lut transformation (and the content of the bitfile) are totally locked trade secrets.

I got the QuickLogic dev kit - it uses the fully open source Symbiflow toolchain.

I think my chances of ever understanding what Symbiflow does are quite small, but that is a shortcoming on my side :D

And even if I do, I have to learn semiconductor fabrication next!

I entirely agree with you there is a time for the shell and a time for an IDE and knowing when and knowing both is a huge win.

My comment is more addressing the article where in the author mentions vim with no extensions and grepping. IMO that's often the wrong tool for the job (writing code). It can be a useful tool but there are often better tools for that job. Knowing when to use one vs the other and therefore knowing both is very useful.

Agreed. IDEs were how I was taught in class, but discovering shell tooling on my own removed the magic and made programming a transparent process.

I didn’t really started out with IDE I become overwhelmed by using an IDE its just my personal preference but I love using text editor they are very simple and minimal

My understanding, as an exclusively nix developer, is that if you’re a Windows dev, all you really have are IDEs. Yes, I know about Cygwin and WSL and the rest, but if you’re a run of the mill Windows developer then your life is centered around Visual Studio and NetBeans and PyCharm and maybe Powershell and maybe maybe cmd.exe if you’re a greybeard.

That vim and bash and all of these terminal-driven ways of developing are the unique privilege (and I do say that unironically) of working with *nix systems.

That’s not to say Windows devs don’t use vim, but in my (limited) experience, it’s about as common as using a gas-powered generator to charge your Tesla.

Reply on news.ycombinator.com