Hacker News Reader

Comment by sethev | Hacker News Reader

I thought the article was good and addressed a real point of confusion, as evidenced by the two included comments (from Reddit and HN). You can consume arbitrary data using a program written in a statically typed or dynamically typed language. Whether it's decoupled from changes in the data depends on how the code is written and the data model, which have nothing to do with static vs dynamic typing.

To me the stronger argument is that the boundary between programs is dynamically typed (interpreted and checked at runtime). This is true in the statically typed example as well - the JSON is interpreted and checked at runtime, not at compile time. There's nothing your compiler can prove in advance about what's in the JSON that you'll receive at runtime.

If systems that extend beyond a single program require dynamic typing, doesn't it make sense to invest more in ways to do dynamic typing better?

View on HN

I think it's a question of efficacy and productivity. People routinely make mistakes using type systems. While static typing tends to be really good at solving problems it itself introduces (change a type and, wow! My IDE knows where that type is everywhere and can change it for me! Nevermind that only the producer and final receiver should care, it's everywhere now...)

There hasn't been a lot of study on this topic* but what little there is shows that 3% of errors found can be mitigated with type systems, where they do not exist, fixing these classes of errors takes less time than it took to use the type system.

* https://www.infoq.com/presentations/dynamic-static-typing/

> There hasn't been a lot of study on this topic* but what little there is shows that 3% of errors found can be mitigated with type systems, where they do not exist, fixing these classes of errors takes less time than it took to use the type system.

It seems to me like you're cherry picking evidence. Copy-pasting from a previous comment I made in another thread (https://news.ycombinator.com/item?id=19530274):

There is plenty of evidence showing that modern type systems reduce bugs considerably.

In Airbnb, they found out that 38% (!) of bugs could have been prevented by using TypeScript[1].

Another scientific study discovered that TypeScript and Flow could prevent about 15% of bugs in committed code [2]. And these aren't even measuring reduction of bugs in non-committed code!

Stripe is also writing their own type checker for Ruby and engineers have reported an increase in productivity[3].

[1]: https://news.ycombinator.com/item?id=19131272

[2]: https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q....

[3]: https://sorbet.run/talks/StrangeLoop2018/#/

Well what I should have said is there has been a lot of studies on the efficacy of type systems, but much has been shown to be flawed. I haven't looked at your citations mostly because of the use of typescript which I have personal experience with and I know it's not helping. I'm not going to debate this with you, though; too little good papers on the topic so too much heat and too little light. I've spent most of my career using static typed languages in hindsight I've found most of the static typing not helpful for successful projects.

> If systems that extend beyond a single program require dynamic typing, doesn't it make sense to invest more in ways to do dynamic typing better?

Isn’t dynamic typing more or less a default state of not knowing anything at compile time about the values your data will take?

One could equally well ask “given that the boundaries of our systems are necessarily characterized by unpredictability, doesn’t it make sense to invest in more ways to isolate that unpredictability better (e.g. by use of static analysis)?”

No! The "default state" for not knowing anything at compile time about the values your data will take is typelessness, exemplified by machine-oriented languages like BCPL and most assembly languages. In this state, the machine knows nothing about the types of your values at any time. Each operation that you apply to a value just assumes that it has the right type for that operation.

Programs in such languages must be statically type checked --- by the coder.

Sometimes (usually?) those languages define the effects of type punning, so type mismatches are not necessarily errors. The programmer must know which are intentional (to be analyzed for correctness from a type-punning perspective) and which are bugs. This could come from comments or naming conventions.

Dynamic typing is a huge increment over this situation; what is surprising is how early the original Lisp people figured it out, while also inventing useful abstractions like symbols and whatnot.

> the boundary between programs is dynamically typed

Many interfaces have declared, enforced static types. I don't have to write any code to handle

  SELECT birthdate FROM employees WHERE id = ?

returning "fish" because the database would never let it happen.

You know that but your compiler doesn't (generally speaking).

Hence ORMs. It's possible to do much better than ORMs though. The object/relational type system mismatch is a property of how technology evolved, it's not fundamental.

So you say, but sqlite has no problem with you storing "fish" in an integer column.

> You can consume arbitrary data using a program written in a statically typed or dynamically typed language.

Really? Okay, below is something that meets the definition of "arbitrary data". Can some static program process it and evoke its full meaning without the programmer having to develop an ad-hoc dynamic typing system?

  (defun defset-expander (env macform name params newval setform)
    (with-gensyms (getter setter args gpf-pairs gpr-pairs ext-pairs
                   pgens rgens egens all-pairs agens nvsym)
      (let* ((ap (analyze-params params))
             (exp-params (car ap))
             (total-syms (cadr ap))
             (fp (new fun-param-parser form macform syntax exp-params))
             (fixpars (append fp.req fp.(opt-syms)))
             (restpar (if (symbol-package fp.rest) fp.rest))
             (extsyms [keep-if symbol-package
                               (diff total-syms (cons restpar fixpars))])
             (xsetform ^^(alet ((,',nvsym ,,newval))
                           ,,(expand ^(symacrolet ((,newval ',nvsym))
                                        ,setform)
                                     env))))
        ^(defplace (,name . ,args) body
           (,getter ,setter
             (tree-bind ,params ,args
               (let* ((,gpf-pairs (mapcar (op (fun list) (gensym)) (list ,*fixpars)))
                      (,gpr-pairs (if ',restpar
                                    (if (consp ,restpar)
                                      (mapcar (op (fun list) (gensym)) ,restpar)
                                      (list (list (gensym) ,restpar)))))
                      (,ext-pairs (mapcar (op (fun list) (gensym)) (list ,*extsyms)))
                      (,pgens (mapcar (fun car) ,gpf-pairs))
                      (,rgens (mapcar (fun car) ,gpr-pairs))
                      (,egens (mapcar (fun car) ,ext-pairs))
                      (,all-pairs (append ,gpf-pairs ,gpr-pairs ,ext-pairs))
                      (,agens (collect-each ((a ,args))
                               (let ((p (pos a ,all-pairs (fun eq) (fun cadr))))
                                 (if p
                                   (car (del [,all-pairs p]))
                                   a)))))
                 ^(alet (,*,gpf-pairs ,*,gpr-pairs ,*,ext-pairs)
                    ,(expand ^(symacrolet (,*(zip ',fixpars
                                                  (mapcar (ret ^',@1) ,pgens))
                                           ,*(zip ',extsyms
                                                  (mapcar (ret ^',@1) ,egens))
                                           ,*(if ,gpr-pairs
                                               (if (consp ,restpar)
                                                 ^((,',restpar ',,rgens))
                                                 ^((,',restpar ',(car ,rgens))))))
                                (macrolet ((,,getter () ^(,',',name ,',*,agens))
                                           (,,setter (,',newval)
                                              ,',xsetform))
                                  ,body))
                             ,env)))))))))

Yes. A program written in a statically-typed programming language can parse the lisp you have written above.

I believe that such system cannot fully process the data, as is written in that data's specification, without providing the type system that is in that specification.

The requirement for dynamic typing can either come from the language, or it can be "Greenspunned", or some combination of the two.

For instance, in that data we can construct objects, and we can write expressions which interrogate an object's type.

Thus, that is an example of input data whose processing requires dynamic typing.

I'm quite sure it's not. Statically-typed programs can recursively parse data, and they can also monadically (sequentially) parse data. The same is true of dynamically-typed programs.

Likewise academically speaking, statically typed programs can simulate Universal Turing Machines, QED.

If the detailed requirements describing the inputs require dynamic typing, then the statically typed program has to whip up a facsimile of that dynamic typing. It's not an implementation detail; it shows up in visible, testable system behaviors.

And then, there you are, with the possibility of errors that are not caught at your compile time.

I don’t get it. Why are you concerned with compile time?

The debate that the article is addressing is the supposed difference of capabilities between programs written with static vs dynamic types, at runtime.

The situation is not written entirely with static types if the run-time processing requires the expression of dynamic typing. That's based on some actual dynamic typing from the language, or else some ad hoc dynamic types cobbed together in the program itself.

You picked a strange example since so many Lisps were implemented in statically typed languages.

Here's one in C (less than 200 lines): https://carld.github.io/2017/06/20/lisp-in-less-than-200-lin...

Here's one in Haskell: https://www.defmacro.org/ramblings/lisp-in-haskell.html

That first one looks dynamically typed through a List * type, and tags put into pointers. That algebraic type in Haskell also looks dynamic: an Expr can be any one of four things.

This supports the case the article was making. Clearly the type system in Haskell doesn't prevent it from handling arbitrary data - it's hard to imagine a program more open to change in the input data than a Lisp interpreter.

You seem to have a set of rules that you think code in a statically typed language has to follow in addition to the type constraints in order for you to consider it sufficiently 'typed'.

Well, just one rule: if we are looking at type tags at run-time, it's dynamic typing! Whether that be things put into C pointers, or integer fields discriminating unions, or algebraic sum types with pattern matching.

If someone writes Haskell applications by defining an Expr type that is a sum of several dozen things, and then makes al their function arguments and return values of type Expr, is that still bona fide static typing?

Reply on news.ycombinator.com