2 ms·

Hmm... We don't seem to be connecting here. When I said "there is no better way to do it", I meant that interacting with tools through the command line (or she

Hmm... We don't seem to be connecting here. When I said "there is no better way to do it", I meant that interacting with tools through the command line (or shell scripts) is the best way we have of doing these kinds of tasks. I didn't say so explicitly, but my intention was to include all of the usual tools that one would use (grep, awk, make, whatever). Though it was several decades ago, I also suffered greatly from having to deal with poorly built academic projects. It's not even confined to academia. A friend of mine often tells a tale of a start up who spent 3 years building software only to discover that they had built such a mess that they couldn't deploy (never having done it in 3 years... :-P). The company ran out of money before they solved the issue. I may be wrong, but I don't think that's what the original article was complaining about. I think he was frustrated that while the tools were very good, they were hard to teach to his students. He wishes there were easier to learn systems for doing this work. Personally, I don't think it will ever happen because the problem space is quite complicated. You can make it easier to learn by restricting what it can do, but eventually you butt up against that ceiling, making it extremely difficult to use. That's why we are all still using these same tools decades years later (although, I'm quite happy to ditch make in favour of more modern equivalents [1]) I can't tell you the number of times I've wandered into a new project and spent every spare second writing README files, fixing the build systems, removing dead code, etc. I've even worked on projects where there wasn't a single person who knew how to build the entire project -- all they could do was compile individual files and link it to pre-built libraries. They thought me crazy for even wanting to know how to build it. We do our industry a grave disservice by not teaching this stuff somewhere in our education system. [1] Says the guy who just wrote a new make file a couple of weeks ago <whistling>

a_bonobo 11y ago
I appreciate your post! I do agree that awk, grep etc. are extremely good tools, and you rarely run into real annoyances with them (actual scientific software is a completely different bag of problems that suffers from different problems). Still, there's lots of room for improvement even in the good tools [1] and I feel like it's easy to stop thinking about the problem space, and shut out others who don't immediately grok what's going and why you've now run "apt-get update" instead of "apt-get upgrade". Many posts in this thread show that attitude. I do think at some point we'll get easier systems - git has now overtaken cvs in popularity so these tools aren't set in stone, even though both aren't easy to understand for beginners, git is just more powerful. I see people write tiny Python scripts instead of using bash-tools to manipulate folders and files, I think that is a case of taking up a tool because it's easier to use. Are there other tools that are slowly fading out? I feel like awk is on the way out but that may be my echo-chamber. >We do our industry a grave disservice by not teaching this stuff somewhere in our education system. I fully agree - I think that some hands-on programming, understanding and refactoring experience is much more important than knowing how to write the code to keep a b-tree balanced. The first is something you have to do every few weeks - the latter is something you do only once or twice, if ever (even though it's a cool application of recursive thought). The first will make you a more valuable member of the workforce. [1] One example: when I teach people git I struggle to show the man-pages because nothing in there makes sense until you've truly understood how git works under the hood

a_bonobo 11y ago

I appreciate your post! I do agree that awk, grep etc. are extremely good tools, and you rarely run into real annoyances with them (actual scientific software is a completely different bag of problems that suffers from different problems). Still, there's lots of room for improvement even in the good tools [1] and I feel like it's easy to stop thinking about the problem space, and shut out others who don't immediately grok what's going and why you've now run "apt-get update" instead of "apt-get upgrade". Many posts in this thread show that attitude. I do think at some point we'll get easier systems - git has now overtaken cvs in popularity so these tools aren't set in stone, even though both aren't easy to understand for beginners, git is just more powerful. I see people write tiny Python scripts instead of using bash-tools to manipulate folders and files, I think that is a case of taking up a tool because it's easier to use. Are there other tools that are slowly fading out? I feel like awk is on the way out but that may be my echo-chamber. >We do our industry a grave disservice by not teaching this stuff somewhere in our education system. I fully agree - I think that some hands-on programming, understanding and refactoring experience is much more important than knowing how to write the code to keep a b-tree balanced. The first is something you have to do every few weeks - the latter is something you do only once or twice, if ever (even though it's a cool application of recursive thought). The first will make you a more valuable member of the workforce. [1] One example: when I teach people git I struggle to show the man-pages because nothing in there makes sense until you've truly understood how git works under the hood