"Static typing prevents a whole class of errors"

>Yes, but how common are those errors?
very once you get over the toy program stage and add other team members.

Okay you got me.

>I'll take being able to write a Y combinator without having to define meme recursive types over that small bit of "safety".
What did he mean by this?
fix :: (a -> a) -> a
fix f = f (fix f)

>there are usually more important things to worry about.
nope. which type system to use is one of the most important decisions to make

>naming the function
You've totally missed the point, that's cheating.

>Haskell can't do X easily
>but it's even easier to just do Y
>haha that doesn't count haha Haskell BTFO

I never said that. I only said that expressive static type systems are better than inexpressive static type systems.
Personally I prefer dynamic typing for small projects that I'll constantly iterate over and rework, while I prefer static types for large projects that I'll need to maintain for a long time.

It IS cheating, though. It's about lambda calculus, not cheating by naming functions. With named functions, you don't really need a Y combinator in the first place.

Well that's just a consequence of being a typed lambda calculus.

I'm not sure what you're getting at here. Why would you rather have (\x.xx)(\x.xx) than named functions?

FYI, you can still do Church encodings in Haskell or any typed lambda calculus. No need for a fixed point combinator at all.

>Yes, but how common are those errors?
They were much more common if users of dynamically typed languages didn't rely on huge amounts of C++ under the hood for the non-trivial parts in the first place.
Also, you make a huge assumption that everything works alright because no crash is happening. In reality however, as implies, there is a lot of graceful, implicit conversion takes place which is technically wrong but might not become a problem right now. Think JSON parsing.

This is why I hate dynamic fags, Cniles and better Java (C#) users: They use a type system that doesn't even have proper sum types and write only trivial code that STILL breaks left and right yet claim to know about programming languages.

For example, with proper checked sum types it is easier to automatically express and check state.

>The users of a language only stand to gain from a good type system.
Don't underestimate the increased size of the language and implementation. Something like Lua would be impossible with a proper static type system.

not all code projects are 1 person sub 100 line projects, when you deal with big projects with many people, you need strictly defined structures to prevent fucking up things that wont be detected until in production

yes, type safety us extremely important

sum types are gay, all you need is a lambda to match your variants

>but how will this help me fizzbuzz

TypeError: 'NoneType' object is unsubscriptable

With a static typed language, you would find out at compile time that you forgot the return on a function, and it would point out to you what function. In a dynamic or duck type system, you don't find out until potentially much later, and it might take some work to figure out when your array became nothing.

Big projects are a sign of mismanagement. Every codebase should be the responsibility of a single programmer.

That's nice on paper but it only translates so well into the real world, where sometimes a component is too big for one person and not easily split into logical separate codebases.

small errors bring down large airliners

He's not wrong. It doesn't mean that only one person *should* *write* it, but that it is possible one person could write it and one person could maintain it/be the expert source for it.

what the fuck is a sum type

>small errors bring down large airliners

That's why Ada exists.

>static types are only useful for large projects

This always seemed like a deceptive argument to me. If the code base is small and self contained, then the investment required for static typing is a non-issue.

And in return you still get better tooling, faster runtimes, free documentation, and the reassurance that you won't get paged at 3AM over a type error.

With a powerful type system you can express stronger constraints that you would have to hack together in a dynamic language using crappy OOP. For example a probability can be constrained to being a number between zero and one.

something that can easily be googled.
en.wikipedia.org/wiki/Tagged_union

It's just aggregating several types into one. If S is the sum type of A and B, then any x of type S is either of type A or of type B.
It's called sum type because the number of elements in S is the sum of the number of elements in A and B.

Refactoring a codebase with a statically typed language is orders of magnitude easier than doing so in a dynamically typed codebase. Want to change that interface signature? Whelp, good luck finding everywhere it's used. If it's a library you use in a lot of places it's especially a bitch to track down every usage. With a statically typed language you just make the change, hit compile, and all the errors are where you used it. If you fix the errors, you're guaranteed to not have issues at runtime. Anyone depending on your library will be told by the compiler in no uncertain terms that the signature is now Y.

Now you'll think "well I don't refactor like that very often!". Probably because it's difficult. In big dynamic codebases I often see people terrified to make even a small change. But I refactor my code like that all the time since making interface changes in a static language has an extremely low cost. Even in codebases that are brand new to me, I can refactor with absolute confidence. I can delete code, change class names, modify inheritance structures, change method signatures, add new ways of doing things and mark the old way deprecated, find out every location something is used, guaranteed, and more! And I don't even have to think about the spiderweb of code, just make the changes and let the compiler guide me. Maintaining statically typed codebases is just way, way easier to do.