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

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

#151

Post by int_19h » Sat, Oct 27, 2018, 7:34 PM 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…

> Such holes include for example the ability to use Object and then downcast in Java and have the implicit contract that the people using them know what they are doing,

It's worth noting that this is still not quite the same as the leeway that most dynamic languages allow you, because, while you can downcast, all such downcasts are checked. You can't just say that Foo is a Bar, and proceed to treat it as a Bar, in Java and similar languages. You can assert (via a typecast) that it ought to be a Bar - but if it's not, you just get an exception or some other indication of failure.

As a result, it's much, much more difficult to hammer square pegs into round holes in those languages. As it should be.

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

#152

Post by stephenr » Sat, Oct 27, 2018, 7:35 PM UTC

mattbierner wrote: post #146

stephenr wrote: post #13

Earlier quoted context omitted.

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?

No it doesn't. This may not be a popular opinion for those coming from C or Java, but runtime type checks in JavaScript are usually an anti-pattern. If my function defines a contract that the caller violates by passing in null or undefined, then my function should raise an exception when it tries to access `undefined.xyz` or whatever. Otherwise, embrace the duck! If the function can work with what it was given, it sh…

> If the function can work with what it was given, it should

How do you know that it "can work" based purely on the name of the function?

> But be pragmatic

I am. I consider javascript a last-resort option, only really useful for adding minor enhancements client side. Beyond that, I don't use it.

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

#153

Post by int_19h » Sat, Oct 27, 2018, 7:38 PM UTC

Aqueous wrote: post #89

mdgrech23 wrote: post #85

Earlier quoted context omitted.

Switching endpoints may not be option. It's probably not. Why would your company have two endpoints that do the same thing. If it's a third party service you could switch to a competitor but that's not that simple either. Switching jobs? I mea yea you could but again that's not exactly an option for a lot of people. Particularly in the short term. Mean while your app is stuck on a loading screen with an infinite spin…

In many companies, there's also option C - fix it yourself. Any way you slice it, the bug is in the system that's reporting the wrong condition, and adding a defensive check merely papers over an issue with additional code complexity. Sure - your program can degrade gracefully. But that should be for informational / diagnostic purposes only. It doesn't change the fact that you're using a system that is not living up…

To make an analogy pivoting on contracts: modern programming is often not a "rule of law" environment. If you try to pretend that it is when it's not, you're just going to get a lot of pain. And you can't fix everything by yourself.

At some point, the most efficient way to push back against bad code is by validating the contract at the boundary. Then, when that breaks, you have a lot more leverage to go around and demand fixing things.

Or, better yet, use systems that don't allow contracts to be so easily broken. Static typing is an example of that.

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

#154

Post by stephenr » Sat, Oct 27, 2018, 7:40 PM UTC

int_19h wrote: post #148

arcticbull wrote: post #123

Earlier quoted context omitted.

Typechecking at the runtime level means that you have to write tests that traverse every single code path to make sure your code works the way you expect. You can just do this at compile time with static typing. Saves you a lot of boiler plate tests you don't need to write yourself to assert the same thing.

This is where terminology fails us. I really wish the terms "static typing" and "dynamic typing" as presently used would be gone entirely. What you're saying is that explicit type annotations can be enforced at compile time. However, they can also be enforced at runtime, and they're no less safe for that - you just see the errors later, but any call that would be blocked by a static type checker can similarly be bloc…

Thankyou, im glad someone understood the point.

A similar example that web-focused developers are likely familiar with, is type hinting in PHP. For the developer's purpose, there is no 'compile' step (yes the code is compiled and then run, but it happens at request time so its not realistic to compare it to compile time type checking in a compile language like Java).

The 'compile/run' lifetime (in browser based JS) bears similarity to that of PHP: compile time effectively is run time, because it's compiled during the request and then executed immediately.

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

#155

Post by qwer » Sat, Oct 27, 2018, 7:46 PM UTC

arcticbull wrote: post #128

qwer wrote: post #100

Earlier quoted context omitted.

Well don't lose sight of the goal. The goal is less bugs. Static typing is just for internal quality. Users don't give a rat's ass if your types are correct as long as the program works. Proof: Many wildly and massively successful programs are duck-typed. Nobody ever cared to use tests to replicate what a type system does. That's a straw man. Tests go straight for the actual goal by testing actual values. Correct val…

Internal quality is external quality haha. If your types are wrong your program is wrong, and if it just happens to work now wait until more people use it, or you refactor it, or you change the way it works. Your users are basically just fuzzing machines haha. Your statement that "nobody ever cared to use tests to replicate what the type system does" is trivially false, have you ever tested what happens when you pass…

> If your types are wrong your program is wrong

That's not necessarily true though is it? If the "1" in the "1 hour ago" message in the header of your reply wasn't the expected type of the writer of the output function but ultimately still shows up as "1 hour ago" to the user, there's no user-facing defect. I can promise you that this happens all the time in javascript. You're in a thread about Javascript.

> have you ever tested what happens when you pass "null" into a function

Not that I recall. Javascript will throw an appropriate error when it detects that your duck isn't quacking correctly. No one writes validation logic everywhere on internal units, so there's no functionality to verify with a test.

With that said, null is decidedly not "just a type". It's also a value. I generally avoid using null everywhere as much as possible too, because it's a pretty terrible concept.

> Some type systems allow you to even specify valid subranges of types, and combined with algebraic data types, it's effectively impossible to misuse.

Sure but you're in a thread about javascript and typescript. And let's be honest: the vast majority of type systems do not support that.

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

#156

Post by qwer » Sat, Oct 27, 2018, 7:59 PM UTC

TimJYoung wrote: post #105

qwer wrote: post #100

Earlier quoted context omitted.

Well don't lose sight of the goal. The goal is less bugs. Static typing is just for internal quality. Users don't give a rat's ass if your types are correct as long as the program works. Proof: Many wildly and massively successful programs are duck-typed. Nobody ever cared to use tests to replicate what a type system does. That's a straw man. Tests go straight for the actual goal by testing actual values. Correct val…

"Static typing is just for internal quality." Frankly, I don't even know what to do with such a statement. What is your definition of "internal" ? I just did a very large re-factor of a codebase a few days ago where I changed a lot of event handler (method) types in a codebase of around 200K lines of code (Object Pascal). This means that the method signature of every single event handler could have been wrong in some…

Well let me first remind you that you're in a javascript thread. OO Pascal is strict enough that you're not going to get the opportunity to see things work when they get types that they didn't expect because the compiler is unforgiving. So that's going to be hard for you to imagine, but it happens in javascriptland. A function in javascript meant to take a number to output "X hours ago" could very easily get the string "3" and still do exactly what the user expects. That's what I mean by an incorrect type that is internal only, and not a user-facing bug. This is an overly simplified example too. With duck-typing you can often get away with all kinds of not-the-type-that-the-method-expected and live to tell the tale.

I haven't touched OO Pascal in 15 years, so I can't speak to how you would write tests for it, or if there's even a testing framework. I will tell you that I left the if-it-compiles-it-works attitude around that time too though.

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

#157

Post by sgustard » Sat, Oct 27, 2018, 8:03 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…

This seems cynical and wrong. I've never written a line of code for the purpose of "resume padding." Trustworthy code is absolutely useful to a development team.

But writing that code is HARD. Training a growing team to write that code is hard. Banging out new features, on the other hand, is (at first) easy and seems more fun.

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

#158

Post by leshow » Sat, Oct 27, 2018, 8:06 PM UTC

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.

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

#159

Post by leshow » Sat, Oct 27, 2018, 8:10 PM UTC

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…

you can also enable things like "strict", then you need less team discipline, it will be enforced by the compiler. People can still use 'any' explicitly (but not implicitly), however

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

#160

Post by Tade0 » Sat, Oct 27, 2018, 8:16 PM UTC

arcticbull wrote: post #127

Tade0 wrote: post #18

Earlier quoted context omitted.

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.

Think of all the time you wasted writing unnecessary tests that the compiler could perform automatically on your behalf by you properly specifying your types. You'd be much more productive and confident, and have less LOC to maintain. Refactoring would be much easier too.

No type system would measurably help in this case since we necessarily had to deal with browser behaviour which wasn't exactly standardised and tended to change from version to version.