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.

it's easier for me to think of solutions in lisp then say C/C variants and java

Even easier in Perl for me

however I fail at thinking recursively no matter the language, any tips?

also since when was SQL a programming language?

>>2
You don't want to abuse recursion.

>>4
You don't want to abuse recursion.

>>4
You don't want to abuse >>3

>>1
Nope. It's much easier for me to write Lisp code than Java or most other languages. Once I mostly know what I want to write, I just write it. With other more popular high-level languages, I tend to write masturbatory AbstractFactoryFactories filler instead of just writing what I want, because the language forces me to fit my idea to their way of thinking, instead of allowing me to express the idea as directly and as clearly as possible.

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.
Don't confuse Lisp with Scheme. Sure you can abuse TCO all day long, but most of the time I write in CL, which has decent looping constructs (doesn't mean I don't prefer to write in a declarative manner where possible, but I'm not going to go out of my way to write in a functional manner if what I want is better acomplished some otherway), I don't go out of my way to use TCO.

>>6
I think YHBT and IHBT.  But yes, indeed, Lisp is just a way of thinking about syntax and exposing it bare to the user, and even letting the user write his own (regardless of the surface syntax, of course; sweet-expressions may still constitute a basis for a Lisp no matter what the faggot haters say).  In Lisp, when you notice you're writing boilerplate, you just write a macro (or a bunch of them to get rid of it).  In other languages, you're utterly doomed.

Oh yeah, and recursion is just a way of reducing all loops to a single type of construct, from the computer's point of view.  A proper Lisp user would immediately pull out his own loop macro implementation as soon as he notices one isn't available, or just use map if it fits the bill.

>>6
So then you disagree with the quote that you spend more time thinking than writing? Because you claim you can just write.

I was going to learn lisp, but I couldn't decide on scheme vs clisp

>>9
Scheme is small and clean and you write the way you want.
Common Lisp is huge and bloated and gives you less freedom

>>8
Not exactly, I sometimes spend more time thinking than writing code, but I end up spending much less time doing the sum of both than I would in another language. It's not like you don't have to think what your program has to do in another language, well, unless you got some ``architect'' doing all the thinking for you and he just tasks you to code some specific module, however regardless of that, someone has to do the thinking - in Lisp, you tend to do be able to just translate your thought more directly into code than in other languages.
>>9
Learn both. I mostly write Common Lisp these days because it lets you do a lot more things portably (across many implementations and OSes) than Scheme and overall has many features by default as well as lots of user libraries which just work with most implementations. Scheme is easy to learn either if you already know CL or if you're starting from scratch (although learning CL after Scheme might be harder for some if they dislike the Lisp-n style or other things CL does different from Scheme). Scheme has a small standard document that you can just read in an evening, although of course, if you actually want to understand what the language is all about, you should read SICP and the Lambda Papers.

>>1
being fair (and don't forget, i hate haskell) you almost never write directly recursive functions, you use High order functions (foldr,filter,map,scanl)

if i had to put in number, i would say that 5-10% of my code is pure recursive, the rest is higher order aplication.

>>11
I'm calling bullshit because people in general are able to come up with solutions quicker in procedural languages. It's just how we think.

There are no macros you can create in lisp that has no simple equivalent in C.

In C:

int fact(int n) {
  return(n<2 ? 1 : n*fact(n-1));
}
In Lisp:

(defun (fact n)
  (if (< n 2)
    1
    (* n (fact (- n 1)))))

Look at all those parenthesis!

In all seriousness C is more elegant than any lisp dialect.

>>13
It's how people who more background in imperative programming think. I've heard that people who started out with functional programming have trouble with imperative, because they can't get past the notion of mutable state. n = n + 1? But that's false for all integers, n!

>>13
I can write C faster for certain trivial imperative things, but not for more complex problems, some things that could take me weeks to do in C I can do in days in Lisp. You can think what you want, I don't care, it's a reality for me and it matters not to me if you actually believe me or not - it won't change anything about how I write programs.

>>14
And yet none of those parens have to be typed, you use a structural editor instead. Also your code is broken, CL's defun is not equivalent with Scheme's define. Also both your CL and C implementation is liable to stack overflow, neither is tail-recursive (of course, if you don't want to use tail-recursion, you don't have to, there's countless ways of writing such trivial functions).

>>15
Sometimes imperative makes sense, other times declarative and functional make more sense. Personally, I find declarative and functional work best for complex high-level problems, while imperative works best for low-level problems. I have no problem writing some quick-and-dirty C when it makes sense, then writing some declarative or functional CL. Better use the tool more suited for the job.

>>13
There are no macros you can create in lisp that has no simple equivalent in C.
Then let's see you implement do (http://www.lispworks.com/documentation/lw50/CLHS/Body/m_do_do.htm) in C. And while you're at it, go ahead and implement once-only to avoid any variable capture problems:

(defmacro once-only ((&rest names) &body body)
  (let ((gensyms (loop for n in names collect (gensym))))
    `(let (,@(loop for g in gensyms collect `(,g (gensym))))
      `(let (,,@(loop for g in gensyms for n in names collect ``(,,g ,,n)))
        ,(let (,@(loop for n in names for g in gensyms collect `(,n ,g)))
           ,@body)))))

>>14
If you think parens are ugly, write your own indentation-based surface syntax to sexp compiler.  If you think CL is an ugly manbeast and Scheme is useless, write your own Lisp.  If you think recursion is unreadable, use a loop macro or higher-order function.

>>17
I'm intrigued. What does this macro do?

>>19
When a macro expansion contains an expression passed to the macro, you usually only want it to be evaluated once. If the expansion contains (f x x), for example, where x is (g y), instead of expanding to (f (g y) (g y)), you need (let ((x (g y))) (f x x)). The problem with that is that the name x might already be used, so the new binding will shadow the old one and break your code.

The usual way to get around this is to generated a unique name for the temporary variable using gensym, so instead of

(defmacro m (x)
  `(... x ... x ...))

you would write

(defmacro m (x)
  (let ((y (gensym)))
    `(let ((,y ,x))
       (... ,y ... ,y ...))))

That's a lot of boilerplate, and repeated code is usually a bad thing, so once-only lets you do this:

(defmacro m (x)
  (once-only (x)
    `(... x ... x ...)))

>>20
Shit, x should be ,x in the first and third examples.

>>19
It's a macro which is usually used when writing code generating code (that is, other macros). It generates code that bins some symbols of your choosing to only be evaluated once (this works by generating a let form and doing a very clever form of substition of the bound variables with gensyms), without it, if your macro was passed some state-changing code, or context-dependent code (such as by dynamic bindings and whatnot), it could end up being evaluated more than once and generate the wrong code.
I'll try to give a C example if you're not familiar with Lisp, you have a macro which takes one argument, this argument is supposed to be something that can be evaluated, but cannot be expected to always return the same value, such as i++, yet you only want to use the value of that expression once, not subtitute a i++ in each place you've used that macro argument. You can fix this in C by just creating a local variable, assigning your i++ to it and hoping the macro doesn't use your local variable in special ways (such as some symbol conflict) - it's not really possible to do it right with just text substition, you'd need access to the AST to even have a chance of getting it ``right'' and not just a ``very low chance of failure''.

How dare the programmer have to think a few more minutes and make a good algorithm that isn't filled with bugs and shitty code

>>16
Knock it off. Look at the return type in that C code. It's an integer. It's not designed to take parameters large enough to cause a stack overflow. Of course intentionally giving it values it's not designed for won't work.

>>15
n = n + 1? But that's false for all integers, n!
Only an idiot would be bothered by this. All it takes is understanding that = isn't equality.

Of course people who start off with functional programming will be able to come up with solutions faster in functional languages, but people in general are better with imperative. It's how we think on a day to day basis.

people in general are better with imperative. It's how we think on a day to day basis.

^{[citation needed]}

but people in general are better with imperative.
I don't think that's true, not in any kind of a priori sense.

It's how we think on a day to day basis.
This certainly isn't true. Our thought is not even remotely well-represented by any common programming paradigm.

>>24
Ackermann's function returns an integer too.

>>20-22
Thanks, that's plenty.

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)

>>24
I'd argue the common man thinks closer to Logic clauses like Prolog than Imperative. But even that isn't a good fit.

All it takes is understanding that = isn't equality.
lol!

>>29
What's so funny about that you idiot?

>>30
All it takes is understanding that (+ a b) is (a + b).
And all kinds of “programmers” don't understand this.

>>31
Perhaps idiots who are bothered by this.

>>31-32
Usually Lisp is fucking shit because of its surface syntax.

>>33
Lisp is shit.
Or perhaps you're an idiot who is bothered by this.

リ
ス
プ
。

>>33
Really, I didn't want to offend you.
My point here is the observation that people resist to changes because of such insignificant issues.

Nor “mutation” neither “syntax” are challenges to understanding. At least not for mine.

thinking in lisp is kind of like thinking in lisp

>>34
You are the idiot because you fail to realize that most people find its surface syntax uncomfortable if not unbearable, even after they've "gone past it" and understood the huge benefits of exposing the AST to the programmer (in this case, as a very regular syntax).  And before you bring it up, no, using a special text editor to fix a language's woes simply doesn't cut it.

>>36
Well aren't you quite the gentleman.  A polite post like yours deserves a polite reply.  Yes, people do resist to changes, which you argue to be insignificant, when these changes involve taking away things that they are comfortable with, such as using mutability (or at least some convincing imitation of it) when doing things like x[i] ^= a[i] + b[i] + c; as it often happens in cryptography.  A language should not imprison the programmer into an immutable prison, but rather encourage purely functional style while still allowing you to escape from it when it makes sense (such as for overwriting local variables inside an otherwise pure function).  As a short parenthesis (pun intended), this lack of freedom is one of the reasons I strongly dislike statically typed languages, particularly Haskell.  But that's just me.

As for syntax, well, I strongly believe that a different surface syntax for Lisp would do wonders, provided that it would have a simple and clear mapping to S-expressions.  I find S-expressions very unaesthetic, even to the point that they hinder the reading of the code that they represent.  You might be one of those gifted (perhaps misguided) souls who think they have no issues reading S-expressions directly.  That's alright, as long as you don't tell me (and every other person who agrees with me) that my issue with Lisp's de facto surface syntax is insignificant.

If it's lisp, it's shit.

>>38
If it doesn't follow single assignment paradigm, it's shitkind of hard to prove correctness, and parallelize.