Preventing the Collapse of Civilization [video]
I challenge his assertion around 32:50 that something is lost.  I&#x27;ve done assembly programming.  C programming.  I might venture to say I&#x27;m pretty good at it.  I even dabbled a bit in baremetal programming, was going to make my own OS, but lost interest.  Wanna know why?  Take a look at this[1] article.  Yep.  If, on x86, you want to know what memory you&#x27;re allowed to access; how much of it and where it is, there is literally no good, or standard way to do that.  &quot;Well,&quot; you (or jon blow) might say, &quot;just use grub (or another multiboot bootloader), it&#x27;ll give you the memory map.&quot;  But wait, wasn&#x27;t that what we were trying to avoid?  If you do this, you&#x27;ll say &quot;I&#x27;m smart, I&#x27;m sparing myself the effort,&quot; but really there is a loss of capability, you don&#x27;t really know where these BIOS calls are going, what the inner workings of this bootloader are, and something is lost there.<p>This is a bit of a contrived and exaggerated example, but it serves to prove my point which is that these things really do scale linearly: you give up the same amount you get back by going up a layer of abstraction (in understanding&#x2F;productivity, not talking about performance yet).  Low-level programming languages aren&#x27;t more productive than high-level programming languages.  Low-level <i>programmers</i> are more productive than high-level ones because it takes more discipline to get good at low-level programming so the ones that make it in low-level programming are likely to be more skilled or, at least, to have acquired more skill.  Think about the story of mel[2].  Does anyone honestly think, with any kind of conviction, that mel would have been less productive had he programmed in python and not thought about how machine instruction would be loaded?<p>As I&#x27;ve mentioned, I have done, and gotten reasonably good at, low-level programming, and yet my current favourite language is perl6.  A language that is about as far from the cpu as it gets, on a par with javascript or haskell.  Why?  Because <i>nothing is lost</i>.  Nothing is lost, and quite a lot is gained.  There are things I can do with perl6 that I <i>cannot do</i> with c—but, of course, the reverse is also true.  And I think that jon blow&#x27;s perspective is rather coloured by his profession—game development—where performance is important and it really does pay, sometimes, to think about how your variables are going in memory.  He has had, I&#x27;m sure, negative interactions with proponents of dynamic languages, because he sees their arguments as (maybe that&#x27;s what their arguments are, I don&#x27;t know) &quot;c is useless, javascript is good enough for everything.&quot;  Maybe the people who truly think that have lost something, but I do not think that mel, or jon blow, or I, would lose much by using perl6 instead of c where perl6 is sufficient.<p>1: <a href="https:&#x2F;&#x2F;wiki.osdev.org&#x2F;Detecting_Memory_(x86)" rel="nofollow">https:&#x2F;&#x2F;wiki.osdev.org&#x2F;Detecting_Memory_(x86)</a><p>2: <a href="http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;jargon&#x2F;html&#x2F;story-of-mel.html" rel="nofollow">http:&#x2F;&#x2F;www.catb.org&#x2F;~esr&#x2F;jargon&#x2F;html&#x2F;story-of-mel.html</a>