Hacker News Reader

Comment by naasking | Hacker News Reader

> At some level of software complexity, programmers MUST start to organize data into composite objects.

I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean.

> Copying memory around to enable to facilitate these immutable structures is SLOW.

Slower than what and in what context? Append-only logs in relational databases are immutable data structures, and they enable multiversion concurrency control, which is faster and more scalable than locking when there's lots of contention.

Unqualified claims like "immutable data structures are slow" is just wrong.

View on HN

> I don't understand this point. All functional programming languages have algebraic data types and records, which are composite types. If this is not a "composite object", you'll have to clarify what you mean.

I think they meant data structures, not data types. Things like lists of records that each contain further records.

Data types like records and algebraic types are data structures. Here's an algebraic type for polymorphic lists:

    type 'a list = Nil | Cons of 'a

You and the other person don't understand.

All data structures have types. EVEN lists of records that each contain further records. A type or a data structure is an orthogonal concept to FP, because types exist in imperative programming and data structures also exist in FP.

Note: the log (aka write-ahead-log) in Postgres, and its ilk, enables the D(urability) of ACID. MVCC in Postgres is implemented by storing the visibility info of each row in the row-header (search: xmin, xmax).

Some commercial RDBMSs do use their logs for MVCC, though.

Why have immutable data structures not taken over in the general case if it's a strict improvement? Sometimes they're good and sometimes there not. The issue is functional programming needs them to be used in every case.

Personally I'm of the opinion that purity is impossible so if a paradigm needs purity it's going to be an uphill battle.

FP doesn’t require their use in every case. For example, Clojure allows mutation as an optimization. But for the normal path, immutable data structures are just fine and help avoid a whole host of bugs.

I'd argue that means Clojure lets you use paradigms other than FP. FP is still FP.

Reply on news.ycombinator.com