Every programming language in (another) 15 minutes: data types

A very brief survey of the most essential concepts about data types common to most programming languages. Follow up to • Every Programming Lang...

[@OggerFN]

I really like these videos. Nothing knew but solid, language unspecific basics. That's what cs university should be like.

[@MenkoDany]

I thought I wouldn't learn much from this video, but I actually learned a lot because it connected some ideas in my head and revealed relationships that I haven't seen before, great content!

[@cacheman]

11:18 I think you got your Whale and Dolphin mixed up in the commented green text.

[@valcron-1000]

Solid content. Very clear explanations.

[@jaehyi2009]

Excellent tutorial!

[@noahwilliams8996]

I think this could benefit from an explanation of how these work internally.

[@luckyboy20021]

you're the best

[@BruceRicard]

Beware that inheritence does NOT imply sub-typing, in general. You can in theory have a Dog class inheriting an Animal class such that you cannot upcast an Animal into a Dog.

[@MuhammadBinZafar1]

Suddenly inheritance & interface & sub-type started to stop making senses.

[@Madsy9]

Good video and explanation overall. Only constructive criticism I have is the emphasis on downcasting which is generally a bad idea, although I can see why you went that route. A better way to get access to the concrete type is to put the code that depends on it somewhere with more context: Where you have access to the this-reference. I'm assuming here that your videos here is only about languages with single-dispatch, since you mentioned this-references. For single-dispatch languages with a 'this' or 'self' reference, you would typically use what's called the Visitor pattern or at least something of the same flavor. A situation where this is useful would be in the example you mentioned with an array or collection that uses subtyping to get around arrays being homogeneous. A visitor implementation would allow you to perform some operation on the array that requires knowing the subclass of each individual element, but be more maintainable and less error-prone than downcasting.

[@zxxczczczcz]

yes

[@Dan-gs3kg]

The funny bit is that this is heavily biased towards Haskell's opinions on types, and polymorphism. Not a bad thing, but gives an argument for replacing OOP with FP, while clarifying why OOP leaves you exposed to various problems.

[@0ptikGhost]

The video uses terminology that is particularly popular in functional languages but that terminology is still appropriate and correct for imperative languages. In fact, I can't think of a single imperative language for which the statements made in this video are incorrect.

[@firephoenixgamers8590]

@@0ptikGhost ^^^^^

[@raianmr2843]

This is like going to a biotech conference and complaining about why everyone is pro-vaccine. Type theory is a research domain led almost entirely by functional programmers and researchers. Alan Kay's OOP instead advocated for extreme late-binding and dynamic typing. C++, Java, and C# merely inherited the need for at least a barebones type system from C.