The way I remember the pascal type system is arrays of different lengths were different types.

They are pretty much everywhere when statically allocated.

well, not in c.

I believe they are in C, but arrays degrade to pointers when you look at them wrong, and _those_ don't have length as part of their type.

At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.

> when you look at them wrong

no, almost whenever you look at them. it is very hard to carry around the size of an array in C.

> At least I'm seeing: `array type 'int[3]'` in messages when I tried to do something wrong with it quick to get an error message (using llvm), maybe that's a compiler specific thing.

post some code that illustrates what you are talking about

I was trying to get clang to throw an error that included type information to double check what it thought the type was. Quickest thing I could think of was trying to assign to an array.

The exact error in question was: error: array type 'int[3]' is not assignable

Which seems to imply that clang is considering the length to be part of the type.

edit: You asked for code (my apologies that it's rather trivial).

    int x[3] = {1, 2, 3};
    int y[3];
    y = x;

Even in C, citing the standard (6.2.4, 20):

> Array types are characterized by their element type and by the number of elements in the array.

There's more to it than that. You could (from early Pascal days) and can have arrays where the array index range is a previously defined subrange of integers, or maybe even of an enumerated type.

Then you have sets as a built-in type, which is big.

Some more.

In the original Pascal, that was true. The standard (and, I think, Jensen & Wirth) were that way. And it was a fatal flaw.

I had a program that I took over that did a numerical simulation on a 2D grid with user-specified size. The original author simulated that 2D grid with a 1D doubly-linked list. As you might expect, this was both slow and error-prone. But he did it because there was no possible type that you could give to a user-sized array. There was literally no way to talk about such a thing.

We eventually "fixed" it by allocating the largest 2D array possible within our memory limitations, and using only the user-specified part of it.

Most "real" Pascals (Turbo Pascal, but others that were intended to be used in the real world, not just in the classroom) developed some way to give a type to a variable-length array (and also to do a C-ish cast). Unfortunately they all did it in different ways, so there was no code portability between compilers if your code needed such things.

So, yeah, "objectively better than C" is quite a stretch, even just in the type system.

> but Pascal’s type system was pretty solid

To be honest, this is a matter of styles, coming from a dynamic type background I don’t appreciate strongly typed systems as an advantage.

Strongly typed is orthogonal to dynamic and static typing. Python and Common Lisp are both "strongly" typed and dynamically typed. There's no reason to shun strong typing if you also like dynamic typing.

I would be curious to see references that claims that dynamic and static typing are orthogonal with strongly typed systems, as “strongly type” is rather ambiguous and the only reason I used the term was because that was how Pascal was promoted back in the day (or at least how was taught to me)

From Wikipedia: In 1974, Liskov and S. Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."

Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages.

You already found the wikipedia page, try reading it. See where it puts a lot of dynamically typed languages under the category of "strongly typed". You've decided it's a good enough source apparently.

But really, I used "strongly" in quotes deliberately. It's a terrible phrase since it means nothing in practice because it can mean too many things (as that same page notes) that often are at odds with each other.

> Note that the definition refers to type declaration, both being optional in Python and Common Lisp, so I wouldn’t use either as an example of strongly type languages.

Even this definition would potentially exclude SML and OCaml where types are inferred, not declared. So according to you those two languages are weakly typed? I think a lot of people would be surprised to learn that.

Dynamic and static merely point to the fact that type analysis is either done at runtime or at compilation time.

It is an unrelated concept to which type rules will be applied by the software at runtime or compilation time.

"whenever an object is passed" clearly refers to run-time. An object is not being passed when we are compiling the function call.

"declared in the function" clearly means that the function has an internal type check.

An interface declaration (Modula-2 interface file, C header file with prototypes) is not "in the function"; it's compile-time meta-data about a function.

A function call between separately compiled translation units has no idea what is in a function.

how can Python be strongly typed if it doesn't enforce types for declared arguments?

What is the value of this supposedly "strongly typed" Python's type system?

class Object:

    pass

def f(arg:int):

    print("type of arg = ", str(type(arg)))

f(1)

f(666.0)

f("kek")

f(Object())

type of arg = <class 'int'>

type of arg = <class 'float'>

type of arg = <class 'str'>

type of arg = <class '__main__.Object'>

and not a single error/warning thrown

How is OCaml strongly typed if it doesn't have declared types?!?!? (EDIT: In case it's not obvious, I'm being sarcastic, I'm pretty sure some people in this discussion won't get that though.)

  let f x = x + 1;; (* What's the type?!?!? *)

Turns out that "strong typing" is a shitty phrase that people should stop using because it means too many conflicting things, and, consequently, means nothing. Static and dynamic typing have well-defined meanings, stick with those terms instead of ones that mean nothing.

But for a demonstration (compare to Perl) try this in your Python REPL:

  >>> 1 + "1"

Does it work? Probably not unless you futzed with the language implementation. In Perl it does, though. So to the extent that "strong typing" means anything, Perl is "weakly typed", Python is "strongly typed", and both are dynamically typed. It's an orthogonal characteristic of the type system and language from when type checking occurs.

----------

EDIT: BTW, formatting code blocks on HN is really easy. Prefix each line of code with two space characters.

  __Replace those _'s with spaces

The result is much cleaner than your comment:

  def foo(x):
    return x + x

No extra newlines needed, more compact, easier for most people to read.

people on HN often claim that Python is "strongly typed" while PHP is loosely-typed, but I don't see the difference honestly. both are pretty loose.

re: 1 + "1"

I didn't get your point really. My reply was to counter claim that Python is supposedly "strongly typed" and I don't understand how this strong typing helps developers. I know that languages can infer types, which is tangential subject. I dont know why you brought this up

> I don't see the difference honestly. both are pretty loose.

There's a clear difference, in PHP 1 + "1" is 2, in Python it's a TypeError, (and as a bonus, in Javascript 1 + "1" is "11").

The definition of "strongly typed" being used is related to type coercion, not type inference. In PHP the string is being coerced to an integer, but Python requires you to explicitly say 1 + int("1") if you want to add the numbers together. This can be helpful to developers because it requires you to make a decision about what behavior you actually want rather than assuming you want to add two numbers or concatenate strings when you may have wanted the opposite.

String concatenation is probably the most reasonable result aside from a type error given how + is used in JS for concatenation elsewhere, but JS actually gets funny.

  "1"*2 // => 2 (not "2")
  "1"*2+3 // => 5
  "1" - 2 // => -1
  "9"/3 // => 3
  "9" + 3 // => "93"

So some mathematical operators will convert string parameters to a number, but not +.

What's the difference between PHP giving "2" as the result of 1 + "1" and Python giving "999" as the result of "9" * 3?

Try that line in both Python and Perl and see how they behave, you'll see that one (Python) respects types (the most useful notion of "strong typing" is no or limited automatic type coercion and "weak typing" as an excessive permissibility around mixing of types in operations) and the other (Perl) does not.

I pointed out the OCaml example because both you and your sibling poster brought up type declarations as somehow mattering with respect to "strong typing". OCaml doesn't require type declarations, so I guess it's weakly typed according to both of you. Which is a surprising result.

I never do 1+”1” in my code, so this example is not useful to me.

I do however annotate types and expect Python to respect type annotations which is not the case. Then I dont understand what is point of annotating types if they are not respected?

If your argument that Python doesn’t convert from one type to another - well, it doesn’t need to do that if doesn’t care about types in the first place and lets you pass any junk into any method (and this is #1 thing that type system is supposed to prevent)

Is it only for documentation so that people reading code could understand what types to pass?

Python type annotations were added to be used by an external type checker, so no they are not enforced by the interpreter itself.

This was an explicit decision: https://peps.python.org/pep-0484/#non-goals

Python type hinting is not useful at runtime (in fact it's flat out ignored). It is useful at "linting" time when run through mypy.

Strong agree. I used the old Turbo Pascal for many years. It was quite routine to produce substantial programs where the compiler (and type system) had caught ALL the bugs.

Meaning: you used sensible types (and had sensible libraries) and once the obvious compile-time errors were fixed, there would be zero bugs found in testing or in live!

I like the flexibility of python, but I know that every substantial program has untested pathways that will fail when they come to be exercised :(