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

181–190 of 210 posts

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

#181

Post by arcticbull »

stephenr wrote: post #154
int_19h wrote: post #148

Earlier quoted context omitted.

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) b…

100% it's just as safe, though I doubt the program is more reliable as it's harder to catch issues later on.

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

#182

Post by lxe »

This article explores a lot of things bundled together. One morsel to take away is the bit about inbound data validation.

Type systems needs to work statically as well as at runtime via some kind of reflection API. This way you can unmarshal the data that comes over the wire directly into your language's type system. With JavaScript+TypeScript/Flow, the static type system and the dynamic reflection system is split into two separate paradigms, which in my opinion makes things rather complicated to the point of sacrificing developer productivity.

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

#183

Post by baddox »

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.

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

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

#184

Post by ruslan_talpa »

crimsonalucard wrote: post #172
incadenza wrote: post #138

Earlier quoted context omitted.

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?

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

The comparison is quite unfair. Elm manages a system of 1k nodes accessed by one user while sql manages a system of 1m records accessed by 1k users (i am counting browsers) soo... yeah, leaky. You never ever have to optimize anything in sql when you have tables with 1k rows. It’s the scale of things that forces you to optimize.

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

#185

Post by scns »

crimsonalucard wrote: post #172
incadenza wrote: post #138

Earlier quoted context omitted.

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?

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

I like elm but:

- JS Interop is harder in elm.

- Inferno and some others are a lot faster than elm.

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

#186

Post by mezzode »

emptysea wrote: post #165
mdgrech23 wrote: post #114

Earlier quoted context omitted.

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.

Not sure which specific issues you encountered, but I had issues with defining actions and using their types in a union to the reducer. There is a nice little library [1] that fixes this issue. So a general redux setup looks as follows: const FETCH_USERS_BEGIN = "@@FOO/FETCH_USERS_BEGIN" const FETCH_USERS_SUCCESS = "@@FOO/FETCH_USERS_SUCCESS" const FETCH_USERS_ERROR = "@@FOO/FETCH_USERS_ERROR" const fetchUsersBegin =…

I've found myself preferring type guards for checking action type, since it avoids you having to have keep one big `Actions` union around that takes X amount of lines and really doesn't serve any other purpose.

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

#187

Post by TimJYoung »

qwer wrote: post #156
TimJYoung wrote: post #105

Earlier quoted context omitted.

"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 stri…

Yes, I understand how JS works. My company markets and sells a web development IDE that includes an Object Pascal->JS compiler.

Re: your definition of "internal": I suspected that this was what you meant. I also disagree with this particular version of "correctness". If the developer intended that a particular function accept an integer, then accepting anything else is essentially a bug, and the fact that it works at all is down to pure coincidence.

As for writing tests in OP: you write tests in the same manner that you do with Java, C++, C#, etc.

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

#188

Post by crimsonalucard »

ruslan_talpa wrote: post #184
crimsonalucard wrote: post #172

Earlier quoted context omitted.

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

The comparison is quite unfair. Elm manages a system of 1k nodes accessed by one user while sql manages a system of 1m records accessed by 1k users (i am counting browsers) soo... yeah, leaky. You never ever have to optimize anything in sql when you have tables with 1k rows. It’s the scale of things that forces you to optimize.

elm is a high level abstraction that's faster then simpler lower level abstractions like jsx or vue. That's why it's a really good abstraction.

SQL is a leaky abstraction not because of scale. Scale is a requirement and the chosen abstraction for scale is actually not the wisest choice. SQL is an expression based language used to execute algorithms like binary search that are inherently imperative. Thus it is a bad abstraction and the scale of the requirements magnifies this. The need for the EXPLAIN ANALYZE key words exemplifies this flaw. A good abstraction for databases would be a language that explicitly declares the algorithm used for the query. This would make users able to explicitly optimize the query without needing to cross the barriers of abstraction. Like googles V8 implementation of javascript, ubiquity and tons of resources invested into creating an incredibly efficient implementation of an interpreter have made SQL and javascript the best choice for their respective fields even though they wouldn't have been the best design choice if people were given the choice to start over.

Rust is a better design then C++ but again ubiquity, early adoption and random forces have made languages with questionable design choices the dominant paradigm.

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

#189

Post by crimsonalucard »

scns wrote: post #185
crimsonalucard wrote: post #172

Earlier quoted context omitted.

Try elm. The elm abstraction is probably the only one where you literally will never ever touch javascript or raw html. It is the least leaky abstraction I have ever encountered, which is amazing given the fact that it is also blazingly faster than every other framework from React to Vue. Elm is a way higher level abstraction then jsx or Vue yet you don't need to understand the lower level details to produce more eff…

I like elm but: - JS Interop is harder in elm. - Inferno and some others are a lot faster than elm.

The JS interop is basically a leak in the abstraction. It in itself is a flaw and I'm claiming that elm is such a good abstraction that you don't need to access or touch the holes in the abstraction.

Never heard of inferno... I'll check it out.

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

#190

Post by cannabis_sam »

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?

I think it’s the worst of both worlds, you still have to deal with types (often manually even), but you can’t trust your types since they’re not pervasive.

The killer feature is global type inference. I pretty much prototype in Elm as fast (or faster) than any dynamic language, and when the code compiles it’s free of runtime error except at the boundaries (i.e JS interop). This allows me to focus on fixing error arising from my misundetstanding of the problem (and my general incompentence).

Post reply on HN