Strong static typing, a hill I'm willing to die on

https://www.svix.com/blog/strong-typing-hill-to-die-on/

by tasn • 3 years ago

394 852 3 years ago

insanitybit15• 3 years ago

At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer. The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high.

edit: To clarify, I am on the "types good" side of things

wiseowise3• 3 years ago

The only absolute truth there is. Static typing is nonnegotiable.

dartos5• 3 years ago

There’s strong typing and weak typing.

And then, kind of orthogonal to that, there’s also static typing and dynamic typing.

I think strong, dynamic typing is just as good as strong static typing (weak typing is objectively bad)

As long as the types of your variables don’t change from under you, that’s good, but I’m also okay with the compiler / runtime figuring out what those types are for me.

IKantRead2• 3 years ago

Dynamic vs static typing is a similar level of design decision as interpreted versus compiled. It's ridiculous to try to claim one is universally better than the other as they both have styles of programming and domains they are better suited for.

I would never want a statically typed, compiled awk for example.

I generally think large, production, multi-developer software should be written in a statically typed, compiled language.

Strong vs Weak typing is a closer to a debate about having a name spacing system or not. There is really no great reason to have weak typing or not use a name spacing system.

tasn11• 3 years ago

Author here. I ended the post with:

I can see both side of the arguments on many topics, such as vim vs. emacs, tabs vs. spaces, and even much more controversial ones. Though in this case, the costs are so low compared to the benefits that I just don't understand why anyone would ever choose not to use types.
I'd love to know what I'm missing, but until then: Strong typing is a hill I'm willing to die on.

I genuinely want to know what I'm missing. I also outlined in the post all of the arguments I usually see in favor of not having types and why I disagree with them.

I'm happy, willing, and excited to hear what I'm missing.

a_c• 3 years ago

I think you and parent are in agreement

insanitybit15• 3 years ago

Hey, I hear you, and I commend you for your good faith position of "I want to hear both sides". I'm just not there anymore. The arguments put forth ("the cost is worth it, it makes up for itself", etc) are arguments I've had a million times and I just no longer will engage.

randomdata4• 3 years ago

I just don't understand why anyone would ever choose not to use types.

Is there a language out there that gives you that choice?

I expect you mean choose not to use strong static typing as per the original piece? Compatibility is a pretty good reason. I'd like to see Javascript die in the fiery pits of hell as much as the next guy, but its positioning means it is almost inevitable that some system will make it the only reasonable choice for you to choose if you want to build for that system.

Typescript doesn't help. It adds static typing, but not strong typing.

user39393823• 3 years ago

There's a specific scenario where I have more sympathy for weak typing, which is: I'm writing a small, focused utility by myself whose scope can never expand and whose code will never be collaborated on. I do have these, little shell scripts. I write them, they work, I move on and use it for 10 years. No types in there, fine whatever.

As soon as there's any complexity at all or another person involved that exception stops.

packetlost8• 3 years ago

I'm also a pretty die-hard type-system user, but I've been programming a lot of Lisp and FORTH lately. FORTH is just bad at safety period. Lisp, on the other hand, I can see why there really isn't a need for types. The macro system means you can create arbitrary "compile-time" safety checks which is, IMO, more powerful than just a type system. That being said, I would still love a strongly, statically typed Lisp, or at least one with a strong macro type system (before y'all mention it, I'm not a fan of typed Racket).

PrimeMcFly• 3 years ago

In my experience whenever you put effort into making a post like this, outlining the common arguments you hear and your attempt at refuting them, people don't really pay attention and will just repeat the arguments you already addressed, ignoring your refutations.

stratigos3• 3 years ago

Youre missing the perspective of a business owner and operator that has to hire many people with diverse patterns of thoughts and beliefs who will most likely work for their organization for less than 24 months.

1-more4• 3 years ago

What does "strong" mean as regards typing. I've heard a few different definitions so I'm curious what yours is in the context of this article.

ndr• 3 years ago

Consider reading/watching Rich Hickey's talk Effective Programs [0][1] and Maybe Not [2][3]

In [0] in particular there're slides 22/23, here is part of the transcript but makes more sense with the slides on:

And you can call them problems, and I'm going to call them the problems of programming. And I've ordered them here [...] I've ordered them here in terms of severity. And severity manifests itself in a couple of ways. Most important, cost. What's the cost of getting this wrong? At the very top you have the domain complexity, about which you could do nothing. This is just the world. It's as complex as it is. But the very next level is the where we start programming, right? We look at the world and say, "I've got an idea about how this is and how it's supposed to be and how, you know, my program can be effective about addressing it". And the problem is, if you don't have a good idea about how the world is, or you can't map that well to a solution, everything downstream from that is going to fail. There's no surviving this misconception problem. And the cost of dealing with misconceptions is incredibly high. >So this is 10x, a full order of magnitude reduction in (?) severity before we get to the set of problems I think are more in the domain of what programming languages can help with, right? And because you can read these they'll all going to come up in a second as I go through each one on some slide so I'm not going to read them all out right now. But importantly there's another break where we get to trivialisms of problems in programming. Like typos and just being inconsistent, like, you thought you're going to have a list of strings and you put a number in there. That happens, you know, people make those kinds of mistakes, they're pretty inexpensive.

[0] Video: https://www.youtube.com/watch?v=2V1FtfBDsLU

[1] Slides and transcript: https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

[2] Video https://www.youtube.com/watch?v=YR5WdGrpoug

[3] Slides and transcript https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

sumtechguy• 3 years ago

Weak typing has its uses in one use case. Transition between systems. Even then you usually want to know what the type is (unless you really do not care about validation errors).

The reality is I never get to choose. I prefer strong typing. But the projects I am on that ship sailed long ago 2 developers back who used this project as a resume builder.

c048• 3 years ago

People that still want to try and fight it either:

- Use notepad for development (don't laugh, I've actually encountered a dev who's choice IDE was notepad).

- Never worked with more than 1 person on a project.

- Never worked on anything but tiny projects.

- Never re-opened a project after having worked on a different project for several weeks.

Qwertious• 3 years ago

You should legitimately try a project in notepad. Not Notepad++, specifically Notepad. Probably a very short project, but you should give it a shot. It'll give you a bit of a perspective. And some real appreciation for Notepad++.

halfmatthalfcat2• 3 years ago

I've worked with my fair share of vanilla JS devs who refuse to acknowledge the benefit of more statically typed variants of the language. Most of them bemoan the upfront cost of typing everything without realizing the benefits of it. I absolutely think less of them as developers.

giraffe_lady2• 3 years ago

Not liking typescript is not the same thing as denying that types are valuable.

TS has a very complex type system in exchange for relatively weak guarantees about correctness. That's a tradeoff you can choose to take or leave depending on the problem at hand, and holding that position is not the same as believing types have no value.

Unless you're talking about elm or rescript or something then sure sure. But usually when people say things like this they mean typescript.

arp2427• 3 years ago

Are these people who used types but didn't like it, or people who never really used it and refuse to even try it?

IMHO these are markedly different scenarios: the first is essentially just a difference of opinion, the second is a rather myopic attitude.

lo_zamoyski• 3 years ago

Have they considered languages with type inference?

digging10• 3 years ago

bemoan the upfront cost

This applies to much more than static typing as well. Anything built, can be built well or it can be built quickly.

Although I often have to make trade-offs for immediate gain at work, there is a big difference between the quality of my work over time vs the quality of other devs who default to immediate returns. I will say in their defense, they play a role in the team. But I wouldn't want to work on a team where avoiding upfront costs was the expectation rather than the exception.

waffletower5• 3 years ago

And I definitely think less of you as you as a developer as you openly admit to dogmatic and myopic prejudice regarding the nuances of typing systems and the complexity of software development contexts.

leptons5• 3 years ago

I absolutely realize the benefits of it, and I also recognize it doesn't cure all. Everything has trade-offs. There were plenty of amazingly complex and large projects written in vanilla JS before typescript ever existed, and somehow they aren't falling apart and crippled. It really depends on the developers involved more than the language or the dogma.

ecshafer• 3 years ago

This sounds like its just Typescript evangelizing. But while I love types, Typescript kind of sucks and sucks the fun out of writing Javascript. If I am going to add a compilation step to get types, I would rather write Scala or F# and compile to JS, then you also get rid of all of the warts of JS that Typescript doesn't get rid of.

manicennui4• 3 years ago

The problems with JS go far beyond its dynamic typing.

msla• 3 years ago

Similarly, choosing between 'int' and 'long' isn't part of a type system, unless the only semantics your data has is being an integer of a given width. Types are semantic, and telling me "height is 32 bits" tells me jack shit about units of measure or anything else.

pfdietz10• 3 years ago

Strong static typing is useful in the environment where the code is not adequately tested. That's because tests adequate to make the code bulletproof will also detect the problems strong static typing could detect, rendering SST superfluous.

So, how often is poorly tested code out there? From the popularity of strong static typing, it must be ubiquitous.

ozr2• 3 years ago

Ubiquitous is a good guess.

dolmen• 3 years ago

The point of static typing is that the compiler does checks before your program even starts. And that avoids to write lot of coverage tests that are needed (but usually just ignored) with languages that massively use loosely typed data containers (variables).

ShellfishMeme• 3 years ago

Strong types aren't just a correctness guarantee, they also help to discover structure and interfaces that previously were implicit.

If a developer can jump into an unknown part of a codebase and quickly see that following a certain structure will automatically make their code work for them without needing to read all the code first and double checking if it's just a random convention versus a strict interface so they don't reinvent the wheel or build code that doesn't fit in with the existing structure, then that's worth a lot and something you cannot simply cover with tests.

user39393823• 3 years ago

Integration tests are different, but I tend to believe that a strong enough type system should be able to negate the need for unit tests completely.

If anyone can think of something a unit test could test for that an arbitrarily* complex/strong type system couldn't I'd be interested to hear it. It's possible, I just can't think of any.

xmcqdpt23• 3 years ago

High test coverage is useful in the environment where the code is not adequately typed. That's because static types adequate to make the code bulletproof will also detect the problems unit tests could detect, rendering high unit test coverage superfluous.

So, how often is poorly typed code out there? From the popularity of test coverage tools, it must be ubiquitous.

yakshaving_jgt4• 3 years ago

Strong static typing is useful in the environment where the code is not adequately tested. That's because tests adequate to make the code bulletproof will also detect the problems strong static typing could detect, rendering SST superfluous.

Ok, but it's cheaper to not have to write those tests than it is to write those tests.

soggybutter• 3 years ago

Good tests only render SST superfluous insofar as the person writing the tests is capable of never making a mistake. The thing about good static type systems is they don't typically make mistakes in the domain they work in. The fact that you don't have to muddy your test with a bunch of type checking logic and instead focus on the thing actually being tested is just the cherry on top.

Kuinox• 3 years ago

Tests is testing your program against samples, where strong typing make your program incorrect on a whole spectrum of samples.

mejutoco2• 3 years ago

That is a very original take, but I think you have it reversed. Typing removes the possibility of _some_ errors. Those are tests you do not _need_ to write (you can still write them if you want), thus having more time and attention to write tests that matter. Typing is a baseline, and anything over that baseline you can deal with with tests.

It is like the things you already trust when you code. Let's say, that the file system works, that the network stack of your OS works, or that the cpu works. You can rely on them to use your time for the things that matter. This is a much better model than simply testing everything yourself since, as the tests number increase, any change to the codebase involves more and more test changes.

Strong static typing is useful in the environment where the code is not adequately tested. That's because tests adequate to make the code bulletproof will also detect the problems strong static typing could detect, rendering SST superfluous.

Your logic is the same as follows: seat belts are useful in an environment where drivers are not driving adequately. That's because adequate drivers will drive in a way to avoid any danger that the seat belt would prevent, rendering seat belts superfluous.

Ultimately, the problem is adequate drivers (as in described above) or bulletproof tests do not exist, they are just a concept. A test can prove the presence of an error, not the lack of errors, and the argument only works in absolutes.

d3w4s9• 3 years ago

No. It is useful in almost every environment other than things like REPL. I can write TypeScript for hours without writing any tests, run it and fix a few minor logic bugs and code is production level, which is great for prototyping. No chance with plain JavaScript without typing -- it would be at least a day or two and I would constantly run into stupid typos or other errors that can only be found at runtime.

sneed_chucker2• 3 years ago

Yeah, big piles of untyped Django spaghetti need a behemoth suite of integration tests in order to remotely approach the sort of runtime guarantees that typed languages give you for free.

When you use a typed language, you can use your integration tests to actually verify business logic, exception handling, etc. instead of having to write a dozen test cases to make sure that doThing(table, index,*kwargs) doesn't blow up when 'table' is a list or 'index' is bytes...

bitblender4• 3 years ago

I don't consider it productive to be personal about technical topics. It's best to divorce yourself and the other party from the issue to limit as much bias as possible. You don't need to worry about the good-faithness of an objective, egalitarian discussion. It's never truly objective, but you can at least catch yourself saying things like "I might think less of you as a developer" and recognize that's a preconceived notion. In some cases, it may be turn out to be accurate, but it's definitely not always. Dynamically typed languages have had an important role historically in software. We should not categorically denounce people who prefer it as lesser developers. I also generally prefer static types.

insanitybit15• 3 years ago

I explicitly said "as a developer" because it's not a personal judgment. You can be a good person and also have a terrible take as a software engineer.

We should not categorically denounce people who prefer it as lesser developers

I don't think you've justified this point. I'm comfortable with my position on this.

loup-vaillant4• 3 years ago

Some prejudices are rational. To paraphrase, it would take an enormous amount of prior trust and respect before I even humour someone trying me to convince me the sky is green with a straight face.

Some issues are settled enough that there is no need to discus them any further. It is okay to automatically mark people on the wrong side of such issues… let’s say ill-informed.

Static typing, I believe, is close to being one of those issues.

ilaksh2• 3 years ago

As someone who usually prefers JavaScript over TypeScript but has used many typed languages over the years and generally finds then easier to work with in a way, I agree that one should not pre-judge based on something like that.

But he's just being honest. Many developers have been making that judgement for many months or even years.

HideousKojima2• 3 years ago

Nah, someone opposed to typing is either a shit developer and/or a madman who codes too clever by half mad shenanigans that take advantage of the lack of strong typing. I wouldn't want to have to maintain or depend on code written by either.

For the very rare cases where a lack of strong typing is needed, most languages with strong typing offer ways to handle that (i.e. the Object and Dynamic types in C#)

mvdtnz3• 3 years ago

I think you're being a bit too sensitive, and it's not personal. Someone is espousing a (bad) technical opinion about their field of work, it's not unreasonable to say you respect them less in their field of work. That's not personal.

It's like if you met a builder who refused to use a hammer and insisted on bashing nails in with the back of their drill. It's not "personal" to say you'd respect that person less as a builder, regardless of how much you'd enjoy having a drink with them.

bennyelv• 3 years ago

Amen!

I'm currently responsible for a very large system built in raw javascript where function definitions like this one in the article: function birthdayGreeting1(...params)

...are the religion.

It's awful. I hold the people responsible in very little regard.

KronisLV2• 3 years ago

At this point it's beyond a hill I'm willing do die on. I'm not really interested in discussing it. If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer.

That's a pretty strong take! I don't think there are many things that I feel similarly about... maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens, when it'd be my employment on the line, but even that's a pretty contrived and out there example.

The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high.

My problem is that not all type systems and the way you use them are equal.

When working with back end code, I really like .NET or even Java having a type system there for me. I know that people suggest that they have their own shortcomings (type erasure, NPEs, no multiple inheritance, even smaller things like C# enums not supporting methods) and that there are better options out there, but generally you can turn off the part of your brain that'd worry about the language too much and just deal with the domain problem at hand. Something like JetBrains are also excellent, because with the type system suddenly the tool also can reason about the language constructs you're using and give you all sorts of good suggestions and refactoring options.

Whereas with something like TypeScript in combination with React, there are times where you fight the type system instead. That's just the impression that I got working on a few projects for a while, in comparison to React with JS (perhaps the code was also a bit too clever), while with Angular it felt more coherent to me (despite Angular being more complex otherwise and not really my first choice). In the end, I gravitate towards Vue with JS for my personal stuff, but it's not like you can just say no to TypeScript when you need to maintain something long term.

I can't actually remember who said that they ditched TypeScript for similar reasons, but the argument was basically that a non-insignificant part of their codebase was there just to satisfy the type system. TypeScript does what it's supposed to... but it feels like it could be easier.

insanitybit15• 3 years ago

That's a pretty strong take!

Not even one of my spicier takes, just one of the few that I simply don't care to engage with further.

My problem is that not all type systems and the way you use them are equal.

We agree. Some type systems suck so badly that I can see why people would be tempted to believe that all type systems suck.

mcv3• 3 years ago

I'm pretty agnostic about the whole thing. The topic has been done to death already. Types are great, but some ways of handling types can get in the way sometimes, and the excessive type declarations in older Java was just painful. Dynamic types can work fine too, but they work better in smaller projects than in bigger ones. Types do give you a lot more to hold onto, even if they're only compile-time types like Typescript. In large, complex projects where you're juggling a lot of different types, you want to know what you've got in your hands.

That's pretty much my take. I don't hate anyone for having different ideas about it. But if you're going to use Typescript, don't use 'any'. At all. Unless you really don't know and the next step is figuring out what type you've got.

xxs• 3 years ago

maybe if someone suggested that they don't need test environments and can just deploy changes to prod without testing or CI/CD and just see what happens

That's actually not hard, you need to be able to run in dry mode, and run the same in an existing instance (in parallel), then compare the results. If you are happy you can continue with the roll up, disabling the dry mode.

pharmakom2• 3 years ago

Also on the “types good” side of the fence. HOWEVER, I also believe that mainstream typed languages cannot represent some situations very well. Often the only attempts to do so are in some weird Haskell extension and it feels rather… inelegant. Bottom line: types are better; but our current type-systems are not the final word on types.

omnicognate• 3 years ago

The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high.
edit: To clarify, I am on the "types good" side of things

I agree. Python 1 would have been worthless if it didn't have types.

fsdjkflsjfsoij4• 3 years ago

This is basically where I am at. Most libraries and applications are trivially typed even in languages with relatively poor type systems like Go and Java. The necessity, or even benefit, of weak and/or dynamic typing is extremely rare and most languages have workarounds or escape hatches for those exceedingly rare cases.

Dynamic typing also makes a ton of optimizations basically impossible and even after monumental efforts languages like Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

diggan• 3 years ago

Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

I thought this meme was dead already. Of course, you might not be able to squeeze out the same amount of performance compared to a brilliantly written C or Rust program, but for what it is, JavaScript is pretty damn fast already.

DOM manipulation on the other hand, is still a very common bottleneck people come across when writing typical JavaScript code.

da4c30ff2• 3 years ago

The take I have is that with a dynamically typed language you still have a static analysis step. It’s just that the analysis happens in your and other developers’ brain and it is objectively worse. I honestly can’t think of a single thing in favor of dynamic typing.

I write Clojure in my day job and it’s insane how often we have issues where it would have been immediately caught by a static type check.

vasergen• 3 years ago

Javascript are still quite slow

Can you describe your usecase for which JavaScript is slow? There are many languages that are slower than js like python or elixir, but they are doing just fine, that's why I won't agree that js is slow, but sure there are cases for which js just wasn't designed, and any CPU intensive task will be slow, but there are ways to get around it as well.

throw109202• 3 years ago

Dynamic typing also makes a ton of optimizations basically impossible and even after monumental efforts languages like Javascript are still quite slow, inconsistent and memory inefficient outside of trivial benchmarks.

Please provide evidence for this extreme claim. I can point to benchmarks[1] where JavaScript is competitive with or even better than compiled static-typed languages like Java.

(any argument that those are "trivial benchmarks" is automatically invalid without actual empirical evidence)

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

jerf• 3 years ago

There's a temporal component to the argument. Strong typing in the 1990s wasn't very good. Dogma at the time resulted in very rigid designs. The verbosity of it all was staggering. Incorrectly-used Hungarian notation ran rampant and made everything hard to read while still not helping anything [1]. The costs were a lot higher than it is today and the benefits a lot less.

Nowadays, the static typing is much nicer, with both higher benefits and lower costs, and it makes the costs/benefits analysis much more likely to come out in favor of static types.

In the late 1990s when I was cutting my teeth, I did a lot of Python, and I was almost 100% dynamic language until ~2015. In hindsight, I might do the same again even if thrust back in time. There just isn't a great static option back then. (I'm not saying 2015 is the year it became practical, I'm saying that's when I finally moved into static languages. 2010-2015 or so I was in Erlang, doing things that most other languages couldn't do at the time, so that forced me into a dynamic language. C# was looking pretty good in that time frame too, it just wouldn't have run the systems I had on anything like the resources I had at the time. It could probably easily do it in 2023 though.)

Now I even prototype in static systems, and it's a better experience than prototyping in Python was. Like, by quite a lot, honestly. In the end, I don't find it that much of an impediment to make sure that if I want to call a method on a thing, that the method actually exists.

Dynamic typing will never disappear; there's a certain small size of task for which it'll always be more advantageous than static typing, and while said tasks may be small, there's a lot more of them than there are large tasks, so it's a completely valid and sizable niche. But I do think over the next 10-20 years we're going to see the "scripting" languages return back to "scripting" and away from "systems".

I think that in the end, the dynamic scripting languages being used for large tasks will be seen as a reaction to a misdiagnosis of the problems in the 1990s. The code was atrocious in the 1990s not because it was statically typed, and therefore the solution is to go dynamically typed. The code was atrocious in the 1990s because it was poorly statically typed, and the solution was to get better. That said, "getting better" did take a long time, and for many legitimate reasons.

(Much ink is spilled on the so-called rapid pace of technological innovation in our industry, but programming languages move on decadal scales. Programming languages still have only barely grappled with a multicore world, and haven't grappled with a heterogenous computing world at all (GPUs on one end, efficiency cores on the other). Things are not always in as much motion as we fancy.)

[1]: Particularly, Hungarian notation is supposed to supplement the type, not just reiterate it. If you're in a language where you can't easily declare "a width is an int", then Hungarian notation suggests calling a width variable something like "wdthDialog", so that you stand a chance of noticing that you passed a "hghtDialog" in the wrong place. But the way it was used a lot of the time is you got "u16Width" instead, where u16 meant unsigned 16 bit int... but that's already in the type. Using it that way just adds an extra layer of hierglyphicness to the already ugly code. One of the several innovations that made static typing languages more feasible is that in most languages designed in the last couple of decades, you can declare something like this with something like "type Width int", and then you don't need to label any variables with it at all, the compiler enforces it.

throw1234651234• 3 years ago

I think this is especially true for line of business applications that have the following qualities:

1. It's simple. Let's not lie, let's not pretend. It's CRUD. You can put in K8S, you can add AI, it can be behind an API Gateway, you can make it all Event Driven, you can use CQRS for every entity because you really, really want to feel clever. But it's still CRUD.

2. Other people are working on it, many other people.

3. People from other companies are interfacing with it.

So knowing what to expect trumps everything. Types help with that. They help a lot.

stratigos3• 3 years ago

Unfortunately this attitude is not profitable, and also smacks of someone who works on their own island and costs a business more than they add value given their inability to work as a team. This attitude might find a way to be profitable when held by a university professor, though that does not mean its desirable.

insanitybit15• 3 years ago

This is not a "work" attitude. I would never impose my opinions on a team. I've worked professionally in many languages with a variety of type systems. In virtually all cases I have reviewed very positive feedback throughout my career, in particular in terms of my ability to work well with others, to mentor, etc.

WirelessGigabit• 3 years ago

I actually like this approach. I believe in mentoring. I believe in building bridges. But if we're on opposite sides of the Grand Canyon, it's not worth my time.

mpweiher13• 3 years ago

Well, getting this personal about a purely emotional preference might make people think less of a person that does that, with significantly better justification.

To be clear: people have tried to show the long-claimed safety benefits for a long time, and they just refuse to appear.

AlchemistCamp3• 3 years ago

This is a very arrogant and dismissive attitude to take. Consider that both pg and DHH prefer dynamic typing. Maybe you can think less of them as devs, but what each built is undeniable.

What have you built or added to the field that justifies such a lack of tolerance of those who don’t subscribe to your point of view?

insanitybit15• 3 years ago

I reject the idea that pg/DHH should be treated with any authority here, and I reject the idea that I need to prove my authority to you.

That said, yes, of course my post is arrogant and dismissive. I am outright saying I won't engage in a conversation. I'm comfortable with that.

nkozyra• 3 years ago

I'm baffled it's even a debate. Who wouldn't want strong typing? What's the argument?

digging10• 3 years ago

Mostly, it boils down to selfishness and "laziness". (Although I try to be very careful about that term, because I do not believe in it as generally used. I use it here to define: an unwillingness to plan ahead and to have to learn something new. Not applied as a global personality trait but only used in context.)

pxmpxm• 3 years ago

These days you get loads of people without CS degrees that spend their days as python/js "coders" for things that don't really matter.

zare_st• 3 years ago

I'm not sure what I'm reading here.

Types are integral part of standard programming languages. If you mean "types bad" as in BASIC/Javascript variables, then yes I fully agree. These languages were never meant to be a solution for professional software engineering.

Once a language has proper types, it can be "weak typed" by not forcing "strong typing" by being dynamically typed in nature. If the language has normal preprocessor support, the static type system can be added on the project level. And then in essence you get a strong typed environment in a very thin programming language such as C.

Let's take a big C or C++ software project, the process behind it. Of course, the project is in those languages because it requires native opaque pointers and hardware access. The project has coding style, it has arbitrary rules. Although there is little to stop anyone from making a mess in C or C++ code there is entire code infrastructure and CI/CD chain around it. Lets say the rule is no void pointers without encompassing struct that's a type that can be checked via macro system. If you wrongly use the type struct, you get stopped by the project build. If you go around the rule, you get stopped by a code analysis after commit (and get in trouble for doing that).

edem• 3 years ago

Same here. Whenever someone starts babbling about why __language x__ is hard because of types or whatever, I just disengage. I don't care what anyone thinks about types. I use them, and I will keep using them no matter what.

yowlingcat• 3 years ago

The amount of pre-existing respect for someone I'd need to have before I engage in a good-faith discussion on "are types good" is pretty high.

I think that says more about the strength of your zeal than of your argument.

yetanotherasian• 3 years ago

How often do you write bash scripts or do you always write all automation in some other language? Just curious how much your conviction influences your behavior

bigstrat20034• 3 years ago

Speaking for myself, I never write bash scripts if I can help it (though sometimes I can't help it). That isn't so much because of typing, though... it's because bash is a fucking horrible language that should have died 30 years ago. The fact that there's no such thing as types in bash is just one of many reasons why it sucks to use.

insanitybit15• 3 years ago

I write code without static types all the time. Daily probably. I am "pro types" in a hand wavy way. My conviction is to no longer engaging in the debate.

codegeek• 3 years ago

I don't necessarily die on that hill but I definitely want to fight on that hill.

nsajko• 3 years ago

You're confusing static typing with the existence of a type system. As an example, Julia has a rich type system, but the language is dynamically typed.

iopq4• 3 years ago

There's ONE argument that I'm partial to:

if you get the static type system wrong once, there's no going back

Take for example, Rust: mut, Send, Copy, Drop, Debug, dyn have all their warts because they are special and you can't fix them because you'll break previous code.

In a gradual typing language you could potentially bolt-on your own type system as a package where it just runs the type checker if you want one. It just so happens people who favor these gradual typing systems don't do a good job of creating those typing systems because they are not that into types in the first place.

But in theory, this kind of a system would let you not worry about types when prototyping the system, then put some bounds later based on your requirements.

patrickthebold3• 3 years ago

I'm with you, especially in my professional life. That said, I think Clojure is interesting and Rich Hickey has some good talks in support of dynamic typing.

TheBlight• 3 years ago

Not really interested in discussing it. posted on discussion forum ;)

JonChesterfield6• 3 years ago

It really matters which static type system is in question.

SML or Haskell? Yep, like those ones. The languages would not be so useful without their compile time type checking.

C? Not worth the trouble. C++? Not worth the tarpit or the trouble.

Python? Definitely not keen, that language was much better without the annotations.

Typescript people really like but I haven't played with. I'm pleasantly surprised that unsound static + sound dynamic works well.

Type annotations are not inherently good. Some type systems add a lot of value, some really don't.

oldpersonintx2• 3 years ago

type ":t" in ghci for many common Haskell types (functions are also types fyi) and tell me if you have the faintest idea what you are reading

lots of comments here praising Haskell and Rust frankly seem to be coming from people with a superficial understanding or limited exposure

I've had rustc complain about type deductions that were over a line long...that's just one inferred type...you can easily paint yourself into a corner with a type system with no exit other than trying to cajole the right definition out of the compiler and then you copy-paste it and pray

xigoi3• 3 years ago

C? Not worth the trouble. C++? Not worth the tarpit or the trouble.

The OP said strong static type system, so C and C++ are out of the question.

chongli3• 3 years ago

This is not about type annotations, it’s about type systems. You can write Haskell programs without any type annotations. Your program will type check and compile just fine. The value comes from the checks (as well as the inference, documentation, optimization, and everything else a modern type system gives you), which you don’t have to write yourself, you get them for free.

People who say they prefer dynamic languages are really just saying ‘no’ to all these free benefits.

ActorNightly7• 3 years ago

SML or Haskell? Yep, like those ones

Not strong enough.

If you are proponent of strong typing, you need something that is effectively a theorem prover. I.e when you define a type, you define the scope of the data it can hold, operations on that data, and the resultant types of those operations. That way, when you code compiles, it is by definition "correct".

When you accept anything less then that, you are basically making a statement that you are willing to forgo some of that correctness for convenience, which is fine, but that means that no language out there is really good or bad.

yxhuvud• 3 years ago

100% this. Developer experience in a language is a so much bigger question than if it has static types or not.

oldpersonintx2• 3 years ago

languages do not exist in isolation

if I store sql with a column definition that stipulates that the value must be an int between 1 and 3...what difference does it make if I accidentally create a corresponding variable with the value "fred"? it will never be persisted

furthermore, you can run in to even more confusion with a language type that is not properly aligned with the database type...which one wins? the db obviously, since language values not aligned with database definitions will never be persisted

sbjs• 3 years ago

Yeah I've been in that camp since like 2016. TypeScript is basically an essential for me now, and I don't debate it with anyone. If they don't get it, it just gives me a baseline understanding of how little experience they have in real world software development.

Rapzid2• 3 years ago

That's a good year; TS had just added async/await.

oweiler• 3 years ago

God, what has become of healthy discussions? People getting more and more toxic these days...

insanitybit15• 3 years ago

I'm all for healthy discussions, but I think it's fair to say "I've had this discussion enough times, unless you're really bringing something new to the table, I'm opting out".

digging10• 3 years ago

Is it really a healthy discussion? At least with respect to JS vs TS (which is the most common argument as it's a choice every front end team has to make), it's blogs saying "fuck types, I like JS only." I'm not going to step in and tell another team what to use but whining about the difficulty of static typing is just not a productive conversation. I've been converted by the top level comment; I'm not longer interested in entertaining the discussion.

bcrosby952• 3 years ago

I don't use dynamically typed languages because they're dynamically typed. I use them for other reasons and they happen to be dynamically typed.

I'm not going to argue that these features are only possible because of dynamic typing, but regardless, statically typed languages tend not to have them.

Elixir may get "some form" of typing, but it likely won't be traditional static typing.

syndicatedjelly4• 3 years ago

What are those features?

optymizer2• 3 years ago

I find it interesting that people in this thread seem to have absolute certainty that "types good" is true, while to me those two words together are largely non-sensical, just like "bytes good" wouldn't make much sense to debate.

prewett3• 3 years ago

After you repeatedly waste a bunch of time debugging things that static typing would have caught on the first compile, and you start developing a "types good" attitude. If you just do simple React development, you might not ever run into the problem. But once your programs get to a couple thousand lines, you start occasionally forgetting what your function takes and passing in the wrong things, which then get passed around for a while and throw an exception long after the problem happened. This results in very unfun print-debugging, particularly in a recursive descent parser or an algorithm that processes a lot of data.

flohofwoe2• 3 years ago

So... about the strong part in 'strong static typing':

Many years ago I thought that it's a good idea for a game math library to have separate strong types for 'point' (a location in 3D space) and 'vector' (a direction and magnitude in 3D space), and allow/disallow certain operations (e.g. 'point + vector => point' 'vector + vector => vector', 'point - point => vector', while 'point + point' is illegal).

Sounds absolutely great in theory, but in practice it was a royal PITA to work with, but it took me much too long to realize this (how can it be such a hassle when in theory it's such a good idea!)

I soon went back to a general 4D vector class (where a 'point' is defined by .w = 1.0, and a 'vector' by .w = 0.0), and some debug-mode runtime validation (which catches things like trying to add a point to a point).

Of course strong typing also often makes perfect sense, for instance in a 3D rendering API it should be a compilation error to provide a texture-handle where a buffer-handle is expected, but after this experience with points vs vectors (which should've been a classic showcase for strong typing) I would never again "die on that hill" :)

TL;DR: static typing: yes! strong typing: it depends.

Someone• 3 years ago

For things like kilometers versus hours I'm still undecided.

Those help you more if you do a lot of math involving both them, but that’s also when it becomes a nightmare in most programming languages because of an explosion in the number of types.

Let’s say your code computes

  3km × 4hours

If so, you need a “km hour” type.

In many languages, you also have to write code to make that happen, and to make it have the same type as

  4hours × 3km

Even if you don’t ever store values with those types in variables, you also may need types for per km, per hour, km² and hour² for expressing the types of intermediate values (for example, in a physics computation, you may encounter √(3km²/4hour² to compute a velocity in km/hour)

And that’s ignoring that you may

- encounter minutes, meters, yards, etc.

- want to use algorithms that compute exp(3km) or log(4hours). What types do these have? Here, you probably want to forget about string typing values.

sneed_chucker2• 3 years ago

That's not a shortcoming of strong or static typing, that's just you realizing that your initial data model was flawed and that you either needed to unify them into a single type (like you did) or utilize an abstract class/interface.

The good thing about stricter typing systems is that it forces you to handle all the cases when you're doing a refactor like this before it compiles.

When changes to the data model happen in large codebases of dynamic code, it frequently gets shipped in a non complete state and turns into a production runtime error later down the line.

waffletower5• 3 years ago

In my country, the United States, we have broad protections for religious beliefs.

scarythrowaway• 3 years ago

I mean, that's one reason I like dynamic typing, I get to avoid a bunch of psycho cargo culters for free.

cries at the thought of insanitybit not respecting me

thefaux• 3 years ago

If you don't get it I probably don't want to talk to you about it, I might even think less of you as a software developer.

The feeling is mutual.

fargle• 3 years ago

and yet... here you are discussing it. ;)

discussions are a two-way street. if you aren't getting it, then how do you expect someone else to "get" your position?

    "The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts"

-- Bertrand Russell

[edit: To clarify, i am on the "i like strong static typing most of the time but also understand their pros/cons wrt. dynamic languages" side of things]

lasermike026• 3 years ago

Understand that there is no hope. You will die on that hill. Get over it.

leptons5• 3 years ago

Trigger warning: I love to write assembly language.

I probably love assembly language more than C#, or C++, or any of the strongly typed languages I use.

Assembly language has no types. It doesn't pretend types even exist.

Are you going to look down on me because I like to write assembly language?

insanitybit15• 3 years ago

Are you going to look down on me because I like to write assembly language?

Nope.

ActorNightly7• 3 years ago

Here is a fun fact that you don't realize.

Say you can do the project in 2 ways.

First way is to use a strongly typed language, think about the data, and design your code in the appropriate way. You code it up, go through the loop of compiling and fixing errors, and get your code to run.

The second way is to write your code in Python, without worrying about strong types. You complete the code quite a bit faster, but since you also want your code to be correct, you spend time writing an end to end test suit for your code.

The second approach is not only faster (since you are writing tests in both cases), its overall better. Spending time writing tests allows you to essentially validate things that modern mainstream strongly typed languages can't catch at compile time (for example, what happens when the input is unicode strings?). It also forces you to think about end to end behavior and making sure that is correct, rather than just the behavior within your code.

Strong typing is a simply hand-holding tool for programmers. If you cannot write correct code without it, you are on a fast track to being replaced by AI eventually. The future of programming is not going to be designing data structures and types, its going to be using English to generate large chunks of code in most likely Python, and then tweak fine details in those.

gdcbe• 3 years ago

Call me sceptical, but I don’t buy it. What makes you certain that’s the (one) future… Also programming is a super broad field, and more then a field is almost more like a medium then a field.

I honestly don’t know if we’ll still program by hand or not, but I do look skeptical at people who are very certain we won’t. Don’t think that’s the first time in history people make that prediction…

jghn• 3 years ago

Using your example - have a type that that enforces Unicode strings (or vice versa)

_dain_8• 3 years ago

why can't I write it in a statically-typed language and also write end-to-end tests?

also it's pretty ridiculous to say "static type systems are handholding" and then say the remedy is to write your code with AI ..

cjfd• 3 years ago

I think this is completely false. It completely breaks down as soon as you get into your first refactoring that is a bit larger than completely trivial. Typically the mess one ends up is one or more of the following. (1) Nothing is refactored because people do not dare to do it. (2) Not just some but most of the uncommon code paths are broken. (3) Tools that are used to interact with a running application are regularly in a broken state. You want to prevent these problems with 100% test coverage. As such this may be a laudable goal on occasion but I do notice that the code described in (2) and (3) are highly non-trivial to cover 100%. I also have to wonder what mythical developer is does not have the discipline to use static typing but does have the discipline to attain 100% code coverage. I first want to see such a developer before I believe in his/her existence.

gwervc• 3 years ago

Except the kind of people "saving time" writing in a dynamic language will skip the step of writing tests as well since it can be viewed as lost time.

brightball• 3 years ago

I'm firmly in camp "it depends" but it was nice almost talking to you. :-)

auggierose• 3 years ago

I don't know, that is so last millennium. If you prove your software correct, you won't need a static type system, it just gets in your way. And that's a hill I am willing to die on.

RHSeeger• 3 years ago

Sometimes the question isn't "are types good", it's "are the costs associated with static types worth it for this particular use case". And the answer is almost always yes; but the "almost" there is important.

manicennui4• 3 years ago

This is the sort of position that is baffling to me. Software engineers claim to be very logical, but this boils down to a preference being stated as some kind of objective truth. Show the evidence (not anecdotes) that static typing gives benefits that are worth the cost. My anecdotal evidence is that I rarely come across problems in production code that would be solved by static typing and people make the same sorts of logic mistakes in languages like Java and Typescript.

manicennui4• 3 years ago

Arguably, nullability and mutability are issues that cause far, far more issues than dynamic typing.

asdajksah2123• 3 years ago

I think the conversation becomes a lot easier once you recognize that there is no such thing as untyped data.

There's only explicit typing and implicit typing.

So the only real argument you're having with someone is when writing a piece of code, do they want the caller of the code or the input of the code's data type to be known or they want the data type to be a mystery to be figured out, occasionally in production when shit hits the fan.

throw109202• 3 years ago

I reject the idea that pg/DHH should be treated with any authority here, and I reject the idea that I need to prove my authority to you.
That said, yes, of course my post is arrogant and dismissive. I am outright saying I won't engage in a conversation. I'm comfortable with that.

This is an extremely toxic attitude. I wouldn't be interested in working with you in any professional capacity, on an open-source project, or having you as a friend, and as a matter of fact if someone expressed this attitude at work I would complain to HR.

vouwfietsman7• 3 years ago

Couldn't agree more. I suspect in the future software professionals will be apalled by the abuse of freedom that we currently have in languages.

The more freedom we take away, the higher quality software we produce. Looking at you, Rust.

goalieca• 3 years ago

This is an old thought but one which favours declarative languages over procedural ones.

vouwfietsman7• 3 years ago

No it's not, I had it just now.

wait_a_minute2• 3 years ago

The more freedom we take away, the higher quality software we produce.

How are you measuring this?

vouwfietsman7• 3 years ago

Every fortnight during a full moon.

All kidding aside, obviously I don't. That shouldn't detract from my statement at all though, nobody measures anything about software. We're all in the dark. Thats actually reinforcing my beliefs: we are in the dark because software is unmeasurable because of the freedoms taken by programmers that fail to abstract or fail to be formalized.

Formalizing software, and then starting to measure changes rigourously, is the first step we have to take towards becoming a mature industry.

Formalization is the oposite of freedom. People think software is like art, where freedom of expression broadens horizons. This is no longer true, most software is not art, most software is buttons that make money when clicked.

bspammer• 3 years ago

Asking someone to maintain an untyped codebase is like asking them to play a game without telling them any of the rules.

riskable• 3 years ago

Your statement reminds me of the spoon scene in The Matrix: Instead of trying to bend the code to fit within the confines of its types simply try to realize the truth... Static types are just more code. They're extra conditions that we apply to things like function signatures and variable definitions instead of adding conditional checks where it matters.

"Aha!" you say, "but by enforcing conditional checks at variable definition and inside function signatures we don't have to check them ourselves in our code and the compiler itself can check them to ensure correctness and optimize performance!"

...and I'd agree with that sentiment but I'd also add that by having to reason about your types constantly you're adding a non-trivial amount of mental overhead when structuring your code. For some people that's how they reason about their code anyway but for others, having to consider whether or not a number is a `u8`, `u32`, or `usize` adds a lot of complexity to the code that could very well be entirely unnecessary depending on the use case.

Consider, for example a program that's meant to be executed on the command line that takes two numbers and adds them together. No matter what language you use you have to convert the raw string input into a numerical type before performing the addition.

In Python you have a simple function, `int()` that will happily turn any string consisting of numbers into a proper integer that can be used for math operations. If it gets something that isn't a number it'll throw an exception which is trivially easy to detect and wrap in a `try`/`except` block with a user-friendly error message. If we wanted to support floating point numbers we could just use `float()` and the code would otherwise be exactly the same.

In strongly-and-statically-typed languages this same process involves considerably more overhead. Before we can select a function to convert a string into a number we must first pick a numerical type and before we can do that we must think real hard about how big of a number we're going to support in this application. Our function signature(s) could also get complicated because, "wait: what type of string are we going to get from the command line?" Something as simple as adding two numbers becomes complicated really quickly!

Comparing the two ways of handling things (strongly, statically typed VS strongly, dynamically typed), Python ends up the clear winner a lot of the time because you got the job done without having to think as much, with less code that's super easy to reason about even though it didn't use static typing.

The other problem is that when you write such trivial programs in strongly, statically-typed languages like C, C++, Rust, etc it requires a lot more mental overhead to look at the code to figure out what's going on/how it works (though with Rust, less so because there's not 1001 awful ways to do things haha).

handsaway• 3 years ago

Before we can select a function to convert a string into a number we must first pick a numerical type

Except this has literally nothing to do with static typing and everything to do with whether or not the language you're using cares about numeric types.

For instance in typescript you'd just have `number` as the type. You could conceive of a dynamically typed language like python where adding a u8 to a u32 would cause a runtime error. In which case it sure would be nice to have the compiler tell you to convert before you called a function.

The other problem is that when you write such trivial programs

If only I had a career writing trivial programs that would make a lot of things easier.

valcron10002• 3 years ago

In Python you have a simple function, `int()` that will happily turn any string consisting of numbers into a proper integer that can be used for math operations.

For starters this is not the case, it does not work on a string of numbers:

       >>> int("123 890 123")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: invalid literal for int() with base 10: '123 890 123'

> Before we can select a function to convert a string into a number we must first pick a numerical type and before we can do that we must think real hard about how big of a number we're going to support in this application

Aren't you doing the exact same thing in Python by picking `int()` over `float()`?

what type of string are we going to get from the command line?

Well, this might be the case for system languages, but most have a single `String` type.

Here is the program you described in Python

    def main():
        n1 = input()
        n2 = input()
        sum = int(n1) + int(n2)
        print(sum)

And here it's in Haskell

    main = do
      n1 <- getLine
      n2 <- getLine
      let sum = read n1 + read n2
      print sum

Accepting a single line of numbers is not much different

    main = do
      nums <- words <$> getLine
      let res = sum $ map read nums
      print res

I didn't think much about it, it's not a lot of code and I guess it's easy to reason about?

globular-toast4• 3 years ago

I agree, for an untested, untyped codebase. Unit tests are more valuable than types IMO.

occz• 3 years ago

Luckily, you don't have to trade off between them, and neither replaces the other.

kakadu• 3 years ago

The embracing of Typescript and type hints pretty much solidifies the case against dynamic typing for complicated projects.

We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.

With python this takes much longer.

dartos5• 3 years ago

Is typescript strong typing though?

I’ve been through several typescript projects where ‘as unknown as any’ makes me wish we didn’t even have typescript in the first place.

If you can’t trust the type system it’s worse than not having one :/

agos• 3 years ago

if you abuse the type system enough, most languages will have weaker typing.

"the language" is not enough per se, you have to use the tools it gives you to gain some advantage: those projects were clearly actively avoiding strong typing, for whatever reason

jrajav• 3 years ago

I, too, find tools hard to use after I intentionally break them.

It's unfortunate that Typescript even provides this casting hack, though it's necessary for gradual, optional typing. The very first thing I would do on such a project is spend the time to fix those broken types, because it will pay back in full in productivity after a short time.

Tade02• 3 years ago

Is typescript strong typing though?

The term "strong typing" doesn't have a clear definition to begin with.

Other terms which it often substitutes do, e.g. static typing, sound type system, decidable type system etc.

master-lincoln3• 3 years ago

apparently the words strong and weak typing have no agreed upon definition so they can not be meaningfully discussed without stating your definition.

e.g. https://perl.plover.com/yak/12views/samples/slide045.html

ng12• 3 years ago

You can write bad code in any language.

chpatrick• 3 years ago

Python is very much heading towards static typing although it isn't as mature as TypeScript yet.

wait_a_minute2• 3 years ago

We have projects in java7 still which span thousands of LoC and juniors can just jump in using their IDE and make some sort of contribution.

This seems to be a main reason certain people like it. It gives a sense of productivity. However I think it is misguided. It’s a false sense of productivity. Can they commit? Maybe, yes. Will it be right? Maybe, and more likely with types to handhold. But does it mean they understand the data model and the domain of the codebase they’re working in? No. No typing forces you to know what your code is actually doing.

It takes longer to be productive, but you’ll be productive because you know what you’re doing. Not because the IDE held your hand.

Widget factories or scrum farms will no doubt like the “ease” of jumping into a codebase that has typing, but I’m not yet convinced it’s better or that much better for the experience developer. I need to think on it more. For certain though I’ve seen enough in my time to know that how quickly a junior can “just jump in and make some sort of contribution” is not a good measurement.

BigJono3• 3 years ago

Dude, duck for cover, lol.

You're 100% right though.

master-lincoln3• 3 years ago

Your argument sounds like a language should make it hard to understand parts of a codebase without understanding the underlying parts as well. I would argue this goes against the goal of abstracting problems to keep complexity manageable.

Of course abstractions can be misunderstood and misused, but is that an argument for not having them?

marcosdumay6• 3 years ago

Nope. A new dev will need a lot longer to understand a large python codebase than a java one.

In fact, if all the developers change, it's a virtual certainty that none will ever understand the python code, while the odds are about even for java.

(But then, the types aren't the only factor for that.)

berkes6• 3 years ago

"Truly understanding what goes on" and "static typing" are in no way correlated, let alone causations.

You are making a false dichotomy.

It's perfectly possible to work in a dynamic codebase without understanding the domain, business, logic or big picture. And it's just as perfectly possible to build a statically typed codebase that forces you to understand the whole entirety before being able to make a change.

Now, whether it's actuallygood to enforce true understanding of the Whole, before being able to work on a subset, is another debate. One that, unsurprisingly, has long been proven to be false. It's why we consider modules, functions, boundaries, coupling, classes, microservices, layers, and so fort and so on.

kerkeslager2• 3 years ago

One might equally say that the embracing of reflection in Java and C# pretty much solidifies the case against static typing for complicated projects.

I'd tend to think the important feature here is strong typing, not static typing, and indeed TypeScript, which is hampered by the anemic type system of its parent JavaScript, it not the best example of strong typing.

Ultimately, strong typing is a hill I'm willing to die on, too. But a lot of people making arguments on this topic are conflating it with static typing, which just isn't the same thing. In general, that gives me the impression you haven't done enough work in enough different languages to really have an informed opinion. The type systems of different languages work within the context of the language as a whole, with tools like REPLs, test frameworks, constraint checkers, static analyzers, and IDEs carrying a lot of the work that might be attributed to a type system. There are a lot of confounding factors here, and if you're only talking about a few languages and you are making mistakes like conflating static=strong and dynamic=weak, you don't have the breadth of experience to understand what the benefits and downsides of strong types are.

Though uncommon, strong dynamic type systems do exist. Scheme is probably the most popular example, although its type system isn't the strongest. This is the approach I'm taking with Fur[1], which attempts to have as strong a type system as possible while still being dynamic. Python is... stronger than many other popular languages (i.e. JavaScript), but still does a lot of coercion (particularly around truth-y/false-y values--duck typing is a bit of a grey area in that it's sort of arguably weak typing, but also arguably indicates a capable type system rather than a weak type system).

But perhaps more critically, weak static type systems also exist, such as C, which is the source of many of the world's most serious bugs. It's highly unwise to assume that static typing is strong typing.

[1] https://github.com/kerkeslager/fur

rdtsc2• 3 years ago

That’s why we like Python and Elixir but not Javascript which is weakly typed. :-)

Since the author is willing to die for it, they might want to know that they probably meant “dynamically typed”. Some dynamically typed languages are strong typed, too!

tasn11• 3 years ago

Author here. Please read the post, I actually said "Strong static typing" in the post itself (starting from the first paragraph), it just didn't look good in the title. :)

rdtsc2• 3 years ago

That’s an important distinction. Why not just use “Static Typing”. Yeah, the word “strong” sounds strong and cool, but since it’s something you’re betting your life on, it doesn’t hurt to be a bit more precise.

dartos5• 3 years ago

Yeah, but your first point is specifically a weakness of weak types, not dynamic types.

I don’t really see any arguments against dynamic typing in there.

Most strong, dynamically typed languages also have good developer tooling (elixir and dialyzer for example) and have built in ways of describing data structures.

js2• 3 years ago

Please add static to the title. Most of the comments are referring to the current title and haven't read the article.

leroman3• 3 years ago

As an extension to this, strong typing is a gateway drug to generics.

Strong typing really shines when you have generics, saving bugs at one level above basic types..

hospitalJail2• 3 years ago

You got me to look up 'generics'.

I like the idea, feels very pythonic ironically. And I suppose if you don't want the generic, I imagine there is probably some subclass of that which is more restrictive.

Anyway, as a developer I love when people do this. As a developer this sounds like a nightmare to maintain. My coworkers have told me to limit the numbers of 'what ifs' and just roll with it.

leroman3• 3 years ago

You can think of generics a meta-language that restricts and documents some behavior one level above the concrete types that you might need.. Lots of benefits, code re-use, documentation as code, less bugs..

Granted it's not always easy and straight forward but that what senior developers in the team are for..

marcosdumay6• 3 years ago

feels very pythonic ironically.

Look at duck typing.

craigmoliver• 3 years ago

I don't care how many times I see this argument; strong typing is correct. We need to keep beating this drum because every year there are more and more new developers that know nothing. We need to make good one that aren't ignorant of history and what works...because the more things change the more they stay the same.

irrational• 3 years ago

I wonder if most opposition (or even ambivalence) towards strong typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it.

randomdata4• 3 years ago

Python is strongly typed. If your entire career has been Python, you will have a lot of experience with it.

Static typing, maybe not so much.

tonyedgecombe2• 3 years ago

I wonder if most opposition (or even ambivalence) towards strict typing comes from never having used it. If your entire career has been JavaScript, Python, shell scripts, etc.; then you have zero experience with it.

@irrational Sorry for the plagiarism.

siva7• 3 years ago

You probably mean static type checking. I've used strong typing in the first half of my career and have no hard feelings about it. So no, the opposition isn't about no experience with one or the other.

ilaksh2• 3 years ago

I taught myself Turbo Pascal in middle school (34 years ago) and C/C++ in high school. (Both typed).

Over the years, I have done programming with C, C++, Java, C#, PHP, Python, OCaml, Lua, Nim, Golang, Rust, Objective-C, Flash, Bash, D, Scala, TypeScript, assembly, PL/SQL, F#, and a few that I am forgetting.

Compile time type checking can definitely make things easier.

But for dynamic languages that I have been programming in for many years to have types shoehorned into them as an afterthought feels like a kludge.

And it's a tradeoff. I got used to developing in Node or Python with vim without auto completion (although I had those things as a kid in IDEs for other languages and they can be great). And without compile time type checks.

You can pass JSON around and literally never do a database migration.

This stuff will lead to more runtime errors initially, but also means more streamlined code. And you have to do thorough testing regardless.

TypeScript might be a choice for a large project with several developers. But I would also argue that an even better choice would be just to use a different language that has the typing system you want built in rather than awkwardly bolted on.

What I see in most TypeScript projects is a half-assed attempt that still results in run time type errors, but with the added "benefit" of an awkward bolted on typing system and the need for more tools as well as losing any dynamic benefit.

They drop the idea of using JSON and make everything related to the database compile time checked if possible. I'm not saying that those checks can't be useful but if are going that route it would make more sense to just drop the dynamic language.

Having all of the dynamism can be a convenience and save you time and effort in other ways. But not if you treat it as a poor man's static language and shoehorn in types in a half assed way using a traditional database.

Part of this is that people think software engineering is about your choice of stack or adding processes to development.

What matters most is probably the feedback loop between the users and the developers. Starting with the requirements engineering. Second to that would be details of the software design and organization. Leveraging existing code effectively can be key. Using descriptive but relatively concise identifiers, short functions, good code organization.

But diving into and evaluating all of that stuff in detail takes effort and a lot of skill and so many make snap judgements based on surface level processes or tool selection.

hospitalJail2• 3 years ago

I think I agree.

Probably the biggest issue with python.

Seemingly random changes between float64 and object happen when doing unit testing(pandas).

Can't remember the exact situation because I switched to While permanently, but there was some For loop problem. If the data came in as length 1, the for loop would read the individual chars of the string. If it came in as >1 it would iterate through the list.

15 years ago when I started python, maybe it made sense. Probably ~5-6 'oof that was a bug I wasted time' in 3 years professional use. Today, I find myself forcing types to solve a bug, or at a minimum checking the types as the program progresses.

nathan_compton2• 3 years ago

Pandas is a particularly absurd library.

falcor843• 3 years ago

Pandas's flexibility is amazing for exploration and prototyping. I'm actually a huge fan of the gradual typing approach, whereby you can start just messing around with stuff in a notebook, and then add the types and the rest of the structure once you are ready to solidify your design.

ledauphin• 3 years ago

yeah, this isn't Python, this is pandas. Run far away from pandas if it's not too late.

dist-epoch4• 3 years ago

If the data came in as length 1, the for loop would read the individual chars of the string. If it came in as >1 it would iterate through the list.

You probably did this:

  for name in ("John"):
    # "J"
    # "o"
    # "h"
    # "n"

  for name in ("John", "Sam"):
    # "John"
    # "Sam"

The correct form for the first one is this:

  for name in ("John",):
    # "John"

reportgunner2• 3 years ago

I don't understand how someone can use pandas if they have a choice to use something else. It almost feels like a language of it's own.

heisgone• 3 years ago

Strong typing is what allowed me to be a developer. I was never a great developer but I was good enough to be worth my salary. I was not smart enough to maintain a complete mental model of a a weak-typed software but I was able to do fairly complex stuff with the safety net of strong typing. My software developer would have ended much sooner (or never have been) without strong types. I had not other choice but to live or die on that hill.

mik1998• 3 years ago

Static typing is useful if you are building some program for other people to run that you want to be reasonably robust. However, it does not work well with interactive programming. If I had to declare all the types every time I do something in Mathematica, I'd be severely annoyed for no benefit.

Common Lisp seems to be the best of both worlds, with dynamic strong typing in general and advanced compiler type inference that can correctly point out mismatched types in most cases in SBCL, leading to much easier time programming interactively.

loup-vaillant4• 3 years ago

You are complaining about explicit typing.

Try ML (OCaml, F#…) or Haskell, they have type inference. No need to declare types most of the time, but they’re there, checked at compile time.

laserbeam• 3 years ago

I work a lot in python. I hate it.

mtreis86• 3 years ago

What do you call the Common Lisp sort of typing where you can drop hints wherever the machine is guessing at the type, and it will yell at you if you do something dumb with those things. But you don't have to drop hints at all and it will still compile. It is strong when you turn it on but dynamic otherwise. Strongly typed with inference, maybe?

ctenb2• 3 years ago

I believe the term is gradual typing?

Filligree• 3 years ago

Gradual typing?

KaiserPro• 3 years ago

Personally I think Strong Static typing is what's required. But with an option to do dynamic typing to avoid faff in certain parts. Strong typing on its own doesn't really solve the problem that the author is describing.

c# pretty much has that nailed. You can do dynamic typing if you want, but you're on your own if it fucks up. Moreover its obvious when you're doing dynamic silliness.

Python is strongly typed, the problem is that its also duck typed and everything is dynamic. Sure there is type hinting, but that's mostly optional and pretty much broken as its not really supported at run time. (unless I've missed something)

What I'd really like is something like perl's "use strict;" in python.

however I don't see that coming anytime soon.

globular-toast4• 3 years ago

I wish people wouldn't conflate dynamic typing with weak typing. Python, for example, is dynamically typed, but it's strongly typed too. You don't get bugs like `1 + "2" = "12"` in a strongly typed language like Python.

You can still get runtime bugs, of course, but that kind of thing would manifest as a TypeError or something. All of those bugs could be caught with tests.

I like dynamically typed languages. They are simply the pragmatic choice for the vast majority of code that will ever be written. But being dynamic doesn't mean you can't do types. Python has optional type hinting and checkers like mypy are very good. Common Lisp has features that enable you to declare types and get near-native speed binaries.

These days I do type my Python code for many of the reasons given in the article, but I still enjoy using a dynamically typed language underneath.

tonyedgecombe2• 3 years ago

You don't get bugs like `1 + "2" = "12"` in a strongly typed language like Python.

That's more about type coercion which you can avoid in dynamic languages. See === vs == in JavaScript.

shafo• 3 years ago

https://youtu.be/Xb0UhDeHzBM

j16sdiz• 3 years ago

I think clojure spec is still typed. It is just not the type other languages uses.

nightwolf• 3 years ago

clojure.spec is explicitly not a type system:

https://clojure.org/about/spec#_expressivity_proof

zabzonk3• 3 years ago

i agree about strongly typed languages, but rather than:

let person1 = new_person();

i prefer the c++ way (which also supports type inference):

Person person1;

bluetomcat• 3 years ago

Dynamic typing is polymorphism at the language level. In essence, you expect most operators to behave sensibly with different types. An expression such as "a + b" resembles a polymorphic function such as "add(a, b)". You would expect it to work fine most of the time, regardless of the types. And the types in a dynamically-typed language usually aren't so many – you possibly have booleans, numbers, strings, lists, maps, sets and objects.

Chabsff10• 3 years ago

The moniker you are looking for is "duck-typing". Polymorphism is tightly tied to the notion of explicit interfaces.

jwilliamson• 3 years ago

He's describing row polymorphism. Only some forms of polymorphism require explicit interfaces.

alexvitkov7• 3 years ago

You're not "moving faster" if a typo is a runtime error and you're not "more productive" if you can't change a function signature without having to grep your codebase to find all callsites and pray you fixed them all.

Types are good, but as with anything else people take it too far. Making it your life goal to encode all business logic in the type system results in an even more incomprehensible mess than not having types at all. If the type name can't fit on one line in the error message, you've gone too far.

ranting-moth• 3 years ago

I've seen some insane Typescript type definitions. To be fair, they were defined to work with historic vanilla JS code where so many things could have been stuffed in the poor variable.

I'm forever grateful for Typescript, but I wouldn't be surprised to see some of that code in a future research paper titled "The era when types went too far".

alexvitkov7• 3 years ago

I'm mostly fine with bad TS definitions since the types are cosmetic and you can always 'as unknown as whatever' your way out of an insane type definition. If someone nests 5 generics in Rust/C++ you'll have a much worse time.

david422• 3 years ago

I've seen some insane Typescript type definitions.

That's just because the code is bad, not because the type is bad.

That's literally just the definition of, this code is so bad, let's just not type it.

globular-toast4• 3 years ago

The first time I saw this pattern play out was with CSS vs table layouts.

A lot of web devs these days don't remember a time before CSS but, back then, we used to use tables for page layout. This was really an abuse of the `table` element of HTML, which was designed to display tabular data, but it was basically the only way to achieve many layouts like having a side menu bar, for example.

Abusing `table` was bad for many reasons, including accessibility. People started to care about the semantic web and remembered that HTML is a markup language for content, not a style language for layout. So people advocated for using CSS for layout and reserving `table` for actual table data.

But gradually this rule became both simpler and more ridiculously followed. People started talking about "using divs instead of table". They would look at a page source and if they saw `div` it would get a nod, but if they saw `table` the developer would be relentlessly abused because `table` is old-fashioned. Eventually, of course, someone reinvented tables using divs and CSS.

And then people realised the pendulum had swung too far.

Double_a_92• 3 years ago

you can't change a function signature without having to grep your codebase to find all callsited and pray you fixed them all.

I really wonder how people can actually work like that. Is there some overarching methodology like super strict tests with 100% code coverage or so?

JonChesterfield6• 3 years ago

Regex find and replace across a codebase works fine, especially if the functions aren't overload sets.

emerongi• 3 years ago

Tools like https://comby.dev/ help with the refactoring itself, but I'm never really 100% confident.

globular-toast4• 3 years ago

You're not "moving faster" if a typo is a runtime error and you're not "more productive" if you can't change a function signature without having to grep your codebase to find all callsites and pray you fixed them all.

I don't see how either of these things relate to type discussions. A typo can certainly lead to incorrect code in the most strongly typed, staticest language there is (otherwise, what the hell is writing code even for?) What's worse: a runtime error or no error that produces the wrong result? Running a Python project might be quicker than compiling a C++ project. Dynamically typed languages can do better than grepping for function calls.

alexvitkov7• 3 years ago

A typo can certainly lead to incorrect code in the most strongly typed, staticest language there is

Yes but the >99% of possible typos (and nearly 100% of typos in identifier names) will be caught by the compiler. That's good enough for me to say "static typing helps with typos".

What's worse: a runtime error or no error that produces the wrong result

From most bad to least bad:

    1. No error, wrong behavior
    2. Runtime error
    3. Compile error
    4. Red squiggly line telling you "this is bad" before you even compile

> Running a Python project might be quicker than compiling a C++ project

Yes, C++ is an insane language. You can have large C++ projects that compile fast, but you have to spend a non-zero amount of engineering effort. Generally "avoid templates" and "write the code in .cpp files, not headers" will ensure that you won't have hour-long compiles.

This is a problem with C++, not with type-checking in general.

Dynamically typed languages can do better than grepping for function calls.

I'd love to hear how, I was doing quite a bit of JS at my previous job (not TypeScript, couldn't convince them :) and I never found a more reliable way to find callsites/variable usages, than grepping for the function name. And even that is not 100% guarentee, since you can call a function in some pretty insane ways,

    anObject[`asdf${some string}`]

and then good luck finding this callsite when searching for anObject.asdf123

vonwoodson2• 3 years ago

You know, I‘d always been like “`from pdb import set_trace: set_trace()` and you can interactively edit. I don’t care what the type is because I can interact with my running program better than a compiler” (followed by intense nerd chortling).

You know, until the program is non-trivial: passing data between systems on a queue; using async, threading, and/or multiprocessing; compiled binary critical-performance libraries… and I’m left wishing I’d written the whole thing in Erlang.

duped• 3 years ago

if you can't change a function signature without having to grep your codebase to find all callsites

Every time I see a developer make this complaint about static typing I wonder what the hell they're doing with their type definitions and architecture where this is actually a problem.

and pray you fixed them all.

If this isn't detected for you at compile/build time you're not using static typing

_dain_8• 3 years ago

The comment you're replying to is criticizing dynamic typing here, not static typing.

Chabsff10• 3 years ago

While I agree with most of the post, it's just the tip of the iceberg of the discussion. Stuff like interfaces, traits, generics, concepts, inference, duck-typing, implicit conversions, etc. all fuzzyfy the notion of "Strong Typing" in various ways, some more than others.

The real discussion is not about types vs no-types, it's about the role and place for each of these bending of the rule and their associated tradeoff in different contexts. Op even takes inference for granted towards the end of the post, but make no mistake, that's a form of weak(er) typing.

For example, writing template code in C++ without frequent use of type inference (aka. auto) can be an absolute nightmare (I suspect that extends to generics programming at large, but C++ is where I have the most experience here), and the legibility gains from making use of it for iterators is broadly acknowledged as being easily worth the obfuscation for scope-limited variables. But there's also a strong case being made to avoid its use entirely in most other contexts.

kagakuninja4• 3 years ago

C++ templates are a nightmare, because it is also a compile-time macro system. The cryptic, giant error messages from forgetting a > were legendary. Maybe this has improved, I haven't used C++ in a long time.

Java by contrast has a greatly simplified generic system; Scala improves on that with robust type inference, making generics pretty trivial to write and use.

Chabsff10• 3 years ago

100% agreed on all points. But even in these languages, writing generics remains greatly facilitated by the use of type inference, which is all I'm saying.

frou_dh• 3 years ago

Trust the science on this.

Wait, I've never looked at it. I guess that's why I used the word trust. Surely it confirms my preferences.

doktrin• 3 years ago

I don't have much to say about the piece itself other than express broad agreeement on what is a fairly common sensical topic, but just gonna say it's interesting how many commenters here are up pontificating on their soapbox while still clearly confused about the distinction between strong and static typing.

hcks• 3 years ago

The static typing hype bubble which started 10 years ago is soon going to burst.

As a falloff expect decades of engineers lamenting overly engineered, overly verbose, overly complex TS legacy apps.

awestroke• 3 years ago

I've never met anybody who prefers JS over TS.

If anything, the dynamic typing bubble is bursting right now.

yakshaving_jgt4• 3 years ago

I prefer JS over TS, and I'm predominantly a Haskell developer.

But then again, I suppose we haven't met.

ilrwbwrkhv• 3 years ago

I prefer how much cleaner JS code is compared to TS. Some TS errors are such an eyesore that I'm reminded of the ugliness of Microsoft.

meiraleal• 3 years ago

I've never met anybody who prefers JS over TS.

It is because the enterprise TS supporters are too loud.

There are many here saying they consider people that dislike TS to be idiots and they don't lower themselves to discuss with those who think JS is preferable.

They don't wanna argue, we don't wanna argue. Life is great.

panzagl• 3 years ago

Have you met anybody who prefers JS over Java?

BigJono3• 3 years ago

And decades of startups created with the next lisp/ruby/python/perl/JS. Sign me up for those. I for one would rather eat a bullet than maintain any of the TS I'm watching people write today.

I don't think we're near the peak yet. We're still on the way up. I've seen $5M projects turn into $50M projects in the space of 5 years and nobody else in my little consulting bubble has noticed at all lol. It shouldn't take 100 devs to build a SaaS with 5 forms and a dashboard but here we are...

ceving• 3 years ago

Guy L. Steele: "Don't you think it is ironic that type theorists who want to talk about strongly typed languages talk to themselves with an untyped language"

https://youtu.be/dCuZkaaou0Q?feature=shared&t=539

ozr2• 3 years ago

There's been innumerable runtime errors, both tiny and world-altering, as a result.

mrkeen4• 3 years ago

No I don't.

Now go and rewrite your dynamic language's runtime in a dynamic language.

hayley-patton• 3 years ago

Gladly!

https://github.com/robert-strandh/SICL (which I wrote a decent chunk of the compiler backend of.)

loup-vaillant4• 3 years ago

There are advantages to not using types, such as a faster development speed

In my experience, not even that. Static typing speeds up my day to day programming.

You touch this point on later with how IDEs can make your experience nicer with static typing, but I see this even with a REPL: statically detected type errors lead to meaningful error message that are much closer to the actual root cause, and let me fix it quicker than a runtime error would have.

It also liberates my brain from having to think so carefully about types. The compiler is disciplined so I don’t have to be. I can move quicker, with the confidence that a huge class of errors will be caught right away.

Static type systems are in my experience easier to use, speed up development, and increase reliability. The costs? So far I’ve seen only two: they may be harder to learn, and they’re harder to implement.

jodleif2• 3 years ago

Some would argue that exactly that thinking is what makes the software cleaner and better- rather than mush-mash that passes the compiler. I.e what I’m saying is that it might be good to be thinking about exactly what you’re passing in, out and why.

tines• 3 years ago

Isn't this the same argument that says that we should all write assembly, because you should have to think harder and really know what you're doing?

AnimalMuppet4• 3 years ago

Of course it's good to think about what you're passing, and why! Nobody disagrees with that.

The issue is, can you think carefully enough, consistently enough, so that you don't need static types? Can your coworkers - all of them? What about future you, and your future coworkers? What about that time that you're in a hurry, or going on vacation the next day, and you're not at the top of your game?

If computers have taught us anything, it's that automatic processes are more reliable than manual ones.

Personally, I just inherited a code base that is a decade old. I haven't measured, but I'm pretty sure that it's more than 100,000 lines. My current coworkers have two weeks longer on the code base than I do. Static types make this a lot easier.

And, if your approach to static typing is "mush-mash that passes the compiler", no, static typing may not save you. But dynamic typing wouldn't, either, with that approach.

ddejohn2• 3 years ago

> There are advantages to not using types, such as a faster development speed
In my experience, not even that. Static typing speeds up my day to day programming.

Completely agreed. It also completely blows past the whole maintainability argument -- the junior developer you hire in 6 months is going to be much slower getting up to speed on your untyped code (using the "royal you" here).

For some, I'm willing to grant that it may be "faster" to write initially, but every developer reading your code written without types thereafter is going to be slower.

strongly-typed• 3 years ago

TIL I am a hill

okeuro49• 3 years ago

I agree, and I think the industry does too. Types are being retrofitted onto languages, like PHP, or added as a superset of the language, like with Typescript.

andrewclunn• 3 years ago

There are so many benefits for a front end application (written in javascript) to just assume it will be the backend that does type validation. A new field column added to a table? Cool, update the api layer, but the javascript just gets "the object" and now you have access to it immediately. No need to duplicate your definitions in both code bases, and it's not like front end security is real anyways. Sounds to me like a lot of "I learned to code in some derivative of C" programmers couldn't possibly consider that different languages could be optimized for different use cases and just want all coding to be "what they're used to." Then they moralize it and use shaming language to push it on everyone else. F typescript. I use different languages for different things, and strong typing makes a ton of sense IN MOST INSTANCES, but certainly not all.

BigJono3• 3 years ago

People are conflating too many ideas. You're right that there's a huge benefit to that, but it's contigent on you as the dev being able to trust the types coming into your system, you need good docs, and attention to detail as you code.

All the TS devs just conflate JS with "no types" and picture drooling idiots that make random changes without knowing the type of anything (probably because that's what they do without 50 IDE popups to guide them). You're never going to convince them of the values of dynamic typing because they have a different mental model of it in their head.

sakex• 3 years ago

Not all type systems are born equal, for instance I'm amazed daily at the lack of type safety in Java/Kotlin

Zambyte5• 3 years ago

I agree with the title, but not with the blog post. Strong typing is great. There is little reason not to use strongly typed systems.

The post adds "static" typing in too, modifying the argument. Dynamically typed languages allow you to easily have a very intimate understanding of your program; because you can write the program and modify it while it's running using a REPL. The post seems to conflate dynamically typed with untyped, which is very much not the same thing. The two are actually incompatible ideas.

OP: I highly recommend you look into SICP if you want a concrete counter argument to static typing for large systems. A main focus of the course is controlling complexity through abstraction as systems grow to be large, and the course was taught using Scheme, which is a dynamically typed language.

pron• 3 years ago

Yes, typing can be a pain in languages that don't support inference, e.g Java can be tedious

Java has had some type inference for almost 20 years, and local variable type inference (i.e. `var person1 = newPerson();`) for more than five.

tasn11• 3 years ago

I had no idea, thanks for letting me know. I'll update the post now.

Java, I'm sorry for swearing at you all these years. :P

tstrimple2• 3 years ago

I've been in the same position. Modern Java is a solid language. Most "enterprise" companies are still using Java 8 or if you're very lucky Java 12, so you really don't have access to all of the modern functionality and because of that I hated on Java for years. Java programming in the wild is a crap shoot at best.

AlchemistCamp3• 3 years ago

I have to wonder if the author has ever used a strong, dynamically typed functional language like Clojure or Elixir or if his dynamically typed language experience is limited to JavaScript, Python and very similar languages.

It’s very easy to make up one’s mind about something and then completely stop learning.

spprashant• 3 years ago

Asking because I am curious to learn, how does a language being functional matter here?

As I understand it Python is also strongly typed, while JavaScript is not.

AlchemistCamp3• 3 years ago

In Python, variables are mutable and being a class-based OO language, there’s often a lot of state that isn’t immediately clear when inspecting nearby code.

By working with immutable structs and pattern matching, you can get many (but not all) of the same guarantees you would from static types.

tomtheelder2• 3 years ago

I have worked extensively in Elixir and it only made me feel more strongly that static typing is the way to go. The sheer mental overhead caused by the lack of typing in Elixir is the biggest productivity killer for me when working in that language, and refactoring is almost as much of a nightmare as it is in something like JS.

For me, strong and dynamic is the worst possible combination. I actually need to be precise with types, but the language gives me no help.

I think Elixir has the best combination of runtime and tooling and ecosystem out there, and it’s type system is the only thing that prevents me from using it for nearly everything.

ddejohn2• 3 years ago

Python is strongly typed

graypegg2• 3 years ago

I still bemoan the half-assed RBS type system in Ruby 3. I think Ruby actually had a cool chance to explore what inline type hints would look like in a very meta-programming-y environment. While RBS works, it's a hassle to keep updated, and I think adoption is just going to remain low forever sadly.

Sorbet [0] is close, just wish the syntax wasn't as verbose as it is.

Crystal Language [1] is even closer, I just wish it had better IDE support.

[0] https://sorbet.org/

[1] https://crystal-lang.org/

berkes6• 3 years ago

I'm worried that the reluctance of the Ruby community to adopt some typing, might push it further into obscuration.

For me, full time Rubyist for over a decade, it was enough to "jump ship" to Rust and TypeScript. It's one more reason to forego Ruby, I fear.

ddellacosta• 3 years ago

"Strong typing" was a poor choice of terminology here.

https://en.wikipedia.org/wiki/Strong_and_weak_typing

stratigos3• 3 years ago

This article might be right in an academic sense. I suggest the author and those who believe similarly that its a "hill to die on" rethink their approach and spend 5-8 years doing professional consulting (do not confuse consulting with staff augmentation). You will indeed die on the hill as a business cannot expect everyone it hires to believe the same thing, and you cannot expect to force anyone to use strong typing properly. In short, while you may believe this is the right path, most folks dont care, and all that remains is an extremely complex, antipatterned, mysterious ball of mud that no one wants to work with because no one fully bought into the concept for which you were willing to die.

mpweiher13• 3 years ago

Well, people have always been fanatical about thing a they are attached to emotionally, rather than rationally.

Fact is: the “types lead to fewer bugs” claim is just a feeling, it is “truthy”.

https://blog.metaobject.com/2014/06/the-safyness-of-static-t...

And it’s not for lack of trying. You might say the claim has been disproven.

That said,I personally like static types, but primarily for the documentation effect that is, maybe not entirely coincidentally, the only positive effect for which there actually is solid empirical evidence.

purpleblue2• 3 years ago

It leads to fewer bugs of a certain type, but there are plenty of bugs being generated in statically typed languages in different ways.

mpweiher13• 3 years ago

The overall bug burden does not change.

Why this is we do not know. But we do know that it is true.

Chabsff10• 3 years ago

"Types lead to fewer bugs when making changes to long-lived codebases" is not up for much of a debate in my opinion. Preventing regressions is arguably a lot more important than writing a correct first pass, which is what you are evaluating when looking at non-evolving code.

Concretely-speaking, an example of a bug being preventd by a typing system: Removing a field from an object in a large vanilla JavaScript project is inherently a minefield that has caused many bugs in the past, whereas the same alteration in a full Typescript project can be made with confidence.

mpweiher13• 3 years ago

It’s no longer up for debate, true.

But not in the way you fervently want to believe.

Once again: people have tried to show the truth of this for a long time, and they have consistently failed.

taeric6• 3 years ago

It... should be up for debate? I'm fine taking it as a given in projects I'm running. But I do expect people that have the ability to do so, to debate it. Preferably to study it and find concrete evidence.

nurple2• 3 years ago

"Types let me make changes to code I haven't taken the time to understand" is hardly the proof you seem to think it it's.

Removing a field in a data structure is such a big problem, even in typed systems, that the most ubiquitous serialization IDLs, and customer-facing API conventions, don't even allow it.

nercury2• 3 years ago

The argument for static types is that it makes type bugs impossible because the types are static. There is no emotional attachment other than rage when faced with "but but it does not eliminate ALL the bugs!!!!!!".

mpweiher13• 3 years ago

Please read the article.

The objection is not that all bugs aren’t eliminated. The objection is that there is no empirical reduction in bugs.

ReflectedImage26• 3 years ago

Type bugs are so rare in regular code that it's significantly insignificant when measured during research studies. From a code correctness point of view, static typing is simply speaking useless.

You should have spent the time statically typing your code on writing more tests.

iopq4• 3 years ago

Heartbleed is not a type error in C, but it's a type error in Rust

Rust has a more powerful type system that actually fixes MOST of the memory bugs in production

mpweiher13• 3 years ago

And you simply can't have that sort of error in Smalltalk.

¯\_(ツ)_/¯

miloignis• 3 years ago

You're making a very strong statement, so we might as well look at extreme cases, namely the formally verified middle-end of CompCert: https://users.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf

I believe this would count as empirical evidence of very strong static typing reducing bugs. I think this points to what many other comments have been getting at, which is that typing is not a binary yes/no question, but a large, multi-axis (static/dynamic, strong/weak) spectrum with lots difference between type systems, as well as big differences in how people apply those type systems to their problem. You could still work in a static, strongly typed language and represent everything as strings, converting back and forth as necessary, but that's essentially working in a dynamically typed language. You could also take advantage of the tools the type system gives you in order to reap the benefits, creating classes representing the legal values and asserting important invariants.

unstruktured• 3 years ago

The author of that link references the top 25 bugs, one (#12) of which is Null pointer dereferencing- static typing outright eliminates that bug.

Not to mention that range checking is also fixable by using optionals rather than assuming the existence of a value.

fnfjfk• 3 years ago

Academic papers are often very disconnected from industry reality.

I’ve worked on reliability at a company everyone has heard of for software that billions use daily. So many bugs would have been blocked by having a type system at all (dynamic languages on backend or JS on web) or by having a less bad type system (changing ObjC to Swift and Java to Kt on mobile). Null pointers/references alone have created so many bugs for us. Bugs that could have been compiler errors.

magicalhippo7• 3 years ago

The fact that strong static types makes the code self-documenting is the reason I vastly prefer it.

It makes me so much more productive, by orders of magnitude. And I say this as someone who has worked extensively in several different languages which covers large parts of this spectrum, like C, C++, Java, Python, JavaScript, TCL and others.

It makes it much easier for me to reason about code I have not recently worked on, be it in the current project or in dependencies. It also means I can be way more focused on the problem at hand, since I'm not constantly having to go on tangent goose chases to figure out what exactly I can do with this object that some function returns.

Sure there's the good, fuzzy feeling when the compile doesn't error out. But that's secondary.

ReflectedImage26• 3 years ago

Statements like: "The fact that strong static types makes the code self-documenting is the reason I vastly prefer it."

is exactly the reason why you shouldn't be use static typing. We have a developer here who doesn't document any of their code and thinks that a good thing. Whereas in the dynamic typing world, they would be forced to use the good practice of documenting their code.

Code is never self-documenting, there are research studies on it.

mrkeen4• 3 years ago

Well, people have always been fanatical about thing a they are attached to emotionally, rather than rationally.

How would you feel if I claimed that you could make emotional arguments faster than you could make rational arguments?

Because that is how this debate feels!

I want the simple rationality of my compiler saying "no" if I try to treat my hashmap like an Apple or a String.

tomtheelder2• 3 years ago

Research on this topic is beyond impossible and should be completely disregarded. You cannot possibly attempt to control for variables sufficiently, and I don’t think even the most fervent supporters of type systems would argue that they are a dominant factor in code quality and correctness.

booleandilemma• 3 years ago

I don't think the opinion is even controversial at this point. Even the hardcore JS developers I know have come around to using TypeScript.

If you can't at least admit to the benefits of static types in 2023 then you probably don't have experience building or maintaining large software systems or working with a team of 15+ people, many of whom you've only met over Slack.

Tade02• 3 years ago

or even worse not enforced even at runtime (JavaScript, I'm looking at you... 1 + "2" == 12).

I'm having trouble taking seriously a post that beats this dead horse.

Sure, it's there. It's even documented in the language specification, but now that we have template literals it's rarely used because truly, what is the expectation when using addition on two variables of different types?

As for static typing:

Grug put it eloquently: https://grugbrain.dev/

grug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and list of things grug can do pop up magic. this 90% of value of type system or more to grug
big brain type system shaman often say type correctness main point type system, but grug note some big brain type system shaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean when say correct

In my opinion static typing is useful and I wouldn't start a commercial project without it. That being said I think it's productive to practice programming in dynamically typed languages, because:

-You avoid the sort of type golf that happens with a sufficiently powerful type system(I regret every use of the `infer` keyword in TypeScript).

-The situation forces you to be radically explicit.

-You can explore situations that would normally be hard/impossible to type.

purpleblue2• 3 years ago

I did C/C++ for the first 15 years of my career. I generally agree that strong typing is better for everyone.

But when I started working with python, I understood the beauty in it. At first I couldn't believe you could have a system running reliably that was being hit by millions of people around the world, but then that's when I fully appreciated the power of automated testing. I came from an enterprise shrinkwrap environment with 1.5 hr dev cycles, so you can forgive me for not understanding CD/CI at that point.

Yes, you can't detect when changes could cause bugs, but that's where testing comes in. Where I worked, we had to have complete code coverage so that every line of code was tested, and we needed to have a very strong automated testing. Using that method of testing, it made it a lot more predictable.

Sure, bugs can leak through, but having worked in C/C++ for so long, I can assure you that static typing only fixes a certain number of bugs, there are plenty more sources of bugs that just types.

So for the record, I like static typing and generally agree with using it, but I also see the beauty and simplicity in dynamic typing like Python and it's not complete chaos and there are ways to mitigate it.

QuadrupleA• 3 years ago

As a developer who's written hundreds of thousands of lines of C++, Python, and JS - I don't know! It's not so clear cut. I'm productive in all off them, although Python mostly wins. I wouldn't write a game engine or a video codec with it though.

JavaScript is inconsistent and weird, but Netscape's legacy long since stuck us all into it.

I can see in a very OOP-heavy style maybe, with huge nested classes, that compile/parse time static typing saves a lot of mistakes - but I've come to see OOP as mostly a disaster, and simple functions and structured data almost always win the simplicity and maintainability battle. And modern language servers / IDEs can catch a lot of typing errors during JS / Python development.

I'm persnickety about a lot of programming stuff, but never had a strong opinion about static vs dynamic typing. Both have millions of successful projects under their belt.

rdedev2• 3 years ago

In python I mostly code in functional style. Even then types helps me a lot. I make a lot of typos or get the order of arguments wrong. Typing helps me a lot here especially when I'm doing ML. The last thing I want is my training code to crash after it spent 30nmins processing the data. I find pythons gradual typing a really good middle ground for quick prototyping and the type annotate functions once they are mature enough

boxed6• 3 years ago

or get the order of arguments wrong

There's a simple fix for that, just do keyword argument only everywhere you can.

For me the hill I'm willing to die on is that labeled/named/keyword arguments are absolutely necessary and most of the usefulness of types is in fact just a shitty version of labeled arguments (god help you if you have a function where two or more arguments have the same type!)

BobbyJo2• 3 years ago

To be fair, C++ is a pretty rough language to be productive in generally, type system aside. GC is the single largest productivity enhancement a language can offer. I'd be way more interested in how Golang, with it's much simpler syntax/types (but they're still static) would compare. Even Java would be better, as, even though it's very verbose, the cognitive load for most tasks is a fraction of C++'s.

kagakuninja4• 3 years ago

My language evolution went C > C++ > Java > Scala

Java was a huge boost, by eliminating the cognitive load of manual memory management.

Scala can be used as a "better Java" with less verbosity, but also adds a number of extremely useful features; Java has slowly added some of them into the language over the last 8 years.

arp2427• 3 years ago

It's really hard, even with Go there are so many more differences than just types.

e.g. in Python/Ruby I had a REPL and used it a lot. Go doesn't really have a good REPL, so I tend to not use it so much. I probably pay some in productivity for that?

On the other hand, I type code like:

  name:=fun("foo","bar");if name=="foo"{fmt.Println(name)}

And write and let gofmt sort it out. You can kind of do that in Ruby in theory (not sure if good formatters exist), but Python is more tricky (and I also think the auto-formatters for Python are bad and often make code worse).

The flexibility of things like Active{Record,Model} in Rails are great, and hard to emulate with Go. People have tried, and it just doesn't fit with the language very well.

Go's simple "just compile to a statically linked binary" distribution model probably saves me time, especially for distributing it to other people.

Probably other differences I can't think of right now.

So between all of that, how do you split out the productivity of "types" vs. anything else?

That's also my problem with the research on this, because you just can't, not really. What you need to do is compare e.g. Python with Mypy vs. without. I don't think anyone has done that(?) And even then you run in to the problems with differences in tasks, differences in programmer experience and ability, etc. which matter because for a lot of these studies n tends to be small.

AdamN2• 3 years ago

You might like this video from WWDC a few years back on protocol-oriented programming (Swift): https://www.youtube.com/watch?v=p3zo4ptMBiQ

revskill• 3 years ago

THere's a trick i often do on my Typescript projects.

To know which other files is using current file, i just add an additional property, then boom, the IDE go red on those files !

Without types, the best you can do is, search, search and search !

1-more4• 3 years ago

This is a whole vibe when working with an ML language. I usually start at the bottom of the call stack and add the property I need to the signature of that function, then I can just follow "hey, you're calling it wrong—where is argument xyz?" errors up to the top of the stack. Classic bop mode.

karmakaze• 3 years ago

I'm also on the side of static typing being beneficial. I would always however consider the case at hand individually rather than reject it offhand because it lacks it. e.g. a complex distributed working system written with say Elixir or Erlang isn't easily replaced with typescript. Not all systems are better with any static typed language than any without.

Once you reach a certain size of developers, add static typing if available, e.g. TypeScript, Sorbet, etc

at_a_remove• 3 years ago

Big yawn. I'm comparatively old and have programmed computers for a long, long time as one of those unfashionable "dark matter developers." What a lot of people see as unassailable truths I see as fads. Just as an example, I've never had to go wild about types. One day I will set aside some time to see if they're worth the overhead, but chances are I will not be a convert.

Only this toolchain will be used because it is the only one that makes sense. Everything will be so much easier if it we just did it in the functional style. Large programming projects can't exist without Agile (I've actually heard someone say this). J++! X Will Eat The World. No comments! Verbose comments! If we got the whole team on this one editor, imagine the synergy. Silverlight will take over the interactive web.

If types turn into a big deal and remain that way say, fifteen years from now, then it is probably a Good Idea But Not Strictly Necessary. Whatever it is people are so bound up about, it is likely that programming used to happen without it.

The only constants we have in programming are variables.

taeric6• 3 years ago

Strong static typing, where most of your data is going across the wire as JSON, is a battle that is largely fought in incoherent ways.

Yes, you should try and use all tools at your disposal. But you should also find that most "data" is far more squishy than you think it is. People don't fall back to phone numbers being strings because they are lazy, they do it because too many of them made the mistake of thinking they could make them a stronger type at some point. Same for names. Or addresses. Or postal codes. All of these things need to be taken from a user, and the only real way we have to do that is by parsing text. And if you make the mistake of making your system so it doesn't store the preparsed text, you are almost certainly going to regret it at some point.

Now, is it best to have a layer that keeps the original user entered text and offers it as a typed set of data to the user in the backend? I certainly think so, but there will be ROI considerations as to how much that matters for your little part.

More, if you are doing evaluations of any heavy sort, you probably want a translation layer to a SAT or other numerical model for calculation. And in that world, the numbers are the abstraction. Trying to do it another way will almost certainly lead to pain. And again, you will do well to have translations from problem to formulation, and from solution space to domain. All of these can largely be helped with types, but far too often the "types" that are focused on are not these.

tasn11• 3 years ago

Author here. One thing that we do at Svix that I alluded to in one paragraph but I should probably have elaborated on further: thanks to libraries like Serde and Pydantic, we actually follow deserialization is validation (is that a term?), which means that we validate all of the JSON data before even creating the structures in our code.

I guess that's similar to the redis example I gave, but it essentially means that even though we get sent JSON over the wire, we validate it fully and when it gets to our code we know it's a well formatted type. So our code can assume an email type is a valid email, an ID type is a valid ID, etc.

taeric6• 3 years ago

Right, but you should also take pains to keep the original. All too often the deserialization/validation can also alter the data. In many places, this is fine, I think. In many others, it leads to a ton of confusion.

Edit: I wrote "but you should", I really should have worded that as "and you should". I am wanting to add to your point, not contradict it.

davedx• 3 years ago

It’s absolutely a term, and the way to go

williamdclt• 3 years ago

deserialization is validation (is that a term?)

“Parse, don’t validate » is a common Googleable idiom

AdamN2• 3 years ago

What I like that you're doing and what I used to do with Python annotations is that you strongly define types for your higher level business logic - which may be encode quite complex formats.

In many ways, your point is correct and kind of difficult to argue against (i.e. I agree!).

What catches alot of people is they say how important types are but then just use 3 or 4 primitive types and never build custom types on top of them so they don't get much value out of those types aside from preventing the absolute worst runtime errors. The real value of types is having lots of them and evolving them over time as your systems and capabilities mature (US street address, US state, latitude, ... the list goes on for any piece of software).

manicennui4• 3 years ago

This seems to be a common practice in Go and I've seen it cause requests to be rejected because one unimportant field is wrong. Were we to do this for truly important requests, like lead traffic from third parties, we would lose a lot of business.

cbdumas• 3 years ago

we actually follow deserialization is validation (is that a term?)

Perhaps you are thinking of this great blog post on the subject https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

lucasyvas4• 3 years ago

This is correct - if it's going to error or panic, it should do it at the boundary, not at a random place in the program. It's also much faster to debug where the issue is this way.

funnymony• 3 years ago

deserialization is validation

I saw similar, catchy phrase: “parse, don’t validate”.

https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

DanielHB3• 3 years ago

In my opinion this is the single biggest benefit of GraphQL, forced validation of data server-side. Sure you can do that with swagger in REST apis as well but nobody ever bothers to do it strictly and correctly.

Technically you can have more complex and custom validation (email is a valid email address) with annotations but the client-side will not have this information.

bluGill6• 3 years ago

You should still use name and address as types not strings, even though when you look deep you discover they are both strings. It is [almost?] always an error to mix up name and address fields and the type system can enforce this.

taeric6• 3 years ago

This is why I said it will be an ROI of where you are. In your javascript just pulling the data out of form fields to send to the backend? Probably not worth it. Somewhere between taking it from the user and processing it? Probably worth it. And sending it to another system? You almost certainly need a translation between your types and theirs. But making a layer that converts between every one of your types to every possible external system? Probably not worth it.

galdosdi2• 3 years ago

Strong static typing, where most of your data is going across the wire as JSON, is a battle that is largely fought in incoherent ways.

Is it really? Map<String,String> is a totally reasonable type to use in certain cases.

taeric6• 3 years ago

Not to most of the debates you will see online. For one, they will be quick to throw that json is closer to Map<String, JsonAtom>, where JsonAtom can be JsonNumber, JsonArray, String, or Map<String, JsonAtom>. Then the clojure/lisp crowd will start to ask why can't they use a myriad of long standing tools that work on lists with this data. (And for more fun, the lisp crowd will point out that json is closer to an A-LIST, not a Map, since they allow duplicate keys... At this point, most of the crowd will rightfully tell us to shut it. :D)

Though, to be clear, I think I largely agree with you. I don't necessarily think typing is a curse. I just don't think most of the typing debates we see online are really telling us much. I'm reminded of a while back when everyone was writing what a TODO app would look like with their favorite abstractions. When, realistically, all applications get dirty after you throw enough users and existing data at them.

nurple2• 3 years ago

The social pressure to love static typing notwithstanding (think less of me if you will), the reason I got turned off by it eventually are the ivory towers that invariably get built up around them. I've spent a decade each building software in both paradigms and I now prefer not to use type systems.

I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend.

The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away. In fact I find that the type system is often a barrier to truly understanding what's going on as it effectively adds a very domain specific language to every project that has to be learned on top of the language itself.

There are methods to solving the problems presented in TFA that are just as robust as using types and which are simple to understand. Can types be used in a simple way? Sure. Are they ever? Not in my experience. I also don't like autocomplete, so take that as you will.

I may just be a grizzled greybeard screaming "the code _is_ the documentation", but perhaps that is born from my deep dissatisfaction with the current breed of get-big-paycheck-chatgpt-said-it's-right devs that are currently flooding the industry.

busterarm2• 3 years ago

I was going to write a response pretty much exactly like yours.

Also, the domain we're in is engineering. There are no single correct decisions and everything is about trade-offs. And that's good because otherwise our jobs would be the first to be automated out of existence. All of the discussion in this thread about people "thinking less of" other engineers for their opinions/experiences is fucking gross.

purplerabbit• 3 years ago

Your bio says “most people are stupid” — how’d you arrive at that conclusion without judging people?

enraged_camel• 3 years ago

> Also, the domain we're in is engineering. There are no single correct decisions and everything is about trade-offs.

Yep. In my experience, hardliners tend to not be great engineers, even if they have decades of experience.

tasn11• 3 years ago

I think you make a good point about the ivory towers and the social pressure being a turnoff for adopting certain technologies. Though I also think this doesn't detract from their potential technical merits. As in, a technology can be both great, and have everyone about it be pretentious.

I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend.

I don't agree with this argument, I think it's akin to saying "I like driving blindfold because it makes me drive slower". You can use linters with limits on line length and number of params if this is a goal for you, no need to go indirect with the restrictions.

I agree that typing is not the only solution, I'm just saying that I think the ROI is massive in types, so I think this should be the first tool people go to. Almost no investment, and a lot of benefit.

I agree with "code is the documentation", I even made a point about documentation in the post, but I argue that typing is part of the code. So "the code is the documentation, and typing is part of the code" is how I'd phrase it.

sodapopcan• 3 years ago

> I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend.
I don't agree with this argument, I think it's akin to saying "I like driving blindfold because it makes me drive slower". You can use linters with limits on line length and number of params if this is a goal for you, no need to go indirect with the restrictions.

I was assuming this is more along the lines of writing clear variables names and writing functions that make it obvious what the return value is.

koonsolo3• 3 years ago

I also don't like autocomplete

You must have a crazy good memory. I switch between multiple languages, and autocomplete lets me easily see what variant of a function this library uses again.

You know everything by heart?

imran-iq2• 3 years ago

I also don't like autocomplete. The reason being that not having it actually forces me to learn the libraries I am using.

You know everything by heart?

You eventually reach that point. Do you still look down to see which keys you are typing?

This is also has the nice side effect of pushing you to use libraries that are stable and have good documentation as you can always reference them if need be.

leptons5• 3 years ago

I also hate autocomplete. It just gets in my way. Autocomplete doesn't really work unless you already know what you're going to code, and if you already know what you're going to write the autocomplete prompt just gets in the way and often messes with keyboard entry of what I was typing. I just switch it off, it never saved me any time and just gets kind of annoying.

digging10• 3 years ago

The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away. In fact I find that the type system is often a barrier to truly understanding what's going on as it effectively adds a very domain specific language to every project that has to be learned on top of the language itself.

This is very interesting and at first blush strikes me as backward. I wish I could sit in your office and see this happening, because I find it hard to imagine and I would love to know what that looks like. (And I have way less experience than you so I'm not saying it can't happen.)

Specifically, I find the domain-specific logic in my field is impossible to grok in dynamically typed codebases, while statically typed ones actually teach the developer what the business logic is.

I may just be a grizzled greybeard screaming "the code _is_ the documentation"

Also confusing to me! In all my experience, static typing is what allows the code to be the documentation. Without it, there's no way to know what properties this object has or why we have a check for this certain property that I thought didn't even exist on this object. (Other than comments - maybe I'm on a weird team but I don't know anyone other than me who leaves comments of any significance.)

spankalee7• 3 years ago

Comments are great, but they should usually explain why, not what.

Good, long variable and function names, along with breaking complex expressions into multiple statements with those nice variables names can help the code itself describe the what of the process. And then static types help describe the what of the types of data even more.

That lets you save the comments for more useful things than an ad-hoc type system, like "// We need to do this because..."

graypegg2• 3 years ago

The social pressure side, I totally get. People get very defensive about this sort of thing, and act somehow personally offended if anyone does the opposite.

I say that as someone that quite likes static types. I don’t care, do what you do!

xedrac• 3 years ago

I had this attitude too until I got sucked into a very large Python project. I now refuse to use Python for anything bigger than a few pages of code. It's so poorly suited to correctness that it takes an enormous amount of test coverage to gain any confidence. And don't get me started on refactoring. After this experience, I suddenly care a lot more what other people use, because it may impact me in the future. Please don't use such languages for big complex "must be correct" problems.

tipiirai4• 3 years ago

I think the social pressure relates to people forcing _you_ to use a language that you wouldn't personally go with. Pretty sure the pressure is highest with TypeScript currently.

spankalee7• 3 years ago

I really don't understand these lines of argument, because they seem to me to be almost entirely backwards.

I find dynamic typing ... acts as a forcing function to writing simple code; simple to read and simple to comprehend.

I find the opposite true. Many super-dynamic patterns are hard to type correctly. Good type systems tend to encourage simpler patters so you get simpler types.

The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away.

Making the red go away is important because the red indicates a problem! This is a lot easier than other ways of discovering the error. Why would you want to discover the error later?

I also don't like autocomplete, so take that as you will.

This is why I'm with commenters who say they don't trust people who are against static typing... I'm extremely suspect of computer programmers who don't want computers to help them program.

zsyllepsis• 3 years ago

Making the red go away is important because the red indicates a problem! This is a lot easier than other ways of discovering the error. Why would you want to discover the error later?

I don't think that's what the parent to your comment is arguing. They are arguing that "making the red go away" isn't the goal, rather that correctness is, and that it's easy to conflate the too when you focus too much on the "red" part, and don't pay attention to the "correct" part.

Worded another way, the mantra of "if it compiles it works" can lead to a dangerous false sense of security if you don't understand the limitations of your type system and what parts of your program is may or may not cover completely.

ransom1538• 3 years ago

When I hit ctrl+save, the code should be instantly ready to test, less than 200ms. Waiting for 30 seconds to see code is an ETERNITY to people that code fast, 1k lines per day. I have been on teams that wait 5m to test code, what a waste. Fast feedback loops in code are critical, just like design, or anything important. Types seem like some weird religion, the people that use them cannot be talked out of it.

splintercell• 3 years ago

I highly recommend you to check out ReScript. Amazingly fast compile times.

Watching typescript teams spent 30 seconds on the recompile is insane for me.

in fact, the whole ocaml family of programming languages are mega fast.

The most important feature of a very fast compile time is that you can load it with types after types and write in your whole mental model, without worrying about your build process slowing down.

jcparkyn• 3 years ago

30+ second compile times is definitely not something inherent to statically typed languages. 200ms is rare, but plenty of static languages manage <5s for large projects and much less for small ones. Not to mention that a good IDE will incrementally check types in well under a second as you type, so the need for frequent test runs is lower.

That said, I agree 100% about the importance of fast feedback loops.

paulmd2• 3 years ago

in my experience dynamically typed languages are slower to compile than dynamic ones. groovy, for example, is massively slower to compile than java (it is something like a factor of 10x in our codebase), and the whole point is literally to give you python-style code velocity.

that's not to say that you can't write slow statically-typed compilers. but the strict syntax tree gives you much faster parsing/etc. dynamic languages can't avoid this either, it just does it at runtime instead.

and hot-reload for function changes/etc is very possible in a similar fashion to dynamic compilers too. And if you add a space or a bracket, because of the parsing problem, you can't even notionally contain that to a single part of the AST, the whole thing has to be re-parsed.

again, not that you can't make a static language compile very slowly, or that any given implementation is necessarily faster. but dynamic languages almost strictly have to do more parsing work, and have to do it more often, over larger parts of the codebase. and that's expected - static languages offload some of this "preprocessing" to the developer!

eyelidlessness3• 3 years ago

I find dynamic typing similar to how unit testing is a forcing function for writing composable code, it acts as a forcing function to writing simple code; simple to read and simple to comprehend.

If this were broadly true for most developers using dynamically typed languages, it would be a very compelling argument indeed. But I think there’s pretty strong evidence the opposite is generally true: actual types produced to document real world dynamic code tend to be vastly more complex than the equivalent functionality implemented with static types from the outset. In the TypeScript ecosystem, DefinitelyTyped is an excellent source of countless case studies. The types they provide are typically definitely not, as you put it, “used in a simple way”. That’s not complexity inherent to the type system, or the type definitions as provided; it’s complexity inherent to the dynamic code they describe.

Equivalent packages which were statically typed from the outset tend to have much simpler interfaces because the types are defined upfront rather than retconned onto existing APIs. That doesn’t necessarily mean their interfaces are absolutely simple, but they’re typically relatively simple by comparison.

I’d go so far as to say that you can’t know how simple or complex an interface is without specifying it. If “the code is the documentation” (which I agree is a great ideal!), then interfaces without code specifying them are under-documented by definition. The further the code specifying the interface is from the interface itself, the more obscured your documentation is.

hparadiz2• 3 years ago

Dynamically typed language have very clear rules. It's not magic. If you know these rules nothing about dynamically typed code is inherently problematic. It's the difference between logic being in the code versus in the run time. You accept hundreds of rule sets built into the run time all the time.

gls2ro2• 3 years ago

But I think there’s pretty strong evidence the opposite is generally true

I could not find good research that will decisively settle this dispute about static vs dynamic. So when you say "strong evidence" what are the sources for this strong evidence? Not asking to push against, I am gathering a list of articles and papers about this topic.

danenania• 3 years ago

I'm fully a convert to static typing and don't think I'll ever willingly do another project without it, but you make a really good point about how people tend to always go overboard with types. I did this early on in a large TypeScript codebase while learning TypeScript, and now I regret it. I'm still far better off than I'd be without static types though.

This also happens with tests. It's easy to get wrapped in testing libraries and abstractions and spend way more time than you need to.

The 80/20 rule applies in both areas. You get 80% of the benefit with 20% of the abstraction. It's usually a mistake to try to go beyond this.

Of any popular language I'm familiar with, I'd say Go is the one that follows the 80/20 rule best. It encourages you to focus on solving the problem rather than leading you down rabbit holes of various kinds, including with types. That's not to say Go doesn't have its issues, but it really is excellent at discouraging over-engineering.

thegeekpirate• 3 years ago

Heh, before reaching your last paragraph, I was going to recommend Go as the remedy to your woes. Glad you've discovered it yourself!

Djeman• 3 years ago

Code can not be documentation by meer definition. Code is written in programming language and documentation in spoken language. So documentation has important function of explaining intention of code in non trivial sections. Of course you wont give explanation of CRUD actions or other patterns you are using but business rules get coded and people reading that code need to know where rules come from and what are expectations either directly in code or by reference. Otherwise you revert to finding origin of code in source control and related task if you are lucky to have that level of tracking.

mecha_ghidorah3• 3 years ago

The argument that it helps inexperienced developers approach the codebase is, IMO, a poor one as it tends to incentivize an iteration loop that lacks understanding and is simply trying to make all the red go away. In fact I find that the type system is often a barrier to truly understanding what's going on as it effectively adds a very domain specific language to every project that has to be learned on top of the language itself.

What? It helps developers inexperienced with a given codebase (not necessarily inexperienced generally), because you can very easily understand the types being passed into functions. You may need to understand why a function is behaving a certain way, so you look at the arguments, if you see a type you don't recognize you can push a button and your IDE will take you to the definition of that type. If you want to you can with another key combination see all the inheritors of that type, and so on. It makes it much easier to feel confident about what one can and can't do with any given object at any given time, which is helpful when one is getting up to speed with an existing breed of architecture.

DanielHB3• 3 years ago

Dynamic types do make people create more dynamic APIs because it is a lot easier to let the parameter be number or string or format-function or bigint, etc

Dynamic APIs are super hard to reason about if you don't have types to ensure you are calling your APIs correctly (function argument A can be number or string, but not formatFunction)

So having static types makes your APIs less dynamic because people are too lazy to type them correctly. Which in general is good in my opinion, making an API dynamic should be done only when it is really helpful to do so.

The other point is null-guards which _some_ (but not all) type systems enforce, null-guards are just 100% good thing.

mhandley• 3 years ago

I wish the languages I use would not only provide static strong typing, but also proper explicit support for units. Automated dimensional analysis would prevent many of the bugs I've written over the years, and there are so many times I've had to think carefully whether a variable is in seconds, milliseconds or microseconds to the point where I always define my own types of these. Or whether a throughput count is in Mbits/second or Bytes/second.

dep_b• 3 years ago

I like a bit of Python or Elixir from time to time but truth to be said there's never a moment I am happy I didn't have types to worry about.

vonwoodson2• 3 years ago

First off, I appreciate the edit. python is strong dynamic typing, for example.

Second, it’s a shame that the author doesn’t really speak to Haskell at all. Knowing that a variable is a `u16` is rarely useful alone, relying on the meta of a variable name, for example, to prevent me from adding `user_age` and `number_of_legs`; they both are unsigned 16-bit `int`s, so the compiler is cool with it. A better type system allows types to hold semantic information beyond the bit-width or archaic and usually unhelpful information for the computer and not the developer. Relics of a past where 8k or RAM was all you could use for your program.

Ironically, the advanced Haskell type system looks more like dynamic typing specifically because the type inference is so good. You can rely on the compiler (or interpreter) to tell you what the type should be, often times allowing for much more flexible types than you’d think possible.

Also, being able to derive classes like Show and Read is amazing.

So, +1 for loving types!

tubthumper82• 3 years ago

I'm sure the author is aware of these - many of the code examples are in Rust which has newtypes and automatic deriving of traits (ex. Display which is the equivalent of Haskell Show)

jillesvangurp• 3 years ago

This debate is a lot older than typescript vs. javascript and dates back to at least the nineties when languages such as python, perl, and others were creeping into production systems. Before that there were already things like tcl/tk and a few other things of course. And of course people were messing around with things like Basic as well.

A lot of the arguments against typing are a bit stale.

- We have transpilers now. Even most javascript coders use a transpiler or at least a minifier. The overhead of a type checker in such a tool chain is pretty minimal. Especially on a modern laptop.

- We have type inference and a few other modern compiler features now. Typing is a lot less verbose in e.g. Kotlin than it is in Java. Java now has a little bit of type inference but it is still pretty verbose in comparison. A lot of the typing is just added by tools as well.

- A lot of languages like python, ruby, and others have types now. And spin off languages that have better typing (e.g. Mojo, Crystal) and preserve most of the original languages perceived elegance. Just goes to show that typing can be done without too much compromises.

ctenb2• 3 years ago

There are definitely uses for untyped languages (or language variants), for example they are much nicer when using a REPL, or for throwaway scripts in environments that are already hopelessly untyped (e.g. the shell).

I think nushell disproves this example :)

kmstout• 3 years ago

I want different things at different times. When I'm first exploring a problem space or figuring out an approach or fooling around in a REPL, dynamic typing is great. In those circumstances, the ability to quickly test (and reject!) ideas is critical, and I don't usually find static typing worth the friction. On the flip side, when I'm working on something longer lived or mission critical, it's important to set the maintenance brigade up for success. That means, among other things, useful doc strings; detailed and informative design notes; and type declarations with the right level of specificity.

Of course, the coin has a thin edge where the situation is a bit of heads and a bit of tails. Count me a fan of gradual typing.

feoren5• 3 years ago

We want to identify and fix problems as early as possible; ideally, before we even write them. Problems cost exponentially more to fix the later you catch them, and the damage they can cause only grows with time. Static typing lets you identify problems earlier than dynamic typing, full stop. In fact I'd rather have strong static typing and 0% test coverage than dynamic typing and 100% test coverage -- in the latter case, I'm catching problems much later, and I have the maintenance burden of all those tests, 70% of which are only there to catch what static typing would have already found.

The best mix for me is to lean heavily on the type system and only lightly on tests, trying to write code that is simple and "obviously correct". Obviously-correct code has already had its problems ironed out in the first 6 or so bullets below, and there is very little room for further bugs to hide. Of course even "obviously correct code" can actually have bugs or be subtly incorrect -- a better definition is that any surprises in such code would also be surprises to the tests. The tests are nothing more than mirror images of the code, and therefore are not helpful or necessary. Static typing helps me think about the problem clearly, and helps me write "obviously correct" code.

Here's my working list, in order of preference of when I'd like to find the problem. Every time you drop down this list, the cost to fix the problem gets multiplied by some small factor ~1.5 to 3.

- Initial ideation ["Facebook for dogs? That idea sucks."]

- Requirements analysis ["That's not actually how we calculate that metric."]

- Conceptual system design ["Wait, these parts don't fit together like that."]

- Low-level design ["Crap, a loop won't work here, I need a different flow."]

- Brain-to-fingers typing ["Whoops I almost typed 'elesif'"]

- Immediately post-typing [Red squiggly line under 'elesif']

- Re-reading ["Wait that should be i-1, not i"]

- Compile time ["SYNTAX ERROR: Unknown identifier 'elesif'"]

- Unit test time ["Assertion failed: expected 7, got 8"]

- Code review time ["You didn't handle the case where N is negative"]

- Merge / integration test time ["Oh crap, David's commit broke my commit! How the hell do I merge this?"]

- Internal manual testing time ["You need to tighten up the graphics on level 3"]

- Production ["The users say the application keeps crashing when they run this report! Fix it!"]

- Years later/never ["It turns out that the analysis code we've used for the last 10 years had a major bug in it the whole time and we've been giving wrong numbers to a regulatory agency that has the power to shut down our company."]

boxed6• 3 years ago

Problems cost exponentially more to fix the later you catch them, and the damage they can cause only grows with time.

Citation needed.

This is ENORMOUSLY context dependent. Enough to invalidate the entire point.

My day job is writing code that runs on a server I control. Mistakes there are super cheap to fix. I get a nice crash in sentry with stack and variables for all frames, I fix it, deploy. Done.

If I was shipping code to Mars, well that's the opposite situation.

CONTEXT MATTERS

feoren5• 3 years ago

> Problems cost exponentially more to fix the later you catch them, and the damage they can cause only grows with time.
Citation needed.

Really? Isn't this one of the most clear and repeatedly demonstrated facts in all of software engineering? We don't have a whole lot of clear-cut demonstrable facts in this industry, but this is absolutely one of them.

How about this 2002 NIST report, Table 1-5 on page 1-13 is "Relative Costs to Repair Defects when Found at Different Stages of the Life-Cycle" and shows 1X at "Requirements", 90X at "System Testing", 440X at "acceptance testing", and up to 880X at "operation and maintenance".

(Warning: 300-page PDF)

https://www.nist.gov/system/files/documents/director/plannin...

You can find thousands of people saying the same thing from their personal experience with a quick Google. On the list of uncontroversial statements about software engineering, this is right at the top. Is our discipline so immature that we can't even agree on this extremely basic fact?

Another (okay, they don't say "exponential" here, or try to quantify it at all):

The cost of finding and fixing bugs or defects is the largest single expense element in the software lifecycle. ... The earlier in the development lifecycle defects are found, the more economical the overall delivery will be.

The Cost of Poor Software Quality in the US: A 2020 Report, Consortium for Information & Software Quality

https://www.it-cisq.org/cisq-files/pdf/CPSQ-2020-report.pdf

My day job is writing code that runs on a server I control. Mistakes there are super cheap to fix.

That's good to hear, but mistakes caught before they get to your server are even cheaper still. Perhaps your exponential factors are smaller than NASA's, but it still clearly costs you much more to fix a problem that made it to your production server (and possibly impacted your users) than to fix it immediately after typing it because your IDE showed you a red squiggly line.

syndicatedjelly4• 3 years ago

Does mypy for Python offer a complete solution to introducing static type checking to Python? What is mypy missing that a language with strong static typing has?

cmrdporcupine2• 3 years ago

It's interesting we've gotten to this place where the discussion happens like it is on this forum, where acceptance of strong static typing is pretty high.

10 years ago the bias was strongly the other way. And in many shops I've worked in, there was an intense hatred of having to declare types.

I like to think it's the development of better/smarter type systems in mainstream programming languages (vs say Java which is what was dominant then), as well as maybe maturing of software engineer practices.

But I also fear it's just the trend-pendulum ticking.

That and I notice a lot of Python jobs out there, which is an ecosystem I've kept away from for the last 10 years precisely because my professional experiences with large dynamic-typed late-bound Python codebases was terrifying. Beyond NumPy & ML related projects, I fear that this might be indicative that the "types are just getting in my way" crowd is still very influential...

Finally I also think it's important to distinguish two concept that get mixed up -- type vs binding: static typing vs dynamic typing and early-binding vs late-binding. It so happens that most languages that emphasize static typing emphasize early-binding, and vice-versa; but it's entirely possible to have very strong types but still introduce sloppy late binding decision behaviour that ends in all sorts of runtime exceptions. Java is/was notorious for this. Reading configuration files to drive application behaviour, or doing things like the Rust Axum framework's "axum::extract::State" stuff, which can blow up at runtime; they're not strictly type issues, but get mixed up in some of the things people are talking about here.

syndicatedjelly4• 3 years ago

What were the arguments back then that supported the opposite bias?

cmrdporcupine2• 3 years ago

"Move-fast & break things." "Test-first-design & aggressive unit testing is the solution."

To be charitable, perhaps that the type system was getting in the way, physically of what they wanted to accomplish conceptually.

I actually think it has more to do with object-oriented programming as it was propagated through C++ and Java. We were told (and believed) that OO abstractions would solve many software complexity problems. The focus of a lot of programming work was/is on bringing these OO design patterns into play. In large part the OO thing is about a kind of dynamic dispatch. And yet languages like Java imposed a very rigid way of doing OO, and made some of the patterns awkward to express.

So if you believe in your heart in the promise of OO, but find that your OO experience is relatively handicapped by your static type system, one then blames the type system. Ruby was maybe the best example of where this line of thought was going/coming-from?

I think we are getting past this by getting (somewhat) past OO as a dominant design methodology. But also by adopting languages with richer static type systems.

Luctct• 3 years ago

Is that a promise? Are you people really going to die? How soon? Any chance you die by the end of this week?

dang3• 3 years ago

Hey, could you please review https://news.ycombinator.com/newsguidelines.html and use HN in the intended spirit? You broke that badly with this post, and we're trying for something else here.

mcv3• 3 years ago

I just had a moment today. I'm developing a front-end thing in TypeScript. I'm messing around with dates across different data types (date string, Moment, a Neo4j-compatible date type, and Javascript's own Date type). Real fun, as you may understand. Struggling to convert a specific type straight to a js Date, I decide to just `new Date()` and add all the fields I need. `jsDate.setMonth(convert(otherDate.month))`. Red squiggly line appears underneath. I first realise it's a js Date, so I add a -1: `jsDate.setMonth(convert(otherDate.month)-1)`, and the red squiggly line disappear.

I feel a moment of horror. Type coercion. In front of my very eyes! I quickly added proper conversion everywhere.

I have no problem with dynamic types, but type coercion is the devil.

bjourne9• 3 years ago

The discussion over whether strong typing is better than weak typing is settled [1], but not over whether static typing is better than dynamic typing. Adherents of static typing thinks that the compiler should check "correctness" by verifying type invariants, adherents of dynamic typing think that is a waste of time.

I'm firmly in the latter camp. Because the compiler can't check program correctness only type correctness. Type correctnes is necessary for program correctness, but NOT sufficient. Static typing adherents fail to recognize this, thus falsely believing that static typing guarantees them more than what it actually does (blub).

Consider the article's birthdayGreeting example. Author is happy that static typing catcges the birthdayGreeting("John", "20") bug because "20" is not a number. But birthdayGreeting(" ", 123) is not caught (" " is not a name) and neither is birthdayGreeting("Anna," -12335). birthdayGreeting("Anna" 4.5), though, is caught, which arguably is wrong since 4.5 is an age.

This is actually very important since "type bugs" are trivially easy to catch, while "semantic bugs" can stay undetected for years. An account balance stored as a uint that overflows, a number that must be prime at a certain program location, but isn't, a list that must not be empty, etc. No, not even dependent types can guarantee these invariants.

If you don't believe me, read up on some catastrophic bugs. Those that have caused space ships to explode and cars to crash. To the best of my knowledge, not a single one has been caused by bona fide type errors. In the overwhelming majority of cases, the root cause has been a semantic error.

[1] - Most people don't understand that typing is measured over at least two axes, strong/weak and static/dynamic, and continue to conflate weak typing with dynamic typing. C is statically typed and weakly typed. Python is strongly typed and dynamically typed. Javascript is weakly typed and dynamically typed.

scarmig• 3 years ago

In principal, at least, you could encode all those constraints in the birthday example into the type system. In practice, no one does, partially because existing type systems aren't ergonomic enough to express those constraints for developers to want to use them.

tasn11• 3 years ago

Consider the article's birthdayGreeting example. Author is happy that static typing catcges the birthdayGreeting("John", "20") bug because "20" is not a number. But birthdayGreeting(" ", 123) is not caught (" " is not a name) and neither is birthdayGreeting("Anna," -12335). birthdayGreeting("Anna" 4.5), though, is caught, which arguably is wrong since 4.5 is an age.

Author here. I think your examples illustrate my point rather than provide a counter example.

I mentioned later in the post that we validate when creating the type (from e.g. user input) so we know that the `Name` type is always valid (and " ") is not a name. So the type ensures that we have a valid name. So this will definitely be caught in our codebase.

As for birthdayGreeting("Anna" 4.5) and birthdayGreeting("Anna," -12335), number means a float in JS so it actually would be valid, though admittedly I had full integers in mind when writing this. Another example of where stricter typing than what TS providers (which Rust does!) would have helped better define the invariant.

So in short: the problem in the code there was that I was trying to show a simple example, which means I didn't define all the types as strictly as I normally would have, and it surfaced more bugs that would have been caught with types.

eyelidlessness3• 3 years ago

Many of your examples could definitely be caught by static types, depending on the type system. But that’s less important than…

This is actually very important since "type bugs" are trivially easy to catch

This, IMO, is exactly why I’m in the static type camp. It’s so trivial that you can do it declaratively, inline with the code it’s testing, with instant feedback, at every call site and in every downstream expression/statement. A type annotation doesn’t mean my semantic/domain logic is sound, I still have to test that. but it could replace dozens of trivial tests orthogonal to the logic I care about… tests which, let’s face it, few people are going to write exhaustively otherwise.

perrygeo2• 3 years ago

The amount of runtime checks and/or tests required to emulate the guarantees of static types is huge. It's perplexing that some people would rather do that manually.

But to the point of triviality, static types tend to lull developers into a false sense of security. There are limits to their usefulness. You still need both runtime checks and test-time assertions for your logic. You just need less of them and they provide more value per line of code. But I've never seen a type system capable of expressing the entire problem domain in an ergonomic way. Not even close.

For my money, a combination of: static types, property-based testing, unit/integration tests, and an end-to-end test against prod are all required. You can compensate for the lack of one by putting more effort into another but you're really just shuffling the "correctness burden" from one place to another. I like static types because it makes the rest of testing easier. But at some point, you've got to roll up your sleeves and make sure it works IRL.

alpaca128• 3 years ago

Because the compiler can't check program correctness only type correctness

How is this evidence for it being a waste of time? No solution is perfect yet many are worthwhile.

kpozin• 3 years ago

read up on some catastrophic bugs. Those that have caused space ships to explode and cars to crash.

One of the most famous type errors in recent history did in fact crash a spaceship.

https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_o...

MayeulC• 3 years ago

Those that have caused space ships to explode

It's funny you should mention this, as it immediately brings [1] to my mind. This well-known incident was due to type-checking, with acceptable ranges defined ahead of time for some types (which resonates with your comment: make birthdayGreeting accept ranges 1-150 or something, easy to do in ADA).

There are a few more well-publicized issues with spacecraft that could have been caught with better type-checking, including metric/imperial conversions (why not build the unit into a type? Though the fault probably was with integration testing for [2]).

Of course, you are right that type checking can't find every code issue (especially algorithmic), it doesn't replace tests. Instant feedback and type hints are invaluable during the development phase, though.

In your example, one could probably replace the first name string by a person type/object, by the way.

[1] https://en.m.wikipedia.org/wiki/Ariane_flight_V88

[2] https://en.m.wikipedia.org/wiki/Mars_Climate_Orbiter

bjourne9• 3 years ago

Neither of those were "bona fide type errors". The fact that both errors ocurred while using statically typed languages shows that. The orbiter failed because inches were interpreted as centimeters. But as both datums were stored as floating point numbers, which they always would be, in any reasonable implementation, static typing wouldn't have caught anything. The Ariane failure was due to a cast of a double to a short resuling in an overflow. Again, not something static typing can catch because it can't statically check the value of an arbitrary double.

No, even more types is not the solution. It's not pratical to wrap every measurement in a Meter or Inch type (standardization is one issue, is my Meter type the same as your Meter type?) and it doesn't significantly increase the amount of invariants checked. You still have range issues and you still won't get a statically check PrimeNumber type.

I'm not familiar with ADA, but VHDL has similar range constraints which are runtime checked.

suby• 3 years ago

You didn't provide an argument for why static typing is not worthwhile, merely that it won't solve all of your problems -- thus, you concluded, dynamic typing is better.

Yet static typing does very much catch issues, so I really don't see where you're coming from with this.

bjourne9• 3 years ago

If I'm being generous then maybe 5% of my developer time is spent chasing type errors. And then most of those "type" errors would be errors that no reasonable type system would have a chance of catching - like keys missing from associative arrays. I'm competent enough to not need the compiler to tell me banalities like that age is a number or name a string. The overhead of having to deal with types is many times larger than those 5%.

digging10• 3 years ago

I don't understand how you go from "this tool only does 90% of the work I need it to" to "I'll do the whole thing by hand" instead of "I'm fine doing 10% by hand".

freilanzer9• 3 years ago

Because arguments like these don't make sense in the first place. "The compiler won't let me compile my code in a static language after changes" does not mean that the compiler in a statically typed language is a hindrance but rather that the same program in a dynamic language has the same structure, but it's hidden and not checked. In other words, the compiler is a safety harness for those factors it can check - even if it cannot check for semantic errors.

sanderjd4• 3 years ago

The specific examples you chose to illustrate this point are interesting, because to me, it is clear that what you want is a `Name` type that always represents a valid name and an `Age` type that always represents a valid age. Then you can put the validation in a single place (the constructors of those types) and write many methods like `birthdayGreeting` that can happily use values of those types without needing to take on the responsibility of validating them.

I honestly don't know of a good way to implement this pattern without type checking or at least optional type hints and static analysis. Instead, you can do validation of the input values in every single method, which is hugely burdensome, or you can assume callers are passing you valid values and write tests to make sure it isn't too catastrophic if they don't. I don't find either of these solutions satisfying.

mrkeen4• 3 years ago

Thanks for mentioning blub I guess.

If you program in a dynamic language, then you have no choice but to perceive all bugs as runtime bugs. Because every bug you witnessed was a runtime bug, so why would types have helped you?

When I program in a typed language, the compiler rejects programs I write all the time. Things like: putting code that can't be rolled-back in the middle of a transaction.

marwis2• 3 years ago

How does [1] in any way support the claim made in first paragraph?

mecha_ghidorah3• 3 years ago

I'm firmly in the latter camp. Because the compiler can't check program correctness only type correctness. Type correctnes is necessary for program correctness, but NOT sufficient. Static typing adherents fail to recognize this, thus falsely believing that static typing guarantees them more than what it actually does (blub).

Uhm. What? I'm a static typing proponent and I have never believed that the compiler will guarantee program correctness. Nobody believes that. They believe it largely eliminates a certain category of error, which it does. You're entitled to your opinion on dynamic vs static typing, but this particular point of yours is just a wild straw man

arp2427• 3 years ago

I'm firmly in the latter camp. Because the compiler can't check program correctness only type correctness. Type correctnes is necessary for program correctness, but NOT sufficient. Static typing adherents fail to recognize this,

That's just not true. Absolutely no one claims that static typing guarantees correctness, because that's ridiculous and obviously nonsense.

incomingpain• 3 years ago

I learnt to code in C. I know strong static typing.

I now program exclusively in python. I am never going back.

I have tried and do have some of the

def hello(world: str) -> str:

But to date I have not found a single example where this was useful at all. In fact, I found some odd cases where it's harmful.

No typing for me thanks.

michaelfeathers• 3 years ago

I always have trouble with takes like this because they are context-free. There are a wide variety of project types and development scenarios.

My nuanced take is that typing is an economic choice. If the cost of failure (MTTR and criticality) are low enough it is fine to use dynamic typing. In fact, keeping the cost of failure low (if you can) gives you much more benefit than typing provides.

Erlang, a dynamic language used to create outrageously resilient systems, is a great example of that for the domains where it can be used.

I'm not a dynamic typing zealot (I like static typing a lot) but I do think that dynamic typing is unfairly maligned.

The cost argument brings the decision down to earth.

waffletower5• 3 years ago

I think there is strong religious orthodoxy surrounding static typing in computer science, and this article reflects this religiosity. Strong typing proponents often fail to acknowledge alternative beliefs which assert that strong typing paradigms can be less effective and efficient than dynamic typing for many software development contexts. Rich Hickey, the creator of Clojure, is a fairly prominent counter-voice of this debate and provides some interesting context in this presentation: https://www.youtube.com/watch?v=2V1FtfBDsLU&t=2227s

bluGill6• 3 years ago

The problem with strong types is how strong is right?

If you have a truck with a 1000 liter tank on the back the type for the contents liter, or is it something liters_H2SO4 - if you only need to go to a gauge liter is good enough, but if you are doing anything else you do not want to mix the contents up with liters_H2O. Note that is is very likely you will want to have both in the same program in different areas! Of course we can take the tank out of the truck and replace it with a box of iron - so maybe we need an even more generic type that could be either liters or kg?

davepeck• 3 years ago

Back in the early 2000s, when I was a wee new SDE at Microsoft, there was a shared whiteboard down the hall from my office on which someone had scrawled:

"STRONG TYPING IS SO 90s!"

That missive stayed on the board for over a year. I still think about it from time to time and remember that the tech world's pendulum is always in motion.

Today? I adore TypeScript and I'm pretty excited about the PEP 695 QOL improvements to type annotations in Python 3.12. Where types and tools are concerned, we're in a much better place today than when Nirvana was still the next big thing.

But I won't be surprised at all if in another decade I see "STRONG TYPING IS SO 20s" marked on some corporate whiteboard in Redmond. :-)

t435622• 3 years ago

I also don't want to get into a debate about something where there's no chance of changing an opinion. An absolute position is like a religion - it's the desire for everything to be simple, for the removal of doubt and the need to think about each situation on its merits.

I remember taking a badly written Python project which was difficult to work on because it took hours to run and could fail at the very end due to a syntax error or other trivial kind of mistake. I needed some way to make it less difficult to change so I could change it to something good. I tried applying type hints because I thought this had minor impact for potentially some gain. In this case it didn't and what helped was to take every tiny bit that was unit-testable and make a test and then to mock the part of the process that took all the time (it was an android build system so I mocked the android build). Every bit of refactoring-for-testability made it easier to do the next bit.

So to me I feel that writing tests has more value than any other activity - I'm ready to use types when it makes my IDE work better and when I think it stops me making a mistake I've made before but for my money tests deliver more and I will rather work on them than trying to build an elaborate type system that models the problem well enough to prevent one from doing invalid things under any circumstances. For me, the types/classes I create are there to make my program understandable and manageable as it gets bigger.

I find it useful to be able to choose where to put my effort. When I worked on Java long ago I found the type system of the JDK libraries horrendously overdesigned and hard to use - flexibility is sometimes bad if you don't gain from it but are forced to pay the price anyhow.

kagakuninja4• 3 years ago

Python is an example of adding types after the fact. I don't know the specifics of your situation, but gradually typed languages do not offer the same guarantees as languages that have static type checking from the beginning.

Replacing types with tests adds giant amounts of boiler-plate code, for little benefit.

t435622• 3 years ago

My experience is that tests model the expected behaviour and that type systems cannot. Therefore I get lots of value out of tests where types are an impediment.

Static typing from the beginning just sets me into a big design up front problem where I try to anticipate the flexibility that I will need and I start building lots of boilerplate abstractions that end up never being used or restricting me later.

I find it useful to write imperfect code with only the constraint that it is testable and then revise the structure and any types I need as it becomes evident that they are valuable in the context.

ranger207• 3 years ago

Dynamic typing is fine for exploring. If I'm trying out a new API and don't want to look at the documentation every 30 seconds (or more realistically the documentation is terrible) then writing a simple service in Python is a great way to gain experience. Someone mentioned Julia; I think that most of the stuff you're going to be doing with Julia is exploring so it's fine that it's dynamic. But, for anything actually intended to be used, all the advantages of strong static typing come into play. The problem arises when people start out exploring a problem with a dynamic language, get something working, and then try to expand that dynamic program into something production-ready.

pphysch• 3 years ago

I have come to believe that static typing zealots haven't worked seriously on a large variety of (shipped) software projects. I certainly was one when I was in school.

Static typing is a good choice when the system you are implementing is already defined. It's great for implementing a well-defined algorithm or protocol, or a well-studied domain like game engines or financial exchanges or rocket ships. Basically, wherever correctness is necessary and possible.

Static typing is a bad choice when the system you are implementing is largely undefined, or actively evolving. That is, "the rest" of the software, where "software correctness" is undefined. Which includes things like a business, a new video game, a website, and scientific research. Because you will waste time building an ontology of types that can't possibly be known at the time, or worse, constrain the natural evolution of the project.

CS students often get a warped perspective of software, where everything is well-defined by their professor or some textbook or RFC or some other smart bloke, and they just have to implement it. In reality, the average software project is not this way.

The end result is Enterprise Java (formerly C macro hell). You get a bunch of CS grads who think static typing is the only answer working on some fuzzy business logic with Java. The conclusion is an unspeakable monstrosity of bad abstractions (and job security).

EVa5I7bHFq9mnYK• 3 years ago

Hmm, just a few years ago, before typescript, the prevailing wisdom was that types are dead, this is a brave new world out there, just need to create more unit tests.

DevKoala• 3 years ago

The best engineers I’ve met are business objective driven. Strong vs dynamic typing is often a secondary concern. I understand the arguments for each approach, but I’ve never understood those who are dogmatic about their preferences.

xeckr• 3 years ago

I gave TypeScript a shot on more than one occasion, and it always ended in frustration after I inevitably encounter some obscure ts(42069) error that I have to research, then find out that a compiler bug is causing the error, and then get told "it's fine, just add @ts-ignore to the top of the file! See, your code works now!"

hangonhn2• 3 years ago

Does anyone here know how Standard ML inferred types? I really loved coding in SML and its strongly type checking system. The amount of bugs I produced was noticeably less. What I'm wondering is why we can't use a similar system as SML to infer the types. Other languages haven't adopted a similar system so there must be some kind of trade off. What was the downside?

valcron10002• 3 years ago

Look up 'Hindley–Milner type system'. AFAIK, one feature that break this system is subtyping which is very common in many programming languages.

nyssos9• 3 years ago

You can't do full nominal subtyping, so no high church OO, but you can add subtyping for records without too much trouble.

mrkeen4• 3 years ago

What I'm wondering is why we can't use a similar system as SML to infer the types.

We can and do! Use SML!

People just don't find out about the good type systems because the market is crowded out by mainstream shit.

And people write pieces about how good this shit is: "I was going to add an Int to a String but the compiler stopped me! Less [sic] bugs!". With arguments like that, why would you switch camps?

Or sometimes you get fed shit and get told it's inference: "I can replace the first word on the line with 'var'!".

So what are the downsides?

Inference doesn't play well with inheritance or mutability.

If you read Effective Java and see the points about avoiding mutation and inheritance, then these downsides may very well seem like upsides to you.

Why did you stop coding in SML?

hangonhn2• 3 years ago

SML has never been used in any of the jobs I've had. I definitely have a very functional programming bend to my preferences. The closest I've come to doing something like SML for work is to use Clojure.

nyssos9• 3 years ago

Does anyone here know how Standard ML inferred types?

SML uses Hindley-Milner (with some modifications to support imperative code). Many statically typed functional languages descend from it: Haskell and OCaml are the most prominent.

Other languages haven't adopted a similar system so there must be some kind of trade off. What was the downside?

If you're asking why existing popular languages don't adopt it: they can't. HM type inference requires a HM type system, and they've committed to a different one. At best you could get good inference on a HM-typed fragment within the language (though even that would mean making a lot of painful tradeoffs) but it would break down the moment it made contact with existing code.

If you're asking why HM languages didn't become more popular? Historical accident, in my opinion. I don't think it has much to do with the type system, given how fundamentally awful Java's is.

beders• 3 years ago

The author is basically wrong on all the points. I used to think like that for decades, but in recent years changed my mind completely.

Types lead to less bugs - nope, maybe marginally, but not significantly (see research on that)

Types lead to a better development experience - nope, I have all the definitions and vars in my REPL and so has my IDE. I get completion on all symbols, I can look at call trees, usages, refactor things with confidence, run functions in isolation, replace them, wrap them, all from the REPL and inside my application.

We encode everything in the type system - you can't. You need to do runtime validation.

And good luck untangling your type definitions when your requirements change. That one is the killer. Static types are premature concretions on the domain data model as you understand them now. They will change and if you are unlucky you will have to support multiple different variations of domain models in the same runtime. Good luck with that. Especially if you use inheritance.

Granted, static types give compilers great leverage to optimize code, but, wouldn't you believe: there are dynamically typed languages that have static types as a la card add-on.

But for many, many use-cases, especially enterprise development, a dynamically typed, immutability-first, functional language pays off dividends in the long run.

The categorical error that is made by many strong typing fans is that they assume you would write the same code - just without types. Well, you don't.

jjnoakes3• 3 years ago

I have all the definitions and vars in my REPL and so has my IDE. I get completion on all symbols, I can look at call trees, usages, refactor things with confidence, run functions in isolation, replace them, wrap them, all from the REPL and inside my application

This is great, but it only works if you are executing the code that you want to inspect/complete/refactor. In my experience, that just doesn't scale well.

You need to do runtime validation.

Type systems don't eliminate this, sure, but when used correctly, they _drastically_ reduce it, which is extremely useful.

And good luck untangling your type definitions when your requirements change.

That's the best part - the compiler tells me exactly what I have to fix to get things working again. If I do the same thing in a dynamic language, I have to track things down myself, wait for unit tests to fail (hopefully I have 100% coverage...), and pray that there isn't an escape.

sanderjd4• 3 years ago

It's an inevitably frustrating debate because everyone has just drawn totally different conclusions from their experiences. For pretty much all your points, my conclusions are the exact opposite. (Except for "You need to do runtime validation" - of course that's true; but you absolutely can avoid doing most runtime validation.)

Just to take one somewhat at random:

And good luck untangling your type definitions when your requirements change.

I think it is exactly the opposite of the case that static types make it harder to adapt to changing requirements. In every dynamically typed system I've ever worked on, there have been important assumptions about data structures - sometimes checked dynamically in pre- or post- conditions, sometimes only checked in tests, and often simply not checked at all - scattered all around, such that changing requirements necessitated reasoning through the impact of the change on all these implicit assumptions. It was terrifying to make changes. Sure, easy to make a change and start up the application with the new code without a fuss. But to know whether the change broke some obscure codepath I hadn't considered or been aware of? Very difficult! I much prefer a static analysis pass saying, "hey, you changed this interface, did you know this codepath over here relied on that thing you changed?". Static type systems are not the only way to accomplish this, but in my view, they are a much less burdensome way to accomplish it than the level of dynamic validation and testing necessary to do so otherwise.

But again, it's just a frustrating debate, because clearly you have the exact opposite experience! So where does it get us? Nowhere really...

yAak• 3 years ago

I’m half convinced it’s a difference in how people’s brains work. Dynamic typing adds just so much cognitive overhead for me.

Well, that and PTSD from digging through so many horrors created with Python and JavaScript.

mecha_ghidorah3• 3 years ago

And good luck untangling your type definitions when your requirements change. That one is the killer. Static types are premature concretions on the domain data model as you understand them now. They will change and if you are unlucky you will have to support multiple different variations of domain models in the same runtime. Good luck with that. Especially if you use inheritance.

I actually found this way easier with static types because with static types I could be significantly more confident about every single place one of those types was used, and look at it and see if it needed changes. This was way fiddlier to do in a dynamically typed environment

deterministic4• 3 years ago

That might be your experience but not mine. I believe there is no right choice for everybody. So pick what works for you and move on.

Veuxdo• 3 years ago

Static type checking won the battle, but lost the war to microservices, micro front-ends, micro-repos, and so on.

victorNicollet2• 3 years ago

I think there are at least two ways to write safe and robust code, one being to rely on static types to provide automatic guarantees, and another being to structure the program in a way where tests reveal errors immediately. They are mutually incompatible, and so different from one another that few people can be experts at both, but I don't think one is objectively inferior to the other.

Both styles require code to be disciplined, and undisciplined code cannot be caught by compilers, linters or automatic tools, it has to be through code review (or experience and sheer willpower). It's easy to think of examples where a lack of static types would allow brittle code to be written, but it's important to question whether that brittle code may be considered unacceptable by someone experienced in working without static types, in the same way that code using a Dictionary<string, object> instead of an actual type would be considered unacceptable by a type-safety practitioner despite being (technically) type-safe.

evrimoztamur2• 3 years ago

Why are they incompatible?

victorNicollet2• 3 years ago

For example, with static typing one would define many different complex types over the program, in order to have the compiler enforce the many different constraints (here the value can be null, but not there ; these two values must be provided together ; and so on). Things like structural typing or algebraic data types even allows the creation of unnamed types on the fly. When sum types are used, conditional operators will be used to deconstruct these in a type-safe way, resulting in many branches.

With dynamic typing, one would have only a small number of very different types, because having many types increases the risk of using the wrong one, and having similar types makes it harder to notice that the wrong one is being used. The types must be very simple, because deconstructing complex types requires having branches, and branches should be kept to a minimum because they are hard to cover properly with unit tests.

KMag4• 3 years ago

Some early Lisps had both compiled and interpreted mode, where the interpreter used dynamic scoping and the compiler used lexical scoping. (Which, I presume, caused much developer confusion when code worked fine in the interpreter and got very strange behavior once compiled.) Something analogous (but more sane) could be done with type systems.

I'm very much a fan of strong static typing, but I understand the appeal of dynamic typing, particularly for small scripts and/or prototypes.

Static type checkers (for most languages) are pretty simple theorem provers. For statically typed languages, the compiler (or, I suppose in rare cases, interpreter) rejects any program that it can't prove is free of type errors. An alternative would be to only reject programs that provably contain type errors. The difference in allowed programs covers the cases where the type checker can't prove either way.

So, I'd love a language with a type checker that when ahead-of-time compiling code would refuse to emit libraries/binaries when it couldn't statically prove types were used correctly. In interpreted mode, it would only refuse to load code that it could statically prove contained type errors. Maybe when used within an interactive session, it would still allow (but warn) when code provably has type errors.

As an added bonus, static type guarantees open up more opportunities for the optimizer. A single language offering some range of static guarantees would reduce the number of cases where dynamically typed code gets re-written into a higher performance statically typed language when re-factored into libraries.

If you prefer, go ahead and dynamically type your scripts, etc. However, if/when it comes time to package up parts of your program for wider re-use as libraries, please tighten up the static guarantees of type safety.

dannymi• 3 years ago

So, I'd love a language with a type checker that when ahead-of-time compiling code would refuse to emit libraries/binaries when it couldn't statically prove types were used correctly. In interpreted mode, it would only refuse to load code that it could statically prove contained type errors. Maybe when used within an interactive session, it would still allow (but warn) when code provably has type errors.

Haskell can do that. https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_gui...

cma256• 3 years ago

Static typing won there's no point arguing over it anymore. The issue is the type systems. Someone writing Haskell will have a very different opinion of types versus someone writing Rust versus someone writing Typescript versus someone writing Bash.

That's why you see a negative reaction to static typing. Its the developer experience. Its the error messages. Its the amount of time and mental effort it takes to type something correctly.

If you told me I had to choose between dynamic Python or strict Typescript I would choose Python. I love static typing. I hate Typescript.

So don't die on a hill! Just make better type systems!

tabtab• 3 years ago

Although a lot depends on personal preference, in general "root" infrastructure is best on strong typing, while "glue-ish" scripts best as dynamic.

derbOac• 3 years ago

Strong static typing is better when used well, but worse when it's used poorly.

That last part is the catch, and I've seen plenty of people think they're using it well when they're actually using it very, very, very poorly.

Dynamic typing isn't just a convenience sometimes, sometimes it helps compensate for poorly planned type structures.

Like a lot of things, there are tradeoffs in terms of what types of errors you want to avoid more.

cocoacat• 3 years ago

But in my experience I have also experienced the opposite. I have seen people casually reuse variables by reassigning them to a new type or developing a single function that returns different types. With dynamically typed languages it sometimes feels like you can take messy shortcuts because they let you.

Draiken17• 3 years ago

The only thing that really frustrates me in this discussion is that it's all about how people "feel" and without empiric evidence.

The research out there found no meaningful difference between both styles (unless there's newer research I haven't seen?) and people keep taunting around how their preferred side is undoubtedly the right one.

That's just like, your opinion man.

Personally I like typed languages but the type systems in languages like TypeScript are simply insufficient. You still end up with runtime bugs because you can't actually use those types at runtime. You can't encode a lot of the runtime logic into the type system so you're still manually checking impossibilities everywhere. I find myself even having to create local variables just to make typescript detect an obvious condition.

If a type system could basically remove the need for me to think about runtime bugs, then that's an absolute killer feature that I doubt anyone would argue against. But most languages don't provide that, so you're stuck in this halfway point where you have all this overhead, some benefits, but you still can't 100% trust your types.

As for why there are no meaningful differences in bugs, speed, etc my guess is that it all evens out. Without the type system safety net you are much more likely to test your code and as a result less bugs go in. On the other side people rely too much on the type system that's not good enough and then still end up with the same amount of runtime bugs. On one side you write code faster, but you have to test more, so it also evens out with writing more boilerplate, but with less tests.

I really wanted some hard research on this, but I know it's a hard one.

dgb23• 3 years ago

Exactly my thoughts!

The article and many commenters here all talk about programmer ergonomics, productivity and "correctness".

The current research shows that these things are neither improved nor weakened by static typing. There are (even recent) papers on comparing typed vs dynamic language with no meaningful results. So basically it's entirely subjective.

However there _is_ an actual effect of static typing that can be trivially proven: It enables a programmer to write more efficient code. That should be at the forefront of every discussion around typing discipline, because everything else is just _hot air_ at this point.

TypeScript (used in the article) is an example that is _not_ actually strongly typed (it's statically typed but weak) and it doesn't even provide performance and memory layout guarantees, because the types are just comments. So you pay all of the cost of static typing without _any_ of the tangible benefits except documentation.

To me it is surprising that we as a technical community completely ignore actual evidence and take our cultural and personal preferences as fact.

lolinder2• 3 years ago

As other commenters have noted, the evidence here is really weak either way. The controlled studies are all done on college students, and therefore on pretty small short-lived projects. My instincts tell me that while static types may be optional at that scale, they are essential on large commercial projects that last for years, and projects like that are nearly impossible to properly study.

Other studies try to compare bug rates between open source projects, but it's hard to be confident in answers gleaned from that kind of observational study. As long as the evidence is so weak, the industry will continue to ignore the research and go with our instincts.

the_af7• 3 years ago

The current research shows that these things are neither improved nor weakened by static typing

I think there's a difference between "current research hasn't been able to conclude anything" and "current research shows [thing]".

I believe static typing is better, but that there's no conclusive research because there are many confounding variables and the experiments are really hard to conduct in the real world.

tasn11• 3 years ago

I think most people would agree that types prevent a lot of bugs (and others posted research to support it in the thread), so the question is less about that and more about the subjective reasoning people have to decide the investment is not worth it.

Draiken17• 3 years ago

I think most people would agree that types prevent a lot of bugs

Again, that's not what research shows. Type checking bugs are most definitely not the most common ones and typing doesn't really help with runtime bugs unless it's a strongly typed language.

I'm all for types, but after using TypeScript and seeing everyone (including the article) touting it as the solution, it simply isn't all that better than vanilla JS.

I did spend countless hours having to wrangle typescript when integrating with third party libraries, searching for types that were not always there, manually extending/creating library types and so on.

So no, it's not as clear cut as some say it is.

If we want to argue for types, then we should use strongly typed languages that prevent these bugs (if you can manage to create the right types, of course). Examples in TypeScript are simply not going to cut it because that's a horrible example of a typed language. I mean, it's not even a language.

Edit: above all, hard research. If there's research for this, why isn't that in the article?

ReflectedImage26• 3 years ago

Nope, static typing triples the average bug count of a piece of software. Using static typing add complexity to your code and complexity leads to more bugs.

Static typing is where you significantly decrease your development speed and significantly increase your bug count in order to increase the performance of your software.

patrickthebold3• 3 years ago

Perhaps the issue is how people like to solve problems. I'm a huge typescript fan, and I say a lot of the hard work is designing the types. Then the code becomes 'the only thing that makes sense given the types'. There may be some duality at play, where otherwise designing the code is the hard work. And the types become, 'anything that makes sense given the code'

And note the switch from 'only' to 'any'.

Anyway just hypothesising.

Draiken17• 3 years ago

I had to learn TS because that's the hype today, and went into it after seeing some amazing F# talks on typing. I was amazed at the way they used types to ensure your code was actually correct. I was excited to be able to do that with TS.

Then I found out the hard way that none of that works. Basically it's all a lie. You can't use the types in runtime so all that effort you put into the types doesn't actually translate when you want to use the type system to full effect. That was absolutely demoralizing.

For me, the white elephant in the room is that the language doesn't really matter all that much. Good developers will write good code and bad developers will write bad code.

Good developers might use meaningful types and bad developers will use strings, records and numbers everywhere. Guaranteeing a string is passed and not a number is not gonna prevent many bugs. Guaranteeing a `PhoneNumber` is passed can truly prevent bugs. But that's never the code that you actually see in the wild (even in the article).

In the real world, most people can't even use half the type system they claim is so great.

joekrill• 3 years ago

The research out there found no meaningful difference between both styles (unless there's newer research I haven't seen?) and people keep taunting around how their preferred side is undoubtedly the right one.

Does it, though? I'm not sure the research shows any strong evidence one way or the other. There's a decent review of various studies here, for example: https://danluu.com/empirical-pl/, that seem to indicate no real conclusion.

Draiken17• 3 years ago

That was my bad. I meant to say it didn't lean either way because the research is lacking.

ryandv• 3 years ago

A 2018 study [0] found the following:

Language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages.
The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits.
The data indicates that functional languages are better than procedural languages; it suggests that disallowing implicit type conversion is better than allowing it; that static typing is better than dynamic; and that managed memory usage is better than unmanaged.

Regarding your comments:

Personally I like typed languages but the type systems in languages like TypeScript are simply insufficient. You still end up with runtime bugs because you can't actually use those types at runtime.

That's because TypeScript is not actually strongly typed, it is gradually typed; throw in a single "any" type into your TS and all static guarantees are now off. I agree that TypeScript is insufficient, and point to languages like Rust or Haskell (one of the languages with the lowest defect rate in the study [0]) that actually do offer static guarantees, and where use of untyped "escape hatches" is far less common and/or is far more judiciously applied.

If a type system could basically remove the need for me to think about runtime bugs, then that's an absolute killer feature that I doubt anyone would argue against. But most languages don't provide that

Isn't this basically the promise of Haskell, Rust, et al? "If it compiles, it works;" "guaranteed memory safety," etc?

[0] https://developers.slashdot.org/story/18/01/01/0242218/which...

dang3• 3 years ago

That study dates from 2014 and was discussed here:

A Large-Scale Study of Programming Languages and Code Quality in GitHub (2014) - https://news.ycombinator.com/item?id=15378800 - Oct 2017 (66 comments)

It's also discussed prominently in Dan Luu's survey, linked to here:

https://news.ycombinator.com/item?id=37770719

Draiken17• 3 years ago

Isn't this basically the promise of Haskell, Rust, et al? "If it compiles, it works;" "guaranteed memory safety," etc?

Yes, 100%. If that's what people were referring to when they argue for typed languages, then I'm all for it!

But the article (and almost everyone else that brings this up) then tries to use TypeScript as an example. That's a big issue for me. TS leaves you hanging in the middle with a ton of boilerplate and you fighting the imperfect type system, while catching very few bugs (at least for an experienced developer).

Hermitian909• 3 years ago

I really wanted some hard research on this, but I know it's a hard one.

I think we'll have to settle for judgment calls.

I tried going through some of the research we have on developer productivity a few years back and it's almost all garbage or is only truly applicable to juniors (e.g. when you're new you really benefit from quick feedback time on static errors).

The entire space suffers from the fact that good experimental design is impossible to implement with anyone who's not a college student (good luck getting professionals to follow your rules for months) and the curse of dimensionality from the need to disentangle individual variations, type of software development, management style, and a thousand other things to try and draw out a signal.

Sadly, many things and life can't be effectively measured.

d0mine• 3 years ago

It looks like you think writing your program in the language used to express types will magically remove "runtime bugs"

If the language is powerful enough to be able to write ordinary programs, it is powerful enough to produce bugs.

Static typing can be effective at catching certain types of bug, not all. It can improve readability sometimes (as a DSL for static unit tests/executable docs).

In general, dynamic languages are more agile and you can write more tests easier. Some of the tests you wouldn't need to write in a statically typed language, therefore typing is still useful though not as universally effective as one might believe.

the_af7• 3 years ago

In general, dynamic languages are more agile and you can write more tests easier.

Where's the evidence of this? Be wary of speaking from "common sense", this kind of assertions are deceptive. Maybe statically typed languages are better prototyping languages? (E.g. there's evidence from an early experiment by Paul Hudak that Haskell is actually a good and fast language for prototyping, beating other languages in the experiment!).

deterministic4• 3 years ago

SeL4 and CompCert are examples of software that is proven correct using a very strong type system.

gmfawcett• 3 years ago

A good resource for research on topics like this is It Will Never Work in Theory: https://neverworkintheory.org/category/#programming-language..., https://neverworkintheory.org/category/#types

lolinder2• 3 years ago

Static typing is just one slice of Swiss cheese in the pursuit of more reliable software. Yes, it will leave holes like any other technique, which is why you should mix and match them for maximum reliability. But throwing out static typing because it doesn't catch everything is like choosing to leave the door unlocked because the thief could always break a window. If security is really important to you, then you should have bars on the windows in addition to locking the door, not instead.

littlestymaar3• 3 years ago

The research out there found no meaningful difference between both styles

I don't know which research you're thinking about, but if it's the one I've seen, it was empirical analysis and it's worthless because it's subject to survivor bias: whatever the tool you're using to make a program, it's going to be polished just as much as needed for it to fit its market, or it will die, simple as that.

If one paradigm lead to much more bugs per written line of code, but you're using it anyway for mission critical stuff, then you'll fix those bugs or fail. On the other hand, if one other paradigm leads to very little bugs compared to others, but you're using it somewhere where reliability doesn't matter, then the few bugs that are there from the beginning will stay there.

We can even call that the iron rule of bugs: No matter what tools you use, your code will contain roughly as many bugs as your business can tolerate.

The real question is how much effort does it take to achieve the same level, but it's obviously harder to study.

leecommamichael• 3 years ago

Implicit conversions and multiple “nil” values are the root of your complaints of TypeScript. Dart improves on this, but adds OOP heft. Alas.

tlavoie2• 3 years ago

Would Elm be better there? It's compiling to JS, but not trying to interact with most JS except through specific interfaces.

myaccountonhn2• 3 years ago

I don’t think you need a “study” for example when Elm has no runtime exceptions. That’s an entire class of bugs plain impossible to express (bar a few contrived examples)

pharmakom2• 3 years ago

Elm does have runtime errors. It doesn’t statically analyze division by zero, for example.

insanitybit15• 3 years ago

Research is... complicated. I've seen a lot of research, some shows that types prevent bugs, some doesn't. It's all over the place. If you really want me to I can find you some papers. I've read perhaps two dozen, total, maybe 15+, dunno. The methodologies range from "we scanned github" to "we went to a company and had them solve a problem twice" to "we took a curated group of developers, trained them in two made up languages (one with and one without a type system) and let them attempt to solve a complex business problem" - and the results vary, although my recollection is that they are largely "pro types".

The thing is, not everything is going to show up in research results. There are an insane number of variables.

How do you account for developer experience? How do you account for experience within a domain? Experience with a language? How do you account for different type systems? Training with type systems? Complexity of the domain? How do you account for one developer being better than another? How do you account for development methodologies? How do you account for people's moods that day? How do you account for effort?

It's just not something you can easily research. It's extremely expensive just to generate a small study that tries to control for some of these things.

In the meantime, we can use our experience as engineers. We have to make a judgment. We have to form opinions that are biased and subjective.

deterministic4• 3 years ago

It is pretty much impossible to prove this one way or another. I also believe it varies from person to person. I am personally way more productive using typed languages. However others claim the opposite. And we might all be right.

fennecfoxy4• 3 years ago

That's because there's no recorded metric for every time a dev working in plaint JS mis-spells a property, or accesses one at the wrong level, calls a function that doesn't exist on that particular version of the library, etc, etc.

For the most part, the resistance to Typescript from devs who prefer to write plain Javascript is purely borne out of adding the types being "too much effort to be worth it". Sure you gotta wrestle with the type system now and then but there's often a reason you have to + once it works it usually works very well. Which I find kind of funny bc those devs don't mind putting the effort into writing unit tests, but adding types (think of them as just lower level tests) is somehow an insult to the way they do things.

But nah they'll still just rawdog their JS and just make mistakes/misspell stuff now & then as we all do. Let's just hope tests/CI pipeline is enough to pick it up before it gets to prod.

thot_experiment• 3 years ago

It seems like such a weird thing to have a super strong opinion on. Sure if you only ever do one specific thing maybe there's an argument to be made that one is better than the other. I think there are just some problems that are best solved with statically typed langs, and some are better solved with dynamically typed langs. IIRC research shows it's a wash.

throwawaaarrgh• 3 years ago

Typing is literally an architectural/design decision. There is no such thing as one single type system that works for all use cases.

It's like saying there's only one good kind of metal fastener for construction. Sometimes you should use nails, sometimes screws, sometimes bolts. It's not like one of those is always superior to the others. You literally should not use a bolt all the time, nor a screw, nor a nail. There are specific engineering requirements and purposes to them all and you can't just mix and match based on your personal preferences.

Well, let me correct myself: you could just use one fastener you prefer, but your building would fall apart six different ways and be a huge pain in the ass to construct. Thankfully we have building codes so people can't just decide to do that.

berkes6• 3 years ago

I doubt anyone is arguing that our bash scripts should be typed, or our quick "remove_currency_from_bank_csv.py" must be statically typed.

The article puts a few cases forward. What the article is discussing, however, is the majority of software. Built in varying teams. Over long periods of time. Large software, complex software.

Animats• 3 years ago

There's been considerable convergence on this. Most languages now have some degree of type inference for statements now. Even C++ has "auto". That substantially reduced the amount of type boilerplate in code. Remember having to write out long iterator types in C++ "for" statements? We're past that.

As for function declarations and structure fields, that's where you need type information to read the code. Once a program gets beyond a few hundred lines or beyond one developer, some amount of annotation is essential.

The main objections come from Python and Javascript users, of course. Python retrofitted a very strange advisory typing system, and Javascript retrofitted TypeScript. Both are bolt-on type systems and are used in mixed typed/untyped environments. That is painful.

LISP also got a type system retrofit decades ago, with "flavors" and the Common LISP Object System, and that was ugly, too. The lesson here is that retrofitting a type system creates a mess.

mjr00• 3 years ago

I actually think Python's type system is pretty good, given the circumstances. It's got some nice features like Optional forcing checks for None values before use, and structural subtyping with typing.Protocol. Could it be better if Python were designed with types from the ground up? Yeah, of course. But given the requirements of integrating with all existing Python code and not breaking any existing code I think it does a decent job.

The bigger issue with Python and static typing is the ecosystem and conventions that a lot of developers use, made worse by a lot of these developers really being data scientists who are writing Python. *args/**kwargs are heavily abused by people too lazy to write proper method signatures. It's extremely common in Python to have methods pass around DataFrames or dictionaries as a grab-bag of stuff. Bonus points when methods add and remove columns/fields so you don't know what's in the data bag until you run the code (or read every line).

You can do this in almost any language, of course. Nothing stops you from writing a C# program with every type being `dynamic` or have all your Go methods accept `interface{}`. But Python, for a long time, actively encouraged this approach, and sadly there's still many beginner tutorials today that present things like "just write a method that takes *kwargs and you don't have to change the function signature!" as an advanced language feature for smart people instead of an awful footgun.*

spankalee7• 3 years ago

TypeScript's type system is flat out amazing though. I wish more type systems were as expressive.

Byamarro• 3 years ago

TS' type system is insane in what it's capable of expressing. I've personally wrote a snake game using types alone (you see a board, snake and snacks inside your editor type popups).

Despite that, TS is still quite cumbersome to use due to its initial mission statements. I.e. `Object.keys(myObject)` doesn't return `keyof (typeof myObject)`, so if you'd do something like this: `Object.keys(myObject).forEach(key => myObject[key])` it'll throw an error that key is not assignable to `myObject`. The reasons lie in design choices made in order to be able to gradually migrate an untyped JS codebase into a TS one. There's tons of issues like this, some of them are just completely absurd and make developers that try to achieve simple things throw their laptop out of the window :D

germandiago2• 3 years ago

Python and Typescript "type systems" were designed for gradual, non green-field typing. It is essential to incremental migration and totally understandable that it works this way.

lispm• 3 years ago

LISP also got a type system retrofit decades ago, with "flavors" and the Common LISP Object System, and that was ugly, too. The lesson here is that retrofitting a type system creates a mess.

Flavors and CLOS are not "type systems". They are "object systems" and there is nothing "ugly" about them. Flavors was introduced into a Lisp which did not have a type system. Later CLOS was added to a Lisp which already had a type system: Common Lisp.

freilanzer9• 3 years ago

http://alhassy.com/TypedLisp

choeger• 3 years ago

First of all: I always have and always will be a proponent of statically strongly typed languages (although I would argue that "statically strongly" is redundant here, there are only typed and untyped languages, IMO).

But there's one cost that the author seems to miss and that I didn't fully appreciate for some time. That's the cost of composition. If you look at python you can pretty much compose all possible packages on pypi in your project. All their means of abstraction are usually fully compatible (except for concurrency). Composition often only requires a little bit of glue code.

In a statically typed language's ecosystem you will probably a handful of fundamentally different means of abstraction like functors vs. classes that simply don't compose well together. Hence the fragmentation increases massively.

lucasyvas4• 3 years ago

The dynamic typing crowd is frankly just flat out wrong at this point and someone has to say it - so, thank you Tom. This is especially apparent with advancements of type inference in compiled languages.

Beyond initial prototyping (which I doubt will actually ever be thrown away), what logical defence is there for catching obvious bugs in production when they could have been caught at compile time instead? Dynamic typing straight up hides unavoidable realities of programming - you have to know what thing you have to cover all the cases. I don't just mean cases that "make the compiler happy". These cases are most often not mutually exclusive from the business domain - cases related to core business logic are missed, which produce more bugs which makes your software objectively worse for both the end user and whatever business the software is sold by.

The complaints I hear are that it's too cumbersome or annoying to satisfy these cases - my retort is to stop complaining because most of us are paid to write working software, not software we can pass off as being complete when it's not.

And don't suggest that tests cover this - they absolutely don't, and testing such things is a total waste of time. The train has left the station, best get aboard.

lisper• 3 years ago

No one is against static typing. This thing that some people, myself included, oppose -- with good reason -- is mandatory static typing. The idea that anyone advocates giving up the ability to catch bugs at compile time if it can be done at no cost is a straw man.

berkes6• 3 years ago

Who is arguing for mandatory static typing?

Even the article we're discussing points out there are cases for no- or dynamic typing.

PaulHoule2• 3 years ago

A counter is that nothing has replaced Python for data science. I mean, Julia has talked a good game but gotten very little traction.

lucasyvas4• 3 years ago

I would argue this is a false equivalency. The explanation is that Python is too entrenched to replace, not that it is somehow superior for this use case because it is dynamically typed.

ReflectedImage26• 3 years ago

Dynamic typing triples your software development speed and decreases bugs in delivered software by two thirds.

You can either hire 10 dynamic typing software developers or 30 static typing software developers. Businesses which choose to hire 30 static typing software developers will fall to the companies which hired 10 dynamic typing software developers. It's pure economics.

Static typing fills your codebase with bugs. Whilst an inexperienced software developer might not understand why static typing increases rather than decreases bugs, you can see the increase in bugs in research papers on the topic. As plan as day.

(Hint: You have made your code more complex by using static typing and more complex code contains more bugs.)

germandiago2• 3 years ago

Clojure author Rich Hickey disagrees on this. He argues that not only typing is what you need since many of the errors are not typing errors and not even most are (not sure he said that last thing exactly though, talking from the top of my head). The point being that an alternative that can check that and more is better. Also, he argued that types are key/values no matter the formal type if it is the same thing in two systems.

So he created spec. Spec can check more invariants than just typing. Truth to be told, Clojure is functional and one of the goals is to generate test cases from those specs. So it is a bit of a different story probably.

At the end we want correct software.

amelius• 3 years ago

How long until Copilot can type-annotate any piece of dynamic code, making the issue mostly irrelevant? Everybody sees the code how they like to view it.

todd8• 3 years ago

I understand that modern type systems can do anything (that can be computed) since they are Turing complete. So are Java generics and C++ templates and Lisp’s macro systems, but I don’t want these things.

I’ve written a number of Turing machine programs; yeah it’s impressive that an imaginary machine that is so simple can run any program that runs on any other computer, but it’s no fun writing code for a Turing machine. For the Theory of Computing studying Turing machines is important.

If I don’t want Turing complete type systems, what do I want? Well, first off, the bugs I find in my programs that are more troubling don’t seem to be stopped by strong type systems. What I want is to be able to declare assertions in my code. For example, I’d like to tell the compiler that the variable year must always satisfy (2000 < year < 3000) and that in a certain block of code that x and y are always within 0.5 of each other. I want the compiler to ensure that these invariants are satisfied by a combination of compile time and run time checks generated by the compiler.

The problem is that we can’t expect programmers to use Turing machine like type declarations, because the programmer must now program the type system without bugs to ensure that the types in the program carry enough information that higher level assertions can be made about the original program’s correctness.

TLDR, I want to work with higher level assertions about the code than that provided by complex types.

kazinator6• 3 years ago

Your comment seems as if it might be confusing Turing completeness with the expressiveness of the actual machines described in Turing's work.

A Turing machine is not "so simple that it can run any any program ...".

Simplicity has nothing to do with it. Turing showed that some very simple machines can calculate recursive functions.

Not every machine that is Turing Complete looks like a tape machine from Turing's papers.

it's no fun writing code for a Turing machine

Almost every general-purpose programming language is a Universal Turing Machine; so that's like saying it's not fun to write code, period.

coldtea• 3 years ago

The question around strong static typing is simple: would you rather work a bit more and get invariants checked at compile-time (or type-checking time for non-compiled languages), or work a bit less and have them be enforced at runtime

The latter. Other question?

yc-kraln• 3 years ago

The example from the article without any explicit arguments reminds me very much of objective c's message passing concept, which I actually quite liked and used very much. So, I guess the answer is: there is no objectively correct way to do things, except if the thing you are trying to do is get "engagement" then take an extremely strong stance on something which has no objectively correct answer.

m0llusk• 3 years ago

Seems like a matter of degree.

If taken to an extreme then nearly all parameters can be made into unique types. Not just measures, but pixel height measures. Not just pixel height measures, but help panel pixel height measures. Not just help panel pixel height measures, but settings help panel pixel height measures and so on. This may seem like a great way to keep everything well sorted, but ends up being an unhelpful mess that is difficult to maintain. So the question is how exactly in a situation is best to define types, not whether or not to have them or to make them static or whatever else.

And why exactly do you need types in the first place? Lots of projects are messy and involve teams and have work handed off to developers on a regular basis. In that kind of context which is quite common types can be a life saver. There are also short term one person projects that have a high expectation of all work being thrown away soon after. Isn't defining a bunch of types likely to be a waste of time if there is only a brief development effort which is clear and not expected to ever be touched by teams?

Most one size all solutions like static typing have some contexts in which they are either a complete waste of time or need their breadth to be carefully limited.

terminatornet• 3 years ago

It's a shame so many people have had bad experiences with static typing due to Typescript. In languages like Rust and Elm, static typing truly feels like a super power when I'm coding, particularly when modeling my applications possible states.

This talk does a great job at articulating how to use types to disallow invalid/illegal states.

https://www.youtube.com/watch?v=IcgmSRJHu_8

simonblack• 3 years ago

Moi aussi.

If you have strong static typing you don't need all those dumb functions like string_to_number("1234"), etc. to change the type you're given to the type you find you need right now.

When you know that a variable is of a set type, you DO NOT need to keep looking to see what type it happens to be at the current moment, and then juggling it to suit.

webworker• 3 years ago

Frankly I'm surprised that there even seems to be a vogue/fashion on this.

I learned programming with types (C++). Was then beaten over the head that types didn't really matter/yolo. And now we're back here again.

It could have always been this way. And for some, I'd imagine the type party never took a break.

kazinator6• 3 years ago

Because nobody ever put together a hash key using string interpolation, and made a typo, in a strong, static language.

berniedurfee• 3 years ago

As a greybeard, I’m so glad to hear and see type safety becoming okay once again.

XP seemed to be the catalyst for the “code fast and bail” mentality that’s persisted for too long.

I feel somewhat validated as a long time advocate of type definitions.

It always irked me to hear someone say a language with types is too “verbose” and slows them down.

Yeah, please do slow down! It really is okay to take a little more time to write better code.

zubairq• 3 years ago

As someone who has programmed in C++, VB, Clojure, Java, Ruby, Erlang, and now Javascript (because of NodeJS and that it is in the browser), I will admit that I usually ending up implementing my own Type system and checks more and more as programs gets larger. Maybe there is some variation of Greenspun's tenth rule like "Any sufficiently complicated dynamically typed program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of INSERT YOUR FAVORITE TYPED LANGUAGE HERE"?

CraigJPerry• 3 years ago

When I sit down to do a side project these days I’ve gotten into the habit of turning on a screen recorder then just forgetting about it and cracking on with the project. Watching these recordings back at 10x speed has been fascinating to see how I work.

Most of my findings around wasted time and effort or correctness stem from design (faulty or skipping design analysis altogether and just coding). Every other aspect of coding just pales into insignificance compared to this one thing.

ReflectedImage26• 3 years ago

Static typing sounds great to Junior Software Developers, who don't properly understand what the problems the software they write needs to solve.

Static typing allows me to check the types are correct! In practice, typing related errors are a very rare bug so it isn't very useful.

Static typing allows me to check things at compile type. In practice, this means waiting around for things to compile and lots of dead time. The larger the project get the longer the compiles times.

If performance doesn't matter, dynamic typing is pretty much always the way to go. You get the code out faster, so you have time to write more tests and you can throw away the code faster. Cause in the real world, code is a churning thing that evoles with the business requirements. Not some static build once thing that static typing and Junior Software Developers assume.

Snacklive• 3 years ago

Ok so, based on the comments it's basically people who loves Strong Static Types and people who only experience with types is Typescript and they hate it.

zomglings• 3 years ago

My context is the Only True Context. My way is the Only True Way.

Zealotry and fucking bullshit.

danabrams• 3 years ago

The author leaves out what to me is the most compelling argument against static types: it is somewhat at odds with interactive development with a running system, as seen in smalltalk and lisp.

Now, not a lot of developers are really doing this. But it's still a good reason for those who are.

kazinator6• 3 years ago

The article's author is using Blub static types, in which you're declaring that the variable that captures something from the cache is a Pet handle.

Under a properly modern static typing system, you let that be inferred:

  let var = cache.get("key");

var is of whatever type that the cache object returns. Even clunky old C++ can do this with auto.

That author will most likely die in some statically statically typed corner he painted himself into.

Aerbil3132• 3 years ago

People are saying strong static typing is not a worthy investment mentioning their experiences with Typescript. That's Typescript. Types are comments. They don't even exist in runtime. Try a real strong static typed language like Rust.

LLyaudet• 3 years ago

Just spotted a typo "mulitple" in case the author lurks in the comments here :). ("You'll pay it mulitple times over when you need to debug why your code doesn't work (either locally, in the test suite, or in production).")

Strong static typing, a hill I'm willing to die on

Related Stories