4 ms·

I challenge his assertion around 32:50 that something is lost. I've done assembly programming. C programming. I might venture to say I'm pretty good at it.

I challenge his assertion around 32:50 that something is lost. I've done assembly programming. C programming. I might venture to say I'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're allowed to access; how much of it and where it is, there is literally no good, or standard way to do that. "Well," you (or jon blow) might say, "just use grub (or another multiboot bootloader), it'll give you the memory map." But wait, wasn't that what we were trying to avoid? If you do this, you'll say "I'm smart, I'm sparing myself the effort," but really there is a loss of capability, you don't really know where these BIOS calls are going, what the inner workings of this bootloader are, and something is lost there. 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/productivity, not talking about performance yet). Low-level programming languages aren't more productive than high-level programming languages. Low-level programmers 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? As I'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 nothing is lost. Nothing is lost, and quite a lot is gained. There are things I can do with perl6 that I cannot do with c—but, of course, the reverse is also true. And I think that jon blow'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'm sure, negative interactions with proponents of dynamic languages, because he sees their arguments as (maybe that's what their arguments are, I don't know) "c is useless, javascript is good enough for everything." 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. 1: https://wiki.osdev.org/Detecting_Memory_(x86) https://wiki.osdev.org/Detecting_Memory_(x86) 2: http://www.catb.org/~esr/jargon/html/story-of-mel.html http://www.catb.org/~esr/jargon/html/story-of-mel.html

NeveHanter 7y ago
About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout. About the second one, performance should be crucial everywhere, if some application eats all the resources then I can't have other applications working in the background doing their stuff. That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc. Going back some years ago, I was able to run Skype, AQQ, IDE, Chrome browser and Winamp at the same time on archaic (in today's standards) i3-350M and 4 GiB of RAM.
- earenndil 7y ago
  > That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc. Again, this is a problem with programming design, not programming language. It is very possible to make good, performant programs in fancy dynamic languages, and awful, leaky, slow ones in 'high-performance' compiled languages. The impact of the language itself is really not as high as it's made out to be. Yes, python is 100x slower than c at multiplying numbers, but so what? Your program doesn't spend most of its time multiplying numbers. If you design a python program in a non-stupid way, for an application like a chat app, the performance hit compared to c is negligible.
- Ace17 7y ago
  > About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout. It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module). The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware. This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.

NeveHanter 7y ago

About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout. About the second one, performance should be crucial everywhere, if some application eats all the resources then I can't have other applications working in the background doing their stuff. That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc. Going back some years ago, I was able to run Skype, AQQ, IDE, Chrome browser and Winamp at the same time on archaic (in today's standards) i3-350M and 4 GiB of RAM.

earenndil 7y ago
> That's the problem with i.e. "modern" communication apps (I'm talking about you, slack) where my four core CPU is on it's knees when doing simple things like switching the team or even channel, not mentioning starting the app itself. Another one is when I'm on the Google Meet chat, my browser eats 80% of CPU, I can't do anything reliably in that time, running anything makes chat to loose audio, lag a much, etc. Again, this is a problem with programming design, not programming language. It is very possible to make good, performant programs in fancy dynamic languages, and awful, leaky, slow ones in 'high-performance' compiled languages. The impact of the language itself is really not as high as it's made out to be. Yes, python is 100x slower than c at multiplying numbers, but so what? Your program doesn't spend most of its time multiplying numbers. If you design a python program in a non-stupid way, for an application like a chat app, the performance hit compared to c is negligible.
Ace17 7y ago
> About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout. It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module). The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware. This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.