Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

reaktor.com

Post reply on HN
Print view View original

31–40 of 210 posts

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

#31

Post by OrderlyTiamat »

pka wrote: post #20
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.

But the conclusion doesn't jive with the comments he was responding to. I found the article a bit annoying because of that, though otherwise interesting.

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

#32

Post by Kiro »

Quekid5 wrote: post #28
Kiro wrote: post #23

Earlier quoted context omitted.

How would static typing help you if it's two different applications like the post you reply to is talking about?

You can insert whatever level of validation you need at the untyped interface between the two... just as you would with dynamically typed languages.

So using static typing doesn't help you in other words since you need to do the same runtime validation as with dynamic languages?

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

#33

Post by Kiro »

pka wrote: post #27
Kiro wrote: post #23

Earlier quoted context omitted.

How would static typing help you if it's two different applications like the post you reply to is talking about?

You try to parse the received data into a predefined data type, if this fails you are forced by the type system to handle the failure scenario, if it parses correctly you now have a 100% valid data structure you can work with in the rest of your codebase, no defensive checks necessary.

How does that work? I thought static typing was only checked when compiling.

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

#34

Post by Sawamara »

dsign wrote: post #6

Broken promises in Javascript? ... unsurprising ... Here is an imaginary article that I would read: "New web platform runs entirely in webassembly generated by well-typed languages". Subtitle: "When hand-written Javascript is detected, continuous integration activates subdermal shock-collar that each of the developers is contractually obliged to have".

I just love how you managed to come off more elitist than an ivy league school frat boy realizing that there are workers cleaning up his mess after every party they throw.

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

#35

Post by Sawamara »

maxhallinan wrote: post #22

> in various cases the types are wrong and the compiler doesn’t care It's disturbing how often I encounter this in TypeScript. Or its inverse: the types are correct and the compiler is wrong. Or a third common problem: the types for a library are incorrect. The unsoundness of TypeScript is not merely theoretical. The compiler is frequently just wrong. For that reason, I am mystified by the amount of enthusiasm for Ty…

Typescript brings much needed order to the complete (seemingly) typeless nature of Javascript. That is the source of enthusiasm. TS is the direct result of a development team working out the kinks of having to maintain a large JS codebase.

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

#36

Post by sbr464 »

I agree that defensive checks may clutter code, but in the current landscape of constant security issues, to not use a battery of defensive checks whenever dealing with input is simply naive, no matter the IDE, compile language or runtime language.

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

#37

Post by tempodox »

Tade0 wrote: post #18
arcticbull wrote: post #15

Earlier quoted context omitted.

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.

You would never be able to write the infinite amount of tests necessary to supplant static typing, let alone run them.

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

#38

Post by dgreensp »

Static types are great because they make certain classes of bug impossible to write, but they have their limits. There are escape hatches, like casts and Object types, even in statically-typed languages, though fewer of them in languages with more advanced type systems. There are reasons to like PureScript over TypeScript, just as there are reasons to like Haskell over Java. TypeScript doesn’t give you a way to ban side effects, for example, being part of the imperative family of languages that it is. So if you are super into banning side effects you might like a language that does.

The thing to realize is that at the end of the day, all you are doing is reducing bugs, and while your type system (IMO) really can help reduce bugs, it will never catch all bugs. There is still value in a function declaring that its argument is of type User (and not defensively checking it) even if it is theoretically possible, in the presence of a bug, though unlikely, that the argument is not really a User. The function has said what its precondition is, and (assuming you are validating any data that comes over the network or from an untyped source), this precondition will in practice be checked 99% of the time. If a bug happens to line up with a hole in the type system, you’ll just have to debug and fix it.

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

#40

Post by messit »

It fails all with the teams opinions. It's the people not the language or tools. All these discussions of developers trying to be correct. You don't need typescript, flow, functional programming, OOP, whatever. These tools have it's place particularly because teams cannot work together and need some kind of rules. In most cases individual developers differ quite a bit from each other, especially when it comes to their opinions. It's dramatic.
Post reply on HN