My own pet theory of the relevant personality disorders is this: Narcissism and Boderline are extremes on the same scale, namely, how you manage your identity.

BPDs are "extreme followers" which seek whole systems of validation, identity and meaning from their local social environment. NPDs are "extreme leaders" which cannot receive this validation socially, so push-out a delusional theory of their own identity (, role, value system, etc.). -- Which is why, so often, the structure of a cult is one NPD leader and a coterie of BPD followers.

If this scale exists, ie., from follower-to-leader... then many conditions can influence your position on it. A "healthy" person is presumably one who, I'd say, is mostly a mild follower but will adopt a mild leader position when required (eg., by role).

In ASD, my guess is that since some social mirror / double-empathy /etc. is different/impair, you get NPD-like problems because you're not getting that social validation feedback signal, so you're having to push out some validation/identity/etc. system of your own.

Likewise in ADHD, you tend to find a lot of social rejection due to impulsive behaviours that alienate people.. so you get a comorbid BPD-ish quality where you're aware of the social validation available, but are constantly fighting your own impulsive undermining of receiving it.

One diagnostic difference between the ASD-ADHD vs. NPD-BDP categorisation should be the possibility of self-awareness, where in the former you'd expect improving self-awareness to have some immediate benefits -- but in the later, often none. Since position on the leader-follower line in ASD/ADHD is effectively an "ecological concequence" of repeated accidental behaviours, whereas in NPD/BPD its something stranger and I think less well understood. One imagines, most probably, very early infant trauma that has severely impaired psycho-social development.

A long time ago I came up with an acronym that's served me well as a consultant who has to bounce from one customer to the next and run through interview gauntlets of all types: RACEMOORES:

R: Restate with sample inputs/outputs/diagrams

A: Assumptions ~ scale of inputs, uniqueness, range, variable parameters now and in the future

C: Complexity: runtime complexity, space complexity, etc

E: Edge cases

M: Maintainability

O: Overflow

O: Optimizations

R: Refactoring - DRY / SOLID / etc

E: Extensibility

S: Scalability

I use the "memory palace" heuristic to guide me through this, where each letter is a naked dude waving a flag on a racetrack I vividly remember from Gran Turismo back in the day. Absurdity helps it stick . I start every interview by writing this on the board and checking off the letters as I run through them. I usually stick another "O" in there for "Other stakeholders", depending on the gig.

This happens to work nicely when guiding/assessing interviewees through technical scenarios as well.

Don't complain that Chinese is ugly and unreadable just because you speak English as your native tongue.

Technically, the above is a snippet of C++ put into an APL variable "rth" but there's so much more to it than that, and so much more to the design that you're missing.

The design and choice of aesthetic in the compiler is a very intentional one that is arguably one of the main issues that has caused me to rewrite the compiler so many times over the years and has lead to this massive code adjustment.

There are very good reasons that the compiler is written in the style that it is, and you cannot compare it to other project's style guides.

Keep in mind that this compiler is designed to run natively on the GPU in a fully data-parallel fashion.

One major issue that I had to address, and I discuss a little bit in a thread above, is the idea of the malleability of the code base. It's critically important to this project that I be able to adapt and alter the compiler rapidly. For example, I recently had to rewrite the entire backend due to a shift in some underlying core technology. This shift lead to a shrinkage of about 2000 lines of code because the underlying supporting libraries were a better fit to what I needed than what I was using previous to this. But I might not have been willing or able to make this change if I didn't have confidence that the rewrite would be swift and fast. Indeed, it took only two months to rewrite the backend from scratch, add more new features, improve robustness, and so forth. The code also got cleaner.

This obsessive need to be highly adaptable leads me to the desire to have exceptionally "disposable" code. The cost for replacing or deleting code should be as low as possible.

This has a few follow ups. In order to achieve the above, I need to ensure that I understand the ramifications of deleting code as readily as possible as quickly as possible. This basically means that I need to be able to squeeze as much of the compiler into my head as possible, and what doesn't fit, I need to be able to "see" and "read" as quickly and as readily as possible.

The compiler is designed so that I can see as much as possible with as little indirection as possible, so that when I see a piece of code I not only know how it works in complete detail, but how it connects to the world around it, and every single dependency related to it in basically one single half screen full of code (usually much less than that) without any jumps, paging, scrolling or any movement. It means that I can completely understand the ramifications of any edit I make in nearly complete detail without any dereferencing or indirection. There are one or two places where there are some helper utilities which are on a different page, but these are part of the "domain vocabulary" which is basically in my mental cache any time I'm working with that code. I keep these "helpers" to a minimum, so that they can fit with anything else I want and not waste mental space in my head. Too many helpers leads to a failure to understand the complete macro picture and thus defeats my ability to delete code.

In order to make the code more readable, it has to be highly consistent and idiomatic. I take this to an extreme level. This code is highly regular and predictable, to an almost obsessive degree. I do this by enforcing a style discipline on the code that allows me to eliminate the use of a host of abstractions, further paring down the complexity of the programming language in which I'm working and allowing me to think in the same mental plane at all times.

The idea of semantic density is critical to this point. The semantic density of the APL code I'm using to solve the problem is at a certain rate. I maintain a consistent density rate by choosing my variable names in such a way that they visually align with the expressivity per character of the built in primitive symbols. This means that the cadence when reading the code is maintained. The "universal" naming scheme allows me to take any given name and know exactly its purpose, parentage, place, and use in the compiler without adding any additional cognitive overhead of inheritance syntax, datatypes, classes, or anything more than a name.

The C++ code above is written the way it is to allow it to stylistically align with the semantic density of the APL code. This means that I can jump between the runtime and the compiler portions of the code with minimal mental shifts between the two, because the style and approach are similar. The code can be "read" in much the same way with minimal change. I am intentionally prioritizing internal semantic and stylistic consistency over satisfying the popular expectations of how C or APL code should look. I believe the internal consistency within the project contributes more strongly to the day-to-day readability and hackability of the project.

Furthermore, I strongly restrict my use of programming languages features. This simplifies self-hosting, but it is primarily a means of maintaining stylistic and cognitive power. Since I know how I need to think about my problem "compilation on the GPU" in order to make it go, I can restrict myself to a paradigm that only allows me to think in this way. I choose a paradigm that is also exceptionally expressive to allow me to be productive as well. By selecting the right core paradigm, I can eschew further programmatic abstractions since they contribute nothing and only cost something.

One way in which I do this is to write the core of the compiler with only one or two syntactical conventions, and only one main programming method: function composition. The entire core of the compiler is a single points-free (almost), data-flow, data parallel expression. Names provide the anchor points of the "macro" level ideas, but the language is expressive enough that I need very few other anchor points. Instead, I use only function composition over the core primitives with a syntax known as "trains" to create the mental effect of working with normal expressions when in reality I create new functions with every line in the core compiler (which is 90 lines or so). By restricting myself to only writing in this style, the mental effect works. If I had to switch between expression level and trains/points-free style in the code, it would be much less readable. But because I can now treat my points-free programs as regular expressions for all intents and purposes, it actually simplifies my cognitive load, as there is only one thing to think about: function composition.

Is that actually true? From my cursory understanding, it seems that there has been a slew of theoretical breakthroughs (including ways to architecte and train networks aside from just blindly throwing more computation resources) that significantly pushed the field forward. Off the top of my head, I'm thinking of Hinton's 2006 DNN which pre-trained each layer one at a time as a restricted Botlzmann machine, computationally simpler activation functions like ReLu, the development of residual networks, the development of GANs, etc.

Of course GPU-based training has helped a lot, but my impression is that these theoretical breakthroughs were also important.