Fear, trust and JavaScript: When types and functional programming fail • Hacker News Board

Re: Fear, trust and JavaScript: When types and functional programming fail

#11

Post by austincheney » Sat, Oct 27, 2018, 9:36 AM UTC

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is.

You don't need static typing to program defensively. Static typing instead ensures a certain defensive position, but as a developer you can choose to program in such a way even in a dynamic language.

That being said it is foolish to make a blanket assumption that data is doomed to confusion. The state and shape of data is determined by the authoring application and reinforced by the receiving application. If data is shaped improperly then a defect is present in the system, so fix the defect.

If a dose of common sense is still not enough... then program in TypeScript.

Re: Fear, trust and JavaScript: When types and functional programming fail

#12

Post by cetra3 » Sat, Oct 27, 2018, 9:41 AM UTC

I love TypeScript and use it in any new project I create. The author is right though, you need to have team discipline to avoid using the `any` type when it can be avoided, and immutability is not in scope. TypeScript is probably the closest we'll get to my personal ideal of static typing in JS, while understanding that you sometimes need an escape hatch to deal with dynamic typing as JS is a dynamic language.

I think that the focus now should be allowing other more modern languages in the browser by means of Web Assembly. Rust is a great candidate for dealing with immutability and unsoundness concerns. I can't wait for wasm to be fleshed out more.

It does beg the question though, would web development be as ubiquitous and as popular if the core language in was statically typed? Does the freedom JS offer you allow greater adoption overall, meaning that it's beneficial to loosen the type restriction as the ecosystem will flourish because of it?

Re: Fear, trust and JavaScript: When types and functional programming fail

#13

Post by stephenr » Sat, Oct 27, 2018, 9:50 AM UTC

qaq wrote: post #7

sedeki wrote: post #4

Earlier quoted context omitted.

I guess he means ”knows [at compile time]”

if someone invented a typed superset of JS life could be so much easier Oh wait ...

Typescript doesn’t actually do runtime checking though does it?

So if I wrote a library in ts and someone called the built js directly it wouldn’t have any type checking would it?

Re: Fear, trust and JavaScript: When types and functional programming fail

#14

Post by arcticbull » Sat, Oct 27, 2018, 9:52 AM UTC

austincheney wrote: post #11

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. You don't need static typing to program defensively. Static typing instead ensures a certain defensive position, but as a developer you can choose to program in such a way even in a dynamic language. That being said it is foolish to make a blanket assumption that data is doomed to confusion. The state and shape of data is…

It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers.

In theory weak dynamic typing works great. In practice humans suck. Hence checklists.

[1] https://www.newyorker.com/magazine/2007/12/10/the-checklist

Re: Fear, trust and JavaScript: When types and functional programming fail

#15

Post by arcticbull » Sat, Oct 27, 2018, 9:53 AM UTC

Tade0 wrote: post #10

But in JavaScript, the fear is always with you. That's why we have both tests and code reviews. Aside from that I'm surprised the author didn't mention checking constructors. It's arguably the most dependable way of checking if something is of a certain type. But I agree that it's a shame that TS/Flow lose their ability to check types whenever partial application or currying is involved - it's not like it's impossibl…

I did Objective-C work for a decade under such conditions. It's never enough to have tests and code reviews. Static typing is strictly better.

Re: Fear, trust and JavaScript: When types and functional programming fail

#16

Post by arcticbull » Sat, Oct 27, 2018, 9:54 AM UTC

stephenr wrote: post #3

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. Being dynamic doesn't preclude variables from being type checked by the runtime. Reading this just sounds like "javascript has no built in support for type checking, so lets pretend it's not possible" All the time people spent making weird unreadable 'fat functions', but you still can't define the types of arguments you wa…

The runtime is unhelpful unless your tests include 100% code coverage.

Re: Fear, trust and JavaScript: When types and functional programming fail

#17

Post by alehander42 » Sat, Oct 27, 2018, 9:58 AM UTC

ridiculous_fish wrote: post #5

One of the strengths of JS is how the runtime environment can be dynamically interrogated and polyfilled, and how it can often gracefully degrade if there's a mismatch between static assumptions and runtime behavior. Is there a vision for how PureScript/ReasonML/Elm etc. can accomplish the same thing? The brute force approach is to place a boundary between everything external and handle it via an FFI. This adds frict…

Nim is another language with a JS backend and it is also kinda good at this: it has a pretty good type system, but it's easy to use it gradually for JS code.

You have a `JsObject` type (which is basically `any`) which lets you write your Nim->JS code in a dynamic way and cast to static types whenever you need to interface with static parts of your program. You can still also define the type signatures of a JS API as well and have a fully type safe experience, but you can do it lazily: just for the functions/types you need.

Basically you can use a JS api in any way you want: from almost fully dynamically to gradually more and more type safe way

Re: Fear, trust and JavaScript: When types and functional programming fail

#18

Post by Tade0 » Sat, Oct 27, 2018, 10:04 AM UTC

arcticbull wrote: post #15

Tade0 wrote: post #10

But in JavaScript, the fear is always with you. That's why we have both tests and code reviews. Aside from that I'm surprised the author didn't mention checking constructors. It's arguably the most dependable way of checking if something is of a certain type. But I agree that it's a shame that TS/Flow lose their ability to check types whenever partial application or currying is involved - it's not like it's impossibl…

I did Objective-C work for a decade under such conditions. It's never enough to have tests and code reviews. Static typing is strictly better.

I worked on a 150k LOC pure JS codebase for almost two years and my experience is different - if tests aren't enough then they're either not written well enough or there isn't enough of them.

Re: Fear, trust and JavaScript: When types and functional programming fail

#19

Post by austincheney » Sat, Oct 27, 2018, 10:05 AM UTC

arcticbull wrote: post #14

austincheney wrote: post #11

> In a dynamic language like JavaScript, it can be hard to know what the shape of your data is. You don't need static typing to program defensively. Static typing instead ensures a certain defensive position, but as a developer you can choose to program in such a way even in a dynamic language. That being said it is foolish to make a blanket assumption that data is doomed to confusion. The state and shape of data is…

It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…

This completely ignores my comment in its entirety. Do people make mistakes: yes. Does software ever have defects: yes. Typically, people making mistakes in software is called a software defect.

It is absolutely critical in a discussion like this to understand that defects in software are not necessarily defects in data. This conversation is about data, and checks for processing data are already present in various forms. For example when was the last time you complained about weak type systems when working with JSON, XML, or SQL tables?

Re: Fear, trust and JavaScript: When types and functional programming fail

#20

Post by pka » Sat, Oct 27, 2018, 10:08 AM UTC

bad_user wrote: post #9

The article builds a strawman. It's not the types that fail, but the type system and its misuse. > This is like pretending really hard No, that's not pretending — static typing is literally about theorem proving, type theory being equivalent with math logic. This is the famous Curry-Howard isomorphism, types corresponding to propositions. Of course, you can have situations in which your type system cannot describe th…

Did you read the whole thing? This is exactly the point the author is trying to make. Look, you both arrive at the same conclusion even:

> Or you change the game and just use PureScript. Or ReasonML, or Elm, or even ClojureScript.

> If you want to see actual dynamic typing and how it can shine, use ClojureScript. If you want to see actual static typing and how it can kick ass, use PureScript.