[ale] Ruby vs C, a non-technical chat

[Michael B. Trausch]

On Thu, 2015-08-06 at 09:19 -0400, leam hall wrote:
> The main issue I'm trying to overcome with coding is getting work
> done at work. I've done stuff with a few languages but keep getting
> pulled back to shell or manual because that's what work supports.
> With Ruby, I can say "It's on the machines, so I can use it". Go
> would be a harder sell unless I can find a job at a Docker shop or
> some place that is producing system tools. Given my current coding
> skills, I see that as unlikely in the short term. 
> 
> Some of the skills I'm learning now should translate; writing tests,
> making the code handle errors and exceptions. Some are only useful to
> OO languages. 
> 
> Still, having fun rates high. 
The great thing about native-code compilers is that they do not have to
be installed on the target system.  Only the shared libraries,
executable binaries, and runtime data is required.
That's the great thing about C.  I can ship a statically-linked ELF to
a remote server to rescue it, even if it only has a read-only FS, so
long as SSH lets me in.  I've done this before to create a tiny ELF
program that calls the reboot() system call when the /sbin and /usr
directories was unavailable.  Solution?  Compile statically linked ELF
file (against MUSL, yields a < 30KB binary; without a C library and
calling the system call directly gives a binary < 15KB), sftp it to
/run, /tmp, or /dev (the first available one that is read-write to UID
0), and run it.
It could just be that I've used the language for so long that I'm
comfortable rapidly writing code in it, but my productivity in C and
C++ is quite acceptable to me. It is possible to easily do just about
anything with it. C and C++ code modules are freely available to handle
ASN.1, BSON, JSON, XML, Thrift, and other data interchange
formats/systems, and the code (if well-written) is fast *and* portable.
 I prefer to use formats that I don't have to pull in huge libraries
for, so I avoid XML and Thrift when at all possible.  Binary formats,
IMHO, are better, but there are lightweight JSON libraries in C.
Another thing that helped me out:  I used to think of C and C++ as two
separate things, but really they go together quite well.  A C++ module
can expose a C API/ABI and you can use the best tool for the job. (C++
as of C++11 is no longer a strict superset of C, meaning that there are
times when it is better to use one over the other.)  Plus you can
interop with Cocoa, NEXTstep and GNUstep simply by writing glue between
C/C++ and the framework, which expects to use ObjC/ObjC++.
Lastly, modern C++ gives you nearly all the power of dynamic runtime
languages like Python, but with predictable on-disk and in-memory
footprints and no runtime interpretation or JIT.  Fewer moving
components and all that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150806/2aaf1525/attachment.html>