5 ms·

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 arbitra

by sethev 7y ago

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?

nickbauman 7y ago
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/ https://www.infoq.com/presentations/dynamic-static-typing/
- frankpf 7y ago
  > 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 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 https://news.ycombinator.com/item?id=19131272 [2]: https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q.. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q.... [3]: https://sorbet.run/talks/StrangeLoop2018/#/ https://sorbet.run/talks/StrangeLoop2018/#/
  - nickbauman 7y ago
    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.
mokus 7y ago
> 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)?”
- kazinator 7y ago
  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.
erik_seaberg 7y ago
> 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.
- sethev 7y ago
  You know that but your compiler doesn't (generally speaking).
  - thu2111 7y ago
    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.
- Izkata 7y ago
  So you say, but sqlite has no problem with you storing "fish" in an integer column.
kazinator 7y ago
> 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)))))))))

by sethev 7y ago

nickbauman 7y ago

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/ https://www.infoq.com/presentations/dynamic-static-typing/

frankpf 7y ago
> 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 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 https://news.ycombinator.com/item?id=19131272 [2]: https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q.. https://blog.acolyer.org/2017/09/19/to-type-or-not-to-type-q.... [3]: https://sorbet.run/talks/StrangeLoop2018/#/ https://sorbet.run/talks/StrangeLoop2018/#/
- nickbauman 7y ago
  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.

mokus 7y ago

> 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)?”

kazinator 7y ago
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.

erik_seaberg 7y ago

> 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.

sethev 7y ago
You know that but your compiler doesn't (generally speaking).
- thu2111 7y ago
  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.
Izkata 7y ago
So you say, but sqlite has no problem with you storing "fish" in an integer column.

kazinator 7y ago

> 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)))))))))