Live data from Hacker News

Don't Be Afraid of Types

lmika.org

81–90 of 233 posts

Re: Don't Be Afraid of Types

#81

As somebody who is afraid of types (and also, who hates types, because we all hate what we fear), may my point of view serve as balance: you don't need a type system if everything is of the same type. Programming in a type-less style is an exhilarating and liberating experience: assembler : everything is a word C : everything is an array of bytes fortran/APL/matlab/octave : everything is a multi-dimensional array of…

But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and they each have their own individual access patterns and, more importantly, modification functions. You can't add a number to a string, only to another number. If you are dealing with a float, you better be careful how you check it for equality. If it's pure bina…

> You can't add a number to a string

Haven't written JavaScript?

Re: Don't Be Afraid of Types

#82

> That’s what the type system is for: a means of grouping similar bits of information into an easy-to-use whole. While types can be used for that, they are a much broader concept. I would say the general purpose of types is to tell apples from oranges.

not to mention having some actual confidence when making changes to a project! especially one you didn’t author.

...even in a strictly-statically-typed language with a perfectly expressive type-system, it would be unwise to rely _only_ on a "Build succeeded!" message for having confidence in any changes to the system: there's no substitute for well-trodden unit and integration tests for any codebase of nontrivial importance or complexity.

Re: Don't Be Afraid of Types

#83
post #19

Huh. I don't see any conflict between loving OO-programming and also loving types. Isn't 9/10ths of OO just about consolidating your business logic into interfaces and types that you'd ideally want to re-use? I feel like if it's not, then people are using OO the wrong way.

You can love conflicting things, but the basis of OO programming, that which makes it object-oriented and not just object-based, is message passing, which sees messages flow between objects for inspection. That is inherently runtime behaviour which is at odds with static type enforcement.

Swift has built-in support for actor-classes - which are strongly-typed too (not that it wasn't already easy-enough to define a self-driven actor class without the added syntactic-sugar) - I'm curious if you've tried that and how it fits into your notions of what OOP should be like.

Re: Don't Be Afraid of Types

#84

In Java you can’t just create a type. You are creating a mini app. Classes in Java hold logic and internal mutating state. I don’t want to create this just because I need a type. Really you want to create a struct or an interface as a type.

Luckily Java now has "Record" to partially handle the pain.

Re: Don't Be Afraid of Types

#85

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

That is what happens when all too commonly people treat OOP as their religion. Prefer encapsulation to inheritance is good advice. Interfaces are very useful if you have more than one implementation (mocks/fakes do not count), but otherwise pointless. Having private data is always a good idea - no matter what your code style is you don't want to have to look over all 10+million lines of code anytime you need to change data. (there is no clear answer to how the size of a circle should be stores - radius, diameter, circumference, area - given one you can easially calculate the others, but there are implications to whatever choice you make and sometimes you will discover late that you made the wrong choice).

> we [snip] use encapsulation." "Yes, but why?"

Simple: because when your program gets large you cannot know everything needed to modify the code. You need places where you can say "something really complex happens here and I must trust it is right" (not to be confused with it is right, only that right or wrong is irrelevant)

OOP is a great answer to the problems of large complex programs. It is not the only answer. It sometimes is the best and sometimes not. Applying it like a religion is wrong.

Re: Don't Be Afraid of Types

#86

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

In that setup, how do you write a test which acts against a mock version of your API client (a static function in your proposal?)

Re: Don't Be Afraid of Types

#87

People might be afraid of types because in OOP land there's the idea that types aren't mere containers for data. You have to use encapsulation, inheritance and polymorphism. Fields and properties shouldn't have public setters. You assign a value only through a method, otherwise you make the gods angry. You have gazillions of constructors, static, public, protected, private and internal. And you have gazillions of met…

> … [I]n OOP land there's the idea that types aren't mere containers for data.

Can you elaborate? Types don’t contain data in any way that I understand… Do you mean constrain?

Re: Don't Be Afraid of Types

#88

As somebody who is afraid of types (and also, who hates types, because we all hate what we fear), may my point of view serve as balance: you don't need a type system if everything is of the same type. Programming in a type-less style is an exhilarating and liberating experience: assembler : everything is a word C : everything is an array of bytes fortran/APL/matlab/octave : everything is a multi-dimensional array of…

I've programmed in typeless languages and they are great for small programs - less than 10,000 lines of code and 5 developers (these numbers are somewhat arbitrary, but close enough from discussion). As you get over that number you start to run into issues because fundamentally your word/array of byte/multi-dimensional array of floats/ ... has deeper meaning and when you get it wrong the code might parse and give a result but the result is wrong.

Types give me a language enforced way to track what the data really means. For small programs I don't care, but types are one of the most powerful tricks needed for thousands of developers to work on a program with millions of lines of code.

Re: Don't Be Afraid of Types

#89

As somebody who is afraid of types (and also, who hates types, because we all hate what we fear), may my point of view serve as balance: you don't need a type system if everything is of the same type. Programming in a type-less style is an exhilarating and liberating experience: assembler : everything is a word C : everything is an array of bytes fortran/APL/matlab/octave : everything is a multi-dimensional array of…

ruby: everything is an object

Re: Don't Be Afraid of Types

#90

Earlier quoted context omitted.

But once you get down to the unit data values inside any of those aggregates, you're still dealing with either characters, ints, floats, strings, arrays, and they each have their own individual access patterns and, more importantly, modification functions. You can't add a number to a string, only to another number. If you are dealing with a float, you better be careful how you check it for equality. If it's pure bina…

> And your saying "everything is a word" for assembler is just plain wrong. I also love x87 registers, but they are becoming rarer these days.

Your profile says "just another C hacker".

I learned C from reading K&R in the late 80s.

Every C compiler I've worked with could output the code as assembler, so C is really a thin layer of abstraction that wraps assembler. Having programmed in pure assembler before, I understand the benefits of C's abstractions, which began with its minimal, but helpful, type system.

Should I not be taking you seriously?

We are not just talking with each other but sharing our expertise with those who may be reading.

Sometimes I forget that other people can just be unpleasant on purpose. I find no other explanation for your response.

Post reply on HN