Re: embedded newbies site.

[Strake <strake888@gmail.com>]

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.

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!"

> 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.

> 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!

> 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" (^_^)

Cheers,
Strake