Things I Was Wrong About: Types • Hacker News Board

Re: Things I Was Wrong About: Types

#331

Post by alkonaut » Sun, Sep 27, 2020, 8:15 PM UTC

chrismeller wrote: post #186

pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

I went a similar path, PHP to C#, and never looked back. When I had to switch to Node for one job I was pulling my hair out constantly (and quite literally) because of stupid things that would never have happened in what I called a “real” language (that being a typed, compiled one). I mean for $deity’s sake, there weren’t even any dependency injection options at the time and many many times it turned out a bug I intr…

Node isn't so bad now with typescript. The JS folks learned from endless fixing hot mess code that you couldn't really do with anything less than a good dev experience (Imagine a 5 minute turnaround from edit to test on JS to find a typo in a variable). With TS you get all the nice dev experience from JS, but also some of the C# niceness.

Re: Things I Was Wrong About: Types

#332

Post by gfodor » Sun, Sep 27, 2020, 8:16 PM UTC

I’m one of those programmers who doesn’t care about types. Am I coding in a dynamic language without compile type type checking? Great, I lean into it, hand me vim and a good testing framework. Putting me into a big Java codebase? OK, time to run IntelliJ and use automated refactoring to change the code. The type system dictates the style and trade offs so it’s just one more dimension that informs how you deal with the code and write new code.

I’m more worried about what I’m working on and why.

Re: Things I Was Wrong About: Types

#333

Post by inetknght » Sun, Sep 27, 2020, 8:19 PM UTC

loup-vaillant wrote: post #192

chrisoverzero wrote: post #105

Earlier quoted context omitted.

>[…] increasingly permitting looser/more expressive typing with `var`, anonymous types, pattern matching, etc. None of these features are related to loosening the type system.

It can still feel that way. Take C++ for instance: Foo f = fooFromElsewhere; // explicit typing (old) auto f = fooFromElsewhere; // type inference (new) Now what happens if we change the type of `fooFromElsewhere` from `Foo` to `Bar`? With the old way, we need to change the code to: Bar f = fooFromElsewhere; With type inference however, you won't need to change that line at all. And if the new type has enough in comm…

In cases where Foo and Bar are stricly incompatible, auto is fine here. In cases where Foo and Bar are similar and might cause trouble, auto shouldn't be used here.

Re: Things I Was Wrong About: Types

#334

Post by christophilus » Sun, Sep 27, 2020, 8:29 PM UTC

rogerkirkness wrote: post #195

Rewriting our app from Node to Go reduced cloud spend by 20x, did not increase dev time, made it much easier to read and grow the project past 5k lines. Literally no downside. If your database is typed on the bottom, and your documentation is typed on the top, you have a type sandwich in every non-script application. Might as well be consistent.

20x seems high. Node is within 3x of Go in most benchmarks I've seen like TechEmpower[0]. I'm curious how you got a 20x improvement?

[0] https://www.techempower.com/benchmarks/

Re: Things I Was Wrong About: Types

#335

Post by billisonline » Sun, Sep 27, 2020, 8:31 PM UTC

ysavir wrote: post #225

billisonline wrote: post #212

Earlier quoted context omitted.

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be wr…

> Should it be expected that all programmers use these text editors and have access to these tools?

If they don't have access, then the tools ought to be standardized to the point where they can be integrated into any editor. The Language Server Protocol[1] seems like a step toward this.

> I'm of the opinion that code should be written independent of the tools used to understand and modify that code.

This a widespread, "common sense" opinion that I've come to disagree with strongly. No one would argue that, e.g., illustrators, 3D modelers, music producers, etc. should be so tool-agnostic—and yet their situation is quite similar. One could produce a complex piece of music in Audacity instead of using Logic or Ableton, but musicians don't have the same mentality of picking the cheapest, most austere, or lowest-common-denominator tool. Instead, they invest in tools that enhance their productivity. And that's precisely what's at stake here. Pairing (a) a language that allows implicit "smart" features like type inference with (b) an equally smart editor to make what is implicit in the code explicit to the developer as needed, is more productive than forcing the developer to make everything explicit themselves.

Re: using VIM over ssh, your choice of scenario is revealing. Why would you limit your everyday development work based on the lowest common denominator tool you're forced to use in an emergency? Also, it's not necessary to run code inspection on the remote box. JetBrains IDEs, for example, will copy a folder from ssh or a similar environment, index and inspect them locally, and then sync them back as needed.

1: https://microsoft.github.io/language-server-protocol/

Re: Things I Was Wrong About: Types

#336

Post by alkonaut » Sun, Sep 27, 2020, 8:33 PM UTC

jenscow wrote: post #125

aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

Personally, I prefer the type names to be at the start of the line, so I don't need to scan to the end of the line (or guess based on a function name). But I agree, it's a waste to type it all out. So I use an intelligent IDE that reduces the repetitive typing: So typing `Person.var` gives me `Person person = new Person();` or typing `Person person = ` will suggest `new Person()` Sure, it doesn't look as appealing wh…

If the type isn't obvious, I want the former rather than the latter.

The newest C# has the reversed inference for ctors too, so you can actually do this and not have to repeat it and still get it first.

    Person p = new();

Re: Things I Was Wrong About: Types

#337

Post by cannabis_sam » Sun, Sep 27, 2020, 8:34 PM UTC

cannabis_sam wrote: post #277

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

(Sorry for being a bit too aggressively argumentative in this comment)

Re: Things I Was Wrong About: Types

#338

Post by MiroF » Sun, Sep 27, 2020, 8:37 PM UTC

5n wrote: post #327

mumblemumble wrote: post #314

Earlier quoted context omitted.

Here's my split personality: I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are. I hate hate hate Python for ML engineering, in part because it's dynamical…

IMO dataframes are the reason why dynamic typing fits data science so well. It's certainly possible to represent a single dataframe as a static type; but representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks. So bypassing types for data frames is preferable. On your ML engineering point, the other side of it is that once your dataframe's schema is finalizes it real…

> representing all the slicing, column removal, joins, etc. is actually pretty hard without dependent tricks

Disagree in the strongest possible terms, tbh.

It's the lack of static typing that gets you 3/4 of the way down your experimental pipeline only for your code to fail because column "trianing_batch" can't be found. Huge productivity loss, even with rapid iteration.

Re: Things I Was Wrong About: Types

#339

Post by erik_seaberg » Sun, Sep 27, 2020, 8:38 PM UTC

steveklabnik wrote: post #134

wutbrodo wrote: post #129

I which there was a little more elaboration on _why_ he originally disliked types so much. This perspective is still very strange to me, as the value of types seems self-evident for systems more complex than a script, and I'd like to understand it better. As it stands now, my only assumption is that this comes from the place the author is coming from: people who don't think types are useful are generally coming from…

I can't speak for Chris, but I can speak for myself. I did the bulk of my early programming in statically typed languages. Specifically, late 90s C, C++, and Java. Then I found Perl, and pretty much went into dynamically typed languages only for the next near-decade. At the time, I felt like the types didn't pull their weight. There was a lot of extra writing, and you got very little benefit for it. Plus, dynamically…

Oh yeah, types need to express everything people actually want to do or they become a straitjacket. In the late 1990s we had to find cumbersome workarounds for seemingly-valid templates that would crash Borland C++. Today Java’s type system is … not great, but it was a lot worse before generics in 2004.

Re: Things I Was Wrong About: Types

#340

Post by cuddlybacon » Sun, Sep 27, 2020, 8:42 PM UTC

cannabis_sam wrote: post #277

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

I think there are a few reasons why people develop an impression that types are overhead:

* People who are learning to code are writing lots of code but not reading very much code. I think types do the most work when trying to understand existing code.

* Lots of people's first experience with typed languages was something like C++ or Java back when they had much worse error messages.

* The kind of mistakes you make when first learning to code make the type checker feel like a pedantic nitpicker instead of a protective ally.

* Programming instruction tends not to teach technique very much. If you invent techniques that leverage the strengths of types, then great for you. If you don't, then you might program for years until you are exposed to the benefits types can provide.