He even goes on to quote himself (sigh) as a proof of what he proposes.

Look, maybe someone just explained it badly to you, and you should look it up for yourself. However, if the command line looks scary to you... wait until you read bad documentation :)

My point is: yes, programming is awesome. But just like it's hard to become a good musician if you shy away from sheet music, programming is hard if you shy away from command line and a little web searching to know what $PATH is.

If that is your mindset, then maybe it's just not for you. There's still plenty of awesome things you can do in IT without ever touching code, though. Machine learning is accessible from nice UIs now. I used that, it's great.

As pointed out by others, there's also plenty of websites where you can either try things, or build complete projects. AWS, for one, has a fully browser-based editor for Lambda. Look it up, it might be the solution for you.

I spend a lot of my day working in a 'no code' visual programming environment and the difference between the solutions created by the people who know how to program and those who don't know how to program is massive. Those who don't know how to program tend to fail at coming up with non-trivial solutions and are not really able to debug the 'code' when it fails. They also always come up with the most 'brute force' solutions and can't really reason around performance.

Familiarity with this type of thinking is visible not just in computer-related endeavors, but often in everyday life matters as well.

It's the first leap and as you make it you can manage the emotions and the growth will happen.

I think there’s a lot of misunderstanding of complexity by newcomers of programming. A lot of people are pointing to the current state of the Unix command line as an example of being overly complex and bad. And certainly you could point to this or that command line tool and say that could be better designed and you’d probably be right. But all the command line tools we are familiar with weren’t designed in one go, they grew over time to fill needs. It could not have been done in one go, the different needs of different users and the overlap and disconnect is too great to know all beforehand. And the same thing would happen if we started from scratch today. We would design something we think is great and multipurpose only to realize it doesn’t quite fit this new requirement so we will have to add an edge case. Maybe we could do better than the current standard, but it won’t be perfect, there will always be corner cases and competing requirements.

Neither can most programmers if modern software is anything to judge by.

What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.

When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.

I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.

The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.

In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.

I've heard, though, that declarative programming (prolog, haskell etc) was a LOT easier for people who aren't trained in imperative programming. Whereas those who are actually have a hard time picking it up... As was my experience.

@op have a look for declarative programming. You might like prolog :)

I remember my final breakthrough in grokking Prolog was realizing that the engine hides a glorified DFS that walks a graph of concepts for you. Suddenly, all the reasoning and non-deterministic features wasn't mysterious anymore, and performance-related implications became clear. Similarly, for people who struggle with async, it's beneficial to understand that async means somebody hid an event loop from you.

Of course the solution is to learn a lot on the low level details of the compilers for these languages, at which point it’s not easier than imperative coding.

I like this analogy a lot. You can't just write code and then say "here, I'm done" most of the time. You need to know the environment it's around and what it needs to interact with/what will interact with it.

A bunch of world famous artists would disagree with you there.

https://www.themusicstudio.ca/blog/2017/11/909/

If you want to be a professional musician who works with other people rather than just doing their own thing, you need to know sheet music, especially within certain sub-domains like orchestral settings.

(To be fair, as someone who is on the periphery of the music business, the above is a simplification. I'm not trying to imply that the "rock stars" get to skate by, often they're working harder than everyone else to be/remain successful. But they are still exceptional in many respects. Your average person trying to make a living as a musician absolutely needs to know sheet music or at least it's simpler cousin, the lead sheet, to be taken seriously.)

I know an fairly good amateur folk musician who can't read music at all. He relies entirely on his ability to learn music by ear. But he can usually play something after listening to it a few times, and he mostly plays solo folk music. So because he's talented and happy in his niche, he can get by without many typical professional skills.

Similarly, I know a CS researcher who hates to use anything but MatLab, and his MatLab code is not exactly an example of good software engineering. But he's published a stack of really great papers. He's brilliant and he works in a niche.

But the average novice would not be well served by imitating either of these people. They can do what they do because they're above average in specific skills, and because they've found a niche where they can thrive.

Dude, it's just a metaphor.

* https://repl.it/

* https://jsfiddle.net/

I didn't see anything like that mentioned in the article, but I think that you can easily write code inside your browser today.

Also, web browsers are already extremely heavy and complicated. That complexity is convenient for end users, but it also has costs, like making it very difficult and expensive to create a new competitive browser. Do we really need to add another standard to turn them into offline IDEs on top of everything else?

repl.it, stackblitz.com, codesandbox.io, jsfiddle.net, codepen.io

Back then we don't even have online repls jesus christ.

These days devs got it easy it's really amazing

Plus: glitch/replit are quite slow to do any real coding inside of vs developing locally.

But maybe the future really is in the browser in this way.

If we’re deciding to bundle additional software with a browser, why would a programming environment (chosen based on someone’s favorite language) be top priority?

Saving and loading .js files uses a very non-standard flow. The editor is OK but I think basic operations like "find across files" are missing. It's very "canned" and not customizable.

In other words, it feels more like a debugging environment than a programming environment, which I think is basically what they were going for.

https://codesandbox.io

You can code in JavaScript on most browsers without installing anything. Sure, the UI of browser Developer Tools can be somewhat intimidating for newcomers, but that could be fixed with some good tutorials. But it seems the author doesn't want to just write and run JavaScript, he wants to use node.js specifically. But the whole point of node.js is to take Chrome's JavaScript compiler/interpreter out of its native webbrowser environment and have it run in a Unix-like command line environment, such as Linux/MacOS. So complaining that you need to know some of the workings of a Unix-like command line environment to use node.js seems very misinformed.

As for accessibility of programming in general, the core developers are usually not that interested in that, but for most popular languages there are plenty of third party tutorials aimed at laymen. Most programming languages are specialized tools; they shouldn't try to be everything to everyone. We don't complain that university Calculus profs don't also write arithmetic books for elementary schools either.

When I was younger, one had to search high and low on the net trying to find help using shitty dial-up service. Then, you'd end up in some IRC channel asking for help and someone simply says 'RTFM!'

Even then despite all the amazing ressource available, there is a risk of digital divide between people having access to tutor that can show the good ressource (because there is a lot of bad ressource!) and isolated people that are stuck with glorified engagement platform.

[1] https://www.salon.com/2006/09/14/basic_2/

See p.514- for the schematic https://archive.org/details/c64-programmer-ref/page/n513/mod...

I had such a delightful retro experience the other day! I had spent days fighting a segfault in a widely used, mature library. Naturally, me being new to the library, and knowing that it's mature and widely used, I assumed I was doing something wrong. No mention of the problem online. Crickets in my StackOverflow question for days. In the end, my last ditch effort was to find some of the devlopers on IRC (I hadn't used it for a decade). I was ready for the "RTFM!!!" telling off of my childhood.

But no. People were super helpful. Helped me debug and explain what the library was doing. Turns out it was a bug in a little-used corner of the library afterall! It had lingered there unreported for 3 years. 10/10, would IRC again!

That said, they did carry BBS magazines which led me eventually into the nascent WWW over the 14.4K modem I saved all my pocket money to buy.

Then I finally managed to access the resources to learn. God bless mailing lists.

I was able to fool around with BASIC easily enough, with entire programs provided in magazines like Byte.

Overall I dont see how any of their points supported the random "install node by default" conclusion - and the point saying "most" people hate command lines made me physically reel.

And for an inquisitive mind, having to type arcane command just to get the desired result is incredibly frustrating, and I don't count mindlessly browsing stack overflow or the internet just to get the stuff I need as learning. That is why course such as nand2tetris are incredibly good.

There is still an incredibly lot of stuff that can be done in matter of computer education. My dream would be a time travel libvmi based educational tool that allow to drill all the various function augmented with built in interactive explanation a la explorable and various code vizualization.

If someone didn't know what they were trying to solve for here, I'm not sure google would help them succeed.

I haven't used Google web search for years, has it really gotten that bad?

At some point, there's some level of problem-solving required which involves taking what you know, and figuring out why it doesn't work. - One extremely common way of finding out what doesn't work is searching the web for the error you get, and finding a StackOverflow page which might be enough to explain it.

My experience was that I can "get by" without a deep understanding of some thing, until it doesn't work, then I need to poke around to get a better understanding so that I can fix whatever problem I have.

IIRC, I bet you can get decently far on the command-line without having to know what PATH is (or all the places it's set), thanks to package managers making things accessible. And then you'll run into some problem so that you need to know what PATH is, and then you'll learn.

Then they need to get over that if they want to learn to code or use scratch.

On the one hand I've been using the CLI for my entire career and and would be lost without it. On the other hand also I have colleagues who learnt to code after Visual Basic/Studio became a thing and work entirely in Visual Studio and manage to deliver top quality work year after year without basically ever having to touch the command line, so it certainly doesn't seem to be necessary.

If you really want to learn to program without learning to use the CLI you probably shouldn't pick and OS who's entire development environment is built around using the CLI.

This is the right attitude to have as an aspiring programmer, but exactly the wrong attitude for someone who creates the tooling or documentation for helping aspiring programmers learn.

In other words, the target audience of a Promise library for JS are people who know JavaScript and understand async. Trying to explain the basics of JavaScript, or programming in general, in that library's documentation would be a waste of time for everyone involved. A beginner has plenty of resources to learn from to reach the appropriate level, at which point they'll be able to wield the Promise library in a useful and responsible manner.

People should deal with it and learn. No matter how low the barriers to entry are, you're still going to have to figure shit out at some point.

PS: You don't need to understand $PATH to start coding in JS. You can create an HTML or JS file, hack away and run it locally.

In video games you have blueprint systems because the economy supports this idea. For kids you have scratch.

For web dev you have some solutions but my guess is that when someone wants to use node there isn't yet any useful solution (outside of playgrounds) that is cheap enough to make and remove the need for some basic computer knowledge.

From this field came things like Scratch [1].

If you're interested a very important paper in that area (from the philosophical aspect) is "Meta-Design: A manifesto for End-User Development". [2]

[1] https://scratch.mit.edu/ [2] (PDF) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68....

Javascript is not a beginner language anymore. It has a lot of edge cases and traps that defeat the average person.

Why not? You can still write vanilla JS the same way you could decades ago without much (any?) change.

> It has a lot of edge cases and traps that defeat the average person.

It's always had that. In fact, I think the reason it feels less like a beginner language is that the solutions we've created to handle the edge-cases and traps have been solved for professionals. It's more that the way we teach it has changed. It's now a "professional" tool, so most content out there is aimed at people endeavoring to become professionals, needing to deal with all the complex realities of professional-grade problems. But you can still teach it in the same beginner-friendly way you could in the early 2000's.

I've seen this teaching my son (using JavaScript). My instinct is to direct him to use all of the techniques I use because it's the "right" way. But a beginner doesn't really care about the problems that the "right" way solves. They don't even know about them yet. So it's overkill. Forget Typescript, webpack, eslint, Angular, node, etc., let's just write everything in one HTML file (not even using <script> to include a separate .js file yet) and focus on the thing he's interested in making. We'll get to all that other stuff eventually, and then he'll actually have enough foundation and context to understand and appreciate (not to say all the complexity we've built is perfect).

I do think VisualBasic(6) had a thing there. It was so easy to visually design a GUI and slap some code into it.

That said, as a "professional programmer" I once had to maintain such a VB6 application that was developed by someone that wasn't a professional programmer and that application was absolutely business critical for that company.

It wasn't fun to put it mildly. So my take on this is that it probably died for a reason.

Yes, Microsoft killed it.

Up to the point when Microsoft killed it, it did nothing but grow. And for years after Microsoft killed it, it did nothing but grow.

Microsoft killed it because it was a mess on every level, and they didn't like the part they were the ones maintaining. But lack of demand certainly wasn't a factor there in any way.

Also I've seen some strong programmers being very productive with tools like VB6 and Delphi.

I suspect the main reason for its demise is corporates don't like installing software on client machines. It's much easier for them to deliver everything through the browser.

I see this in many in many of my apprentices - the desire for instant gratification and the lack of experience means they refuse to do anything that doesn’t immediately proceed them closer to their goal.

Here’s the thing with programming - you can’t run before you can walk.

Go read “Learn python the hard way”, do 1 lesson a day

Go do Linuxjourney - do 1 lesson a day

By lesson 8 you’ll know about /usr/local/bin and path, and packages, that’ll fix all of your gripes about not being able to install ruby, pip and node too.

And all of that is solved only after 8 days of disciplined learning. Sure it’s not immediately towards your goal but you need the lower level skills and knowledge first. And it’s only 8 days!

Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult. Go and learn some electrical engineering, go and learn some metalworking, go and learn some mechanical engineering, then you may come back and attempt to assemble a car. You might fail the second time too, but each time you’ll get further.

Stop seeking that immediate gratification, the path to success is NEVER a straight line

Most of these people find driving hard. You have to put the liquid in the hole and turn the key and keep pressing the floor-thing and hold the circle thing all while looking out the window to make sure no one gets in your way and the car stays on the hard paths.

What they really want is to just be able to jump in the back seat and state their destination then go back to chuckling at tik-toks and messaging friends until they're there. That's the kind of car assembly they want, complete with the commensurate salary and benefits. Is it really so much to ask to have that delivered to them?

Another thing I want to add on - it looks like the author is lacking curiosity. I didn't have much discipline and structure in the beginning of my programming journey. In fact, I've been trying to add more discipline and structure to my learning now.

When I started though, I had a TON of curiosity. I fiddled all the time with everything. I fiddled with settings in Windows XP to make my family's computer faster, I fiddled with my own laptop by installing Linux and trying out tons of programs, I fiddled with the code on my computer to make it do cool things on the command line, etc.

I didn't have an end goal in mind - it was just something fun to do and I just wanted to answer all the questions in my head. Being curious drove me to learn, adding discipline and structure helps to fill in some gaps in my learning that my curiosity may have missed.

[1]: https://linuxjourney.com/

It helped me a lot as a teenager in the late nineties that I could install borland delphi and very easily have a self contained windows app running without understanding too much, it gave me the confidence to go on and learn the lower level stuff.

It is only required because, as the author correctly points out, the tools we use are BAD. They are absolutely fucking AWFUL.

/usr/local/bin is an implementation detail from an OS nobody has used for decades. It's still here because we refuse to fix these ridiculous things. Nobody should need to know this.

All of which used /usr/local/bin and $PATH. Every system, regardless of programming language across python, C, C++, java, go, erlang.

Saying /usr/local/bin and/or $PATH "has absolutely nothing whatsoever to do with programming" is total rubbish. Programming as a field doesn't just include domain and syntax knowledge of a programming language, it includes ALL of the system implementation details below it, and YOU ARE EXPECTED TO KNOW THEM.

Saying something so basic and fundamental "has absolutely nothing to do with programming" only shows a terrible lack of systems knowledge, this is used in unix, linux, bsd, embedded and massive server scale deployments.

Acting like this stuff is somehow below you, just shows intellectual laziness, this stuff both BASIC (easy to learn) and FUNDAMENTAL (applies almost universally in many systems), and if you acted like this during an interview or working at anywhere with non-trivial setups you'd be laughed out of the room.

And so when CLIs became popular with (broadly speaking) the early growth of the internet, we became more familiar with /usr/local and PATH (we probably had some exposure to these already). So while yes, these are found in most modern systems, we see these things as details. PATH simply doesn't feel "fundamental" to me because I've written exactly the same kind of code in environments where PATH is used and where it doesn't even exist as a concept.

Of course, what is "fundamental" is rather a judgment call, and your perspective makes it so that these are fundamental for you.

I won't defend the original post, particularly wrt nonsense like adding node to a browser. But I do think different perspectives are at play here, and disagreement on either side does not reflect intellectual laziness or people who should be laughed out of the room.

I define "fundamental" as something thats in wide use and deployment in actively running systems. Like $PATH being in every operating system used today and /usr/local/bin on every linux distribution running on literally hundreds of millions of servers globally, right now.

And the requirement of understanding these are part of what's holding back the author of the article from not having a running ruby, pip and node.js

Superfluous, and could be replaced at any time.

And I note you immediately jump to the conclusion that I am too stupid to know these things that you know because you are clever. And that is EXACTLY the problem.

"absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge"

Were indeed critical components to all of these systems, and organisations, and that it's not a big ask to require a programmer to know them.

Also, on what authority do you decide what is programming and what isn't?

We could make a different choice, and not require a programmer to know these things. They could do everything just as well without knowing this, if we let them.

Saying "This is arbitrary if we made a different choice things would be different" is a total meaningless statement because you just move the bar and then say if the bar is moved things are different.

My argument is that eventually all implementations are embedded in reality, if not /usr/local/bin and $PATH then some other abstraction that is equally arbitrary - but in the real world, the one we live in, we have /usr/local/bin, $PATH and a bunch of other "arbitrary" lines that have to be somewhere because without these lines (or some lines) there is nothing. And you have to know them, whatever they are.

Because you know what happens if you don't know them? You end up with people writing blog posts about how difficult programming is, ranting they cant install ruby or pip or node.js, like the article above. You have to learn the underlying system, whatever it is. In this case, it's /usr/local/bin and $PATH.

I think you're not arguing that you shouldn't know the underlying system (correct me if I'm wrong) but you're more saying that these particular abstractions are inconsistent or distasteful - if that's the case, let me assure you that no implementation is perfect, and programmers for nearly 100 years now have been trying to come up with the perfect abstraction that requires no knowledge below, but in reality, it never works, because theres always exceptions, or the abstraction is not flexible enough to apply generally enough to be useful, thats like the two forces that push and pull the argument both ways.

I've come to learn that you must just learn the underlying system, because you'll be able to diagnose better. To that end, you must learn sysadmin, you must know $PATH and you must know the underlying system. Go and have a look at the programmer competency matrix - this stuff is in there

As is happening everywhere in this very thread.

I am saying that this is weird, toxic and must stop. We must be able to admit that yes, the tools we use are kind of bad. We must admit that we could do better. Otherwise nothing will ever change, and we will keep using stupidly broken tools until the end of days, while patting ourselves on the back for being clever enough to use them.

Nobody has said this to you in this thread, and the fact that you're acting like it is the only toxic thing here. This is called a straw-man logical fallacy, you misrepresent my argument so it makes it easier for you to attack. Nobody has said this to you, that part is all in your head.

I'm saying the tools are not weird if you understand them, and how they fit as a cohesive whole. I'm saying they just look weird to you, because you don't yet understand them. Can we do better? Absolutely, I'm all for better tools. But if the original poster wants to install pip and ruby and nodejs then knowledge of system paths is mandatory - because this is what they are trying to do.

In my answers above, I have named several programming languages, several operating systems, discussed my commercial experience and then talked about the rationale behind my logic.

You have done nothing but turn these into personal attacks against yourself, not discussing systems or operating systems, (not even naming one!) but always complaining about people calling you stupid or how you're the victim. The only person that has used the word stupid in this thread is you. You are a toxic narcissist, and I chose not to engage with you.

No, they are still weird. They are only not weird if you've become accustomed to the weirdness.

I primarily develop on Windows, and when I come to Linux to work on things I am astonished to find that Linux developers think nothing of using upwards of half a dozen different languages to build one thing. CMake, autoconf, shell, and python all being used to build a single C++ program is weird and unnecessary. If you don't think so I submit you've merely become accustomed to doing things in this incredibly weird way!

PS: Windows has its own developer tendencies that are weird and unnecessary, but I will at least readily admit that about them.

That said, if you are a modern web developer, you just have to understand the command line. You have to know what /usr/local/bin is. You have to know how to install your toolchain. It’s inconvenient, but it’s table stakes. I don’t think it’s reasonable to say “Hey! I’m used to GUIs so people programming on the command line are wrong and I shouldn’t need to know about /usr/local/bin“

It isn't even unprecedented. Way back in the 90s Another World used a bytecode VM for portability between hardware platforms. It ran on a whole lot of them and had input, graphics, and sound. Before that Infocom used a VM for its text adventures that was ported to many platforms. P-Code existed before that. The modern web browser, and web code, is a jankier, significantly more complicated, design-by-intertia/committee/def-facto-monopoly hybrid monstrosity. It's a document viewer with incoherent bits glued on until it kinda almost works like an application platform.

> Think of all the layers of abstraction and code that is necessary to have millions of combinations of hardware + software all show the same thing!

Not that f'ing many if you didn't engineer your VM like a blind monkey! Cross platform VMs are not a new idea, at all, and that's essentially what the modern web is, only it's the most Frankenstein version of that idea ever conceived.

Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.

I have been using them for decades. I know them very, VERY well. I am saying all of this from a position of long and deep familiarity with the tools.

Yet immediately you jump the conclusion that I just don't know what I am talking about.

Nothing I read by malux85 implied to me that not understanding command line tools makes someone stupid.

No one is screaming in rage about anything here. We do tend to get frustrated hearing complaints from people that are unwilling to take even the smallest amount of time to learn before complaining about the state of things.

What I am saying is, as soon as someone new to gardening points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, gardeners will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a gardener.

A new person comes in, and asks, why on earth do you all use chainsaws for this? Wouldn't it be easier to use more appropriate tools?

And the gardeners immediately call him clueless, make fun of him for not being able to handle a chainsaw, and tell him he will never be a gardener if he can't even figure out how to use a chainsaw.

Can you imagine if a layman walked into a mechanic's shop off the street and started trying to tell the workers there the same thing? Or a bakery?

And then people shout them down because they've apparently become so accustomed to using a chainsaw that they honestly can't imagine a better way.

Examples that I have personal experience with:

  * VB6
  * Frontpage
  * Delphi
  * Access
  * Excel
  * Hell even storyboards in iOS based Dev
  * Blueprints in Unreal Engine
  * etc... 

If you are a beginner in some topic (any topic), and encounter a group of people who are proficient in that thing, and you disagree with them about some aspect of it, the options are broadly that 1. you've hit some great insight, or 2. you don't understand, but the odds favor option 2. If, however, you're confident that you've hit onto something better than everyone else, let me echo others and suggest that you should try to implement it; either you will succeed and show the industry the error of their ways, or you'll find out why things are the way they are, and both of those are good outcomes.

There's no point to making sure a programmer knows how his environment is set up? Are you being serious right now?

Are you taking the piss? Should we also remove SOCKET's because they were introduced in that same OS?

It should be noted that _EVERY_ modern operating system implements a "path" system, even the ones that are very divergent.

Even in normal Life, when identifying people or things, we have concepts of this everywhere. How can people see that as pointless?

  process :: function
  path ::  namespacing
  command line argument :: function argument
  environmental variable :: dynamically bound variable

You keep saying that things could be better but show no counterexample.

Lead the change or stop whining. Nobody is going to do the job for you if they're satisfied by their current tools, especially if they think you're wrong.

Do it and prove everyone else wrong. If everyone thinks the status quo can't be improved, but you're enlightened, it's your chance to turn your "likely can be improved" into reality.

The non-programmer user base is immense. You can get rich by selling your alternative.

That's not a counterexample because beginners have contemporary expectations. There are simpler alternatives that just work. Why do beginners want to use Node.js locally then?

> We do things the way we do things largely for historical reasons

Nobody challenged that. The question is: is the alternative better or just a different (but equally arcane) set of quirks?

If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.

Sounds like NIH to me.

Did it do so for reasons that are still relevant today, is the question.

> That's not a counterexample because beginners have contemporary expectations.

Alright I'll present a counterexample: Lazarus. You download it and install it [0], then you run it and make programs. It has a WYSIWYG GUI builder and produces stand-alone executables for multiple operating systems. There is no complicated build environment to set up.

> If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.

I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.

> Sounds like NIH to me.

And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.

[0] I would argue that the installation step here is also unnecessary as there is no reason Lazarus cannot operate as a stand-alone self-contained portable folder other than the developers insistence on hardcoded paths.

Do you write programs that don't load libraries? That don't interact with files? $PATH is required (or something to search along to find those libraries or files). I've been programming for 25+ years and I can't think of a serious actual application that I've written that doesn't need something like $PATH. Even simple data formatting console apps generally need to load a JSON library or something similar. It's impossible to bundle every library needed for an app in every app. People keep saying that $PATH isn't needed but location services of some kind is absolutely needed! I'd argue that $PATH is the result of 50+ years of engineering/science and research and is the best known way to address that issue as of now.

Understanding your programming environment is absolutely a prerequisite to getting into programming. If you don't want to deal with $PATH, you should know enough about your target OS to know how to run things without it (which is really, really not hard to do).

No program exists in a vacuum.

EDIT: Any good small-ish project in GitHub to get a feel for the language?

Yeah they're taking the piss. You can make the same argument about GUI tools too. We're gonna be dealing with "implementation details" for awhile lol. This thread is wild. Makes me understand why all the juniors I work with suck so much.

We just use operating systems which implement concepts derived from there.

So, technically correct, though the argument has little merit.

I have struggled a lot with the nitty-gritty of ENV over the past few years and I agree with you that maybe there is a better way. /etc/, Conda, virtualenv, docker, ROS, Windows registry, they all deal heavily with managing the environment, and all have their own thorns. Then you have kube, consul, ansible, and all the fun of distributed environments.

The bottom line is, if you want multiple, orthogonal runtimes, you need an abstraction for managing namespaces. PATH is actually one of the simplest mechanisms to achieve this.

I can't just wave my magic wand and eliminate Bash, and all $PATH nonsense.

It existed before.

So as a programmer, I expect you to know about it. There may be a day when the knowledge is obsolete. Where we can coordinate politically and socially enough to eliminate all usage of bash and $PATH. But those are social and political problems.

As a programmer, I expect you to have the technical knowledge necessary to do your job. Stop complaining about the social and political context that brought $PATH to existence and just know how to use it, and don't write something like it yourself.

Programming is not AWFUL. People and the social and political aspects of interacting with others is AWFUL and always will be. We work around it, we make it better, and we improve it. But no, our tools are not CRAP, they're not AWFUL. We build amazing, wonderful things with these tools.

What a short-sighted perspective. Just pass. Seriously.

Also, using the search query "/usr/local/bin" in Google returns this[0] link first. This is my real issue. If a simple web search returns a good result first that gives you a good overview and gives you more background knowledge and more terms to search for and flesh out your knowledge, then there is little excuse to say learning is too hard. If you don't want to learn, that's fine, but complaining about learning being too hard here is unjust.

[0] https://unix.stackexchange.com/questions/4186/what-is-usr-lo...

Linux, MacOS, the BSDs... They're very much used today, not just decades ago. the /bin, /usr/bin and /usr/local/bin are very simple to understand after around 10 minutes of looking at the contents of / (root).

*/bin/ has binaries,

*/lib/ has libraries,

*/include/ has headers.

Its as simple as it gets, I dont see a way you could make a "better" system, other than maybe renaming "bin" to "binaries" for the 5 people on the planet with an irrational fear of common abbreviations.

> Its as simple as it gets, I dont see a way you could make a "better" system

I do, we could stop separating binaries from the associated other files they require in order to work. That is an artifact of how UNIX was originally implemented that is irrelevant today. Case in point: the existence of containers, flatpak, AppImage, and other such things that do exactly that! Not to mention all the operating systems, like Windows and Mac, that always worked that way.

But, a system _does_ have users. Those users _do_ have programs. There's a hierarchical relationship. I've been following along with your comments in this thread and I just don't follow what you're getting at here.

/usr/local/bin is where most Linux distros put binaries that were built locally, as opposed to those that came from the package manager...

Not to mention, if you don't understand how and where your binary is supposed to run, what on earth are you doing making it in the first place?

I am always looking for better tools and tutorials for the people I mentor, but LPTHW has been great, I have mentored 15 or so people so far from no coding to starting and running their own companies, and I have yet to find something better.

Should Chrome have Node JS loaded into it during install? I don't do web-dev so my answer is no.

Should there be browsers made for those learning web-dev that come with these? By all means, sure. Go nuts.

This also might sound elitist but I would expect the kind of person that takes an interest in coding to be able to google what $PATH is or hell take the complete instruction "add <dir> to $PATH"

Note that the installer is not saying "please make sure /lib/node.js/ is in $PATH" - this would certainly be something to expect the node.js-specific installer to set up by itself.

It doesn't know if you purposely meant to remove it's install location from the PATH, so it doesn't re-add it.

It could do what you ask, but this requires setting the $PATH. The most common way to do so is modifying bashrc, but now you're modifying the user's bashrc. Now you ask, is the user using bash? Maybe you're using the fancy whiz-bang ohmyzsh since that's what Medium told you to do, and now that doesn't work either.

If you keep /usr/local/bin on your $PATH (which is standard in most 'nix installations) then you don't have to change anything or do anything. Why do _you_ have such an abnormal system? We can play this game all day and it's fucking miserable. Just learn how to use your tools for fuck's sake.

Googling "Making sure /usr/local/bin is in my $PATH" leads me here: https://stackoverflow.com/questions/19202007/making-sure-usr...

So I fire up the terminal and write echo $PATH and then go back to SO to see that it looks like it's all set up correctly. But why do I need to go to SO? Why do I need to fire up the terminal? It just feels too damn hard and too opaque.

I think defaults and documentation and onboarding matter. Not to mention a GUI :)

The "make sure X is in your $PATH" is its own thing. I sympathize but there is a balance between docs for the expert and docs for the novice. This is closer to the former.

Steve Jobs if he was a programmer would slam today's tooling.

It's programming. It's difficult, and there's a lot you need to know to be effective. Trying to just hide things like the command line is just pointless. You need to know it. Go learn it.

Your comment to which I'm replying now shows that you do have the ability to learn this new language. You've correctly and successfully used the term "SO" to refer to a popular resource on programming. You have successfully "fired up the terminal." You've even used the terminal to echo $PATH. You're making great progress! :-)

The particular idea of installing node.js by default in web browsers seems to me like installing toasters on sofas. That would make it easier to make toast without going to the kitchen, but is not something that most people would want.

> why do I need to ______?

This is the current state of computers and programming. Computers are just concentrated piles of logic gates and they don't actually know what they are doing.

He's been a user of HN since 2010...

It seems he likes the idea of programming more than the act of it. It's similar to one being enrapt with the idea of being an accountant but in reality, just wanting TurboTax to do everything and not learning anything. But i get to play pretend that I'm an accountant.

And in terms of (free) knowledge availability on the internet for any one profession, there is nothing that comes anywhere close to programming.

Why do I need to fire up the terminal? Your OS doesn't do things via GUI like you do, so you need to validate that what it needs is available in the manner it will use.

Too damn hard and too opaque.? How did you learn that Node js was even a thing? You weren't born with the knowledge and everything has a learning curve to it, very few things are truly easy to do starting at the very bottom.

I agree that things need documentation and onboarding. I think we can view the Node js docs similar to a shop manual at a auto repair shop - it will expect you to know what tools are what and how to do certain things.

You shouldn't need one though. Environment variables are one of the core basics of any program, and you'll need to learn about them eventually. The same thing is true if you can't deal with the terminal; there's a few "magic" commands to learn but most of the terminal stuff is just "how does this computer thing even work".

Most programming tools and languages, as well as their documentation, assume you know how to manage your computer when you start programming them, as well as some basic knowledge of how an operating system works. These tools and their getting started guides are written for people who know the basics of their computer and programming, and want to try out a new language like JS. If they're too technical for you, you're not the target audience. You'd get much more out of a book explaining you the basics step by step.

The terminal is everything but opaque; you tell the computer exactly what you want rather than clicking the "just make it work" button. You're in control instead of letting some tool assume what's best for you. In my experience, the "one button to fix all" systems will work for a while but once they break (and they will) they're basically unrepairable without deep knowledge of the tooling and its configuration as well as the defaults the installer chose for you and why they're now messing up.

A problem with Javascript and Python development is that the setup is very complex and that guides become outdated (especially for web dev). There's loads of edge cases to deal with so there's loads of configurations and options most tooling supports. The magic install button would lead many to ruin their operating system configuration because they've already installed another tool that might also have had a magic install button. These tools don't operate in a vacuum, they influence each other.

If you just want to program code, grab a great big IDE like MS Visual Studio on Windows (the full one, not Code) or XCode on Mac (no experience there, but it's trivial to install at least). The experience of getting started programming in C# is very easy, just select the types of program you want to be able to make (or "all" if you don't care) during setup and your tool is set up. No fiddling with the command line, just a shortcut on your desktop. You won't be making any websites in them from the start, but they'll provide you with an environment that Just Works for writing your first program, moet likely a console window that says "hello world".

If you want to get started in web dev, you don't need node or any terminal work, just a good text editor to write your own HTML, CSS and JS files in. Sure, node is what people use in production, but it's only complicating things if you're just getting started. Guides from ten years ago on how to write HTML and Javascript are still perfectly functional if you're just starting out.

If that's still to much to grasp, there's kits out there for Raspberry Pis that come prepackaged with tutorials and with exercise books for programming in scratch and Python. Your only barrier to entry there is the money to buy the kit. You'll still have to learn everything and work through stackoverflow or technical documentation all the time, but you won't need to bother with any terminals at least.

Complaining that programming is too hard because there's no fancy GUI for every tool is like me complaining that finances are too hard because I can't walk into a bank and start making money without reading all kinds of boring books about finances. There's easy ways to get started if you know where to look, but in the end you'll always need some knowledge about the field you're entering to get started without paying someone to teach you directly.

[0] https://tutorials.yax.com/

In what way is it madness?

These are highly orthogonal concerns. html is markup, React and Rails are client/server side ways of generating that markup.

> Yet that is the expectation we've set as professional web developers

This is so weird to read. Like yes, obviously it's an expectation that you need to know a way of generating html if you want to have any more than just a static page.

> There's no need for build tools in development when we can use module CDNs

Sure, if you want to write plain JS. But that means no Typescript. No tree shaking, or lazy load importing, so your application is going to be big, and slow. No code transpiling to backfill support for older browsers.

You can, press F12.

> Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.

Why? If you’re new to coding then you don’t need an IDE: it adds complexity. You just need a “Run” button like in Excel (right?).

Additionally, you probably don’t need Node.js because it is just adding some API to interact with the operating system.

If you use said APIs then you need to learn a couple of things about the O.S. - nothing major - like what is a shell, or what mkdir and PATH stands for.

But, hey, we’re talking about non-coders here right? They don’t need these APIs, they are just getting started. So why should they need Node.js?

> People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. This is why people would rather code inside a spreadsheet application - because it’s an application.

I’m all in for the no-code movement, although I’m not the target audience. I agree that you don’t need to know how to code to setup a simple website. You can just use Webflow.

I think this article doesn’t make much sense. Every paragraph of the article (especially the outro) suggests that Node.js is not an example, it’s the target of the article. The fact that the OP is proposing to run Node.js on the browser suggests that they doesn’t know what Node is, and why you should use it.

Your code will run fine on the browser and on Node as long as you don’t use Node APIs.

Once you use such APIs, you’re agreeing to the fact that you know what you’re a doing - you agreed to use Node’s API; if you didn’t want to deal with the OS directly, then should have opted for something like Visual Basic. And if you agree to use such APIs then you know that Node exists so that you can forget about the browser.

Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.

Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding. And just about any PC has what you need. [1]

Nowadays you can technically develop on any PC with a browser by locally editing HTML / JS / CSS using Notepad, but it's rather painful. How hard would be to have a default Firefox environment for budding coders? These days you can probably do some Wasm magic to create an entire Linux OS in a browser tab, and install stuff in a virtual disk in the local storage.

Heck, it probably wouldn't be that hard to cobble together the existing pieces to make a Firefox addon to do that.

[1] Granted BBC Micro and TRS-80 weren't PC architectures, but for computers of that generation, a built-in BASIC interpreter was pretty much expected.

If you want to pick up programming as a hobby, a hobby computer exists. If you want to get more serious eventually you have to learn your tools.

You can get there today with some closed loop envirinments. But like wit QBasic and other Basics, there is very little commercially useful programming you can do there, unless it is an in-house application. See e.g. FileMaker Pro. Production grade web application programming is an order of magnitude more complicate than it was in 80s. Networking, client/server, graphical UI, responsive UI, dependencies with third party packages, multi user and multi tenancy come in my mind for example.

That just sounds mindblowingly inefficient and pointless. There's no point making these great speed and efficiency leaps in CPUs if people just do inane stuff like this.

The browser is fine as it is. If you want to use it as an IDE, use something like codespaces or any of the online REPLs, don't try to make the browser an IDE?!

Visual Basic was essential in th e90s if you wanted to create a gui app, but it was a £500 piece of software you had to buy and install on top of windows.

Now sure, if you installed a standard linux desktop in the 90s you'd have things like gcc, perl etc built in, but you do today.

Nowadays you don't need a compiler for a lot of things, your interpreter is your browser which everyone has, you can just start up your text editor and create a html/js/css page, just like you could on your BBC Micro or Dos 5 machine and start creating a program by copying things out of a magazine. The standard debugging built into firefox and chromium is amazing compared to what you had with QBasic or the Spectrum 48k.

You've also got a realm of information on the internet available on how to start. If you do want to download something like Atom or VSCode it's three clicks away (literally you type "vscode" into ddg, click the first link, then click the deb)

If you want to program something even simpler from entirely in your browser you can pop over to Scratch or Purple Mash and build a game from the browser.

Before the times of Firefox, Mozilla (the browser, not the company) actually did have something like that: Mozilla Composer[0]. Granted, it was a WYSIWYG editor and today no one writes entire websites that way anymore. But it still allowed basically anyone to start their own website – an idea which I still find very appealing as it's so close to Tim Berners-Lee's vision of a web where everyone is both a consumer and a producer. (Whether or not this vision was ever realistic is a different matter.)

[0]: https://en.wikipedia.org/wiki/Mozilla_Composer

Nope. That's not what they're criticising.

"Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.

Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding."

Bash is 5000x more powerful and user-friendly programming environment than any version of rom BASIC ever was.

qbasic... well guess what? qbasic was not necessarily just there. It might be there. You have to type the command at a command line, and if it doesn't work, you have to investigate %PATH%

Bash kills basic hands down, as a programming language mind you, using only it's built-in features, forget the fact that it's also a wrapper around exec(), and it is right there exactly like the the old rom basics were.

There should be an "educational" mode on every computer where you can just boot into it.

https://glitch.com/

https://runkit.com/home

https://codepen.io/

https://github.com/features/codespaces

Maybe you don't need new browser ?

Maybe ?

https://twitter.com/tomcritchlow/status/1349839954558427136

The solution to this is to use an actual native IDE, not try to shoehorn it into the browser, which is completely inappropriate.

We could package programming languages up with GUI installers that set everything up correctly and let you get right to the code - and in fact, we used to. If you install IntelliJ, you'll have a fully-working Java environment out of the box. The same for Visual Studio.

Why the "hacker mentality" languages think this sort of user-obsession is beneath them, well, that escapes me...

The thing is, that's the system they are using. Node.js is a programming runtime for that system. Node.js has a GUI installer that sets everything up correctly, it's just not an IDE.

Jetbrains has an IDE, WebStorm, that probably works just as well as the Java one. It can automatically download Node.js for you, so the same experience as for Java is available there as well.

Those would be fairly trivial changes to the website landing page, but they could drastically reduce the steepness of the on-ramp.

By contrast, if I visit python.org, there is a clear funnel leading me to alternative development environments, beginner tutorials, etc.

Compare with https://www.javascript.com/

npm? got it. whoop. yarn? okay cool nope. bower, now? wow. all set.. no. webpack. done. wait. gulp? okay okay. are we there yet?

Just as an aside, GUI installers are an absolute cancer. I don't mind if there is an option to do that, but I just wish I could make a simple script for installing all the necessary programs on Windows, just like I can on Linux. But no, I have to spend two days doing nothing but manually clicking through the installers, because that's fun.

That's a whole additional world of arcana, since the Windows PATH variable works subtly differently, and is configured through a (fairly obtuse) GUI in an unrelated settings panel.

> On most Linux distros you can simply run the equivalent to `sudo apt-get install nodejs`

The OP is however on a Mac, where there isn't a default package manager. Now suddenly novices have to go learn about the differences between Homebrew vs MacPorts, and why neither one works properly on their shiny new MacBook.

> Just as an aside, GUI installers are an absolute cancer

For us linux sysadmins? Sure. For the rest of the world GUI installers are just how computers work.

It doesn't tend to be true of mature IDE-first environments (see the aforementioned Visual Studio or IntelliJ).

There is undoubtedly work to be done into making programming more accessible to newcomers - almost all tutorials on code start in the wrong place, assuming a lot of knowledge of the difficult bits but then labouring through the easy ones.

I don't think the problem is tooling, but how we introduce and talk about those tools - you can quickly explain the command line in a way that takes the fear away and gives learners a framework for understanding it, but you have to give that explantion; too often it's skipped over.

um... because you didn't press ctrl-shift-I?

But frankly, if you can't manage to install ruby and think $PATH is somehow complicated or scary, I don't want you writing code. So maybe it's for the best that you haven't discovered the developer tools built into every browser.

No, but I also don't want them being paid for their efforts to prove the Riemann hypothesis using only an abacus.

>we need to be better teachers

According to google there are about 1,040,000 results for 'what is "$PATH"?'. I feel like one or more of those is probably a pretty good resource.

They don't want to have to google what $PATH does, they want the browser to come with an IDE (and massively ramping up its complexity because why?) instead of actually downloading an IDE.

The author has weirdly treated the problem of not knowing something as that it is wrong that they need to know it.

Yes, that’s TFA in a nutshell.

The title is deceptively “normal” though, so lots of people are making good faith attempts at answering the question. Except cloud9, code-server or whatever aren’t what TFA asks for, since you still need to understand what’s going on in the server to use them effectively, you’re only offloading storage and computations to a remote machine.

There's nothing wrong with being new to coding, not knowing things, and making mistakes - it's how we learn - but when you start your article with list of things that you couldn't be bothered to do a web search for, proudly proclaiming your ignorance and unwillingness to learn and expecting me to do your thinking for you, I don't have much interest in being nice and/or trying to teach you stuff.

For anyone that doesn't know that, open dev tools > Sources > Filesystem > + (Add folder to workspace) > right-click on folder > New file. Then double-click on file to open it for editing and save modifications with Ctrl-S. Of course it isn't an IDE, with even the editor being nothing more than a Notepad clone, and you're limited to client-side work which is in contrast to what OP seems to want.

Recently, after a few days of trying to set up Scala to work with the latest JVM in Visual Studio Code I just gave up and installed IntelliJ IDEA instead. Works out of the box.

I'm a seasoned programmer with 15 years of experience in Python, Java, Scala, OCaml, C++, JavaScript, Linux, bash, ... (a.k.a. I can do or learn pretty much everything). Could I set up VS Code to work with Scala? Yeah, probably. But why would I bother?

UI matters. Programmers mostly suck at UI. Which is reasonable, really, because after you set it up once, you can easily forget about it...

But I also believe that he makes a lot of great points. Installing and maintaining programming languages is too hard. Going from "I would like to try some $lang" to being up and running is usually difficult and requires you to install binaries, then deal with PATHs, and with CLIs, and REPLs and a bunch of cruft before you can start experimenting and getting to the interesting parts.

The programming language experience comes with a shitoad of stuff that really has very little to do with the language itself.

There is also a lot of potential in more flexible tools that allow me to create small apps with, well, maybe not with minimal coding, but with minimal installations, minimal integrations in my particular OS, minimal maintenance of the installed binaries and tools etc.

I think a lot of people here forget that people who program no longer need to be "programmers", and understand every aspect of the system. For these people who just want to simulate a model, or do some calculations, or automate a mundane task. For them programming is a means to an end, it's about the result.

But, I don't see why this guy thinks installing NodeJS is hard. I have a low tolerance for painful installs, but NodeJS and Visual Studio Code were quite easy for me to install and pick up.

Furthermore, you can code in a browser: Azure supports this, although it was somewhat buggy when I tried it.

A browser is all you need to start coding and everyone has one installed on their system.

Also on coding is too hard for newbies: JS, Python, PHP are NOT hard. I couln't have became a developper 25 years ago when programming was really hard but nowadays building usefull applications with JS and/or Python the myriad of libaries available and the ridiculous hardware ressources at the disposal of anyone, it's not hard anymore.

And all of that goes against the ease of access the OP post seems to request.

Short answer: you can write NodeJS code inside your browser[0]. Being able to do so will not solve ANY of the problems listed in your blogpost.

The author's problem is that they don't have an attention span for learning a domain which contains necessary complexity; they crave quickfixes but don't have enough basic knowledge to understand why those quickfixes won't help them.

> An incomplete list of things I’ve tried and failed to do:

> [lists 3 things that most/many web programmers fail to do regularly as part of their day-to-day]

I've failed to install node or pip at least 100 times. This is a normal part of learning anything in life. How many times did you fall off your bicycle as a child?

[0] Whether it's repl.it, Codespaces or some other method there a million ways to do this depending on your needs. All do require a basic understanding of code which the author seems to lack (their bullet list of coding projects are all based on pre-existing templates & copypaste, especially their "fairly complex Jekyll blog")

A lot of those introductory tools abstract away the way that software actually works which allows you to focus on learning the basics of logic and programming. This is great for learning but extremely limiting. There is a reason why professional tools and programming languages don't abstract away the technical details. Because you need to know how things work under the hood in order to be a truly effective programmer.

This is part of why a formal programming education is so valuable IMO. It can be very hard to cross that gap on your own.

I think this article also defines a kind of smoke test for programmers. If you don't like learning how to read error messsage on a command line or googling stuff, you probably won't like programming.

To Tom I would say - programming is hard, but I think that's OK. It's not good to hide all of the technical "ugliness" of how these tools work because to be an effective programmer you need to know how they work. That's just the reality. The messages you see when working with tools like Ruby or Node are designed to be useful for a professional who knows how to read them. What may seem like command line garbage to an untrained eye is actually extremely useful to someone that knows what they are looking for...and that is what takes someone from a hobbyist programmer to a professional. Is there room for improvement? Can we close the gap between the myriad of "hello world" programming tools and the seemingly bottomless trench of "real" programming tools? Absolutely.

Cloud9 exists and although it was acquired by AWS you can still use it.

https://aws.amazon.com/cloud9/

The real solution to this problem is more awareness and good entry level resources that you can point indecisive people toward. None of his points are actually going to improve the situation even a tiny bit, mostly because they already exist and some of them completely failed while the others are there if you just look for them.

ANYTHING is hard when you first start out. Try making a table out of wood, or doing origami, or playing an instrument for the first time, and unless you're some bizarre savant you're going to effing SUCK at it. Learn why things are the way they are, or in this case learn the way things are in the first place, and your results will improve.

Sure everyone could learn about $path with a little research but there is SO MUCH to learn to get started with a "simple" react app... It's not necessary.

Great tools hands a "low floor AND a high ceiling" meaning it's easy to get started and possible to go really really far.

Clearly tools like replies show there's a desire for easier to set up environments.

Have you never wished you could save your css tweaks directly from chrome dev tools?

Why should the browser show you the page source when you could just curl it? Well... Let's try to make the unimportant things EASY so we can focus on the useful parts.

Firefox could absolutely come with a standard node server and editor. And it could integrate with providers like GitHub or netlify.

Gatekeeping getting started benefits nobody.