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

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

#131

Post by uryga » Sat, Oct 27, 2018, 6:05 PM UTC

KirinDave wrote: post #124

ender7 wrote: post #91

This article is just a recapitulation of the old pure functional programming vs. imperative programming argument but wrapped up in new packaging. Most of these issues, such as needing to validate types at codebase boundaries, functions that have side effects, and unsound static type systems, could just as easily be leveled at most imperative languages (C++, Java). So yeah, go use a proper functional language (many of…

It's not really, though. Because even pure FP folks read this article and say, "This is just nonsense and ill-considered propaganda." For example, the idea that you can't trust Typescript because it might call untyped code but you CAN trust Purescript is just wrong. It's not even just wrong, it's utterly misrepresentative of what actually happens in Elm and Purescript. It's misinformation.

Could you elaborate? Why is it wrong/misinformation?

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

#132

Post by arcticbull » Sat, Oct 27, 2018, 6:06 PM UTC

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…

SQL has a schema, and the way I use it, I generate interfaces with strict types from my schema, specifically because I've run into trouble not doing so.

XML, well, there's the schema language for that, but that's fairly "outdated" and I haven't touched it in ages, but if you've ever looked at an HTML parser, it's borderline sentient because of weak typing.

JSON? That's a huge source of issues. I've run into them professionally and personally, and they cause outages all the time. Thats why protobufs are great (schema) and GraphQL with generated interface is great.

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

#133

Post by always_good » Sat, Oct 27, 2018, 6:07 PM UTC

Kiro wrote: post #32

Quekid5 wrote: post #28

Earlier quoted context omitted.

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?

Well, it's like saying static typing doesn't help you because both statically- and dynamically-typed systems need to do arithmetic. It doesn't really make sense, and nobody is saying static-typing is helpful because it frees you from the shackles of a + b.

The difference is that in a statically-typed system, you're validating data at your boundaries such that they comply with your nominal types that are then compiler-guaranteed to be internally consistent.

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

#134

Post by arcticbull » Sat, Oct 27, 2018, 6:17 PM UTC

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…

I didn't really ignore your comment either though.

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

Correct, but in a statically typed language defensive programming is not required on your part to the same extent (because the compiler enforces a whole set of defenses on your behalf). You'll also forget sometimes, mistype sometimes, check the wrong things sometimes, forget to update some defenses. The compiler won't.

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

The type system enforces you checked the data (by for instance, providing a conversion function `fn convert(input: String) -> Result` which then forces you to handle your error there, and then you don't need to check anything else later.

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

That's half a solution because unless your entire ecosystem is typescript those types are at best aspirational. An improvement to be sure, but still aspirational.

Which, IMO, can all be summed up by "we have automated checks so humans don't have to write them and make mistakes doing so as they go". Outsource the checks to an automated system.

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

#135

Post by raiflip » Sat, Oct 27, 2018, 6:24 PM UTC

erikpukinskis wrote: post #117

Companies and coders will always push themselves to the absolute brink, where they no longer trust the code and the system is nearly unmaintainable. Because every step towards that line has not just cash value, but exponential cash value if it’s a startup. And by constantly pushing themselves into unfamiliar territory coders develop the most impressive possible resumes. They either have relevant experience or have ex…

Sure, if you're going to dump your project in 6 months like a hot potato. Any coder that takes pride in their work knows that constantly piling on more tech debt to push thing out faster only slows down your project in the end. The only exception I can think to this is very early start ups, where if you don't get a product out in 6 months, then the project won't have a future to think about.

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

#136

Post by nv-vn » Sat, Oct 27, 2018, 6:41 PM UTC

tybit wrote: post #58

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

I’m still amazed by how much faster transpiling from Reason is compared to TypeScript or JavaScript is via Babel.

OCaml as a language is so close to a sweet spot between performance and ergonomics in my experience. I'm not sure if the Bucklescript compiler is generally running on Node or natively, but that could also be a big variable at play here.

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

#137

Post by KirinDave » Sat, Oct 27, 2018, 6:42 PM UTC

uryga wrote: post #131

KirinDave wrote: post #124

Earlier quoted context omitted.

It's not really, though. Because even pure FP folks read this article and say, "This is just nonsense and ill-considered propaganda." For example, the idea that you can't trust Typescript because it might call untyped code but you CAN trust Purescript is just wrong. It's not even just wrong, it's utterly misrepresentative of what actually happens in Elm and Purescript. It's misinformation.

Could you elaborate? Why is it wrong/misinformation?

Purescript code calls into untyped code via its FFI for expediency or async integration constantly, for example.

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

#138

Post by incadenza » Sat, Oct 27, 2018, 6:46 PM UTC

scns wrote: post #56

nathan_f77 wrote: post #25

The author talks about Immutable.js, but doesn't mention Records, which have been a real godsend in my application. I use Immutable.Record with types [1] (using Flow), and I feel very confident with this setup. You are forced to set default values for every key, and the code will crash if you try to set a key that hasn't been defined. It's really great to have typed Records (often nested), and I expose the getters as…

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

This all sounds great but I cringe a bit at yet another layer of abstraction in an already insane JS tooling ecosystem.

It seems like half of the time you’re just using the escape hatch to plain JS to stitch all of this stuff together, no?

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

#139

Post by erikpukinskis » Sat, Oct 27, 2018, 6:56 PM UTC

oldboyFX wrote: post #130

erikpukinskis wrote: post #117

Companies and coders will always push themselves to the absolute brink, where they no longer trust the code and the system is nearly unmaintainable. Because every step towards that line has not just cash value, but exponential cash value if it’s a startup. And by constantly pushing themselves into unfamiliar territory coders develop the most impressive possible resumes. They either have relevant experience or have ex…

Could you elaborate on this a bit; do you have any interesting real life examples of this mentality?

Sure.

I worked on the system which is now the customer admin for Square’s ecommerce platform they bought in Weebly.

We were all learning Vuex, while also trying to ship code. Across a half dozen pages we had a half dozen slightly different ways of addressing Vuex data. It wasn’t so much complexity that a professional coder couldn’t keep it straight in their head. But it was a trivial amount of complexity to fix. Two days work, maybe a week. Mostly variable naming.

But we chose to ship that feature because we wanted to prove to the company we could deliver. Now those coders will live with that choice for a log* time. New pages will use another slightly ad hoc scheme.

Eventually some architect will decide something like “Vuex is too conventional, we’ve got too much glue code, should we try switching to Redux or Vuedux?”

And the correct answer for the devs is: yes, it’s good for your resumes.

And (speculation) the engineering management will probably never swallow “we have to do three weeks of variable renaming and function moving to fix this now”. If they couldn’t swallow two days of cleanup in exchange for meeting an arbitrary internal target, they won’t swallow three weeks which probably pushes back a user-visible release.

* I meant to type long, but log time, pun intended

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

#140

Post by adimitrov » Sat, Oct 27, 2018, 7:02 PM UTC

uryga wrote: post #131

KirinDave wrote: post #124

Earlier quoted context omitted.

It's not really, though. Because even pure FP folks read this article and say, "This is just nonsense and ill-considered propaganda." For example, the idea that you can't trust Typescript because it might call untyped code but you CAN trust Purescript is just wrong. It's not even just wrong, it's utterly misrepresentative of what actually happens in Elm and Purescript. It's misinformation.

Could you elaborate? Why is it wrong/misinformation?

Not OP, but I'd guess the idea is that calling untyped code in TS is basically Pushing the Big Red Button, or Launching the Nukes™. When doing that in TS, you do it knowing it's your own responsibility to test and establish trust in the code. And Elm and PureScript are the same. In other words, Elm and PureScript won't save you from screwing it up the way you can with TS.

All pure/statically typed languages have escape hatches. It has been leveraged as a counter-argument to using them. But but but, they will say, Haskell has unsafePerformIO!!! Well, yeah, sure it does. You can subvert the borrow checker of Rust, too.

But you have to do it explicitly. You can grep your code base for "unsafe" (literally). You can lint for that. You can code review for that. You can document it. And that's what makes it OKish. In a way, types are like big fat oven mitts, and you're the lead programmer of a bakery, where you pop buns in the oven all day. You can discard the oven mitts for a time, though, and do whatever delicate work you need your actual fingers for. Just don't touch the hot stuff, lest you get yourself burned!