Fad Oriented Programming

Is it time to declare object orientation officially over and allow functional programming to take the crown as the latest fad?

Also, do you think logical programming will be next? Maybe I should brush up on my Prolog.

> (defn foo (a b)
(display "HW!"))
java.lang.IllegalArgumentException: Parameter declaration a should be a vector

So much for a fucking LISP.

>>41
Clojure is a member of the Lisp family of languages. Many of the features of Lisp have made it into other languages, but Lisp's approach to code-as-data and its macro system still set it apart. Clojure extends the code-as-data system beyond parenthesized lists (s-expressions) to vectors and maps. Thus vectors and maps can be used in macro syntax, have literal reader representations etc.

Lisp data, and thus Lisp code, is read by the reader. The result of reading is the data structure represented by the forms. Clojure can compile data structures that represent code, and as part of that process it looks for calls to macros. When it sees one, it calls the macro, passing the forms themselves as arguments, then uses the return value of the macro in place of the macro itself. Thus macros are functions that are called at compile time to perform transformations of code. Since code is data, all of the Clojure library is available to assist in the transformation. Thus macros allow Lisps, and Clojure, to support syntactic abstraction

>>42

extends the code-as-data system beyond parenthesized lists

Thus, it's not a List-Processing Language. And the programmer has extra irrelevant shit to worry about when writing macros. It's not sufficient to generate s-expressions anymore, you have to remember where there should be a vector and where there shouldn't.

Anus-Processing Language. Everything is an anus.

>>40,41,43
Scheme is obviously also not a Lisp.

> (car 1)

warning: argument type error [diagnose-call-error]
(car 1)
(procedure wants: (:pair))
(arguments are: (:exact-integer))

assertion-violation: argument of wrong type [car]
(car 1)

>>45
You're confused. What you see in Scheme is a type error, but what Clojure complains about in >>41 is a syntax error.

You see, we've already acknowledged that Lisp code can operate on various data structures. The question is whether the code itself is made up of s-exps exclusively. In Scheme, it is. In Clojure, it's not.

Take Racket for example. You'll often see []'s mingled with ()'s in people's code. Does that mean Racket is not a Lisp? No, it doesn't, because in Racket []'s are equivalent to ()'s (so it's possible to use only ()'s or only []'s if one so wishes). Thus, when writing code by hand or working with syntax objects, one does not have to worry about any non-homogenous syntax. It's lists all the way down. But in Clojure, you're locked into that overtly complex syntactic prison. You have to know which goes where, lists or vectors, ()'s or []'s, they have their strictly defined places. You have to keep another layer of syntax complexity in your head. And all of this for no reason because s-exps have proven themselves to be perfectly valid and fitting to represent code. That's why Clojure is not a Lisp (and hence crap).

>>46
Other lisps allow you to use vectors in code with #() instead of Clojure's [] and procedures may expect vectors as arguments instead of s-exps.

>>47

allow you to use vectors in code with #()

Those are vector literals. They're atoms, thus s-exps.

and procedures may expect vectors as arguments instead of s-exps

Really? What "Lisp" would that be?

>>46
You're plainly full of shit. Ignoring your lies about syntax, I will press on.

Clojure "code" (strings, like any lisp) can be have any transient representation, like (like any lisps.) Whether or not this is so is a meaningless distinction because the terminals in any other Lisp are almost never represented by lists just like in >>41 except in toy examples.

If you read your SICP you would know you can have a lisp without any lists at all, and still run all the programs, as written, presented in the book.

>>49

"code"
strings, like any list

You're plainly full of shit. Lisp code is directed acyclic graphs, not strings.

And where did I lie about syntax, you full-of-shit retard?

>>49
Also, internal representations are irrelevant. Syntactically Lisp code must be lists, exclusively. If you can't cadaddr everything, if you have to watch out for some non-sexp elements, then it's not a Lisp.

>>50
The part where you talked about it.

>>51

If you can't cadaddr everything, if you have to watch out for some non-sexp elements, then it's not a Lisp.

See >>45. Try to keep up.

I was with >>51 since the beginning, but the discussion got me curious, so I ran a test in sbcl. I don't know what the common lisp spec dictates, but sbcl isn't a lisp by our standards either. #() notation actually expands to a vector at the syntax level. I always thought it created the list, (vector ...). None of the built in syntax in common lisp expects a vector, but you could write macros that expect vectors as arguments and supply them with #().

* (defmacro form-is-list-p (form) (listp form))

FORM-IS-LIST-P
* (form-is-list-p (test))

T
* (form-is-list-p ())

T
* (form-is-list-p 8)

NIL
* (form-is-list-p (vector 1 2 3))

T
* (form-is-list-p #(1 2 3))

NIL

And it appears #() doesn't evaluate its arguments. I don't know what to think now.

Convert to JavaScript, infidels.

>>55

Dubs oriented programming.

>>54
Why? #(x ...) ≡ (apply vector (quote (x ...)))

>>53
Dude, I don't know what you've been smoking. It's really strange that a simple fact such as this (all Lisp code is made up of lists and atoms) needs so much explanations, but here goes.

#(1 2 3) is obviously an atom. Just like 8, just like "anus".

(vector 1 2 3) is also obviously a list. Just like (1 2 3) is a list, just like (1 #'sort 666 #(a b c)) is a list.

The REPL session that you posted is absolutely in accordance with this. (form-is-list-p #(1 2 3)) gives a NIL because #(1 2 3) is an atom, not a list. You can check that explicitly by using the atom predicate:

* (atom '8)
T
* (atom '(1 2 3))
NIL
* (atom '#(1 2 3))
T

A more interesting test would be this:

(defmacro vec-macro #(a b)
`(format t "I got a vector of ~a and a ~a" ,a ,b))
(defun vec-syntax-test ()
(vec-macro '#(1 2))

But that fails miserably at compile-time:

debugger invoked on a SIMPLE-TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1002C6F2D3}>:
DEFMACRO lambda-list is not a list #(A B)

So Silver Bank Common Lisp is a red-blooded, full-on Lisp. Not so for Clojure.

>>58
If it was truly a lisp, vectors would be lists, not atoms. There's nothing wrong with having vectors in lisp, as long as they're represented as lists. As soon as vectors are represented as atoms, it's no longer a lisp.

Lists are just an specific kind of digraph where every vertex has only two connected edges. Lisp cannot easily handle a data structure more abstract than it's primitives, therefore, it is useless and shouldn't be held as a model for other languages to strive for.

>>58
Oh ho ho. So now it's lists AND atoms. I submit Clojure vectors are permissible as a kind of atom.

Now it's your turn to move the goalposts again.

>>61
So you've finally learned the definition of a s-exp? Something new every day, huh?

Or if you're too blunt to understand why you're wrong: Clojure vectors are not atoms like they are in CL, they take the place of any function's arglist, and of any let-form's bindings list. I.e. the rot of the syntax is ubiquitous and strongly separates Clojure from any Lisp.

>>60
You can define whatever data structures you want and abstract them away with clos. Just like every other programming language that allows you to define new data types.

>>62
* (defmacro defn (name args &rest body)
`(defun ,name ,(coerce args 'list)
,@body))

DEFN
* (defn clojure-style #(oh shit nigga) (print (list oh shit nigga)))

CLOJURE-STYLE
* (clojure-style 1 2 3)

(1 2 3)
(1 2 3)

>>62
Not that long ago it was *all* lists according to this thread. I can't help it if you can't be bothered to pay attention.

The case you're making now isn't any good either. You're arguing about a form that could be valid in any Lisp—even if you lack the imagination to implement it. It being valid in Clojure doesn't separate it from the family.

"LISP IS INCREDIBLY FLEXIBLE AND PRODUCTIVE"
"EVERYTHING IS A LIST, AND YOU BETTER LIKE IT"
"WHY NO ONE USES LISP???"

I'd rather write x20 more code than dealing with LISP and its community.

*lifts head and drifts out of solitude for a moment*
What? We have a community?

>>64
It is true that clojure is not a lisp. common lisp is also not a lisp. but clojure is not a lisp by default. You could write replacements for clojure's syntax so it could become a lisp. But unless you can undefine the parts that make it not a lisp, it is still not a lisp. This debate is not important. Just admit you were wrong so we can relax.

>>66
A toxic community that stifles app development
http://blog.jacius.info/2012/04/04/a-rubyists-impressions-of-common-lisp/

>>65
Whose quotes are you quoting?

>>68
THEM

>>68
THE SPIRITS INSIDE THE MAGICAL COMPUTER

>>70
We invoke the ghosts of the computer with our incantations!

>>66
It is true that clojure is a lisp. common lisp is also a lisp. but clojure is a lisp by default. But unless you can undefine the parts that make it a lisp, it is still a lisp. This debate is not important. Just admit you were wrong so we can relax.

>>64
No it wasn't, you dimwit. I'd assumed that everyone knew that s-exps allow atoms, this fact is too basic and well-known to even mention it.

You're arguing about a form that could be valid in any Lisp

But in a Lisp it is not baked into the surface syntax of the language. In Clojure, it is. You can't just define a function whose arglist will be represented as a s-exp. That's just blatanly un-Lisp.

>>66
Common Lisp is, obviously, a valid Lisp. On what grounds do you claim otherwise?

>>63
This requires the redefinition of the core defn form. Not sure if Clojure allows it. At any rate, there's just too much Clojure code littered with non-s-exps that one has to deal with to consider it a Lisp.

>>73

No it wasn't, you dimwit.

1. Yes it was 2. You're a moron if you think anyone is going to argue against a case that wasn't presented.

You can't just define a function whose arglist will be represented as a s-exp.

Uh, it is an s-exp. The base case for an s-expression is the atom, which is what the parameter list is.

7777777 GET