Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't Be Afraid of Types

lmika.org

Post reply on HN
Print view View original

101–110 of 233 posts

Re: Don't Be Afraid of Types

#101

Post by enriquto »

MrMcCall wrote: post #90
enriquto wrote: post #76

Earlier quoted context omitted.

> 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…

Sorry man, I was just trying to spew some harmless banter.

Re: Don't Be Afraid of Types

#102

Post by throw_m239339 »

DeathArrow wrote: post #70

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…

Inheritance is one way to achieve polymorphism. it is not mandatory for OOP.

Unfortunately YES, because of "Java Entreprise" pushed by consultancies 15 years ago, a lot of developers insist on encapsulating everything, even when it's redundant.

Fortunately, Java is a better language today.

Re: Don't Be Afraid of Types

#103

Post by wruza »

bluGill wrote: post #88
enriquto wrote: post #68

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 r…

I experience it often in teams less than 2 developers and projects less than 2000 lines of code (that's still 50 pages, btw). It boils down to being able to load everything into your mind, and that heavily depends on a type of a project, data/code models, ide, etc, and also various factors unrelated to coding.

A human mind is a cache -- if you overload it, something will fly out and you won't even notice. Anyone who claims that types have no use probably doesn't experience overloads. If it works for them, good, but it doesn't generalize.

Re: Don't Be Afraid of Types

#104

Post by RodgerTheGreat »

bluGill wrote: post #88
enriquto wrote: post #68

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 r…

Sure! But many, many useful programs will never need to grow to millions of LoC or thousands of developers.

Re: Don't Be Afraid of Types

#105

Post by svara »

efficax wrote: post #92
jt2190 wrote: post #87

Earlier quoted context omitted.

> … [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 ?

it’s common to be imprecise and mix up the type and an instantiation of the type, and that’s all that is happening here

It's usually not just imprecision though, I've found that a lot of programmers fundamentally don't understand what types are and this confusion might be an example of that.

Types are just a layer on top of your code that help enforce certain logical / mathematical properties of your code; those that your particular type system enables you to constrain.

Most actual type systems are not powerful enough to allow you to fully specify the logical objects you are actually working with, but thinking about exactly what they are and how to constrain them as well as you practically can (or should) is in my experience one of the important skills of an advanced programmer.

By the way, if you know what I mean and have found a good way to effectively teach this way of thinking, let me know, because I have often been unsuccessful. I see people left and right thinking about code as a procedure that will with trial and error ultimately be made to work, rather than as an implementation of logical / mathematical objects that can be correct or not.

Re: Don't Be Afraid of Types

#106

Post by usernamed7 »

enriquto wrote: post #68

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…

Files have types though: .txt, .jpg, .bin, etc.

Re: Don't Be Afraid of Types

#107

Post by jerf »

salmonellaeater wrote: post #3

> I found that there’s a slight aversion to creating new types in the codebases I work in. I've encountered the same phenomenon, and I too cannot explain why it happens. Some of the highest-value types are the small special-purpose types like the article's "CreateSubscriptionRequest". They make it much easier to test and maintain these kinds of code paths, like API handlers and DAO/ORM methods. One of the things that…

This can't be the explanation for everything, but I do know that once upon a time just the sheer source-code size of the types was annoying. You have to create a constructor, maybe a destructor, and there's all this syntax, and you have to label all the fields as private or public or protected and worry about how it fits into the inheritance hierarchy... and that all still applies in some languages. Even the dynamic scripting languages like Python that you'd think it would be easy tended to need an annoying and often 100% boilerplate __init__ function to initialize them. You couldn't really just get away with "class MyNewType(string): pass" in most cases.

But in many more modern languages, a "new type" is something the equivalent of

     type MyNewType string
or

     data PrimaryColor = Red | Green | Blue
and if that's all your language requires, you really shouldn't be afraid of creating new types. With such a small initial investment it doesn't take much for them to turn net positive.

You may need more, but I don't mind paying more to get more. I mind paying more just to tread water.

And I find they tend to very naturally accrete methods/functions (whatever the local thing is) that work on those types that pushes them even more positive fairly quickly. Plus if you've got a language with a halfway modern concept of source documentation you get a nice new thing you can document.

Re: Don't Be Afraid of Types

#108

Post by chamomeal »

DeathArrow wrote: post #70

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…

Uncle Bob in particular is a funny case. I feel like his books are largely credited as the being source those very particular OOP obsessions

But he eventually turned to the dark side. He claims clojure, a functional lisp, is his absolute favorite language.

He’s even got blog posts about it! Multiple!

I stumbled on this while reading about clojure. I really like his blog!

https://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure....

Re: Don't Be Afraid of Types

#109

Post by tarcon »

DeathArrow wrote: post #70

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…

Humans reason with objects much better because that's how the real business world works.

Re: Don't Be Afraid of Types

#110

Post by necovek »

Hojojo wrote: post #43
necovek wrote: post #27

Please be afraid of types. On top of new cognitive load, introduction of redirection, and anti-patterns like pretend-simplification where you shuffle a bunch of unrelated parameters into a struct to make a function receive only a single argument (which quickly evolves into functions receiving parts of that struct they don't need, making use and testing much harder — I am surprised an article is really recommending th…

Conversely, do you also consider the downsides and consequences of not having types? If you don't, then you're blind to whole categories of issues. As a good engineer, you need to be able to reason both ways to come to a reasonable solution, not just one that conforms to your particular ideology.

How do you understand the sentence above:

> Benefits of types should be carefully balanced against the cost of introducing them

Does "benefits of types" not imply to you that there are downsides to not having them?

Post reply on HN