This is wonderful! I'm definitely going to be sharing this with my students (college sophomores studying CS).
If I were to make some suggestions, based on how I know they would receive this:
- I would make explicit reference to heap and stack. Students who are learning this material are learning about the heap/stack dichotomy, and I think it would really improve the exposition to make clear that not all memory is allocated this way in a program.
- I would remove this line: "At the end of this post, you should know everything you need to know to write your own allocator." I can confidently say that my student will not be able to write an allocator after reading this. It's nothing to do with your piece, it's just the intersection of people who don't understand hex and who could build an allocator after a short blog post is very very small. Students who read this post and at the end still feel like they can't build an allocator will end up discouraged, with a feeling that maybe they are missing something.
- Consider rethinking how you handle hex numbers throughout. You introduce them and say they are distinguished by a preceding "0x", but then you immediately omit the 0x to save space in the figure. In my experience, students have a lot of trouble with understanding that hex and dec have the same underlying representation. They will not be able to distinguish between hex and dec bases implicitly, so from a pedagogical standpoint, it's better to be consistent throughout and include the prefix.
- Finally at the end I would make mention that there are other strategies for memory management to encourage further exploration. Other languages do it differently, and for students it's important to know which other avenues are out there. Otherwise they might think heap-based malloc/free are the only way to do things, the same way they often thing imperative programming is the only way to program.
Anyway, thank you for creating this, and I'm sure it will really help my students. In a just world, "seeing" the memory like this would ideally be first-class tooling for languages like C.
Nice, but I wouldn't confuse static images with the underlying semantic graph of live objects that's not visible in pictures.
DonHopkins on June 14, 2014
Precisely! When Lisp Machine programmer look at a screen dump, they see a lot more going on behind the scenes than meets the eye.
I'll attempt to explain the deep implications of what the article said about "Everything on the screen is an object, mouse-sensitive and reusable":
There's a legendary story about Gyro hacking away on a Lisp Machine, when he accidentally trashed the function cell of an important primitive like AREF (or something like that -- I can't remember the details -- do you, Scott? Or does Devon just make this stuff up? ;), and that totally crashed the operating system.
It dumped him into a "cold load stream" where he could poke around at the memory image, so he clamored around the display list, a graph of live objects (currently in suspended animation) behind the windows on the screen, and found an instance where the original value of the function pointer had been printed out in hex (which of course was a numeric object that let you click up a menu to change its presentation, etc).
He grabbed the value of the function pointer out of that numeric object, poked it back into the function cell where it belonged, pressed the "Please proceed, Governor" button, and was immediately back up and running where he left off before the crash, like nothing had ever happened!
Here's another example of someone pulling themselves back up by their bootstraps without actually cold rebooting, thanks to the real time help of the networked Lisp Machine user community:
The woman owned and founded startup I work for is completely unable to hire the diverse candidates we have interviewed because they are completely unaffordable at a startup.
Why is this?
Because executives at various massive tech companies are getting massive bonuses connected to how many diverse people they hire. They give lavish salaries and large chunks of equity to people who they otherwise would not. Somebody who is getting offers like this is naturally going to have all of their incentives misaligned for joining a startup.
My company's back end code is Java and Python and we interviewed an engineer who I was willing to teach both of these languages to. She happened to be a black woman and only new PHP using the laravel stack. Zero experience doing front end coding and not really a standout when it came to databases and barely new cloud.
She asked for a large equity stake, but also wanted a salary of $195,000. We are not at all in the Bay area and this salary is completely ridiculous for somebody who also wants a lot of equity and has very few skills that connect to our code base.
She was hired at Amazon for some rather boring role on an internal team that helps the data centers meet energy efficiency requirements by building applications that are essentially dashboards for internal decision makers.
We actually talk on regular basis now because I give her some advice for learning Python.
She was simply negotiating based on her market value and her own fiscal priorities and made a sound well-reasoned decision.
If my company hits it big one day which of course is typically not high probability, people like you will show up and say that we are systemically racist. Ironically the twisted incentives at these massive companies are creating this issue. As long as women are significantly less interested in jobs involving things just like men are significantly less interested in jobs involving people we're going to have to admit that trying to bring things to 50/50 proportions is going to create weird incentives that will further create side effects.
For twenty years I tried to build products and sell them to others, to no avail. "Marketing is the problem" - I always told myself about my failures.
I still have one product up from those days. FileSculptor is a file converter used by non developers to automate CSV to XLSX conversion. What was the last time I used it myself? Excluding testing before new releases or support issues, never.
I decided that my next product should be something I really care about. Something that scratches my on itch and that I would use on a daily basis. I should be the first one to find bugs on my product, not my users.
I always kept track of my expenses, but was less so with my budget. I used a spreadsheet and would update if once or twice a month. So I decided to create an app with the budget and expense tracking I wanted. I always had lots of ideas of how it should work, how it would forecast transactions automatically from a detailed budget and how it would deal with credit card purchases, hitting the budget on the month they'd appear of the credit card statement. It would support credit card purchases with installments, something always missing in the apps I tried.
I created Pleke to be the personal finance app I always wanted, and use it on a daily basis. For the last six months its been the only source of truth about my finances. At my day job I work on a product used by others. I'm grateful and want it to work well because it pays my bills. But with my app, its quite a different relationship. I'm always proud when I input data in it and it works as designed. When something breaks, I want to fix it ASAP. I have a text file with planned features for version 2, version 3, 4 and 5.
Pleke is the app I want to work on for the next ten years, even if others do not value it as much as I do. "Marketing is the problem" - I will tell myself, to their loss.
Be the first user of your product! A person who takes good care of their garden will work on it and admire it on a daily basis. So should we with our products.
The stack on this story so far (newest ones at the bottom—if I've missed any, can you let me know at hn@ycombinator.com? this is sort of an experiment and we may eventually write software to support building lists like this collaboratively):
in the link you provided is quite interesting. The concept of HV electrostatic blowing of polyethylene is new to me - I wondered how N95 masks were made. I note that in the cotton candy machine experiments they reduced the voltage to 50V, lol.
I'm going to reserve judgement on the physics behind making electrostatically charged fibers and the question of how long they retain the charge. That's an interesting area to investigate! For example:
Ethanol and isopropyl alcohol don't dissolve polypropylene, so the efficiency loss must be due to some other effect.
If the small fibers in the N95 mask have charge embedded in manufacturing, i.e. they are electrets, perhaps the removal of surface charge by alcohol (or screening by adsorbed alcohol?) is only temporary, and if the masks were tested a couple of days later, perhaps their efficiency might have recovered?
I would appreciate it if the Federal administration put some effort into upping production of N95 masks for everyone - I've used them for years as dust masks, and now they are not readily obtainable. I still have a small stash, which we reuse and spray down with Everclear 151 after use.
If I were to make some suggestions, based on how I know they would receive this:
- I would make explicit reference to heap and stack. Students who are learning this material are learning about the heap/stack dichotomy, and I think it would really improve the exposition to make clear that not all memory is allocated this way in a program.
- I would remove this line: "At the end of this post, you should know everything you need to know to write your own allocator." I can confidently say that my student will not be able to write an allocator after reading this. It's nothing to do with your piece, it's just the intersection of people who don't understand hex and who could build an allocator after a short blog post is very very small. Students who read this post and at the end still feel like they can't build an allocator will end up discouraged, with a feeling that maybe they are missing something.
- Consider rethinking how you handle hex numbers throughout. You introduce them and say they are distinguished by a preceding "0x", but then you immediately omit the 0x to save space in the figure. In my experience, students have a lot of trouble with understanding that hex and dec have the same underlying representation. They will not be able to distinguish between hex and dec bases implicitly, so from a pedagogical standpoint, it's better to be consistent throughout and include the prefix.
- Finally at the end I would make mention that there are other strategies for memory management to encourage further exploration. Other languages do it differently, and for students it's important to know which other avenues are out there. Otherwise they might think heap-based malloc/free are the only way to do things, the same way they often thing imperative programming is the only way to program.
Anyway, thank you for creating this, and I'm sure it will really help my students. In a just world, "seeing" the memory like this would ideally be first-class tooling for languages like C.