Re: embedded newbies site.

[Rob Landley <rob@landley.net>]

On 07/29/2013 08:35:26 PM, Strake wrote:
> On 29/07/2013, Rob Landley <rob@landley.net> wrote:
> >> 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
> 
> I doubt it not, but I said nil of C++ and Java in that segment.

You were using their buzzwords.

> >> 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!"
> 
> > C has had this from day 1 (it's why it has function pointers).
> 
> Oh, it's surely possible, but at times forgotten.
> Too, (passing pointers, clearing errno, ...) to kludge over C's lack
> of (tuples|multiple return values) can break this.

C is based on static typing and static memory management, with the  
static structures, arrays, and pointers as its main data composition  
mechanisms.

Scripting languages like python/ruby/lua use dynamic typing and dynamic  
memory managment, which means they can include resizeable containers as  
first class types. So instead of using structs, they use dictionaries  
to associate names with values, and abstract away the underlying  
implementation mechanism. (Is it a hash table or a tree? Who cares, it  
just works.)

In between "entirely manual" and "fully automated" is the demilitarized  
zone C++ inhabits where it's got automation that sort of works, but  
only if you understand how it's implemented. To leverage the installed  
base of C, they tried to build additional automation on top of  
_pointers_ (not references), and it didn't work. Anywhere its  
abstractions actually hide implementation details, you wind up with  
elaborate magic rules that must be followed or things inexplicably  
break and it's your fault.

So talking about kludging over C's lack of some feature is like saying  
you're kludging over assembly language's lack of a feature. Intel did a  
chip that implemented object support inthe hardware, it was called the  
Intel 432 it turned out to be unusably slow. Using the tool that's fast  
while complaining about what makes it fast is silly.

If you don't want to do everything manually, there are plenty of  
languages that allow you not to. They run at about 1/5 the speed of C,  
and yes that includes the optimized subsets of javascript once you  
strip out the hype and carefully crafted benchmarks. (The fact that 1/5  
the speed of a gigahertz machine is 200 mhz and Quake ran fine on those  
at low resolution can take people a while to notice; until their  
battery dies.)

> > Nobody ever needed a buzzword for it, because it's not special.
> 
> It's not special, but it may be noteworthy, particularly when teaching
> or at least telling good practice, as we aim to here.

I'm trying to figure out if "I didn't learn C using object oriented  
buzzwords" means "you don't need object oriented buzzwords to teach C".  
I have the disadvantage of being old here.

That said, teaching C++ and thinking that means you've taught C was a  
massive disservice to a generation of programmers. A mud pie is not a  
beverage, even if you make it with bottled water. You can _add_ fail to  
something.

> > unix has this at the command line level.
> 
> Yes, but some utilities fail at it. Sort, for example, has insanely
> many flags, and nevertheless fails to cover common usage cases. If
> rather sort worked thus:
> 
> $ sort comparator argu ...
> 
> where comparator is some program, and argu ... its arguments, it would
> not need those flags.

sort <(ls -f)

> >> Yes, so that particular library loses, but factorization wins.
> >
> > "factorization" is a word now?
> 
> Yep, modern English has Latin in it.

Ah, the bellum donum of the puella agricola. (My wife's had 4 years of  
latin recently, and half of fadeaccompli.dreamwidth.org is translating  
Catallus these days. Me, I just had the one in high school.)

English also had greek, celtic, gaelic, various scottish dialects, the  
angles and the jutes (multiple times including the norsemen bouncing  
off northern france), some deeply misguided germans, and that's before  
the empire where the malaria drugs became a happy tradition of "gin and  
tonic" bringing phrases and diseases from around the globe. (It's been  
years since my english minor and the history of english class is a bit  
fuzzy, I remember how to pronounce "gedaewhamlichan", which more or  
less meant "daily" in old english, but not the correct way to spell it.)

That said, factorization is still pure buzzword in this context.

> >> 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.
> 
> And sometimes the engineers ignore the tools...

It's been a while since they improved on the hammer.

Rob