4 ms·

> strong, static typing is an essential feature for large scale projects This is empirically false. There are (of course!) good reasons to consider static typ

> strong, static typing is an essential feature for large scale projects This is empirically false. There are (of course!) good reasons to consider static typing. But, in my experience, use of static typing has never been a first-order predictor of business or technology success. It's quite possible to build considerable value with, for example, a large Python 2.x code base. A fun, and tangentially related, talk: https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology

woolvalley 9y ago
All of it is possible, but specific features help in making better software cost less in time and money. For example, nullability annotations reduce nil pointer exceptions. Static typing removes the need to make certain typing unit tests, makes refactors easier to do in large code bases, makes it easier for compilers to generate faster code and so on. Think of them as compiler level linters. Anyway, python has a static gradual typing mechanism. You should try it out :D
twic 9y ago
That reminds me of Kapital [1] - a valuation and risk analysis system written in Smalltalk at JPMorgan, begun in the early '90s and as far as i know still going; 14,000 classes, 400,000 methods, hojillions of dollars of profit, twenty years in service, zero types: http://www.esug.org/data/ESUG2004/ValueOfSmalltalk.pdf http://www.esug.org/data/ESUG2004/ValueOfSmalltalk.pdf
- Koshkin 9y ago
  > 14,000 classes..., zero types In my view, classes are types. (Well, maybe I'm just spoiled by C++.)
  - twic 9y ago
    In C++, classes do indeed define types. Templated classes define whole families of types. But in Smalltalk, classes do not define types. I understand the word "type" to mean a property of a variable which restricts the range of values it can hold, and the set of methods which can be invoked on it. Smalltalk doesn't have any way to do either of those things, so it has no types.
    - Koshkin 9y ago
      But don't objects that belong to a class also effectively have similar restrictions imposed on them? (Otherwise, why have classes at all?)
      - twic 9y ago
        It's true that a class with a set of methods defines a contract with its collaborators about what calls they can make (or what messages they can send, in Smalltalk terms), that is a lot like a type. Smalltalk calls this a "protocol". But they aren't enforced by the compiler; you can still send a message to an object that it won't be able to understand. What happens in that case is that a method called doesNotUnderstand gets called; a class can implement that to try to do something useful (you could implement a proxy this way, for example), but the default implementation throws an exception. I think that a genuine type would prevent the message being sent in the first place - the could would be rejected by the compiler, and would never get a chance to run. Interestingly, it seems that this was planned for Smalltalk, but never implemented; a 1981 article about the design of Smalltalk [1] says: "Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism." [1] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
weberc2 9y ago
That's not "empirically false", it's just not empirically true. Static typing is a big boon to software development, and I use Python in my day job.
- aidos 9y ago
  The OP said "I believe" so obviously we can neither empirically prove or disprove the statement. We can say with absolute certainty that static typing is not required for large codebases, because there are large codebases that are not statically typed.
- chrisseaton 9y ago
  Are there large codebases that are not statically typed? Yes? Then empirically it is false. > big boon But they argued ‘essential’. You’ve watered that down to nice-to-have.

woolvalley 9y ago

All of it is possible, but specific features help in making better software cost less in time and money. For example, nullability annotations reduce nil pointer exceptions. Static typing removes the need to make certain typing unit tests, makes refactors easier to do in large code bases, makes it easier for compilers to generate faster code and so on. Think of them as compiler level linters. Anyway, python has a static gradual typing mechanism. You should try it out :D

twic 9y ago

That reminds me of Kapital [1] - a valuation and risk analysis system written in Smalltalk at JPMorgan, begun in the early '90s and as far as i know still going; 14,000 classes, 400,000 methods, hojillions of dollars of profit, twenty years in service, zero types: http://www.esug.org/data/ESUG2004/ValueOfSmalltalk.pdf http://www.esug.org/data/ESUG2004/ValueOfSmalltalk.pdf

Koshkin 9y ago
> 14,000 classes..., zero types In my view, classes are types. (Well, maybe I'm just spoiled by C++.)
- twic 9y ago
  In C++, classes do indeed define types. Templated classes define whole families of types. But in Smalltalk, classes do not define types. I understand the word "type" to mean a property of a variable which restricts the range of values it can hold, and the set of methods which can be invoked on it. Smalltalk doesn't have any way to do either of those things, so it has no types.
  - Koshkin 9y ago
    But don't objects that belong to a class also effectively have similar restrictions imposed on them? (Otherwise, why have classes at all?)
    - twic 9y ago
      It's true that a class with a set of methods defines a contract with its collaborators about what calls they can make (or what messages they can send, in Smalltalk terms), that is a lot like a type. Smalltalk calls this a "protocol". But they aren't enforced by the compiler; you can still send a message to an object that it won't be able to understand. What happens in that case is that a method called doesNotUnderstand gets called; a class can implement that to try to do something useful (you could implement a proxy this way, for example), but the default implementation throws an exception. I think that a genuine type would prevent the message being sent in the first place - the could would be rejected by the compiler, and would never get a chance to run. Interestingly, it seems that this was planned for Smalltalk, but never implemented; a 1981 article about the design of Smalltalk [1] says: "Also, message protocols have not been formalized. The organization provides for protocols, but it is currently only a matter of style for protocols to be consistent from one class to another. This can be remedied easily by providing proper protocol objects that can be consistently shared. This will then allow formal typing of variables by protocol without losing the advantages of polymorphism." [1] https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

weberc2 9y ago

That's not "empirically false", it's just not empirically true. Static typing is a big boon to software development, and I use Python in my day job.

aidos 9y ago
The OP said "I believe" so obviously we can neither empirically prove or disprove the statement. We can say with absolute certainty that static typing is not required for large codebases, because there are large codebases that are not statically typed.
chrisseaton 9y ago
Are there large codebases that are not statically typed? Yes? Then empirically it is false. > big boon But they argued ‘essential’. You’ve watered that down to nice-to-have.