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

[Qqwy]

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.

[OvermindDL1]

@peerreynders

I often wish I worked in a language where I could start dynamic and end statically. There are a number of languages with optional type systems, but they aren’t the ones that I use. I can imagine writing the core of an algorithm and then gradually tightening the conditions as it comes into focus. More than a tool, this would be a practice: progressive type elaboration. To get there, we probably need as much control of our type system, minute to minute as we program, as we have of our tests.

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

[peerreynders]

@OvermindDL1

Why would someone want to do that instead of starting tight and loosening as necessary?!

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

Functional Programming is Terrible

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

[OvermindDL1]

@peerreynders

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.

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…

@peerreynders

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.

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

@peerreynders

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

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.

@peerreynders

TypeScript didn’t set the bar very high in the first place - only really aiming for a C# level of experience.

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.

@peerreynders

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

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… ^.^;

@peerreynders

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.

True true, they are all exceedingly poorly typed.

[peerreynders]

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

[mkunikow]

@peerreynders

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

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 …

[cdegroot]

@OvermindDL1

C is just assembly with a better syntax really.

I had to think about that remark when reading C Is Not a Low-level Language - ACM Queue earlier today…

Also, I have to quote the closing paragraph of that article here:

There is a common myth in software development that parallel programming is hard. This would come as a surprise to Alan Kay, who was able to teach an actor-model language to young children, with which they wrote working programs with more than 200 threads. It comes as a surprise to Erlang programmers, who commonly write programs with thousands of parallel components. It’s more accurate to say that parallel programming in a language with a C-like abstract machine is difficult, and given the prevalence of parallel hardware, from multicore CPUs to many-core GPUs, that’s just another way of saying that C doesn’t map to modern hardware very well.

Yup