Global Mutable State

Eric Normand on September 18, 2017

One of the biggest problems in software is global mutable state. It makes your code difficult to work with, and once you go down the road, it kee... [Read Full]
markdown guide
 

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.

 

Nice writeup. Rust deals with the mutable part of this triple-whammy by adding mut syntax into the language to mark a binding as mutable.

In this way, all variables are immutable unless they are explicitely marked as mutable. Trying to modify an immutable variable will result in a compile-time error. It also has the added benefit of allowing the compiler to warn you if you've marked a variable as mutable unnecessarily.

I think this helps keep the thought of immutability in your mind when programming. It also allows another developer to know which parts of a program contain mutable state.

 

Awesome article!

This will be on my all time favorites, for sure 😁

 
 

Maybe it's just me, but aren't you first counting lines of a file and then iterating over each line in the same file and appending line count to each line? Effectively reading through the file twice.

Looks like a bug to me...

 

Nice post! I like how you reduced 20+ lines of code to just 3 lines. πŸ‘

 

Pony is an object-oriented, actor-model, capabilities-secure programming language that handles mutability really well. ponylang.org/discover/

code of conduct - report abuse