241–250 of 624 posts
Earlier quoted context omitted.
/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 sho…
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…
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.
Earlier quoted context omitted.
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. Th…
> 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 u…
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?
Earlier quoted context omitted.
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.
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 ca…
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?
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…
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…
Earlier quoted context omitted.
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 th…
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 mor…
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 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…
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 th…
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.
Earlier quoted context omitted.
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)
Earlier quoted context omitted.
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…
-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).