Is that really a typing problem, though? If I tried to use a "recived" slot on a Lisp struct that only had a "received" slot defined, I'd get a read-time error, and there's zero typing involved there.

> For four days, I spent debugging a python production script because in one place I had typo'd ".recived=true" on an object and just couldn't understand why my state machine wouldn't work

Is that really a dynamic typing problem or a language that allows you to create instance members anywhere? It seems like that is a flaw in the declaration model of the language and not a static / dynamic issue.

TXR Lisp, a dialect I created:

  $ txr
  This is the TXR Lisp interactive listener of TXR 185.
  Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
  1> (set a.b 3)
  ** warning: (expr-1:1) qref: symbol b isn't the name of a struct slot
  ** warning: (expr-1:1) unbound variable a
  ** (expr-1:1) unbound variable a
  ** during evaluation of form (slotset a 'b 3)
  ** ... an expansion of (set a.b 3)
  ** which is located at expr-1:1

Both warnings are static. If we put that into a function body and put that function into a file, and then load the file, we get the warnings.

The diagnostics after the warnings are then from evaluation.

Those are nothing; TXR Lisp will get better diagnostics over time. I'm just starting the background work for a compiler.

There is dynamic and then there is crap dynamic.

Don't confuse the two.

There is crap static too. Shall we use C as the strawman examples of static? Hey look, two argument function called with three arguments; and there's a buffer overrun ...

It seems to me that you've just invented a static type checker. (Combined with a run-time type checker.) Am I mistaken?

I mean, we can argue the semantics of what, exactly "static type checker" means, but...

Static checking doesn't make a "static language".

A "static language" occurs when we have a model of program execution that involves erasing all of the type info before run-time. Or most of it. (Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.)

Note how above, my expression executes anyway; the checks produce only warnings. The warning for the lack of a binding for the a variable is confirmed upon execution; the non-existence of the slot isn't since evaluation doesn't get that far.

If we retain the type info, we have dynamic typing. There is no limit to how much checking we can do in a dynamic setting. The checking can be incomplete, and it can be placed in an advisory role: we are informed about interesting facts that we can act on if we want, yet we can run the program anyway as-is.

This really sounds like "semantics" to me (not PL semantics! :).

For example, these days it's quite possible to ask GHC to defer type errors to runtime. Does that mean that the GHC dialect of Haskell is dynamically typed? This is basically a command line switch away, btw.

Retention of type information does not "dynamic typing" make. As a trivial example, consider C++ RTTI.

You really have just reinvented static (type) checking and a good runtime. There's no shame in that, but let's not pretend that these are opposing forces.

C++ RTTI is only for class objects, and only useful when they are manipulated by pointer or reference. I believe I covered that sort of thing with my statement, "Some static languages support OOP, and so stuff some minimal type info into objects for dispatch.". It's a gadget which provides an alternative to the structure of doing everything via virtual functions on a base class reference.

Ok, fair enough, but what about e.g. "-defer-type-errors" for GHC?

I still think you're just arguing semantics.

EDIT: Incidentally, the statically typed crowd can even go the "other way", namely from runtime -> compile time. For example, it's quite possible to derive a static proof/type from a runtime value in e.g. Idris by pattern matching as long as you're meticulous about building up the proof.

Not sure it's really an invention, it's been around for awhile. Check any decent common lisp implementation.

I'm pretty sure he doesn't mean invented in a literal sense. The phrasing implies a meaning of reinvented.

Correct, I was being a little bit facetious. All in good fun, obviously :).

>There is dynamic and then there is crap dynamic. (...) There is crap static too.

Excellent. My point exactly. I have no fear of using a static or dynamic language, as long as it is a good implementation of a statically (or dynamically) typed language.

What would you consider good implementations of either?

Good "statics": Haskell, ML family, maybe Rust.

Good "dynamics": All the Lisp-family languages. Smalltalk. Julia. Lua. Tcl.

Plus you can eliminate all typos in any language with a simple statistical linter that you can implement in like an hour or two.

Could you clarify - did you go over all classes in your codebase and added __slots__ attribute? Or you have some tooling to do that for you? I don't have any clear counterargument but that sounds wildly unpythonic thing to do.

> I still write 90% of my useful code in python, but that one week of debugging was exhausting & basically wouldn't have even compiled in a statically declared language.[...]

nothing stops you from using static typing with python3

I haven't used optional typing in python. However, the problem I see with optional typing is that while I may choose to use it my team mates might not. Even more importantly, the 3rd party dependencies I use probably don't. So the amount of code that actually uses the types would be very limiting. Saying the choice is entirely up to you personally is a misnomer.

Strict use of type annotations has to be a team decision, yes. Checking for them can be integrated into a CI build, though.

The typing spec provides for supplementary "stub files" that can be provided for third-party dependencies without their own annotations. The typeshed project provides these for a fair and quickly increasing number of common dependencies, and is plugged into pycharm and mypy by default: https://github.com/python/typeshed

I think GP meant 'you' as in 'your team'. Anyway, Python has a type repository for popular libraries, just like TypeScript does. And mypy can still typecheck your code even without type annotations.

In fairness the hints available in Python 3 aren't really a static typing system. It would take a lot of extra work to make it one.

Well, nothing except almost the whole ecosystem of libraries not having type annotations, those type annotations that exist themselves being quite limited (IIRC), etc. etc.?

Can we stop pretending that adding type annotations to a 'dynamic' language solves the "good static typing" problem? It's just silly.

(About as silly as pretending that static types solve all problems.)

This seems like something a linter can catch though. ESLint certainly seems to give me warnings for use of undefined properties.

That's a kind of error caught by the popular static analysis tools. Better add that pylint and mypy to your travis.yml as soon as possible.