Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

401–410 of 468 posts

Re: Things I Was Wrong About: Types

#401

Earlier quoted context omitted.

Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have…

You're showing an example of a function signature in a specific language, not an example of typing though. These are related but not exactly the same. For example here is a Ruby version, very dynamic: def request(method, url, **options) end request("get", "http...", foo: "bar") And here is a completely statically typed Crystal version: def request(method, url, **options) end request("get", "http...", foo: "bar") The…

Nitpick: It's -> Dict[...]. Colons begin a function body.

Re: Things I Was Wrong About: Types

#402
post #395

Earlier quoted context omitted.

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.

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.

Re: Things I Was Wrong About: Types

#403

Earlier quoted context omitted.

Anti-intellectualism in programming is fascinating to me. The variance in skill between individual programmers is immense, and languages act as force multipliers on that. There are huge opportunities that emerge from pushing yourself to explore new paradigms and domains.

> There are huge opportunities that emerge from pushing yourself to explore new paradigms and domains. What are those opportunities? As a Rubyist, to me it makes more sense to become really good in Ruby. As I get older and more expensive, I need to be better than the 3 year experience 26 year old colleague. And if not better at least not noticeably worse. Learning Elixir, Go, Haskell or you name it isn't gonna help m…

> As a Rubyist

Are you a Rubyist, or a developer?

> As I get older and more expensive, I need to be better than the 3 year experience 26 year old colleague. And if not better at least not noticeably worse.

Yeah, I had this line of thinking. I don't recommend it. I eventually realized I don't want to play the same game as people who are willing to throw away more than I am. Specifically, I don't want to be in positions that companies would be asking those types of questions. Younger devs will work longer, not have families, work for cheaper, and be more compliant.

So I decided I'd focus my career in the following way: no more web dev. I chose compilers and systems programming to self-study. It's been fantastic. Along the way, I learned Haskell and Rust, contributing a bit to both communities, and having a lot of fun. Eventually, I started finding my way towards seeing more jobs that were in my wheelhouse, and landing some.

> there are so many other worthy things a person can do with his time other than learning a new programming language (both within programming and outside programming), we shouldn't judge people by their passion or lack of passion for learning new languages.

Agree. But if you want to pivot your career, don't wait for your employer to sponsor you in doing so.

Re: Things I Was Wrong About: Types

#404
post #323

Earlier quoted context omitted.

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…

This doesn't conform with any of my experiences in non-trivial JS codebases. Migrating to TS tends to reveal previously overlooked implicit typing issues. Also, I find the "upfront productivity loss" of TS to be overstated: adding in annotations here and there doesn't take much time at all, and pays dividends quickly. Many hours have been lost tracking down some elusive runtime bug stemming from a typo in a vanilla J…

In my career (which spans 15 years at over a dozen companies), I've built many complex front ends, complex backends with different database systems, a popular open source pub/sub server which auto-scales on Kubernetes across a cluster of machines, a P2P networking library with selective message routing/propagation (in a scalable partial mesh configuration), a scalable chat system, a decentralized cryptocurrency exchange (federated 2-way peg), a modular multi-process blockchain framework (which scales both horizontally and vertically) and many other complex projects; all of these written with plain JavaScript/Node.js, in record time and essentially bug-free (no major bugs reported so far on any of my projects since they were shipped). So I'm quite confident when I say that there is nothing wrong with JavaScript and dynamic typing.

I've programmed in many different languages too; ActionScript, Delphi, C/C++, Java, Python, PHP, C#, AVR Assembly (ATMEGA8-16PU microcontroller)... I've also programmed a JavaScript UI front end for a TV set top box which had a custom JS engine.

From my perspective, many among the TypeScript crowd are arrogant junior developers who regurgitate what they were taught by a bunch of academic bureaucrats who never actually built a single fully working system in their lives but who believe that their PhD qualifies them to tell everyone else about the many theoretical (but in fact, imaginary) benefits of functional programming and static typing... Benefits that not a single human soul has actually experienced themselves on a real large complex project.

I've seen real-world complex FP projects; in all cases, the code was spaghetti; it's almost impossible to follow the logic because it jumps around too many modules and files; because all the state is kept in a single centralized place, instances end up getting passed around all over the place; traversing many intermediate modules to reach the target module; buried deep in the code... And there is no clear separation of concerns; it's hard to separate concerns when you fully decouple state from logic.

Re: Things I Was Wrong About: Types

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

The reason people argue for being able to write and run code quickly is it helps with prototyping and iterating on a concept. For a lot of people, overly verbose typed languages kill that creative cycle. Type systems are great for data validation and self documenting code when you need those things but they essentially double the work when you’re first getting something off the ground.

Re: Things I Was Wrong About: Types

#406
I'm having the distinct impression that the top comments in this discussion didn't read the article all the way through.

This is the article's conclusion:

> And, critically, this taught me to be far less dogmatic about the value of ideas in programming languages and software development in general

And yet all the top comments are completely, absolutely dogmatic (or at the very least, far more strongly worded than they merit; presented as fact when they're anything but) repetitions of "arguments" said over an over in that sixty-year-old flamewar. A flamewar that has no ending in sight and probably has no ending possible.

There have been studies made trying to answer this particular question: whether static or dynamic typing ensure more or fewer errors. Not only have those studies always been inconclusive, in one case the discussion among the researchers themselves ended up turning into a flamewar.

As for me, I'm just as happy working with Python or with Typescript, or with Kotlin or Clojure; somewhat less so with Go or Ruby; and I'm absolutely miserable when working with Java or PHP. Because these are just personal preferences, nothing more.

Re: Things I Was Wrong About: Types

#408
TypeScript, Rust, and working on a huge projects impacted me the same way.

Rather than "using types so that things run", I have been encouraging people to ”describe business entities/constraints with types” in some languages. That's a way to get compilers to check half of your business constraints. But, I agree that some types are not worth it, particularly those not separating nullish from its non-nullish counterpart.

Re: Things I Was Wrong About: Types

#409
I think the usefulness of type annotations is directly related to whether you are using classes.

In JavaScript or PHP, it’s usually easy to figure out if something is meant to be an int, string, array or object (yes we’ve probably all done “1”+1=>”11” before, but it’s very rare).

But if you are using classes, it’s very useful to distinguish at coding time which exact class an object is. Often you’ll end up with multiple classes with similar sets of properties, and it’s imperative to know which one is being used so you call the right methods.

Re: Things I Was Wrong About: Types

#410

Earlier quoted context omitted.

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…

The other issue with dynamically-typed languages is that the language sometimes "helpfully" fixes the types for you. I came across one JS project that said this: for (var i = 1; i != Math.pow(2, 16); i Replacing Math.pow(2, 16) with 1 (It's been a while since I coded PHP, but my recollection is that PHP tries to pull a strings-are-integer tricks a few times).

> my recollection is that PHP tries to pull a strings-are-integer tricks a few times

Yeah, the implicit casting in PHP is bonkers, especially when it comes to comparisons. The comparison table looks like the scribblings of a madman: https://www.php.net/manual/en/types.comparisons.php

(though granted, Javascript acts very similarly.)

Post reply on HN