While there's no doubt there are some libraries/tools/systems which are poorly designed, perceived complexity may often be due to the requirement to support a wide variety of new and legacy systems or to support layers of the tech stack that many people are not even aware of.

"We've just chosen to keep things like this because we think it makes us clever."

If I could make my job any simpler I would jump at the opportunity. Personally I often marvel at how relatively quick and easy it is to quickly develop useful programs.

Perhaps if you try implementing some of these more simple tools the reasons for the underlying complexity will reveal themselves.

Two of the pieces of irreducible complexity that beginners have problems understanding (or even appreciating!) are change management and software delivery. If a newcomer created a simple but novel program and it turned out to be successful, two sure-to-follow requirements are:

- Now someone else wants to access and suggest changes to your project. In parallel. Without breaking anything.

- Now the software needs to be shared with others outside of the development environment.

Both create a surprising amount of complexity and require fourth- and fifth-dimensional thinking. You have to learn a version control system (probably)! You have to learn how to perform a code review! You have to do learn software design and hopefully documentation.

You have to learn and leverage at least one packaging ecosystem for the development approach that was chosen. Hopefully you chose one with an accessible packaging ecosystem, assuming that exists!

It takes practice to get computers to do what you want to do well and no matter what tools you use getting to know the tools will not even take 5% of the time that you need to get to a place where you do what you want.

Furthermore, the clamoring that there is some sort of nefarious gatekeeping cabal keeping programming from being easy to whoever cares to shout about it is fundamentally dismissive of the actual effort and practice put in by people who used to have (but no longer have) this problem. Sometimes the answer is just that it's not trivial thing to do and this shouldn't be a surprise to anyone. We don't think this of math, we don't think this of making good drawings or paintings.

If PATH and installing python is a struggle for them, hoo boy, no wonder they don't feel like part of the "code club".

I merely type into my favorite search bar with auto complete

"make sure /u"

And I get:

"make sure /usr/local/bin is in your $path"

And top result is a SO spelling out what this message means and how to check.

Engineering, of any discipline, is the sum of three phases: domain research, applying that knowledge to build something, testing that thing you built. With experience, you spend less time on 1 and more on 2, but with learning software, you spend the lion's share in 1.

We still need to lower the barriers to entry. That involves teaching heuristics on how to solve problems.

We do and we try every which way to make it 'natural' and 'easy', sometimes with vaunted social goals like stemming drop-out rates. The reality is, at some point, you just have to sit down, put your head down, and power through. Sometimes, like you alluded, there are no shortcuts.

There are programming environments (sometimes even gamified) for learning, but if you want to use something to solve general purpose problems, you just have to learn it.

The author is certainly correct on some things, but makes no good argument for why node.js should run in the Browser. I'm not even clear he understands what node is, or what he would gain from being able to use it in the browser, when it can already run Javascript just fine as is.

No, Google should stop the show and bring node.js to his browser because he can't be bothered to go to Google to look up what a PATH is.

I'm not saying programming can't be much more user-friendly; it certainly can be and should. Heck, maybe Chrome would do well to ship with a lightweight IDE to edit code in outside of the console. But the author hasn't listed a reason node.js has a place in Chrome natively, and is going on to claim they should. Talk about entitlement.

The question is whether it is easy to improve.

Writing good software is hard. You say it like programmers have ego, but you know what is better than ego? Money. People would lay down their ego to make money (by making a more user-friendly app).

But clearly it’s hard to write good apps. If you try any graphical programs you would see that it sucks. You default back to the terminal and vim because it’s better. I choose what works, not what gives me pride because this is work not hobby.

I CAN use the command line. I know very well how to do it. I have done it for decades. But when I program for iOS, I don't need it. The tooling is good enough that I never need to. So I don't.

There's no reason this couldn't be the case for other environment too. There's nothing magical about iOS other than that Apple actually values developer convenience and put the effort in that others are unwilling to do.

What you are really complaining about is the fact that nobody is there to shout in your face that these options exist.

> Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.

You can take that either way :)

You need that knowledge to build production level applications. The problem is not that these tools are useless, but rather that the audience you are thinking of doesn't care about them. Instead of crapping on other's people's work just look for things that are actually suitable for your own needs instead of trying to one up the experts.

>It's not. It's really not. Nothing has to be this esoteric and annoying. We've just chosen to keep things like this because we think it makes us clever.

I'll be honest. I don't like people like you. You are making things harder for yourself. You have chosen to go down a difficult path and then you complain that the experts that need these difficult tools are stupid.

Why? There are lots of easy to learn programming languages. You can start off with a very limited and restricted environment. Just fire up a google spreadsheet and start writing javascript if that is all you want. Don't complain that writing a production level web application is difficult because you need to know about complicated things like what a HTTP server is and why it has to run on port xyz and why everyone calls their own computer localhost.

>Programming can and should be much, much more user friendly than it is now.

It is so user friendly even kids can pick it up if their game supports modding. You're not looking hard enough. If someone were to hand you everything on a silver platter you would never learn on your own.

Programming is in some cases over-complicated, for no reason. If you dig deeper however, you'll sometimes learn that the thing you considered overly complicated, was actually designed that way, not to annoy you, but because the same tool has to support use cases you didn't consider or don't understand.

That's not to say that things couldn't be simpler in many cases.

Witness, say, beginner python tutorials that start with "These 15 tools let you set up a development/testing environment that ensures your code can be tested against every platform that has ever run python". Useful tools, but poorly matched to the 'I just want to *learn how to* print "Hello World"' use case. I suspect we're all a little guilty of that occasionally.

Which part is over-complicated for no reason?

I think the point was that some things do not justify their complexity. Especially if you discount inertia.

Trivial example: the creat function could have been named create. That's one more thing folks just have to know and the reason for it isn't much better than "just because".

Again, can you provide an example? Because like you implied, tools like node.js and npm, were made with a purpose. They are professional tools made for professional programmers to solve commercial problems. They aren't made for beginners and novices to teach them about programming concepts. Their complexities stems from the fact that they need to support all kinds of deployment and runtime use-cases and can't be too opinioned on how they should be used.

>Trivial example: the creat function could have been named create

That's your example? Really?

Some are essential complexity, sure. But many aren't.

Oh come on. You're complaining about a function name (created decades ago) in a system level language as an example of 'needless complexity'. That's not complexity - that's just a quirky name kept around for backwards compatibility. By the way if you don't like 'creat' or find it difficult to use then don't use 'creat' use 'open' with the relevant flags. Any complexity around C programming does not come from this ... Honestly.

I have yet to see someone actually point out a good example of needless complexity in programming - something that the blog author is complaining about that apparently you agree with but cannot come up with a single reasonable example.

What are you trying to do?

Say I'm Santa and have a list of names in "naughtynice.lst", in the format

  Joey Bloggs,train,nice
  Johnny Doe,car,naughty
  Mary Lamb,car,nice

I can get my shopping list by simply creating a file on my machine

  my $i = 0;
  my $toys = {};
  my $coal = 0;
  while (<>) {
    chomp;
    my ($name, $toy, $nice) = split(/,/);
    if ($nice eq "nice") {
        $toys->{$toy}++;
    } else {
        $coal = $coal++;
    }
  }
  
  print "$_: ".$toys->{$_}."\n" foreach keys (%{$toys});
  print "coal: $coal\n";

  perl test.pl naughtnice.lst 

Now you could say that you don't like the syntax of perl, or python, or basic, or java, but actually knocking up a quick program and running is no harder than writing that same code in some hidden part of excel

For what sort of users? It's clear a number of people here consider the command line difficult. I do not. There are many tools that make simple tasks very simple. I use it for manipulating tab files. I can pipe data through scripts and back through command line utilities, pipe it directly into a database, or do the reverse. It's very simple, and very powerful.

Just because you don't understand it or aren't familiar with it doesn't mean it isn't simple, powerful, and user friendly.

Most programming languages are very simple. a = 1, b = 2, if a+b > 2, doSomething(). You can't actually make the logic simpler than that - this is why visual programming fails. It's still programming, but it turns out a limited visual/gui tool to do these logical operations is much harder to manage and work with than actual code.

Consider all the things you've committed to memory that you've had to learn to do those things: all the archaic command names, all the one-letter switches, all the unreadable awk lines to re-jigger the formatting between tools, all the gotchyas and edge-cases you had to deal with in your scripting language, etc.

I think the point is that most programming tools aren’t made to be easy to use the first time. They’re made so that the 100th or 1000th time it’s fast even if every time it’s been a little different.

I didn't cite the commandline itself as the problem. PowerShell does a significantly better job at making sense than typical core-utils do, but you hear people used to core-utils bad mouth it all the time because it isn't exactly the same as core-utils.

And I submit that your lack of ability to conceptualize a GUI for doing the same thing does not mean one can't exist, but that is beside the point, because I don't think knowing how to use those tools is a necessary and fundamental part of programming anyway.

Someone who is just getting started in a new programming environment shouldn't need to know the ins and outs of a dozen different tools, especially when those tools are used to solve problems that user has not even conceptualized the existence of yet.

Again, this all comes down to one thing: why is it so damned complicated just to get enough of a programming environment running that the user can write a goddamned program? Not write it well, not write it efficiently, just f'ing write it in the first place?

If you have the time I would challenge you to spend an hour or two mocking up what you think a GUI with the same capabilities as powershell or bash would look like. I would genuinely be curious what you come up with. Personally I do not think it would be possible to do in an intuitive way.

> Someone who is just getting started in a new programming environment shouldn't need to know the ins and outs of a dozen different tools, especially when those tools are used to solve problems that user has not even conceptualized the existence of yet.

For some more complicated environments yeah it is hard to get the environment up and running. Python environment hell is a very really thing. But if you want a a simple environment to write a simple program is it trivially easy to get one up and running.

I am on computer I’ve never downloaded python on. I just googled python IDE. Clicked on the top result, pycharm. Downloaded latest release clicked next 4-5 times without looking at options. Opened it. Agreed to some TOS. Clicked new project and then clicked next without looking at any settings. Then I clicked the big green run icon. It printed “Hi, PyCharm”.

Python is a beginner friendly language and if I wanted to start programming it is probably the recommendation I would get. I did not have to know anything to install it and start programming.

And even easier if I want to do front end development I just go to codepen.com and that’s all I need to do!

Dismissing other people’s work as awful, pointless on the Internet. Well, at least it makes you look clever, in certain eyes.

But let's be honest, the design is pretty esoteric.

You want to find a file containing a particular string? For some reason the tool is called 'grep'. The name is followed by '-r' then the search term, then the directory to start the search in.

And it won't be long before you start encountering tools with such intuitive names as 'sed' and 'awk' and 'crontab'

The tool for finding a file by name is better - that's called 'find' - except compared to grep the arguments are swapped: The directory to search is now the first parameter, not the last.

Oh, to find the *.desktop files on your system you did a find on / ? Yes, the messages like "find: ‘/proc/19917/fd’: Permission denied" are normal, you should ignore them. It's easy, simply add 2>/dev/null to the command.

Before you know it, the command line infects your brain and you start saying things like "sudo and nohup are perfectly good names"

g - global re - regex p - print

https://en.wikipedia.org/wiki/Grep#:~:text=Its%20name%20come....

You bet that `ls`/`cd` is a great name for me - it takes 2 characters and I don't have anything similar conflicting on the PATH.

For a beginner? Not so much - `change-directory` and `list-directory` would probably be better. It's the same with regular expressions `^[A-Z0-9]{0, 3}$` is perfectly readable once you're reasonably familiar with the syntax.

It's also true in other fields such as mathematics or music - the notation is quite good once you're proficient in it.

I use Bash a fair amount and I don't consider it overly complicated as a shell. There are some rough edges in Unix, like handling spaces in directories, and I'm no fan of Bash as a scripting language, but I wouldn't say the basic model of the Unix command-line interface is overly complicated.

-o for outfile / output

-f for file / infile

-q for quiet

there are already many of these, and for the others that arent so common between tools. Compilers will, inevitably, need switches that, say, a code editor doesnt need.

You're right that, for example, `watch` has -n for "delay", and `htop` has -d, but then again those accept different types (seconds vs some other sub-second measurement).

And it brings no good things. This is entirely superfluous complexity. You could have all the benefits with far less complexity if you just put in the effort to build and design things.

But we don't. We've decided that it is impossible to do so. And many people have decided that knowing all of these obscurities makes them smart, and they will look down on anyone who doesn't.

> many people have decided that knowing all of these obscurities makes them smart, and they will look down on anyone who doesn't.

I don't think it's sysadmins who are pushing for this messy state of affairs, it's that various specific projects refuse to follow the POSIX conventions, presumably for reasons of backward compatibility/general resistance to change.

[0] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

[1] https://www.gnu.org/software/libc/manual/html_node/Argument-...

[2] https://www.gnu.org/prep/standards/html_node/Command_002dLin...

https://news.ycombinator.com/item?id=25305575

I admit that I'm kind of conflating the concept of a terminal emulator, a shell and a shell language, but the shell model has plenty to improve upon.

PowerShell streams Objects instead of characters/bytes. But that is more compatible with cmd than sh.

Many other points are more about the terminal emulator. terminiology has some of those features AFAIK.

This shouldn't be supported in a first-class way, it should be supported as an extension where applicable, in keeping with Unix principles. We already have this with X11.

> It should be possible to `cat` an image, or a video, or even previews of Word and Photoshop documents

Again this can be done with X11 if you want it.

> Programs should be able to raise notifications without relying on third-party/OS-provided utils that have a drastically different API and availability across platforms.

Interesting idea, perhaps this could be done with a metacharacter, akin to the 'bell' character, or perhaps even overloading the bell character. There could be a convention along the lines of BELL BELL your message here BELL BELL.

> Rich read-only visualisations of progress should be possible to call up with a few lines of code. I want to see a `dd`, `mv` or `cp` with a graphical progress bar at the bottom of my window.

wget and curl indicate progress in this way. I'm sure there are programs out there that would give you this.

> We should be able to render a piece of output in 3D, if we so desire. I don't want Crysis, but I do want a Matlab logo that I can rotate by dragging my mouse and graphs that zoom when I Ctrl+scroll at them.

Again we have X11 for this. It's not easily done, which is why we have drama like Wayland which lacks network transparency. [0]

> Support for file pickers and rich selection/filtering of file/directory lists. Not for sandboxing, but for convenience.

A file-picker could be implemented as a TUI, which is roughly what Midnight Commander gives you. Perhaps a Unix shell could support mouse-clicks for selection from its auto-completion listings. I think that would be possible, perhaps it's already been done.

> A command line builder (like one of the classic Apple OSes had, cannot find a reference now, or something like the one in Fish but more advanced). Only valid combinations of parameters will be supported, mutually exclusive commands are impossible to select.

I agree it would be great to have a system like this, akin to type safety. Perhaps applications could distribute something akin to a regex to describe their syntax. I imagine something like this is already implemented for auto-completion purposes (e.g. how Bash can auto-complete git's verbs).

> Terminals should be able to intake gigabytes of input per second, up to the limit of the hardware, without choking up.

I don't know quite what you have in mind here but you can already do this in the way that matters. You can easily run a Unix command to tarball a local directory, then compress it, send it over SSH to a remote server, and have that remote server decompress the stream and then unpack the tarball, all 'on the fly' without ever saving the intermediate streams into persistent files. This all works very well in Unix, giving you a lot of flexibility/power and good performance too. (Doubtless the flow I described would be slightly faster if a dedicated application were used instead, but Unix pipes are pretty fast).

> We should be seeing 60FPS and beyond as a normal feature.

Which command-line applications would benefit from 60fps? Better TUIs would be nice but I don't think the frame-rates are the issue there.

> We should finally get unlimited scrollback enabled by default

You can probably enable that if you want it.

> We have the space for it, either in RAM or persistent storage

Not if you accidentally stream /dev/random.

> If not, it should be adaptable and drop the scrollback buffer that is lower priority than other applications on the system if they need more resources.

This approach would have the downside of being less predictable than the current one.

> Unicode should come as standard. Emoji should come as standard.

Sure. I think Unicode support is pretty good though, I believe it's used in many TUIs.

> End termcap. We should be able to hash out ONE standard to rule them all.

I imagine this is one of those things where there will always be a few legacy systems that still need to be supported.

> end Bash

I agree that Bash has many unfortunate quirks that are annoying at best and are outright dangerous footguns at worst, especially when it's used for scripting. The only advantage of writing a traditional Unix script, as opposed to say a Python script, is portability. configure scripts, for example, run on just about any Unix, with no dependencies.

> consider adding hypertext support. It's here to stay, and not just in the form of HTML

Not a bad idea, perhaps this too could be done with metacharacters.

[0] https://wayland.freedesktop.org/faq.html#heading_toc_j_8

The point is, we should not HAVE to use a different environment. Images and media should be first-class citizens in a CLI just as much as they are in a GUI. There is nothing about a CLI that says it has to only handle text.

Breaking things down into meaningfully separated subsystems is part of why Unix has been successful. What you're suggesting would mean hugely increasing the amount of complexity in SSH. It makes far more sense to use SSH as the transport solution, using a separate system to handle drawing/windows/graphics acceleration/user input into the GUI.

Not all servers support a graphical environment, and neither do all clients. This allows for lightweight servers and lightweight clients.

> There is nothing about a CLI that says it has to only handle text.

The command-line itself should be a relatively simple canvas, not a complex rendering subsystem. It's already rich enough to support TUIs, including mouse-click support. If you want more than that, use a proper GUI.

If you want a very basic GUI over SSH without a full-blown GUI like with X11, you already have the option of using a TUI like Midnight Commander. You can preview images on the command-line, with a tool like imcat. [0]

[0] https://github.com/stolk/imcat

If we rebuilt the command line today it would be massively better

Ctrl+C sends SIGINT, while CMD+C copies text, and running commands when a newline is pasted can be disabled.

Shell (just like language) is a medium. We use it to communicate our ideas, not because it is great or flawless.

just try to imagine the language as the OS. if it were good enough, there would be no need to have different languages, and one would not have the horrible level of fragmentation and harmful shared state that characterizes today's dev environment. most people have become blind to this fact.

then there is the problem of selection bias: the majority of developers in this business have tolerated an insane level of abuse. most are proud of their abilities, even if they can be characterized as "they know how to wade through layers upon layers of shit". it is often hard to have a discussion about this, because they take this as personal criticism.

the situation we live can be described as a paradox: the Unix culture is at the same time both a pinnacle of OS design (from days gone by) and a steaming pile of shit with so many bad practices abound it is no use highlighting one (with the command-line just being a visible part).

just pointing out the obvious.

Would you want your kitchen to be limited to plastic spoons and silicone bowls, because that's easy for a 2 year old to grasp? Pots and stoves and knives, after all, are too complicated, and God forbid the knife is metal and the stove is powered.

You can't do useful things and cater for beginners at the same time, because that implies nothing can ever improve beyond what a beginner can grasp. The job of a beginner is to become proficient. They can achieve that through learning, not through expecting rewards just for showing up.

(Hell, situation in programming is actually quite good for beginners. You can go very far with toys. For instance, people make and sell complex video games in clicker tools. The experience of pushing such tools to the limit tends to shine a light on why programming is complex in general: you're pushing at irreducible complexity. Serious tools like command line exist to help you manage that complexity better.)

The general trend in programming has been moving TOWARDS command line interfaces, not away from it. Mac OS didn't even have a built in command line until 2001. Microsoft Windows in the last few years has had its command line functionality enhanced, to the point that the GUI only Server versions of Windows have been stripped back, and now there are CLI only versions of Windows Server.

You can do more now in a command line than ever before, you can do more now in a command line than you could in 2001.

"Everything should have a GUI alternative" has been tried and it has failed. Almost all computer efforts through the 1990s were focused on making everything GUI only.

What are you assuming about my experience level?

I thought it was perfectly clear that the argument isn't "there should be no command line" but that knowledge of the command like should't be necessary for beginners. Just like e.g. knowing assebler shouldn't be (and isn't) neccessary for programming. That's why I put the parenthesized statement above, specifically so you understand what the argument is. Or you could just read what I responded to.

The command line _IS_ a programming language. If you do not want to learn it then you do not want to learn programming.

That is simply not true. I have plenty of colleagues that do everything in Visual Studio and never touch the command line and they produce solution to hard problems that are absolutely useful and well written.

You can create and distribute a world-class iOS app without having to touch a command line even once. It is just not necessary. Nothing gets easier if you do.

Because iOS has actual well-designed modern tooling.

But sit in front of a device with a keyboard - one that's meant for creative use - and suddenly, the command line shines as a force multiplier.

Yet, to program for it, you don't need to use the command line. You just never need to touch it. It is possible to make a fully productive programming environment where the command line is not necessary, if you just put the effort in to do it like Apple has.

Your statement truly shows how unaware you are of actually good toolings and solutions for software development, and, frankly, you should not say a single word more about software development experience, if only not to embarrass yourself even further.

At least pro-console users had some sort of argument for their setups.

You cannot comprehend a simple idea that there are much better ways to develop software, than crippling, mind-bogglingly bad Xcode and friends.

I still find Xcode very productive, pleasant to use, and far better than almost any alternative I have seen.

It has some annoying bugs, some annoying limitations, but none that would make it any worse than the absolute shitshows you get elsewhere.

I do know what I am talking about, here. I have done a lot of this.

Wow, if I ever saw a comment on HN that was fundamentally wrong on many levels, this was it.

No, a command line interface is not "a layer of abstraction". A command line interface is an interface. That's it. Instead of pressing a button, you run a command. If you want to pass settings to an app when you launch it, you use the command line interface. If you want to script away a task, you call the command from your script.

That's it. It's not a layer of abstraction. It's an interface. They exist for many good reasons.

You must not visit political threads much.

But seriously, you could have said that in a constructive way.

Why, yes?

> Not useful, but necessary for a beginner to touch the command line?

Do you understand that you're asking if a beginner needs to run or pass a setting or even automate any operation that's relevant to programming?

I repeat, a CLI is an interface. It's an interface to perform an action and/or pass a setting. That's it. What warrants this irrational opposition to an interface?

[0] https://tutorials.yax.com/learn/your-first-custom-html-tag/i...

> Programming is massively over-complicated for no useful reason

And then offer absolutely no justification for why this is the case, and to shrug off any questions as to what obvious improvements could be made.

You offer no useful contributions to the conversation by doing this. None.

I am saying, the fact that those tools are bad is not a given. We could have better tools.

What you seem to miss is that developers tools are the best tools created in computer science, period. That's because we use them and we usually are too lazy to deal with stuff that bothers us, so we improve over time(and much faster than we do with tools for our customers). The only real problem is the learning curve, which is hard to avoid. So no, those tools are not bad. They just require some learning first, as pretty much any tool on this planet.

And yes, we could have better tools and we will have, that's how progress works. You just didn't make any useful suggestions how to get there faster.

I can use the command line. I've used it for decades. I know it intimately, and I know just how many problems it has. Problems it doesn't NEED to have, but problems that we have just decided will be there, and we learn them, and live with them, and then complain when someone points out that they are, in fact, problems.

Developer tools really, REALLY aren't the best tools created, in any way, shape, or form. They are generally AWFUL. But we've convinced ourselves that we are clever if we know how to use these awful tools.

I know how to use the command line. I could do it. But there is no reason to do so. It would not do a better job than the tools I have been given in the GUI.

1. It's faster. You can(and will after some time) remember hundreds of different commands. That means that to make computer do something, you just need to type. Typing is usually way faster than clicking in GUI, especially for non-trivial tasks, which require moving through several layers of GUI.

2. It's scriptable. I can automate pretty much anything invokable from command line through.

3. It's gluable. I can connect output of the program to any workflow I imagine.

All of those are usually strictly worse in GUI. Of course, GUI has it's uses(analysing data is usually easier in graphical environment) and there is nothing wrong with your personal preference. I object solely to your qualification of CLI being worse just because of your own taste.

Sure, in some cases, those are useful. But not always. And programming, in general, is not really a case where those things are useful on a minute-to-minute basis.

In your opinion

Trying to project your personal preferences as objective reality is not helpful. You don't like CLIs, fine. You sound like you've got some good reasons to not like them. Your assumption that everyone else shares your values is a little weird.

Personally, I love the CLI and have yet to find many instances where the GUI is easier to use and more useful than the CLI alternative. Does this mean I think all GUIs are objectively bad? Of course not. It's personal preference.

But the fact remains, they are not useful when doing iOS programming, because the tooling provided does a BETTER job than the command line.

> because the tooling provided does a BETTER job than the command line.

Once again, better for you.

I think it could be a lot less of the two former and a lot more of the latter. But it will not be, because people are unwilling to even admit it has any flaws.

> Please don't fulminate. Please don't sneer

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

This is in reply to

> We've just chosen to keep things like this because we think it makes us clever.

Sneering at the unspecified "we".

> Programming can and should be much, much more user friendly than it is now

Work has been done on programming language accessibility for decades. It's often been controversial, e.g. Dijkstra versus BASIC, despite the huge practical success of BASIC as an introductory language across the microcomputer revolution. It's not enough to assert that something should be better, you've got to say something about how, in a way that at least acknowledges what has been tried already.

(Many of the ways in which the Javascript ecosystem is "bad" are the result of it being a horrible commercial battlefield over who gets to control the internet and all the computers connected to it and for what purpose)

And 10 years later: people want ways to write a ten liner, in one line compressed.

The first one is easy to understand, easy to follow, the second one, not so much, even for the person who wrote it.. (after doing something else for a year for example)

I hate it...

There is nothing wrong with that. People want to work with higher-level concepts, which allows them to solve more complex problems without burning their brains out. I'd go as far as saying that the utility of a programming language is measured in its ability to compress code with abstractions. All this means you have to first understand the abstractive tooling and the abstraction itself before you can work with it, but this is how it should be. Most programming languages are tools, not toys.

The alternative would be to handicap all programming, make it impossible to solve complex problems with it for the sake of beginners, who want to get accolades without putting in work. You can't run an industry on participation trophies. By this line of thinking, we wouldn't have this conversation because inventing computers took work. Hell, none of us would have any conversation whatsoever, because language itself is something that takes years to learn.

Previously, I've developed open source software that got 5000-10000 downloads a day, and a few private commercial projects that pulled in a few thousand dollars a month.

A recent open source project on github has 8k stars.

Is that enough credentials to listen to what I say?

Maybe, with a skillset like that, you could just make the things better that you dont like, instead of what looks like "just complaining".

But today, I feel no real motivation to do so, because I know that if I tried to release this, the main response I would get would essentially be complaints that I shouldn't be changing things. I don't think any attempt to improve things would be accepted, because people refuse to believe there is anything wrong with what we have.

Like what?

I don't know of any developer that likes complexity for complexity sake for productive systems.

I know there are some esoteric programming languages or obfuscation techniques that make simple things more complex, but they a either meant as a challenge for fun or efforts to protect IP.

Do you have some examples where you have observed such design decisions?

But no, what I am talking about is all the tooling around the programming, which in turn relies on the massively archaic Unix command line.

You can get low-level and write assembly on a 6505. Or you can write python programs in Python. Or you can break out a terminal & node.js and a browser and build an entire website.

But you'll need to put in different amounts of time, effort, and research to achieve these different things.