5 ms·

When you start looking at the code of the tools, and how older systems were design, it's really is a testament to good engineering practices because it all scal

by jecxjo 8y ago

When you start looking at the code of the tools, and how older systems were design, it's really is a testament to good engineering practices because it all scales so well. Small, simple, "one task well" utilities that process data in streams means the megabyte files of the 80's and 90's are today's terabytes. Sure they require some work to get things scripted correctly but it really is pretty amazing what coreutils and a shell script can do.

molotovbliss 8y ago
There Unix philosophy. https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy It's a shame to see so much bloated, over abstracted development these days with more emphasis on delivery than doing one thing well. https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene After seeing what the demo scene is able to pull off in very little code makes me hope that the art of fundamentals & single responsibility principals like in Unix/Linux resonates with younger developers the ability of truly understanding a problem scope before implementing a solution. Above all else have fun with it, be curious on even a low level how your program functions at an os & hardware levels. Things like what is the von Neumann bottleneck? Or even those building boolean logic gates in minecraft is inspiring to want to know "how does it work? And why?"
- bleachedsleet 8y ago
  You see this in malware development a lot as well, the search for smaller and more efficient executables that use a minimum of code to function.
- molteanu 8y ago
  Also a nice read: The art of writing Linux utilities (Developing small, useful command-line tools) [0] [0] http://people.fas.harvard.edu/~lib113/reference/unix/writingtools.html http://people.fas.harvard.edu/~lib113/reference/unix/writing...
  - vram22 8y ago
    A tutorial I had written for IBM developerWorks, titled "Developing a Linux command-line utility" (in C), is mentioned in the Resources section of that page ([0]) above. But that article was archived from the IBM dW site some time ago, after being there for some years. However, I wrote to IBM and got the PDF of the article, and put it on my Bitbucket account, with the C code for the utility. This post on my blog describes the article: https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-article.html https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-ar... And here is the Bitbucket project for selpg, the utility used as a case study, with the C code and the article text (as PDF): https://bitbucket.org/vasudevram/selpg https://bitbucket.org/vasudevram/selpg The article and all the source files are here: https://bitbucket.org/vasudevram/selpg/src https://bitbucket.org/vasudevram/selpg/src It may be of use to people who want to progress beyond using Unix / Linux command-line utilities (in C, but the principles and techniques can be adapted to other languages like Python, Ruby, etc.), to writing such utilities themselves, along with integrating them into shell scripts and pipelines.
jpfr 8y ago
You might appreciate the original implementation of awk. Good engineering everywhere. https://github.com/RetroBSD/retrobsd/tree/master/src/cmd/awk https://github.com/RetroBSD/retrobsd/tree/master/src/cmd/awk
- cat199 8y ago
  Updated, but still the original: https://github.com/onetrueawk/awk https://github.com/onetrueawk/awk
__sr__ 8y ago
The difference is that most of the things back in 60s, 70s and 80s were built by people who were actually passionate about computers and programming. Then the career types took over — the ones who spend more time planning sprints and following SCRUM practices and figuring out ways to exaggerate what they do than they spend writing actual code. Of course, some of the blame can be laid on the feet of the people who fancy themselves engineering manager because they happen to have an MBA — despite the fact that they can’t Engineer their way out of a paper bag.

by jecxjo 8y ago

molotovbliss 8y ago

There Unix philosophy. https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy It's a shame to see so much bloated, over abstracted development these days with more emphasis on delivery than doing one thing well. https://en.wikipedia.org/wiki/Demoscene https://en.wikipedia.org/wiki/Demoscene After seeing what the demo scene is able to pull off in very little code makes me hope that the art of fundamentals & single responsibility principals like in Unix/Linux resonates with younger developers the ability of truly understanding a problem scope before implementing a solution. Above all else have fun with it, be curious on even a low level how your program functions at an os & hardware levels. Things like what is the von Neumann bottleneck? Or even those building boolean logic gates in minecraft is inspiring to want to know "how does it work? And why?"

bleachedsleet 8y ago
You see this in malware development a lot as well, the search for smaller and more efficient executables that use a minimum of code to function.
molteanu 8y ago
Also a nice read: The art of writing Linux utilities (Developing small, useful command-line tools) [0] [0] http://people.fas.harvard.edu/~lib113/reference/unix/writingtools.html http://people.fas.harvard.edu/~lib113/reference/unix/writing...
- vram22 8y ago
  A tutorial I had written for IBM developerWorks, titled "Developing a Linux command-line utility" (in C), is mentioned in the Resources section of that page ([0]) above. But that article was archived from the IBM dW site some time ago, after being there for some years. However, I wrote to IBM and got the PDF of the article, and put it on my Bitbucket account, with the C code for the utility. This post on my blog describes the article: https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-article.html https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-ar... And here is the Bitbucket project for selpg, the utility used as a case study, with the C code and the article text (as PDF): https://bitbucket.org/vasudevram/selpg https://bitbucket.org/vasudevram/selpg The article and all the source files are here: https://bitbucket.org/vasudevram/selpg/src https://bitbucket.org/vasudevram/selpg/src It may be of use to people who want to progress beyond using Unix / Linux command-line utilities (in C, but the principles and techniques can be adapted to other languages like Python, Ruby, etc.), to writing such utilities themselves, along with integrating them into shell scripts and pipelines.

jpfr 8y ago

You might appreciate the original implementation of awk. Good engineering everywhere. https://github.com/RetroBSD/retrobsd/tree/master/src/cmd/awk https://github.com/RetroBSD/retrobsd/tree/master/src/cmd/awk

cat199 8y ago
Updated, but still the original: https://github.com/onetrueawk/awk https://github.com/onetrueawk/awk

__sr__ 8y ago

The difference is that most of the things back in 60s, 70s and 80s were built by people who were actually passionate about computers and programming. Then the career types took over — the ones who spend more time planning sprints and following SCRUM practices and figuring out ways to exaggerate what they do than they spend writing actual code. Of course, some of the blame can be laid on the feet of the people who fancy themselves engineering manager because they happen to have an MBA — despite the fact that they can’t Engineer their way out of a paper bag.