Thinking in Lisp

SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing.
That's because it takes forever to think of the solution in Lisp and Haskell as opposed to a decent language. Faggot lispers will spend most of their time figuring out how best to abuse recursion because they think it makes them leet programmers or some shit.

(defun >>41 ()
  (>>42)
  (print "dubz"))

(defun >>42 ()
  (>>43)
  (print "functional"))

(defun >>43 ()
  (>>44)
  (print "these"))

(defun >>44 ()
  (print "check"))

(>>41)

>>41-45

Why is this considered functional when you can do the same thing in any language?

>>46
Actually, contrary to popular belief, Lisp is not purely functional. What gives people boners about Lisp is macros.

>>40
Single assignment is fucking awful, and if you can't write a compiler that deals with non-SSA and transforms it to SSA, I'm going to have to revoke your Lisp license.

>>48
why is it awful?

and for converting it, I guess this could work:

int f(int n) {
  int a = g(...);
  if(n < 3) a = h(...); // Note the wasted computation of g.
  ...code using a...
}
-->>
int f(int n) {
  int a = g(...);
  if(n < 3) {
     int a2 = f(...); // g is still wasted, but at least is looks ugly, encouraging you to write it like the following instead:
     ...duplicated code to use a2 instead...
  } else {
    ...code using a...
  }
}
// do this bro:
int f(int n) {
  int a;
  if(n < 3) {
    a = f(...);
  } else {
    a = g(...);
  }
  ...code using a...
}

the calls to f(...) should've been calls to h(...).

>>49

oh wait, this would be a better conversion:


int f(int n) {
  int a = g(...);
  int a2;
  if(n < 3) {
    a2 = f(...)
  } else {
    a2 = a;
  }
  ...code using a2...
}

But if g is a pure function, then this is wasteful code in the case that n < 3. Shame on you, making such unnecessary calculations.

>>38
I understand that people may have (usually have) hard time when reading s-exprs. And I agree that people must choose whatever is easier to understand, even C++¹, if you're coming from a imperative background. But I don't think that Lisp is that hard to understand.

People rejecting functional programming because of personal style or aesthetics just deserve every bug and shame that may arise when going on vacancy, or when Apollo 1 burnt, or when Therac-25 overdosed patients or when their billion-dollar jets crashed.

¹ Before learning C++ I tought it was the best language, because of its wide usage. Now I just think that people are dumb.

>>40,48
Implicit parallelization is great. But OpenMP is there for those you know who.

>>52
What I am saying is that Lisp is not necessarily S-exprs.  Lisp is a certain way of doing things, among which homoiconicity and macros

>>38
I find S-expressions very unaesthetic, even to the point that they hinder the reading of the code that they represent.
Personal tastes. I find XML very unaesthetic, but S-Exp's are heaven to read, if properly indented (such as by using Emacs).
Other languages can also become much harder to read the more complexity you add to your expression, yet this almost never happens with Lisp, unless you (ab)use a bit too many reader macros. Before I learned Lisp, I used to just think it's a bit weird, but after spending a week coding in it (and using the right tools to do so), it becomes very natural.

>>28
There's something I never understood, though; in a decent Lisp, should defmacro top-level forms be evaluated one at a time (and injected immediately into the macro environment), such that mutual macro dependency is impossible (e.g. macro abc uses macro xyz and the other way around)?  Doing it any other way just seems like too much pain, if not impossible.  (yeah I'm the fucktard who wants to write a Lisp variant, shoot me)

It's how CL does it. defmacro tends to be a macro which expands to an eval-when form which then sets a function in the global macro environment. Things are a bit more trickier with local macros.

In practice, you'll write code which expands to other macros, which are of course expanded as well, that way you can have mutually recursive macros (in the generated code). However, what you're asking for is a macro used at macro-expansion time which is then used as a macro that calls the initial macro at macroexpansion time, and so on. The problem with this is that you need to compile one macro, but to compile it, you need to be able to fully expand its body, which you won't be able to do because the other macro function referenced in your macro's body needs to be compiled as well, and yet to compile it, you need a compiled version of your original macro (that is, to compile A you need B to be compiled, but to compile B, you need A to be compiled, thus it doesn't make too much sense).

Related:
http://www.lispworks.com/documentation/HyperSpec/Body/m_defmac.htm
http://www.lispworks.com/documentation/lw51/CLHS/Body/03_bca.htm
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/73a48ff3fb098931/

Haskell is the only programming language that I've seen where one spends more time statically typing than thinking.

>>1
If you weren't such an idiot and had minimum english skills you'd know that what that sentence means is that LISP is so easy to code that after you reach a solution for a given problem implementig is pretty much straight forward and fast.

>>49
U MENA if(n < 3) a = h(...); // Note that g(...) probably has side-effects since this is C
Another bullshit strawman argument that assumes C programmers need to have the compiler wipe their asses for them. Are you the same retard who assumed functional programmers are all idiots who confuse equality and assignment (>>15)? If g() is declared with extensions like __attribute__((pure)) or #pragma pure g the compiler should be able to optimize it away even without single assignment. If someone wants to call a pure function whose return value isn't used, either the compiler can figure it out by looking at the definition or the programmer can rewrite the code so it's only called once. No single assignment faggotry needed.

>>52
What I am saying is that Lisp is not necessarily S-exprs.  Lisp is a certain way of doing things, among which homoiconicity and macros.  But the surface syntax does not have to be S-expressions and I would argue that it could still be called Lisp, as long as there is an obvious and trivial mapping to a S-expressions-based Lisp.  I agree with you, rejecting everything that Lisp brings just because of its surface syntax is a tad bit silly.  But there's more than one way to get past it, and it doesn't have to be "well just get used to it".

People rejecting functional programming
With a few exceptions, Lisp allows side effects (but indeed encourages functional programming).  Implicit parallelization does not require purely functional programming style all throughout the language; the compiler must merely prove that a particular time-consuming function is pure, regardless of whatever impure things it does inside.  Functional programming is nice, but sometimes it's cumbersome not to just write things out imperatively.  I can't imagine writing a codec or a cryptographic library in purely functional style.  It's obviously possible (by Turing equivalence), but sometimes you just want to a[i] += f(x,y,z).  Yes, 98% of my functions *are* pure functions (possibly containing impure things like multiple assignments to the same variable), and the remaining 2% will probably be I/O and the likes.

So no, I don't see the point of forcing upon the user S-expressions nor purely functional programming.


Sussman tripped along lispingly. He was on his way to meet his
lover, Abelson, for Valentine's Day. He smiled to see a snake
hopping along, carrying a snake in its mouth.

Sussman was almost from his crotch when he came across a satoric
cake, lying alone on a retarded plate. "That must be a treat
from my small bear," he said to himself, and tripped over to it.
The cake looked big, so he ate it.

It gave him the most lisplike tingling sensation in his lung.
"How unusual!" he said and continued tripping to see Abelson.

When Abelson came out to meet him, he took one look and fell
over.

"What is it?" Sussman cried swiftly.

"Your brain! And your heart!" Abelson said. "They're dyadic!
Can't you feel it?"

Sussman felt his brain and his heart. They were indeed quite
dyadic. "Oh, no!" Sussman said. "I'm a woman!" He, or rather,
she started to cry. "It must have been that satoric cake you
left for me. Did you know what it would do?"

"I didn't leave you any cake," Abelson said. "I got you a SICP.
It must have been that obolescent man who lives nearby. He acts
a little quietly, ever since he compiled a Python."

"But how can you ever love me, now that I'm a woman?" Sussman
sobbed.

"Well, I never knew how to tell you this," Abelson said
satorically, "but I actually prefer women. And I think your
brain is really indeterminate like that."

"Really?" Sussman dried her tears. Sussman kissed Abelson and it
was an entirely monadic sensation, like a huge black snake head
with retarded-looking eyes.

They spent the night having entirely monadic sex, until the cake
wore off suddenly.

Everything was rather awkward after that.

>>58
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?

I don't want to put your opinions on s-exprs down, it's okay to dislike anything. But I think the other two benefits (homoiconicity and macros) outweight the annoyance that s-exprs are to you. Just look at how nice is to deal with JSON when Javascripting. XML and Java do not look as good choices.

And I really think that previous statement holds (about paradigm background). People only have trouble with things that they don't understand clearly. If you get that any program is some transformation f : I → O between an element in I to an element in O, imperative or functional don't matter. My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage). There's nothing wrong with shared state, except that it defeats the whole purpose of modules. Your functions can't be considered modules anymore, and programmers should take extra attention to the enclosing scopes. When you evolve into a big code base and a lot of coworkers, your heat-seeking missiles are “locked”, but can easily retarget your allies without your control or awareness.

>>60
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?
Ah, but you didn't really read my post.  I said that I might still use imperative (i.e. destructive) code inside functions that turn out to actually be pure.  Purely functional languages usually don't let you do that, or let you do it but in a rather awkward way.  If you just meant functional language as in language that puts emphasis on functional programming all while still allowing side-effects, then ignore this paragraph.

I don't want to put your opinions on s-exprs down, it's okay to dislike anything. But I think the other two benefits (homoiconicity and macros) outweight the annoyance that s-exprs are to you.
Ah but you didn't read my post.  I considering the possibility of a "more comfortable" non-S-expression surface syntax that has a direct mapping to S-expressions, thereby maintaining homoiconicity and macros (especially if the source code is preprocessed into S-expressions before any parsing even begins).

My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage).
Well yes, shared mutable state brings in a whole new class of bugs.  This is why I said that whenever I do end up writing impure functions, it's for I/O or for managing around the purely-functional workhorses.

>>59
use [m]

Beautiful, though.

>>61
You seem like a good programmer. Too bad you don't like S-exprs, but to each his own.

2^6 GET

>>64
U MENA (GET (expt 2 6))

def (GET (dubs (check (em) ) ) )

>>61
1. Ok, I thought that you had written “pure” to denote functions with local assignments only, I didn't mention “pure”, and this paragraph is properly ignored.

2. I read your post well, I just don't think you really considered it seriously. Also, it's less appealing for newcomers if they have to install a compiler to a compiler [or interpreter, doesn't matter].

3. So you know that mutation can brings more bugs, but still prefer to take the risk. I almost mentioned it before, but I didn't want to be offensive: I think this attitude is a specific form of “hacker syndrome”, which are mostly based on unprofessional claims.

Also, I'm not a Lisp or functional evangelist, because there's still room for reasonable imperative programs. My only complaint is that people don't have discernment to choose the right tools. There's a good phrase for that [took from the fellow Eduardo Marinho, free translation]: “I don't like to say that people are dumb, in fact they're dumbified”. From my own experience, industry code bases and tools have all kinds of tricks and unclear reasonings. People still don't understand that minimalism is the best-size-fits-all. From personal experience, the most pleasing languages for me where C, Lua and Lisp, maybe Ocaml. Not that they're that good, but they deserve a place in my brain, and are the closest to the first place. Anyway, I'm designing [another] language to interoperate with C and C++ ABI, maybe with some sort of scripting [in the same language], somewhat like a cleaner “C” counterpart to Lua.

>>67
Sorry, but bad programmers will find new and ingenious ways of writing bad code regardless of how much you try to prevent them with your language.  It's a game you can never win.

>>68
I don't want to and never will win this game.

>>24

It's best to not confuse your friendly neighborhood theorem prover.

>>28

A macro in lisp is a function that takes code as an argument, and generates code, which is then executed. So if a macro was to call another macro, the second macro would generate code for the first macro, which would be executed by the first macro, in its effort to generate code for the main program, and then the final result of the first macro would be executed.

>>57

Hi, after filtering out your buttrage, I extracted from your post:

"If the compiler can prove that g is pure, then it can optimize a = g(...); if(n < 3) a = f(...);  to  if(n < 3) a = h(...); else a = g(...)".

That's a nice and easy optimization (assuming the compiler can prove that the function is pure, which reduces to the halting problem in general, but should be easy in most cases), but I prefer to see it clearly in the code. It helps me reason about the efficiency of the program, and it helps me think about what value is actually inside of a. But, to each their own. I'll keep using it, you can choose to not use it. I don't think you have stated why you hate it though. You just say that it is shit, but the only negative thing that you've said about it is that it is unnecessary.

>>61

tail recursive calls to nested functions can be pretty self documenting representations of state change, and control transfer, and they generalize modifications to local variables. Take a step on the wild side, and code in a functional language. Modifications to local variables is not where functional languages limit you, but using immutable data structures can be painful when mutable arrays and hash tables are more suitable. Most functional languages support these though. So all I'm seeing is a failure on your part to learn a different representation for a universal technique, where you are already familiar with a different representation for the technique. If you only want to get things done, then that is fine, but if you want to discuss the trade offs of different paradigms, then you should be open to learning other things, and other ways of doing things.

It's easier to ``think" with object oriented languages like C++.

Fucking /prog/ hispters. Lisp is shit. SICP is obsolete training for programming.

>>71
I guess you could call it a tail call, not necessarily recursive.

>>72
Okay, make good use of C++ and take care of yourself, pitiful human being.

>>73

true, tail call is better. Seeples is good for a lot of things though. This doesn't need to be a which one is better contest.

>>72
but you shouldn't call seeples object oriented. You might offend the one who coined the term.

>>75
What do you mean offend? C++ is an object oriented language.

>>76
It would be better to call it a multi paradigm extension to C.

http://dis.4chan.org/read/prog/1325625255

>>77
It's not a C extension, if that were true then C would be a subset of C++-

>>78
you are being pedantic.

>>71
Take a step on the wild side, and code in a functional language.
I think what you meant is ``purely functional language''.  No, tail recursion is not always the clearest way to express a computation, and forcing the programmer to do it in a specific way sounds like a horrible idea to me.  I love playing around and figuring out new and inventive ways to implement silly things like reverse on lists using tail recursion, but when it comes to implementing larger things, it might not be the best approach.