I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.

There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.

▲ _flux 2 hours ago | parent | next [-]

There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression.

But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime.

Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like".

It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.

▲ jt2190 2 hours ago | parent | next [-]

> Strongly typed and weakly typed do not seem to have good definitions.

Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?

▲ dtech 2 hours ago | parent [-]

There's a lot of nuance to that statement. Most languages, including e.g. Java or Typescript, would not be strongly typed according to your definition, because their type system is "unsound": there are known cases where the type system does not protect you and the types are wrong. We generally still call these languages strongly typed.

In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them.

Example:

   const dogs: Dog[] = []
   // A sound type system would error here,
   // but there's too many useful cases where you want to do this
   const animals: Animal[] = dogs 
   animals.push(new Cat())
   animals[0].bark() // runtime TypeError here

▲ arcfour an hour ago | parent | next [-]

Okay, so I'm not crazy for thinking that declaring an empty, typed array as `const` and then writing/pushing to it is confusing/feels wrong.

I didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way.

It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;)

▲ bennettpompi1 2 hours ago | parent | prev | next [-]

I may be missing something, but your example doesn't typecheck?

  class Animal { }
  class Dog extends Animal{
    bark(){return 1}
  }
  class Cat extends Animal{
    bark(){return 1}
  }
  const dogs: Dog[] = []
  const animals: Animal[] = dogs
  animals.push(new Cat())
  animals[0].bark() <<<<< "Property 'bark' does not exist on type 'Animal'."

	▲	anematode an hour ago \| parent [-]
		Should be `dogs[0].bark()`

▲ 26 minutes ago | parent | prev | next [-]

[deleted]

▲ jt2190 2 hours ago | parent | prev [-]

I would have called this “strictly typed” I think, not “strongly”. Maybe my terminology is off.

▲ kstrauser 2 hours ago | parent | prev [-]

That's fair, and I don't claim that I have the canonically correct answers. My broader claim is that I don't think I've ever heard someone say ugh, I despise that my bucket of bytes has an associated type! The real discussions weren't against types, but against various type disciplines.

For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough to figure out what I mean, in the absence of ambiguity. Like imagine this C code:

  int main() {
      int i = 23;
      auto j = i;
      printf("i = %d, j = %d\n", i, j);
  }

There wasn't a great way until recently (C23, I think?) to say "just make j whatever type it needs to be here and don't pester me with it". Contrast with Rust which is strongly, statically typed but also infers types where it can:

  fn foo1() -> i8 {
      23
  }
  
  fn foo2() -> String {
      "foo2".into()
  }
  
  fn main() {
      let f1 = foo1();
      let f2 = foo2();
      let f3 = f1 + f2;
      println!("Hello, world!");
  }

Here, that bit in "foo2" says "cast this str into whatever type you can infer it's suppose to be". Since it's going to be the return value of a function that returns a String, it must be a String, so Rust casts it to a String. Similarly, the first line of main() says f1 is an i8 because it's assigned to something that returns an i8. f2's a String for the same reason. The f3 line is an error because you can't add an i8 and a String, and Rust can figure all that out without having to annotate f1 or f2.

I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.

FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.

	▲	delta_p_delta_x an hour ago \| parent [-]
		This is called automatic type inference, and it is a big feature of functional programming languages, many of which are very strongly typed. Also, for the record, C++ gained type inference about a decade and a half ago. In C++ one can declare a completely typeless lambda: `auto callsAdd = [](auto x, auto y) { return x + y; }` And the programmer need never specify what x and y are, as long as there exists a reachable declaration of operator+ that has two arguments that accepts whatever x and y resolve to, at instantiation time (which is compile time).

▲ tgv 2 hours ago | parent | prev | next [-]

Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.

	▲	kstrauser an hour ago \| parent [-]
		Python doesn't have variables in the C sense. It has pointers to objects (aka "names"), and the "=" is a pointer assignment operator. So: `i = 23 # Create an int(23) object and store its address in i i = "foo" # Create a str("foo") object and store its address in i` i isn't typed. It's a reference to a thing with a type, not a thing with a type itself. It's also pragmatic, in that 99.9% of cases, `1.5 + 2` has a completely obvious meaning. I don't recall ever seeing int+float being the source of a Python bug. Surely someone has, but I haven't. > Python's strong typing mostly boils down to some operator rejecting mixed types. Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.

▲ baq an hour ago | parent | prev | next [-]

haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5.

for the record - I agree completely.

(glad people are over the unicode thing!)

▲ librasteve 9 minutes ago | parent | prev | next [-]

[flagged]

▲ skybrian 2 hours ago | parent | prev | next [-]

[dead]

▲ sysguest 3 hours ago | parent | prev [-]

> I don't recall anyone disliking types

> where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.

hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?

▲

delta_p_delta_x 3 hours ago | parent [-]

That is what the parent author means. Static vs dynamic typing is along the dimension of when the type is checked, and strong vs weak typing is a matter of how strongly bound names adhere to types. JS, for instance, is super weak here, you can assign a numerical value to something and in the next line re-assign it to a string, an array, or even a function object.

	▲	MrJohz 3 hours ago \| parent [-]
		That's also true of Python, though, which is traditionally considered a strongly typed language. I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all. Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior. In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.