mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: musl@lists.openwall.com
Subject: Re: embedded newbies site.
Date: Fri, 26 Jul 2013 19:58:28 -0500	[thread overview]
Message-ID: <1374886708.3031.23@driftwood> (raw)
In-Reply-To: <CAL3m8eCfyDWjqwbciyXaBN1s2-N1pmwDojhVW1XMAmxizgZ64A@mail.gmail.com> (from strake888@gmail.com on Mon Jul 22 19:12:39 2013)

On 07/22/2013 07:12:39 PM, Strake wrote:
> On 21/07/2013, Rob Landley <rob@landley.net> wrote:
> > What did you have in mind?
> 
> >> > - efficient (elegant) programming
> >> >    - Why C and scritpting languages, why NOT C++ and autoconf
> 
> This. Too, why not glib, and other such garbage.

Never having used glib, I'm not qualified to warn people away from it.
I _have_ used C++ fairly extensively and already wrote up a banishment  
ritual.

> >> >    - tradeoffs
> >> >      - code reuse
> 
> including, particularly, polymorphism and composability.

I don't know what you mean by this. (I remember the buzzwords, but...)

By "code reuse" I meant it's very easy to suck in a lot of code you  
never have a first user for by grabbing a library that does 1000 things  
of which you need 3. Environmental dependencies are a form of code  
complexity, but it's invisible because you seem virtuous by requiring  
the whole gnome library suite for what turns out to be a network daemon.

Alternately, "infrastructure in search of a user" is as bad as  
premature optimization: hold off writing code until you actually need  
it.

Otherwise the unused code will sit there and bit-rot, never tested or  
regression tested by anything, making it harder to change your design  
in response to real world needs both by bulking out the code you need  
to rewrite to accomodate design changes, and by chaffing the system  
about what your real world needs actually _are_ since half the code is  
serving imaginary needs. Plus you have code you're afraid to touch  
because you can't test whether or not your changes break users you  
can't find; showing nothing _does_ use it after the fact is proving a  
negative, notoriously difficult.

> >> >      - transaction granularity
> >> >      - taking advantage of SMP without going crazy
> 
> I leave these to someone less ignorant on the matter.
> 
> I would note too that computers are meant to save our time, including,
> perhaps above all, the hackers who write code for them. This often
> seems ignored or forgotten.

My aboriginal linux 260 slide presentation described why native  
compiling under emulation is better than cross compiling. One reason  
was throwing processor time at the problem instead of throwing  
engineering time at the problem. Moore's Law helps with one of these.

Rob

  reply	other threads:[~2013-07-27  0:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16  2:03 Rob Landley
2013-07-16  3:18 ` Strake
2013-07-17 12:07   ` LM
2013-07-17 13:58     ` Rich Felker
2013-07-20 15:17   ` James B
2013-07-22 12:27     ` Andrew Bradford
2013-07-22  4:40   ` Rob Landley
2013-07-23  0:12     ` Strake
2013-07-27  0:58       ` Rob Landley [this message]
2013-07-27  2:01         ` Strake
2013-07-27  2:50           ` Rich Felker
2013-07-29 20:01             ` Rob Landley
2013-07-29 19:54           ` Rob Landley
2013-07-30  1:35             ` Strake
2013-08-01  6:20               ` Rob Landley
2013-08-03 16:52                 ` Strake
2013-07-16 11:50 ` LM
2013-07-16 13:56   ` Szabolcs Nagy
2013-07-16 14:00   ` Rich Felker
2013-07-16 17:49   ` Strake
2013-07-22  6:00   ` Rob Landley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1374886708.3031.23@driftwood \
    --to=rob@landley.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).