The advantage of using pure functional language for frontend than JS hack

bucklescript
ocaml
Tags: #<Tag:0x00007fc8374e1388> #<Tag:0x00007fc8374e10e0>

#41

There also is Typed Racket which is a variant of Lisp that allows gradual static typing, as well as e.g. Flow which is a gradual static type checker for JavaScript. :slight_smile:


#42

That sounds horrifying… Why would someone want to do that instead of starting tight and loosening as necessary?! o.O


#43

Even in Haskell there is the push to define your functions with the least constraining types (i.e. most generic) possible - e.g. if even if you are using it with Num require only Eq if that is all you need.

The blog itself was likely written from the perspective of languages without mature type inference - e.g. some changes to a type (more likely class) or switching types results in a cascade of compilation errors due to explicit typing everywhere. Dealing with issues like that is seen as a distracting timesink. I would expect that TypeScript has similar issues because

  1. It constantly complains because the code is incompletely typed in first place, so there isn’t enough information to infer anything (Flow would be similarly affected and overuse of any can seriously undermine it’s capabilities).
  2. TypeScript didn’t set the bar very high in the first place - only really aiming for a C# level of experience.

I find that in the JavaScript community “short time-to-initial-success” is a big deal (see videos above) despite the costs that are imposed on the tail end. Once the complexity of your logic gets to a certain point you need to be at least type aware (at which point you would want to have a competent type checker to have your back).

Unfortunately the mainstream experience with “static typing” is through C/C++/C#/Java which for the most part is an imperfect experience, so all their issues are seen as static typing issues rather than issues with those particular implementations. The mainstream usually doesn’t have exposure to type system/inference implementations of the caliber of OCaml, Haskell, etc.


Functional Programming is Terrible

Rúnar Bjarnason (Functional Programming in Scala) rants how the JVM type system is diminishing the Scala FP experience.


#44

I tend to not prefer typeclasses (I prefer witnesses overall) so I don’t use that, but I could see the point in it, standardized interfaces…

True, without a decent type system it’s a lot harder to do it right.

I thought typescript was ahead-of-time typed, so you always had to type everything? I’ve not used it yet though, but I know purescript requires it. Flow is ‘enhanced’ typing though so it’s not required there, but it does make it ‘better’ the more you add. :slight_smile:

C#'s typing is… well… a joke, like java’s… >.>

C++'s is by default not that great but can become great with proper template usages.

I try to write code that solves the problem now, so try not to overengineer, but I also think about maintainability (because I’m going to be the one maintaining it) at the start, and I want code that makes sense and is easy to refactor for me a year later… ^.^;

I have a feeling most programmers don’t think about their sanity later though… ^.^;

True true, they are all exceedingly poorly typed. :frowning:


#45

Hacker Noon; Two Years of Functional Programming in JavaScript: Lessons Learned


#46

Flow and Typescript fail to work correctly because it’s hard for them to express all that currying and argument polymorphism. Although there’re bindings for Ramda, for example, they often give you false alarms, and when there’s indeed an error, the message is very cryptic and unclear.

This is why Buckerscript, ReasonML rocks and JS sucks …