He: We need to put more parentheses in the code for readability
Me: Ok, I get it.

Here you go:
(if(member prop data)(log(concat prop(concat ':' (index data prop))))

They'll be Lost In Silly Parentheses 😂

@coolq that's exactly what the devilspie configuration files look like

@DarkHole
Really? Wow.

Parentheses != Readability

As I'm sure you know, it actually makes it harder. Wouldn't be surprised if it's an obfustication technique 😛

Aaghhh It Burns!

What the fuck

JavaSclisp

Babel ES6->Lisp transpiler ftw

EcmaLisp FTW!

Ha! You obviously don't know Racket...

If you write Lisp or Clojure there's really no way around it 😄

@aaxa wtf, in JS you also need brackets around lists...

@ac1235 That's not remotely the same...

@theCalcaholic it is exactly the same

@ac1235 No. In Clojure/Lisp you have brackets around every function call and definition. Not only lists.

@theCalcaholic you have just successfully made me facepalm

no offense, but this statement is outright stupid

@ac1235 Saying no offense doesn't mean what you're saying is not leaning on the offensive side, nor does it do anything to remedy that. In fact prepending stuff with "no offense" doesn't mean anything.

If you'd like to share your wisdom for the benefit of those who are looking at this thread, you have every opportunity to do so.

@mzeffect thank you for pointing this out, but to a Lisp programmer this literally seems like trolling,
even more so since he expressed familiarity with a lisp (clojure).

sadly, I don't have any wisdom to share here.

@ac1235 Why are we talking about lists specifically? I'm quite sure what @theCalcaholic meant was that you need parentheses around a function call in Lisp which is not remotely the same as what you're talking about. No one even mentioned brackets. So maybe read the comment, and ask for elaboration before commenting offensive stuff

@ac1235 @aaxa Maybe he is irritated because I called 'parentheses' 'brackets'? Coming from a (natural) language where there is only one term for both that felt always a bit arbitrarily to me...

@theCalcaholic Might be 😂 I know what you meant though

@theCalcaholic no that's absolutely not the reason. learn a lisp or don't talk about it

@ac1235 In that case you're just dip shitting. *shrugs*

@theCalcaholic
> In clojure you not only have parenthesis around lists but also around function calls (paraphrased)

@ac1235 yes, and?

@theCalcaholic Oh common,
function calls ARE LISTS.

@ac1235 Can you please elaborate? AFAIK function calls just look like lists, but are definitely not lists

@ac1235 Yeah, but usually you don't write them as such but use shorthand notation.

@aaxa in lisp (well in Racket, which I have most experience with) pairs of two elements are defined like this:
(cons a b)
Lists are defined as pairs where the second pair is another pair (which might contain another pair and so on). So you could define a list containing the elements a, b, c, d line this:

(cons a (cons b (cons c (cons d))))

which you can also write as

(list a b c d)

In both cases its basically a function call returning a list.

There's another notation however which I ended up using the most:

'(a b c d)

That doesn't look like a function call anymore (but it still is, under the hood - as would be the case in any language where lists arent primitives).

Or did I get that wrong, @ac1235?

@theCalcaholic Ah okay. My Lisp knowledge is pretty limited of what concerns the underlying technology.
I already knew that lists in Lisp is basically linked lists though

@theCalcaholic You did get all of it wrong.
'x is shorthand for (quote x).
What does quote do? It returns it's argument **unevaluated**.
So '(x y z) means (quote (x y z)) and evaluates to (x y z). It's a list.
So is (+ 2 2).

You should really learn to program btw:
learn about evaluation,
homoiconizity etc...

@ac1235 Well that's the case in every language. I thought you were talking about something relevant.

In Python:
[1, 2, 3] evaluates to a constructor (i. e. method, i. e. function) call, creating a list.
"foo" evaluates to a constructor call, creating a string

In Java:
int[] ar = {1,2,3,4} will evaluate - you guessed it - to a constructor call.

It's just irrelevant. You could have stated that 'every list in lisp is byte code' and it would have been just as true and irrelevant.

I didn't even consider that that's what you were trying to say in the first place, because it's so trivial.

Nothing of what you said contradicts my statement, btw. I was saying 'Yes, but you usually don't notate it as such' not that it isn't evaluated to a function call in the end.

@ac1235 Are you for real right now? Why the hostility? Excuse us that we didn't get what you meant to begin, but that's really your fault for not explaining it well enough in the first place. There's no reason to be a dick

@ac1235
I have written a Lisp(LEL) interpreter. And I have to say that I agree with @theCalcaholic and @aaxa.

Look, you sound like you think you know everything. Your statements put others down. Just slow down, what is the point of telling us we need to learn how to program? Or that we're worse?

You're telling us we need to learn how to program? You need to learn some manners and respect. Even if you truly better programmer, then why do you feel the need to say it?

Let your code and knowledge show that for you.

I'm not usually this harsh, but it gets on my nerves when someone treats others like this.

@coolq @aaxa Thank you! I was becoming increasingly fed up myself (which probably showed in my tone).

@theCalcaholic
Don't worry, we're all only human 😉

@coolq
You are right, it just feels frustrating.
but it really is my own inability to express myself in a calm way, please excuse my misbehavior.

okay:
(+ 2 2) is a list of 3 items (+, 2, 2).
the evaluator makes 4 out of it.
but (+ 2 2) itself is a list.
so is (f x). it is a list.
the statement "you not only put parens around lists but also fncalls" therefore makes absolutely no sense,
because you denote fncalls as lists.
in the tree to evaluate (f x) is a list.
what the evaluator makes out of it might be a fncall, but the thingy is a list (thus the parens around it)

@ac1235 I'd rather call it a function than a list. That's why it's called functional programming.

But I see what you mean.

EDIT: To elaborate, in lisp everything is a function. That you write the function name inside the parenthesis and not outside is just syntax, imo.

@theCalcaholic
look, there is one core concept you seem not to get and as it shows I'm not qualified to teach it, sadly.
This concept is homoiconizity.
It is extremely core to all Lisp's that matter (CL Scheme Clojure...) and you should read about it if you are interested.
This concept is required to come to Lisp enlightenment.

@ac1235 Interesting, I'll look into it.

@ac1235
Damn, you really flipped that around. You have regained my respect 😤

You are right about the list thing, many lisp interpreters treat things in parentheses as lists. I think it is important to note that not _all_ lisp interpreters work like this, however.

My understanding is that most major lisp languages treat everything as lists. That includes function calls. Lists in the program simply return their arguments.
This makes it easier to evaluate, since you can directly execute the AST which is just a giant list.
Using recursive behaviour, you may walk through each list inside the AST, count the first token as the function unless it is a primative value. Return the result of the list(function call), if any.

Is this correct?

In this explanation I assume familiarity with JSON:

So, in JSON this is a list:
[1,2,3].

Now, imagine a Json interpreter,
which allows you to write code in it:
The interpreter would treat a list as a function call or macro call (if the first element is special). Also it treats strings as variables and numbers as numbers.

> ["+", 2, 2]
4
> ["set", "x", 5]
> ["+", 1, ["*", "x", 2]]
11

Alright. Now you have the Json programming language, but you have to put brackets around funcalls.
Why? Because they are lists.

What do you gain? Your code is data.
You can do things to code you would normally do to data.

> ["quote", [2,2]]
[2,2]
> ["append", ["quote", ["+"]], ["quote", [2,2]]]
["+", 2, 2]
> ["eval", ["append", ...]]
4

This allows you to create own syntax in the form of macros.

> ["macro", ["incr", "x"], ["list", ["quote", "set"], "x", ["list", ["quote","+"],"x",1]]]
> ["incr", "n"] // same as ["set", "n", ["+", "n", 1]

Now Lisp works exactly like this.
Instead of Json lists [1,2,3] we have lisp lists (1 2 3) and for variables we use symbols (x) instead of strings ("x")

@ac1235 Thank you for the explanation. That makes way more sense than what you initially said. Now I at least understand the concept

This is why you do python. 😏