Why static languages suffer from complexity

Post by yakshaving_jgt » Wed, Jan 19, 2022, 8:18 PM UTC

vanusa wrote: post #107

arc619 wrote: post #88

Earlier quoted context omitted.

They're probably laughing because a) you're suggesting manually doing the work static typing does in a dynamic language because its untenable not to for large projects, and b) you can't easily add type hints to other people's libraries.

No - (a) is not what I'm suggesting. And (b) while disappointing, just doesn't slow one's work down very frequently in daily practice. Look, I just don't buy the suggestion that static typing magically solves a huge set of problems (or that it does so without imposing negative tradeoffs of its own -- the very topic of the original article). Or that dynamic languages are plainly crippled, and that one has to be a kind…

  // compiles and runs, but does bad things
  function foo(x, y) {
    someDangerousEffect();
    return x + y;
  }

  -- does not compile; huge sets of problems magically solved
  foo :: Int -> Int -> Int
  foo x y = someDangerousEffect >> pure $ x + y

Post by tomp » Wed, Jan 19, 2022, 8:20 PM UTC

HideousKojima wrote: post #23

nicoburns wrote: post #14

Earlier quoted context omitted.

The real power of dynamic languages is being able to do: const foo = JSON.parse(arbitraryJsonString); and not having to worry about the structure up front.

In C# I can just parse it to a Dictionary , and I can do that without destroying the usability of the rest of the language.

Post by foxfluff » Wed, Jan 19, 2022, 8:20 PM UTC

Diggsey wrote: post #103

foxfluff wrote: post #83

Earlier quoted context omitted.

That's the theory. Works great when there are no bugs and everything's been designed just right. In that world you could wipe implementations from memory because you won't ever need to dive in.. Very often I'm looking at code and "how to use the interface" is not a question I'm looking to find answers for.

Some information is a lot better than none. In some cases you might want to know what implements the interface: that information is also statically available. In Rust, you can look at a trait and see what types implement that trait. If you need to know exactly which implementation is being used in a particular context then maybe you shouldn't be using an interface, but should be using the concrete type?

Post by Jtsummers » Wed, Jan 19, 2022, 8:28 PM UTC

yakshaving_jgt wrote: post #108

Jtsummers wrote: post #90

Earlier quoted context omitted.

Pre/post conditions are complementary to a type system. They can ensure logical properties that may not be encodable in your underlying type system (that is, essentially every mainstream statically typed language). Such as the relationship between two values in a collection. Trivial example, if you have a range such as [x,y] where x < y must hold, how would you convey that in any mainstream type system?

The Haskell-y way to do this is to use a smart constructor[0]. [0]: https://wiki.haskell.org/Smart_constructors

Post by acchow » Wed, Jan 19, 2022, 8:30 PM UTC

Animats wrote: post #100

Fascination with type systems does not seem to be all that useful in practice. Go has a minimal type system, and is able to do much of Google's internal server side work. Most of the problems that cause non-trivial bugs come from invariant violations. At point A, there's some assumption, and way over there at point B, that assumption is violated. That's an invariant violation. Type systems prevent some invariant viol…