5 ms·

Id like to keep immutability and databases separate in this comment. Immutability the supposed "big advantage" of functional languages, is a discussion which i

Id like to keep immutability and databases separate in this comment. Immutability the supposed "big advantage" of functional languages, is a discussion which is one-way. No one ever discusses the implications of a system which is constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. This is not how systems are/should be designed and Im sure as hell not going to use a functional language until functional understands basic common sense. A system that is constantly copying data for no reason will do nothing else.

catnaroek 13y ago
> Immutability the supposed "big advantage" of functional languages No, immutability is just the means. The objective is writing programs that are easier to reason about. > No one ever discusses the implications of a system which is constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. Just because copy assignment requires, well, copying in languages like C++, it does not mean things work the same way in functional languages. Precisely because data structures are immutable, you can internally just pass around a pointer to the data structure and pretend you have copied it (e.g., when you pass it as parameter to another function).
- greatsuccess 13y ago
  You are correct, thats easy to reason about unless you are writing the garbage collector, in which case its pointless to write a garbage collector because there will never be anything to collect and memory will expand infinitely. As for the persistent data structure comments, that has nothing to do with the fact that every function in a functional program has to copy data at such a ridiculously fined grained level that all you are doing is writing a garbage creator. This data that every function creates in the name of immutability is meaningless, void of any purpose and is a bug.
talaketu 13y ago
> No one ever discusses the implications of a system which is constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. see persistent data structure
- deleted 13y ago
  [deleted]
- greatsuccess 13y ago
  I don't believe in this data structure. Its ill informed Rich Hickey nonsense and it doesnt scale and has no purpose but to seem clever.
  - TheHydroImpulse 13y ago
    > Its ill informed Rich Hickey nonsense How so? > it doesnt scale I take it that if many of Clojure's primitives are built using this data structure, it doesn't scale either? Yet some else mentioned how performant it actually is, given that it doesn't copy everything, but merely shares commonality. Given your past comments, this isn't the first time you say something without knowing much about it.
chongli 13y ago
constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. That's simply not the case. With persistent data structures (used in languages such as Clojure, upon which Datomic is built), copying is kept to a minimum. If you've got a million-element hash-map and you want to associate a new key/value pair to it, you copy a path to the root of the tree -- an O(log32N) operation -- and you get a new map with 1,000,001 key/value pairs. Just for reference, log32 of 1,000,000 is ~4. This growth in complexity is so negligible that it ought to be considered constant for most practical purposes.
wging 13y ago
Immutability doesn't mean large amounts of copying. You can exploit the fact that things will never change in clever ways. http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...
lmm 13y ago
Maybe you make more copies. But that can be done in parallel. Immutability makes it much easier to do fully concurrent garbage collection. If I make my program use 3x more (parallelized) CPU time but avoid 500ms pauses, that's a good tradeoff - and in my actual job solving real problems I've seen Haskell beat even carefully written C++ by a factor of 5.
pkolaczk 13y ago
Copying is in many cases faster than mutating data in-place by several threads, requiring blocking and cache synchronization. Therefore, it is easier to scale.

catnaroek 13y ago

> Immutability the supposed "big advantage" of functional languages No, immutability is just the means. The objective is writing programs that are easier to reason about. > No one ever discusses the implications of a system which is constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. Just because copy assignment requires, well, copying in languages like C++, it does not mean things work the same way in functional languages. Precisely because data structures are immutable, you can internally just pass around a pointer to the data structure and pretend you have copied it (e.g., when you pass it as parameter to another function).

greatsuccess 13y ago
You are correct, thats easy to reason about unless you are writing the garbage collector, in which case its pointless to write a garbage collector because there will never be anything to collect and memory will expand infinitely. As for the persistent data structure comments, that has nothing to do with the fact that every function in a functional program has to copy data at such a ridiculously fined grained level that all you are doing is writing a garbage creator. This data that every function creates in the name of immutability is meaningless, void of any purpose and is a bug.

talaketu 13y ago

> No one ever discusses the implications of a system which is constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. see persistent data structure

deleted 13y ago
[deleted]
greatsuccess 13y ago
I don't believe in this data structure. Its ill informed Rich Hickey nonsense and it doesnt scale and has no purpose but to seem clever.
- TheHydroImpulse 13y ago
  > Its ill informed Rich Hickey nonsense How so? > it doesnt scale I take it that if many of Clojure's primitives are built using this data structure, it doesn't scale either? Yet some else mentioned how performant it actually is, given that it doesn't copy everything, but merely shares commonality. Given your past comments, this isn't the first time you say something without knowing much about it.

chongli 13y ago

constantly, needlessly, insanely doing nothing but MAKING COPIES OF DATA. That's simply not the case. With persistent data structures (used in languages such as Clojure, upon which Datomic is built), copying is kept to a minimum. If you've got a million-element hash-map and you want to associate a new key/value pair to it, you copy a path to the root of the tree -- an O(log32N) operation -- and you get a new map with 1,000,001 key/value pairs. Just for reference, log32 of 1,000,000 is ~4. This growth in complexity is so negligible that it ought to be considered constant for most practical purposes.

wging 13y ago

Immutability doesn't mean large amounts of copying. You can exploit the fact that things will never change in clever ways. http://hypirion.com/musings/understanding-persistent-vector-pt-1 http://hypirion.com/musings/understanding-persistent-vector-...

lmm 13y ago

Maybe you make more copies. But that can be done in parallel. Immutability makes it much easier to do fully concurrent garbage collection. If I make my program use 3x more (parallelized) CPU time but avoid 500ms pauses, that's a good tradeoff - and in my actual job solving real problems I've seen Haskell beat even carefully written C++ by a factor of 5.

pkolaczk 13y ago

Copying is in many cases faster than mutating data in-place by several threads, requiring blocking and cache synchronization. Therefore, it is easier to scale.