It's a fascinating bit of information that demands minimal time to absorb and comprehend. It's a refreshing break from the usual content seen here while still being intellectually stimulating.
English can do reasonably well if you don't mind poetic sounding language (and, to be fair, Shakespeare compressed down a lot of things into shorter, poetic idioms we use today). Something like her farewells overran, perhaps.
I am not sure why I upvoted this. Perhaps because I have dealt with C, C++, Java, JavaScript and some Python. I know a smattering of French, German, Dutch, Japanese and Czech. So perhaps that too. Or perhaps because of the Sapir–Whorf hypothesis.
Aside from anything else, human language and its comprehension is an important aspect of AI, and the sheer variety among grammars is a salient feature that cannot be ignored.
I think it's useful mostly as a sort of Linnæan classification device—it's a lot easier to compare different type systems by placing them on a 'standard' cube, than by choosing ad hoc points of comparison.
Type theories are formal logic languages. People use formal logic for all sorts of things but mathematics has the longest history. This is where people first defined formal languages and assigned meaning (mathematical meaning.)
Starting from simply typed lambda calculus ("simple type theory", also "higher order logic"), one can make various extensions that make the logic language more expressive. The lambda cube is a way to systematically organize the space of type theories.
Interestingly, the theory has become very relevant for type systems of normal programming languages. Milner invented ML as "meta language" for helping with logic and theorem proving, but it was used widely and today everyone expects generics to work more or less as in System F polymorphic lambda calculus.
This is why people think these concepts aren’t useful, because this was a lot of words without any practical example of what it would be used for.
Here’s a practical example: there are type systems in the lambda cube that allow us to statically check that a list has a certain length. That means a compiler can prevent an out of bounds access error, without human intervention. I have written code that crashes because of an out of bounds access, so the idea is interesting to me.
> The lambda cube is a way to systematically organize the space of type theories.
All of this was already meaningful before the lambda cube. The cube just organizes what we knew in a systematic way. It shows the relationships between the various systems that exist when they are differentiated on the features that describe their expressive power.
Not cool. It sets a bad precedent for the community by trying to game the (unwritten) rules. In equilibrium, HN is drowned by blogspam and people leave HN.
So, you're doing whatever sequence is better. It's a general case of the example you mention:
With one permutation (yours), you can get everything done.
With another permutation (relax first, meeting prep later) - you might be leaving the prep for the last minute.
There's some cases when the first permutation is better - when you have enough energy, say, and the meeting is important.
There's other cases when the second permutation is better - when, say, you're already low on energy and the meeting isn't that important - so you're prioritising relaxing.
There's more examples on the linked page[0]
An example of neither delayed gratification, nor priorities:
Permutation 1: Accusing someone of spewing non-sense, then understanding what they really meant.
Permutation 2: Understanding what they really meant, and then, if necessary, accusing them of spewing nonsense.
Permutation 2 as a habit leads to better outcomes. Mostly.
I have to keep reminding myself that everyone isn't like me.
In my private talks with myself, I refer to this skill as modelling other people well: in effect, I'm trying to build models for different kinds of people.
There's lots of different kinds, and a few broad types show up, explaining most of their (general / broad) actions.
This is still very much a work in progress for myself too, but would be very interesting to see if I get somewhere substantial.
One thing I'd expect to see more of in this type of article would be understanding the business domain. It sounds like you understand the value of doing so from your section on leaning what others around you are doing. But I think over time, you'll see that learning those specific business nuances is what separates the promising engineer from the seasoned veteran who hears a business problem and already knows the 4 ways it's been attempted to be solved and why they didn't work. And importantly, still has the optimism to try again in a different way! I recognize every organization is different so YMMV.
Rereading my post it may have came off as a bit of a backhanded compliment and wasn't intended as such. Terrific post. I think it will help a lot of people.
That's probably because the content in this post is more about "soft skills" or what many would consider fluff.
"habits of mind", "tools of thought", "force multiplier", "superpowers" "embrace fear" etc. reads straight out from a Tim Ferris-like self-help book targetting millennials than anything a senior engineer would write.
I read your last year's post - that one was much more useful and insightful. So +1 (upvote) to more of those.
Can someone explain how the title fits the article? I was .. pretty pissed once I reached the end (almost all of it interesting) to find it's not related to the title at all.
