Indignation commonly gets a lot of upvotes but it's not what we're looking for here.
What value does this article even add? It's a google query with a rant attached to it.
You started a 200+ comment value-subtracting subthread so the 'should have stuck to the guidelines' argument seems extra-solid here.
And for a different reason: I find that programmers who think like this, are also lazy when it comes to respecting the user. They're lazy when it comes to supporting accessibility. They're lazy when it somes to properly supporting i18n and making experience great for non-Americans. They're lazy when it comes to respecting privacy and not burning 8GB of RAM just to render a webshop frontend.
They'll say "this is hard" and add Facebook SDK to do things for them. They'll say "this is hard" and make the page inaccessible for people that don't own a 4000$ 16" MBP and has perfect vision.
That's the core issue of this attitude for me, which I'm seeing by too many people I mentor. Development is sometimes hard and requires hard work to do right by people.
I disagree, actually. There are plenty of languages, and even visual programming (via flow-diagrams, like Unreal Engine's "Blueprint" and Blender's shader flow diagrams), for those who just want to play around. For people who want to write a quick and dirty script, languages like python make it very easy already (relative to what they actually do).
> Programming COULD use [...] removal of barriers
Absolutely agree with this, though. There's an unnecessary elitism in many places that really needs to go..
> Development is sometimes hard and requires hard work to do right by people.
This is *so* important for these people to understand. There are languages and domains where the "elitism" is fully justified. If someone decides they want to write a high performance, easy to use, cross platform native application and complain about C++ or Rust being too complicated, then they should find an easier job. There is justified and unjustified elitism, and there are domains which could use, if anything, even more "complication" and more specifications, more "barriers" to ensure higher quality.
Flash was terrible for all sorts of other reasons. But it did demonstrate that there is a class of incredibly creative people out there who can create amazing things, but not on the command line, and not using the tools currently available.
How do we get them doing that again?
I'm serious. I don't think there can be another "explosion of creativity" of the (relative) magnitude of Flash, because people now express themselves by recording videos. It's both easier and more social than making interactive software, even with Flash.
?? What kind of bizarre red-pill nonsense is this? You think all those interactive Flash microsites were to impress girls? lol
I disagree. I follow a lot of game developers and you'd be hard pressed to say they don't do high-performance corss-platform native application development. They almost universally think C++ (and by extension Rust) are too complicated. They generally use C++ anyway because that's the industry standard, but they think there is definitely a conceptually less-complicated way to do things.
See: Jonathan Blow and Casey Muratori, for instance. The former is so sick of C++ he's making his own programming language, and the latter routinely complains about C++'s complexity and eschews all but the simplest features of it.
C++'s complexity is also a product of design choices like using templates to do both generics and metaprogramming, which in hindsight probably made things much harder than they needed to be. Rust has the benefit of being able to avoid decades of C++'s missteps.
However, I do know that a lot of objections to it from the people I follow are around the borrow checker and both the friction and high[0] compile times it causes.
[0] to put that in context, Jon is frequently annoyed by the sub-second linking time incurred by LLVM because it is more than an order of magnitude longer than his largest program (~60k line game, IIRC) takes to compile.
What makes it worse is that complication doesn't even exist for "good" technological reasons; it only exists for inertial, industrial reasons like compatibility with C and 1980s naivete -- both because of and in spite of it, since, like the other person said, even more complexity was bolted on to try to force new lessons without breaking backwards compatibility.
I used to love C++, since I thought its complexity was somehow, fundamentally necessary for a lang to be a "fancier C". Once I learned Rust and found out that was not true, I now hate C++ with a passion and can't wait until it completely displaces C++, which it should do ASAP[0]. :D
THAT SAID, some people (who are much better programmers than I am), say that C++ is the most expressively versatile language around, which is at least a "good" technological reason for its enduring existence. That's one I can't relate to, though, since the people who are saying that tend to be talking about very advanced, byzantine aspects of C++ that I never got to.
This has happened pretty regularly for decades at this point, people hate on c++ and think they have the silver bullet approach to do things better. They spend a few years on it, and it fails to get much traction.
There is a network effect around c++, sure. But industry standards are there for reasons, and usually most of them have a core at least that is sensible. People keep coming back to c++ mostly because it works, and it turns out often if you start with a safer and cleaner language you get 80% of the way there much faster, but a lot of the 20% that's left over is performance related and you just can't get there no matter how hard you try.
So from a business point of view, the pain level of c++ (and associated costs) is somewhat known, but most other approaches trade that off against project risks people just aren't willing to take.
It's not inherently crazy, even in 2021 to start a new high performance project in c++. Obviously the exact requirements matter, but there is a subset of what it can do that we don't really have a obviously good replacement for. What would be crazy is starting a new project in it that doesn't really need any of thee things it's good at.
Graphical programming languages, removing barriers to learning, etc. They've been chugging away for decades and visual programming, Blender, Blueprints, Scratch, etc are all we got out of it.
Does the article writer just think research doesn't exist? That CS sprouted from existence fully formed as a web browsing experience?
More like 50 years. :)
I'm not sure I want to code like that, but damn is it impressive.
Blueprints and Scratch are widely used and are important tools. Your comment sounds very dismissive, and if you meant to be, then I think you’re unaware of their impact and reach.
That said I don’t fully buy the author’s exact argument:
- node.js local install IS for a traditional programming environment on the CLI - you don’t need node built in when you have the browser - plenty of web IDEs exist that do as the author wishes… run node code in the browser while also editing it.
If you really hate `git checkout -b`, ship `git make-branch` that suits your taste. You can even package it as a trivial script to redistribute if you wanted.
Programmers do things by writing code, compiling, deploying, etc... so the notion of customizing an app through anything that looks like their workflow seems fine to them.
OTOH I write code for a living and I often hate the tools we use...
I so completely disagree. Writing JavaScript is already so simple that almost nobody knows how to do it any more. You can download a colossal framework and a billion NPM packages to write some completely unoriginal CRUD application and bitch about how hard life is. Fearing writing original code is the name of the game.
The reason for this seems more that there a many coders that forget about the task of vetting their dependencies, which is a big part of programming.
Just learning a language does not give you the discipline required to be a good software engineer.
The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
There is a worse toxicity in my opinion: when engineers at all levels religiously adhere to fads or practices just because others do (see: OO, TDD, etc.)
If not, where do you draw the line? Should you write your own business logic? Should you write your own logic to allow implementing that business logic (e.g. request parsing, validators, data transformations and processing etc.)? Or maybe you should write your own web framework that routes and handles HTTP(S) requests? Or maybe the entire ORM (if you're using one in the first place) as well? But that ORM probably uses JDBC/ODBC or some other driver as well, and the HTTP(S) requests also can be processed because of some additional code and libraries. Should you write those as well? What about the operating system itself, and the code that allows it to interface with the hardware? What about the kernel?
I don't necessarily agree with the OP's point about making a browser that has Node.js packaged (though it's a novel idea), but i definitely agree that defaults and tools matter. Tools like XAMPP ( https://www.apachefriends.org/index.html ) or the CLIs for automatically generating projects and helping automate everything from creating project files, like in Ruby on Rails Generators ( https://guides.rubyonrails.org/generators.html ) or entire apps, like with JHipster ( https://www.jhipster.tech/ ) or create-react-app ( https://reactjs.org/docs/create-a-new-react-app.html ) all seem to decrease the chance of human error and make development safer, more consistent and easier. Even IDEs that are aware of the specifics of the frameworks you're using can be very useful!
In addition, they can improve the developer experience (DX) a whole bunch, since in larger projects time can be invested to address common problems. For example, see Dylan Beattie's conference talk on the topic: https://youtu.be/lFRKrHE8oPo?t=431
I've seen people trying to write their own web frameworks and most of the time the results have been poor, both in understanding the system and maintaining it in the long term, in addition to which you can't hire people that are familiar with "Random Company's Web Framework". Unoriginality is good for being to maintain the project, as far as i'm concerned.
Here's another conference talk, by Venkat Subramaniam about deciding between using existing code or writing your own: https://youtu.be/OheeK7Ux2-8?t=727
One big task about programming is handling dependencies and thinking about assumptions. Before even beginning to write any code, you have to think about these things:
- What environment do I expect the end user uses? Are there already some libraries I can use as well installed?
- Do I need a GUI, or should it also run on headless devices? TUI or just CLI?
- Does it make sense to use a big comprehensive framework or rather a bundle of minimal components?
- Does a specific feature really need an additional dependency or can I rather implement something on top of the already existing dependencies?
- How good is the maintenance of a library, code quality and is the license compatible?
- and many more...
Lazy people might just add any dependency some stackoverflow or other random search result says, without thinking about these. While good developers think about each one and try to find a minimal set of them.
> While good developers think about each one and try to find a minimal set of them.
(tl;dr at the bottom, things up to "In short, " are merely my experience, which is entirely subjective)
For example, suppose that i'm working on a Java project and i want to do some non-trivial operations with the filesystem. In this instance, my options for implementing the functionality would be as follows:
1. Attempt to do it myself by using the standard library
2. Attempt to find a really specific library that allows me to do what i need
3. Attempt to use one of the larger libraries out there, that provide a variety of related functionality, which may or may not be useful
1. Attempt to do it myself by using the standard library
+ Will be easily customizable, because no source/recompilation will be necessary for an external library (though mostly a problem of the toolchain and approaches to including libraries).
+ Will result in a small distribution size, since there won't be redundant code included.
- The code mostly won't have good test coverage, since i cannot spare the time because of business/bosses needig functionality ASAP. Neither will i be able to address the technical debt that might arise from this solution, or throw out a sub-optimal solution and rewrite it until i get it right. Ideally this wouldn't be a problem, but i'm afraid that this is usually the case.
- The documentation will be sub-par, since code itself doesn't provide many mechanisms for showing examples on how to use it (as opposed to a Wiki/sandbox), even in the case of "self-documenting code", non-trivial concepts will still require code comments, which will also need to be kept up to date by someone who'll need to edit the code. Onboarding will be more difficult, because initially noone will be familiar with the solution.
- Time spent creating bespoke solutions will prevent me from implementing other solutions and addressing other concerns with the limited time i have. In addition, bugs could arise, since i'd miss certain aspects that people who are more proficient in working with IO would notice and address.
+ Will result in a small distribution size, since there won't be too much redundant code included.
- More often than not, minimal dependencies can result in many of the above problems (especially problematic with documentation, since i wouldn't even have had written the code in the first place).
- In addition, minimalistic solutions often have relatively few contributors, which can result in them becoming abandoned some time down the road. Maybe not too important for small libraries that can be rewritten, but eventually you'll end up with unmaintained dependencies which will need addressing.
+ Will usually be actively maintained (for example, https://github.com/apache/commons-io has 70 contributors and 360k users).
+ Will usually also have reasonable test coverage (the library above has 89%, according to GitHub)
+ Will usually have a rather good documentation that's updated by others (sometimes in the form of a separate website, like https://commons.apache.org/proper/commons-io/)
+ Can easily be Googled with plenty of common problems (some of which are almost inevitable) addressed. This will also help others, who need to work with said code.
+ Maintenance and technical debt won't need to be addressed in house. Oftentimes it'll be as easy as bumping up the version number and running the tests surrounding the integration (if any exist).
- Will probably include lots of bloat, which may or may not have a significant impact on the bundle size of your project.
- Will most likely increase the attack surface of your project in some way.
- Will also be difficult to audit and really get to know in entirety (if not impossible).
There was actually a rather humorous presentation a while back and while the best video i can find of it is still in pretty bad quality: https://youtu.be/AUYPnxv0yss (couldn't find the exact timestamp) one of the things that stuck to me was the suggestion that you should use whatever language/tool/framework that your friends/colleagues use, if possible. Essentially - use boring technology, that will be easy to reason about and that will help you more often than not.
> In short, i don't think that how "minimal" dependencies are should be the deciding factor when choosing them, but rather the results of deliberation of the points that you've described above.
Well I said 'minimal set of dependencies' not 'minimal dependencies'. My text wasn't meant to make a point for small libraries or for implementing everything inside the project, but just to point out the important factor of dependency management as part of programming, which I felt was missing in this discussion.
Of course if there is some big framework that is well maintained, possible already used by other software components that might be already available on the device of the end user, fulfills all business/project requirements and you might end up using it for more the just one function, then great! That also means you might not add many other random small dependencies to dependency set, now or in the future and that set might stay minimal.
But if there is something that is not part of the big framework, and easy to get wrong, then of course you should add some dependency that does it for you under all these deliberations instead of trying, and possible failing, to do it yourself.
You should however step back from this and reconsider, if you start adding libraries for just string padding and the like.
TFA is a classic x-y problem. Author says they want node in the browser. What they really want is something they can quickly be productive in, a one stop shop. Author is describing an IDE.
Many problems don't go away and don't become easier just beacuse you shove them under the carpet into a library. A lot of developers use libraries as an excuse to NOT THINK about the issues and ignore their existence not to save work. There's a fundamental difference between "I understand the problem and I know that library X will give me a good solution with low amount of work" and "This problem is hard, I'll shovel in another library and keep my fingers crossed that it does a good job at it."
It's saving work vs. saving thinking. First one is ok. Second one is not.
This, I think, is more intended for people who are not really programmers, but would like to write a bit of logic, and find themselves with tools intended for professionals.
Because I am an experienced programmer now, I may be biased but I have a feeling we raised the barrier to entry for programming. The author mentions Excel, that still exists and us used all over the world by non-programmers to write terrible macros. But I am also thinking about Visual Basic, a lot of stuff by Borland (thinking about Delphi). DOS even shipped with Basic IDE.
As a general rule, I consider all "don't be lazy" arguments wrong. Machines are meant to work for us, not the other way around. The only ones who shouldn't be lazy are those who write the tools, so that users can be if they want to.
What is special about programming that should be easy where playing the piano or learning to draw well is not? Maybe it's just fundamentally hard?
I'm not suggesting it can't be made more approachable for beginners and for small tasks but most non-trivial things someone wants to make, they have 1000s of questions that need to be answered and even more combinations. Making the tools better, for the most part, won't remove that complexity IMO.
Take the stereotypical "To Do" starter app. First you just have an array (db) of todos and they have title, text, done fields, and that's it. Then you add due dates, dependent tasks, assigning ownership for tasks, oh, you just made it multi-user, you now need login, ownership, editing rights, migrations when someone quits. You probably have user settings, machine local settings, user account setting, People want different displays of the data, sorted different ways, or with graphs. They need formatting for printing. You want notifications when a task gets reassigned but you don't want them notified on every device. Oh, suddenly you have users in foreign office, they need it localized., etc.. It gets extremely complicated very quickly.
I think this is not exactly the same. Tom is I want to X, but I don't want to learn Y. Consider
> I want music at my party but I don't want to learn the piano
Easy, just put on spotify
> I want to compose, but I don't want to learn the piano
Well there are many evolving tools for doing that without needing to learn the piano, such as sibelius.
> I want an app to do X but I don't want to learn how
Just hire someone to make it for you
I don't agree nor disagree, but I just wanted to point out the hypocrisy of this argument:
If someone is too lazy to learn how something works, would it not be hypocritical for them to complain about the laziness of other people, that fail to make it easier for them?
And if this lazy person writes their own stuff, would they be diligent enough to make it easier for others?
It would be something different if that person was actually not lazy and, after understanding something, could point out or help implement ways to make the introduction for the next person easier.
You can't install npm packages. There's no simple UI to alter DOM like via drag and drop. Theres's no pre-built components (besides html) to easily create more advanced functionality. They have to write JS from scratch to add events. Managing more than 1 liners is a pain.
Yes, and I'll be honest and say that I missed that to begin with. The author is also not a developer, which is why he is mistaken on a number of specifics. I think concentrating on those specifics miss the point of what he's trying to relate.
I think the barrier to start coding is incredibly low at the moment though. There are so many learning resources and even websites that provide a full stack including a web based ide. The barrier to doing it completely on your own hardware may be slightly higher than it used to be because everything requires so much customizability that it ends up being difficult to operate. Of course there are simpler option out there but they don't get as much press as the more capable tools.
I don't think he solved the crux of his excel problem though: excel provides an easy way of coding, providing the input for the code, and presenting the results in productive manner. Most environments make this fairly painful for the beginner, requiring you to parse text files or similar. This allows beginner excel users to be productive quickly. Of course, baking node into the browser isn't going to solve that.
I can only imagine how much faster I'd have gotten my start if I could have used the browser itself. And the inspector console is useless until you can type your code perfectly on the first try (or second if you happen upon the up-arrow/edit functionality).
So after I began my dev career I began volunteering at a free local library coding session. It was part-babysitting, but there were a handful of kids who usually had part-time access to a parent's budget Windows laptop.
A basic coding environment inside Chrome or Edge (vscode lite?) would have made those sessions so much more productive. And I'd have been confident that no matter what computer they ended up on later, they'd wouldn't have to do any magic incantations to get back to coding.
Even giving them a bookmark to one of the all-in-one dev env websites isn't enough. It needs to be able to run locally without internet. And those coding websites over the past few years have been changing so rapidly in interface and setup that it would easily throw someone for a loop who was just beginning.
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.
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]
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.
> Here’s my pitch: build a browser that comes pre-installed with node.js
Okay, you don't have to know anything about JS or V8 or Node to live a normal life; most people don't and they're fine. But if you're going to complain that you can't "code in the browser" you should try to understand what you're talking about a little more.
This sounds like an elaborate prank.
Epigram 93, Alan Perlis
I like Prolog because it is that language. Other languages you have to write a program telling the machine what to do every step of the way. (Except if the program uses neural nets.)
We, as software industry at large, however should work on two fronts:
- Try to make things, which can be simple simple. Many do that out of self interest, but sometimes one is so used to complexitiest, that one doesn't see them anymore and we often fear redoing grown things as "it works" and we might break use cases and we don't want to relearn things ...
- There is a large room for enabling non-programmers to build tools. In the past™ people built fancy tools on top of dbase, delphi, access, excel (world runs on excel ...) etc. without being programmers. There is an easy start allowing a domain expert to build a tool in their office faster than explaining the problem to the IT department. The solutions weren't nice from an Software Engineering view, but solved problems. This we have to enable with modern technologies instead of access conflicts to an excel file on a windows share ...
> Simple things should be simple. Complex things should be possible.
[1]: https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad...
It is, though. It really is.
He's some kind of self-anointed "thought leader" and "consultant". Because, honestly, of course he is.
Just for context: he'a talking about installing ruby/npm/node here, not about coding. Not about visual coding!
The next line makes it obvious:
> Can you imagine if the beginner version of Node.js came pre-installed with a GUI for managing and running your code?
I feel like I almost have that in jetbrains tools. I can browse through composer packages, discover package names, and select specific versions. Not quite the same, but was a pleasant surprise to accidentally discover recently (but... it's still just wrapping CLI stuff, AFAICT).
There's nothing wrong with not being good at something.
Does make me think programming can be radically different and maybe a lot easier
What I'd like to see is how it handles any kind of more complicated tasks - e.g. one where you need to build two or three layers of abstraction. Or one where you build domain objects that are used by other tasks. Or even one that showcases error handling.
You can get something similar, minus the fancy NLP processor, in Unreal Engine, via its Blueprints feature. Suffice it to say, there's a reason people end up learning and switching to C++ the moment their problem starts to involve any kind of complex logic.
Note: I'm not against improvements in programming experience, and more visual and interactive paradigms. But I've also played with enough dataflow languages to fully internalize that there is irreducible complexity in programming (that comes from it being an art of micromanaging possible states), and it's painfully hard to work with it in a flowchart form.
I don't know about that. The author is certainly confusing programming with setting up a development environment. I can understand why they would be frustrated with the latter, since it takes away with what they are trying to do.
When I started out, the latter was fairly simplistic: computers booted into BASIC. If you needed something more sophisticated, you could buy an IDE where everything would run right off the boot disk or after an automated installation. You can still find those tools, designed to serve everyone from home users to professional developers. That being said, it seems to be much less common.
In some cases, like web development, that makes sense. The target is a standard rather than an operating system or hardware architecture. In other cases it is self-inflicted. When you choose to work with third party libraries, there is a much higher probability that some work will need to be done to integrate it. Then there is the WTF category.
Take one of the easier cases: Java. Even though the development model is much closer to traditional languages like C++, the most common use case will involve installing an IDE and the language separately (possibly with some tweaking of the environment). That's not too bad, but it's likely more than people want to see when they want to get their tools up and running. Contrast that to C++ on a commercial operating system: you install Visual Studio or Xcode and are ready to focus upon programming for the chosen platform.
Of course, C++ isn't always like that and it comes close to representing the other extreme. Setting up development tools for microcontrollers can be quite the task, particularly if you choose the "wrong" one. That's a good part of the reason why novices like Arduino and Platform IO, it makes going from nothing to a functional IDE fairly straightforward.
Now I'm not going to say that the author is right, but I will admit that they have a point. Presenting Unix-isms in a macOS installer is going to rub some people the wrong way. That should have been addressed in a better manner. On the other hand, they were also attempting to accomplish something that is non-trivial to start with.
The author is very right to point out the fact that the browser in 2020 is still so fundamentally broken.
Theoretically, tons of work should be facilitated in the cloud without having to download or setup a single thing.
You should be able to make fixes, test etc. in github without having to download the code and toolchain as easy as you would on your desktop.
Even the 'local' version of software development is a giant mess, we have not well thought out dependencies, tool chains etc..
>Because I love building things using code.
I mean, someone who "builds things using code" should be able to install ruby. I've never even attempted to use ruby, don't even know what its syntax looks like, but I guarantee you it can be installed by something akin to
$ apt install ruby
(Ubuntu 18.04, maybe it just came with this distro?)
I would guess that almost everyone who has ever learned programming has gone through this experience, been frustrated, and understood in the moment that this was bad UX that could be improved for learners. As such, your attitude, and lack of empathy, seems like gate-keeping to me.
You have been treated poorly and accepted it, so other people must be treated poorly and accept it, in order to prove themselves. This only perpetuates bad practices.
I would say that you are the lazy one, in not wanting to support other people in their programming journeys.
There is only one word for someone, who approaches a topic they know little about, and suggests that its rubbish and he knows better.
That word is 'arrogant'.
And you are correct, I have no sympathy for arrogant people.
I think as a set of musings it's totally valid: there really is a ton of yak-shaving that still stands between "coders" and "non-coders" which actually has very little to do with code itself. It's a good exercise to brainstorm which speedbumps are unnecessary and what we could do to remove them.
But there is a balance to be spoken of here between laziness and learning. Laziness, in a way, is a driver of efficiency. You want to do something in a way that requires less effort.
It is learning, though, that gives you the tools you need to be "lazy" (if we agree on reading "lazy" as a desire to do less, as opposed to a desire to not doing anything at all - there could be debate here). In turn, finding a way to do less work takes work itself.
I guess what I'm trying to say is that these complaints could hold some validity, it's just a shame that the author doesn't seem like the type to do anything about it.
This is the exact type of behavior thats unwelcoming in this industry.
You don't have to type to write programs. Many people don't. It's why applications that do visual programming have opened the way for AMAZING bursts of creativity.
Everyone should be able to communicate with a computer. The more people that are the more likely it is were going to make fascinating things.
Your elitism in programming is showing. And it's not welcome.
Do you ever see ads for 'become a doctor in 6 weeks, land a job'? Or plumber? Or electrician? Or anything else? No, but you do for programming.
Do you ever see people whining that being a medical doctor is too hard and confusing, and demand that everyone should just have a handheld with webmd?
Programming as a field requires many years to really understand. And even when you understand, it's just some niche, not -everything-. Nobody knows everything. And that's not completely dissimilar from other trades/professions.
I'm not trying to gatekeep here. I encourage everyone to learn to program, -if- they take the time to learn. If they don't, they do not belong doing it as a profession for others. Just as people can toy around with wood in their garage, so long as they don't call themselves a professional carpenter. That's how you end up with glaring security and privacy problems that we read about nearly daily. Imagine if anyone could call themselves a doctor, and constantly read stories of people dying from horribly botched practices.
I think the only real solution here is for the profession to be certified somehow, as other countries do.
No one is denying that you're not going to be the best developer in a few days. But I welcome everyone learning the way they want to and how they want to, and for others in the industry helping them learn.
And for your example, I'd much rather hire someone who has worked in their garage with wood for a decade than someone who just got a certification to call themselves a professional carpenter right out of trade school.
And yes, you are literally trying to gatekeep because you're realizing the thing you've spent thousands of hours learning is actually not that difficult and is getting easier and easier every day.
https://www.youtube.com/watch?t=167&v=8pTEmbeENF4
"There can be a lot of resistance to new ways of working that require you to unlearn what you've already learned and think in new ways. ... And there can even be outright hostility."
Programming Baduk used to involve expert systems. Now convolutional neural networks (CNNs) can hoist a computer to superhuman performance, even doing so without pre-programmed rules (see MuZero). We no longer "program" computers to play Go, chess, shogi, or even Atari games.
Some people have difficulty keeping code structures in their mind's eye. Here's a conceptual development environment for navigating code visually, ending with a dual text editor:
https://www.youtube.com/watch?v=u3QqjhzhnAw
Is that programming?
What's the difference between _typing_ instructions into a computer to place a graphical user interface widget on a screen and _telling_ the computer you'd like to put a toroid on the screen? Computers can use CNNs to fill in knowledge gaps. Even though the computer wasn't told the colour, size, shading, material, or location of the toroid, it can still show us the ring.
Is telling a holodeck that you'd like to replay a scene from a novel a form of programming?
https://www.youtube.com/watch?v=d7dfsLfWJvc
Each evolutionary step in programming has given us more powerful ways to express ideas in ever terser forms. Few people code in binary anymore. Did Picard need to tell the computer where to put every chair, table, glass, and machine gun?
What is programming?
I think the person is trolling.
What he's looking for is basically Anaconda for python or MatLab; Environments that are already pre-configured with packages so you can import whatever you want and start coding. But that's less clickbaity.
However, there are times when I’d like to do it all in the browser too, preferably on a tablet or small laptop.
I won’t be at my most productive, but I’ll likely be sitting in my backyard or in a park.
Why I am questioning you is that You cannot call the author lazy. Just because one post gives you that opinion, doesn't mean he is a lazy person.
The author gave a fresh opinion about web browsers and shared it with everyone. appreciate that.
Problem - Browsers dont allow us to write code/ Solution - create browser extension / use console.
Thinkers talk, doers do.
>The author gave a fresh opinion about web browsers and shared it with everyone. appreciate that.
The author gave a stale opinion that can be answered by typing his post title into google and hitting enter.
LoL they dont know tab completion exist.
Discoverability & Learning curve is a point in favor of GUIs. But having to press more keys (offset by not having to use mouse & fight with shitty new designs) is not.
The author is lazy, and is channeling his energy into complaining rather than learning. He believes he is by default an expert on the 'user friendliness' of programming.
His comments don't really make much sense, and come across as whining that should be ignored.
"People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. "
You have to type to write programs. I truly believe that this person has had a conversation with friends about how programs should write themselves by you just telling them vaguely what problem you'd like to solve. And unhelpful error messages? You know what would be an unhelpful error message? 'ls' outputting a commandline tutorial every time I mistype a directory name so that people like this can have his hand held and continue to be intellectually lazy.
I have no patience any more for lazy know it alls in regards to programming.