4 ms·

That's a nice chart to keep in mind, but kinda tangential. Joe's point is that with the right tools, it is sometimes faster to write your own solution than it

by clarry 7y ago

That's a nice chart to keep in mind, but kinda tangential. Joe's point is that with the right tools, it is sometimes faster to write your own solution than it is to pick one from all the available canned solutions and learn to build & install & configure & use it (and figure out what to do when it doesn't work like it's supposed to).

zimpenfish 7y ago
> Joe's point I think his point is more it's faster to solve the problem you have ("I want to get files from machine X") rather than the problem you imagine you have ("I need an FTP server") - it's just wrapped up in "I solved it myself using Erlang".
- clarry 7y ago
  Well both Joe's program and an FTP server & client are possible solutions to the problem "I want to get files from machine X." But I very much agree that the speed of the custom solution can in large part be attributed to the fact that you can reject the cost and complexity of existing solutions like FTP (which set out to solve more than just Joe's immediate problem). Similarly, I often transfer files by piping them to netcat. EDIT: the point about tools still stands. For example: host1$ nc -l 1234 > my.file host2$ cat my.file | nc host1 1234 This is very easy to do given that unix is my toolbox. It'd be much more involved to write from scratch in (say) C. On the other hand, Joe's tool is much more powerful; it doesn't require him to manually interact with the shell on two different hosts, and his program can list files on the remote host and automatically download them under the correct name whereas I'm stuck manually redirecting nc's output to the right file (and cursing myself when I accidentally forget to change the name and overwrite a file I wasn't supposed to fetch). Those features were very easy to add to his program because Erlang is a powerful tool. On unix shell, it's much harder.
  - gmfawcett 7y ago
    Consider adding 'tar' on each side to avoid naming errors. If you squint just right, 'tar' is "the pipe fitting that remembers what things used to be called." :)
- hinkley 7y ago
  The good people formulate their handwritten solution in a way that invites other people to replace it with a library. This is the best of both worlds. The bad ones get us stuck with that solution for a very long time. These are the experiences that prompt people to post to threads like this.

by clarry 7y ago

zimpenfish 7y ago

> Joe's point I think his point is more it's faster to solve the problem you have ("I want to get files from machine X") rather than the problem you imagine you have ("I need an FTP server") - it's just wrapped up in "I solved it myself using Erlang".

clarry 7y ago
Well both Joe's program and an FTP server & client are possible solutions to the problem "I want to get files from machine X." But I very much agree that the speed of the custom solution can in large part be attributed to the fact that you can reject the cost and complexity of existing solutions like FTP (which set out to solve more than just Joe's immediate problem). Similarly, I often transfer files by piping them to netcat. EDIT: the point about tools still stands. For example: host1$ nc -l 1234 > my.file host2$ cat my.file | nc host1 1234 This is very easy to do given that unix is my toolbox. It'd be much more involved to write from scratch in (say) C. On the other hand, Joe's tool is much more powerful; it doesn't require him to manually interact with the shell on two different hosts, and his program can list files on the remote host and automatically download them under the correct name whereas I'm stuck manually redirecting nc's output to the right file (and cursing myself when I accidentally forget to change the name and overwrite a file I wasn't supposed to fetch). Those features were very easy to add to his program because Erlang is a powerful tool. On unix shell, it's much harder.
- gmfawcett 7y ago
  Consider adding 'tar' on each side to avoid naming errors. If you squint just right, 'tar' is "the pipe fitting that remembers what things used to be called." :)
hinkley 7y ago
The good people formulate their handwritten solution in a way that invites other people to replace it with a library. This is the best of both worlds. The bad ones get us stuck with that solution for a very long time. These are the experiences that prompt people to post to threads like this.