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

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

#141

Post by tom_ » Sat, Oct 27, 2018, 7:04 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…

This has been my experience too. I've done a bunch of these sorts of changes over the years in C++. It's very straightforward: break code, fix errors, run code, fix remaining bugs (if there are any), commit code.

None of these projects had unit tests, but that's fine - you don't really need them for this sort of modification, just some patience, a tolerance for boredom (that, or the ability to suck it up anyway), and a complete lack of concern about messages such as 'ERROR: 0/1,577 file(s) built. NOTE: Error limit exceeded - only showing the first 99,999'.

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

#142

Post by erikpukinskis » Sat, Oct 27, 2018, 7:08 PM UTC

raiflip wrote: post #135

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.

I think most companies do do this, on a rolling basis with different parts of the product.

Except by “dump every six months” it’s more like “after six months don’t add much to that anymore, unless we can dedicate a good three weeks to hacking it into place. And then dump the whole component in three years”.

Since your customer base and business requirements are likely to turn completely over in 3 years this makes some (perverse) sense for a startup.

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

#143

Post by int_19h » Sat, Oct 27, 2018, 7:17 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...

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.

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

#144

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

Kiro wrote: post #33

pka wrote: post #27

Earlier quoted context omitted.

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.

In most modern languages with static types, types are reified - i.e. actual values have some runtime type associated with them, and it's impossible (or, at least, exceedingly difficult) to create a value that has the wrong representation for its type.

In practice, with parsing, this usually means that runtime type metadata is used. Effectively, types become your schema, and you can validate against them as needed.

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

#145

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

stephengillie wrote: post #49

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…

I really like the type system in Powershell and wish JavaScript had something similar. Typescript is a mess by comparison. [string]$String = "Dog"; $String = 5; Cannot convert value 5 to type "System.Objects.String"

This produces a similar error ("Type 5 is not assignable to type 'string'") when compiled with TS:

   var s: string = "Dog";
   s = 5;

The difference is that it's a compile-time error, while in PowerShell it's a run-time check. But what's the difference in this case? Either way, it tells you.

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

#146

Post by mattbierner » Sat, Oct 27, 2018, 7:25 PM UTC

stephenr wrote: post #13

qaq wrote: post #7

Earlier quoted context omitted.

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?

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 should instead of trying to enforce some Java-esque type system at runtime using typeof or instanceof.

But be pragmatic. If there is some critical area of your app that absolutely must never ever throw, typecheck away (although this is JS after all, so it still may throw if it damn well pleases).

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

#147

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

> Being dynamic doesn't preclude variables from being type checked by the runtime.

It kinda does, because in a dynamically typed (as colloquially defined - if you want to debate that definition, that's another discussion) language, variables don't have types - values do.

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

#148

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

arcticbull wrote: post #123

stephenr wrote: post #24

Earlier quoted context omitted.

Huh? If the runtime can guarantee your function receives an instance of a particular class, that's a lot of boiler plate you don't need to write yourself to assert the same thing.

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 blocked by a dynamic checker. I think that's what OP refers to by "runtime checking", not writing explicit asserts.

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

#149

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

Zalastax wrote: post #44

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…

I instead proclaim that it brings you the best of both worlds. Finding the right mix of static/dymamic is a balance act but if you do so you get the benefits of static types (safety, documentation, tooling) and dynamic types (fast prototyping, not having to write convuluted code to please the compiler). What are the killer features that gradual types lose out on?

As the old saying goes, "there's nothing more permanent than a temporary solution".

In the context of software development, it means that "prototypes" get shipped as production code all the time.

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

#150

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

int_19h wrote: post #147

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…

> Being dynamic doesn't preclude variables from being type checked by the runtime. It kinda does, because in a dynamically typed (as colloquially defined - if you want to debate that definition, that's another discussion) language, variables don't have types - values do.

Ok, if you want to be pedantic about it, fine.

Nothing precludes values from being type checked.