Simple made easy

http://www.infoq.com/presentations/Simple-Made-Easy

Rich Hickey's presentation which received a standing ovation from Dr. Sussman.

Complex made hard

http://download.oracle.com/javase/6/docs/api/

Flash
Yeah, no.

This is actually a pretty decent presentation.  How ironic to find it on /prog/.

The rest of this thread is dedicated to debating whether >>4 used `ironic' correctly.

Ok, this will surely "out" me as an imperative programmer, but the speaker's focus seems to be that "state" is bad.  How the fuck do you write anything useful in any language without having "state?"  Any program boils down to code and data, and "state" is just another word for "data."  So now we're supposed to write programs that are all code and no data?  So I should declare all my C variables as const?

>>6
State isn't bad. Purely functional languages have to simulate state using kludgy hacks such as monads. However, abusing state can make a program much harder to debug and maintain than necessary. That's why it should be used carefully.
Of course, a good programmer knows when to use functional style and when to use imperative style.

That said, I haven't listened to that presentation.

>>6 has not reached satori.

>>6
Uncontrolled side effects (such as mutable state+uncontrolled mutations) are bad, not state itself.

But yes, you can go pretty far without mutation. Also, read SICP, mutation is only introduced in chapter 3.

>>7
State isn't bad. Purely functional languages have to simulate state...
That said, I haven't listened to that presentation.

He clearly things that state is bad because it "complects" value and time.  You'll have to watch it to understand what he means by "complect," but I really don't understand what the alternative to state is.  He seems to think it's something called "managed refs" and that sounds like some kind of dog shit you'd find in .NET to me.

>>10
I haven't listened to the presentation too, but I understand what he's saying. He's probably suggesting immutable state along with controlled state (via STM), which is, in my opinion, the right thing to do.
Hickey's got some good ideas, but his problem is that he's the Jobs of programming languages: he really likes to play the revolutionary fucktard, and digress in pointless and sometimes contradictory pseudophilosophical bullshit. There's nothing really new in Clojure, as far as I know, he just combined some good concepts (immutability, STM, code=data) into an inconsistent-from-the-beginning, already broken, frankenstein monster language.

>> 9

how are monads hacks? they seem pretty well grounded in math and CS theory. it's actually quite simple once you become familiar with it.

>>6
in C you do everything in state, even basic things like looping ("++i") require side effects.

In a functional language, you tend not to loop over anything. You transform data structure to new data structures. It's memory inefficient, but it reduces headaches.

>>10
I think by "managed refs" he means transforming data structures to new data structs via function application, which requires automatic memory management. (or headaches.)

>>11

Actually mr. hickey is all about practicality. clojure really doensnt try to be new. it takes the parts that have been proven to work from other functional lang. he's pretty humble and i dont see how he's like jobs at all. have you even used clojure?

>>13
How about an example of this?  Not actual code, but just a problem that would be solved by looping in an imperative language and without looping/state in a functional language.

Also this talk is fucking awesome. This is like the first cool link I've seen on /prog/ in some time.

>>16
http://www.lispworks.com/documentation/HyperSpec/Body/f_mapc_.htm

>>18
TERRIBLE example.  Looking at that page for one second reaffirms everything I've ever thought about functional languages being absolute shit.  If code that looks like that is the alternative to imperative programming, I'll take imperative programming from now until the end of time.  Sorry.

>>16
a simple example...

imperative/side-effects: (C)

void double(int* ar, int size)
{
  for (int i = 0; i < size; ++i)
  {
    ar[i] = ar[i] * 2;
  }
}

functional/basically needs GC (Scheme)

(define (double lst)
  (map (lambda(x) (* 2 x)) lst))

the second returns a new list with doubled contents. The first modifies the list in place. The second has no side effects on anything. (of course, under the hood, the CPU's state is changing a lot, but you never have to think about it.)

basically it's about using arguments and return values. things that help you code this way are: lambda, GC.

>>1
gives a great explanation for the difference between simplicity and ease.

claims that CL and Scheme are complex because of QUOTE, I guess.

wat

>>14
No, by ,,managed refs'' he means ,,managed refs''[1].

>>15
That's (almost) exactly what I said: he took some good ideas and mixed them together. Albeit good ideas, they don't necessarily make the language good.
It's got already broken features, inconsistencies and design warts, but when I look at Clojure it's just to see the evolution of those ideas together, so I don't mind.
Still, I don't accept mindless fanboyism over the language, it's not The Best Thing Since Sliced Bread.

The Jobs part was more an exaggeration, but he does play the revolutionary.

[1] http://clojure.org/refs

>>19
Holy shit, I clicked the link a second time and somehow it was worse than the first.

Ok, let me try this again...  I have an array of pairs of strings.  Say they represent (first_name, last_name).  I want to be able to sort the list by either first_name or last_name.  In C, I'd probably use a simple data structure that's an array of structs, where each struct contains two char * pointers.  To sort them, I walk through the array in whatever fashion my particular sort algorithm requires and I swap structs here and there until my algorithm says that they're all sorted.

In doing this, I've definitely changed a lot of "state" because I've moved those structs around and overwritten memory contents.  What's so bad about that, and how does functional programming do better?

>>20
Stop fucking mentioning the GC, or fucking find and show me the exact part of R[567]RS/CLHS that mentions garbage collection.

>>24
I'm the C guy in this thread and even I can see why his example would lead to a dependence on GC.  You're basically passing/returning everything by value.  You'd better either have infinite memory or GC or find some way to manually manage all those copies of your data.

>>23
in functional programming, your sort function would return a new sorted list (and probably take as an argument, a function to compare the members of the list)

This has the advantage that you don't have to worry about what else might have been using the old list. (for instance, your comparison function) It's still there.

>>25
Keep in mind that the C stack is basically an incomplete garbage collector. It's a form of automatic memory management. It's a fast form, but also limited. Scheme's automatic memory management is unlimited and there's no "now you're working with the stack, now you're working with the heap" thing.

>>26
So use C and pass/return everything by value.  Your program will be 100 times slower and 100 times more wasteful of memory.

Hello Pierre Chapuis.

>>28
not if you're mostly passing structs that look like this:

struct cons
{
  void* car;
  void* cdr;
}

>>25

yup. FP pioneered GC because memory allocation is a side effect and orthogonal to how computation should work. your brain has limited space and should be filled with important stuff, like the actual problem.

>>21
are you retarded? he said that CL and scheme are complex because the syntax can be ambiguous with the case of parens holding both data and computation. clojure has quote too, but it encourages you to use braces and brackets to denote sets and vectors.

>>23
You'd use a list of pairs. To sort them, you make a new (sorted) list from the original list without mutating it in whatever fashion your particular sort algorithm requires and return a new list.
The old list still exists, see >>26.

Functional programming's advantage here over imperative is not really about immutability over the fact that it's possible to write a generic ,,sort'' function, by being able to pass a comparison function to sort.

An example of immutability doing better than mutability is sharing. Wikipedia will probably explain it better than I'll ever do: http://en.wikipedia.org/wiki/Persistent_data_structure#Linked_lists

Also, read SICP, really.

>>25
I know, but there's no point in spamming it in every thread, and there was no point in saying it now. Keep it elsewhere, where it is relevant to the discussion.

>>31
but it encourages you to use braces and brackets to denote sets and vectors.
Last time I checked, Scheme and CL had standard syntax for vectors/arrays, and most Scheme implementations provided syntax for hashes, and CL had reader macros. Something changed while I was away?

it's possible to write a generic ,,sort'' function, by being able to pass a comparison function to sort.

That's possible in all variations of C, and in any imperative language that I know of.  The std::sort() in C++'s standard library takes a comparison function, and that has been true for decades -- never mind the introduction of lambda in C++0x.

This thread has actually reduced my interest in functional languages and I wouldn't have thought that was possible.  /prog/ actually accomplished something today.

>>35
I'm sorry. :(

Maybe a better way: functional programming encourages you to reduce your program down to its essential IO (of which the state of memory and the CPU are not considered a part) and for everything else, describe it in terms of declarative transformations which are easy to manage and reason about.

functional programming languages make this much much easier to do, to varying degrees.

>>35
Purely functional languages suck because they force you to express things uncomfortably at times.

Functional programming languages, especially dynamically-typed ones, allow you a much greater freedom of thought and liberty of code than you will find anywhere else.

Which do you find more readable?

r = [];
for (var i = 0; i < a.length; i++)
  r.append( a[i] * 5 );

or

r = map(
  function(x){ return x*5 + 1; },
  a
);

Functional programming often puts emphasis on recursion or function application (a fancy term you'll see sometimes that just means "calling a function") rather than iteration.

Good examples of functional programming languages are (in alphabetical order) Javascript, Lua, Scheme.  Be careful that Javascript and Lua code is often written in an imperative manner (by programmers who come from non-functional languages), while Scheme programmers try to avoid imperativeness.

To keep in mind with functional languages with immutable elements, while a "new list" of cons cells may have been created during sorting, the data the list references is not recreated. Presumably, in most cases the bulk of the memory use is in the data and not the list itself so performance should be OK.

the second returns a new list with doubled contents. The first modifies the list in place.
in functional programming, your sort function would return a new sorted list
The old list still exists
I have never understood why this is a good thing. Why would you want to keep the unsorted list around unless you needed to use it later? It's a waste of memory and time.

>>35
To me, this thread only reaffirms my belief that functional programming languages and their users have absolutely no understanding of the practical issues of programming in the real world; they believe memory and memory bandwidth is infinite, and so is computation speed.

I have read SICP and studied FP. It's interesting that computations can be modeled without state and the lambda calculus etc., but it's all just mental masturbation. Real computers, and indeed, the Universe as we know it, is stateful (as we know it - because some interpretations of QM assert that new copies are made every time something changes, but regardless, it's state from our point of view.) It's all as theoretical and impractical as Touring machines.

I have seen many beginning programmers write code that makes lots more copies of data than necessary (especially objects, which have more overhead due to constructors etc.), so immutability may be "easier" to think about in some ways, but once you learn how a computer really works (and that should have been the first thing you learned), it's trivial to see how much more efficient it is to not make new copies unless they're actually needed.

>>37

for(int i=0;i<l;i++)
 a[i] *= 5;

>>39
I have never understood why this is a good thing. Why would you want to keep the unsorted list around unless you needed to use it later? It's a waste of memory and time.
Escape analysis gets rid of it.

To me, this thread only reaffirms my belief that functional programming languages and their users have absolutely no understanding of the practical issues of programming in the real world; they believe memory and memory bandwidth is infinite, and so is computation speed.
Don't generalize. Retards are part of any programming language's userbase.

a[i] *= 5;
That's not what my code does; you are doing an in-place modification of the original list, and you forgot to add the one (it's x*5+1). My code assumed that you'd still have to do something with the original list afterwards. Otherwise, were the original list to be discarded, I would have written:

imap(
  function(x){ return x*5 + 1; },
  a
);