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.

>>35
Lisp is the #1=(programmable . #1#) programming language. All is open for plasticity.

Have you read your PDFs today?

>>42
oh my gods, le who are le you le quoting??? XD????

>>43

gods

What the shit? Get out of here you heathen scum.

>>43
Satire is the lowest form of comedy and the lowest form of wit.

>>44
Christianity is polytheistic too. They have 3 gods + lesser gods which are called "saints".

>>32
So what you've boiled it down to is "In my specific case, I invent limitations for myself so I can do more work in lieu of having the computer do it for me (as GC). Thus, universally, GC is shit."

Thanks for wasting my time.

>>46
Every christian is a "saint", at least according to their actual book. I don't think they count as lesser gods, though.

>>48
Of course not. According to their actual book, they are all sinners, because all people came short of God's standard.

>>48
Saints count as lesser gods not by the book, but in Christian practice. E.g. Santa Claus is Saint Nicholas and is regarded as a lesser god who brings presents to children every New Year. In Catalonia, they celebrate Saint George's day on 23rd April because St. George is supposedly the patron god of Catalonia. In Scandinavia, they celebrate Saint Lucia's day on 13rd of December, asking that lesser goddess to give light in the coming winter days. Etc etc, there are many lesser gods disguised as saints in the Christian tradition, read here:

http://www.americancatholic.org/Features/Saints/patrons.aspx

Also count the pictures and statues of dudes in any church. Funny for a religion that says "don't worship idols".

catholics are pagans, dolt

niggers

>>50
s/Christian/Catholic/, confessionfag.

The real question is, was the roman catholic church merely a tool of empires, or were the empires merely tools of that church? </tinfoilhat>

>>54
Even non-Catholics have 3 gods: the Father God, the Son God, and the Holy Spirit God. That makes them pagans, too, or at least polytheists.

Is God immutable?

>>57
Why don't you ask Him? Oh, I forgot, he no longer talks to anyone, despite all the magic books being filled with claims God talking to people and giving them visions and messages.

>>58
All Abrahamic religions are really suprematistic and hate-inciting. They are based on a notion of oneness and absolutism:

1) there is only one holy land (Palestine), all other lands are inferior and God doesn't like them

2) there is only one holy tribe (Jews in Judaism and Christianity, Mohammed's tribe in Islam), all other people are inferior and God doesn't ever talk to them

3) there was only one period of time when God was giving His law to man (Judaists believe it's the time of Moses, Christians - the time of Christ, Muslims - the time of Mohammed). Never before and never after did or will God ever impart His holy law to mankind

4) even when God did give His law unto man, he only gave it to his select holy tribe in His select holy land. The other 90% of humanity is just too inferior to receive God's message: all the Eskimos and Aztecs and Incas and Sami and Zulu and Maori and Japanese and the rest just weren't entitled to a holy prophet or at least a holy scripture.

5) there is only one God and anyone who didn't know about Him (due e.g. to living on a remote island around 50 CE and not meeting any missionaries) will go to hell with no chances of salvation; wrong place and time to be born, suckers!

1) there is only one holy land (Palestine)

U MENA ISRAEL

>>34

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.

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.

lol, again, have fun playing with bytes.

I write programs to play with bytes for me.

>>47
It's actually the opposite. You've imposed the artificial constraint that your program must use GC, when it can get by without it. Adding that constraint leads to suboptimal programs. I still have the computer do work for me, but most of that is done at compile time.

>>61

you are trusting someone else's code to generate asm

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

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

One word: Lisp macros. Thread over. Hell, even LLVM and its plugin architecture fits your requirements.

It's actually the opposite.

Don't you "no u" me. I never said it must use GC, I said it's much easier and takes a huge design load off, to which you replied "as long as I write my programs in this severely constrained way, everything will be fine".

>>62

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

If I could fabricate my own hardware, I'd consider reviewing and modifying it. The difference is all it takes for me to generate asm is to learn about it and write programs for it.

One word: Lisp macros

You are correct. I'm also a lispppeerrr. However, since I'm not completely satisfied with any lisp implementation, I've taken my own route.

everything will be fine

Everything could be better. Rather than choosing a simple inefficient design, I write programs that calculate complicated efficient designs starting from simpler ideas.

>>61

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.

Yeah, you don't Lisp at all, bro. Lisp is one of the only languages where you can modify the actual fucking compiler at either compiletime or runtime. Piss off with your shit C assumptions, and quit fucking telling me that my superior languages has the shortcomings of yours. Wallow in your garbage, fuck off, and die. You have no fucking clue what you're talking about and are only making an embarrassment of yourself.

>>64
On some hardware Lisp machines, you could even reprogram the CPU's microcode at runtime, all in Lisp.

>>65
Check this video if you wanna date gay Jews!
https://youtu.be/DXYaIxxx9KY

>>64
Your hostility is misplaced. But if you were really a lispperrr, you would know nothing I said could have implied lisp had shortcomings, since you can inline asm in lisp.

http://www.pvk.ca/Blog/2014/08/16/how-to-define-new-intrinsics-in-sbcl/

I only avoid lisp because of the runtime.

>>67
This le quote here:

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.

That's a shortcoming, and one that Lisp doesn't have. You aren't bound to what the compiler does out of the box, you can make it do whatever you want, at any level.

You don't have to bypass the compiler by generating your own assembly. That's the only tool you keep bringing up, and it's a C-focused shit view. The Lisp compiler is in Lisp in every reasonable implementation, and is fully modifiable. Compiler macros are standard (no, these aren't regular macros). The MOP lets you change the entire OO system. And that's without even getting into the implementation's compiler itself.

>>63

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

This is exactly what lisp excels at. 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. It is done and it is done to death.

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

Is that your job then? Or a hobby? As we discussed in >>31,32 - is the reason you are programming to implement the ideas you are talking about? Because if so, again, you are completely generalising to "GC is shit" and "if you are using GC, you aren't OMG OPTIMISING enough" because that is the domain you are working in. Everybody else is working on something else, and GC or otherwise is just a detail of implementation of the underlying system. You may well have only convinced yourself that bare-metal asm generation is the only way to go because of your current goals.

Of course, if that is not the case, feel free to elaborate on how GC and no GC are relevant to metalinguistic abstraction for anything other than a compiler.

>>68
Stop talking to me like I'm a C stack boy. You have no idea who you're talking to kid. I've been matching parens since before you were born.

But inlining asm fits the spirit of lisp. Why shouldn't I be able to write a loop macro that can translate a certain class of expressions into SIMD instructions, and use lisp itself to do the translation. It's perfectly built for it.

MOP

Overengineered crap. Thanks for reminding me why I've abandoned all known lisp implementations.

>>69

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.

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

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

An underlying detail that makes it run slower than it needs to be. Using such a flexible interface at runtime is convenient but it's never optimal. With compiler time abstractions you can get optimality while still maintaining a simple model of how the program works in source form. GC is the lazy way out and its results show.

>>70
GC isn't slow. And lol at "optimality" as there is no such thing when generating code, because it depends on runtime circumstance.

>>71
There is something eerily familiar about that statement....

>>70

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

I don't know what part you aren't getting.
Your program. Write it in lisp.
Yur program will mostly use code-generating functions you defined yourself.
You will define functions and macros using these code-generating functions. They could take the names of standard library functions and macros, if you like.
You will write your lisp program as anyone else does: using a bunch of abstractions. It will read like any other lisp program. It will run like any other lisp program.
Your program will output another program. You can run that other program.
The program produced won't rely on a lisp runtime or GC or anything, because you wrote the entire stack.
Lisp implementations produce whatever the hell you tell them to.

Keep re-reading >>71 as well.

>>73
Not many people are working on that stack, but that is what I'm getting at and what I'm looking for. No, >>71 is shit.

>>71
Just because there is noise at runtime doesn't mean you can't produce programs that will on average greatly outperform other programs on average. 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.

Wait, who the fuck am I to know who is and isn't working on a lisp stack. Nevermind.

>>75
It's going to be either Lisp, Haskell or an ML in that realm. There's also C++ if you are lucky enough to be sponsored by Apple (LLVM).

>>74

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

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

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

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.

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.

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.

This is why I hate the computing industry. Nothing has changed since the 1950s, when there was nothing but bits, and it was the human's job to manually route them around. People like >>74-chan are actually happy with that. That's either flagrant masochism, or ignorance about the potential of computing. Probably both.

There are the occasional people here & there who actually do perceive how much things suck with computing. However, they either don't know any better and can do nothing but just reinvent the wheel; or they get so lost up their own meta-rectum that they never actually get around to anything useful.

Computing remains at a stasis where humans serve the details of the machine, instead of the centuries-old vision of machines taking care of the details of humans.

Precisely and absolutely because of people like >>74. and cudder

the anti-GC bait is so strong.. it's because there's actually a lot of stupid programmers who actually beleive this

>>25

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

I live in a world where people are increasingly (in fact, the majority now) uses battery powered devices - extra overhead or bad performance directly translates to less battery time.