3 ms·

Well, I'd put some limits on this. If a coworker cobbled together something that still let them program by punch card then I'd 1) probably be frustrated with th

Well, I'd put some limits on this. If a coworker cobbled together something that still let them program by punch card then I'd 1) probably be frustrated with their level of output and 2) impressed at the setup. 3) asking for their extra set of eyes on my own code because if they had the patience for punch cards they would probably be better than me at catching errors.

rascul 5y ago
I would probably be wondering where the machine is kept that reads punch cards. And how to use it. And how do I make punch cards. Then, after all that, your list seems like it would suffice.
- ineedasername 5y ago
  where the machine is kept that reads punch cards In my mind I envisioned in on their desk in the next office over that looked like something out of the movie "Brazil" and machines on the desks during the Central Services scene [0] [0] https://www.youtube.com/watch?v=V-yXL-LDMyg https://www.youtube.com/watch?v=V-yXL-LDMyg
KronisLV 5y ago
As funny as the mental image is, that's a fair point. Clearly pick whatever suits the needs of the team, if you're developing something together with others. But just in general, don't scoff at technologies just because they're not currently popular: there are a few problems out there that can be fixed really nicely within something like Prolog, Lisp or another seemingly dated language. Admittedly, nowadays there's perhaps too much focus towards using walled gardens, as opposed to piping some data through a few Bash scripts or maybe embedding Lua in a larger executable for some more dynamic functionality. Of course, those are just some overly general examples, but getting discouraged from a good solution just due to peer pressure isn't exactly optimal. Having technologies that don't have good documentation due to never having been popular in the first place, or that are difficult to run or utilize nowadays, however, is a different story entirely. Where punch cards would fit into all of that, however, i'm not sure as of yet. :)

rascul 5y ago

I would probably be wondering where the machine is kept that reads punch cards. And how to use it. And how do I make punch cards. Then, after all that, your list seems like it would suffice.

ineedasername 5y ago
where the machine is kept that reads punch cards In my mind I envisioned in on their desk in the next office over that looked like something out of the movie "Brazil" and machines on the desks during the Central Services scene [0] [0] https://www.youtube.com/watch?v=V-yXL-LDMyg https://www.youtube.com/watch?v=V-yXL-LDMyg

KronisLV 5y ago

As funny as the mental image is, that's a fair point. Clearly pick whatever suits the needs of the team, if you're developing something together with others. But just in general, don't scoff at technologies just because they're not currently popular: there are a few problems out there that can be fixed really nicely within something like Prolog, Lisp or another seemingly dated language. Admittedly, nowadays there's perhaps too much focus towards using walled gardens, as opposed to piping some data through a few Bash scripts or maybe embedding Lua in a larger executable for some more dynamic functionality. Of course, those are just some overly general examples, but getting discouraged from a good solution just due to peer pressure isn't exactly optimal. Having technologies that don't have good documentation due to never having been popular in the first place, or that are difficult to run or utilize nowadays, however, is a different story entirely. Where punch cards would fit into all of that, however, i'm not sure as of yet. :)