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

Things I Was Wrong About: Types

v5.chriskrycho.com

Post reply on HN
Print view View original

271–280 of 468 posts

Re: Things I Was Wrong About: Types

#271

Post by novok »

I would even assert the amount of typing you get in a language like Java or even C is very useful. I think a big reason why the python 2 to python 3 transition was so painful was a lack of static typing.

Unlike other languages where if you update to the new version and get a whole bunch of build errors about methods not existing for a type or this function now returns a different type, you had to run an %80 of the way there migrator who's effects you weren't completely sure about and run your app through your unit test suite. Almost nobody has %100 unit test coverage to approximate what a build statically typed language compiler does, some functions 'worked' anyway due to duck typing and did behaviors that were different than what you were expecting and a bunch of methods returned a slightly different string type that gave more errors, only when you ran the code, each exception at a time.

While in a static language you can just run it, and you would of saw all the places where a function now returned a bytestring and deal with them all at once, properly. I've dealt with several breaking change migrations with the swift language, and although annoying, it was tractable and only took a day or two without worries about hidden gotchas.

Nowadays my minimum requirements for static types are:

- Nullable types (does this type container accept nil or not)

- Very basic generics for containers

- Typical static typing features

Bonus:

- Enums with variables (also known as ADTs)

The reason why I chose these features specifically is they give you a lot of benefit, but are not actually slow to compile and not complicated to implement for language maintainers when first writing a language. I hope golang has all of them one day.

Re: Things I Was Wrong About: Types

#272

Post by SebastianKra »

deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

> reason it never took off in a serious way is because it combines all the downsides of dynamic typing with the downsides of static typing. Types are meant to document code. Without the annotations, you can't look at code and know what is going on.

Type annotations aren't for me, they're for the compiler and the IDE. If I wan't to know whats going on inside a variable, I cmd+hover over it.

Re: Things I Was Wrong About: Types

#273

Post by mlthoughts2018 »

dpc_pw wrote: post #191
mlthoughts2018 wrote: post #93

This is the opposite of my progression. I worked professionally with Haskell for 6 years and then Scala for 2 years at the early stages of my career. Static typing is a waste of time that does not facilitate better design, better clarity or safer code. The classes of errors detectable and preventable with static typing are almost never very important, and in dynamic languages you can achieve the same results with lig…

Let me guess. You probably worked in small teams, mostly with code you co-wrote your whole carrier. You literary compare 3 languages that you happened to use and think that all there is to know about this argument.

No, the Haskell job was in a large financial service firm with a huge investment in Haskell. Many people on the team were even experienced with GHC compiler engineering. The code base was very large and cross-org.

All the other jobs have been in large ecommerce firms, again with large codebases cutting across the org, and separate pockets of “small project” development here and there.

I also have many years of experience in C and C++, both of which are solid. I especially like writing systems in C because it’s easy to make it module oriented, and static typing doesn’t need to have anything to do with concept or domain modeling, yet you still can occasionally sprinkle it in with simple structs. I like C++ without classes or exceptions, but the language outgrew that way of using it.

The best approach I ever saw to using Haskell at scale was to severely disallow any complex type system feature, like even disallowing lensing or custom type classes. Just ruthlessly stick only to basic language features and module oriented design. When you make your own data structures, never generalize them to inherit functionality through type classing, rather always rotely splay out a new module of all the functions and behaviors for operating on that data structure. Do not seek to endow it with any type of compositional behavior besides very basic plain function composition (eg no monadic behaviors).

Re: Things I Was Wrong About: Types

#274

Post by masklinn »

TeMPOraL wrote: post #141
cconroy wrote: post #99

Earlier quoted context omitted.

"statically, strongly typed Lisp that still doesn't sacrifice its flexibility and expressive power" SML

... with sane (i.e. s-expression based) syntax. :). But I'll check out SML. That's Standard ML, right?

> ... with sane (i.e. s-expression based) syntax.

You can just enclose all your function calls in parens :D

Also you probably want to check out OCaml rather than SML, I don't know that SML has much of a presence… anywhere really.

Re: Things I Was Wrong About: Types

#275

Post by mantap »

igouy wrote: post #172
mantap wrote: post #59

A good static type system is better than dynamic typing. But, dynamic typing is better than a bad static type system. A bad static type system will slow you down, forcing you to appease its irrelevant complaints, and pervert your code into a form that no sane programmer would choose to write it in, if it weren't for the type system looking over their shoulder. I won't mention any names, but suffice to say such langua…

good is better than bad !

Not quite. Good > none > bad. This relation is not universal, it does not apply to pizza :)

Re: Things I Was Wrong About: Types

#276

Post by Jtsummers »

novok wrote: post #271

I would even assert the amount of typing you get in a language like Java or even C is very useful. I think a big reason why the python 2 to python 3 transition was so painful was a lack of static typing. Unlike other languages where if you update to the new version and get a whole bunch of build errors about methods not existing for a type or this function now returns a different type, you had to run an %80 of the wa…

> I think a big reason why the python 2 to python 3 transition was so painful was a lack of static typing.

And I'll add compilation vs interpretation to this. I have, on a couple of occasions, had to update Java or C# code from one version to a much newer version. This meant that deprecated features were often used (more an issue with the Java cases). Thanks to actually compiling the code and the static typing, most of the things I needed to update/change were apparent from the start. This didn't mean they were good "modern" versions of the program, but they were functional and operational and could interact with newer Java and C# code bases properly with only a week or two of effort.

The same was true when a library was changed in a breaking way (at the interface level). Of course, you still need tests when semantics of the library change (like it returns the same type, but with different meanings), but that's usually well-documented.

Re: Things I Was Wrong About: Types

#277

Post by cannabis_sam »

rswail wrote: post #159

A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code. Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a s…

It’s honestly embarrassing to hear all the worthless arguments against types.

The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load???

It’s just so endlessly easier to program with types

Re: Things I Was Wrong About: Types

#278

Post by didibus »

I think a point not often brought up is that Java takes a stance against type inference. It argues that type inference can lead to bugs, because sometimes it doesn't infer the type you meant and makes code harder to read. So explicit types it is. Also inference slows down the compiler and similarly the auto-completion.

Now, I'm in the camp where I don't really think static type checkers are all that great. I judge languages as the sum of their parts, and in that way, you can easily rank one statically typed lang above a dynamic lang and yet rank another dynamic lang above both of them.

I just bring up Java's stance, because I find it interesting. I tend to find most static type checkers enthousiasts have an internal conflict between static types make for programs with less defects, static types help me navigate my code, and static types are too verbose.

See this SO for context: https://softwareengineering.stackexchange.com/a/184183/89630

Re: Things I Was Wrong About: Types

#279

Post by dddbbb »

throwaway17_17 wrote: post #210
dddbbb wrote: post #96

Earlier quoted context omitted.

Haskell's Either is a 'true' sum type, it corresponds exactly to the way sums have been defined in the literature for decades, and also is the Curry-Howard representation of logical or. It necessarily must be inside a Either-like wrapper in order to be type safe, String and Int are ultimately different and so at some point we must discriminate between them. foo could call further functions with its argument inside it…

I’m curious, is the ‘true’ sum types, I mean where true is in quotes, based on the premise that lazy language can not have logically true sum types? Or is it in the quotes for some other reason?

I was just responding to the parent comment's claim that Haskell's sum types are not true sum types.

Re: Things I Was Wrong About: Types

#280

Post by Jtsummers »

willtim wrote: post #110
jondubois wrote: post #65

Earlier quoted context omitted.

I agree. I think the downside of static typing is that it encourages developers to pass around complex types between functions instead of simple types and I think this is a mistake. If you have the option between creating a function which accepts a string (e.g. ID) as argument or accepts an instance of type SomeType, it's better to pass a string because simple types such as strings are pass-by-value so it protects yo…

If you use String for all your data types than you are no better than a dynamic language. There are many string like things that benefit from their own types, e.g. currency, identifiers, post codes. Such types should only be created from a parse of valid strings, i.e. no empty strings, whitespace, illegal values etc. They do not have to be Alan Kay "objects", despite what your language or thought leadership is tellin…

> If you use String for all your data types than you are no better than a dynamic language.

I once read a Haskell (I believe, may have been SML or OCaml, this was a while ago) tutorial (can't find it anymore) that did this. It was infuriating as it completely hid the benefit of the type system. Essentially, details fuzzy, it was creating a calculator program. Imagine parsing is already done and had something like this:

  eval "add" a b = a + b
  eval "sub" a b = a - b
  ...
Where the parsing should've at least turned those strings into something like an Operation type.

Sadly, I've seen similar programs in the wild at work (not using these languages, but with C++, Java, C#) where information is encoded in integers and strings that would be much better encoded in Enums, classes, or other meaningful typed forms.

Post reply on HN