Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

411–420 of 468 posts

Re: Things I Was Wrong About: Types

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

As helpful a static type system can be, most of them do cause increased cognitive load UNTIL the FIRST RUNNABLE VERSION. Having your code running for the first time is rewarding for devs, especially those who are handling many simple codebases rather than few complex ones.

There are great type system that provide enough ramp for for first runnable version. Rust, for example, has type inference and an unusually helpful compiler.

But most languages, especially the old ones, don't have that. Because of that, coders need full-blown IDEs like Intellij/VS to write comfortably in those languages. Without full-blown IDEs or editors packed with plugins, it is quite a chore to navigate types. There's no hyperclicking, type annotation, docs preview. While dynamic-typed languages usually is runnable since the first character without having to wait for the compilation, so even notepad is acceptable to write with (though that would be really painful).

Having been in both sides, I love types in certain languages (and disdain them in others e.g. PHP). I would still pay the price of compilation and use TypeScript for scripts that lives long rather than using JavaScript. But I think both sides need to understand where the cognitive load arguments came from.

Re: Things I Was Wrong About: Types

#412

Earlier quoted context omitted.

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)

(It turned out to be a productive comment despite the aggressive wording, so upvotes!)

Re: Things I Was Wrong About: Types

#413

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/

Concurrency instead of queuing between microservices

Re: Things I Was Wrong About: Types

#414
Great article. Chris’s rust podcast often sounds like this article reads and worth the time.

I happen to be a Python guy. I don’t get to program every day anymore, and python is about all my brain has room for now. However, I’d love to have optional types and am envious of the Typescript crowd. I wish they would have based it on Python instead. Oh well, one can hope. Maybe one day we’ll have something like it.

Re: Things I Was Wrong About: Types

#415
post #293

Earlier quoted context omitted.

> 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. I agree. It's not unlike what you can do with reflections and other dynamic features of dynamicaly-typed languages. So it's not a problem of static typing itself. It's a…

> “ IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).” That’s fair, since most of the issues are caused by poor attempts to create “concepts” that match a problem domain and encode them in the type system, which is a very OO mentality. But it’s not exclusive to OO, you can get the same problems in functional language…

Interesting. Seems we have very opposite experiences.

I definitely agree that one can paint themselves into a static-typing corner where refactoring becomes painful (but as I said, usually because of OOP). Also in big projects care needs to be taken to keep compilation times manageable.

> Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programmer has freedom to make these choices.

Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high.

I am supporter of gradual typing though, if someone wants to go with dynamic typing route.

Re: Things I Was Wrong About: Types

#416

Types are controversial because we can't measure engineer productivity. Full stop. I see people on here arguing that they are faster one way or the other, yet we have absolutely no empirical evidence for such a claim. What makes it more complex is that "fighting with types" often takes one out of the flow in a different way than usual progamming challenges. Since it's unmeasurable, we cannot see the effect of product…

Exactly. There is a lot of post-hoc rationalisation happening, along the lines of:

> I like language/technology X. Why? Well I'm obviously a super smart and rational person, so my preferences could only be based on facts and logic. Therefore everything I like must be objectively correct. QED.

Anecdotally, the more someone prides themselves on being intelligent and logical, the less skeptical they are of their unsubstantiated emotional judgements.

Despite primarily working in dynlangs, I would guess that type systems affect developer productivity somewhere in the range of +-50%. While I have pulled that number directly from my ass, I think that if the effect size was larger then there wouldn't be much of a debate. If a company could swap languages for any given team and get 3x more functionality, or get the same work done for 1/3rd of the cost, we would know about it already. And to be clear, 3x productivity is achievable, but not by simply switching to Haskell.

Re: Things I Was Wrong About: Types

#417

Earlier quoted context omitted.

> IMHO, type-less provides some resiliency. If you write code for a "string" anything that satisfies "stringiness" will still run just fine. Things like that are actually possible to do in a light weight way in FP languages and many of them are part of the stdlib. (PureScript happens to be my favorite example.) Many times it brings back the same feelings I had working in Ruby (which I also happen to love), but with t…

Scala is the closest I've gotten to FP at work. I'd love to play with Haskell/F#/etc in a professional setting, it just hasn't come up. Yet.

Haskell family languages are something unique. I’ve never worked with Scala so I can’t say.

Re: Things I Was Wrong About: Types

#418

Earlier quoted context omitted.

Java's stance is flat wrong as a matter of practice. I don't believe I've once had the compiler infer a wrong type in a way that led to runtime bugs. If it did, we would all be rightfully annoyed with that compiler because it would be broken. Once more, for the back of the room: Java does not count as an example of a worthwhile type system. Good types do not increase verbosity.

I can see you disagree on a matter of principle and personal experience. And that's alright. I just think it's as valid an opinion as all the others. There are some who like explicitly defined types of various levels. Those who want it all infered or partially infered, and those who don't want them at all, or want them optional or gradual, etc. And none has been able to make a claim over the others even now years lat…

Any language that supports type inference will also support annotations if your taste/linter/boss demands it. That's fine. But hobbling the compiler by not including type inference at all, because you think it causes bugs, is quite definitely stupid. I literally don't understand how anyone could dispute this except by inexperience with type inference.

Based on the sentence with the tangent about "optional or gradual" etc, I suspect you are conflating two debates. Of course there is debate on to what degree static type systems are helpful. That is quite separate from the debating whether to include the very convenient and theoretically rock-solid feature of type inference. I have hardly heard anyone discuss this, much less attempt to gather empirical data.

Returning to the original point, there is no conflict between static typing and concision, except in C++/Java style type systems. I especially don't understand how a "static type checker enthusiast" would think there is, but if you meet one tell them Someone On The Internet told them to learn OCaml already.

Re: Things I Was Wrong About: Types

#419

Earlier quoted context omitted.

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

Also, many beginner programmers work on small code bases in every sense of the word. These days I will often have to glue together some tiny part of two or three enormous APIs, some of which are "auto generated" from some other system. Think LINQ-to-SQL or WCF. It's amazing when you can take a 100 MB chunk of code, and simply "navigate" to the thing that you want using tab-complete, in the sense that "somefactory.som…

> If you're working with a "blank slate" PHP app (or whatever), where you've personally written most of the lines of code involved, typing can feel unnecessary.

> If you're glueing together Enterprise Bean Factory Proxies all day, then strong typing is practically mandatory.

Might that not be a problem, though? Shouldn't more software systems be small, elegant and well-architected rather than a spaghetti nightmare navigable only through an IDE?

I like types, I think they are great, I like editor tool, I think it is great. I even like a lot of the luxuries modern systems afford me. But … maybe we could stand a little simplification?

Re: Things I Was Wrong About: Types

#420
post #402

Earlier quoted context omitted.

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

I don’t care if my throw away CSV munger is formally safe/sound or maintainable. I care if it gives me correct results , once, as quickly and effortlessly as possible. Which is why very few people fire up GHCi/rustic/javac for that, but instead use awk/shell/Python or something similar.

OTOH, sometimes the CSV munger one writes today is still in use five years later, when the input CSV has a UTF-8 character for the first time, and suddenly it crashes and no-one knows where the bug could even be.
Post reply on HN