The Old New Thing

There's actually a very good reason to implement a delay in switching submenus.

Recent versions of Apple's human interface guidelines don't make any mention of it, because those decisions are baked into the toolkit and not under control of application designers, but the earlier editions of Apple's guidelines went into some detail about why and how pop-up submenus were delayed.

1995 edition of Macintosh Human Interface Guidelines:

http://interface.free.fr/Archives/Apple_HIGuidelines.pdf

>pp. 79: Hierarchical menus are menus that include a menu item from which a
submenu descends. You can offer additional menu item choices without
taking up more space in the menu bar by including a submenu in a main
menu. When the user drags the pointer through a menu and rests it on a
hierarchical menu item, a submenu appears after a brief delay. To indicate
that a submenu exists, use a triangle facing right, as shown in Figure 4-36.

The original 1987 version of the Apple Human Interface Guidelines can be checked out from the Internet Archive, and should be required reading for serious user interface designers, the same way that serious art students should contemplate the Mona Lisa, and serious music students should listen to Mozart. Even though it's quite dated, it's a piece of classic historic literature that explicitly explains the important details of the design and the rationale behind the it, in a way that modern UI guidelines just gloss over because so much is taken for granted and…

I agree with you, but it's important to acknowledge the strength of the argument against exceptions. I think Raymond Chen put forth some of the best arguments, claiming they were human error prone:

https://blogs.msdn.microsoft.com/oldnewthing/20050114-00/?p=36693

https://blogs.msdn.microsoft.com/oldnewthing/20040422-00/?p=39683/

While forceful, I don't accept the conclusion of Raymond's argument. I feel it may be true for programmers primarily trained and experienced in C, but is not true in general. As such, the argument reduces to "programmers who are not familiar with exceptions sometimes make mistakes when using them." One could say the same thing about pointers, dynamic typing, lambdas, macros, comprehensions, pass-by-reference, etc. Today, most programmers are familiar and comfortable with exceptions, having almost certainly been taught to use them in college and almost certainly using them on a daily basis for their entire professional career. They'll also have been taught to use a language-specific toolbox such as RAII or try/catch/finally to deal with any potential problems.

Once you get in the habit, it's not hard to scan through a program line-by-line asking yourself "what would happen if an exception were thrown at this point?" and to take appropriate precautions. In fact, I'd wager that for anyone who's spent years working in any language with exceptions this quickly becomes second nature. It's also an easy way to add value during peer code review. In my…

I try to live by a few simple rules regarding code vs comments. Here are ten of them. Some of these are already in other comments, in a different form.

1. Code should show not tell. That means the comments I write are typically at the beginning of a class or function rather than scattered throughout on separate lines.

2. Code shows how, comments instruct why. A good comment includes the reasoning behind the algorithms and tradeoff choices chosen by the coder.

3. Good comments include an example of usage

4. Good comments are compatible with an automated documentation framework, such as Javadoc, Doxygen, Rustdoc, and Pydoc

5. Good comments do not include a modification history. Version control and changelogs can handle that.

6. Kill your darlings - Good code follows the KISS principle, and is easily understood, as well as easily maintained

7. Good code is SOLID - This is part of Kill Your Darlings, in a way. To be easily maintained, in many cases, you need to follow SOLID. Here's a good article on SOLID: https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

8. Good code is short - I don't have a firm line count, because it's different based on domain, language, etc. I do try to keep each method/function to no more than a quarter of a screen of code at a reasonable resolution, so that's maybe around 15 lines. With modern optimizing compilers and VMs this will not be a large performance hit, if it's a hit at all, assuming you are…

why would a compiler do that?

The theory is that constraint propagation enables optimizations that aren't possible otherwise. In particular, it lets the compiler avoid emitting code for conditions it judges are impossible to occur. This usually doesn't help much with C, but can be useful with C++, and many of the optimization decisions are driven by C++ performance.

To satisfy the Rust community's desire to spread FUD throughout the C community?

I'm a big fan of C, and consider it my primary language. I have barely used Rust and am not part of the Rust community.

A more logical thought process here is that signed operations aren't uniform across architectures and are sometimes emulated, leading to UB for certain edge cases, like overflow.

Personally, I would love if this was the vision for C that compiler writers held. But it is not, and has not been for at least a decade.

Its more practical to believe that a future C standard will fix this loophole rather than think compilers will exploit this and punish their own community.

Unfortunately there is no chance that this will happen. That ship has sailed. Compilers are taking ever greater advantage of undefined behavior for purposes of optimization. Overflowing a signed integer is undefined behavior, therefor real-world compilers can and do strip out checks that they determine would require undefined behavior to be occur.

I realize this is hard to believe, but try this article as an intro:…

I enjoy Yossi Kreinin's blog [1] and The Old New Thing [2].
I don't read programming language books, which I usually find to have little good industry knowledge and to be too detail oriented and easily out of date. Although K&R (the one about C) is a great book that's exactly the right size and the examples from the Gang of Four book are actually very on point.

Most often I learn code by reading code. OpenSceneGraph is an example of an open source project that has modern ish C++ but no deliberately abstract misdirection. Open source usually does not have super clean code but it's a good way to sample the variety of structures you can find in a project. Of course the classics (sqlite and the Linux kernel) are much too C-like for where I'm getting at but they are still full of lessons for how to organize modules and APIs, how many arguments to pass and where, where to park I/O code, that sort of thing.

I posted it here for the benefit of HN readers who may have the same question but I'll write you an email too so you can share what you want to improve and such. There aren't many C++ programmers left in the HN-reading, not just punching a clock demographic, and I kind of miss talking to people who get that. Like the prototypical game dev in the article I go to one conference a year, and it's not about C++.

[1]: https://yosefk.com/blog/
[2]: https://blogs.msdn.microsoft.com/oldnewthing/

Great insights!

Your comment also made me wonder what actually happened to ELKS. Last I checked (many years ago, apparently), it seemed abandoned. But development has started again in 2014, and still seems ongoing: https://github.com/jbruchon/elks

Should play with it some time, maybe in an 8086 emulator.

EDIT: By the way:

I forgot to mention this in my other comment:

> The core of it is a smart linker/loader which allows code and data segments to be loaded, patched together on the fly, and dropped on demand. All data is relocatable, allowing it to be rearranged or swapped out.

Early Windows on early XTs did that, too! With all sorts of crazy hacks to make it happen [1]. I don't know how it compared to what GEOS did, though.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203 and many other articles on that site can send you down a deep rabbit hole.