3 ms·

Taco Bell Programming

36 points by andyjpb 8y ago

gpapilion 8y ago
I’m not even sure how to interpret this. It’s sort of a know your tools post, with a hint of don’t over optimize. Having done both the Hadoop and shell script type solutions, generally error handling and debugging are what cause you to move into blatform solutions.
- Sohcahtoa82 8y ago
  To me, it was more of an "don't over-engineer" post. As another example I could see the author using...if you have tasks to run on a regular basis, do you really need Jenkins? Or will cron do just fine?
DLA 8y ago
There's a lot to be said for this approach. With the size of today's machines (say a TB of RAM, 16/32/or more cores, many TB of SSD) you can do a stunning amount of work with smart programming. For example, I've developed a tool to do some file processing that uses Go's excellent concurrency mechanisms to reach speeds of ~40-50k files/second on a moderate laptop.
yellowapple 8y ago
Reminds me a bit of "Master Foo and the Ten Thousand Lines"[0], except replacing C code with a bunch of stuff in The Cloud™. The problem with Taco Bell Programming is that those "ingredients" need to be versatile enough to actually be useful enough to not warrant reinventing their wheels. Unfortunately, that usually translates into complexity, ever-growing manpages, etc. If you're only using 8 ingredients, it's pretty unlikely that any of those ingredients are going to stick to the Unix philosophy of doing one thing and doing it well. Additionally, at some point the task does end up being complex enough or atypical enough to involve coding for different corner cases and such. The only thing I'd dread more than ten thousand lines of C is ten thousand lines of Bash. [0]: http://catb.org/esr/writings/unix-koans/ten-thousand.html http://catb.org/esr/writings/unix-koans/ten-thousand.html
dimator 8y ago
Yes, there's merrit to this, but up to a point. The problem is that the "glue" you're using to connect your ingredients is bash, and that quickly gets unwieldy >100 lines or so.
- tluyben2 8y ago
  I always keep cutting to seperate script files which I call. Makes it more reusable and clearer imho. Like the author, I do a lot in bash and I do not have scripts even close to 100 lines: I do have 1000s of scripts though. Works well for me.

36 points by andyjpb 8y ago

I’m not even sure how to interpret this. It’s sort of a know your tools post, with a hint of don’t over optimize. Having done both the Hadoop and shell script type solutions, generally error handling and debugging are what cause you to move into blatform solutions.

Sohcahtoa82 8y ago
To me, it was more of an "don't over-engineer" post. As another example I could see the author using...if you have tasks to run on a regular basis, do you really need Jenkins? Or will cron do just fine?

DLA 8y ago

There's a lot to be said for this approach. With the size of today's machines (say a TB of RAM, 16/32/or more cores, many TB of SSD) you can do a stunning amount of work with smart programming. For example, I've developed a tool to do some file processing that uses Go's excellent concurrency mechanisms to reach speeds of ~40-50k files/second on a moderate laptop.

yellowapple 8y ago

Reminds me a bit of "Master Foo and the Ten Thousand Lines"[0], except replacing C code with a bunch of stuff in The Cloud™. The problem with Taco Bell Programming is that those "ingredients" need to be versatile enough to actually be useful enough to not warrant reinventing their wheels. Unfortunately, that usually translates into complexity, ever-growing manpages, etc. If you're only using 8 ingredients, it's pretty unlikely that any of those ingredients are going to stick to the Unix philosophy of doing one thing and doing it well. Additionally, at some point the task does end up being complex enough or atypical enough to involve coding for different corner cases and such. The only thing I'd dread more than ten thousand lines of C is ten thousand lines of Bash. [0]: http://catb.org/esr/writings/unix-koans/ten-thousand.html http://catb.org/esr/writings/unix-koans/ten-thousand.html

dimator 8y ago

Yes, there's merrit to this, but up to a point. The problem is that the "glue" you're using to connect your ingredients is bash, and that quickly gets unwieldy >100 lines or so.

tluyben2 8y ago
I always keep cutting to seperate script files which I call. Makes it more reusable and clearer imho. Like the author, I do a lot in bash and I do not have scripts even close to 100 lines: I do have 1000s of scripts though. Works well for me.