[jkhdigital]

I started teaching undergraduate computer science courses a year ago, after ~20 years in various other careers. My campus has relatively low enrollment, but has seen a massive increase in CS majors recently (for reasons I won’t go into) so they are hiring a lot without much instructional support in place. I was basically given zero preparation other than a zip file with the current instructor’s tests and homeworks (which are on paper, btw).

I thought that I would be using LLMs for coding, but it turns out that they have been much more useful as a sounding board for conceptual framing that I’d like to use while teaching. I have strong opinions about good software design, some of them unconventional, and these conversations have been incredibly helpful for turning my vague notions into precise, repeatable explanations for difficult abstractions.

[iib]

I found Geoffrey Hinton's hypothesis of LLMs interesting in this regard. They have to compress the world knowledge into a few billion parameters, much denser than the human brain, so they have to be very good at analogies, in order to obtain that compression.

[TeMPOraL]

I feel this has causality reversed. I'd say they are good at analogies because they have to compress well, which they do by encoding relationships in stupidly high-dimensional space.

Analogies then could sort of fall out naturally out of this. It might really still be just the simple (yet profound) "King - Man + Woman = Queen" style vector math.

[bjt12345]

That's essentially the manifold hypothesis of machine learning, right?

[normie3000]

> I have strong opinions about good software design, some of them unconventional

I'm jealous of your undergrads - can you share some of the unconventional opinions?

[jkhdigital]

Another principle that builds on the other two, and is specifically applicable to Java:

- To the greatest extent possible, base interfaces should define a single abstract method which allows them to be functional and instantiated through lambdas for easy mocking.

- Terminal interfaces (which are intended to be implemented directly by a concrete class) should always provide an abstract decorator implementation that wraps the concrete class for (1) interface isolation that can’t be bypassed by runtime reflection, and (2) decoration as an automatic extension point.

[jkhdigital]

I’m required to teach DSA in Java, so I lay down a couple rules early in the course that prohibit 95% of the nonsense garbage that unconstrained OOP allows. Granted, neither of these rules is original or novel, but they are rarely acknowledged in educational settings:

1. All public methods must implement an interface, no exceptions. 2. The super implementation must be called if overriding a non-abstract method.

The end result of strict adherence to these rules is basically that every feature will look like a GoF design pattern. True creative freedom emerges through constraints, because the only allowable designs are the ones that are proven to be maximally extensible and composable.