Hacker News Reader

Comment by noobermin | Hacker News Reader

I might cause a flame here, but I feel like academics and people who give conference talks have adopted stricter typed languages. Actual developers instead embraced from the get-go rather dynamic languages (Python,Javascript,etc.) and continue to use such languages without the type hints because it's easy and they have things to build.

View on HN

IME dynamic typing is super easy and fast until it suddenly isn't. Then you're going through ten layers of functions to check if None is a valid value for some parameter because some intern three years ago figured that would be the easiest way to do it.

I'd say that while there's certainly a ton of purely dynamically-typed code out there, there's also a current reversal of the trend, with static and gradual typing coming back in vogue. Python has fully-supported type annotations, and Typescript is the trendy new way of writing JS. Facebook has ReasonML and Hack/PHP 7. Go and Rust, the current "cool kid" languages, are fully statically typed.

I think that the bad taste left in people's mouths by "enterprise" Java and its 30-character type names is fading, and that we'll see a few years of static types. Then of course the cycle will repeat itself, as is tradition.

My favourite language is Clojure, but this exact thing leaves a bad taste sometimes. Clojure has the attitude that you should validate on the edges, using spec or similar, and then have dynamic types in between. This is really super convenient! However, as the codebase grows, subtle type errors do slip through and it gets rather hard to catch, since its now a runtime error that may not happen until a long time later (and then Clojure's notoriously bad error messages certainly don't help). So you hope your test suite catches it. Luckily, with generative property-based testing, which Clojure has reasonable support for, this can often get caught early, but during tests is still not as early as with a type checker and generative tests could still take a very long time to catch subtle issues (but it catches a lot more than just type errors!). Of course, Clojure also encourages developing in the REPL, so most of the time, you can be pretty confident that it will work before you even run the tests. Still, I feel like some kind of static typed Clojure (not a separate thing like Typed Clojure, which is slow and clunky, but something with first-class static type checking as part of the language) would be awesome. Maybe in reality it would conflict with many of Clojure's other niceties though.

dynamic languages still have strong typing. the given example of type conversion is one of weak typing. it has nothing to do with strict typing that enforces type declarations.

in python this is an error:

  >>> i = 10
  >>> s = "20"
  >>> s+=i;
  TypeError: cannot concatenate 'str' and 'int' objects
  >>> i+=s;
  TypeError: unsupported operand type(s) for +=: 'int' and 'str'

It's a nice error message, but it's a runtime error, it might not happen until weeks into production. It's technically just a crash with a useful error message. "strict typing that enforces type declarations" is generally called static typing, and does not necessarily always require annotations or declarations. It spots such errors at compile time using static analysis.

> it might not happen until weeks into production.

It should never happen in production - there should be a test that proves this.

with declarative or static typing i don't need a test for this case.

That's where a dynamically typed language with optional typing gets handy, when a compiler supports it...

In Common Lisp, the SBCL compiler would be such an example:

  * (defun foo () (let ((i 10) (s "20")) (concatenate 'string s i)))
  ; in: DEFUN FOO
  ;     (CONCATENATE 'STRING S I)
  ; 
  ; caught WARNING:
  ;   Derived type of I is
  ;     (VALUES (INTEGER 10 10) &OPTIONAL),
  ;   conflicting with its asserted type
  ;     SEQUENCE.
  ;   See also:
  ;     The SBCL Manual, Node "Handling of Types"
  ; 
  ; compilation unit finished
  ;   caught 1 WARNING condition
  FOO
  *

To quote Dijkstra, testing shows the presence, not the absence of bugs. If you want to actually prove the absence of these classes of bugs then you need a static type system.

correct, and i am a fan of that too, but the poster above was conflating weak typing with dynamic typing, which are entirely different things.

my preferred language is pike, which is a strong and declarative typed language (declarative typing is the term i prefer since not everyone defines static typing the same way, and some statically typed languages are weak, like this example here)

pike does catch type errors at compile time, but behaves like a strong dynamic typed language at runtime.

i understand that python and rubys optional types now allow for something similar.

As a dev and not an academic, I totally disagree. "dynamic languages" sounds more Kewl than static (well, it's dynamic, innit, it's probably got fundamental synergisms too) but they are a bitch to work with when things get large unless you get really disciplined, and in less careful hands you get bugs. Lisp lovers say it works for them and I won't argue as I've no experience, but in such langs I've used (python, SQL, javascript, VB), well, the road to hell is warm and inviting, especially for the less experienced.

I'm saying this as an experienced dev, please consider from this and others that you may be wrong, and avoid the trouble we've had.

Or not. Everyone has to find their own way.

I’ve just started a project in Go coming from Python and I don’t feel less productive. In fact, I’m digging Go’s decoupling mechanisms when you use interfaces “as intended”. I might get more productive in Go rather than Python soon.

welcome to the fold. Python -> Go dev here and what a refreshing change of pace strong types and a super opinionated language are.

It's common for especially bigger companies that use JavaScript to use some framework that mandates static typing. This is true here at Google, for example.

> and continue to use such languages without the type hints because it's easy and they have things to build

I continue to use python without type-hints because of know of no other similar languages with type-hints that are as popular.

Sure, less strict languages have more production use, but they’re typically older too. That doesn’t mean that conversion bugs aren’t a problem or aren’t hard to find, just that the burden is pushed onto the test suite.

Reply on news.ycombinator.com