Things I Was Wrong About: Types

Re:Things I Was Wrong About: Types by throwaway894345 on Sunday September 27, 2020 @10:31AM (#24606915)

I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of the project and their willingness to trade bugs in other paths for a feature that appears to be working. The cognitive mismatch is that it's intended change the way you think and program so you can move quickly on many paths at once (not only your very narrow happy path)--with a well-crafted type system, we can move fast and have quality. Note also that 'quality' isn't just about bugs, but also about a code base that is maintainable, similar to the GP's and the parent's observations about the unmaintainability of their PHP and Perl code bases.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by mettamage on Sunday September 27, 2020 @01:29PM (#24608363)

Yea, I agree and for this reason when I teach type systems to new programming students, I tell them that a type is somewhat analogous to a building material. You have brick, wood, steel and iron. You want to build a house that has solid bedrock and has easy forest fires in the area. What material would you use? Most would say rock.

Then I tell them about strings and ints. You can represent 66 both with strings and ints, but one is usable for computation where the other one is simply usable to write Alice in Wonderland with it, or simpler forms of text. Sometimes I get the question then: why can't a string both be computational and as a means of character display? And then I list the upsides and downsides of such a system, just like the upsides and downsides of mixing brick and wood to build the outer wall of a house.

I'm curious if people can think of other analogies that they use for teaching.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by jt2190 on Sunday September 27, 2020 @02:23PM (#24608901)

Why do you need an analogy at all? Are your students deeply familiar with the construction characteristics of wood and brick already and ready to draw parallels to software? How do those things relate at all to the subject at hand, strings as “means of display” (data?) versus strings as “computational” (keywords, operators, etc?).

Personally, I avoid analogies because they usually mean I don’t really know how to teach the topic, and I’m “hand-waving” on the fly. I either find a way to build on the student’s existing knowledge or I “park” the topic for discussion when the student has enough knowledge to give a correct answer.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by kevinwcyu on Monday September 28, 2020 @04:48AM (#24614458)

I appreciate analogies when I start learning something. Although it's not a perfect representation of what's being taught, it makes it easier for me to start thinking about the topic I'm learning. I can fill in the details later. I think it's useful for certain types of learners such as myself. Although I'm not deeply familiar with the characteristics of construction materials, I was more familiar with them compared to types when I was learning about them. So it would've been a helpful analogy for someone like me.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by throwaway894345 on Sunday September 27, 2020 @01:37PM (#24608441)

I don’t know if this is pedagogically useful, but I think of types as shapes, variables (including struct fields and function parameters) as a shaped hole, and values as a shaped thing that can fit (or not fit) into those holes. Kind of like the children’s toy. You don’t want to pass a circle in to a function that needs a square shaped thing, and the type system helps make sure you don’t do that by accident.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by sumitkumar on Sunday September 27, 2020 @06:32PM (#24610711)

If we think of variables as boxes and types as label on those boxes, does it makes sense to have labels on the boxes if complexity of opening the box just to see what is inside goes up?

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by cuddlybacon on Sunday September 27, 2020 @03:07PM (#24609296)

I think types also get in the way of writing speculative code, which is something I did a lot more often when I was new.

Run what you have so far. Print the last value you computed. Crash. Verify the data has the "shape" you expect it to. Write a bit more code. Repeat.

[ Parent | on HN ]

Re:Things I Was Wrong About: Types by throwaway894345 on Sunday September 27, 2020 @05:43PM (#24610368)

Probably a little. I might lack average cognitive facilities, but I find that types pay off for me very early. When I worked in a Python shop, I would prototype in Go because the types helped me move fast, and then I could port it to Python (often for a huge performance loss, not to speak of maintainability) to integrate with the code base.

On the other hand, Python’s repl was nice for a small handful of tasks (although I mostly used it for figuring out what the actual type of some variable was, which is obviously a non-problem in the statically typed world).

[ Parent | on HN ]