Have you read your PFDS today?

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.

hope to reach the performance of a FP solution

If you want a thread safe malloc you can write your own.

You can use pure functional data structures in C by just allocating things and not modifying them.

the programmer hopes the compiler is clever enough to optimize away the overhead, and at the end of the day it turns out it isn't.

malloc/free is dog slow for functional use compared to garbage collectors.

Sorry, but I'm an adult who programs to get things done, not a kid who's just tinkering around for its own sake.

These are solved problems.

If the overhead does become a problem

And while you're doing that, you can enjoy writing your own garbage collector to go with it,

I'm not impressed the solutions you are presenting me with.

Overhead is always a problem.

Here we go again. GC is shit.

Congratulations, you have reinvented GC.

Congratulations, you have reinvented GC.

I get what I need to get done

aren't you curious to see what you could do if it could work 100 times faster and operate in virtual memory on datasets that were 100 times larger?

You have a very narrow idea in your mind of a shared data structure. I bet you assume I use malloc and free as well. And you draw data structures with nodes and arrows like you're in elementary school.

But even in these simple cases, it's stupid that you spend your time wrangling bytes instead of teaching the machine how to do it for you. Have fun reinventing the wheel every single time.

When it matters, you can make the overhead disappear.

This is an amusingly substanceless rebuttal. If you are so enlightened, would you care to sketch out an immutable, shared tree, with minimal memory overhead, and without nodes and branches? Or are you saving that for your master's thesis? Or HIBT?

You force yourself to choose from a limited set of abstractions while I'm free to invent my own.

If you really study how your program is utilizing a shared data structure, you'll likely find the interface is overkill...

Working in Lisp lets you work with true abstraction at the [meta-]expression/declaration level all the way down to assembly code, and all the way up to however high you care to get, without writing fucking inline asm.

Have you read your PDFs today?

gods

1) there is only one holy land (Palestine)

Working in Lisp lets you work with true abstraction at the [meta-]expression/declaration level all the way down to assembly code, and all the way up to however high you care to get, without writing fucking inline asm.

lol, again, have fun playing with bytes.

you are trusting someone else's code to generate asm

you have no ability to improve their generators or add your own abstractions that translate to asm.

It's actually the opposite.

You are also trusting someone else's hardware implementation to execute your asm (see HCF, FDIV), so where do you draw the line?

One word: Lisp macros

everything will be fine

If you don't deal with inline asm, you are trusting someone else's code to generate asm and you have no ability to improve their generators or add your own abstractions that translate to asm.

If you don't deal with inline asm, you are trusting someone else's code to generate asm and you have no ability to improve their generators or add your own abstractions that translate to asm.

since I'm not completely satisfied with any lisp implementation, I've taken my own route.

I write programs that calculate complicated efficient designs starting from simpler ideas.

MOP

At the level you appear to be working, there is no reason to use anything other than lisp, as >>34 says. It's a traceable tower of abstraction from macros down to asm if you write it to be -- and yes, you can write the whole thing yourself without relying on someone else's code generator.

and GC or otherwise is just a detail of implementation of the underlying system.

Lisp implementations today don't produce programs that can be separated from their expensive runtime environments.

The statement GC is or is not slow depends greatly on how you are using it and what the alternatives are.

But if you can avoid it altogether, that's one less thing your program needs to spend time doing

and if you take more control over how things are allocated in memory you can arrange objects compactly to save memory and adjacently to improve cache performance.

Do you live in a world where computer programs do not interact with humans in any way? Who gives a shit if the results come through 8µs faster

You live in a world where 99.99% of battery-powered devices are executing Objective-C, Java, or Javascript.

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

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

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

and is definitely faster for development time,

you're a fucking pathetic idiot for discarding it.

You're wasting your goddamn time.

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

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.

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

I am cudder

Lol, look at me move bits!

No, j00r progarm is slower becuz hooman do better than masheen!

I am cudder!

I write programs to do this for me.

or ignorance about the potential of computingdesire of HW manufacturers to sell product

That's just a roundabout way of saying (like most other pro-GC articles) that the less you have to GC, the faster it is.

Many years ago, Java...

This "GC isn't slow" bullshit really feels like a conspiracy.

An optimal GC will be as fast as manual memory management.

The circumstances of small and fast do not hold the same on modern CPU architectures, with modern connectivity, with supporting modern hardware compatibility, with support of modern file format & encoding variety, and with modern flexible behavioral expectations

Compiler & runtime environment tech has come a long way in the last years, especially due to the fact that regular machines now have the elbow room to analyze the code environment FAR better. The space and speed afforded to us in modern machines are well-used in making the resulting code faster and smaller. That is appropriate use of resources.

So you don't want high-functioning software, and you don't want the computer to be smart enough to manage its own affairs.

Everything you say always points back that you want to be a slave to the machine, enjoying your waste of time in manually tracking bits and cycles.

and you don't want the computer to be smart enough to manage its own affairs.

that you want to be a slave to the machine