The author is 100% correct on everything. Programming is massively over-complicated for no useful reason.
Programmers tend to get very proud of the completely pointless knowledge they have to acquire to use the pointlessly complicated tools they do, and they confuse that with being clever.
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.
Programming can and should be much, much more user friendly than it is now.
"Programming can and should be much, much more user friendly than it is now."
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!
The problem isn't the user-friendliness of the tools (many very friendly tools exist), it's the amount of energy the author is willing to invest (approximately none). When exposed to truly trivial tooling, the problem becomes a lack of practice in the type of thinking that leads to good programs. There we see that the core of the issue why programming isn't "easy" is that it's just not.
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.
> ... it's the amount of energy the author is willing to invest (approximately none). When exposed to truly trivial tooling, the problem becomes a lack of practice in the type of thinking that leads to good programs. There we see that the core of the issue why programming isn't "easy" is that it's just not.
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.
Perhaps this is a cultural difference then, efforts to make math 'natural' and 'easy' are not something my secondary education had. You could either do it or you could not and if you could not you were put in a class that had basically no math (or just some very simple math if you picked economics).
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.
There are tools that do what he wants but they are not node.js. That's the problem. The insistence on a specific tool and the desire that the entire world changes to accommodate you instead of just picking a different tool that does what you want.
It's by no means an IDE, but Chrome does have Workspaces: https://developers.google.com/web/tools/chrome-devtools/work... . In any case, I remember using this (or something similar that maybe I forgot?) when I was doing frontend work, it was quite neat, especially if you had a local server recompiling things as you made changes.
You say it like pointing out an obvious problem is hard to do. Programming is a very complicated activity, and of course it can be improved. Anything can be improved. There is no doubt about that.
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 write code for a company worth hundreds of millions every day, with a world-class user rating. I don't use the command line at all.
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.
You can just start up Eclipse or Visual Studio (the original) and have the exact same experience. That's how I started with Java and zero Linux knowledge.
What you are really complaining about is the fact that nobody is there to shout in your face that these options exist.
>Programmers tend to get very proud of the completely pointless knowledge they have to acquire to use the pointlessly complicated tools they do, and they confuse that with being clever.
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.
While it's a massive simplification of programming as a whole, I think you're at least partly right.
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.
Perhaps we're bad at allocating tools to use cases, particularly for education.
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.
Everything happens for some reason if we want to be pedantic.
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".
>I think the point was that some things do not justify their complexity. Especially if you discount inertia.
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
It's a trivial example, but a valid one. Those sorts of "it works great as long as you remember..." things are complexity, often unneeded. There are more severe examples of this involving frameworks with assumptions being too hardcoded (or softcoded!) as well.
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.
> The author is 100% correct on everything. Programming is massively over-complicated for no useful reason.
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
etc
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";
and then typing
perl test.pl naughtnice.lst
to run it. Python I assume is similar. I'm fairly sure that OSX comes with perl, python and bash if nothing else.
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
> Programming can and should be much, much more user friendly than it is now.
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.
> 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.
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.
But in the long run knowing all that makes it easier. We could have some GUI for doing all those things but it would end up being a massive mess of buttons EVERYWHERE and endless menus. And maybe a nice wizard could be designed for the given example that you could check the boxes as you go and it would be easy to figure out the first time. But after 5 years of doing this same thing do you want to spend 2 minutes clicking through a wizard every time or do you want to have spent a little time learning some cryptic commands a couple years back and now you can type it out in 20 seconds. Or better yet you made a script and it takes 1 second to run ./processAndInsertToDevDb
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.
> But in the long run knowing all that makes it easier. We could have some GUI for doing all those things but it would end up being a massive mess of buttons EVERYWHERE and endless menus.
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?
> 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
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!
Please explain how the command-line is pointless. If investing time into learning the ins and outs of a complicated system does not make you clever then please explain to me what does make someone clever?
"The command line" is not pointless. The current popular implementation of a command line, is, however, pointlessly complicated and esoteric for no real gain. It could be improved massively.
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"
To be honest the criteria for a beginner and someone who's used a tool for a while are different.
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.
Standard unix shells. They contain a massive amount of complexity and obfuscation that only exists because that's how it was always done and nobody dares change it any longer.
Like what? Please be specific or we can't have a meaningful discussion.
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.
One aspect of standard command line experience is that the various standard unix tools have different, incompatible "interfaces" (different switches for the same things, requiring multiple different memorizations) - the experience could be "unified" to a common standard and it would be better and simpler, without removing any actual functionality, but they can't be because that would break backwards compatibility and what people remember.
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).
fair, there are commandline tools by third parties that dont conform. From reading your other comments, though, I can tell that you likely don't enjoy learning complicated systems in order to leverage them for your advantage. Just like the author of the article, you complain on and on, without displaying any sort of passion for the good things this complexity brings.
That's a deeply unfair way of characterizing that. I love UNIX shell, but it is unquestionably true that it has a lot of cruft and could be a lot better designed. It's possible to both appreciate and enjoy learning complicated systems while recognizing that complexity is in and of itself a bad thing that should be reduced to the greatest possible extent.
All command line tools are by third parties. There is no first party.
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.
To put that another way: not all command-line applications follow the POSIX/GNU command-line conventions. [0][1][2] I agree that all new command-line applications should do so. It's annoying that Java uses java -version rather than java --version, and I can't see why they couldn't just add support for --version, as they wouldn't have to remove the existing -version.
> 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.
True, but in my experience it's not a great concern in practice. If you have to administer various different Unices then I could see this being a real pain-point, but GNU/Linux has taken over most of the world.
I feel like a lot of these are beyond the scope of the terminal. Like, we don't need a way to cat images — we have `xdg-open`, which will open an image file in the system's default image-viewing application. It'll open any file in its default application. Integrating images into the terminal requires doing away with the text-only abstraction, and in exchange for what? Something `xdg-open` gets for us already?
PowerShell is very close to what I think we need, but even PS is not quite cutting deeply enough. We need to rethink the command line rather than apply band-aids to an idiosyncratic model. Terminology is great, but it cannot solve the fundamental problems at the layers below that.
> Terminals of 2020 and beyond need to have first-class support for audio, video, images, and peripheral interactivity/customization.
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.
"We have X11 for this" just means "we can't do this, use a different environment".
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.
> we should not HAVE to use a different environment
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.
Do you have a specific gripe against X11? Again, it would be very much against the Unix philosophy to roll that highly complex functionality into the core SSH protocol. The problem would still be just as complex and challenging. Implementing a network-transparent GUI always is. You'd lose the separation of concerns, and you'd end up running two GUI systems rather than one.
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]
Agreed. There are so many annoyances like how you can’t use the standard shortcuts to copy and paste or how pasting text can insert a newline and run the command.
If we rebuilt the command line today it would be massively better
What do you mean by "current popular implementation of a command line"? The shell, common tools (e.g ls, cat, grep), command line interfaces for other programs?
yes, that should have been obvious. if you ever used them, you know they do not scale beyond the basics.
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).
The command line is a layer of abstraction that could be made unnecessary for programming. You could program in Turbo Pascal without a command line in the 90s
It's definitely GUIs, which is much easier to use for beginners (we're talking about beginners here, not people who have been using command lines exclusively for the last 20 years)
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.
And so they do, and so there are plenty of programming tools and environments aimed at beginners. But, just like you can't expect to make a proper dinner with your kid's toy-utensils, if you want to build nontrivial software, you need to learn suitable tools for that. And the command line the most basic of serious tools.
(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.)
In one statement you just revealed your age and experience level.
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.
>In one statement you just revealed your age and experience level.
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.
I disagree completely, and I'm starting to see now that you do not see the command line as programming, which is a fundamental flaw in how you're approaching your argument.
The command line _IS_ a programming language. If you do not want to learn it then you do not want to learn programming.
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.
Developing iOS apps isn't the be-all, end-all of programming. iOS itself is a consumption platform. It's garbage if you want to actually do anything (and so is Android), because the input bandwidth is severely limited. You don't need a command line on your phone, because there's hardly much you can do with it anyway.
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.
None of that is relevant. iOS is a fully-fledged OS, with at least as much complexity as anything else you'd be programming for.
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.
iOS has one of the most pathetic development toolings in existence.
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.
> The command line is a layer of abstraction that could be made unnecessary for programming.
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.
Sure, but you're entirely missing the point. Question is, is it necessary for programming? I repeat, to be entirely clear, is it necessary? Not useful, but necessary for a beginner to touch the command line?
> 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?
While I understand and recognize the frustration with programming today, I wonder if comments like these have any sort of factual basis to them. What exactly is over-complicated for no useful reason? And what are the ways to fix this? I haven't looked at every "coding for non-coders" app, but all I've seen fail in offering the same functionality as coding in itself does. How would the ideal way to programm look like where you have the same freedoms you have with todays languages, tools, frameworks, etc. while still being easy and intuitive to use?
Remember that for all the time spent trying to figure out these philosophical conundrums in our trade tech debt is still piling up and someone else is out there writing actual code/working... these are nice things to think about but don’t get hung up on them. Lots of this is subjective stuff that has no answer and the code isn’t going to write itself (not yet).
Try this tutorial [0]. It shows how to build a web component using JavaScript with just a text editor and browser. No Node, no $PATH, no build tools, no framework, and it's useful for any beginning web developer. Happy to improve it with any suggestions, as I want to make web development easier for beginners.
Well, here's an example: You can develop a fully featured, world-class iOS app, and distribute it, without even touching a command line. Nothing in the process would get easier by touching a command line. You just don't need it. There is a fully-featured environment that provides all the tooling you need without it.
And do you have any proof of that? Because in my humble opinion, the command line is great solely because keyboard is (up to now) the best input device we have invented. Any graphical tool requires eye-hand coordination, which slows things down considerably. Using keyboard you basically only depend on your muscle memory and can input commands to the machine way more quickly.
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.
The proof is that I develop for iOS, and I do not need to use the command line at all for this. Using it does not make anything easier and more efficient. It live this every day.
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.
You repeat the previous content without any example on how they are better. To you it seems that not having to use command line is an advantage. To me it's not, making your argument moot.
I am saying that if I were to use the command line, things would not be easier for me. Thus, the GUI tools I have are superior to the command line.
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.
That solely depends on your use case. There are three reasons to use command line and none of them has anything to do with being easier:
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.
I am well aware. And I am saying that none of those are easier than the GUI tools provided in this case.
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.
> I am well aware. And I am saying that none of those are easier than the GUI tools provided in this case.
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.
I think the currently popular cli, the old unix-based one, is esoteric, annoying, and still useful.
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 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)
You see that absolutely in every "new". Programming language. It starts simple, beautiful, easy to read and understand.
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)
> And 10 years later: people want ways to write a ten liner, in one line compressed.
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.
Too many to list. Currently working as a senior programmer for the user-facing client for a company worth hundreds of millions, with an app store rating of 4.9.
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?
It's enough credentials to make your criticisms worth thinking about. It's fascinating how, in a few years, I got so familiar with the commandline and never felt like it was too complicated (although I do almost everything through it), both at work and privately.
Maybe, with a skillset like that, you could just make the things better that you dont like, instead of what looks like "just complaining".
I have in the past implemented my own shell to work around some of the limitations the usual one had.
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.
>Programmers tend to get very proud of the completely pointless knowledge they have to acquire to use the pointlessly complicated tools they do, and they confuse that with being clever.
> The author is 100% correct on everything. Programming is massively over-complicated for no useful reason.
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?
I like to nominate frameworks for the complication category. People say they don't want to reinvent the wheel, but what they really mean is that they want to have the training wheel on.
I am not sure how true this is. There have been numerous attempts at visual programming and they have generally turned out to be crap. Because syntax is actually a relativity small part of the problem.
It has nothing to do with visual programming. Which, by the way, is in massive, wide-scale use today. Game engines tend to use it, audio processing software uses it, and scientific control software also use them.
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.
There have been some general purpose visual programming environments which have had some degree of uptake. Prograph is one (http://www.andescotia.com/products/marten/) - it is certainly niche but apparently there are users.
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.
Programmers tend to get very proud of the completely pointless knowledge they have to acquire to use the pointlessly complicated tools they do, and they confuse that with being clever.
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.
Programming can and should be much, much more user friendly than it is now.