Date: Fri, 26 Jul 2013 19:58:28 -0500 From: Rob Landley <rob@...dley.net> To: musl@...ts.openwall.com Cc: musl@...ts.openwall.com Subject: Re: embedded newbies site. On 07/22/2013 07:12:39 PM, Strake wrote: > On 21/07/2013, Rob Landley <rob@...dley.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.