re: Global Mutable State VIEW POST

VIEW FULL DISCUSSION
 

It hard to eliminate or even significantly reduce the problems associated with globals, mutables, and state-fulness in JavaScript. Most transpiled languages like CoffeeScript or TypeScript follow the same JavaScript idiom.

One way to do it, and make your web applications certainly more robust and likely more performant is to use Elm instead of JavaScript.

Like Clojure or Haskell, Elm is a functional programming language.

I know that Clojure can target JVM. I've heard (but have never tried) that Clojure can target .NET and JavaScript as well.

Elm was designed to be a "transpile to HTML, CSS, and JavaScript" language. Which makes it very amenable to client-side web development. I'm not sure the same is the case for Clojure-to-JS.

Languages like Rust and D go a long way to help mitigate the problems mentioned in your post, but aren't (in my opinion) suitable for targeting browser-based applications using HTML, CSS and JavaScript.

 

The language is not the reason for global state, it's always the programmer. Even in Haskell you have IORefs and similar for global state.

I use Cycle.js for writing web apps in typescript. As a functional framework, I do not have any global state.

 

That's awesome that you don't have global state!

Functional programming naturally avoids global state, such as member instance variables.

I'll have to check out Cycle.js (I've got 2 years of using TypeScript day in and day out... but we had classes with member variables, so our code relied heavily on global state and moreso smaller scoped global state for instances.)

Pure functions and separation of logic from data can reduce or eliminate global state.

The other parts -- getting rid of mutables and getting rid of state-ful-ness altogether -- are the other challenges of OO that is easy and natural in FP.

code of conduct - report abuse