akdas

This works if performing at the top of your current level equates to performing at the bottom of the next level. That said, there's a problem where sometimes a "promotion" is really a new role, meaning to perform at the next level, you have to kind of not perform well at the current level.

* https://avikdas.com/2020/07/08/barebones-webgl-in-75-lines-o...

* https://avikdas.com/2020/07/21/barebones-3d-rendering-with-w...

I still go back to them myself to refresh my memory. It's funny that I called this a lot of boilerplate, but Vulkan is known to have even more.

This won't answer all your questions, but maybe it'll answer some of them.

The confusion is probably because "empty" can mean two things:

- What's inside the returned value. That may be why the parent suggested empty for the unit type. But that's now what "unit" means in the common parlance.

- How many possible values can be returned. Never returning means the function has zero possible return values.

I wrote this page for my own compiler that I'm working on, but I think it would be a good complement to this article. Note that the page is not that great on mobile, the extra real estate on desktop really helps.

https://cstheory.avikdas.com/

https://nesdev.avikdas.com/

If you're interested in collaborating for your classes, reach out to avik at avikdas dot com

For the bug, feel free to email me at avik at avikdas dot com if you'd like. The behavior I verified just now (for me) is that if you click one byte to highlight it, then clicking any other byte in the same group will remove the highlighting.

Lately, I've been using Svelte for interactive visualizations (see my post on using a tool called Astro with Svelte: https://avikdas.com/2023/12/30/interactive-demos-using-astro... ). But this one is all hand-written JS!

To explain the format to myself and others, I also created an interactive visualization for the bytes in the file. It helps me to click on a byte, see an explanation for it and see related bytes elsewhere in the file highlighted. https://scratchpad.avikdas.com/elf-explanation/elf-explanati...

It's the Gameboy and the NES, running a Z80-style and a 6502-style processor respectively, that typically need more hand-holding from manually written assembly code. It's not just the processor but the lack of hardware features (such as lacking multiple background layers, the relatively low number of sprites that can be on screen at a time, etc.) that result in squeezing out extra performance to overcome these limitations in creative ways. Compare that to the minesweeper game just rendering all the board cells as sprites!

The first time around, I struggled a lot with decoding errors. Many years later, after being a more experienced developer, I wrote the LZW decompression with unit tests. Doing so forced me to think about each edge case, and fix issues without breaking existing functionality. Very quickly, I was able to open pretty much any GIF file I threw at it!

A few of my posts on dynamic programming got a fair bit of traction here on HN.

I haven't posted in a while, but after a busy few years, I have some posts lined up. I want to reflect on some teaching I did (one big reason I didn't have time to blog), as well as document me getting a new home server set up (this time with containers, finally).

- I got to the front page of HN a few times. Definitely a vanity thing, but it was fun!

- My posts on dynamic programming, which got a lot of traction, resulted in someone I knew reaching out to ask me to speak at a conference they organize. The conference didn't result in much professionally, but I love public speaking. It was just a great experience.

- I mentioned off-hand that I got to talk about DP, and that got me connected with someone who was able to create a video course on the topic. I learned a ton thanks to their guidance on things like how to organize smaller chunks of information that build up to a bigger course.

- Another post about mental health got me a chance to be interviewed on a podcast. I'm a huge podcast listener, so I was ecstatic about actually being on one!

With the confidence from the 12-month experiment, I then decided to write weekly about hiring in the tech industry, a topic I'm passionate about. I kept that up every week for over a year! What came out of that is I had a bunch of thoughts floating around in my head, and now I have them documented. Now if I want to bring up something about hiring, I probably already have an article I can just link instead of explaining it from scratch. The same actually applies to some topics on my personal blog.

EDITED: Regarding that last point, I've been setting up a Raspberry Pi after a few years. Having some notes documented has been invaluable for myself.

Implementing the halting problem using addition does not assume the existence of halt. It assumes the existence of addition, and you use that to show that halt must also exist. And that's not possible to do.

To implement halts using addition, you need to:

- Take the input to halts, namely the source code to a program.

- Convert that into an input to addition, namely two numbers.

- Call into addition, which adds the numbers.

- Use the result of that addition to infer whether the original program halts or not.

One advantage of this is being able to look back on previous projects in the future, as a form of documentation. That helps me pick up on a project I haven't worked on in a bit. True, you don't need to publish the documentation publicly, but since I wrote it, putting it up publicly is almost no effort now that I have a blog.

That said, given that candidates are generally nervous to some extent anyway, and semi-colons shouldn't matter in a whiteboard interview, that joke seemed like in poor taste to me. That underscores why we need better training and mentorship for interviewers.

- Giving trick questions that have an "insight" moment, instead of one that has multiple answers, even partial answers to build off of.

- Not letting the candidate pick the language they're comfortable with. The candidate may even know the language they're asked to code in, but if they haven't been working with it recently, an interview is not the right time to pick it up again.

- Making the candidate nervous, both by not being helpful and by watching over them with unnecessary scrutiny.

- Looking for flaws instead of strengths.

People, myself included, are always talking about these problems, but companies have so much inertia, they are not evolving fast enough to solve these problems. No wonder tech companies are filled with people who, while capable, often fit a particular mold, and why we end up in situations where products don't reflect the needs of the market (because the people working on those products aren't representative of the market).

[0] https://hiringfor.tech/archive.html

> feminism as a movement isn't really for equality, they say they are but they aren't really or else those wouldn't get accepted in the movement

You keep bringing this up, but you haven't provided proof. Whereas people blaming women (instead of cultural sexism as a whole that's practiced by both men and women, and therefore the target of feminism) for their problems has plenty of proof in the comments here.

To be fair, there are people who call themselves feminists while being toxic, such as Trans-Exclusionary Radical Feminists. Mainstream feminism decries these groups, as evidenced by the backlash against J.K. Rowling. This kind of exclusionary behavior is _not_ acceptable.

And finally, if you believe in equality, then let's champion it. Even if you believe that women are making it hard for you, positively commend those who are behaving in an equitable way, and the same for men who are behavior in an equitable way. _We_ get to decide how the world should be. Let's make it happen!

> If they really wanted men to cry more then they should encourage women to handle that burden rather than totally drop the ball and shame men who dare to cry.

There's some truth to this, but it's also omitting something that's extremely important (and therefore changes the entire tone of this argument): we should also encourage men to handle that burden rather than totally drop the ball and shame men who dare to cry. It's not men vs. women. It's men and women together. That's what feminism is.

Other than that one, I don't know of other such positive men's spaces.