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

191–200 of 468 posts

Re: Things I Was Wrong About: Types

#191

Post by dpc_pw »

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.

Re: Things I Was Wrong About: Types

#192

Post by loup-vaillant »

chrisoverzero wrote: post #105
stult wrote: post #103

Earlier quoted context omitted.

It seems pretty evident to me that most successful and popular dynamically and statically typed languages are converging from different directions on a similar set of solutions. Very much reflecting the phenomenon you describe. Some simple examples: C# has moved from very strong typing of the exact sort OP criticizes (`Person person = new Person();`) to increasingly permitting looser/more expressive typing with `var`…

>[…] 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 common with the old type, you may not change the code at all. It's just as strict as explicit typing, but it's arguably more flexible, and thus feels looser.

Re: Things I Was Wrong About: Types

#193

Post by wutbrodo »

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…

> Plus, dynamically typed languages had these rich features that just weren't really accessible in mainstream statically typed languages, and so they kind of became associated with each other in my brain even if that wasn't specifically true.

This resonates a lot with me (though as you say, isn't really a typing thing). I work on ML systems for autonomous vehicles, so I switch between Python and C++, and I definitely occasionally start writing some C++ logic in an elegant functional way and realize that C++'s boilerplate makes it less readable than the usually-less-readable naive construct like a loop (eg I'm surprised at how often std::transform comes out looking terrible).

Do you mind if I ask about the size of the systems/teams you've worked on throughout this process? My experience with C++ has been in large systems worked on asynchronously by lots of engineers (with strong code review policies in place), and my experience with Python has been everything from moderately-sized systems down to smaller ones down to scripting. The Python case also included work with an inexperienced (and frankly, partially unintelligent) team of engineers, which made the discipline imposed by typing all the more valuable, but I have found the documentation and structure that typing imposes on code to be invaluable in communicating

As I said in my other comment, I'm still concerned this is a little facile, but having started my career on C++ systems at Google, I wonder whether I've just set a standard so high for the health of a system that many of those who dismiss typing's value don't understand that those benefits are possible (I'm certainly an order of magnitude better at reading code than anyone my current team, but this is confounded by the fact that everyone else has a weaker engineering background and stronger robotics or ML domain expertise).

To be clear, I don't think this applies to you necessarily; your approach of trading off the benefits of ergonomics vs structure resonates strongly with me, and I'd imagine it's even more the case on pre-modern statically-typed languages. What I'm really curious about is the perspective expressed in the OP, which, in the 2010s, doesn't even see _value_ in types beyond perhaps negligible benefit from some compiler checks.

Thank you very much for the perspective!

Re: Things I Was Wrong About: Types

#194

Post by kobe_bryant »

I'm working on a system where the users supply equations as rules and in a roundabout way we came across static vs dynamic typing.

having users have to define each equation and its type (boolean, numerical, etc) would make it simple and foolproof, but add extra work and requires defining each equation separately when a lot of them are just partitioning the space (imagine 30 combinations of x, y and z) so we ended up deriving the type from how its result is being used, but that puts the work of getting it right on the user

Re: Things I Was Wrong About: Types

#195

Post by rogerkirkness »

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.

Re: Things I Was Wrong About: Types

#196

Post by valuearb »

jondubois wrote: post #75
dynamite-ready wrote: post #27

Types are useful, but they are currently trending, so now, they might often be forced into situations where they might not be needed. Programming languages and their type systems are tools, at the end of the day. Occasionally, an overwrought system of types will slow you down, or quite possibly make simple changes impossible. On another day, some other type declaration could save you hours of debugging, or speed up y…

Type hype is real. It almost seems like job-creation propaganda at this stage. When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team. With JS, I can write more code and mor…

I switched my Javascript code base to Typescript a few months ago. There is a productivity cost that is declining over time as I get more used to Typescript. But the conversion also flushed out some significant bugs in the JavaScript base.

And I only get to work on this code once a week. So when I come back to it I’ve found it’s much clearer how it works and I get productive much faster.

I will bet any coworkers who have to work on your code wish it was in Typescript.

Re: Things I Was Wrong About: Types

#197

Post by withinboredom »

loup-vaillant wrote: post #184
musingsole wrote: post #165

Earlier quoted context omitted.

Those who argue strongly for one method over the other are likely to not understand the one they're against. Which sucks, because if you do know both, there's rarely a reason to have strong feelings one way or another. So, once again the naive but vocal voices get all the decision power. /Too many arguments at work are over dogma and I have to spend a lot of my time reminding people that there are options. That's all…

I was never sure what to think of dynamic typing, until I tried to implement a fairly simple Earley parsing algorithm in Lua. The thing was 50 lines, and I was lost . I only managed to get runtime errors such as "you can't add functions, you can't apply a number, this reference is null… That's when I understood where TDD came from: dynamically typed languages require so many tests to work reliably that we better writ…

> The thing was 50 lines, and I was lost.

The key to writing type-less code is making it so simple that you could cry. Avoid being clever at all costs. However, it's almost the exact opposite when you have a nice compiler checking everything, you can be mighty clever and know that it will work.

I'm lucky in that we can solve a problem in a myriad of languages, depending on if it needs to be "realtime", or can be precomputed. There are some types of problems I'd rather solve in Scala, and others, Python or PHP. It just depends.

Re: Things I Was Wrong About: Types

#198

Post by tasogare »

hn_throwaway_99 wrote: post #169

I'll add a 4th thing to his list based on my experience moving from Java to Typescript: Nominally -based type systems like Java (where you can only write Foo f = new Bar() if Bar has Foo somewhere up it's static type chain or interface hierarchy) are way more of a pain in the ass than structurally -based type systems like TypeScript (where you can say f: Foo = new Bar() as long as TypeScript determines Bar has all th…

This is why interfaces exist.

Re: Things I Was Wrong About: Types

#199

Post by bo1024 »

skohan wrote: post #187
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…

> Understanding other people's code is at least half the job of a programmer This was one of the pain-points when I was working more with node.js: the function signature told you nothing - like whether the function would even return or not would sometimes be a mystery. In very, very short scripts you can get away without types (like in a notebook for example), but once a project starts to get even medium size the tin…

This kills me about python. So many times I cannot figure out what exactly a functions expects and what it returns, sometimes even from reading the documentation! Matplotlib is especially bad.

Re: Things I Was Wrong About: Types

#200

Post by loup-vaillant »

pansa2 wrote: post #170
williamdclt wrote: post #111

Earlier quoted context omitted.

> I found that static typing actually speeds up my development. It's less work, not more. It's a point that comes back often, and that I totally agree with so it's worth reiterating. In addition to the improved dev tooling (autocompletion, hinting, refactoring), being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a hu…

> being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a huge load off my mind. I've heard similar things before, e.g. "static typing allows you to find bugs in your code without even running it". Perhaps the reason I'm a fan of dynamically-typed languages is that I don't see the benefit of this. Maybe my workflow is u…

OCaml has a REPL. I use it all the time to check that a new function I just wrote is correct. Yet I still get huge benefits from the static typing: many of my errors are stupid type errors, and having the type checker tell me about them, rather than a runtime error (or worse, a wrong result), makes early prototyping much faster.

Even if I already have a REPL. I believe the main reason is because the type checker is much closer to the source of my errors than runtime checks or tests are.

Post reply on HN