Live data from Hacker News

Why Type Systems Matter

matthias-endler.de

71–80 of 103 posts

Re: Why Type Systems Matter

#71

There is never a person more zealous (and vocal in their zealotry) than a new convert. You don't see the bad points, just the good. That's how this post comes across: "Types are so awesome, let me show you how awesome types are!" Come back in two years, show us how the types feel after the honeymoon is over.

While I agree that type systems often get in the way, and that the author is only pointing out bad points and not good ones, aren't you doing the same? At least the author is trying to back up their claims (e.g. they provide an example where someone decided to put sizes in strings).

The honeymoon part is also an unfair assumption, not to mention incorrect. I just clicked on "About me", clicked on the author's github link, and after some scrolling and clicks, I found a rust commit from August 2015 the author made - thus, the author has been here for 2 years, and is not some newbie.

You should provide a list of cons involved with type systems that aren't so glaringly obvious that the author has probably already ran into them, and that will serve as a much stronger argument (e.g. you could bring up the fact that in large codebases with lots of generics, type systems drastically increase time spent typing, as well as cognitive overhead when there are s and s and so on all over the place).

Re: Why Type Systems Matter

#72

I thought this was quite clear, and it's what I've always been missing in languages like Python or JS. Yet I meet many devs, especially coming from such languages, making fun of Java for its verbosity and clumsiness. On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.

> They just randomly change types until it somehow compiles, without thinking about what their doing.

I did that, too, when I was inexperienced with C++. Especially with const, but also with * and &. But somehow it "clicked" at one point and I don't have that problem anymore.

In recent times, I've found static type systems to helpfully nudge me in the direction of correct code. I was pleasantly surprised by TypeScript. Also, in modern C++, if you use unique_ptr, shared_ptr, try to get rid of naked pointers, and use value types and RAII if possible, the code ends up a lot cleaner. I've found a couple of places where ownership was unclear, and I previously had circular references or dangling pointers as a result.

And anecdotically, the way people program in Haskell is basically, write what you mean, and then fix it until it compiles; it will likely also be correct.

Re: Why Type Systems Matter

#73
post #56

Earlier quoted context omitted.

Person myPerson = new Person("My", "Name") You need to specify the class twice on the same line, because Java can't figure it out on its own.

The left hand side only reserves the memory, the right hand side actually initializes the object. A bit redundant I agree, but to the compiler it is two atomic operations.

It is two separate operations, but in many other languages the compiler is smart enough to figure out that they'll be the same type (and allow you to specify it when they're not)

That's what I mean—Java's type system is verbose and clumsy, because it doesn't bother trying to figure out things it could figure out, forcing the programmer to be redundant and repeat themselves all over the place. The fact that it's 2 separate operations to the compiler shouldn't dictate anything about the language.

Re: Why Type Systems Matter

#74

There is never a person more zealous (and vocal in their zealotry) than a new convert. You don't see the bad points, just the good. That's how this post comes across: "Types are so awesome, let me show you how awesome types are!" Come back in two years, show us how the types feel after the honeymoon is over.

While I agree that type systems often get in the way, and that the author is only pointing out bad points and not good ones, aren't you doing the same? At least the author is trying to back up their claims (e.g. they provide an example where someone decided to put sizes in strings). The honeymoon part is also an unfair assumption, not to mention incorrect. I just clicked on "About me", clicked on the author's github…

Because my comment was not about type systems, it was about the fervor and lack of usefulness of the post itself. Plus, I'd just be repeating myself and others much more eloquent than I - why do that?

Plus, arguments about typed languages rank up there with vi vs Emacs (or is it now vi/emacs vs. Atom/VSC?) in terms of my interest in joining them. I like statically typed languages. I like dynamically typed languages. I dislike weakly typed languages. What more to add?

Re: Why Type Systems Matter

#75
post #61

Earlier quoted context omitted.

> Perhaps rocky1138 thinks this because they have experience answering this question by doing so? They have experience with their problem solving style, they don't have experience with every problem solving style, or even necessarily with my problem solving style. You can't infer much from that, and certainly not that typing is "not great when prototyping". > Just to be clear, I'm talking about recognizing the monads…

> They have experience with their problem solving style, they don't have experience with every problem solving style, or even necessarily with my problem solving style. You can't infer much from that, and certainly not that typing is "not great when prototyping". I tend to grant the first person who states their opinion in absolutes the nicety of automatic insertion of "it is my opinion/experience that," because this…

> Is in inconceivable that a programmer can check their types manually, using an ad hoc intuitive type system?

Sure, if you don't mind an ad-hoc, informally specified, bug-ridden, slow implementation of half of a type checker that no one but you knows (and so is "intuitive" only to you... until you read this same code 3 months later).

Re: Why Type Systems Matter

#76

There is never a person more zealous (and vocal in their zealotry) than a new convert. You don't see the bad points, just the good. That's how this post comes across: "Types are so awesome, let me show you how awesome types are!" Come back in two years, show us how the types feel after the honeymoon is over.

> Come back in two years, show us how the types feel after the honeymoon is over.

I have been programming for more than 20 years, with a lot of different languages.

Until six years ago, most of my languages were on dinamic typing (PHP, Bash, Perl5, Python, Ruby, ...). I used C sometimes, but it was not the common case.

Then, 6 years ago, a friend show me Scala. I was lucky because I could use it in my daily job. Two years ago I started to use Rust for some stuff.

That said, after years using languages with good type systems, I can say dealing with a dinamic type system in a big project is a huge PITA. Almost every time I have to deal with legacy code (mostly Ruby) I really miss both Scala and Rust.

The honeymoon is over for me, and now I'm in a very stable and wonderful relationship :P

Re: Why Type Systems Matter

#77
post #61

Earlier quoted context omitted.

> They have experience with their problem solving style, they don't have experience with every problem solving style, or even necessarily with my problem solving style. You can't infer much from that, and certainly not that typing is "not great when prototyping". I tend to grant the first person who states their opinion in absolutes the nicety of automatic insertion of "it is my opinion/experience that," because this…

> Is in inconceivable that a programmer can check their types manually, using an ad hoc intuitive type system? Sure, if you don't mind an ad-hoc, informally specified, bug-ridden, slow implementation of half of a type checker that no one but you knows (and so is "intuitive" only to you... until you read this same code 3 months later).

What are you addressing? My position is that automatic type checkers are nice to have but not essential, and it is possible to prototype software without one. I am not arguing against their use, just what seemed to be your assertion that it is impossible to prototype/develop software without an automatic type checker. Anyway, I understand the pitfalls of not using one, but I also understand how type systems tend not to capture everything. There is no reason to be dogmatic about it: use whatever works as a tool for thought.

As I said before, "intuitive" is in the sense of intuitionism; not "easy to understand" or "obvious." A point of view: formal type systems comes from explaining what we see with mental perception (intuition). What do you do if your automatic type checker doesn't check every possible thing you want to verify is correct? Surely you aren't just blind to the types they "should" be. Seeing the invariants which must hold is seeing the intuitive type.

> if you don't mind an ad-hoc, informally specified, bug-ridden, slow implementation of half of a type checker that no one but you knows

I can't tell if I was understood or if you just wanted to quote Greenspun's tenth rule whether it completely worked or not: I was talking about a programmer with a type theory, not implementing an automatic type checker from scratch.

Re: Why Type Systems Matter

#78

Earlier quoted context omitted.

While I agree that type systems often get in the way, and that the author is only pointing out bad points and not good ones, aren't you doing the same? At least the author is trying to back up their claims (e.g. they provide an example where someone decided to put sizes in strings). The honeymoon part is also an unfair assumption, not to mention incorrect. I just clicked on "About me", clicked on the author's github…

Because my comment was not about type systems, it was about the fervor and lack of usefulness of the post itself. Plus, I'd just be repeating myself and others much more eloquent than I - why do that? Plus, arguments about typed languages rank up there with vi vs Emacs (or is it now vi/emacs vs. Atom/VSC?) in terms of my interest in joining them. I like statically typed languages. I like dynamically typed languages.…

You may be entirely correct, but the way you have presented your position looks extremely unconvincing.

What I can see: You chime in on a discussion with a strongly critical viewpoint, then refuse to back it up saying you don't want to be part of certain kinds of arguments. Implying religious level flamewars, while the rest of us are keeping a level head and discussing these things based on technical merit. It looks like you are making excuses because it looks like you have no point. Even if that wasn't what you intended and you have strong points, that isn't what it looks like from the outside.

Please remember that not everyone has exactly your experience so if you have examples you should share them because they will make your points stronger even if someone attempts to rebut them. It also artificially weakens your point to try to back out with what from the outside look like excuses instead of substance. Again, I must say you might be entirely correct, I just can't see that from here.

Re: Why Type Systems Matter

#79

Earlier quoted context omitted.

While I agree that type systems often get in the way, and that the author is only pointing out bad points and not good ones, aren't you doing the same? At least the author is trying to back up their claims (e.g. they provide an example where someone decided to put sizes in strings). The honeymoon part is also an unfair assumption, not to mention incorrect. I just clicked on "About me", clicked on the author's github…

Because my comment was not about type systems, it was about the fervor and lack of usefulness of the post itself. Plus, I'd just be repeating myself and others much more eloquent than I - why do that? Plus, arguments about typed languages rank up there with vi vs Emacs (or is it now vi/emacs vs. Atom/VSC?) in terms of my interest in joining them. I like statically typed languages. I like dynamically typed languages.…

[deleted]

Re: Why Type Systems Matter

#80
post #73

Earlier quoted context omitted.

The left hand side only reserves the memory, the right hand side actually initializes the object. A bit redundant I agree, but to the compiler it is two atomic operations.

It is two separate operations, but in many other languages the compiler is smart enough to figure out that they'll be the same type (and allow you to specify it when they're not) That's what I mean—Java's type system is verbose and clumsy, because it doesn't bother trying to figure out things it could figure out, forcing the programmer to be redundant and repeat themselves all over the place. The fact that it's 2 sep…

I agree it could be more clean, but the way it is designed allows for immediately understandable semantics when dealing with inherited types (which everyone though was the future during Java's Formative years).

This makes operations like this intuitive:

    Animal results = new Dog("Lassie");
Post reply on HN