From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: musl@lists.openwall.com
Subject: Re: embedded newbies site.
Date: Mon, 29 Jul 2013 14:54:51 -0500 [thread overview]
Message-ID: <1375127691.3031.39@driftwood> (raw)
In-Reply-To: <CAL3m8eA9Za658ziJBZd3zfuSVPXbPnj0ORAy_Cz87PBjsyQgDg@mail.gmail.com> (from strake888@gmail.com on Fri Jul 26 21:01:48 2013)
On 07/26/2013 09:01:48 PM, Strake wrote:
> On 26/07/2013, Rob Landley <rob@landley.net> wrote:
> > 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 used it little, just to hack surf and jumanji, but I found
> insanely_long_function_names, poor docs of what allocates or frees
> what, wanton type synonyms, and generally a tangled mess.
>
> I gave up.
>
> This may not be glib alone, but glib surely seems guilty too.
>
> > I _have_ used C++ fairly extensively
>
> this -> beSorry ();
>
> >> including, particularly, polymorphism and composability.
> >
> > I don't know what you mean by this. (I remember the buzzwords,
> but...)
>
> Polymorphism: not need to rewrite essentially the same code for each
> type.
> Haskell wins at this, but is not quite a systems language (^_~)
> C at least has void pointers, which work in some cases.
C++ templates don't make you write the same code for each type, instead
they generate code for each type bloating the executable tremendously
and making you reverse engineer their code generation when a bug
happens in the middle of it or you have to trace back through it to
understand what the code actually did.
Java has a similar failure where they use templates to punch holes in
their type system and the result is your tools generate buckets of
template code so one year old java projects with three developers with
more than a million lines of code are not actually that unusual.
The difinitive (long) Java takedown:
http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.html
> Composability: write functions to do one thing well, and have them
> call other functions, perhaps passed as arguments, to do other things,
> or better yet, not do them at all. For example: "Damn, I wish I could
> define my own comparator/reader/whatever function here!"
Um, unix has this at the command line level. C has had this from day 1
(it's why it has function pointers). Nobody ever needed a buzzword for
it, because it's not special.
> > 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.
>
> Yes, so that particular library loses, but factorization wins.
"factorization" is a word now?
> > Alternately, "infrastructure in search of a user" is as bad as
> > premature optimization: hold off writing code until you actually
> need
> > it.
>
> Worse: it may never save any time at all!
It generally costs time.
> > 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.
>
> Ah yes, "engineer competence doubles every 18 months" (^_^)
Sometimes the tools get better. But often they go down blind allies,
and then refuse to back out of their cul-de-sac because they made
_progress_ for a year or so before encountering the dead end, and they
refuse to abandon all that work they've done on the properties of
caloric fluid migrating through the ether.
Rob
next prev parent reply other threads:[~2013-07-29 19:54 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
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 [this message]
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=1375127691.3031.39@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).