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

391–400 of 468 posts

Re: Things I Was Wrong About: Types

#391

Post by loup-vaillant »

nonbirithm wrote: post #317
pansa2 wrote: post #170

Earlier quoted context omitted.

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

When moving from a dynamically typed language to a statically typed one, about the only thing I end up missing is hot reloading. In gamedev, static types don't help when you have a constant value you have to change that tweaks the gameplay buried inside a compiled class that you want to balance out. Changing that one constant means either putting it in a script, which is usually written in a dynamically typed languag…

Hot code reloading and static typing are not incompatible.

On a trivial level, C and C++ can unload & reload DLLs at runtime. On a less trivial level, I believe the Yi editor, written in Haskell, can do hot code reloading. On a practical level, I use the XMonad window manager, whose configuration involves modifying a Haskell source file (the main one, actually), and hitting some shortcut. If my modifications are correct, the whole things reloads without loosing any state (my windows are still at the same places).

Re: Things I Was Wrong About: Types

#392

Post by koyote »

piedar wrote: post #228
tasogare wrote: post #198

Earlier quoted context omitted.

This is why interfaces exist.

Nominally-typed interfaces are still clumsy in some circumstances. For example, if I consume a library with namespace ThirdParty { public sealed class Foo { public void Do() { } } } and I want to hide it behind namespace MyCode { interface IFoo { void Do(); } } the compiler does not accept ThirdParty.Foo as an implementation of MyCode.IFoo so I must define a wrapper namespace MyCode { sealed class ThirdPartyFooAdapte…

While I agree, I feel that third-party library consumption is a bit of an edge case (i.e. the majority of your interface implementations won't be wrappers around third-party stuff).

Whenever I do work closely with a third-party library, the wrapping pays for itself quite quickly because it never takes long for you to find a 'quirkiness' or unsuitability in how the library implements something and you end up with code resembling this:

   public void Do() {
     _instance.SpecialOptionForTheBehaviourYouRequire = true;

     try
     {
       _instance.Do();
     }
     catch
     {
       // Workaround for bug that has not been fixed in ThirdParty Library yet. Remove when fixed!
       _instance.ResetBrokenStateCausedByBug();
       _instance.Do();
     }
   }

Re: Things I Was Wrong About: Types

#393

Post by jeanl »

One good reason for not caring about types: prototype code. I do a lot of prototyping (trying ideas quickly, not for production). I typically do that in python. In that case, I don't think types would be helping me at all, I can get run-time errors, but I don't really mind, it's an easy fix. I used to have to prototype in C++, definitely not the type of language that's fit for that (if only because it's compiled). Prototyping is best done with an interpreted, untyped language in my humble opinion...

Re: Things I Was Wrong About: Types

#394

Post by jakear »

zo1 wrote: post #374
scubbo wrote: post #326

Earlier quoted context omitted.

This is absolutely it. Untyped languages are great for glue-scripts, for exploration (of an API, a dataset, whatever), for quick-and-dirty things. As soon as your logic grows beyond "what can be appropriately expressed in <5 files" and/or "this is going to have a second developer", types become helpful.

I see it completely the other way around coming from the python, dynamically-typed side. For me, statically-typed languages have a benefit on the smaller-side of the scale, but absolutely bomb when the code-base grows. At that point everything is a FooFactory or an IInterface with no help from the IDE anyways because of IOC/DI/attribute reflection magic. And when it's that big, everyone argues over folder, package an…

The second you’ve “engineered” yourself into losing good IDE support half the benefit or using a strongly typed language goes out the window in my opinion. Though maybe some bias because I make an IDE! :)

Happily with TS it’s possible to have DI and IInstantiationService’s and all that and still maintain good IDE support —- in no small part because the IDE is built with all those, in TS... if it was unusable we’d fix it.

Re: Things I Was Wrong About: Types

#395

Post by cle »

throwaway894345 wrote: post #353
cle wrote: post #348

Earlier quoted context omitted.

There’s a continuum for sure. Type systems have their own kind of cognitive load, because you have to learn them, how to model your invariants in them, how to understand error messages, avoid common pitfalls, etc. Type systems are usually quite “general” and abstract, and that always comes with cognitive load. Quite often reading the code of a parametrically-polymorphic Python function is way easier than understandin…

For the most part this cognitive load already exists in order to write correct programs. Types don’t just appear when a type checker is present. Type systems only add on the additional burden of needing to understand the formalization of that intuition. It’s not an insignificant burden, but it’s a much smaller gap than learning to intuit about programming correctly in the first place.

It depends on what you mean by "correct". If it means "it does what I need it to do and I can move on with my life", then no, the cognitive load doesn't already exist, and formalized type theory in many cases adds an incredible amount of cognitive load.

I know that in many cases "correct" means a lot more than that, such as in proper software engineering contexts when building a program/system that needs to live and evolve for a long time among many people. I write that kind of software all the time, and I always use static type systems for it.

But I also write a bunch of ad-hoc, one-time-use programs, and I'm very glad that I don't need to reason about abstract type theory in order to parse a CSV file and add up some columns to send to a colleague.

Re: Things I Was Wrong About: Types

#396

Post by cle »

pvorb wrote: post #351
cle wrote: post #348

Earlier quoted context omitted.

There’s a continuum for sure. Type systems have their own kind of cognitive load, because you have to learn them, how to model your invariants in them, how to understand error messages, avoid common pitfalls, etc. Type systems are usually quite “general” and abstract, and that always comes with cognitive load. Quite often reading the code of a parametrically-polymorphic Python function is way easier than understandin…

I don't buy this "choose the right tool for the job" thing. I'd always advise you to choose the tool that your company has the most knowledge in. If there's a problem that cannot be solved in that programming language, then you can look for a better tool. But you shouldn't pick a language that nobody else understands, just to save a few lines or some time when doing the initial implementation - just to realize that y…

I consider that one of the most important criteria when picking the right tool for the job (if you're writing something to be maintained by other people in a company).

Re: Things I Was Wrong About: Types

#397

Post by _4jlx »

Comparing languages with types to languages without types is like comparing conservatism to liberalism. Less rules = more change. How much of your newfound liking for typescript can be attributed to 'realizing' it's better and how much of it is simply because you're getting older?

Re: Things I Was Wrong About: Types

#398

Post by mumblemumble »

MiroF wrote: post #338
5n wrote: post #327

Earlier quoted context omitted.

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.

We must work very differently. I couldn't fathom that happening to me, if only because I compulsively peek at samples of the data frame every step of the way, in order to make sure the data look reasonable all the way through.

Re: Things I Was Wrong About: Types

#399

Post by throwaway894345 »

cle wrote: post #395
throwaway894345 wrote: post #353

Earlier quoted context omitted.

For the most part this cognitive load already exists in order to write correct programs. Types don’t just appear when a type checker is present. Type systems only add on the additional burden of needing to understand the formalization of that intuition. It’s not an insignificant burden, but it’s a much smaller gap than learning to intuit about programming correctly in the first place.

It depends on what you mean by "correct". If it means "it does what I need it to do and I can move on with my life", then no, the cognitive load doesn't already exist, and formalized type theory in many cases adds an incredible amount of cognitive load. I know that in many cases "correct" means a lot more than that, such as in proper software engineering contexts when building a program/system that needs to live and…

No one is talking about abstract type theory; we’re talking about the intuition you use to write maintainable, correct software including CSV munging.

Re: Things I Was Wrong About: Types

#400

Post by a1369209993 »

eru wrote: post #128
echelon wrote: post #3

I followed a similar trajectory. Types were the bane of my early career. Hideous, extraneous. But really, they're the light at the end of the tunnel once you've worked your way though the dynamic / weak typing minefield. It took me a lot of Python, Javascript, and Ruby for me to get there, but now I'm way more comfortable on the other side. The correct type system is actually way more expressive than not having stron…

Sum types even work when you actually have the multiple of the same return types. (Ie in Haskell `Either String String` works just as well as `Either String Int`; the types don't have to be distinctive.)

Also, `Maybe (Maybe a)` works correctly, contra possibly-null values in dynamically-typed languages. It's a surprisingly significant issue given how seemingly trivial it can sound.
Post reply on HN