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

191–200 of 210 posts

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

#191

Post by pas »

mdgrech23 wrote: post #114
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…

100% agree with this. If you're using redux the boilerplate of Typescript is huge. To do that all that work and still have the compiler miss problems at the state level deemed Typescript pointless to me.

Is Redux a TS native library? Angular has typing issues of its own, e.g. Forms are typed with 'any', no easy access to certain HTMLElements' properties, etc., but the rest is okay. (Meaning hard to do bad things without early warning/failure during compilation.)

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

#192

Post by pas »

maxhallinan wrote: post #173
tom_ wrote: post #125

Earlier quoted context omitted.

From your description, that sounds like the compiler accepting something that isn't correct. I'm more interested in the case(s?) mentioned where the types are correct and the compiler won't accept the code. I will have a quick skim through the @types/ramda issues, thanks.

The compiler was telling me that there was no field foo on props but there clearly was.

Lack of inference is usually not considered a soundness issue.

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

#193

Post by rane »

TimJYoung wrote: post #103
dgreensp wrote: post #38

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 s…

All good points, but I'm having a hard time with this statement: "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." I'm trying to think of a statically-typed language that would allow such a thing, and I can't, so I assume that you're…

In TypeScript you could also pass `any` as argument to such function and the compiler would be happy. Of course the noImplicitAny flag helps here, but sometimes you could get `any` from a library with poorly written types as well.

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

#194

Post by ItsMe000001 »

eropple wrote: post #110
ItsMe000001 wrote: post #108

Earlier quoted context omitted.

How much time you spend depends on your data structures. If the easy default options are good enough you don't need to sweat. We make heavy use of disjoint unions, and while the simple case here too is easy, some things that we do - although they still are very simple on the Javascript side - are hard on the type checker (Flow in this case). > TypeScript is not a "complex dynamic" language I don't know what you read…

I don't feel defensive, but I do find your comments interesting and your experience almost diametrically opposed to mine--which is what I said. JavaScript is quite complex and quite dynamic, but the reason TypeScript got me back into doing web stuff was, by and large, because it removes that except for in clearly delineated places (at least, once you turn on strict mode). You're reading in some stuff that isn't inten…

> You're reading in some stuff that isn't intended.

What a coincidence, same thing I said to you! Why do you make a stupid reply when you know it's stupid?

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

#195

Post by marpstar »

leshow wrote: post #158
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…

I would not use typescript without the "strict" compiler option. It enforces lots of things that should have been default and covers a lot of the issues you mentioned.

On a brand-new project, I agree wholeheartedly. To do otherwise is to miss half the benefit, in my opinion.

However, those of us that are in love with TypeScript often want to refactor existing JS into TS, where allowing implicit `any` and allowing `null` make it a bit easier to convert larger codebases.

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

#196

Post by crimsonalucard »

austincheney wrote: post #19
arcticbull wrote: post #14

Earlier quoted context omitted.

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 fo…

Data in itself can be typed. For JSON objects the equivalent type is usually called a Record. Within a single strictly typed program, data is transferred between methods and functions and the shape of this data would be described by a type.

There is not much of a difference, theoretically speaking, when data is passed between functions inside an app, or between apps via some network api. What you describe is actually a real issue in typing. Types are lost across systems. JSON is not strictly typed, neither is XML or SQL. So if I have a typed application that spits out data to these formats I lose type checking. If you think about it, even jumping across abstractions from one typed language (say rust on the backend) to another typed language (say typescript on the frontend) you will lose type safety due to incompatibilities between languages.

I don't know if there's research into or thought going into solving this issue. But a universal type language/syntax that can be translated into respective type systems across api abstractions could lend a lot to safety of entire ecosystems. There is no type safety across http services and designing a system to overcome this issue is very possible and to my knowledge not something people have thought about yet. New idea?

Imagine a language/framework that compiles into web apps and microservices on some cloud provider. The language has syntax that allows me to decorate functions to specify which microservice it runs on. Data transfer between microservices can now be placed in some binary format or maybe the language has syntax that allows me to specify human readability. Either way the language abstracts away the devops and webapp layer and combines it into a single source code... this would allow type checking of the shape of data to not happen just within an app, but across services.

Is there such a framework/language that does this? I'm positive it can be done. I would totally love to work on an idea like this. The microservice fad talked up modularity between services but in practice people realized that microservices are too complicated. Perhaps an entire language framework that combines the web app layer and dev ops layer and adds type checking across services would solve this issue.

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

#197

Post by int_19h »

baddox wrote: post #183
int_19h wrote: post #143

Earlier quoted context omitted.

Does BuckleScript do any runtime type checking? If not, you have the same problem the moment you call out into any pure JS library - your type annotations say what you expect, but JS code can merrily give you something else.

That just means the type annotations are incorrect, and how would runtime type checking solve that?

It wouldn't solve that, but it would prevent the code from running with data that is incorrect according to type annotations. Think of it as a runtime assert that is automatically generated from the compile-time type annotation.

(Unfortunately, the JS runtime object model does not allow for such runtime type checks to be performed with reasonable performance.)

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

#198

Post by cetra3 »

jorblumesea wrote: post #168
cetra3 wrote: post #12

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 thin…

But isn't that true for every software project? You need discipline to avoid most of the garbage that can be created by using any language or framework. I've seen some of the worst java apps before, but no one says "never use java". It's generally accepted that skilled engineers can make clean, easily maintainable apps, and unskilled engineers make garbage apps. This just sounds like sloppy engineering and a total la…

I used to believe that the language didn't have any gauging on the quality of code, but I personally feel that coding in rust has made me a better and cleaner programmer, and I trust my team's rust code more than I do its java code.

It's definitely an anecdotal observation though.

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

#199

Post by TimJYoung »

rane wrote: post #193
TimJYoung wrote: post #103

Earlier quoted context omitted.

All good points, but I'm having a hard time with this statement: "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." I'm trying to think of a statically-typed language that would allow such a thing, and I can't, so I assume that you're…

In TypeScript you could also pass `any` as argument to such function and the compiler would be happy. Of course the noImplicitAny flag helps here, but sometimes you could get `any` from a library with poorly written types as well.

Yep, that makes sense, thanks.

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

#200

Post by 52-6F-62 »

int_19h wrote: post #143
scns wrote: post #56

Earlier quoted context omitted.

With Bucklescript/Reason you get typesafety, immutability, performance and small codesize: >Now we compare the runtime performance: BuckleScript Immutable Map: 1186ms Facebook Immutable Map: 3415ms We also compare code Size: BuckleScript (Prod mode): 899 Bytes Facebook Immutable: 55.3K Bytes source: https://github.com/BuckleScript/bucklescript/wiki/Why-buckle...

Does BuckleScript do any runtime type checking? If not, you have the same problem the moment you call out into any pure JS library - your type annotations say what you expect, but JS code can merrily give you something else.

I have to admit, as much as I enjoy working with TypeScript— this same problem is always on my mind. I find myself continually writing the same tests for type safety that I would in JS. I have to remind myself that, yes the types are safe while writing, but still not quite at runtime. It can lead to pretty fundamental flaws if you’re not careful.
Post reply on HN