Have you read your PFDS today?

Purely Functional Data Structures
http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf

When a C programmer needs an efficient data structure for a particular problem, he or she can often simply look one up in any of a number of good textbooks or handbooks. Unfortunately, programmers in functional languages such as Standard ML or Haskell do not have this luxury. Although some data structures designed for imperative languages such as C can be quite easily adapted to a functional setting, most cannot, usually because they depend in crucial ways on assignments, which are disallowed, or at least discouraged, in functional languages. To address this imbalance, we describe several techniques for designing functional data structures, and numerous original data structures based on these techniques, including multiple variations of lists, queues, double-ended queues, and heaps, many supporting more exotic features such as random access or efficient catenation.

In addition, we expose the fundamental role of lazy evaluation in amortized functional data structures. Traditional methods of amortization break down when old versions of a data structure, not just the most recent, are available for further processing. This property is known as persistence, and is taken for granted in functional languages. On the surface, persistence and amortization appear to be incompatible, but we show how lazy evaluation can be used to resolve this conflict, yielding amortized data structures that are efficient even when used persistently. Turning this relationship between lazy evaluation and amortization around, the notion of amortization also provides the first practical techniques for analyzing the time requirements of non-trivial lazy programs.
 
Finally, our data structures offer numerous hints to programming language designers, illustrating the utility of combining strict and lazy evaluation in a single language, and providing non-trivial examples using polymorphic recursion and higher-order, recursive modules.

>>77

In order words, the statement "GC is slow" (or "makes it run slower than it needs to" and all its variations) is incorrect.

Only when there are no faster alternatives, which is never the case unless you are unwilling to consider faster alternatives.

It's not something the programmer spends time doing, so it's moot.

It leads to a suboptimal program. It's crap.

And because it can be as fast or faster at runtime than manual management,

There's more ways to manage memory than malloc and free. Like memory pools. You can allocate and free memory in constant time and a few assembly instructions with some additional assumptions.

and is definitely faster for development time,

Not if you have meta-linguistic abstraction to do this work for you at compile time.

you're a fucking pathetic idiot for discarding it.

Nope, a rational being.

You're wasting your goddamn time.

No, I write programs to do this for me. The thing is I try to get things right at compile time rather than use some resource intensive overkill monstrosity that figures obvious shit out at runtime.

Your life is useless, because you throw it at shit like this.

The value of my life is independent of these pursuits, and your judgement of it has no bearing for me.

People who are way smarter than you have already solved these problems, but you'll dick around with slower shit, spending months fiddling with bytes and address lines, instead of taking advantage of stuff that's better.

Their solutions are utter shit. And trying to optimize their shit is too fucking hard. I'm starting with bit fiddling and finding the right set of abstractions that will trivially lead to optimal machine code.

Again, you're a child playing with toys. Fuck off, because you have nothing mature to say.

No, the toys are python, ruby, javascript, java, and haskell. And I refuse to waste any more time playing with them.