From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3795 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: embedded newbies site. Date: Thu, 01 Aug 2013 01:20:57 -0500 Message-ID: <1375338057.4211.7@driftwood> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1375338069 13304 80.91.229.3 (1 Aug 2013 06:21:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 1 Aug 2013 06:21:09 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3799-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 01 08:21:12 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V4mG7-0001fy-5q for gllmg-musl@plane.gmane.org; Thu, 01 Aug 2013 08:21:11 +0200 Original-Received: (qmail 13612 invoked by uid 550); 1 Aug 2013 06:21:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 13598 invoked from network); 1 Aug 2013 06:21:10 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=el8SySXZ0R94WaHEBmKJLRrBigYyTiDw+PmlolWBePE=; b=SpQ5gQ666z6E71Oc1mcN+aoF73RGiaSdOdKVRwBvJ7b/DKLxprAutKjqsTQ08c9lVk hv6bxYjaierpGklHf1sYybWGKphp4CUxS0aEKNJIDfpbHuyvqXpzHaoLNvza0JhPtqKh sTH/9PmxQIAc7Sa0GG5oR39vha6AvmHJYBcFldoFvBwEkuoL+jlpihDY6bt3mmK8bDS2 XRyR/qPEjYJ74b9tYFRyFH+xeqK/YfwROGDpKOIU+Q7tPdQdRZLX1KiNHmI3eTm2liSx A84svb4i/CKyLQEryvm1j/ct7Y6fZ3fNtJ1Ni7lP5RJ32vZ7e6bWmMelq/jTUQR+B9r2 IqdA== X-Received: by 10.236.17.105 with SMTP id i69mr34375502yhi.157.1375338058301; Wed, 31 Jul 2013 23:20:58 -0700 (PDT) In-Reply-To: (from strake888@gmail.com on Mon Jul 29 20:35:26 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQnyqZLp4jdWl26rbw7KgBZS8ifbrova7RUAmlCgHRSA56TmRDz9aQx1jvAKSl4jVb+UxQZx Xref: news.gmane.org gmane.linux.lib.musl.general:3795 Archived-At: On 07/29/2013 08:35:26 PM, Strake wrote: > On 29/07/2013, Rob Landley wrote: > >> Polymorphism: not need to rewrite essentially the same code for =20 > 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, =20 > instead > > they generate code for each type bloating the executable =20 > 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 =20 > in > > their type system and the result is your tools generate buckets of > > template code so one year old java projects with three developers =20 > 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 >=20 > 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 =20 > things, > >> or better yet, not do them at all. For example: "Damn, I wish I =20 > could > >> define my own comparator/reader/whatever function here!" >=20 > > C has had this from day 1 (it's why it has function pointers). >=20 > 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 =20 static structures, arrays, and pointers as its main data composition =20 mechanisms. Scripting languages like python/ruby/lua use dynamic typing and dynamic =20 memory managment, which means they can include resizeable containers as =20 first class types. So instead of using structs, they use dictionaries =20 to associate names with values, and abstract away the underlying =20 implementation mechanism. (Is it a hash table or a tree? Who cares, it =20 just works.) In between "entirely manual" and "fully automated" is the demilitarized =20 zone C++ inhabits where it's got automation that sort of works, but =20 only if you understand how it's implemented. To leverage the installed =20 base of C, they tried to build additional automation on top of =20 _pointers_ (not references), and it didn't work. Anywhere its =20 abstractions actually hide implementation details, you wind up with =20 elaborate magic rules that must be followed or things inexplicably =20 break and it's your fault. So talking about kludging over C's lack of some feature is like saying =20 you're kludging over assembly language's lack of a feature. Intel did a =20 chip that implemented object support inthe hardware, it was called the =20 Intel 432 it turned out to be unusably slow. Using the tool that's fast =20 while complaining about what makes it fast is silly. If you don't want to do everything manually, there are plenty of =20 languages that allow you not to. They run at about 1/5 the speed of C, =20 and yes that includes the optimized subsets of javascript once you =20 strip out the hype and carefully crafted benchmarks. (The fact that 1/5 =20 the speed of a gigahertz machine is 200 mhz and Quake ran fine on those =20 at low resolution can take people a while to notice; until their =20 battery dies.) > > Nobody ever needed a buzzword for it, because it's not special. >=20 > 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 =20 buzzwords" means "you don't need object oriented buzzwords to teach C". =20 I have the disadvantage of being old here. That said, teaching C++ and thinking that means you've taught C was a =20 massive disservice to a generation of programmers. A mud pie is not a =20 beverage, even if you make it with bottled water. You can _add_ fail to =20 something. > > unix has this at the command line level. >=20 > 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: >=20 > $ sort comparator argu ... >=20 > 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? >=20 > Yep, modern English has Latin in it. Ah, the bellum donum of the puella agricola. (My wife's had 4 years of =20 latin recently, and half of fadeaccompli.dreamwidth.org is translating =20 Catallus these days. Me, I just had the one in high school.) English also had greek, celtic, gaelic, various scottish dialects, the =20 angles and the jutes (multiple times including the norsemen bouncing =20 off northern france), some deeply misguided germans, and that's before =20 the empire where the malaria drugs became a happy tradition of "gin and =20 tonic" bringing phrases and diseases from around the globe. (It's been =20 years since my english minor and the history of english class is a bit =20 fuzzy, I remember how to pronounce "gedaewhamlichan", which more or =20 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 =20 > they > > refuse to abandon all that work they've done on the properties of > > caloric fluid migrating through the ether. >=20 > And sometimes the engineers ignore the tools... It's been a while since they improved on the hammer. Rob=