Eval considered

Using eval is almost always a bad idea. It's a crutch for bad designs, it opens giant security holes in your code, and in practice it's almost never needed to get actual stuff done.

>>1
But would my self-improving artificial waifu need to apply eval?

And metacircular eval?

yeah eval is bad. lisp is stupid for having it.

Functional programming considered

http://prog21.dadgum.com/54.html

I've finally concluded that purely functional programming isn't worth it. It's not a failure because of soft issues such as marketing, but because the further you go down the purely functional road the more mental overhead is involved in writing complex programs.

the more mental overhead is involved in writing complex programs

$ ls -lh *

-rw-r--r-- 1 nikita prague 5.2K Dec 08 17:23 how-to-compile.txt
-rw-r--r-- 1 nikita prague 80.9M Jan 30 13:37 program.hs

>>6
Was that supposed to mean something or what?

A critical element of puzzle languages is providing an escape, a way to admit that the pretty solution is elusive, and it's time to get working code regardless of aesthetics. It's interesting that these escapes tend to have a stigma; they induce a feeling of doing something wrong; they're guaranteed to result in pedantic lecturing if mentioned in a forum.

Hahaha barely anyone has ever criticized Haskell so succinctly and devastatingly.

>>7
Mental overhead is unavoidably greater than O(project size) regardless of the language paradigm, so the only way I can see you having more more overhead with FP is if you don't structure your programs correctly.
Thus, the fabricated quote was a sardonic commentary on how I assume >>5 structures their projects.

w4c /prog/ wouldn't have needed that explaining.

>>9
Your logic is somewhere between illusory and retarded. Anyway, to me it is obvious what he meant, even without his example:

Imagine you've implemented a large program in a purely functional way. All the data is properly threaded in and out of functions, and there are no truly destructive updates to speak of. Now pick the two lowest-level and most isolated functions in the entire codebase. They're used all over the place, but are never called from the same modules. Now make these dependent on each other: function A behaves differently depending on the number of times function B has been called and vice-versa.

In C, this is easy! It can be done quickly and cleanly by adding some global variables. In purely functional code, this is somewhere between a major rearchitecting of the data flow and hopeless.

This is the same problem that Haskellers solve with their Debug.Trace clutch ("shit, I thought this function would be pure, but turns out I need it to print debug output"). This is the same problem that arises in tons and tons of cases: a purely functional design is beautiful and minimalistic, with only the barest minimum of dependencies between functions, but changing that design is a pain in the ass.

>>10

function A behaves differently depending on the number of times function B has been called and vice-versa.

So the problem with FP is when it isn't functional in the slightest?

It can be done quickly and cleanly by adding some global variables.

IHBT

>>11
The problem with FP is that life isn't functional in the slightest.

>>12
Who givs a shit when these problems about FP are entirely contained within the program, where it's your imcompetence that is the failure, not FP nor ``life''? State and IO are not unsolved in FP.
Run through the C scenario in >>10 a few more times and you have a garbled mess of dog piss mascquerading as a program. Do it in Haskell or ML, where you change the signatures of functions A and B, and you have 10 minutes of satisfying the compiler followed by an equivalently clean program.

>>13

State and IO are not unsolved in FP.

Please. Monad transformers are not a satisfying solution. And all the others are even worse.

>>14
Is that it? ``I don't like monads'' is the crux of your argument?

haskell is a fucking joke because everyone is programming unsafely with it. what a tragic disappointment. "I'm too stupidto figure out how to structure a program I have to use mutable global variables"

>>15
No, also global state is good which I've found out in practice. Threading stuff through function arguments is painful. What we need to help debugging is protected globals to restrict in which functions a global may be modified.

The functional way of "mutable globals are evil!!1" is like curing headache with an axe.

I take it you've only ever written toy, single-threaded programs.
Plus, if you're threading program state through functions as more than one argument, you're doing it entirely wrong.
type state = { i_am_here: int; enable_frobnicator: bool; _ }
val do_the_thing : state -> state
val go_over_there : int -> state -> state
Oh look, a nice, single place to put your global state. No ``protection'' required and it's just as simple as a smaller functional program.

>>18
Yes, I haven't had experience with concurrent programming yet. But in sequential programming global variables are king. And your

state -> state

thing is inferior because ML and Haskell don't allow in-place modifications. There will be a lot of unnecessary allocations and GC going on: at least the modified record field and the tree spine have to be reallocated on every mutation.

>>19

ML and Haskell don't allow in-place modifications.

You mean the implementations don't do in-place modifications yet as far as you know.

This, too, is false in OCaml (for instance).
Since state is only ever going to have one instance (unless you're including global undo, which will be about 4 loc with immutable data and almost impossible with your global variable business) then the first copy will no longer be referenced by the time you get to using the second copy. That makes it incredibly unlikely that state will survive the minor heap (barring huge calculations between state modifications, but then the cost of state modification is proportionally minimal).
The minor heap is small, always hot in cache and cleaned in constant time, i.e. tuned to shit because pretty much everything uses it. Compare that with global variables scattered all over the place (cache miss party!) and suddenly FP is looking a whole lot faster than you thought.

I wasn't particularly rigorous and I'm sure you can search "how ocaml gc works", but rest assured the gist of it is that short-lived variables, being the main mode of operation for functional programs, are highly optimal in performance.

Actually, mutable state is useful in concurrent programs too. If you have 1 speaker thread and N listener threads, then mutable global shared state is the cleanest and most efficient way to go. To avoid that, you'd have to send messages to all N threads, which would require the speaker thread to keep track of its listeners... fuck, give me mutable shared state any day.

>>21
Problem solved N times over without explicit mutable global state (nanomsg, Erlang, ...), each in a way that actually works with broadcaster and listeners on different machines.

>>17

"mutable globals are evil!!1"

Faggot quotation mark goes to >>>/g/
Also FP and other declarative paradigms don't consider mutability something evil (wannabes who never actually write anything nontrivial in HASKAL do), they just like their mutations explicit and controlled.

Give me a purely functional associative array where all operations that are reasonable alternatives to read and write to a random access perform in O(1). Functional programming has its place, but its place isn't everything.

>>23
I specifically mentioned mutable globals, retard.

GET STUFF DONE!

Use Action Man: The Programming Language to GET STUFF DONE!

Be there, or be x*x!

>>25
Dick
Dick
Dick
Dick
Dick

>>24
Give me a non-functional associative array where all operations that are reasonable alternatives to read and write to a random access perform in O(1) first, or whatever it is you meant to say instead of that nonsense.

>>29
I'm not him, but: Judy arrays.

>>30
https://en.wikipedia.org/wiki/Judy_array

The HP (SourceForge) implementation of Judy arrays appears to be the subject of US patent 6735595

lol

Patenting a data structure.

>>31
That's right goy, all of your Platonic forms belong to the Jew.

>>31
Because it's a damn good data structure, the likes of which you'll never be able to create.

>>31
Not a single line of code, nice.

>>33
Retarded nigger.

>>35
Methinks you might an idiot be!

>>36
>>33-dono is the one that doesn't know how to implement a sparse radix tree.

>>37
Judy arrays are not just sparse radix trees.

JEWDY ARRAYZZZZZZZZZZZZZZZZZZZZ

JUDY DON'T STICK ME IN JUMANJI

JUDY A HAIRY MAN WHO LOOKS LIKE RICHARD STALLMAN JUMPED OUT OF MY BOARD GAME

JUDY A BIG FAT LION JUMPED OUT OF MY BOARD GAME

JUDY HOW COME HALF THE FUCKING HOUSE JUST GOT TORN DOWN BY A STAMPEDE

JUDY YOU'RE SUCH A FUCKING BITCH

>>39
Hey, I still remember that movie vaguely.