Why can't I write code inside my browser?(tomcritchlow.com)
tomcritchlow.com
Why can't I write code inside my browser?
https://tomcritchlow.com/2021/01/14/new-browsers/
606 comments
There's still plenty of awesome things you can do in IT without ever touching code
I spend a lot of my day working in a 'no code' visual programming environment and the difference between the solutions created by the people who know how to program and those who don't know how to program is massive. Those who don't know how to program tend to fail at coming up with non-trivial solutions and are not really able to debug the 'code' when it fails. They also always come up with the most 'brute force' solutions and can't really reason around performance.
I spend a lot of my day working in a 'no code' visual programming environment and the difference between the solutions created by the people who know how to program and those who don't know how to program is massive. Those who don't know how to program tend to fail at coming up with non-trivial solutions and are not really able to debug the 'code' when it fails. They also always come up with the most 'brute force' solutions and can't really reason around performance.
Yup. That's because programming isn't just learning the vernacular. It's, first and foremost, learning to express concepts in a structured, super-precise way; learning to evolve systems in your head step by step, according to a set of arbitrary rules; learning the nature of computation.
Familiarity with this type of thinking is visible not just in computer-related endeavors, but often in everyday life matters as well.
Familiarity with this type of thinking is visible not just in computer-related endeavors, but often in everyday life matters as well.
IMHO, before all that, programming is admitting before yourself that you are very often wrong (either when coming up with a usable mental model or when applying that mental model or when observing the unforeseen effects).
It's the first leap and as you make it you can manage the emotions and the growth will happen.
It's the first leap and as you make it you can manage the emotions and the growth will happen.
We gotta keep beating this drum though. You get people saying programming is just learning Node.Js or learning X or learning Y, and you end up with bootcamps and no computer science. Just reading this thread has been a true journey.
Reading this thread was extremely frustrating for me as I have this idea in my head that everyone on HN is a seasoned software engineer. But obviously that’s not true, which is a good thing! And I certainly shouldn’t be frustrated at other people’s perspectives, it’s making me think about complexity a little more.
I think there’s a lot of misunderstanding of complexity by newcomers of programming. A lot of people are pointing to the current state of the Unix command line as an example of being overly complex and bad. And certainly you could point to this or that command line tool and say that could be better designed and you’d probably be right. But all the command line tools we are familiar with weren’t designed in one go, they grew over time to fill needs. It could not have been done in one go, the different needs of different users and the overlap and disconnect is too great to know all beforehand. And the same thing would happen if we started from scratch today. We would design something we think is great and multipurpose only to realize it doesn’t quite fit this new requirement so we will have to add an edge case. Maybe we could do better than the current standard, but it won’t be perfect, there will always be corner cases and competing requirements.
I think there’s a lot of misunderstanding of complexity by newcomers of programming. A lot of people are pointing to the current state of the Unix command line as an example of being overly complex and bad. And certainly you could point to this or that command line tool and say that could be better designed and you’d probably be right. But all the command line tools we are familiar with weren’t designed in one go, they grew over time to fill needs. It could not have been done in one go, the different needs of different users and the overlap and disconnect is too great to know all beforehand. And the same thing would happen if we started from scratch today. We would design something we think is great and multipurpose only to realize it doesn’t quite fit this new requirement so we will have to add an edge case. Maybe we could do better than the current standard, but it won’t be perfect, there will always be corner cases and competing requirements.
For some people, bootcamps could be the right entry point. I started by building websites in a wysiwyg editor :)
> They also always come up with the most 'brute force' solutions and can't really reason around performance.
Neither can most programmers if modern software is anything to judge by.
Neither can most programmers if modern software is anything to judge by.
This is a variant of the no-code mindset where people expect coding to be easy.
What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.
When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.
I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.
The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.
In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.
What they don't understand is that tools which aim to make coding easy or automatic don't add any value if the person using the tool doesn't understand all the nuances in the underlying logic which is being produced. Fully understanding the distinction between client and server is one such nuance.
When it comes to coding, the bottleneck is essentially never the tool, it's almost always the person.
I don't think I've ever met anyone who was naturally good at thinking logically. Working close to the hardware and then working your way up the stack is one of the best ways to develop the required level of nuanced logical thinking.
The problem with no-code, low-code or tools which try to move away from the underlying reality is that they don't train your logical thinking skills.
In my view, tools should help people develop into better programmers, not give an illusion of ease and mastery when it is not deserved.
> I don't think I've ever met anyone who was naturally good at thinking logically
I've heard, though, that declarative programming (prolog, haskell etc) was a LOT easier for people who aren't trained in imperative programming. Whereas those who are actually have a hard time picking it up... As was my experience.
@op have a look for declarative programming. You might like prolog :)
I've heard, though, that declarative programming (prolog, haskell etc) was a LOT easier for people who aren't trained in imperative programming. Whereas those who are actually have a hard time picking it up... As was my experience.
@op have a look for declarative programming. You might like prolog :)
I'm someone who learned declarative after imperative. In my experience, there are two things to understand about any declarative language: what it expresses, and what it actually does on the machine. The latter is often considered an implementation detail, but - at least for the people with imperative programming experience - it's actually crucial to gaining full understanding.
I remember my final breakthrough in grokking Prolog was realizing that the engine hides a glorified DFS that walks a graph of concepts for you. Suddenly, all the reasoning and non-deterministic features wasn't mysterious anymore, and performance-related implications became clear. Similarly, for people who struggle with async, it's beneficial to understand that async means somebody hid an event loop from you.
I remember my final breakthrough in grokking Prolog was realizing that the engine hides a glorified DFS that walks a graph of concepts for you. Suddenly, all the reasoning and non-deterministic features wasn't mysterious anymore, and performance-related implications became clear. Similarly, for people who struggle with async, it's beneficial to understand that async means somebody hid an event loop from you.
Both Prolog and Haskell make memory management really hard, and without good memory management you can’t reason about the run time of software.
Of course the solution is to learn a lot on the low level details of the compilers for these languages, at which point it’s not easier than imperative coding.
Of course the solution is to learn a lot on the low level details of the compilers for these languages, at which point it’s not easier than imperative coding.
Doubt it. To do anything beyond basic stuff in Prolog you need to understand its resolution algorithm. And it is not enough to understand 'what' it does but also the 'how' which is basically a backtracking algorithm.
My main problem with declarative/functional programming languages is that they force developers to separate the logic from the state (they are not co-located based on concerns) and this often causes developers to neglect the separation of concerns principle altogether; which is by far the most important principle in my experience.
Most developers never learned proper blackboxing/state encapsulation.
It's impossible to create truly modular code without colocating related logic and state.
Most developers never learned proper blackboxing/state encapsulation.
It's impossible to create truly modular code without colocating related logic and state.
Yes! Being able to hide state is a blessing but sometimes also a curse.
However Monads kind of allow you to hide/abstract over state too. I find it way more difficult though.
> But just like it's hard to become a good musician if you shy away from sheet music, programming is hard if you shy away from command line and a little web searching to know what $PATH is.
I like this analogy a lot. You can't just write code and then say "here, I'm done" most of the time. You need to know the environment it's around and what it needs to interact with/what will interact with it.
I like this analogy a lot. You can't just write code and then say "here, I'm done" most of the time. You need to know the environment it's around and what it needs to interact with/what will interact with it.
> just like it's hard to become a good musician if you shy away from sheet music
A bunch of world famous artists would disagree with you there.
https://www.themusicstudio.ca/blog/2017/11/909/
A bunch of world famous artists would disagree with you there.
https://www.themusicstudio.ca/blog/2017/11/909/
Those are literal rock stars, people who's fame and proficiency at one very narrow thing has given them the clout to hire and work with people who do all the things they don't know how to do or don't want to know. They're the exceptions which prove the rule.
If you want to be a professional musician who works with other people rather than just doing their own thing, you need to know sheet music, especially within certain sub-domains like orchestral settings.
(To be fair, as someone who is on the periphery of the music business, the above is a simplification. I'm not trying to imply that the "rock stars" get to skate by, often they're working harder than everyone else to be/remain successful. But they are still exceptional in many respects. Your average person trying to make a living as a musician absolutely needs to know sheet music or at least it's simpler cousin, the lead sheet, to be taken seriously.)
If you want to be a professional musician who works with other people rather than just doing their own thing, you need to know sheet music, especially within certain sub-domains like orchestral settings.
(To be fair, as someone who is on the periphery of the music business, the above is a simplification. I'm not trying to imply that the "rock stars" get to skate by, often they're working harder than everyone else to be/remain successful. But they are still exceptional in many respects. Your average person trying to make a living as a musician absolutely needs to know sheet music or at least it's simpler cousin, the lead sheet, to be taken seriously.)
I think you have a good point.
I know an fairly good amateur folk musician who can't read music at all. He relies entirely on his ability to learn music by ear. But he can usually play something after listening to it a few times, and he mostly plays solo folk music. So because he's talented and happy in his niche, he can get by without many typical professional skills.
Similarly, I know a CS researcher who hates to use anything but MatLab, and his MatLab code is not exactly an example of good software engineering. But he's published a stack of really great papers. He's brilliant and he works in a niche.
But the average novice would not be well served by imitating either of these people. They can do what they do because they're above average in specific skills, and because they've found a niche where they can thrive.
I know an fairly good amateur folk musician who can't read music at all. He relies entirely on his ability to learn music by ear. But he can usually play something after listening to it a few times, and he mostly plays solo folk music. So because he's talented and happy in his niche, he can get by without many typical professional skills.
Similarly, I know a CS researcher who hates to use anything but MatLab, and his MatLab code is not exactly an example of good software engineering. But he's published a stack of really great papers. He's brilliant and he works in a niche.
But the average novice would not be well served by imitating either of these people. They can do what they do because they're above average in specific skills, and because they've found a niche where they can thrive.
In that article, none of the artists is quoted as saying what they did was easy. The previous article on the same blog said it's best to learn both playing by ear and to read sheet music, because without reading it's hard to play anything new you haven't heard.
Didn't say it's impossible. I know great developers who don't like the command line.
Dude, it's just a metaphor.
Dude, it's just a metaphor.
Could you elaborate on which UIs for machine learning you are referring to?
I'm thinking in particular about Kibana (part of elasticsearch stack). I used it, it's absolutely awesome. It's a paid feature though.
I'm curious if the author has heard of sites like:
* https://repl.it/
* https://jsfiddle.net/
I didn't see anything like that mentioned in the article, but I think that you can easily write code inside your browser today.
Also, web browsers are already extremely heavy and complicated. That complexity is convenient for end users, but it also has costs, like making it very difficult and expensive to create a new competitive browser. Do we really need to add another standard to turn them into offline IDEs on top of everything else?
* https://repl.it/
* https://jsfiddle.net/
I didn't see anything like that mentioned in the article, but I think that you can easily write code inside your browser today.
Also, web browsers are already extremely heavy and complicated. That complexity is convenient for end users, but it also has costs, like making it very difficult and expensive to create a new competitive browser. Do we really need to add another standard to turn them into offline IDEs on top of everything else?
This this this.
repl.it, stackblitz.com, codesandbox.io, jsfiddle.net, codepen.io
Back then we don't even have online repls jesus christ.
These days devs got it easy it's really amazing
repl.it, stackblitz.com, codesandbox.io, jsfiddle.net, codepen.io
Back then we don't even have online repls jesus christ.
These days devs got it easy it's really amazing
or cloud9 https://aws.amazon.com/fr/cloud9/
Mentioned Glitch and Replit in the article - they're great and I love them but there's still something missing about relying on these platforms imho. I think cementing a default coding environment right into the browser would make it a lot more accessible - and actually be much closer to real coding where you're manipulating files and running code.
Plus: glitch/replit are quite slow to do any real coding inside of vs developing locally.
But maybe the future really is in the browser in this way.
Plus: glitch/replit are quite slow to do any real coding inside of vs developing locally.
But maybe the future really is in the browser in this way.
But why stop there? Let’s bundle something like Excel or Powerpoint, or Photoshop or Final Cut.
If we’re deciding to bundle additional software with a browser, why would a programming environment (chosen based on someone’s favorite language) be top priority?
If we’re deciding to bundle additional software with a browser, why would a programming environment (chosen based on someone’s favorite language) be top priority?
Imagine if there was some kind of runtime the browser shipped with that could let developers create all kind of applications that are downloaded and run on demand. That would be pretty cool.
They already put entire desktop environments in some two decades ago. It never took off.
With good reasons at the time -- browsers were slow and heavy. Now we have (among others) the V8 Javascript engine and insanely fast client computers (all of any recent desktop, laptop, and mobile device)
Because installing Excel is simple already
Install excel and nodejs. Then evaluate which was easier. I suspect node will win by a wide margin.
Already did. The author found that installing Node.js needs knowledge about the command line while Excel just needs a few clicks of "Next" (I just did it yesterday)
Node.js could improve their installer, would that solve all of OPs complaints?
Having installed excel and node countless times I can safely say excel is harder to install.
If you open the dev tools in your browser there's a full sandbox environment right there, not to mention the load of other sites available. I don't see why specifically Node should be installed.
Not only that, but if you set up Workspaces in Chrome (https://developers.google.com/web/tools/chrome-devtools/work...) you can edit files stored on your computer using devtools, making it even more like an IDE.
I just wrote a bunch of code inside Chrome devtools to do some web scraping. It works pretty well, with a REPL, (overly aggressive) autocomplete, and good integration with the DOM, but it's also limited.
Saving and loading .js files uses a very non-standard flow. The editor is OK but I think basic operations like "find across files" are missing. It's very "canned" and not customizable.
In other words, it feels more like a debugging environment than a programming environment, which I think is basically what they were going for.
Saving and loading .js files uses a very non-standard flow. The editor is OK but I think basic operations like "find across files" are missing. It's very "canned" and not customizable.
In other words, it feels more like a debugging environment than a programming environment, which I think is basically what they were going for.
Agreed, the much stronger counterargument is that all major browsers already have JS development environments built in! I am curious to hear why this is not suitable for the author.
I think you're craving a 21st century version of Emacs, where the development environment is baked into the product. I agree it's awesome, and I think the browser comes the closest, but you're right, it's not there yet. I fear the reason is mostly security: browsers are used by billions, but Emacs benefits from relative obscurity.
For TypeScript, there’s the TS Playground: https://www.typescriptlang.org/play
Back in college I would sketch something every day in jsfiddle
Those are basically standalone apps, not integrated into many of the other systems we use, which is the authors point.
I use jsfiddle a lot for small experiments. Another grate website is
https://codesandbox.io
https://codesandbox.io
The literal answer to the headline question is "You can, just open Developer Tools -> Console and code away." But it seems the question in the article is actually "Why can't I write node.js code inside my browser?", followed by what seems to me lots of confusion between coding and program execution environments (web-browser or MacOS).
You can code in JavaScript on most browsers without installing anything. Sure, the UI of browser Developer Tools can be somewhat intimidating for newcomers, but that could be fixed with some good tutorials. But it seems the author doesn't want to just write and run JavaScript, he wants to use node.js specifically. But the whole point of node.js is to take Chrome's JavaScript compiler/interpreter out of its native webbrowser environment and have it run in a Unix-like command line environment, such as Linux/MacOS. So complaining that you need to know some of the workings of a Unix-like command line environment to use node.js seems very misinformed.
As for accessibility of programming in general, the core developers are usually not that interested in that, but for most popular languages there are plenty of third party tutorials aimed at laymen. Most programming languages are specialized tools; they shouldn't try to be everything to everyone. We don't complain that university Calculus profs don't also write arithmetic books for elementary schools either.
You can code in JavaScript on most browsers without installing anything. Sure, the UI of browser Developer Tools can be somewhat intimidating for newcomers, but that could be fixed with some good tutorials. But it seems the author doesn't want to just write and run JavaScript, he wants to use node.js specifically. But the whole point of node.js is to take Chrome's JavaScript compiler/interpreter out of its native webbrowser environment and have it run in a Unix-like command line environment, such as Linux/MacOS. So complaining that you need to know some of the workings of a Unix-like command line environment to use node.js seems very misinformed.
As for accessibility of programming in general, the core developers are usually not that interested in that, but for most popular languages there are plenty of third party tutorials aimed at laymen. Most programming languages are specialized tools; they shouldn't try to be everything to everyone. We don't complain that university Calculus profs don't also write arithmetic books for elementary schools either.
Also don't forget projects like Cloud9. It is literally a cloud-based IDE similar to what the author was talking about.
I do agree with someone else's comment that this is lazy writing - even a little bit of research/google-fu would immediately point you to similar projects.
I don't know how he manages to write Node.js programs when one of the first things he says is that he couldn't get node to install.
The whole sentiment of this article just comes off a little whiny to me. Nowadays there is so much more information available for learning how to code and set up your dev environment. There are literally coding books for kids at book stores. And StackOverflow!
When I was younger, one had to search high and low on the net trying to find help using shitty dial-up service. Then, you'd end up in some IRC channel asking for help and someone simply says 'RTFM!'
When I was younger, one had to search high and low on the net trying to find help using shitty dial-up service. Then, you'd end up in some IRC channel asking for help and someone simply says 'RTFM!'
If this is the case, it is because people were conscious that there was in issue in how computer turned into more and more as an appliance mean to consume information [1] (The C64 had a full programming manual delivered with it, booted directly to an interpreter and even had schematic of the machine reportedly!) and tried to counter it.
Even then despite all the amazing ressource available, there is a risk of digital divide between people having access to tutor that can show the good ressource (because there is a lot of bad ressource!) and isolated people that are stuck with glorified engagement platform.
[1] https://www.salon.com/2006/09/14/basic_2/
Even then despite all the amazing ressource available, there is a risk of digital divide between people having access to tutor that can show the good ressource (because there is a lot of bad ressource!) and isolated people that are stuck with glorified engagement platform.
[1] https://www.salon.com/2006/09/14/basic_2/
The schematic wasn't in the C64 User Guide delivered with the machine, but it was in an additional Commodore publication "Commodore 64 Programmer's Reference Guide". The PRG was essential if you wanted to do anything more than the most basic BASIC contained in the UG.
See p.514- for the schematic https://archive.org/details/c64-programmer-ref/page/n513/mod...
See p.514- for the schematic https://archive.org/details/c64-programmer-ref/page/n513/mod...
Thanks I was not sure if the PRG was delivered with the C64.
> Then, you'd end up in some IRC channel asking for help and someone simply says 'RTFM!'
I had such a delightful retro experience the other day! I had spent days fighting a segfault in a widely used, mature library. Naturally, me being new to the library, and knowing that it's mature and widely used, I assumed I was doing something wrong. No mention of the problem online. Crickets in my StackOverflow question for days. In the end, my last ditch effort was to find some of the devlopers on IRC (I hadn't used it for a decade). I was ready for the "RTFM!!!" telling off of my childhood.
But no. People were super helpful. Helped me debug and explain what the library was doing. Turns out it was a bug in a little-used corner of the library afterall! It had lingered there unreported for 3 years. 10/10, would IRC again!
I had such a delightful retro experience the other day! I had spent days fighting a segfault in a widely used, mature library. Naturally, me being new to the library, and knowing that it's mature and widely used, I assumed I was doing something wrong. No mention of the problem online. Crickets in my StackOverflow question for days. In the end, my last ditch effort was to find some of the devlopers on IRC (I hadn't used it for a decade). I was ready for the "RTFM!!!" telling off of my childhood.
But no. People were super helpful. Helped me debug and explain what the library was doing. Turns out it was a bug in a little-used corner of the library afterall! It had lingered there unreported for 3 years. 10/10, would IRC again!
Your good experience was probably due to "10/10 would help someone who did their own homework first again!"
This is the nature of monotonic improvement. Just because things were substantially worse back in your day doesn't mean those darn kids don't have good reason to complain about the pain points of of today in an effort to make things substantially better tomorrow.
I'm happy to be that old guy who learned programming with magazine articles(and a pirated copy of turbo Pascal. You really appreciated that hypertext help.)
I'm impressed you did, I tried to learn the same way when I was younger, (albeit with pirated Borland C++) but never made any headway. Admittedly the library books I had access to were obsolete, and no-one in my rural area of a small country carried decent magazines on the subject.
That said, they did carry BBS magazines which led me eventually into the nascent WWW over the 14.4K modem I saved all my pocket money to buy.
Then I finally managed to access the resources to learn. God bless mailing lists.
That said, they did carry BBS magazines which led me eventually into the nascent WWW over the 14.4K modem I saved all my pocket money to buy.
Then I finally managed to access the resources to learn. God bless mailing lists.
I also got stuck on C++. It was (and remains) such a disproportionate pain to compile, which was just too high a hurdle in the days before you could search for your cryptic build errors on the internet.
I was able to fool around with BASIC easily enough, with entire programs provided in magazines like Byte.
I was able to fool around with BASIC easily enough, with entire programs provided in magazines like Byte.
Not all documentation should be aimed at an absolute beginner - the authors point about $PATH seems moot to me, especially considering how easy it is to look up.
Should a library also explain how an async function works in JS when introducing its feature that uses promises? Of course not.
Any field requires technical knowledge, and we're lucky we live in a world where its increasingly easier to overcome any roadblocks you find. I'm very anti gatekeeping, but if one expects to have every little detail drawn out for them then they're going to struggle in any even slightly complex field.
Overall I dont see how any of their points supported the random "install node by default" conclusion - and the point saying "most" people hate command lines made me physically reel.
Overall I dont see how any of their points supported the random "install node by default" conclusion - and the point saying "most" people hate command lines made me physically reel.
It’s all about reducing the barrier to entry. Many people find the command line daunting. Why not reduce these barriers to entry? Why require someone to understand $path to start coding in JavaScript?
I guess it's possible that new aspiring programmers will gain the fortitude to read documentation after a little while programming, but I can't help feeling that if someone isn't able to type "computer path" into a search engine from the start, they probably won't be able to figure out a whole lot of programming.
I learned programming on my calculator precisely for this reason, no cruft just pure code.
And for an inquisitive mind, having to type arcane command just to get the desired result is incredibly frustrating, and I don't count mindlessly browsing stack overflow or the internet just to get the stuff I need as learning. That is why course such as nand2tetris are incredibly good.
There is still an incredibly lot of stuff that can be done in matter of computer education. My dream would be a time travel libvmi based educational tool that allow to drill all the various function augmented with built in interactive explanation a la explorable and various code vizualization.
And for an inquisitive mind, having to type arcane command just to get the desired result is incredibly frustrating, and I don't count mindlessly browsing stack overflow or the internet just to get the stuff I need as learning. That is why course such as nand2tetris are incredibly good.
There is still an incredibly lot of stuff that can be done in matter of computer education. My dream would be a time travel libvmi based educational tool that allow to drill all the various function augmented with built in interactive explanation a la explorable and various code vizualization.
I'd like to point out here that I just spent a good 5 minutes punching variants on "computer path", "node path", "node install path", etc. into Google. And exactly zero results on the first page for any of those queries have anything to do with how to configure the PATH variable in your shell.
If someone didn't know what they were trying to solve for here, I'm not sure google would help them succeed.
If someone didn't know what they were trying to solve for here, I'm not sure google would help them succeed.
I just searched "computer path" (no quotes) on DDG and got:
- The wiki page for 'path' as a computing concept
- 3rd result is "how to set the path in MS Windows"
- 6th result is the wiki page for the path variable as a computing concept
I haven't used Google web search for years, has it really gotten that bad?
I haven't used Google web search for years, has it really gotten that bad?
My experience with programming, especially when I'm trying something new, is that about a dozen different things will go wrong.
At some point, there's some level of problem-solving required which involves taking what you know, and figuring out why it doesn't work. - One extremely common way of finding out what doesn't work is searching the web for the error you get, and finding a StackOverflow page which might be enough to explain it.
My experience was that I can "get by" without a deep understanding of some thing, until it doesn't work, then I need to poke around to get a better understanding so that I can fix whatever problem I have.
IIRC, I bet you can get decently far on the command-line without having to know what PATH is (or all the places it's set), thanks to package managers making things accessible. And then you'll run into some problem so that you need to know what PATH is, and then you'll learn.
At some point, there's some level of problem-solving required which involves taking what you know, and figuring out why it doesn't work. - One extremely common way of finding out what doesn't work is searching the web for the error you get, and finding a StackOverflow page which might be enough to explain it.
My experience was that I can "get by" without a deep understanding of some thing, until it doesn't work, then I need to poke around to get a better understanding so that I can fix whatever problem I have.
IIRC, I bet you can get decently far on the command-line without having to know what PATH is (or all the places it's set), thanks to package managers making things accessible. And then you'll run into some problem so that you need to know what PATH is, and then you'll learn.
> Many people find the command line daunting
Then they need to get over that if they want to learn to code or use scratch.
Then they need to get over that if they want to learn to code or use scratch.
Then they need to get over that if they want to learn to code
On the one hand I've been using the CLI for my entire career and and would be lost without it. On the other hand also I have colleagues who learnt to code after Visual Basic/Studio became a thing and work entirely in Visual Studio and manage to deliver top quality work year after year without basically ever having to touch the command line, so it certainly doesn't seem to be necessary.
If you really want to learn to program without learning to use the CLI you probably shouldn't pick and OS who's entire development environment is built around using the CLI.
On the one hand I've been using the CLI for my entire career and and would be lost without it. On the other hand also I have colleagues who learnt to code after Visual Basic/Studio became a thing and work entirely in Visual Studio and manage to deliver top quality work year after year without basically ever having to touch the command line, so it certainly doesn't seem to be necessary.
If you really want to learn to program without learning to use the CLI you probably shouldn't pick and OS who's entire development environment is built around using the CLI.
> Then they need to get over that if they want to learn to code or use scratch.
This is the right attitude to have as an aspiring programmer, but exactly the wrong attitude for someone who creates the tooling or documentation for helping aspiring programmers learn.
This is the right attitude to have as an aspiring programmer, but exactly the wrong attitude for someone who creates the tooling or documentation for helping aspiring programmers learn.
But it is the right attitude for someone creating tools for other proficient programmers to do even more advanced things. We won't advance the state of the art by handicapping yourself through catering to extreme beginners at every point.
In other words, the target audience of a Promise library for JS are people who know JavaScript and understand async. Trying to explain the basics of JavaScript, or programming in general, in that library's documentation would be a waste of time for everyone involved. A beginner has plenty of resources to learn from to reach the appropriate level, at which point they'll be able to wield the Promise library in a useful and responsible manner.
In other words, the target audience of a Promise library for JS are people who know JavaScript and understand async. Trying to explain the basics of JavaScript, or programming in general, in that library's documentation would be a waste of time for everyone involved. A beginner has plenty of resources to learn from to reach the appropriate level, at which point they'll be able to wield the Promise library in a useful and responsible manner.
If it's not $PATH, it will be something else.
People should deal with it and learn. No matter how low the barriers to entry are, you're still going to have to figure shit out at some point.
PS: You don't need to understand $PATH to start coding in JS. You can create an HTML or JS file, hack away and run it locally.
People should deal with it and learn. No matter how low the barriers to entry are, you're still going to have to figure shit out at some point.
PS: You don't need to understand $PATH to start coding in JS. You can create an HTML or JS file, hack away and run it locally.
you dont need to understand $path to start coding in javascript.
Just open a textfile with .html ending in an editor and in your browser..
You don't have to set up anything to get going.
I agree with the sentiment. But in order to build something that lower the barrier to entry you need an incentive. Building tools is hard and costly. Maintaining them even more.
In video games you have blueprint systems because the economy supports this idea. For kids you have scratch.
For web dev you have some solutions but my guess is that when someone wants to use node there isn't yet any useful solution (outside of playgrounds) that is cheap enough to make and remove the need for some basic computer knowledge.
In video games you have blueprint systems because the economy supports this idea. For kids you have scratch.
For web dev you have some solutions but my guess is that when someone wants to use node there isn't yet any useful solution (outside of playgrounds) that is cheap enough to make and remove the need for some basic computer knowledge.
That is a good point, but, instead of explaining path in the installer, maybe the starting point for learning should be somewhere else, such as a tutorial?
The author is not talking about "professional programming" but about a field called "end-user programming" or more generally "end-user development", which is a whole academic field with the goal os allowing end-users to develop their own solutions.
From this field came things like Scratch [1].
If you're interested a very important paper in that area (from the philosophical aspect) is "Meta-Design: A manifesto for End-User Development". [2]
[1] https://scratch.mit.edu/ [2] (PDF) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68....
From this field came things like Scratch [1].
If you're interested a very important paper in that area (from the philosophical aspect) is "Meta-Design: A manifesto for End-User Development". [2]
[1] https://scratch.mit.edu/ [2] (PDF) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68....
HyperCard, Excel, and (at the upper end) Flash are basically end-user programming that allowed for some really great creativity. I get the feeling most corporate programmers want to ban Excel and force the users to had over their code to have it properly programmed. The other two were gotten rid of. Instead of making easier and easier tools, we've gotten harder and harder. I still contend that NeXTSTEP was an easier programming environment than the web of today.
Javascript is not a beginner language anymore. It has a lot of edge cases and traps that defeat the average person.
Javascript is not a beginner language anymore. It has a lot of edge cases and traps that defeat the average person.
> Javascript is not a beginner language anymore.
Why not? You can still write vanilla JS the same way you could decades ago without much (any?) change.
> It has a lot of edge cases and traps that defeat the average person.
It's always had that. In fact, I think the reason it feels less like a beginner language is that the solutions we've created to handle the edge-cases and traps have been solved for professionals. It's more that the way we teach it has changed. It's now a "professional" tool, so most content out there is aimed at people endeavoring to become professionals, needing to deal with all the complex realities of professional-grade problems. But you can still teach it in the same beginner-friendly way you could in the early 2000's.
I've seen this teaching my son (using JavaScript). My instinct is to direct him to use all of the techniques I use because it's the "right" way. But a beginner doesn't really care about the problems that the "right" way solves. They don't even know about them yet. So it's overkill. Forget Typescript, webpack, eslint, Angular, node, etc., let's just write everything in one HTML file (not even using <script> to include a separate .js file yet) and focus on the thing he's interested in making. We'll get to all that other stuff eventually, and then he'll actually have enough foundation and context to understand and appreciate (not to say all the complexity we've built is perfect).
Why not? You can still write vanilla JS the same way you could decades ago without much (any?) change.
> It has a lot of edge cases and traps that defeat the average person.
It's always had that. In fact, I think the reason it feels less like a beginner language is that the solutions we've created to handle the edge-cases and traps have been solved for professionals. It's more that the way we teach it has changed. It's now a "professional" tool, so most content out there is aimed at people endeavoring to become professionals, needing to deal with all the complex realities of professional-grade problems. But you can still teach it in the same beginner-friendly way you could in the early 2000's.
I've seen this teaching my son (using JavaScript). My instinct is to direct him to use all of the techniques I use because it's the "right" way. But a beginner doesn't really care about the problems that the "right" way solves. They don't even know about them yet. So it's overkill. Forget Typescript, webpack, eslint, Angular, node, etc., let's just write everything in one HTML file (not even using <script> to include a separate .js file yet) and focus on the thing he's interested in making. We'll get to all that other stuff eventually, and then he'll actually have enough foundation and context to understand and appreciate (not to say all the complexity we've built is perfect).
HyperTalk was a language that a beginner could use. Javascript is directed towards pro programmers and things that don't help the beginner like comparison and breaks in return statements.
> The author is not talking about "professional programming" but about a field called "end-user programming" or more generally "end-user development"
I do think VisualBasic(6) had a thing there. It was so easy to visually design a GUI and slap some code into it.
That said, as a "professional programmer" I once had to maintain such a VB6 application that was developed by someone that wasn't a professional programmer and that application was absolutely business critical for that company.
It wasn't fun to put it mildly. So my take on this is that it probably died for a reason.
I do think VisualBasic(6) had a thing there. It was so easy to visually design a GUI and slap some code into it.
That said, as a "professional programmer" I once had to maintain such a VB6 application that was developed by someone that wasn't a professional programmer and that application was absolutely business critical for that company.
It wasn't fun to put it mildly. So my take on this is that it probably died for a reason.
> So my take on this is that it probably died for a reason.
Yes, Microsoft killed it.
Up to the point when Microsoft killed it, it did nothing but grow. And for years after Microsoft killed it, it did nothing but grow.
Microsoft killed it because it was a mess on every level, and they didn't like the part they were the ones maintaining. But lack of demand certainly wasn't a factor there in any way.
Yes, Microsoft killed it.
Up to the point when Microsoft killed it, it did nothing but grow. And for years after Microsoft killed it, it did nothing but grow.
Microsoft killed it because it was a mess on every level, and they didn't like the part they were the ones maintaining. But lack of demand certainly wasn't a factor there in any way.
That's not a problem unique to VB6, there is a lot of crap code out there.
Also I've seen some strong programmers being very productive with tools like VB6 and Delphi.
I suspect the main reason for its demise is corporates don't like installing software on client machines. It's much easier for them to deliver everything through the browser.
Also I've seen some strong programmers being very productive with tools like VB6 and Delphi.
I suspect the main reason for its demise is corporates don't like installing software on client machines. It's much easier for them to deliver everything through the browser.
If the author has “been playing with the web and code for years” and is still “wtf” on /usr/local/bin in $PATH it shows a lack of discipline and structure in their learning.
I see this in many in many of my apprentices - the desire for instant gratification and the lack of experience means they refuse to do anything that doesn’t immediately proceed them closer to their goal.
Here’s the thing with programming - you can’t run before you can walk.
Go read “Learn python the hard way”, do 1 lesson a day
Go do Linuxjourney - do 1 lesson a day
By lesson 8 you’ll know about /usr/local/bin and path, and packages, that’ll fix all of your gripes about not being able to install ruby, pip and node too.
And all of that is solved only after 8 days of disciplined learning. Sure it’s not immediately towards your goal but you need the lower level skills and knowledge first. And it’s only 8 days!
Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult. Go and learn some electrical engineering, go and learn some metalworking, go and learn some mechanical engineering, then you may come back and attempt to assemble a car. You might fail the second time too, but each time you’ll get further.
Stop seeking that immediate gratification, the path to success is NEVER a straight line
I see this in many in many of my apprentices - the desire for instant gratification and the lack of experience means they refuse to do anything that doesn’t immediately proceed them closer to their goal.
Here’s the thing with programming - you can’t run before you can walk.
Go read “Learn python the hard way”, do 1 lesson a day
Go do Linuxjourney - do 1 lesson a day
By lesson 8 you’ll know about /usr/local/bin and path, and packages, that’ll fix all of your gripes about not being able to install ruby, pip and node too.
And all of that is solved only after 8 days of disciplined learning. Sure it’s not immediately towards your goal but you need the lower level skills and knowledge first. And it’s only 8 days!
Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult. Go and learn some electrical engineering, go and learn some metalworking, go and learn some mechanical engineering, then you may come back and attempt to assemble a car. You might fail the second time too, but each time you’ll get further.
Stop seeking that immediate gratification, the path to success is NEVER a straight line
> Stop trying to assemble a fully functional car with no understanding of the fundamentals and then getting frustrated that car assembly is difficult.
Most of these people find driving hard. You have to put the liquid in the hole and turn the key and keep pressing the floor-thing and hold the circle thing all while looking out the window to make sure no one gets in your way and the car stays on the hard paths.
What they really want is to just be able to jump in the back seat and state their destination then go back to chuckling at tik-toks and messaging friends until they're there. That's the kind of car assembly they want, complete with the commensurate salary and benefits. Is it really so much to ask to have that delivered to them?
Most of these people find driving hard. You have to put the liquid in the hole and turn the key and keep pressing the floor-thing and hold the circle thing all while looking out the window to make sure no one gets in your way and the car stays on the hard paths.
What they really want is to just be able to jump in the back seat and state their destination then go back to chuckling at tik-toks and messaging friends until they're there. That's the kind of car assembly they want, complete with the commensurate salary and benefits. Is it really so much to ask to have that delivered to them?
Thank you for mentioning Linux Journey[1]! I never heard about it before - it looks like a great resource.
Another thing I want to add on - it looks like the author is lacking curiosity. I didn't have much discipline and structure in the beginning of my programming journey. In fact, I've been trying to add more discipline and structure to my learning now.
When I started though, I had a TON of curiosity. I fiddled all the time with everything. I fiddled with settings in Windows XP to make my family's computer faster, I fiddled with my own laptop by installing Linux and trying out tons of programs, I fiddled with the code on my computer to make it do cool things on the command line, etc.
I didn't have an end goal in mind - it was just something fun to do and I just wanted to answer all the questions in my head. Being curious drove me to learn, adding discipline and structure helps to fill in some gaps in my learning that my curiosity may have missed.
[1]: https://linuxjourney.com/
Another thing I want to add on - it looks like the author is lacking curiosity. I didn't have much discipline and structure in the beginning of my programming journey. In fact, I've been trying to add more discipline and structure to my learning now.
When I started though, I had a TON of curiosity. I fiddled all the time with everything. I fiddled with settings in Windows XP to make my family's computer faster, I fiddled with my own laptop by installing Linux and trying out tons of programs, I fiddled with the code on my computer to make it do cool things on the command line, etc.
I didn't have an end goal in mind - it was just something fun to do and I just wanted to answer all the questions in my head. Being curious drove me to learn, adding discipline and structure helps to fill in some gaps in my learning that my curiosity may have missed.
[1]: https://linuxjourney.com/
If you're looking for resources currently, Humble's got a Linux book bundle for the next 2-3 days that looks pretty good.
Immediate gratification does have its purposes.
It helped me a lot as a teenager in the late nineties that I could install borland delphi and very easily have a self contained windows app running without understanding too much, it gave me the confidence to go on and learn the lower level stuff.
It helped me a lot as a teenager in the late nineties that I could install borland delphi and very easily have a self contained windows app running without understanding too much, it gave me the confidence to go on and learn the lower level stuff.
/usr/local/bin has absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge.
It is only required because, as the author correctly points out, the tools we use are BAD. They are absolutely fucking AWFUL.
/usr/local/bin is an implementation detail from an OS nobody has used for decades. It's still here because we refuse to fix these ridiculous things. Nobody should need to know this.
It is only required because, as the author correctly points out, the tools we use are BAD. They are absolutely fucking AWFUL.
/usr/local/bin is an implementation detail from an OS nobody has used for decades. It's still here because we refuse to fix these ridiculous things. Nobody should need to know this.
I've been programming for 25 years now, about 20 of which as a developer at billion dollar companies, google, facebook and various high scale hedge funds, including systems that serve billions of users a day. I have had a hobby in embedded programming and FPGA programming, compiler design and distributed deep learning.
All of which used /usr/local/bin and $PATH. Every system, regardless of programming language across python, C, C++, java, go, erlang.
Saying /usr/local/bin and/or $PATH "has absolutely nothing whatsoever to do with programming" is total rubbish. Programming as a field doesn't just include domain and syntax knowledge of a programming language, it includes ALL of the system implementation details below it, and YOU ARE EXPECTED TO KNOW THEM.
Saying something so basic and fundamental "has absolutely nothing to do with programming" only shows a terrible lack of systems knowledge, this is used in unix, linux, bsd, embedded and massive server scale deployments.
Acting like this stuff is somehow below you, just shows intellectual laziness, this stuff both BASIC (easy to learn) and FUNDAMENTAL (applies almost universally in many systems), and if you acted like this during an interview or working at anywhere with non-trivial setups you'd be laughed out of the room.
All of which used /usr/local/bin and $PATH. Every system, regardless of programming language across python, C, C++, java, go, erlang.
Saying /usr/local/bin and/or $PATH "has absolutely nothing whatsoever to do with programming" is total rubbish. Programming as a field doesn't just include domain and syntax knowledge of a programming language, it includes ALL of the system implementation details below it, and YOU ARE EXPECTED TO KNOW THEM.
Saying something so basic and fundamental "has absolutely nothing to do with programming" only shows a terrible lack of systems knowledge, this is used in unix, linux, bsd, embedded and massive server scale deployments.
Acting like this stuff is somehow below you, just shows intellectual laziness, this stuff both BASIC (easy to learn) and FUNDAMENTAL (applies almost universally in many systems), and if you acted like this during an interview or working at anywhere with non-trivial setups you'd be laughed out of the room.
So I think what's happening is that there are people here who have maybe been programming longer than you have. And we remember when professional programs might be written in BASIC and sold on 5.25 inch floppies. On machines with no /usr/local or PATH. And then we programmed PCs using Borland or Symantec or whatever IDE and there was no /usr/local or (usually) PATH to be concerned about. And we programmed MacOS before it was Unix based using Think C or CodeWarrior and there was no /usr/local or PATH or even a CLI.
And so when CLIs became popular with (broadly speaking) the early growth of the internet, we became more familiar with /usr/local and PATH (we probably had some exposure to these already). So while yes, these are found in most modern systems, we see these things as details. PATH simply doesn't feel "fundamental" to me because I've written exactly the same kind of code in environments where PATH is used and where it doesn't even exist as a concept.
Of course, what is "fundamental" is rather a judgment call, and your perspective makes it so that these are fundamental for you.
I won't defend the original post, particularly wrt nonsense like adding node to a browser. But I do think different perspectives are at play here, and disagreement on either side does not reflect intellectual laziness or people who should be laughed out of the room.
And so when CLIs became popular with (broadly speaking) the early growth of the internet, we became more familiar with /usr/local and PATH (we probably had some exposure to these already). So while yes, these are found in most modern systems, we see these things as details. PATH simply doesn't feel "fundamental" to me because I've written exactly the same kind of code in environments where PATH is used and where it doesn't even exist as a concept.
Of course, what is "fundamental" is rather a judgment call, and your perspective makes it so that these are fundamental for you.
I won't defend the original post, particularly wrt nonsense like adding node to a browser. But I do think different perspectives are at play here, and disagreement on either side does not reflect intellectual laziness or people who should be laughed out of the room.
I started with BASIC on a second-hand VIC20, and then onto assembler on an 80286 running DOS. So I've been there.
I define "fundamental" as something thats in wide use and deployment in actively running systems. Like $PATH being in every operating system used today and /usr/local/bin on every linux distribution running on literally hundreds of millions of servers globally, right now.
And the requirement of understanding these are part of what's holding back the author of the article from not having a running ruby, pip and node.js
I define "fundamental" as something thats in wide use and deployment in actively running systems. Like $PATH being in every operating system used today and /usr/local/bin on every linux distribution running on literally hundreds of millions of servers globally, right now.
And the requirement of understanding these are part of what's holding back the author of the article from not having a running ruby, pip and node.js
[deleted]
[deleted]
The reason I say it has nothing to do with programming is that none of all of these tools that make you rely on this stuff NEED to do so. They chose to. But they don't need to. This is an implementation detail that is entirely orthogonal to the rest of the task of programming.
Superfluous, and could be replaced at any time.
And I note you immediately jump to the conclusion that I am too stupid to know these things that you know because you are clever. And that is EXACTLY the problem.
Superfluous, and could be replaced at any time.
And I note you immediately jump to the conclusion that I am too stupid to know these things that you know because you are clever. And that is EXACTLY the problem.
No, I was just saying that in my vast experience the two things that you described as:
"absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge"
Were indeed critical components to all of these systems, and organisations, and that it's not a big ask to require a programmer to know them.
Also, on what authority do you decide what is programming and what isn't?
"absolutely nothing whatsoever to do with programming. Nothing. Zero. Zilch. It is completely superfluous knowledge"
Were indeed critical components to all of these systems, and organisations, and that it's not a big ask to require a programmer to know them.
Also, on what authority do you decide what is programming and what isn't?
The whole point is, there is no reason to require a programmer to know them. That is an arbitrary choice we have made.
We could make a different choice, and not require a programmer to know these things. They could do everything just as well without knowing this, if we let them.
We could make a different choice, and not require a programmer to know these things. They could do everything just as well without knowing this, if we let them.
> The whole point is, there is no reason to require a programmer to know them.
There's no point to making sure a programmer knows how his environment is set up? Are you being serious right now?
There's no point to making sure a programmer knows how his environment is set up? Are you being serious right now?
When I was travelling through Italy, I learnt a phrase from programmers there, "If my mother had wheels, she would have been a bike" - and it's a criticism of hypothetical situations like your answer above.
Saying "This is arbitrary if we made a different choice things would be different" is a total meaningless statement because you just move the bar and then say if the bar is moved things are different.
My argument is that eventually all implementations are embedded in reality, if not /usr/local/bin and $PATH then some other abstraction that is equally arbitrary - but in the real world, the one we live in, we have /usr/local/bin, $PATH and a bunch of other "arbitrary" lines that have to be somewhere because without these lines (or some lines) there is nothing. And you have to know them, whatever they are.
Because you know what happens if you don't know them? You end up with people writing blog posts about how difficult programming is, ranting they cant install ruby or pip or node.js, like the article above. You have to learn the underlying system, whatever it is. In this case, it's /usr/local/bin and $PATH.
I think you're not arguing that you shouldn't know the underlying system (correct me if I'm wrong) but you're more saying that these particular abstractions are inconsistent or distasteful - if that's the case, let me assure you that no implementation is perfect, and programmers for nearly 100 years now have been trying to come up with the perfect abstraction that requires no knowledge below, but in reality, it never works, because theres always exceptions, or the abstraction is not flexible enough to apply generally enough to be useful, thats like the two forces that push and pull the argument both ways.
I've come to learn that you must just learn the underlying system, because you'll be able to diagnose better. To that end, you must learn sysadmin, you must know $PATH and you must know the underlying system. Go and have a look at the programmer competency matrix - this stuff is in there
Saying "This is arbitrary if we made a different choice things would be different" is a total meaningless statement because you just move the bar and then say if the bar is moved things are different.
My argument is that eventually all implementations are embedded in reality, if not /usr/local/bin and $PATH then some other abstraction that is equally arbitrary - but in the real world, the one we live in, we have /usr/local/bin, $PATH and a bunch of other "arbitrary" lines that have to be somewhere because without these lines (or some lines) there is nothing. And you have to know them, whatever they are.
Because you know what happens if you don't know them? You end up with people writing blog posts about how difficult programming is, ranting they cant install ruby or pip or node.js, like the article above. You have to learn the underlying system, whatever it is. In this case, it's /usr/local/bin and $PATH.
I think you're not arguing that you shouldn't know the underlying system (correct me if I'm wrong) but you're more saying that these particular abstractions are inconsistent or distasteful - if that's the case, let me assure you that no implementation is perfect, and programmers for nearly 100 years now have been trying to come up with the perfect abstraction that requires no knowledge below, but in reality, it never works, because theres always exceptions, or the abstraction is not flexible enough to apply generally enough to be useful, thats like the two forces that push and pull the argument both ways.
I've come to learn that you must just learn the underlying system, because you'll be able to diagnose better. To that end, you must learn sysadmin, you must know $PATH and you must know the underlying system. Go and have a look at the programmer competency matrix - this stuff is in there
What I am saying is, as soon as someone new to programming points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.
As is happening everywhere in this very thread.
I am saying that this is weird, toxic and must stop. We must be able to admit that yes, the tools we use are kind of bad. We must admit that we could do better. Otherwise nothing will ever change, and we will keep using stupidly broken tools until the end of days, while patting ourselves on the back for being clever enough to use them.
As is happening everywhere in this very thread.
I am saying that this is weird, toxic and must stop. We must be able to admit that yes, the tools we use are kind of bad. We must admit that we could do better. Otherwise nothing will ever change, and we will keep using stupidly broken tools until the end of days, while patting ourselves on the back for being clever enough to use them.
I'd like to put one of your comments in a different but maybe enlightening context:
What I am saying is, as soon as someone new to gardening points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, gardeners will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a gardener.
What I am saying is, as soon as someone new to gardening points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, gardeners will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a gardener.
Now imagine that gardeners all use chainsaws. They are very proud of how skilled they are at their chainsaw usage.
A new person comes in, and asks, why on earth do you all use chainsaws for this? Wouldn't it be easier to use more appropriate tools?
And the gardeners immediately call him clueless, make fun of him for not being able to handle a chainsaw, and tell him he will never be a gardener if he can't even figure out how to use a chainsaw.
A new person comes in, and asks, why on earth do you all use chainsaws for this? Wouldn't it be easier to use more appropriate tools?
And the gardeners immediately call him clueless, make fun of him for not being able to handle a chainsaw, and tell him he will never be a gardener if he can't even figure out how to use a chainsaw.
A new person has no grasp on what constitutes a "more appropriate tool." People with zero experience don't get to dictate what tools people who know what they're doing should use.
Can you imagine if a layman walked into a mechanic's shop off the street and started trying to tell the workers there the same thing? Or a bakery?
Can you imagine if a layman walked into a mechanic's shop off the street and started trying to tell the workers there the same thing? Or a bakery?
I find this a highly amusing example, as gardeners do use chainsaws. Possibly not often, but it is a tool with a purpose that they do use.
And they'd be right to, because actually the situation is inverted. Saying a useful tool is unnecessary and a symptom of the fact that all tools are broken is the sort of thing the person holding the chainsaw would say, not the people who understand why a whole range of tools exist.
Except the person you're talking to is a gardener, who uses a chainsaw frequently, and is saying that indeed the beginner is right to point out that we should definitely be using a better tool than a chainsaw.
And then people shout them down because they've apparently become so accustomed to using a chainsaw that they honestly can't imagine a better way.
And then people shout them down because they've apparently become so accustomed to using a chainsaw that they honestly can't imagine a better way.
> What I am saying is, as soon as someone new to programming points out, entirely correctly, that the tools we use are weird, obscure and difficult to use for no apparent reason, programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.
If you are a beginner in some topic (any topic), and encounter a group of people who are proficient in that thing, and you disagree with them about some aspect of it, the options are broadly that 1. you've hit some great insight, or 2. you don't understand, but the odds favor option 2. If, however, you're confident that you've hit onto something better than everyone else, let me echo others and suggest that you should try to implement it; either you will succeed and show the industry the error of their ways, or you'll find out why things are the way they are, and both of those are good outcomes.
If you are a beginner in some topic (any topic), and encounter a group of people who are proficient in that thing, and you disagree with them about some aspect of it, the options are broadly that 1. you've hit some great insight, or 2. you don't understand, but the odds favor option 2. If, however, you're confident that you've hit onto something better than everyone else, let me echo others and suggest that you should try to implement it; either you will succeed and show the industry the error of their ways, or you'll find out why things are the way they are, and both of those are good outcomes.
Except that many programmers, including parent, happen to agree that with what the beginner is saying. That it is so obviously true that even a beginner can see it is evidence that the people who can't see it have conflated the way things are with the way things need to be.
> programmers will scream in rage that no, they are not, and by the way, you are stupid for saying it, you clearly have no idea what you are doing and you will never be a programmer.
Nobody has said this to you in this thread, and the fact that you're acting like it is the only toxic thing here. This is called a straw-man logical fallacy, you misrepresent my argument so it makes it easier for you to attack. Nobody has said this to you, that part is all in your head.
I'm saying the tools are not weird if you understand them, and how they fit as a cohesive whole. I'm saying they just look weird to you, because you don't yet understand them. Can we do better? Absolutely, I'm all for better tools. But if the original poster wants to install pip and ruby and nodejs then knowledge of system paths is mandatory - because this is what they are trying to do.
In my answers above, I have named several programming languages, several operating systems, discussed my commercial experience and then talked about the rationale behind my logic.
You have done nothing but turn these into personal attacks against yourself, not discussing systems or operating systems, (not even naming one!) but always complaining about people calling you stupid or how you're the victim. The only person that has used the word stupid in this thread is you. You are a toxic narcissist, and I chose not to engage with you.
Nobody has said this to you in this thread, and the fact that you're acting like it is the only toxic thing here. This is called a straw-man logical fallacy, you misrepresent my argument so it makes it easier for you to attack. Nobody has said this to you, that part is all in your head.
I'm saying the tools are not weird if you understand them, and how they fit as a cohesive whole. I'm saying they just look weird to you, because you don't yet understand them. Can we do better? Absolutely, I'm all for better tools. But if the original poster wants to install pip and ruby and nodejs then knowledge of system paths is mandatory - because this is what they are trying to do.
In my answers above, I have named several programming languages, several operating systems, discussed my commercial experience and then talked about the rationale behind my logic.
You have done nothing but turn these into personal attacks against yourself, not discussing systems or operating systems, (not even naming one!) but always complaining about people calling you stupid or how you're the victim. The only person that has used the word stupid in this thread is you. You are a toxic narcissist, and I chose not to engage with you.
> I'm saying the tools are not weird if you understand them
No, they are still weird. They are only not weird if you've become accustomed to the weirdness.
I primarily develop on Windows, and when I come to Linux to work on things I am astonished to find that Linux developers think nothing of using upwards of half a dozen different languages to build one thing. CMake, autoconf, shell, and python all being used to build a single C++ program is weird and unnecessary. If you don't think so I submit you've merely become accustomed to doing things in this incredibly weird way!
PS: Windows has its own developer tendencies that are weird and unnecessary, but I will at least readily admit that about them.
No, they are still weird. They are only not weird if you've become accustomed to the weirdness.
I primarily develop on Windows, and when I come to Linux to work on things I am astonished to find that Linux developers think nothing of using upwards of half a dozen different languages to build one thing. CMake, autoconf, shell, and python all being used to build a single C++ program is weird and unnecessary. If you don't think so I submit you've merely become accustomed to doing things in this incredibly weird way!
PS: Windows has its own developer tendencies that are weird and unnecessary, but I will at least readily admit that about them.
I think a lot of this thread is people’s biases from what they are used to. I’m one of those guys who started on the command line and lived on the command line most of his life. I couldn’t imagine a more productive environment! I consider a bunch of xterms running vi to be the pinnacle of IDEs. But I did two brief stints at Windows shops and just couldn’t get really productive. The guy next to me who was scared of the command line and never went outside Visual Studio? He wasn’t stupid, he just had a different lineage and got accustomed to a different environment and workflow. One is not inherently better than the other.
That said, if you are a modern web developer, you just have to understand the command line. You have to know what /usr/local/bin is. You have to know how to install your toolchain. It’s inconvenient, but it’s table stakes. I don’t think it’s reasonable to say “Hey! I’m used to GUIs so people programming on the command line are wrong and I shouldn’t need to know about /usr/local/bin“
That said, if you are a modern web developer, you just have to understand the command line. You have to know what /usr/local/bin is. You have to know how to install your toolchain. It’s inconvenient, but it’s table stakes. I don’t think it’s reasonable to say “Hey! I’m used to GUIs so people programming on the command line are wrong and I shouldn’t need to know about /usr/local/bin“
I think it is perfectly reasonable to question whether all of that is necessary just to program stuff for the web.
First you say nobody has called me stupid.
Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.
I have been using them for decades. I know them very, VERY well. I am saying all of this from a position of long and deep familiarity with the tools.
Yet immediately you jump the conclusion that I just don't know what I am talking about.
Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.
I have been using them for decades. I know them very, VERY well. I am saying all of this from a position of long and deep familiarity with the tools.
Yet immediately you jump the conclusion that I just don't know what I am talking about.
> First you say nobody has called me stupid.
> Then in the NEXT PARAGRAPH, you tell me that I don't understand command line tools.
Nothing I read by malux85 implied to me that not understanding command line tools makes someone stupid.
Nothing I read by malux85 implied to me that not understanding command line tools makes someone stupid.
I think davorak is right, malux85 never says lack of understanding implies stupidity. I'd go even further. I don't read malux85's comment as an attack on your understanding personally. I read it as referring to people like the blog post author, who clearly don't understand the basics of the tools they're complaining about.
No one is screaming in rage about anything here. We do tend to get frustrated hearing complaints from people that are unwilling to take even the smallest amount of time to learn before complaining about the state of things.
No one is screaming in rage about anything here. We do tend to get frustrated hearing complaints from people that are unwilling to take even the smallest amount of time to learn before complaining about the state of things.
[deleted]
> /usr/local/bin is an implementation detail from an OS nobody has used for decades.
Are you taking the piss? Should we also remove SOCKET's because they were introduced in that same OS?
It should be noted that _EVERY_ modern operating system implements a "path" system, even the ones that are very divergent.
Are you taking the piss? Should we also remove SOCKET's because they were introduced in that same OS?
It should be noted that _EVERY_ modern operating system implements a "path" system, even the ones that are very divergent.
Also, Namespacing and search paths are a concept in every environment where people name things. Be it the filesystem or a programming language itself.
Even in normal Life, when identifying people or things, we have concepts of this everywhere. How can people see that as pointless?
Even in normal Life, when identifying people or things, we have concepts of this everywhere. How can people see that as pointless?
And environmental variables, too. You can see the same pattern:
process :: function
path :: namespacing
command line argument :: function argument
environmental variable :: dynamically bound variable
Should we remove sockets? Possibly. We could most likely design a better API today.
Go ahead and do so, please.
You keep saying that things could be better but show no counterexample.
Lead the change or stop whining. Nobody is going to do the job for you if they're satisfied by their current tools, especially if they think you're wrong.
Do it and prove everyone else wrong. If everyone thinks the status quo can't be improved, but you're enlightened, it's your chance to turn your "likely can be improved" into reality.
The non-programmer user base is immense. You can get rich by selling your alternative.
You keep saying that things could be better but show no counterexample.
Lead the change or stop whining. Nobody is going to do the job for you if they're satisfied by their current tools, especially if they think you're wrong.
Do it and prove everyone else wrong. If everyone thinks the status quo can't be improved, but you're enlightened, it's your chance to turn your "likely can be improved" into reality.
The non-programmer user base is immense. You can get rich by selling your alternative.
> Lead the change or stop whining.
Ugh. Look, just because they themselves have not attempted to create something better doesn't mean that their criticisms are invalid.
Ugh. Look, just because they themselves have not attempted to create something better doesn't mean that their criticisms are invalid.
They are if they are nonspecific. Saying "X is bad" requires a counterexample, at least.
They gave counter examples, specifically "we didn't need this in the past, therefore it is not actually necessary". Which is entirely correct. We do things the way we do things largely for historical reasons and beginner users are right to point that out.
I was there in the past and the tools are really not comparable. I just inserted a floppy disk and did A: then TP.EXE (which was just as arcane as knowing $PATH) but do I really want to work on Turbo Pascal in MS-DOS? Of course complexity skyrocketed!
That's not a counterexample because beginners have contemporary expectations. There are simpler alternatives that just work. Why do beginners want to use Node.js locally then?
> We do things the way we do things largely for historical reasons
Nobody challenged that. The question is: is the alternative better or just a different (but equally arcane) set of quirks?
If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.
Sounds like NIH to me.
That's not a counterexample because beginners have contemporary expectations. There are simpler alternatives that just work. Why do beginners want to use Node.js locally then?
> We do things the way we do things largely for historical reasons
Nobody challenged that. The question is: is the alternative better or just a different (but equally arcane) set of quirks?
If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.
Sounds like NIH to me.
> I was there in the past and the tools are really not comparable. I just inserted a floppy disk and did D: then TP.EXE but do I really want to work on Turbo Pascal in MS-DOS? Of course complexity skyrocketed!
Did it do so for reasons that are still relevant today, is the question.
> That's not a counterexample because beginners have contemporary expectations.
Alright I'll present a counterexample: Lazarus. You download it and install it [0], then you run it and make programs. It has a WYSIWYG GUI builder and produces stand-alone executables for multiple operating systems. There is no complicated build environment to set up.
> If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.
I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.
> Sounds like NIH to me.
And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.
[0] I would argue that the installation step here is also unnecessary as there is no reason Lazarus cannot operate as a stand-alone self-contained portable folder other than the developers insistence on hardcoded paths.
Did it do so for reasons that are still relevant today, is the question.
> That's not a counterexample because beginners have contemporary expectations.
Alright I'll present a counterexample: Lazarus. You download it and install it [0], then you run it and make programs. It has a WYSIWYG GUI builder and produces stand-alone executables for multiple operating systems. There is no complicated build environment to set up.
> If you're not using $PATH you'd be using an analogue system to solve the same problem, and you'd lose portability with current OSes.
I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.
> Sounds like NIH to me.
And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.
[0] I would argue that the installation step here is also unnecessary as there is no reason Lazarus cannot operate as a stand-alone self-contained portable folder other than the developers insistence on hardcoded paths.
> I contend that the problem $PATH solves has nothing to do with programming. $PATH is a solution for finding programs when you type their name on the commandline, nothing more. Windows and Mac programs don't really use or need it for the vast majority of tasks. Programming does not fundamentally require $PATH.
Do you write programs that don't load libraries? That don't interact with files? $PATH is required (or something to search along to find those libraries or files). I've been programming for 25+ years and I can't think of a serious actual application that I've written that doesn't need something like $PATH. Even simple data formatting console apps generally need to load a JSON library or something similar. It's impossible to bundle every library needed for an app in every app. People keep saying that $PATH isn't needed but location services of some kind is absolutely needed! I'd argue that $PATH is the result of 50+ years of engineering/science and research and is the best known way to address that issue as of now.
Do you write programs that don't load libraries? That don't interact with files? $PATH is required (or something to search along to find those libraries or files). I've been programming for 25+ years and I can't think of a serious actual application that I've written that doesn't need something like $PATH. Even simple data formatting console apps generally need to load a JSON library or something similar. It's impossible to bundle every library needed for an app in every app. People keep saying that $PATH isn't needed but location services of some kind is absolutely needed! I'd argue that $PATH is the result of 50+ years of engineering/science and research and is the best known way to address that issue as of now.
>And arguments that understanding $PATH is somehow a necessary pre-requisite to get into programming sound like needless complexity fetishism to me.
Understanding your programming environment is absolutely a prerequisite to getting into programming. If you don't want to deal with $PATH, you should know enough about your target OS to know how to run things without it (which is really, really not hard to do).
No program exists in a vacuum.
Understanding your programming environment is absolutely a prerequisite to getting into programming. If you don't want to deal with $PATH, you should know enough about your target OS to know how to run things without it (which is really, really not hard to do).
No program exists in a vacuum.
You seem to be advocating for an IDE-style environment, examples of which abound. Is that all this whole discussion is about?
I see what you mean. Lazarus look great, I might try teaching it to a friend!
EDIT: Any good small-ish project in GitHub to get a feel for the language?
EDIT: Any good small-ish project in GitHub to get a feel for the language?
"<CR><RET> is an implementation detail from an OS nobody has used for decades"
Yeah they're taking the piss. You can make the same argument about GUI tools too. We're gonna be dealing with "implementation details" for awhile lol. This thread is wild. Makes me understand why all the juniors I work with suck so much.
Yeah they're taking the piss. You can make the same argument about GUI tools too. We're gonna be dealing with "implementation details" for awhile lol. This thread is wild. Makes me understand why all the juniors I work with suck so much.
The server you submitted your comment to uses this 'OS nobody has used for decades'. The OS you wrote this from, also uses this implementation detail.
It most definitely does NOT use that OS. That is a ridiculous claim.
Every OS, Windows as well, uses the concept of search paths, namespaces, and environmental variables.
I think he's speaking about First Edition UNIX, and, yes, we don't use that operating system.
We just use operating systems which implement concepts derived from there.
So, technically correct, though the argument has little merit.
We just use operating systems which implement concepts derived from there.
So, technically correct, though the argument has little merit.
The point is, "/usr/local/bin" is an artifact that made sense on that system, and that system alone, but we started using it elsewhere, and not it is so firmly established we do not dare to change it, even though it is a completely arbitrary choice with no relevance to modern systems.
All environments for computer development need to manage some amount of abstraction to bootstrap that environment and get programs to run. In nixes, it's the bootloader, the kernel, and shell (with its ENV). When you issue the command `node` to a computer, what does that actually mean? Your Delphi setup probably just hid most of that abstraction from you, the way most people need not worry about the bootloader. But env is kind of unavoidable. It's like the Construct from the Matrix. The staging area for all other programs.
I have struggled a lot with the nitty-gritty of ENV over the past few years and I agree with you that maybe there is a better way. /etc/, Conda, virtualenv, docker, ROS, Windows registry, they all deal heavily with managing the environment, and all have their own thorns. Then you have kube, consul, ansible, and all the fun of distributed environments.
The bottom line is, if you want multiple, orthogonal runtimes, you need an abstraction for managing namespaces. PATH is actually one of the simplest mechanisms to achieve this.
I have struggled a lot with the nitty-gritty of ENV over the past few years and I agree with you that maybe there is a better way. /etc/, Conda, virtualenv, docker, ROS, Windows registry, they all deal heavily with managing the environment, and all have their own thorns. Then you have kube, consul, ansible, and all the fun of distributed environments.
The bottom line is, if you want multiple, orthogonal runtimes, you need an abstraction for managing namespaces. PATH is actually one of the simplest mechanisms to achieve this.
Yeah but they're bad cause they have to be.
I can't just wave my magic wand and eliminate Bash, and all $PATH nonsense.
It existed before.
So as a programmer, I expect you to know about it. There may be a day when the knowledge is obsolete. Where we can coordinate politically and socially enough to eliminate all usage of bash and $PATH. But those are social and political problems.
As a programmer, I expect you to have the technical knowledge necessary to do your job. Stop complaining about the social and political context that brought $PATH to existence and just know how to use it, and don't write something like it yourself.
Programming is not AWFUL. People and the social and political aspects of interacting with others is AWFUL and always will be. We work around it, we make it better, and we improve it. But no, our tools are not CRAP, they're not AWFUL. We build amazing, wonderful things with these tools.
What a short-sighted perspective. Just pass. Seriously.
I can't just wave my magic wand and eliminate Bash, and all $PATH nonsense.
It existed before.
So as a programmer, I expect you to know about it. There may be a day when the knowledge is obsolete. Where we can coordinate politically and socially enough to eliminate all usage of bash and $PATH. But those are social and political problems.
As a programmer, I expect you to have the technical knowledge necessary to do your job. Stop complaining about the social and political context that brought $PATH to existence and just know how to use it, and don't write something like it yourself.
Programming is not AWFUL. People and the social and political aspects of interacting with others is AWFUL and always will be. We work around it, we make it better, and we improve it. But no, our tools are not CRAP, they're not AWFUL. We build amazing, wonderful things with these tools.
What a short-sighted perspective. Just pass. Seriously.
I haven't seen anyone mention why $PATH is nonsense, and what a better system would be.
I'd say programming (at least modern programming) involves knowing one's environment and knowing how to get things done in relation to the actual code writing.
Also, using the search query "/usr/local/bin" in Google returns this[0] link first. This is my real issue. If a simple web search returns a good result first that gives you a good overview and gives you more background knowledge and more terms to search for and flesh out your knowledge, then there is little excuse to say learning is too hard. If you don't want to learn, that's fine, but complaining about learning being too hard here is unjust.
[0] https://unix.stackexchange.com/questions/4186/what-is-usr-lo...
Also, using the search query "/usr/local/bin" in Google returns this[0] link first. This is my real issue. If a simple web search returns a good result first that gives you a good overview and gives you more background knowledge and more terms to search for and flesh out your knowledge, then there is little excuse to say learning is too hard. If you don't want to learn, that's fine, but complaining about learning being too hard here is unjust.
[0] https://unix.stackexchange.com/questions/4186/what-is-usr-lo...
> /usr/local/bin is an implementation detail from an OS nobody has used for decades
Linux, MacOS, the BSDs... They're very much used today, not just decades ago. the /bin, /usr/bin and /usr/local/bin are very simple to understand after around 10 minutes of looking at the contents of / (root).
*/bin/ has binaries,
*/lib/ has libraries,
*/include/ has headers.
Its as simple as it gets, I dont see a way you could make a "better" system, other than maybe renaming "bin" to "binaries" for the 5 people on the planet with an irrational fear of common abbreviations.
Linux, MacOS, the BSDs... They're very much used today, not just decades ago. the /bin, /usr/bin and /usr/local/bin are very simple to understand after around 10 minutes of looking at the contents of / (root).
*/bin/ has binaries,
*/lib/ has libraries,
*/include/ has headers.
Its as simple as it gets, I dont see a way you could make a "better" system, other than maybe renaming "bin" to "binaries" for the 5 people on the planet with an irrational fear of common abbreviations.
And what is /usr/lib and /usb/bin then? Sure, they had meaning historically but today they're often just symlinks because we don't really need the distinction.
> Its as simple as it gets, I dont see a way you could make a "better" system
I do, we could stop separating binaries from the associated other files they require in order to work. That is an artifact of how UNIX was originally implemented that is irrelevant today. Case in point: the existence of containers, flatpak, AppImage, and other such things that do exactly that! Not to mention all the operating systems, like Windows and Mac, that always worked that way.
> Its as simple as it gets, I dont see a way you could make a "better" system
I do, we could stop separating binaries from the associated other files they require in order to work. That is an artifact of how UNIX was originally implemented that is irrelevant today. Case in point: the existence of containers, flatpak, AppImage, and other such things that do exactly that! Not to mention all the operating systems, like Windows and Mac, that always worked that way.
And what does "usr" mean?
User System Resources
That is not what it meant when it was created. Apparently some people have retroactively tried to change it mean that, but, that is just a complete nonsense phrase.
Right, as far as I understand it originally was just short for "user". It's where home directories of users were placed. Now that it's been relegated to storing user-usable programs & data it makes sense to me that it's separate from say /Users, but I suppose it could be aliased to something like /UserProgramsAndData for verboseness and clarity to newer users. But regardless, "User System Resources" is a fairly useful phrase, it's there to separate their system resources (programs & data) from their personal resources (which should be in their user directory).
But, a system _does_ have users. Those users _do_ have programs. There's a hierarchical relationship. I've been following along with your comments in this thread and I just don't follow what you're getting at here.
But, a system _does_ have users. Those users _do_ have programs. There's a hierarchical relationship. I've been following along with your comments in this thread and I just don't follow what you're getting at here.
If you designed this from scratch, is that the name you would naturally pick?
If the naming of the path is where you are hanging the crux of your argument about how "bad" things are, then you are not making a terribly convincing argument.
It is not. It is just one example out of a million of how things are weird and non-obvious for pointless reasons.
>/usr/local/bin is an implementation detail from an OS nobody has used for decades.
/usr/local/bin is where most Linux distros put binaries that were built locally, as opposed to those that came from the package manager...
Not to mention, if you don't understand how and where your binary is supposed to run, what on earth are you doing making it in the first place?
/usr/local/bin is where most Linux distros put binaries that were built locally, as opposed to those that came from the package manager...
Not to mention, if you don't understand how and where your binary is supposed to run, what on earth are you doing making it in the first place?
[deleted]
Every linux environment in the world is in disagreement with you.
[deleted]
While I'm not a low code fan, I would say please don't read Learn Python the Hard Way. https://sopython.com/wiki/LPTHW_Complaints
Rather than just criticise, can you please suggest a better alternative?
I am always looking for better tools and tutorials for the people I mentor, but LPTHW has been great, I have mentored 15 or so people so far from no coding to starting and running their own companies, and I have yet to find something better.
I am always looking for better tools and tutorials for the people I mentor, but LPTHW has been great, I have mentored 15 or so people so far from no coding to starting and running their own companies, and I have yet to find something better.
I take the "wtf is user/local/bin in $path?" to be a question from a non-tech person that is interested in learning to code. I can't be sure though since the author stated he has failed to install Node js.
Should Chrome have Node JS loaded into it during install? I don't do web-dev so my answer is no.
Should there be browsers made for those learning web-dev that come with these? By all means, sure. Go nuts.
This also might sound elitist but I would expect the kind of person that takes an interest in coding to be able to google what $PATH is or hell take the complete instruction "add <dir> to $PATH"
Should Chrome have Node JS loaded into it during install? I don't do web-dev so my answer is no.
Should there be browsers made for those learning web-dev that come with these? By all means, sure. Go nuts.
This also might sound elitist but I would expect the kind of person that takes an interest in coding to be able to google what $PATH is or hell take the complete instruction "add <dir> to $PATH"
My question is: why can’t the Node installer add /usr/local/bin to the path itself (if needed)? Why force me to do it? The Windows installer did it for me. I can just type `node` or `deno` into PowerShell and it loads up a REPL. I never had to add them to `PATH`.
It expects /usr/local/bin/ to be on the $PATH, and so it adds itself to that location.
It doesn't know if you purposely meant to remove it's install location from the PATH, so it doesn't re-add it.
It could do what you ask, but this requires setting the $PATH. The most common way to do so is modifying bashrc, but now you're modifying the user's bashrc. Now you ask, is the user using bash? Maybe you're using the fancy whiz-bang ohmyzsh since that's what Medium told you to do, and now that doesn't work either.
If you keep /usr/local/bin on your $PATH (which is standard in most 'nix installations) then you don't have to change anything or do anything. Why do _you_ have such an abnormal system? We can play this game all day and it's fucking miserable. Just learn how to use your tools for fuck's sake.
It doesn't know if you purposely meant to remove it's install location from the PATH, so it doesn't re-add it.
It could do what you ask, but this requires setting the $PATH. The most common way to do so is modifying bashrc, but now you're modifying the user's bashrc. Now you ask, is the user using bash? Maybe you're using the fancy whiz-bang ohmyzsh since that's what Medium told you to do, and now that doesn't work either.
If you keep /usr/local/bin on your $PATH (which is standard in most 'nix installations) then you don't have to change anything or do anything. Why do _you_ have such an abnormal system? We can play this game all day and it's fucking miserable. Just learn how to use your tools for fuck's sake.
On what platform doesn't it? I've installed node on Windows and various flavours of Linux and I've never needed to extend $PATH for it. Is this a mac thing?
node puts relevant binaries into /usr/local/bin because that's just how you do things. Whether or not that path is in $PATH is none of node's business, and if you (for whatever weird reason) work on a system where that's not the case, you probably wouldn't want the node installer to mess with that.
Note that the installer is not saying "please make sure /lib/node.js/ is in $PATH" - this would certainly be something to expect the node.js-specific installer to set up by itself.
Note that the installer is not saying "please make sure /lib/node.js/ is in $PATH" - this would certainly be something to expect the node.js-specific installer to set up by itself.
This was a real question FYI. I don't know what that means.
Googling "Making sure /usr/local/bin is in my $PATH" leads me here: https://stackoverflow.com/questions/19202007/making-sure-usr...
So I fire up the terminal and write echo $PATH and then go back to SO to see that it looks like it's all set up correctly. But why do I need to go to SO? Why do I need to fire up the terminal? It just feels too damn hard and too opaque.
I think defaults and documentation and onboarding matter. Not to mention a GUI :)
Googling "Making sure /usr/local/bin is in my $PATH" leads me here: https://stackoverflow.com/questions/19202007/making-sure-usr...
So I fire up the terminal and write echo $PATH and then go back to SO to see that it looks like it's all set up correctly. But why do I need to go to SO? Why do I need to fire up the terminal? It just feels too damn hard and too opaque.
I think defaults and documentation and onboarding matter. Not to mention a GUI :)
90% of your programming life is going to be spent iterating up and down a stack of "how do I...?", "what is...?" and "why does...?" type questions. If searching for a keyword and then reading the first hit is 'too damn hard and too opaque', that could be a sign that software development may not be your thing.
It's one of those basic things. Like, when someone says "Make sure you have salt in the kitchen" they say just that, not "Open the first cupboard in your kitchen. See if there is a blue tin with a little girl in a frock carrying an umbrella" and so on and so forth.
The "make sure X is in your $PATH" is its own thing. I sympathize but there is a balance between docs for the expert and docs for the novice. This is closer to the former.
The "make sure X is in your $PATH" is its own thing. I sympathize but there is a balance between docs for the expert and docs for the novice. This is closer to the former.
Also I'm fairly certain that an explanation of what $PATH is on unixlike OSes and how to manage that is one of the first things one will see when reading any number of dev basics/getting started tutorials. I understand wanting to jump right into writing "real" projects but things like this are why I think spending a little time finding well-written tutorials and doing them makes a big difference when picking up a new language/library/framework/etc.
There are install shields and tutorials for this. He's right, most tooling sucks and require arcane incantations. They do allow later flexibility though.
Steve Jobs if he was a programmer would slam today's tooling.
Steve Jobs if he was a programmer would slam today's tooling.
This is the most insane article and comments I've seen in a while.
It's programming. It's difficult, and there's a lot you need to know to be effective. Trying to just hide things like the command line is just pointless. You need to know it. Go learn it.
It's programming. It's difficult, and there's a lot you need to know to be effective. Trying to just hide things like the command line is just pointless. You need to know it. Go learn it.
Learning a new language is hard, whether it's a spoken language or, in this case, the incantations on command line.
Your comment to which I'm replying now shows that you do have the ability to learn this new language. You've correctly and successfully used the term "SO" to refer to a popular resource on programming. You have successfully "fired up the terminal." You've even used the terminal to echo $PATH. You're making great progress! :-)
The particular idea of installing node.js by default in web browsers seems to me like installing toasters on sofas. That would make it easier to make toast without going to the kitchen, but is not something that most people would want.
> why do I need to ______?
This is the current state of computers and programming. Computers are just concentrated piles of logic gates and they don't actually know what they are doing.
Your comment to which I'm replying now shows that you do have the ability to learn this new language. You've correctly and successfully used the term "SO" to refer to a popular resource on programming. You have successfully "fired up the terminal." You've even used the terminal to echo $PATH. You're making great progress! :-)
The particular idea of installing node.js by default in web browsers seems to me like installing toasters on sofas. That would make it easier to make toast without going to the kitchen, but is not something that most people would want.
> why do I need to ______?
This is the current state of computers and programming. Computers are just concentrated piles of logic gates and they don't actually know what they are doing.
> You've correctly and successfully used the term "SO" to refer to a popular resource on programming. You have successfully "fired up the terminal." You've even used the terminal to echo $PATH. You're making great progress
He's been a user of HN since 2010...
It seems he likes the idea of programming more than the act of it. It's similar to one being enrapt with the idea of being an accountant but in reality, just wanting TurboTax to do everything and not learning anything. But i get to play pretend that I'm an accountant.
And in terms of (free) knowledge availability on the internet for any one profession, there is nothing that comes anywhere close to programming.
He's been a user of HN since 2010...
It seems he likes the idea of programming more than the act of it. It's similar to one being enrapt with the idea of being an accountant but in reality, just wanting TurboTax to do everything and not learning anything. But i get to play pretend that I'm an accountant.
And in terms of (free) knowledge availability on the internet for any one profession, there is nothing that comes anywhere close to programming.
Why do I need to go to Stack Overflow? Being sympathetic I would say that because the Node JS Installer makes the assumption that you know what the PATH environment variable is and you know how directories work.
Why do I need to fire up the terminal? Your OS doesn't do things via GUI like you do, so you need to validate that what it needs is available in the manner it will use.
Too damn hard and too opaque.? How did you learn that Node js was even a thing? You weren't born with the knowledge and everything has a learning curve to it, very few things are truly easy to do starting at the very bottom.
I agree that things need documentation and onboarding. I think we can view the Node js docs similar to a shop manual at a auto repair shop - it will expect you to know what tools are what and how to do certain things.
Why do I need to fire up the terminal? Your OS doesn't do things via GUI like you do, so you need to validate that what it needs is available in the manner it will use.
Too damn hard and too opaque.? How did you learn that Node js was even a thing? You weren't born with the knowledge and everything has a learning curve to it, very few things are truly easy to do starting at the very bottom.
I agree that things need documentation and onboarding. I think we can view the Node js docs similar to a shop manual at a auto repair shop - it will expect you to know what tools are what and how to do certain things.
Looking up stackoverflow is harder than learning a programming language?
Windows has a perfectly good GUI to edit your PATH variable if you need one. Most installers also add their tools to that same PATH, so on Windows this is all pretty easy to accomplish. The problem is, if you don't know what environment variables are, the GUI won't be of any use to you.
You shouldn't need one though. Environment variables are one of the core basics of any program, and you'll need to learn about them eventually. The same thing is true if you can't deal with the terminal; there's a few "magic" commands to learn but most of the terminal stuff is just "how does this computer thing even work".
Most programming tools and languages, as well as their documentation, assume you know how to manage your computer when you start programming them, as well as some basic knowledge of how an operating system works. These tools and their getting started guides are written for people who know the basics of their computer and programming, and want to try out a new language like JS. If they're too technical for you, you're not the target audience. You'd get much more out of a book explaining you the basics step by step.
The terminal is everything but opaque; you tell the computer exactly what you want rather than clicking the "just make it work" button. You're in control instead of letting some tool assume what's best for you. In my experience, the "one button to fix all" systems will work for a while but once they break (and they will) they're basically unrepairable without deep knowledge of the tooling and its configuration as well as the defaults the installer chose for you and why they're now messing up.
A problem with Javascript and Python development is that the setup is very complex and that guides become outdated (especially for web dev). There's loads of edge cases to deal with so there's loads of configurations and options most tooling supports. The magic install button would lead many to ruin their operating system configuration because they've already installed another tool that might also have had a magic install button. These tools don't operate in a vacuum, they influence each other.
If you just want to program code, grab a great big IDE like MS Visual Studio on Windows (the full one, not Code) or XCode on Mac (no experience there, but it's trivial to install at least). The experience of getting started programming in C# is very easy, just select the types of program you want to be able to make (or "all" if you don't care) during setup and your tool is set up. No fiddling with the command line, just a shortcut on your desktop. You won't be making any websites in them from the start, but they'll provide you with an environment that Just Works for writing your first program, moet likely a console window that says "hello world".
If you want to get started in web dev, you don't need node or any terminal work, just a good text editor to write your own HTML, CSS and JS files in. Sure, node is what people use in production, but it's only complicating things if you're just getting started. Guides from ten years ago on how to write HTML and Javascript are still perfectly functional if you're just starting out.
If that's still to much to grasp, there's kits out there for Raspberry Pis that come prepackaged with tutorials and with exercise books for programming in scratch and Python. Your only barrier to entry there is the money to buy the kit. You'll still have to learn everything and work through stackoverflow or technical documentation all the time, but you won't need to bother with any terminals at least.
Complaining that programming is too hard because there's no fancy GUI for every tool is like me complaining that finances are too hard because I can't walk into a bank and start making money without reading all kinds of boring books about finances. There's easy ways to get started if you know where to look, but in the end you'll always need some knowledge about the field you're entering to get started without paying someone to teach you directly.
You shouldn't need one though. Environment variables are one of the core basics of any program, and you'll need to learn about them eventually. The same thing is true if you can't deal with the terminal; there's a few "magic" commands to learn but most of the terminal stuff is just "how does this computer thing even work".
Most programming tools and languages, as well as their documentation, assume you know how to manage your computer when you start programming them, as well as some basic knowledge of how an operating system works. These tools and their getting started guides are written for people who know the basics of their computer and programming, and want to try out a new language like JS. If they're too technical for you, you're not the target audience. You'd get much more out of a book explaining you the basics step by step.
The terminal is everything but opaque; you tell the computer exactly what you want rather than clicking the "just make it work" button. You're in control instead of letting some tool assume what's best for you. In my experience, the "one button to fix all" systems will work for a while but once they break (and they will) they're basically unrepairable without deep knowledge of the tooling and its configuration as well as the defaults the installer chose for you and why they're now messing up.
A problem with Javascript and Python development is that the setup is very complex and that guides become outdated (especially for web dev). There's loads of edge cases to deal with so there's loads of configurations and options most tooling supports. The magic install button would lead many to ruin their operating system configuration because they've already installed another tool that might also have had a magic install button. These tools don't operate in a vacuum, they influence each other.
If you just want to program code, grab a great big IDE like MS Visual Studio on Windows (the full one, not Code) or XCode on Mac (no experience there, but it's trivial to install at least). The experience of getting started programming in C# is very easy, just select the types of program you want to be able to make (or "all" if you don't care) during setup and your tool is set up. No fiddling with the command line, just a shortcut on your desktop. You won't be making any websites in them from the start, but they'll provide you with an environment that Just Works for writing your first program, moet likely a console window that says "hello world".
If you want to get started in web dev, you don't need node or any terminal work, just a good text editor to write your own HTML, CSS and JS files in. Sure, node is what people use in production, but it's only complicating things if you're just getting started. Guides from ten years ago on how to write HTML and Javascript are still perfectly functional if you're just starting out.
If that's still to much to grasp, there's kits out there for Raspberry Pis that come prepackaged with tutorials and with exercise books for programming in scratch and Python. Your only barrier to entry there is the money to buy the kit. You'll still have to learn everything and work through stackoverflow or technical documentation all the time, but you won't need to bother with any terminals at least.
Complaining that programming is too hard because there's no fancy GUI for every tool is like me complaining that finances are too hard because I can't walk into a bank and start making money without reading all kinds of boring books about finances. There's easy ways to get started if you know where to look, but in the end you'll always need some knowledge about the field you're entering to get started without paying someone to teach you directly.
The author is right when he says "coding is still too damn hard for beginners." That's because he's been led to believe he needs to install Node to join the "code club." Contemporary professional web development (as practiced by members of "the code club") is madness. We owe it to beginners to show there are easy, practical, sensible ways to get started. He needs to look at tutorials that show how to write code with just a text editor and browser. I've written some about going Stackless [0]; we need more.
[0] https://tutorials.yax.com/
[0] https://tutorials.yax.com/
> Contemporary professional web development (as practiced by members of "the code club") is madness
In what way is it madness?
In what way is it madness?
For beginners who've started with HTML, React or Rails is a huge cliff to climb. Yet that is the expectation we've set as professional web developers, when in fact we're often over-engineering our projects. There's no need for build tools in development when we can use module CDNs. There's no need for frameworks in many use cases (unless you need state management but that's not for beginners anyway).
> For beginners who've started with HTML, React or Rails is a huge cliff to climb
These are highly orthogonal concerns. html is markup, React and Rails are client/server side ways of generating that markup.
> Yet that is the expectation we've set as professional web developers
This is so weird to read. Like yes, obviously it's an expectation that you need to know a way of generating html if you want to have any more than just a static page.
> There's no need for build tools in development when we can use module CDNs
Sure, if you want to write plain JS. But that means no Typescript. No tree shaking, or lazy load importing, so your application is going to be big, and slow. No code transpiling to backfill support for older browsers.
These are highly orthogonal concerns. html is markup, React and Rails are client/server side ways of generating that markup.
> Yet that is the expectation we've set as professional web developers
This is so weird to read. Like yes, obviously it's an expectation that you need to know a way of generating html if you want to have any more than just a static page.
> There's no need for build tools in development when we can use module CDNs
Sure, if you want to write plain JS. But that means no Typescript. No tree shaking, or lazy load importing, so your application is going to be big, and slow. No code transpiling to backfill support for older browsers.
We're talking about beginners. Presumably they start with HTML and then ask what they should learn next. Let's save the madness of Typescript and tree shaking until after they've achieved some initial wins. Let's start with algebra before calculus. Right now it's too much like times tables and then Fourier transforms.
Lol the demonization of Typescript continues...
Take a look into your node_modules folder.
Agreed. Notepad for the win!
It doesn't have to be Notepad. But it's important to communicate to beginners that they can actually get far without build tools or frameworks. Go stackless. Use the platform.
Couldn't agree more. Actually, even non beginners should be reminded of that, sometimes.
> So I can write code inside my spreadsheet, but not inside my browser? WTF.
You can, press F12.
> Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
Why? If you’re new to coding then you don’t need an IDE: it adds complexity. You just need a “Run” button like in Excel (right?).
Additionally, you probably don’t need Node.js because it is just adding some API to interact with the operating system.
If you use said APIs then you need to learn a couple of things about the O.S. - nothing major - like what is a shell, or what mkdir and PATH stands for.
But, hey, we’re talking about non-coders here right? They don’t need these APIs, they are just getting started. So why should they need Node.js?
> People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. This is why people would rather code inside a spreadsheet application - because it’s an application.
I’m all in for the no-code movement, although I’m not the target audience. I agree that you don’t need to know how to code to setup a simple website. You can just use Webflow.
I think this article doesn’t make much sense. Every paragraph of the article (especially the outro) suggests that Node.js is not an example, it’s the target of the article. The fact that the OP is proposing to run Node.js on the browser suggests that they doesn’t know what Node is, and why you should use it.
Your code will run fine on the browser and on Node as long as you don’t use Node APIs.
Once you use such APIs, you’re agreeing to the fact that you know what you’re a doing - you agreed to use Node’s API; if you didn’t want to deal with the OS directly, then should have opted for something like Visual Basic. And if you agree to use such APIs then you know that Node exists so that you can forget about the browser.
You can, press F12.
> Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
Why? If you’re new to coding then you don’t need an IDE: it adds complexity. You just need a “Run” button like in Excel (right?).
Additionally, you probably don’t need Node.js because it is just adding some API to interact with the operating system.
If you use said APIs then you need to learn a couple of things about the O.S. - nothing major - like what is a shell, or what mkdir and PATH stands for.
But, hey, we’re talking about non-coders here right? They don’t need these APIs, they are just getting started. So why should they need Node.js?
> People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. This is why people would rather code inside a spreadsheet application - because it’s an application.
I’m all in for the no-code movement, although I’m not the target audience. I agree that you don’t need to know how to code to setup a simple website. You can just use Webflow.
I think this article doesn’t make much sense. Every paragraph of the article (especially the outro) suggests that Node.js is not an example, it’s the target of the article. The fact that the OP is proposing to run Node.js on the browser suggests that they doesn’t know what Node is, and why you should use it.
Your code will run fine on the browser and on Node as long as you don’t use Node APIs.
Once you use such APIs, you’re agreeing to the fact that you know what you’re a doing - you agreed to use Node’s API; if you didn’t want to deal with the OS directly, then should have opted for something like Visual Basic. And if you agree to use such APIs then you know that Node exists so that you can forget about the browser.
A lot of you guys are hating on the author for not being able to figure out how to install Nodejs.
Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.
Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding. And just about any PC has what you need. [1]
Nowadays you can technically develop on any PC with a browser by locally editing HTML / JS / CSS using Notepad, but it's rather painful. How hard would be to have a default Firefox environment for budding coders? These days you can probably do some Wasm magic to create an entire Linux OS in a browser tab, and install stuff in a virtual disk in the local storage.
Heck, it probably wouldn't be that hard to cobble together the existing pieces to make a Firefox addon to do that.
[1] Granted BBC Micro and TRS-80 weren't PC architectures, but for computers of that generation, a built-in BASIC interpreter was pretty much expected.
Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.
Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding. And just about any PC has what you need. [1]
Nowadays you can technically develop on any PC with a browser by locally editing HTML / JS / CSS using Notepad, but it's rather painful. How hard would be to have a default Firefox environment for budding coders? These days you can probably do some Wasm magic to create an entire Linux OS in a browser tab, and install stuff in a virtual disk in the local storage.
Heck, it probably wouldn't be that hard to cobble together the existing pieces to make a Firefox addon to do that.
[1] Granted BBC Micro and TRS-80 weren't PC architectures, but for computers of that generation, a built-in BASIC interpreter was pretty much expected.
That pretty much exists though. That's why Raspberry PI was invented and at the cost of $25 + a keyboard and mouse for the base model.
If you want to pick up programming as a hobby, a hobby computer exists. If you want to get more serious eventually you have to learn your tools.
If you want to pick up programming as a hobby, a hobby computer exists. If you want to get more serious eventually you have to learn your tools.
Raspberry is a far cry from ben upton desired goal, this is not a matter of price, it is a matter of a full environment geared toward learning.
> Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding. And just about any PC has
You can get there today with some closed loop envirinments. But like wit QBasic and other Basics, there is very little commercially useful programming you can do there, unless it is an in-house application. See e.g. FileMaker Pro. Production grade web application programming is an order of magnitude more complicate than it was in 80s. Networking, client/server, graphical UI, responsive UI, dependencies with third party packages, multi user and multi tenancy come in my mind for example.
You can get there today with some closed loop envirinments. But like wit QBasic and other Basics, there is very little commercially useful programming you can do there, unless it is an in-house application. See e.g. FileMaker Pro. Production grade web application programming is an order of magnitude more complicate than it was in 80s. Networking, client/server, graphical UI, responsive UI, dependencies with third party packages, multi user and multi tenancy come in my mind for example.
> These days you can probably do some Wasm magic to create an entire Linux OS in a browser tab, and install stuff in a virtual disk in the local storage.
That just sounds mindblowingly inefficient and pointless. There's no point making these great speed and efficiency leaps in CPUs if people just do inane stuff like this.
The browser is fine as it is. If you want to use it as an IDE, use something like codespaces or any of the online REPLs, don't try to make the browser an IDE?!
That just sounds mindblowingly inefficient and pointless. There's no point making these great speed and efficiency leaps in CPUs if people just do inane stuff like this.
The browser is fine as it is. If you want to use it as an IDE, use something like codespaces or any of the online REPLs, don't try to make the browser an IDE?!
But QBasic etc. were just basic text editor with a "run" option.
They didn't have many fancy IDE features. You didn't even have syntax highlighting most of the time.
I don't think editing a html file locally is more painful than figuring out those tools back then.
I would even argue that's a good place to start because a full blown IDE can also be really intimidating if you don't really know whats happening.
I seem to remember Microsoft removing qbasic from normal machines at some point in the 90s, either way it wasn't much use after windows 95 came out.
Visual Basic was essential in th e90s if you wanted to create a gui app, but it was a £500 piece of software you had to buy and install on top of windows.
Now sure, if you installed a standard linux desktop in the 90s you'd have things like gcc, perl etc built in, but you do today.
Nowadays you don't need a compiler for a lot of things, your interpreter is your browser which everyone has, you can just start up your text editor and create a html/js/css page, just like you could on your BBC Micro or Dos 5 machine and start creating a program by copying things out of a magazine. The standard debugging built into firefox and chromium is amazing compared to what you had with QBasic or the Spectrum 48k.
You've also got a realm of information on the internet available on how to start. If you do want to download something like Atom or VSCode it's three clicks away (literally you type "vscode" into ddg, click the first link, then click the deb)
If you want to program something even simpler from entirely in your browser you can pop over to Scratch or Purple Mash and build a game from the browser.
Visual Basic was essential in th e90s if you wanted to create a gui app, but it was a £500 piece of software you had to buy and install on top of windows.
Now sure, if you installed a standard linux desktop in the 90s you'd have things like gcc, perl etc built in, but you do today.
Nowadays you don't need a compiler for a lot of things, your interpreter is your browser which everyone has, you can just start up your text editor and create a html/js/css page, just like you could on your BBC Micro or Dos 5 machine and start creating a program by copying things out of a magazine. The standard debugging built into firefox and chromium is amazing compared to what you had with QBasic or the Spectrum 48k.
You've also got a realm of information on the internet available on how to start. If you do want to download something like Atom or VSCode it's three clicks away (literally you type "vscode" into ddg, click the first link, then click the deb)
If you want to program something even simpler from entirely in your browser you can pop over to Scratch or Purple Mash and build a game from the browser.
> How hard would be to have a default Firefox environment for budding coders?
Before the times of Firefox, Mozilla (the browser, not the company) actually did have something like that: Mozilla Composer[0]. Granted, it was a WYSIWYG editor and today no one writes entire websites that way anymore. But it still allowed basically anyone to start their own website – an idea which I still find very appealing as it's so close to Tim Berners-Lee's vision of a web where everyone is both a consumer and a producer. (Whether or not this vision was ever realistic is a different matter.)
[0]: https://en.wikipedia.org/wiki/Mozilla_Composer
Before the times of Firefox, Mozilla (the browser, not the company) actually did have something like that: Mozilla Composer[0]. Granted, it was a WYSIWYG editor and today no one writes entire websites that way anymore. But it still allowed basically anyone to start their own website – an idea which I still find very appealing as it's so close to Tim Berners-Lee's vision of a web where everyone is both a consumer and a producer. (Whether or not this vision was ever realistic is a different matter.)
[0]: https://en.wikipedia.org/wiki/Mozilla_Composer
"A lot of you guys are hating on the author for not being able to figure out how to install Nodejs."
Nope. That's not what they're criticising.
"Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.
Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding."
Bash is 5000x more powerful and user-friendly programming environment than any version of rom BASIC ever was.
qbasic... well guess what? qbasic was not necessarily just there. It might be there. You have to type the command at a command line, and if it doesn't work, you have to investigate %PATH%
Bash kills basic hands down, as a programming language mind you, using only it's built-in features, forget the fact that it's also a wrapper around exec(), and it is right there exactly like the the old rom basics were.
Nope. That's not what they're criticising.
"Yet if you're old enough to have gotten started in the time of JavaScript in the late '90s, or QBasic in the early '90s, or systems like the BBC Micro or TRS-80 in earlier decades, you should know what the author's talking about.
Everything you need to program is just there. It just works, there's no extra installation, you start a program and start coding."
Bash is 5000x more powerful and user-friendly programming environment than any version of rom BASIC ever was.
qbasic... well guess what? qbasic was not necessarily just there. It might be there. You have to type the command at a command line, and if it doesn't work, you have to investigate %PATH%
Bash kills basic hands down, as a programming language mind you, using only it's built-in features, forget the fact that it's also a wrapper around exec(), and it is right there exactly like the the old rom basics were.
How can I easily draw pixel with Bash? Easily inspect and modify the whole memory with it?
There should be an "educational" mode on every computer where you can just boot into it.
There should be an "educational" mode on every computer where you can just boot into it.
How can I easily make a tcp connection with basic?
>Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
https://glitch.com/
https://runkit.com/home
https://codepen.io/
https://github.com/features/codespaces
Maybe you don't need new browser ?
Maybe ?
https://glitch.com/
https://runkit.com/home
https://codepen.io/
https://github.com/features/codespaces
Maybe you don't need new browser ?
Maybe ?
Also worth mentioning https://codesandbox.io/ especially for those familiar with VSCode.
Yeah I love Replit and Glitch (not used the others) but I still think there's something missing. They don't feel like standards that are easy and simple to use. Two more points:
https://twitter.com/tomcritchlow/status/1349839954558427136
https://twitter.com/tomcritchlow/status/1349839954558427136
> 1) offer native local speed - Glitch and Replit can still feel a bit slow on continual page refresh. 2) having your development files available locally - so that it's easy to take those files and upload to netlify etc or even edit using another app.
The solution to this is to use an actual native IDE, not try to shoehorn it into the browser, which is completely inappropriate.
The solution to this is to use an actual native IDE, not try to shoehorn it into the browser, which is completely inappropriate.
I believe node itself s just an environment/blank canvas as well. What is this "standards" you're looking for? There are a million frameworks, templates, etc as well.
A lot of dunking of the "git gud" variety going on here, but the author has a solid point. Requiring a novice to learn arcana of a 30 year old Unix system before they can learn to program is purely extraneous.
We could package programming languages up with GUI installers that set everything up correctly and let you get right to the code - and in fact, we used to. If you install IntelliJ, you'll have a fully-working Java environment out of the box. The same for Visual Studio.
Why the "hacker mentality" languages think this sort of user-obsession is beneath them, well, that escapes me...
We could package programming languages up with GUI installers that set everything up correctly and let you get right to the code - and in fact, we used to. If you install IntelliJ, you'll have a fully-working Java environment out of the box. The same for Visual Studio.
Why the "hacker mentality" languages think this sort of user-obsession is beneath them, well, that escapes me...
> Requiring a novice to learn arcana of a 30 year old Unix system before they can learn to program is purely extraneous.
The thing is, that's the system they are using. Node.js is a programming runtime for that system. Node.js has a GUI installer that sets everything up correctly, it's just not an IDE.
Jetbrains has an IDE, WebStorm, that probably works just as well as the Java one. It can automatically download Node.js for you, so the same experience as for Java is available there as well.
The thing is, that's the system they are using. Node.js is a programming runtime for that system. Node.js has a GUI installer that sets everything up correctly, it's just not an IDE.
Jetbrains has an IDE, WebStorm, that probably works just as well as the Java one. It can automatically download Node.js for you, so the same experience as for Java is available there as well.
Sure, but when I visit nodejs.org there is a very prominent "Download" button, and no mention at all that I might have an easier time with WebStorm (or another such fully-integrated development package). No links to introductory materials either, I might add.
Those would be fairly trivial changes to the website landing page, but they could drastically reduce the steepness of the on-ramp.
By contrast, if I visit python.org, there is a clear funnel leading me to alternative development environments, beginner tutorials, etc.
Those would be fairly trivial changes to the website landing page, but they could drastically reduce the steepness of the on-ramp.
By contrast, if I visit python.org, there is a clear funnel leading me to alternative development environments, beginner tutorials, etc.
Apples to oranges. Python is a language and Node is a runtime.
Compare with https://www.javascript.com/
Compare with https://www.javascript.com/
This. I've been writing code for years, but every time I pull a repo of the latest web app it turns into a series of frustratingly complicated learning exercises. I'm 17 all over again...
npm? got it. whoop. yarn? okay cool nope. bower, now? wow. all set.. no. webpack. done. wait. gulp? okay okay. are we there yet?
npm? got it. whoop. yarn? okay cool nope. bower, now? wow. all set.. no. webpack. done. wait. gulp? okay okay. are we there yet?
What arcana? Windows is not Unix and it uses PATH variable too. On most Linux distros you can simply run the equivalent to `sudo apt-get install nodejs` (or use a graphical front-end, if that's too hard for you) and everything will just work.
Just as an aside, GUI installers are an absolute cancer. I don't mind if there is an option to do that, but I just wish I could make a simple script for installing all the necessary programs on Windows, just like I can on Linux. But no, I have to spend two days doing nothing but manually clicking through the installers, because that's fun.
Just as an aside, GUI installers are an absolute cancer. I don't mind if there is an option to do that, but I just wish I could make a simple script for installing all the necessary programs on Windows, just like I can on Linux. But no, I have to spend two days doing nothing but manually clicking through the installers, because that's fun.
> What arcana? Windows is not Unix and it uses PATH variable too.
That's a whole additional world of arcana, since the Windows PATH variable works subtly differently, and is configured through a (fairly obtuse) GUI in an unrelated settings panel.
> On most Linux distros you can simply run the equivalent to `sudo apt-get install nodejs`
The OP is however on a Mac, where there isn't a default package manager. Now suddenly novices have to go learn about the differences between Homebrew vs MacPorts, and why neither one works properly on their shiny new MacBook.
> Just as an aside, GUI installers are an absolute cancer
For us linux sysadmins? Sure. For the rest of the world GUI installers are just how computers work.
That's a whole additional world of arcana, since the Windows PATH variable works subtly differently, and is configured through a (fairly obtuse) GUI in an unrelated settings panel.
> On most Linux distros you can simply run the equivalent to `sudo apt-get install nodejs`
The OP is however on a Mac, where there isn't a default package manager. Now suddenly novices have to go learn about the differences between Homebrew vs MacPorts, and why neither one works properly on their shiny new MacBook.
> Just as an aside, GUI installers are an absolute cancer
For us linux sysadmins? Sure. For the rest of the world GUI installers are just how computers work.
You can for the most part (I've done exactly that for the dependencies of a windows-developed system). Almost all installers support an unattended or 'silent' installation mode through a command line switch, though it can be a bit of a pain to get them to work the way you want.
On windows, you can automate the installs of software that comes as `msi` files, by the way - kind of obscure, but its how you can easily do that.
The problem is that without understanding the "arcana" of the OS platform you're using, you'll quickly hit a brick wall with your IDE. You won't understand what the configuration options mean, you won't understand what the documentation or people on StackOverflow want you to do and why. IDEs are mostly an abstraction over a set of CLI tools; if you try to do anything nontrivial, you'll see where the abstraction leaks.
This is true of quite a few of the kludgy build-an-IDE-out-of-plugins environments popular in the open-source world (Atom, VS Code, Vim-as-IDE, etc), but that's precisely the problem I'm getting at.
It doesn't tend to be true of mature IDE-first environments (see the aforementioned Visual Studio or IntelliJ).
It doesn't tend to be true of mature IDE-first environments (see the aforementioned Visual Studio or IntelliJ).
I'm talking strictly about mature IDE-first environments. Visual Studio (which I use daily for C++ development), IntelliJ (which I used for Java some time ago) and AndroidStudio (i.e. IntelliJ with plugins, and it's probably the most leaky abstraction of an IDE I've ever seen).
The author isn't wrong about the entry barrier into programming. However, they are wrong about almost everything else; 'Node in a browser', as the author uses it, is just a string of half-understood terms thrown together. Ironically, the inaccessibility of programming is probably at least partly to blame for their confusion.
There is undoubtedly work to be done into making programming more accessible to newcomers - almost all tutorials on code start in the wrong place, assuming a lot of knowledge of the difficult bits but then labouring through the easy ones.
I don't think the problem is tooling, but how we introduce and talk about those tools - you can quickly explain the command line in a way that takes the fear away and gives learners a framework for understanding it, but you have to give that explantion; too often it's skipped over.
There is undoubtedly work to be done into making programming more accessible to newcomers - almost all tutorials on code start in the wrong place, assuming a lot of knowledge of the difficult bits but then labouring through the easy ones.
I don't think the problem is tooling, but how we introduce and talk about those tools - you can quickly explain the command line in a way that takes the fear away and gives learners a framework for understanding it, but you have to give that explantion; too often it's skipped over.
>Why can't I write code inside my browser?
um... because you didn't press ctrl-shift-I?
But frankly, if you can't manage to install ruby and think $PATH is somehow complicated or scary, I don't want you writing code. So maybe it's for the best that you haven't discovered the developer tools built into every browser.
um... because you didn't press ctrl-shift-I?
But frankly, if you can't manage to install ruby and think $PATH is somehow complicated or scary, I don't want you writing code. So maybe it's for the best that you haven't discovered the developer tools built into every browser.
That or greasemonkey scripts. Though sometimes I read their source and it makes me feel better about my job security.
$PATH is complicated and scary for most beginners, just as math can be scary for many kids, especially if they don't have a good teacher. Do we say we don't want kids learning math? No, we need to be better teachers. There are so many people with great ambitions and ideas who just need good guidance. Let's help them, not dismiss them.
>Do we say we don't want kids learning math?
No, but I also don't want them being paid for their efforts to prove the Riemann hypothesis using only an abacus.
>we need to be better teachers
According to google there are about 1,040,000 results for 'what is "$PATH"?'. I feel like one or more of those is probably a pretty good resource.
No, but I also don't want them being paid for their efforts to prove the Riemann hypothesis using only an abacus.
>we need to be better teachers
According to google there are about 1,040,000 results for 'what is "$PATH"?'. I feel like one or more of those is probably a pretty good resource.
I’m a programmer but I still to Google how to edit the PATH in Windows. This is not a matter of teaching, it’s a matter of laziness. Open Google and figure it out. This is not math. You don’t need to understand why. You follow the tutorial and go on with your life. You’ll understand why PATH matters when you’ll need to. And before you reply with: then why not abstracting this stuff? That’s because most technical people don’t mind, and they know that defaults don’t always apply. Just like accounting software doesn’t explain every single acronym. It targets a different audience.
What's with the vitriol? The person who wrote this is active in the current thread.
The vitriol, if any, comes from eventually having to use products created by programmers without a shred of curiosity, expect everything handed to them, and do the bare minimum to create a semblance of working products. How many times have you used a website/app and it works so bad that you want to hit the programmer who wrote it? Frankly, “why do I need to figure out what PATH means” is shockingly non-curious even among those.
Exactly this. It's frustrating reading this article and the author's comments in this thread as it's apparent that they don't want to put the smallest amount of effort into learning something that is by its nature complicated.
They don't want to have to google what $PATH does, they want the browser to come with an IDE (and massively ramping up its complexity because why?) instead of actually downloading an IDE.
The author has weirdly treated the problem of not knowing something as that it is wrong that they need to know it.
They don't want to have to google what $PATH does, they want the browser to come with an IDE (and massively ramping up its complexity because why?) instead of actually downloading an IDE.
The author has weirdly treated the problem of not knowing something as that it is wrong that they need to know it.
> The author has weirdly treated the problem of not knowing something as that it is wrong that they need to know it.
Yes, that’s TFA in a nutshell.
The title is deceptively “normal” though, so lots of people are making good faith attempts at answering the question. Except cloud9, code-server or whatever aren’t what TFA asks for, since you still need to understand what’s going on in the server to use them effectively, you’re only offloading storage and computations to a remote machine.
Yes, that’s TFA in a nutshell.
The title is deceptively “normal” though, so lots of people are making good faith attempts at answering the question. Except cloud9, code-server or whatever aren’t what TFA asks for, since you still need to understand what’s going on in the server to use them effectively, you’re only offloading storage and computations to a remote machine.
It could also come from having spent thousands of hours dealing with issues created by this type of person.
There's nothing wrong with being new to coding, not knowing things, and making mistakes - it's how we learn - but when you start your article with list of things that you couldn't be bothered to do a web search for, proudly proclaiming your ignorance and unwillingness to learn and expecting me to do your thinking for you, I don't have much interest in being nice and/or trying to teach you stuff.
There's nothing wrong with being new to coding, not knowing things, and making mistakes - it's how we learn - but when you start your article with list of things that you couldn't be bothered to do a web search for, proudly proclaiming your ignorance and unwillingness to learn and expecting me to do your thinking for you, I don't have much interest in being nice and/or trying to teach you stuff.
Yes, there’s substantial overlap between this group and the group who create “does not work (EOM)” issues I expressed immense frustration over the other day: https://news.ycombinator.com/item?id=25758884
This is not an excuse for being a dick.
I know right. The person who posted this article should have hit up a search engine before wasting all of our time. Very dickish behaviour.
Truly fantastic dialogue
You can though. Chrome dev tools can edit local files. It's basically an IDE. You can easily build a single page application. You can even do some server-like stuff purely in the browser now with service workers. There are also plenty of online IDEs available spanning the gamut from toys to serious work environments.
>Chrome dev tools can edit local files.
For anyone that doesn't know that, open dev tools > Sources > Filesystem > + (Add folder to workspace) > right-click on folder > New file. Then double-click on file to open it for editing and save modifications with Ctrl-S. Of course it isn't an IDE, with even the editor being nothing more than a Notepad clone, and you're limited to client-side work which is in contrast to what OP seems to want.
For anyone that doesn't know that, open dev tools > Sources > Filesystem > + (Add folder to workspace) > right-click on folder > New file. Then double-click on file to open it for editing and save modifications with Ctrl-S. Of course it isn't an IDE, with even the editor being nothing more than a Notepad clone, and you're limited to client-side work which is in contrast to what OP seems to want.
Meh... The author might be pushing it a bit, but s/he has a point.
Recently, after a few days of trying to set up Scala to work with the latest JVM in Visual Studio Code I just gave up and installed IntelliJ IDEA instead. Works out of the box.
I'm a seasoned programmer with 15 years of experience in Python, Java, Scala, OCaml, C++, JavaScript, Linux, bash, ... (a.k.a. I can do or learn pretty much everything). Could I set up VS Code to work with Scala? Yeah, probably. But why would I bother?
UI matters. Programmers mostly suck at UI. Which is reasonable, really, because after you set it up once, you can easily forget about it...
Recently, after a few days of trying to set up Scala to work with the latest JVM in Visual Studio Code I just gave up and installed IntelliJ IDEA instead. Works out of the box.
I'm a seasoned programmer with 15 years of experience in Python, Java, Scala, OCaml, C++, JavaScript, Linux, bash, ... (a.k.a. I can do or learn pretty much everything). Could I set up VS Code to work with Scala? Yeah, probably. But why would I bother?
UI matters. Programmers mostly suck at UI. Which is reasonable, really, because after you set it up once, you can easily forget about it...
The hostility coming off of these comments is pretty off-putting. I share some of the sentiments and believe that the authro has some misconceptions.
But I also believe that he makes a lot of great points. Installing and maintaining programming languages is too hard. Going from "I would like to try some $lang" to being up and running is usually difficult and requires you to install binaries, then deal with PATHs, and with CLIs, and REPLs and a bunch of cruft before you can start experimenting and getting to the interesting parts.
The programming language experience comes with a shitoad of stuff that really has very little to do with the language itself.
There is also a lot of potential in more flexible tools that allow me to create small apps with, well, maybe not with minimal coding, but with minimal installations, minimal integrations in my particular OS, minimal maintenance of the installed binaries and tools etc.
But I also believe that he makes a lot of great points. Installing and maintaining programming languages is too hard. Going from "I would like to try some $lang" to being up and running is usually difficult and requires you to install binaries, then deal with PATHs, and with CLIs, and REPLs and a bunch of cruft before you can start experimenting and getting to the interesting parts.
The programming language experience comes with a shitoad of stuff that really has very little to do with the language itself.
There is also a lot of potential in more flexible tools that allow me to create small apps with, well, maybe not with minimal coding, but with minimal installations, minimal integrations in my particular OS, minimal maintenance of the installed binaries and tools etc.
Exactly. My favourite programming experience so far has been Visual Studio. Setting it up is done in one installer that guides you through the process, and after that it just works.
I think a lot of people here forget that people who program no longer need to be "programmers", and understand every aspect of the system. For these people who just want to simulate a model, or do some calculations, or automate a mundane task. For them programming is a means to an end, it's about the result.
I think a lot of people here forget that people who program no longer need to be "programmers", and understand every aspect of the system. For these people who just want to simulate a model, or do some calculations, or automate a mundane task. For them programming is a means to an end, it's about the result.
Chrome includes (almost) a fully functional IDE. If you dig around, you can bind Chrome's Javascript debugger to files on disk. You can also interactively tweak the CSS that's rendered and then copy and paste it back to your sources.
But, I don't see why this guy thinks installing NodeJS is hard. I have a low tolerance for painful installs, but NodeJS and Visual Studio Code were quite easy for me to install and pick up.
Furthermore, you can code in a browser: Azure supports this, although it was somewhat buggy when I tried it.
But, I don't see why this guy thinks installing NodeJS is hard. I have a low tolerance for painful installs, but NodeJS and Visual Studio Code were quite easy for me to install and pick up.
Furthermore, you can code in a browser: Azure supports this, although it was somewhat buggy when I tried it.
Actually you can code in the browser. You can write JS snippets in the URL, in the URL field, in the console... No need for an IDe, an interpreter or a compiler or to install anything else.
A browser is all you need to start coding and everyone has one installed on their system.
Also on coding is too hard for newbies: JS, Python, PHP are NOT hard. I couln't have became a developper 25 years ago when programming was really hard but nowadays building usefull applications with JS and/or Python the myriad of libaries available and the ridiculous hardware ressources at the disposal of anyone, it's not hard anymore.
A browser is all you need to start coding and everyone has one installed on their system.
Also on coding is too hard for newbies: JS, Python, PHP are NOT hard. I couln't have became a developper 25 years ago when programming was really hard but nowadays building usefull applications with JS and/or Python the myriad of libaries available and the ridiculous hardware ressources at the disposal of anyone, it's not hard anymore.
The case here is that, if it were up to nowadays frontend developers, it would not be possible to write simple JavaScript code in notepad to quickly run in the browser. The frontend scene has evolved to become an unmanageable monster of cargo-cult programming, unnecessary complexity, infinite scaffoldings and huge node_module folders, and frontend developers are proud of that complexity. They enjoy running npm init and tens of initialization commands before even writing a single line of code of their own.
And all of that goes against the ease of access the OP post seems to request.
And all of that goes against the ease of access the OP post seems to request.
Yes you can: <script>. It still works, you know.
> Why can't I write [NodeJS] code inside my browser?
Short answer: you can write NodeJS code inside your browser[0]. Being able to do so will not solve ANY of the problems listed in your blogpost.
The author's problem is that they don't have an attention span for learning a domain which contains necessary complexity; they crave quickfixes but don't have enough basic knowledge to understand why those quickfixes won't help them.
> An incomplete list of things I’ve tried and failed to do:
> [lists 3 things that most/many web programmers fail to do regularly as part of their day-to-day]
I've failed to install node or pip at least 100 times. This is a normal part of learning anything in life. How many times did you fall off your bicycle as a child?
[0] Whether it's repl.it, Codespaces or some other method there a million ways to do this depending on your needs. All do require a basic understanding of code which the author seems to lack (their bullet list of coding projects are all based on pre-existing templates & copypaste, especially their "fairly complex Jekyll blog")
Short answer: you can write NodeJS code inside your browser[0]. Being able to do so will not solve ANY of the problems listed in your blogpost.
The author's problem is that they don't have an attention span for learning a domain which contains necessary complexity; they crave quickfixes but don't have enough basic knowledge to understand why those quickfixes won't help them.
> An incomplete list of things I’ve tried and failed to do:
> [lists 3 things that most/many web programmers fail to do regularly as part of their day-to-day]
I've failed to install node or pip at least 100 times. This is a normal part of learning anything in life. How many times did you fall off your bicycle as a child?
[0] Whether it's repl.it, Codespaces or some other method there a million ways to do this depending on your needs. All do require a basic understanding of code which the author seems to lack (their bullet list of coding projects are all based on pre-existing templates & copypaste, especially their "fairly complex Jekyll blog")
I think what the author is really pointing out is the rather large gap between the many introductory "learn to code" tools and then actual, real development tools used to make software.
A lot of those introductory tools abstract away the way that software actually works which allows you to focus on learning the basics of logic and programming. This is great for learning but extremely limiting. There is a reason why professional tools and programming languages don't abstract away the technical details. Because you need to know how things work under the hood in order to be a truly effective programmer.
This is part of why a formal programming education is so valuable IMO. It can be very hard to cross that gap on your own.
I think this article also defines a kind of smoke test for programmers. If you don't like learning how to read error messsage on a command line or googling stuff, you probably won't like programming.
To Tom I would say - programming is hard, but I think that's OK. It's not good to hide all of the technical "ugliness" of how these tools work because to be an effective programmer you need to know how they work. That's just the reality. The messages you see when working with tools like Ruby or Node are designed to be useful for a professional who knows how to read them. What may seem like command line garbage to an untrained eye is actually extremely useful to someone that knows what they are looking for...and that is what takes someone from a hobbyist programmer to a professional. Is there room for improvement? Can we close the gap between the myriad of "hello world" programming tools and the seemingly bottomless trench of "real" programming tools? Absolutely.
A lot of those introductory tools abstract away the way that software actually works which allows you to focus on learning the basics of logic and programming. This is great for learning but extremely limiting. There is a reason why professional tools and programming languages don't abstract away the technical details. Because you need to know how things work under the hood in order to be a truly effective programmer.
This is part of why a formal programming education is so valuable IMO. It can be very hard to cross that gap on your own.
I think this article also defines a kind of smoke test for programmers. If you don't like learning how to read error messsage on a command line or googling stuff, you probably won't like programming.
To Tom I would say - programming is hard, but I think that's OK. It's not good to hide all of the technical "ugliness" of how these tools work because to be an effective programmer you need to know how they work. That's just the reality. The messages you see when working with tools like Ruby or Node are designed to be useful for a professional who knows how to read them. What may seem like command line garbage to an untrained eye is actually extremely useful to someone that knows what they are looking for...and that is what takes someone from a hobbyist programmer to a professional. Is there room for improvement? Can we close the gap between the myriad of "hello world" programming tools and the seemingly bottomless trench of "real" programming tools? Absolutely.
My only explanation for the existence of this article is laziness. You can write code inside your browser easily.
Cloud9 exists and although it was acquired by AWS you can still use it.
https://aws.amazon.com/cloud9/
The real solution to this problem is more awareness and good entry level resources that you can point indecisive people toward. None of his points are actually going to improve the situation even a tiny bit, mostly because they already exist and some of them completely failed while the others are there if you just look for them.
Cloud9 exists and although it was acquired by AWS you can still use it.
https://aws.amazon.com/cloud9/
The real solution to this problem is more awareness and good entry level resources that you can point indecisive people toward. None of his points are actually going to improve the situation even a tiny bit, mostly because they already exist and some of them completely failed while the others are there if you just look for them.
I think the most infuriating thing to me about this article is that the author doesn't understand the existing tools well enough to have any idea why we need new ones, and instead decided to complain on his blog about how programming is too hard.
ANYTHING is hard when you first start out. Try making a table out of wood, or doing origami, or playing an instrument for the first time, and unless you're some bizarre savant you're going to effing SUCK at it. Learn why things are the way they are, or in this case learn the way things are in the first place, and your results will improve.
ANYTHING is hard when you first start out. Try making a table out of wood, or doing origami, or playing an instrument for the first time, and unless you're some bizarre savant you're going to effing SUCK at it. Learn why things are the way they are, or in this case learn the way things are in the first place, and your results will improve.
I feel many of the comments here are akin to saying "laying out in documents latex is hard, if you can't figure it out you're not ready to write" while the author of the article is saying "I think writing documents could be easier." Google docs is proof it's possible.
Sure everyone could learn about $path with a little research but there is SO MUCH to learn to get started with a "simple" react app... It's not necessary.
Great tools hands a "low floor AND a high ceiling" meaning it's easy to get started and possible to go really really far.
Clearly tools like replies show there's a desire for easier to set up environments.
Have you never wished you could save your css tweaks directly from chrome dev tools?
Why should the browser show you the page source when you could just curl it? Well... Let's try to make the unimportant things EASY so we can focus on the useful parts.
Firefox could absolutely come with a standard node server and editor. And it could integrate with providers like GitHub or netlify.
Gatekeeping getting started benefits nobody.
Sure everyone could learn about $path with a little research but there is SO MUCH to learn to get started with a "simple" react app... It's not necessary.
Great tools hands a "low floor AND a high ceiling" meaning it's easy to get started and possible to go really really far.
Clearly tools like replies show there's a desire for easier to set up environments.
Have you never wished you could save your css tweaks directly from chrome dev tools?
Why should the browser show you the page source when you could just curl it? Well... Let's try to make the unimportant things EASY so we can focus on the useful parts.
Firefox could absolutely come with a standard node server and editor. And it could integrate with providers like GitHub or netlify.
Gatekeeping getting started benefits nobody.
> there is SO MUCH to learn to get started with a "simple" react app... It's not necessary.
One line of HTML: https://reactjs.org/docs/add-react-to-a-website.html#add-rea...
> Have you never wished you could save your css tweaks directly from chrome dev tools?
You can: https://developers.google.com/web/tools/chrome-devtools/work...
> Firefox could absolutely come with a standard node server and editor
A node server runs JavaScript files as do browser engines and the majority of node’s API exists in the browser in a similar form, as well as an editor. GitHub as well comes with an editor built-in, Netlify can be connected to GitHub by clicking one button.
I agree that it’s good to simplify, but are these good examples for that?
One line of HTML: https://reactjs.org/docs/add-react-to-a-website.html#add-rea...
> Have you never wished you could save your css tweaks directly from chrome dev tools?
You can: https://developers.google.com/web/tools/chrome-devtools/work...
> Firefox could absolutely come with a standard node server and editor
A node server runs JavaScript files as do browser engines and the majority of node’s API exists in the browser in a similar form, as well as an editor. GitHub as well comes with an editor built-in, Netlify can be connected to GitHub by clicking one button.
I agree that it’s good to simplify, but are these good examples for that?
> Have you never wished you could save your css tweaks directly from chrome dev tools?
FWIW, you already can. Sources -> Overrides -> Select folder for overrides.
FWIW, you already can. Sources -> Overrides -> Select folder for overrides.
I don't know whether the path is the problem that makes modern web dev so hard to learn.
I'm currently trying to setup the js testing library "jest" to use babel to transpile typescript and I get the most obscure error messages. This is painfully hard and I have years of experience with javascript/typescript [1].
I doubt there ever has been a more complex programming ecosystem than JavaScript's. No other system has more bundlers (webpack, rollup, metro, ..), transpilers (babel, typescript, flow, ...), testing libraries (jest, mocha, jasmine, ...), package managers (yarn, npm, pnpm, ...). It is just insane what we created.
[1] if you are curious, that is the error message. Good luck making sense of it. It probably is caused by non-compatible dependencies but yarn does not tell me.
Validation Error:
I'm currently trying to setup the js testing library "jest" to use babel to transpile typescript and I get the most obscure error messages. This is painfully hard and I have years of experience with javascript/typescript [1].
I doubt there ever has been a more complex programming ecosystem than JavaScript's. No other system has more bundlers (webpack, rollup, metro, ..), transpilers (babel, typescript, flow, ...), testing libraries (jest, mocha, jasmine, ...), package managers (yarn, npm, pnpm, ...). It is just insane what we created.
[1] if you are curious, that is the error message. Good luck making sense of it. It probably is caused by non-compatible dependencies but yarn does not tell me.
Validation Error:
Preset @babel/preset-typescript is invalid:
The "id" argument must be of type string. Received type object
TypeError [ERR_INVALID_ARG_TYPE]: The "id" argument must be of type string. Received type objectI had to do a take home programming task over a weekend for a job interview last year, the only technical requirement was that it had to be done in JS (both Node and browser).
It had been a few years since I had started a JS project from scratch (I spend 90% of my time doing Rails dev). I ended up spending more time figuring out what package/build/testing tools to use than I did actually writing code.
Looking up best practices for Express.js project structures, I found that every blog post/article had a different "best" structure.
I'm happy that my new job is still primarily Rails. I'll take convention over configuration any day.
It had been a few years since I had started a JS project from scratch (I spend 90% of my time doing Rails dev). I ended up spending more time figuring out what package/build/testing tools to use than I did actually writing code.
Looking up best practices for Express.js project structures, I found that every blog post/article had a different "best" structure.
I'm happy that my new job is still primarily Rails. I'll take convention over configuration any day.
> Ok, once again. I can write code inside my spreadsheet but not inside my browser? WTF.
> Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
I don't understand the problem. Ignoring the node.js requirement, just open the developer console in Chrome or Firefox. There you have a powerful JavaScript REPL. There is also a ton of online REPLs, e.g. https://repl.it/languages/nodejs.
> Increasingly there’s a disconnect between the kinds of activities code enables and the “expected” workflow for “being a coder”.
What does that even mean? There is also a huge disconnect between the kinds of activities buildings enable and the expected workflow for "being an architect". Yet I don't hear an architect complaining that he cannot design a building simply by wandering through the Taj Mahal and thinking "wow, this really looks beautiful, I enjoy this!".
> Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
I don't understand the problem. Ignoring the node.js requirement, just open the developer console in Chrome or Firefox. There you have a powerful JavaScript REPL. There is also a ton of online REPLs, e.g. https://repl.it/languages/nodejs.
> Increasingly there’s a disconnect between the kinds of activities code enables and the “expected” workflow for “being a coder”.
What does that even mean? There is also a huge disconnect between the kinds of activities buildings enable and the expected workflow for "being an architect". Yet I don't hear an architect complaining that he cannot design a building simply by wandering through the Taj Mahal and thinking "wow, this really looks beautiful, I enjoy this!".
We keep creating these, but one of two things always happens:
1. They fail (e.g. Smalltalk).
2. They succeed (e.g. the web). When they succeed, professional programmers overwhelm them and make damn sure only very very professional programmers can ever use them again.
1. They fail (e.g. Smalltalk).
2. They succeed (e.g. the web). When they succeed, professional programmers overwhelm them and make damn sure only very very professional programmers can ever use them again.
> When they succeed, professional programmers overwhelm them and make damn sure only very very professional programmers can ever use them again.
I was reading that in the same vein yesterday: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
(it's a well-known false interview with Stroustrup)
I was reading that in the same vein yesterday: http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
(it's a well-known false interview with Stroustrup)
I kind of get that person's point (although I don't quite understand the tone...). I introduced my wife to LaTeX when she started her PhD because she had very specific typesetting needs like phonetic alphabet and arrows on top of words to indicate intonation. She discovered a wonderful world! But none of that could have been possible if she had had to install a LaTeX distribution and an editor on Windows .
Overleaf (and previously Sharelatex) on the other end makes everything easy. You have the choice between XeLateX, PDFLaTeX, etc., all the useful packages you could dream of, and more, without installing anything. Plus collaborative editing for free, when she needs help with a macro or a new environment definition.
So, yeah, being able to program without having to install a development environment is great. There are tools to do that already, like Repl.it, maybe the OP could try that.
Overleaf (and previously Sharelatex) on the other end makes everything easy. You have the choice between XeLateX, PDFLaTeX, etc., all the useful packages you could dream of, and more, without installing anything. Plus collaborative editing for free, when she needs help with a macro or a new environment definition.
So, yeah, being able to program without having to install a development environment is great. There are tools to do that already, like Repl.it, maybe the OP could try that.
U can use html / js with browser in like 5 seconds. No need for Node.js. Just write an html file and link a js file and you can code whatever you want.
> Ok, once again. I can write code inside my spreadsheet but not inside my browser? WTF.
The premise of his article is faulty because... you can code inside your browser. _They mention Glitch_, which lets you code inside your browser! There's things like CodeSandbox.io (and Github Codespaces coming whenever) that give you a full NodeJS environment and 'proper' IDE (VS Code) all in your browser and lets your deploy to a variety of production environments.
Downloading and running a node.pkg that installs all the command line tools seems pretty easy - there's nothing wrong with the command line, you've just got to learn it.
It's never been easier to code.
The premise of his article is faulty because... you can code inside your browser. _They mention Glitch_, which lets you code inside your browser! There's things like CodeSandbox.io (and Github Codespaces coming whenever) that give you a full NodeJS environment and 'proper' IDE (VS Code) all in your browser and lets your deploy to a variety of production environments.
Downloading and running a node.pkg that installs all the command line tools seems pretty easy - there's nothing wrong with the command line, you've just got to learn it.
It's never been easier to code.
"People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh."
Well, people hate graphical interfaces - not only do they LOOK scary, they give weird unhelpful error messages and… you have to click everything with a tiny pointer like you are fishing in muddy waters. Ugh.
Well, people hate graphical interfaces - not only do they LOOK scary, they give weird unhelpful error messages and… you have to click everything with a tiny pointer like you are fishing in muddy waters. Ugh.
Firefox used to have a "scratchpad" for doing code in the browser, albeit somewhat barebones. Unfortunately it was more or less abandoned and eventually removed.
It would have been nice to see it expanded instead. A full on node environment would be a bridge too far IMHO but it would have been great to have added a good way to reuse modules and some more GUI niceties.
It did have full access to the current web page so there would have been security issues with new coders copy/pasting code from the internet. But a revised version could give it its own isolated environment by default.
It would have been nice to see it expanded instead. A full on node environment would be a bridge too far IMHO but it would have been great to have added a good way to reuse modules and some more GUI niceties.
It did have full access to the current web page so there would have been security issues with new coders copy/pasting code from the internet. But a revised version could give it its own isolated environment by default.
Hmm, what about so called bookmarklets? You fire up js console obviously too, or use tanpermonkey, or make a local extension. There are really vast options out there and people do use them one way or another.
This is one of the most whiny and misguided articles I've seen near the top of HN in some time.
I really fail to understand how people can see something like the $PATH variable and not understand it 'for years' - does everyone else not just Google/DDG things they don't understand?
It's not really worth critiquing more of the article, as the entire premise of not being able to 'write code inside the browser' is just another fallacy that's based on the authors complete lack of knowledge, or willingness to acquire any more knowledge.
I really fail to understand how people can see something like the $PATH variable and not understand it 'for years' - does everyone else not just Google/DDG things they don't understand?
It's not really worth critiquing more of the article, as the entire premise of not being able to 'write code inside the browser' is just another fallacy that's based on the authors complete lack of knowledge, or willingness to acquire any more knowledge.
Are you aware of the console? I have used it for all kinds of stuff.
Here's what you do: go to about:blank, open the console and start typing JavaScript code. Try:
Here's what you do: go to about:blank, open the console and start typing JavaScript code. Try:
document.write('hello world')As a JavaScript learning exercise (OK mostly because it was fun), I started writing a simple bot to play the Paperclips game[1] for me.
I was really surprised with how easy it was to do stuff like add in a third party graphing library and then write a bit of code to graph interesting metrics on this page, directly from the console of my own browser.
I've also used greasemonkey for years to inject interesting scripts to improve usability on a couple of key sites. I think there are tons of options to do this kinda stuff, but I'm sure the tooling could be improved a little bit in some areas (e.g., to easily take advantage of npm packages).
1. https://www.decisionproblem.com/paperclips/index2.html 2. https://github.com/trogau/paperclips/
I was really surprised with how easy it was to do stuff like add in a third party graphing library and then write a bit of code to graph interesting metrics on this page, directly from the console of my own browser.
I've also used greasemonkey for years to inject interesting scripts to improve usability on a couple of key sites. I think there are tons of options to do this kinda stuff, but I'm sure the tooling could be improved a little bit in some areas (e.g., to easily take advantage of npm packages).
1. https://www.decisionproblem.com/paperclips/index2.html 2. https://github.com/trogau/paperclips/
> Are you aware of the console? I have used it for all kinds of stuff.
Sorry that (having posted the link) I don't have anything that concretely adds to the discussion, but I just thought I should point out that I'm not the author of the blog-article, as a few posters here seem to think.
I definitely don't endorse the author's views either, but I thought it was an interesting post for discussion, and I certainly don't think that making some aspects of coding more accessible is a bad thing.
edit: I just noticed the actual author is posting to the thread.
Sorry that (having posted the link) I don't have anything that concretely adds to the discussion, but I just thought I should point out that I'm not the author of the blog-article, as a few posters here seem to think.
I definitely don't endorse the author's views either, but I thought it was an interesting post for discussion, and I certainly don't think that making some aspects of coding more accessible is a bad thing.
edit: I just noticed the actual author is posting to the thread.
If we want monkeys typing out the entire works of Shakespeare we might as well make that the default when you open a browser and smash the keyboard/screen (device will magically know).
I mean the alternative - friggin' learnin' stuff - is too hard.
I mean the alternative - friggin' learnin' stuff - is too hard.
Yes, in order to do X you need to learn how to do X. Complaining about not being able to program when you didn't spend a minimal amount of energy to understand the basics of how your computer works is worthless, just like this article.
The reason you can't do this is that Node of course has a bunch of file system APIs that for security reasons necessitate an application designed for automatically downloading and executing arbitrary source code can never, ever, have access to.
But you could rephrase the authors point this way: Browsers make a ton of concessions to regular users at the expense of developers. Consider for example that the act of developing a web application in fact often does not involve executing arbitrary source code online, it involves executing specific source code you have control over, which has different security requirements.
The author is expressing something I'm surprised more developers don't pick up on: The browser is a consumer tool first, and yet it's a favorite tool of developers despite the fact that it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome. A rational developer, who spends all day with a browser open for development, would be frustrated that one of their primary use cases has such a low priority in the application. But that's not how developers perceive the browser, developers have a fondness for the browser that's not reciprocated.
Another example of the low priority of developer use cases in browsers is that the commonality of the other main developer tools, text editors and terminals, is that they achieve incredibly powerful functionality through process management. E.g., code completion, linters, integrated debugging, `grep`, `git`, are all based on text editor's and terminal's ability to manage external processes. But browsers can't do this, which firmly limits their usefulness, and creates bizarre situations like having to manually hit the refresh button because your server process can't talk to the browser application itself.
But you could rephrase the authors point this way: Browsers make a ton of concessions to regular users at the expense of developers. Consider for example that the act of developing a web application in fact often does not involve executing arbitrary source code online, it involves executing specific source code you have control over, which has different security requirements.
The author is expressing something I'm surprised more developers don't pick up on: The browser is a consumer tool first, and yet it's a favorite tool of developers despite the fact that it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome. A rational developer, who spends all day with a browser open for development, would be frustrated that one of their primary use cases has such a low priority in the application. But that's not how developers perceive the browser, developers have a fondness for the browser that's not reciprocated.
Another example of the low priority of developer use cases in browsers is that the commonality of the other main developer tools, text editors and terminals, is that they achieve incredibly powerful functionality through process management. E.g., code completion, linters, integrated debugging, `grep`, `git`, are all based on text editor's and terminal's ability to manage external processes. But browsers can't do this, which firmly limits their usefulness, and creates bizarre situations like having to manually hit the refresh button because your server process can't talk to the browser application itself.
> it barely caters to developers at all. Take for example the "Developer" menu item, which is two levels deep in Chrome.
Sure, but it's also in every single right click menu on every page and has several keyboard shortcuts (F12, Ctrl+Shift+I)
In my opinion, having to go two menus deep is not "barely catering to the audience at all". The vendor of that product just likes to have clean menus.
Sure, but it's also in every single right click menu on every page and has several keyboard shortcuts (F12, Ctrl+Shift+I)
In my opinion, having to go two menus deep is not "barely catering to the audience at all". The vendor of that product just likes to have clean menus.
A thought experiment if you have time for it: Let's say you take a word processor. It's a great word processor, well-designed for its purpose. But it's primarily designed for "consumer" text editing, things like resumes, school papers, and the like. And let's say you add some programmer specific functionality to it, but do it in a way that doesn't interfere with any of the consumer-first features. E.g., you make it automatically syntax highlight source code files, you make it use a more sophisticated find-and-replace when editing these files, you add a file drawer that you can toggle via two levels in the menu bar, etc...
Would you be interested in using this word processor for programming over your text editor or IDE which is designed first-and-foremost for programming? If not, what's the difference between this and the way Chrome treats developers? (I'm not being disingenuous here, I honestly don't see the difference personally.)
Would you be interested in using this word processor for programming over your text editor or IDE which is designed first-and-foremost for programming? If not, what's the difference between this and the way Chrome treats developers? (I'm not being disingenuous here, I honestly don't see the difference personally.)
If I really liked that word processor for general use then I might also use it for simple one-off programming tasks, like how I use my browser's developer tools today (Firefox though).
What's the alternative though? Is the suggestion that browsers ought to be competitive out of the box with whole off-the-shelf IDEs that can cost thousands of dollars, prioritizing that use case over even web browsing?
What's the alternative though? Is the suggestion that browsers ought to be competitive out of the box with whole off-the-shelf IDEs that can cost thousands of dollars, prioritizing that use case over even web browsing?
I wasn't suggestion browsers should compete with IDEs, just that consumer browsers and developer browsers should be different applications with different features, just like word processors and text editors are different applications with different features.
Regarding the word processor experiment, I don't really mean as something you'd use for one-off programming tasks, I mean as a replacement for a dedicated programmer's text editor. E.g., the point is that a developer-first browser could have features and developer-experience that consumer-first browser can never match, just like adding developer features to a word processor would struggle to match a dedicated programming text editor.
Regarding the word processor experiment, I don't really mean as something you'd use for one-off programming tasks, I mean as a replacement for a dedicated programmer's text editor. E.g., the point is that a developer-first browser could have features and developer-experience that consumer-first browser can never match, just like adding developer features to a word processor would struggle to match a dedicated programming text editor.
Are you aware of Firefox Developer Edition?
https://www.mozilla.org/en-US/firefox/developer/
No, I wasn’t, thanks for pointing it out! I’d love to hear which of the issues I listed that it addresses. The tag line “welcome to your new favorite browser. Get the latest features, fast performance, and the development tools you need to build for the open web”, as well as the features listed on the homepage, don’t address any of the points I listed directly. (This doesn’t mean the app itself doesn't, but I'm not encouraged by the features as they’re listed on the homepage, which feels more like some new features for developers, rather than a re-imagining of how we think about how developer tools are integrated into the browser like I’m describing.)
I’m not sure it is a complete reimagining, but it does take a developer first approach. Many Dev tools need to be extendable and the Firefox team has tried to do that with the built-in dev tools.
> The new Firefox DevTools are powerful, flexible, and best of all, *hackable*. This includes a best-in-class JavaScript debugger, which can target multiple browsers and is built in React and Redux.
Here’s an example of extending the devtools for react https://addons.mozilla.org/en-US/firefox/addon/react-devtool...
> The new Firefox DevTools are powerful, flexible, and best of all, *hackable*. This includes a best-in-class JavaScript debugger, which can target multiple browsers and is built in React and Redux.
Here’s an example of extending the devtools for react https://addons.mozilla.org/en-US/firefox/addon/react-devtool...
Cool, yeah not quite what I’m talking about but extensibility is certainly a core attribute of developer-centric tools.
To anyone confused by $PATH, read "Unix for the beginning mage":
https://lab46.g7n.org/_media/haas/ufbm.pdf
I've taught at several bootcamps, and this is the first book I tell everyone to read. I tell my students to just get it read ASAP. After that setting up your environments or $PATH becomes much more comprehensible. Git becomes much more comprehensible. Life as a developer is much more pleasant.
The article author should take time to understand the command line environment they work in, simple as that. I've had the exact same struggles the author has had. I've had Ruby, JS and npm implosions, multiple times. It would be nice if the languages and tools documented their errors better. All tools should strive for better, more beginner friendly documentation. But if you're a dev right now knowing Unix has to be table stakes.
https://lab46.g7n.org/_media/haas/ufbm.pdf
I've taught at several bootcamps, and this is the first book I tell everyone to read. I tell my students to just get it read ASAP. After that setting up your environments or $PATH becomes much more comprehensible. Git becomes much more comprehensible. Life as a developer is much more pleasant.
The article author should take time to understand the command line environment they work in, simple as that. I've had the exact same struggles the author has had. I've had Ruby, JS and npm implosions, multiple times. It would be nice if the languages and tools documented their errors better. All tools should strive for better, more beginner friendly documentation. But if you're a dev right now knowing Unix has to be table stakes.
Sorry. what?
F12->Console->Boom, Code.
It's legit right there? Open up a blank index.html page and you can even start adding canvas elements and stuff probably.
EDIT: After reading more carefully, I realize the author is of the "I just don't understand why this is so hard?" variety. Answer: There's a direct tradeoff between the expressiveness of your language and its difficulty. This is even a concept in linguistics. Take a look at several graphical programming languages, they are incredibly limited so they can be done graphically.
This article ticked me off honestly. Really feels like they just don't understand how and why people use text-based tools and command lines. It's not because we think we're better than you lol, we just like them more and find it more effective. It allows us to get the work done.
Another comment said intellectually lazy and I think that nails it. What a pile of crock.
F12->Console->Boom, Code.
It's legit right there? Open up a blank index.html page and you can even start adding canvas elements and stuff probably.
EDIT: After reading more carefully, I realize the author is of the "I just don't understand why this is so hard?" variety. Answer: There's a direct tradeoff between the expressiveness of your language and its difficulty. This is even a concept in linguistics. Take a look at several graphical programming languages, they are incredibly limited so they can be done graphically.
This article ticked me off honestly. Really feels like they just don't understand how and why people use text-based tools and command lines. It's not because we think we're better than you lol, we just like them more and find it more effective. It allows us to get the work done.
Another comment said intellectually lazy and I think that nails it. What a pile of crock.
Technically VS Code is a browser. If you open about, you'll see its Chrome. That means you can write code inside browser.
Also there are things like Jupyter and AWS Cloud9.
Does the author not get browsers at all?
Chrome should include a nodejs installation by default because the commandline is scary? Does he know, that node is based on the V8 engine that's part of Chrome? Packing it in would be redundant and it's a pure backend integration. You dont need nodejs to learn javascript.
If Pathes and Commands are scary, just right-click on your desktop. Click New->Text Document and name it "index.html". Open the document in a text editor of your choice. insert <html><head><script>### </script></head><body></body></html> into the file. Replace ### with your js code. Open file in browser.. Its that easy. FFS, some people just want to complain.
Chrome should include a nodejs installation by default because the commandline is scary? Does he know, that node is based on the V8 engine that's part of Chrome? Packing it in would be redundant and it's a pure backend integration. You dont need nodejs to learn javascript.
If Pathes and Commands are scary, just right-click on your desktop. Click New->Text Document and name it "index.html". Open the document in a text editor of your choice. insert <html><head><script>### </script></head><body></body></html> into the file. Replace ### with your js code. Open file in browser.. Its that easy. FFS, some people just want to complain.
I am fascinated by the continued prevalence of excel in many industries. It feels as if some modern scripting language should be able to replace some aspects of the spreadsheet and work much better.
Excel is great for prototyping. It produces immediate results without any configuration. And it saves your database along with your code in a single file.
This is huge. Can you name any other programming language that automatically saves database + code in a single file?
Think about how many files you have to share if you use a script + database. At least 2 files. And then you have to zip it and the recipient has to unzip it. (cluttering your downloads folder)
However, at a certain point you have to make the jump and install/configure a database, even if it's just SQLite.
This is huge. Can you name any other programming language that automatically saves database + code in a single file?
Think about how many files you have to share if you use a script + database. At least 2 files. And then you have to zip it and the recipient has to unzip it. (cluttering your downloads folder)
However, at a certain point you have to make the jump and install/configure a database, even if it's just SQLite.
> some modern scripting language should be able to replace some aspects of the spreadsheet and work much better
To begin with, it should be a single package without dependencies, just like excel is. Not some "ecosystem" where you need to install certain versions of packages for your script to work.
To begin with, it should be a single package without dependencies, just like excel is. Not some "ecosystem" where you need to install certain versions of packages for your script to work.
I'm not so much fascinated as scared by how many investment banks are heavily reliant on Excel.
A former co-worker used to work in London for a bank, his job was to maintain the linked Excel spreadsheets that were business critical - and only took six hours to produce a result.
He found moving to the Java ecosystem rather relaxing and uncomplicated in comparison.
A former co-worker used to work in London for a bank, his job was to maintain the linked Excel spreadsheets that were business critical - and only took six hours to produce a result.
He found moving to the Java ecosystem rather relaxing and uncomplicated in comparison.
Why doesn't Windows come with something as easy to get started with as Basic? In the 80s almost every home computer could be immediately used to write code as soon as it was switched on.
Wow. People are being pretty hard on this guy. A common complaint is that he wants to code but not put the least amount of work in. What is wrong with that? Or why get angry at him?
I've been working on a side project related to being an easier coding environment. I hope that is not a terrible idea.
https://www.apogeejs.com/web/apogee.html?url=/web/examples/q...
I've been working on a side project related to being an easier coding environment. I hope that is not a terrible idea.
https://www.apogeejs.com/web/apogee.html?url=/web/examples/q...
It sounds like the author comes from a Windows background. FWIW, way back when I was a beginner, there were already tools geared towards this exact "no command lines ever" audience: xampp[0]. You'd be surprised how far xampp plus php.net docs can take you!
Nowadays, there's also tools like codepen, cloud9, etc, not to mention an endless amount of resources for learning in all sorts of formats (many of which are free).
The thing that bothers me is this idea of "look, I'm a beginner, but your not-geared-at-beginners tool should be geared at beginners!" Imagine you are a beginner at art, and you go around demanding that oil on canvas shouldn't involve brushes and mixing paints because that's too hard, or that metal sculpting shouldn't involve sparks flying out because that's too scary, and instead everything should be as easy as using crayons. That'd just be silly.
At some point in the mastery ladder, you will run into established tools and you just have to learn how to use them.
There's certainly an argument to be made about how rough the ground is when you've veered off the beaten path, but if we were to make a road analogy, while something like setting up a M1 assembler under linux might be way out in the weeds, installing node.js is at worst akin to driving in from out of town.
[0] https://www.apachefriends.org/index.html
Nowadays, there's also tools like codepen, cloud9, etc, not to mention an endless amount of resources for learning in all sorts of formats (many of which are free).
The thing that bothers me is this idea of "look, I'm a beginner, but your not-geared-at-beginners tool should be geared at beginners!" Imagine you are a beginner at art, and you go around demanding that oil on canvas shouldn't involve brushes and mixing paints because that's too hard, or that metal sculpting shouldn't involve sparks flying out because that's too scary, and instead everything should be as easy as using crayons. That'd just be silly.
At some point in the mastery ladder, you will run into established tools and you just have to learn how to use them.
There's certainly an argument to be made about how rough the ground is when you've veered off the beaten path, but if we were to make a road analogy, while something like setting up a M1 assembler under linux might be way out in the weeds, installing node.js is at worst akin to driving in from out of town.
[0] https://www.apachefriends.org/index.html
Open VSCode.
click Help.
select Toggle Developer Tools.
Realize you're writing code in a browser.
click Help.
select Toggle Developer Tools.
Realize you're writing code in a browser.
Am I the only one that doesn’t know how to code in a spreadsheet?
I was thinking the same. I have no problems dealing with the terminal, but man if I ever have to do more than adding numbers in a spreadsheet...
I feel this deeply. Building binaries in a docker container to deploy as a Lambda Layer? Aces. Anything more complex than basic math functions across a few cells? Burn it with fire.
https://nwjs.io/ - A browser with built in Node.js.
Or editors/IDE inside the browser:
https://webide.se/ https://codeanywhere.com/ https://aws.amazon.com/cloud9/
Or editors/IDE inside the browser:
https://webide.se/ https://codeanywhere.com/ https://aws.amazon.com/cloud9/
adding to the editors/IDE inside the browser:
https://github.com/cdr/code-server (headless vscode) https://github.com/pylonide/pylon (fork of c9v2 when it was still open source)
https://github.com/cdr/code-server (headless vscode) https://github.com/pylonide/pylon (fork of c9v2 when it was still open source)
Yes, the author is confused and has no idea what he's talking about.
But I agree with the general idea: The barrier to entry for coding is quite high, which puts it out of reach for so many.
Flash is dead now, but it was an environment that really lowered the barrier. People with barely any coding skills could program with it. But a lot of them had other skills. The results were often awful or horrible, but some really amazing things were also created.
But I agree with the general idea: The barrier to entry for coding is quite high, which puts it out of reach for so many.
Flash is dead now, but it was an environment that really lowered the barrier. People with barely any coding skills could program with it. But a lot of them had other skills. The results were often awful or horrible, but some really amazing things were also created.
One time when I was much younger I wrote an auto-download script for a forum I liked. I used it just for myself and never had a problem, so one day I posted it with instructions on how to use it. A few minutes later I got a really angry reply; some guy had hit a weird edge case and it was downloading the same links over and over, rapidly filling up his small SSD and causing all kinds of problems. I apologized and posted a fix, but I was already getting absolutely reamed in the replies by other people who either had the same bug, or some other. That's how I learned newbies should not throw random code on the Internet - it pisses people off when you tell them "Use this!" and then it breaks their computer.
When I people say "I want everyone to be able to code on the web in JavaScript", what I really hear is "I want an Internet full of broken, unusable, and possibly dangerous garbage, written in one of the least safe and elegant languages ever created, where most things are completely hostile to the majority who come across it."
Additionally, if this person can't read a ten-minute tutorial on how to install Ruby with homebrew, imagine what else they probably won't do:
- Read/write a CoC or contributor's guidelines - Spend time translating their web pages, or making them accessible - Understand basic security and privacy issues/best practices - Take the extra time to make useful bug reports, or make reports at all - Read (or write) references, documentation, or tutorials - Learn general netiquette for commits, mailing lists, pull requests - Understand the basics of open-source licenses
And maybe this is totally fine for your completely personal hobby project, but the next logical step is having other people use it. This isn't the kind of behavior we want to carry into that next step.
When I people say "I want everyone to be able to code on the web in JavaScript", what I really hear is "I want an Internet full of broken, unusable, and possibly dangerous garbage, written in one of the least safe and elegant languages ever created, where most things are completely hostile to the majority who come across it."
Additionally, if this person can't read a ten-minute tutorial on how to install Ruby with homebrew, imagine what else they probably won't do:
- Read/write a CoC or contributor's guidelines - Spend time translating their web pages, or making them accessible - Understand basic security and privacy issues/best practices - Take the extra time to make useful bug reports, or make reports at all - Read (or write) references, documentation, or tutorials - Learn general netiquette for commits, mailing lists, pull requests - Understand the basics of open-source licenses
And maybe this is totally fine for your completely personal hobby project, but the next logical step is having other people use it. This isn't the kind of behavior we want to carry into that next step.
1) your terminal is a browser, a system browser, basically a local, more powerful web browser - and it supports a lot more than just JS unlike other browsers only for the web
2) you operate web browsers via text commands just like a CLI - it all starts with the address/search bar. When you use your search bar to google, you are effectively typing commands into a CLI.
IMO if you can’t install some basic software like node or pip then yeah, maybe the software isn’t the issue and you just need a better fundamental understanding of what it is you’re trying to do. Plenty of people install node, every day, without issues. It’s not rocket science.
If you avoid CLIs, I don’t trust you as a software engineer, because it feels like you’re not looking for the right answer to the problem. It feels like you’re looking for the easy answer to the problem.
Part of the beauty, to me, of the CLI is like starting a painting from a blank canvas, vs a GUI being like a coloring book where you just fill in between the lines.
2) you operate web browsers via text commands just like a CLI - it all starts with the address/search bar. When you use your search bar to google, you are effectively typing commands into a CLI.
IMO if you can’t install some basic software like node or pip then yeah, maybe the software isn’t the issue and you just need a better fundamental understanding of what it is you’re trying to do. Plenty of people install node, every day, without issues. It’s not rocket science.
If you avoid CLIs, I don’t trust you as a software engineer, because it feels like you’re not looking for the right answer to the problem. It feels like you’re looking for the easy answer to the problem.
Part of the beauty, to me, of the CLI is like starting a painting from a blank canvas, vs a GUI being like a coloring book where you just fill in between the lines.
While I'm not sure I agree that IDEs need to be bundled directly into browsers (as other commenters have said: at that point, why not Photoshop? Or Excel?), I think that Github Codespaces [1] is an interesting foray into a much-simplified dev setup experience that will help beginners start writing code without learning the more arcane utilities of professional programming like terminal emulators, shells, and the *nix userspace tools. And it's (optionally) browser-based, so you can get started without installing any dependencies, even though it doesn't ship as part of the Chrome binary.
I agree with a lot of the commenters here that eventually you'll need to learn the arcane things! But I think there's something to be said for being able to just get started writing code and having it run. I did a lot of my early programming on a TI-83 in math class in high school while pretending to pay attention to my teacher. I didn't have to configure it, or do much other than learn the programming language I was writing code in. Later, in college, my intro-level classes were in purpose-built educational IDEs like DrScheme, where I once again just typed my code into the textbox and then ran it from the same UI. I probably would've grit my teeth and pushed through learning all the extra stuff anyway if confronted with an emulator, a shell, and figuring out what `$PATH` refers to, because I was pretty into computers and had high mental pain tolerance. But I can't say it would've been a better onboarding experience, and eventually, I learned all of that stuff anyway -- so why put people off with it at the beginning? Let them do the fun stuff first, then teach them how to do it "for real." In a lot of cases, the not-"for real" version might even be enough to suit their needs.
1: https://github.com/features/codespaces
I agree with a lot of the commenters here that eventually you'll need to learn the arcane things! But I think there's something to be said for being able to just get started writing code and having it run. I did a lot of my early programming on a TI-83 in math class in high school while pretending to pay attention to my teacher. I didn't have to configure it, or do much other than learn the programming language I was writing code in. Later, in college, my intro-level classes were in purpose-built educational IDEs like DrScheme, where I once again just typed my code into the textbox and then ran it from the same UI. I probably would've grit my teeth and pushed through learning all the extra stuff anyway if confronted with an emulator, a shell, and figuring out what `$PATH` refers to, because I was pretty into computers and had high mental pain tolerance. But I can't say it would've been a better onboarding experience, and eventually, I learned all of that stuff anyway -- so why put people off with it at the beginning? Let them do the fun stuff first, then teach them how to do it "for real." In a lot of cases, the not-"for real" version might even be enough to suit their needs.
1: https://github.com/features/codespaces
Bundling is dead. You just need to compile your favorite editor into asm.js and run it in your browser.
Or why not your terminal :) https://www.destroyallsoftware.com/talks/the-birth-and-death...
Or why not your terminal :) https://www.destroyallsoftware.com/talks/the-birth-and-death...
You can’t write code inside your browser because there are better environments for writing code for most people who want to write code, and enabling in-browser coding without it being a giant and regularly exploited security hole through which non-technical users would be exploited is nontrivial.
Yes, it would be very convenient for beginner programmers, but beginner programmers are a very small subset of browser users. (And a robust and even less-secure-against-”paste this command into your browser programming environment” attacks version would be good for more advanced programmers, but even worse for everyone else.) And having specific browsers targeting each of those environments would be possible, but negate (especially for beginner programmers) a significant part of the advantage of having the programming environment integrated in the browser in the first place.
Yes, it would be very convenient for beginner programmers, but beginner programmers are a very small subset of browser users. (And a robust and even less-secure-against-”paste this command into your browser programming environment” attacks version would be good for more advanced programmers, but even worse for everyone else.) And having specific browsers targeting each of those environments would be possible, but negate (especially for beginner programmers) a significant part of the advantage of having the programming environment integrated in the browser in the first place.
Beaker Browser (beakerbrowser.com) already has got you covered.
Lots of commenters here are failing to see past the snarky (in my opinion, tongue-in-cheek) tone and missing the greater point, which isn't a fundamentally new idea, but is always worth revisiting for discussion:
How can we remove as much yak-shaving as possible, so that a person who can understand logic can use it to make computers do things without first learning a bunch of esoteric knowledge required to get the ball rolling? How can we make more Excels?
I think the idea of including a real, accessible, coding environment in a popular web browser is a pretty neat one, if for no other reason than the fact that everyone has a web browser and generally knows how to use it. It would open things up for a very large number of people. Like the author, I doubt Google would ever do this, but it's fun to think about.
How can we remove as much yak-shaving as possible, so that a person who can understand logic can use it to make computers do things without first learning a bunch of esoteric knowledge required to get the ball rolling? How can we make more Excels?
I think the idea of including a real, accessible, coding environment in a popular web browser is a pretty neat one, if for no other reason than the fact that everyone has a web browser and generally knows how to use it. It would open things up for a very large number of people. Like the author, I doubt Google would ever do this, but it's fun to think about.
Counter-argument here is that what the author wants already widely exists. There's a ton of one-stop "install this app & start coding!" apps out there. Someone wants one of those for node.js, sure, knock yourself out, go for it. It'd be just one of a dozen such apps, not a new concept, and not unexplored territory.
But the authors request that this is built into the browser seems insane to me. Why would we bloat browsers with unnecessary stuff just to avoid hitting an app store, which is also extremely user-friendly? It's literally a request for bundled bloatware. No, hell no.
But the authors request that this is built into the browser seems insane to me. Why would we bloat browsers with unnecessary stuff just to avoid hitting an app store, which is also extremely user-friendly? It's literally a request for bundled bloatware. No, hell no.
A big part of why BASIC took off with "non-programmers" (for a while) is that it was bundled on every DOS/Windows install. The same is true of Excel: people already have it and are using it, so they just organically start learning the more advanced things you can do with it, and before long they're basically programming.
We aren't talking about people who make a concerted decision to "go find and install a tool for programming", and who just don't want to put in the effort to learn the "real tools". We're talking about people who would never think of themselves as programmers in the first place. I think you underestimate the significance of the small barriers, even ones as small as a search-and-install step.
I do think it would be silly to drop Node into Chrome wholesale, since the bulk of Node is V8, which is the JS engine Chrome already includes. But what about a version of the JS console that's designed to be exposed to everyday users, for interaction with the sites they use every day? What about a button on the New Tab screen for opening an interactive web dev space similar to CodePen, which can trivially save the resulting files to the local file system (and load projects from there)? They could re-use most of the GUI components from the existing Sources tab in the dev tools. What if it included a preconfigured (simplified) reactive front-end framework so people could get started making custom GUIs? Something like this: https://mavo.io/
We aren't talking about people who make a concerted decision to "go find and install a tool for programming", and who just don't want to put in the effort to learn the "real tools". We're talking about people who would never think of themselves as programmers in the first place. I think you underestimate the significance of the small barriers, even ones as small as a search-and-install step.
I do think it would be silly to drop Node into Chrome wholesale, since the bulk of Node is V8, which is the JS engine Chrome already includes. But what about a version of the JS console that's designed to be exposed to everyday users, for interaction with the sites they use every day? What about a button on the New Tab screen for opening an interactive web dev space similar to CodePen, which can trivially save the resulting files to the local file system (and load projects from there)? They could re-use most of the GUI components from the existing Sources tab in the dev tools. What if it included a preconfigured (simplified) reactive front-end framework so people could get started making custom GUIs? Something like this: https://mavo.io/
> I think you underestimate the significance of the small barriers, even ones as small as a search-and-install step.
I think you over-estimate that barrier. It hasn't stopped things like TikTok, Instagram, etc... The modern world is installing apps. It's not a meaningful barrier.
What you're describing with organic evolution into programming is a cool property of things like Excel, yes. But you don't get that by just bundling an IDE into a browser, either. You still have that barrier of the user needs to decide they want to program. Which they don't want to do when they're just browsing reddit or whatever, that's not a natural evolution path like the Excel one.
I think you over-estimate that barrier. It hasn't stopped things like TikTok, Instagram, etc... The modern world is installing apps. It's not a meaningful barrier.
What you're describing with organic evolution into programming is a cool property of things like Excel, yes. But you don't get that by just bundling an IDE into a browser, either. You still have that barrier of the user needs to decide they want to program. Which they don't want to do when they're just browsing reddit or whatever, that's not a natural evolution path like the Excel one.
I've personally used the browser dev tools in a "consumer" capacity, to:
- Filter content feeds by custom criteria
- Count the number of items in a list
- Tweak a blog post's styling to make it more readable
- Automatically click a large number of items at once (instead of manually)
- Delete cookie overlays and adblocker-detection overlays
Just a few weeks ago a friend asked me how he could go about putting together a little GUI for navigating some D&D rules
Not that the average person would necessarily bother to do all of this stuff, but I think there's a larger space of usecases here than you're assuming
- Filter content feeds by custom criteria
- Count the number of items in a list
- Tweak a blog post's styling to make it more readable
- Automatically click a large number of items at once (instead of manually)
- Delete cookie overlays and adblocker-detection overlays
Just a few weeks ago a friend asked me how he could go about putting together a little GUI for navigating some D&D rules
Not that the average person would necessarily bother to do all of this stuff, but I think there's a larger space of usecases here than you're assuming
You know, I largely agree with the author, I do feel sympathetic. I kinda feel a, idk, lack of sympathy in this thread. Of course you have to learn the machine in front of you, but would you ever have to set $PATH on an iPad? If perhaps I could program Fortran on an iPad, would I really benefit from having the history, the context/history/knowledge of knowing what a $PATH is? Maybe. I doubt it. Knowing /bin from /usr/bin from /sbin from putting . first or last, do you know for fact which $PATH cron/crontab will use? &c &c. Knowing if .bash_profile runs, or .bashrc, or .profile, knowing exactly when they run.. I have not found it fun.
I think you have to admit, most people anyways, that you're ignorant of a lot of systems that came before you. If I gave you an IBM 704, would it be "easy" to program? I would not enjoy that, I think we'd all rather write Fortran on a MacBook. (ask yourself why?)
I have replaced an alternator, but I just learned older cars had "generators" and they're quite distinct (though very similar). I don't know much about "points" or distributors, but I've replaced ignition coils & spark plugs, I feel like I basically understand the gist of that. But I don't know what came before it. I wouldn't fault a mechanic for not knowing points, but an automotive engineer should.
To me, this is where perfectly good wrenching (programming, coding, per se) on its own might be unlikely to advance the state of the art (in software/automotive design). Maybe: To be a really good technician, you should focus narrowly on the hardware/software you service, and not necessarily what came before. But to be a really good engineer/developer/designer, you should focus broadly on everything, to as much depth as you can. Ideally, why not both?
I learned HTML in notepad, then looked for game makers, played with Winamp visualization language, anything that was easily programmable. Did y'all just go straight to writing Rust in Vim?
I think you have to admit, most people anyways, that you're ignorant of a lot of systems that came before you. If I gave you an IBM 704, would it be "easy" to program? I would not enjoy that, I think we'd all rather write Fortran on a MacBook. (ask yourself why?)
I have replaced an alternator, but I just learned older cars had "generators" and they're quite distinct (though very similar). I don't know much about "points" or distributors, but I've replaced ignition coils & spark plugs, I feel like I basically understand the gist of that. But I don't know what came before it. I wouldn't fault a mechanic for not knowing points, but an automotive engineer should.
To me, this is where perfectly good wrenching (programming, coding, per se) on its own might be unlikely to advance the state of the art (in software/automotive design). Maybe: To be a really good technician, you should focus narrowly on the hardware/software you service, and not necessarily what came before. But to be a really good engineer/developer/designer, you should focus broadly on everything, to as much depth as you can. Ideally, why not both?
I learned HTML in notepad, then looked for game makers, played with Winamp visualization language, anything that was easily programmable. Did y'all just go straight to writing Rust in Vim?
I tried this as a Chrome extension a long time ago - github.com/captn3m0/sympathy
The idea was to make file-editing possible and simple in your browser. The extension let you edit file:/// URLs in your browser using the (now unavailable) NPAPI. The results were fun - especially for web development, where I could edit the CSS in one tab, and have it reflect in the second. Chrome added a "workspace" editor a while later, which was similar.
A blog post on why I really wanted to make it: https://github.com/captn3m0/captn3m0.github.com/blob/master/...
The idea was to make file-editing possible and simple in your browser. The extension let you edit file:/// URLs in your browser using the (now unavailable) NPAPI. The results were fun - especially for web development, where I could edit the CSS in one tab, and have it reflect in the second. Chrome added a "workspace" editor a while later, which was similar.
A blog post on why I really wanted to make it: https://github.com/captn3m0/captn3m0.github.com/blob/master/...
This blog post is proof of why what the author wants should never happen.
Coding is about solving problems. Coding is not for everyone. If he cannot even be bothered to find out what $PATH is, then coding is not for him.
He wants to doodle, not code. Why should he expect any browser to cater to his needs?
Coding is about solving problems. Coding is not for everyone. If he cannot even be bothered to find out what $PATH is, then coding is not for him.
He wants to doodle, not code. Why should he expect any browser to cater to his needs?
Conversely, I wish that the nodejs command line debugger were nicer to use. I can get it working—usually after a lot of crying and wishing I weren't too lazy to try to improve it myself and contribute such improvements—and after I do, it's actually pretty fulfilling to use the clunky, limited capabilities it offers. It could be a lot further ahead, or at least as good as pdb (which isn't precisely the bee's knees, but usually gets the job done), but alas, seems like most developers prefer to use the browser for debugging, so that gets a lot more attention.
Well, I'll keep using it, dragging it along kicking and screaming... until it's deprecated or improved, I guess.
Well, I'll keep using it, dragging it along kicking and screaming... until it's deprecated or improved, I guess.
You can literally code in most browsers by accessing their developer tools. It's a hotkey away. You can go write javascript right now.
Second, there are many tools like https://repl.it/ and https://aws.amazon.com/cloud9/ that let you code in browser. I have used a half dozen similar tools on educational websites that allow coding in browser.
Not everyone needs to know how to code, how to be good at it, or have the temperament for it. And the fault rarely lies with the environment around programming.
Second, there are many tools like https://repl.it/ and https://aws.amazon.com/cloud9/ that let you code in browser. I have used a half dozen similar tools on educational websites that allow coding in browser.
Not everyone needs to know how to code, how to be good at it, or have the temperament for it. And the fault rarely lies with the environment around programming.
As easy as it would be to pile on the author here, to me this serves as a stark reminder of the how overwhelming a difficult coding, and setting up environments can seem to beginners.
I think this author is a the perfect target audience for Gitpod https://gitpod.io/#https://github.com/eclipse-theia/theia. With it, you can login with Github, paste the URL of your project into the address bar, and boom! You've got a VSCode clone with NodeJS installed already.
I think this author is a the perfect target audience for Gitpod https://gitpod.io/#https://github.com/eclipse-theia/theia. With it, you can login with Github, paste the URL of your project into the address bar, and boom! You've got a VSCode clone with NodeJS installed already.
Not quite sure if I'm happy about stuffing an IDE and a full development environment into a browser. I would rather stick with the linux philosophy to doing one thing and doing it well, which would be browsing the web.
I've been ranting on and off for years about the need for a good REPL when learning a new language or exploring a new concept. If I can't dig into the objects and poke around at how the individual pieces actually run I find it extremely hard to get a handle on these things at scale.
I've always assumed it was more a "me" issue, and so I've attempted to work in the more "normal" manner, but with pretty poor results. I've all but given up on Python due to its lack of a decent REPL and gone back to Ruby, where at least I have pry to dig in with as needed.
I've always assumed it was more a "me" issue, and so I've attempted to work in the more "normal" manner, but with pretty poor results. I've all but given up on Python due to its lack of a decent REPL and gone back to Ruby, where at least I have pry to dig in with as needed.
I dunno, mate. Why can't I open Jira tickets, access corporate apps and resources, monitor builds and deploys and app health, all from my code editor (Emacs)? Because I'd rather do that.
Although, his idea almost came to pass: Back in the day, the W3C's reference browser, Amaya, had a built-in HTML and CSS editor allowing for in-place editing of any content the browser could view. You could only save back if you had upload credentials, but still. With continued development, Amaya would have probably grown a JavaScript editor as well.
Although, his idea almost came to pass: Back in the day, the W3C's reference browser, Amaya, had a built-in HTML and CSS editor allowing for in-place editing of any content the browser could view. You could only save back if you had upload credentials, but still. With continued development, Amaya would have probably grown a JavaScript editor as well.
Run VS Code on any machine anywhere and access it in the browser.
https://github.com/cdr/code-server
https://github.com/cdr/code-server
This is the magic that HyperCard provided, and I’ve yet to see anything approach it. Regular people made stuff in HyperCard.
Side point: if you’re here because you’re interested in building solutions for people at scale, then maybe don’t tell users they’re stupid or lazy.
Building something for a mass audience means really understanding their problem, not just throwing solutions at them.
Sure, there’s a developer console. You can enable it, open it up, and then have a blank canvas. Then what? That’s not accessible to 99% of people out there.
Side point: if you’re here because you’re interested in building solutions for people at scale, then maybe don’t tell users they’re stupid or lazy.
Building something for a mass audience means really understanding their problem, not just throwing solutions at them.
Sure, there’s a developer console. You can enable it, open it up, and then have a blank canvas. Then what? That’s not accessible to 99% of people out there.
He is using server side programming environment. Linux won the servers. How hard task is there?
But seriously. There is no market. Browser is a javascript runtime, it is easy to make self-contained HTML like self-contained SWF before.
Nodejs is v8 running on the server. In theory it should be possible to emulate in the browser. In practice someone has to implement that first.
$ pacman -S nodejs python-pip ruby
$ pacman -S ghc lua erlang elixir rust gcc clang postgresql docker podman
But seriously. There is no market. Browser is a javascript runtime, it is easy to make self-contained HTML like self-contained SWF before.
Nodejs is v8 running on the server. In theory it should be possible to emulate in the browser. In practice someone has to implement that first.
Here’s my pitch: build a browser that comes pre-installed with node.js, an IDE and a simple runtime environment.
> Can you imagine if the beginner version of Node.js came pre-installed with a GUI for managing and running your code?
It doesn't even need to come pre installed, as long as the GUI could install node almost silently.
E.g. if VSCode had some intelligence built like when it sees package.json and would prompt "Would you like to install Node" and it would do it's magic if user wanted. Lots of small problems would need to be solved, like where to install it etc.
It doesn't even need to come pre installed, as long as the GUI could install node almost silently.
E.g. if VSCode had some intelligence built like when it sees package.json and would prompt "Would you like to install Node" and it would do it's magic if user wanted. Lots of small problems would need to be solved, like where to install it etc.
oh no, no more things coming with browsers
I think if you’re using GitHub already you should look at Codespaces. It’s VSCode + containers in the GH UI. It sounds like exactly what you want.
I agree! I think the key is to use browsers for all parts of the coding experience. Write your code in the browser and run your code in the browser. Because it turns out a Chrome tab is as good if not better at isolating and running code than a VM or container.
And my company is actually working on this exact thing right now and we'll be sharing more info on how we think it works very soon!
And my company is actually working on this exact thing right now and we'll be sharing more info on how we think it works very soon!
I also get frustrated sometimes when programming, especially in a new language or environment and every time I find the solution to an issue that has taken days to resolve, I wish I had studied computer science. I wish I had learned from the ground up instead of jumping straight into trying to write code because I would of learned WHY.
I'm off to buy a computer science book - any recommendations?
I'm off to buy a computer science book - any recommendations?
Because you haven't found lively kernel.
https://lively-kernel.org/
https://lively-kernel.org/
A significant weakness of Lively is missing proper debugger. Amber (https://amber-lang.net/) has one (but it is not plain JavaScript). The next complaint is that you need to host it.
Ideally, the system should have a good debugger and have an option to be self-hosted like TiddlyWiki (with an option to be served by a normal server). I did some experiment in this regard (https://pavel-krivanek.github.io/amber/amber.html - only "legacy IDE" work) but then you can save it and it will save the new version with all the changes you did as a self-hosted HTML file.
Ideally, the system should have a good debugger and have an option to be self-hosted like TiddlyWiki (with an option to be served by a normal server). I did some experiment in this regard (https://pavel-krivanek.github.io/amber/amber.html - only "legacy IDE" work) but then you can save it and it will save the new version with all the changes you did as a self-hosted HTML file.
I am currently working on something similar to what the OP wants!
NodeSnippets – a cross-platform snippet manager with a Node.js playground. It is in the final stage of development, so if you are curious about it, please leave your email on website below and I'll notify you when the app is available.
https://nodesnippets.com
NodeSnippets – a cross-platform snippet manager with a Node.js playground. It is in the final stage of development, so if you are curious about it, please leave your email on website below and I'll notify you when the app is available.
https://nodesnippets.com
The author can download VSCode, which is an Electron / Chromium app, and write code in it. It has really easy integrations with the command line and lots of other tools as well. It even has features to let you use containerized backends for things like NodeJS. This is almost exactly the solution the author is complaining doesn't exist.
If you can't be bothered to get out of your comfort zone you will hit a brick wall fast as a programmer. I use to be like this guy but the more I decided to take the time to learn the more I began to enjoy learning to the point it has become a hobby to learn and try new things. It is quite empowering.
I can write code in my browser, even without external sites: F12
Also, how can you fail to install something like NodeJS?
Also, how can you fail to install something like NodeJS?
[deleted]
The author brings up a good point. Starting to develop for the web still requires too much setup and configuration. No one likes/wants to be doing this. It would be nice if these were abstracted away so we could focus on actually building products.
Skimming the comments here makes me nostalgic for the days when every Mac came with HyperCard.
I agree with the other comments about the attitude of the post.
But as they mention, it can be hard to install ruby/python. Node is normally much easier. I've given up on getting react native going on my personal laptop, and I do react for a loving.
But as they mention, it can be hard to install ruby/python. Node is normally much easier. I've given up on getting react native going on my personal laptop, and I do react for a loving.
To install Ruby, it helps to have a good guide (but, yes, sometimes they are difficult to find):
https://mac.install.guide/ruby/index.html
https://mac.install.guide/ruby/index.html
Thanks! I use a Mac for work but Linux at home. Got it working in Linux with rvm in the end.
Very much enjoying doing some rails after years of JS
Very much enjoying doing some rails after years of JS
Yes, Rails still has its charms :-)
I'm glad the installation guide was helpful. Here's the full guide for Rails:
https://learn-rails.com/install-rails-mac/index.html
Take look at the `$ rails new myapp --minimal` option that's new in Rails 6.1 It gives you Rails without all the extras. Kind of like a 2010 Rails.
I'm glad the installation guide was helpful. Here's the full guide for Rails:
https://learn-rails.com/install-rails-mac/index.html
Take look at the `$ rails new myapp --minimal` option that's new in Rails 6.1 It gives you Rails without all the extras. Kind of like a 2010 Rails.
Just open devtools, everything is there. Maybe it could be made more visible?
>Ok, once again. I can write code inside my spreadsheet but not inside my browser? WTF.
Technically you can write code in the dev console, or using javascript bookmarklets which is similar to code in a spreadsheet.
Technically you can write code in the dev console, or using javascript bookmarklets which is similar to code in a spreadsheet.
Extensive GitHub use with Node?
Sounds like GitHub Codespaces ought to be up his alley.
https://github.com/features/codespaces
Sounds like GitHub Codespaces ought to be up his alley.
https://github.com/features/codespaces
Well have you tried to get a job as a software developer? It is 1000x harder and if you don't know what the PATH is, you are not passing.
To be hired as a developer you have to know 1000x more, small and not related in any way details.
Now we can start talking about gate keeping, because doing some side project might be hard but there is still a lot of "low code" stuff that you can do. Setup a blog? Go configure wordpress.
If someone wants to be a salaried software developer issues like in this blog post are going to finish his career before it has even started.
I understand that author might be annoyed - but understand how people who are making living out of it are feeling when they are denied job opportunity because they did not know that one trick that interviewer knew...
To be hired as a developer you have to know 1000x more, small and not related in any way details.
Now we can start talking about gate keeping, because doing some side project might be hard but there is still a lot of "low code" stuff that you can do. Setup a blog? Go configure wordpress.
If someone wants to be a salaried software developer issues like in this blog post are going to finish his career before it has even started.
I understand that author might be annoyed - but understand how people who are making living out of it are feeling when they are denied job opportunity because they did not know that one trick that interviewer knew...
https://brandondong.github.io/css-turing-machine/
Literally 7 entries further down.
Literally 7 entries further down.
A while back, I met a fashion designer who is also an expert seamstress. And I do believe most music composers can play the piano. You have to learn to walk before you can fly.
How many music composers have to build their own piano from a kit?
How many programmers have to create their own computer
You absolutely can code with just a text editor and a browser. I built an entire browser RPG like that. You just don't get npm packages or Typescript, which is kinda rough.
I can recommend Electron or Flutter, but I can't do a web search and read docs for the author every time he doesn't know what $PATH means or similar.
Programming is hard to keep us employed.. Imagine how programming is going to be I'm the future when all the kids learning to code at primary school (k5).
We will have to add some more jargon new ways to do things so that the people who are not constantly keeping up to date are left behind. Its always been the way.
As a side note I do wish my browser has better programming tools for design, when I'm doing design I do all the editing in the browser and copy the js/css over when it works or looks nice.
We will have to add some more jargon new ways to do things so that the people who are not constantly keeping up to date are left behind. Its always been the way.
As a side note I do wish my browser has better programming tools for design, when I'm doing design I do all the editing in the browser and copy the js/css over when it works or looks nice.
No matter how easy something gets, some people will spend enough time on it that it becomes "hard" to reach their level.
As for your note about css editing, have you tried Brackets? http://brackets.io/
As for your note about css editing, have you tried Brackets? http://brackets.io/
this title made me think this was about a entirely different thing as I have been writing code inside my browser since 2016.
You can try using console or open debugger or you can build an extension. It will help you to write code inside the browser.
Failed to install node
Failed to install pip
Failed to install ruby
It would be much more beginner friendly learning to play the piano if there weren't all those keys.
The only reasonable use of GUIs is if you need one hand free for jerking off.
A software engineer asking “wtf is user/local/bin in $path”?
Sounds fishy to me.
Sounds fishy to me.
What a useless read
Some tasks are inherently complex. Ask a pilot.
Try running a jupyter notebook in google colab
Wow, I thought I saw dumb stuff but this is next level dumbness (no offense intended). I can't even express how dumb this is with words. Where is the world going ffs
This is what I originally thought of ChromeOS should have been, a new take on a Smalltalk like system, just with JavaScript, but alas Google had other plans for it.
why I can't write code while on a walk through the wildest national parks or strolling along the sea shore...
you can use greasemonkey (or equivalent) to write whatever code you want on whatever page you want in the browser.
[deleted]
Stackblitz is great
Try runkit.com?
You can!
I try to keep my comments nice on HN but in this case I can't, I've met this kind of person many times now and I just can't hold back.
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.
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.
Please don't cross into personal attack and name-calling in HN comments. It's against the site rules: https://news.ycombinator.com/newsguidelines.html.
Indignation commonly gets a lot of upvotes but it's not what we're looking for here.
Indignation commonly gets a lot of upvotes but it's not what we're looking for here.
I was aware of that when I posted, but honestly I'm tired of threads like this even hitting the front page of HN.
What value does this article even add? It's a google query with a rant attached to it.
What value does this article even add? It's a google query with a rant attached to it.
That's a separate question. We need you to follow the rules here regardless of how much value an article adds. Perhaps you don't owe the article better, but you owe this community better if you're posting to it.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
Yeah that's true. I humbly fall on my sword.
What value does this article even add?
You started a 200+ comment value-subtracting subthread so the 'should have stuck to the guidelines' argument seems extra-solid here.
You started a 200+ comment value-subtracting subthread so the 'should have stuck to the guidelines' argument seems extra-solid here.
Well I don't know if it was value subtracting, I learned a lot and there was a lot of interesting discussion about history and attempts at graphical programming environments.
Programming COULD use a lot of simplification and removal of barriers. But still, just like you, I really hate the base attitude 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.
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.
> Programming COULD use a lot of simplification
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.
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.
And yet... when Flash provided a simple, easy, way for people to get into coding using a GUI, there was an explosion of creativity.
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?
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?
Shut down YouTube.
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.
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.
That doesn't make any sense. You don't inspire creativity-explosions by shutting down existing platforms, you do it by providing new affordances, which is what Flash did. And videos aren't even interactive! There's not even any comparison here.
Mass creativity follows the path of least resistance. Existence of YouTube - as a much easier and more social venue for self-expression - precludes mass popularity of Flash vids/games. To beat YouTube, a new affordance must be both easier and more socially appealing (because mass creativity tends to be done mostly to show off in front of friends/colleagues or romantic interests).
> because mass creativity tends to be done mostly to show off in front of friends/colleagues or romantic interests
?? What kind of bizarre red-pill nonsense is this? You think all those interactive Flash microsites were to impress girls? lol
?? What kind of bizarre red-pill nonsense is this? You think all those interactive Flash microsites were to impress girls? lol
I'd love to see someone create a Flash-like IDE for Javascript. ActionScript 3 was originally based off of ECMAscript if I remember correctly, so they're quite similar. What's missing from the web scene is probably mostly an entity component system.
Have you seen Processing or P5.js? I can’t really compare them to what Flash was like, but they’re both extremely accessible ways to make cool artwork, animations, etc. and a great way to learn coding by “making real things.” There’s also a big community and some very nice educational videos.
https://processing.org/
https://p5js.org/
https://processing.org/
https://p5js.org/
Have you looked at the indie game market? Unity rules all right now (yes I know there are other engines but Unity is clearly the big dog). 1000's and 1000's of games developed or being developed. Steam has endless lists of them. A lot of the Flash games moved to Unity but the bar was raised as developers pushed to stand out. So now you Flash game isn't enough to stand out. You need something really special. A perfect example is Team Meat, they made Super Meat Boy and Super Meat Boy Forever. Half of that team started making Flash games and now it's indie games. That pattern has repeated itself over and over. The difference is the delivery platform, it's either mobile games or indie games or both often.
> 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.
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.
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.
I'd argue that Rust is meaningfully simpler than C++. Mind you, it's also a fairly feature-rich language, but the complexity of C++ comes from decades of new features building up trying to supersede older features. C++ is several different languages by now depending on which feature set you use, but Rust is still just one language.
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.
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.
I don't know much about Rust, because it doesn't seem to be the kind of language I want to use, so I can't personally speak to its complexity.
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.
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.
Rust is like a modernized, more well-furnished (and more ergonomic and secure) C. That may sound like C++, but C++ is also the most complicated programming language in existence.
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.
0: https://i.imgur.com/tbEohzT.png
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.
0: https://i.imgur.com/tbEohzT.png
The borrow-checker is a big source of frustration for beginners, because it forces you to write code differently, so it takes a lot of getting used to. But I don't think I would characterize it as a source of complexity in the language. Frankly, once you get used to it, it makes the language simpler, because it means you don't need to worry about shared mutability. The complexity that does exist tends to come from the zero-cost no-copy abstractions which rust is so fond of, or `unsafe`, which exposes you to a whole world of complexity which safe rust protects you from.
> The former is so sick of C++ he's making his own programming language,
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.
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.
Yeah like there's 20 years of programming language research that studies exactly what this person is talking about.
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?
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?
> Yeah like there's 20 years of programming language research that studies exactly what this person is talking about.
More like 50 years. :)
More like 50 years. :)
Relevant alan kay video from 1968
https://youtu.be/QQhVQ1UG6aM
Nothing in the article said “why hasn’t this been researched by the CS community?” The author was complaining about the state of things, and I don’t disagree. Programming is too hard. Error messages are always funky and assume expertise. And perhaps the node folks should better understand that beginners are often a target of their product and should find ways to make it more accessible to them.
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.
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.
To be fair, c++ is too complicated, but that's an unrelated conversation, haha.
Even hardworking developers will sometimes don't care about the user experience. For example, Linus could have spent a few hours polishing the git CLI. Instead we have had millions of developer hours wasted in making sens of the CLI inconsistencies...
There is also infinite configurability and plugability through aliases and plugins.
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.
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.
IMO sane defaults are sometimes worth more than infinite extensibility.
IMO extensibility generally means the authors dont know how real people will use software.
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...
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...
> Programming COULD use a lot of simplification
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.
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.
> 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 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.
I don’t think it’s because they forgot to vet their dependencies. I think it’s because there’s a culture of “just get it done” that fosters short cuts, and it’s coupled closely with a culture of worship around open source as if it should be implicitly trusted.
The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
The result has been a massive proliferation of perpetually-junior engineers writing code and rising in ranks to run things.
The worst kind of toxicity is when your senior engineers and team leads are actually junior engineers.
It’s hard to be too hard on them though: they never had proper mentorship as junior engineers and their practices are reinforced by modern practices.
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.)
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.)
But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things?
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
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
> But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things?
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:
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.
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.
That's a fair argument to make, however i'm not sure that i'm able to entirely agree to this.
> 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
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.
> 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.
All of those are very good points!
> 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.
> 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.
Wow, I felt that talk in my bones. It reminds me of the languages I cut my teeth on: visual basic and hypercard. You just get to make stuff and it is liberating.
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.
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.
Your evaluation criteria left out "does new dependency conflict with any other dependency in the system". In which case a minimal set of dependencies is attractive because it reduces likely hood of conflicts and reduces effort to determine conflicts with dependencies added in the future.
> But isn't using the code that people smarter/more proficient than you have developed a rather good way to go about things?
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.
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.
I think the author is not talking about career programming. If that's your job, you have no excuses not learning command lines and all the other stuff.
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.
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.
I want the play the piano but don't want to put in the time. Answer "don't be lazy". I want the learn to dance but don't want to put the time. Response: "Don't be lazy".
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.
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 want the play the piano
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 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.
Following that logic.
> I want an app to do X but I don't want to learn how
Just hire someone to make it for you
> I want an app to do X but I don't want to learn how
Just hire someone to make it for you
> As a general rule, I consider all "don't be lazy" arguments wrong.
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.
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.
When you put it this way, it makes perfect sense. My first computer C64 came with Basic pre-installed and that's how an eight year old learned to code. I guess the equivalent would be, that there would a button 'code' on the browser UI, and that would lead the user onwards.
Open the Developer Console. Get cracking.
Dev console is a debugger, not a code editor. It's useful for us to assist in developing web applications. It's far less useful for a non-engineer to tinker around with and make simple things.
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.
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.
Exactly, that's what is weird about the whole premise of the article.
Well, a developer console with "import" support and some GUI frontend to npm would be something the author wants. Sounds not that hard, right?
I think the barriers are lower. As a kid, my obstacles were things like not having access to a free compiler. Or maybe I could have gotten a free one but I was a kid and the only ones I was aware of were hundreds of dollars, way out of reach. Now I can download any compiler I want for free, as well as tools like VSCode, Visual Studio etc. Also there are environments like Dr. Racket, which are awesome and can be used to build basically any kind of application, and come with all the tutorials at your fingertips.
> I think the author is not talking about career programming.
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.
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 don't know. I've been that guy, except I didn't whine about it in a blog post. I didn't know anyone who knew these things and didn't know how to find answers. Naive web searches were surprisingly hard to parse. I didn't even know Youtube had coding instruction. I ended up doing all my coding inside Google Sheets custom function editor. It let me log my output or be invoked in a cell on the sheet. Looking back that seems so strange, but what I realized is that all the setup instruction for it is directed at non-coders so they don't make any assumptions like the install modal on NodeJS that TFA complained about. All the tutorials and quora (eventually found SO) questions on Google sheets are asked and answered by laypeople.
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.
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.
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.
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.
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.
Agreed.
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!
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!
None of that complexity, as it exists today, is particularly irreducible.
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 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.
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 don't think this of math
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.
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 100% correct on everything.
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 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.
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.
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.
What you are really complaining about is the fact that nobody is there to shout in your face that these options exist.
Can you do that for node.js, like the person in the linked article wants to use?
I haven't used it but https://glitch.com looks like it's what they want.
This reminds me of the timeless quote:
> 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 :)
> 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 :)
>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.
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.
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.
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.
>Programming is in some cases over-complicated, for no reason.
Which part is over-complicated for no reason?
Which part is over-complicated for no reason?
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.
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
That's your example? Really?
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?
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.
Some are essential complexity, sure. But many aren't.
>It's a trivial example, but a valid one.
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.
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.
Most of us don't have the scaling issues that Google or Facebook have but we use tools as if we did.
Again, do you have a specific 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
I can get my shopping list by simply creating a file on my machine
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
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
> 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.
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.
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.
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?
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!
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?
> please explain to me what does make someone clever?
Dismissing other people’s work as awful, pointless on the Internet. Well, at least it makes you look clever, in certain eyes.
Dismissing other people’s work as awful, pointless on the Internet. Well, at least it makes you look clever, in certain eyes.
"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.
Which one? Please explain how it's pointless. What is esoteric about typing which program you want to run?
I love the command line and use it all the time.
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"
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"
Oh oh. I read the HN article about why it's called `grep`.
g - global re - regex p - print
https://en.wikipedia.org/wiki/Grep#:~:text=Its%20name%20come....
g - global re - regex p - print
https://en.wikipedia.org/wiki/Grep#:~:text=Its%20name%20come....
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.
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.
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.
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.
-v for verbose
-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).
-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).
Unless it's -V for verbose. Or -i for infile. Or no flag for infile. Or no flag for outfile. Or...
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.
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.
I addressed these points in one of my comments a while ago:
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.
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.
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?
This smells a bit like PowerShell.
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.
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.
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.
[0] https://wayland.freedesktop.org/faq.html#heading_toc_j_8
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
"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.
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.
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.
Thank you, you understand my point correctly. It's frustrating that most of the responses think that X11 is a solution to this.
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]
[0] https://github.com/stolk/imcat
If you want a very basic GUI over SSH without a full-blown GUI like with X11, you already have the option of using a TUI like Midnight Commander. You can preview images on the command-line, with a tool like imcat. [0]
[0] https://github.com/stolk/imcat
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
If we rebuilt the command line today it would be massively better
Interestingly enough these are both solved problems when using iTerm on macOS.
Ctrl+C sends SIGINT, while CMD+C copies text, and running commands when a newline is pasted can be disabled.
Ctrl+C sends SIGINT, while CMD+C copies text, and running commands when a newline is pasted can be disabled.
ðɪ ˈɪŋɡlɪʃ ɪz pˈɔɪntləs. ɪt kəntˈeɪnz ɐ mˈasɪv ɐmˈaʊnt ɒv kəmplˈɛksɪti and ˌɒbfəskˈeɪʃən ðat ˈəʊnli ɛɡzˈɪsts bɪkˈʌz ðats hˌaʊ ɪt wɒz ˈɔːlweɪz dˈʌn and nˈəʊbɒdˌi dˈeəz tʃˈeɪndʒ ɪt ˌɛni lˈɒŋɡə
Shell (just like language) is a medium. We use it to communicate our ideas, not because it is great or flawless.
Shell (just like language) is a medium. We use it to communicate our ideas, not because it is great or flawless.
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).
just pointing out the obvious.
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.
The vaguely-standard Unix shells, yes.
Not using a complicated system when you don't have to.
Node.js is a command line program, intended for writing server side applications on headless servers.
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
What would be the layer below it? It's certainly not GUIs, which are a significantly more complex layer of abstraction.
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)
That's like people expecting to be able to repair their TV with their remote control.
Some TVs just don't break
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.
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.
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.
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.
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.
The command line is 100% superfluous.
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.
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.
And why would anyone want that?
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.
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.
No, I'm saying that your kitchen should contain plastic spoons and silicone bowls too, because that's easy for a 2 year old to grasp.
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.)
(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.)
Very well said. I like your analogy here.
> 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.
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.
> Wow, if I ever saw a comment on HN that was fundamentally wrong on many levels, this was it.
You must not visit political threads much.
But seriously, you could have said that in a constructive way.
You must not visit political threads much.
But seriously, you could have said that in a constructive way.
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?
> Question is, is it necessary for programming?
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?
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?
What warrants this fanatical devotion to command line iterfaces while people have been happily coding without them for decades?
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).
Please demonstrate your simple alternative and its acceptance testing on real users.
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.
[0] https://tutorials.yax.com/learn/your-first-custom-html-tag/i...
[0] https://tutorials.yax.com/learn/your-first-custom-html-tag/i...
Why? You are allowed to point out failings without having a perfect solution at hand.
It's just kind of .. pathetic, to make statements like:
> 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.
> 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.
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.
You do realize some of us use command line not because we have to, but because it’s usually easier to do so?
Yes, of course. Because your other tools are so bad that even the command line is easier.
I am saying, the fact that those tools are bad is not a given. We could have better tools.
I am saying, the fact that those tools are bad is not a given. We could have better tools.
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.
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.
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.
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.
And it's very domain-specific, which is why it's super easy to make it so simple.
https://news.ycombinator.com/newsguidelines.html
> 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)
> 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)
He's asking you to back up your assertations. If all you have is an easily produced vague thought then it can be dismissed just as easily.
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)
I hate it...
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...
> 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.
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.
How? It seems like you and the author are at the same energy level of complaining without putting up real ideas. How would you “fix” programming then?
It's time to refactor the last ten years of professional web development.
>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.
Like what?
Like what?
> 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 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.
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.
Visual programming can work in specific domains. But I've never seen it used in large general purpose systems.
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.
That is because it is not good for large general purpose systems. But it is good for specific domains.
I think both points are true.
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.
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.
He's not just lazy, he lacks some basic understanding:
> 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.
> 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.
That one statement makes me almost convinced that this is satire.
Yes it very well could be.
"When someone says 'I want a programming language in which I need only say what I wish done,' give him a lollipop."
Epigram 93, Alan Perlis
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Epigram 93, Alan Perlis
http://www.cs.yale.edu/homes/perlis-alan/quotes.html
Yeah... you're being a bit unkind, but you're not wrong. The author mentions having "failed to install pip" — pip isn't exactly challenging to install. There's a base of important technical knowledge here that they don't have, and any GUI would just be a bandaid which prolongs the period for which they can get by without learning.
Software development is hard and complex.
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 ...
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 ...
I've always liked this design philosophy by Alan Kay[1]:
> Simple things should be simple. Complex things should be possible.
[1]: https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad...
> Simple things should be simple. Complex things should be possible.
[1]: https://www.quora.com/What-is-the-story-behind-Alan-Kay-s-ad...
Oh my god you're so right. I read your comment first, and though "man, there's no way that article is that bad!"
It is, though. It really is.
He's some kind of self-anointed "thought leader" and "consultant". Because, honestly, of course he is.
It is, though. It really is.
He's some kind of self-anointed "thought leader" and "consultant". Because, honestly, of course he is.
> "People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. "
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?
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?
> 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).
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).
Thank you!!! Finally someone can say it. I've being extremely frustrated by developers who don't want to learn coding and just jumping on the band wagon cause it is the "IN" thing now.
That is the best way to describe it, it's a bandwagon, they've been told everyone can code, and when they find they can't, they believe it must be the programming ecosystems fault, and not that they just aren't suited to being a programmer.
There's nothing wrong with not being good at something.
There's nothing wrong with not being good at something.
Everyone will go through anger and frustration phase. Be supportive.
I make no opinion on the author but something like this: https://twitter.com/ibdknox/status/1328797793138266113?s=20
Does make me think programming can be radically different and maybe a lot easier
Does make me think programming can be radically different and maybe a lot easier
Doubt it. While it looks cool, what it does is hide a lot of complexity in its standard library and presents only the surface layer - all bolted down to (what seems to be) an overcomplicated NLP processor (but what more likely is just someone playing with Illustrator) that you have to hand-hold to verify it generates sensible code.
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.
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.
This is like Spring Roo. Didn't really get off the ground.
> The author is lazy, and is channeling his energy into complaining rather than learning.
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.
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.
[deleted]
No, this is wrong, it has nothing to do with laziness.
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.
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.
You... can do this in Github.
In some cases, and in a limited way, yes, but it's clearly not well integrated yet.
Even the 'local' version of software development is a giant mess, we have not well thought out dependencies, tool chains etc..
Even the 'local' version of software development is a giant mess, we have not well thought out dependencies, tool chains etc..
I'm not a software engineer, nor a comp sci grad, nor a professional coder. I've ranted on HN about bad documentation in programming before (Lisp being a notable target of my ire recently), and I'm by no means an expert. But when you have someone who by his own admission can't install node.js, pip, or ruby and yet claims
>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
>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
For that matter, I apparently already have ruby installed and I don't know when or why that happened. I don't use the language.
(Ubuntu 18.04, maybe it just came with this distro?)
(Ubuntu 18.04, maybe it just came with this distro?)
> "People hate command lines - not only do they LOOK scary, they give weird unhelpful error messages and… you have to type everything. Ugh. "... I have no patience any more for lazy know it alls
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.
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.
No, I do not think you have understood my argument.
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.
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.
100% agree. I immediately stopped reading as soon as he said "wtf is a user/local/bin in path?" Someone that ignorant of the absolute basics of how a computer works has no business complaining about the user-friendliness of programming.
With a little bit of charity, I don't take it as a serious rant ("I can't believe we have to deal with this stuff! I demand it be made easier!") so much as musings about possibility ("How much better could this be? In what ways?"). I think the tone is a little bit exaggerated on purpose, for effect, as if one is imagining a future world in which we've progressed so much that 2020's status quo really does become unacceptable.
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.
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.
I agree with you to an extent.
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.
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.
You probably should've held back.
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.
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.
Absolutely not. I'm not sure why programming is the one field people make a joke of. It doesn't happen in any other field that I'm aware of. Hear me out.
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.
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.
God I would hate to have this type of behavior as coworkers. I can't imagine what a "certification for programming" would even look like. Programming is a completely different field than others - it's exactly that type of difference that has made programming far more welcoming than others.
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.
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.
Bret Victor's, "The Future of Programming" is illuminating. He walks through what "programming" means and how the concept of "programming" has shifted in little evolutionary leaps.
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?
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?
[deleted]
Who/what kind of tech person doesn't know or complains about user/local/bin... this is like.. basics man..
I think the person is trolling.
I think the person is trolling.
The author can't seem to make a basic google search either.
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.
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.
Yes, I love the CLI too. It’s quite efficient for many tasks.
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.
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.
I agree with you 100%, but also to be fair node, pip, and ruby can be incredibly frustrating to install in some scenarios.
The author seems to be confusing building software with using software. We can build higher level software that allows people to do more (excel), but someone still has to know how all that works (and even what /usr/local/bin and $PATH is) and be able to work at the lower layers. That is what a software engineer is. Do we need to marginalize and inclusive-ise everything to death?
How is your comment different from his post?
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.
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.
You have not read the article.
>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.
>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.
Look, I don't care about which editor you use: want to use vim? Fine, use it. Prefer Emacs? Looks good. You really like nano? Perfect! But for god sake don't expect that someone will ever take you seriously if you say you are experienced and don't know how to use a cli. How can you even work with computers not knowing what $PATH (yes, this exists on windows too fyi) is? This is just dumb. I'd also add: stop using javascript, don't, just don't (or, better, use vanilla-js).
> you have to type everything
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.
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.
There people are not made to be programmers. Having tried various visual tools over the years, they are at best no better than writing code, and at worst a lot less productive and powerful. They are only suitable for very basic tasks like email journeys.
The author sounds like he wants to just be a web Designer. In which case he can work inside his browser, using tools such as WebFlow.
He even goes on to quote himself (sigh) as a proof of what he proposes.
Look, maybe someone just explained it badly to you, and you should look it up for yourself. However, if the command line looks scary to you... wait until you read bad documentation :)
My point is: yes, programming is awesome. But just like it's hard to become a good musician if you shy away from sheet music, programming is hard if you shy away from command line and a little web searching to know what $PATH is.
If that is your mindset, then maybe it's just not for you. There's still plenty of awesome things you can do in IT without ever touching code, though. Machine learning is accessible from nice UIs now. I used that, it's great.
As pointed out by others, there's also plenty of websites where you can either try things, or build complete projects. AWS, for one, has a fully browser-based editor for Lambda. Look it up, it might be the solution for you.