6 ms·

> We are humans and our brains are wired for a certain type of thinking. Lisp breaks this model, and so it's difficult for people to pick it up. If you have ev

> We are humans and our brains are wired for a certain type of thinking. Lisp breaks this model, and so it's difficult for people to pick it up. If you have ever parsed a syntactic tree, you'll realize that it's inherently an s-expression. That means that everything you ever say, and all human communication for that matter, are s-expressions. Sans the logic, operators, symbol quoting and observance of rules (first item is interpreted as a function), lisp is at its core as close to human language you'll ever get. Popularity depends on other things, but lisp doesn't break the way we think.

markessien 18y ago
Take a look at this sample from wikipedia: (defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1))))) Now imagine trying to explain that to a person who does not use a computer. Humans always start learning by looking for the objects, then applying an action on the object. With lisp, this object is not obvious, and the actions being applies are not obvious either.
- utx00 18y ago
  are the axioms of non-euclidean geometry obvious? what about special relativity?
  - markessien 18y ago
    You are saying that I am using the solution for a tough problem as being representative of the use of the language? That may be so, but what I was pointing out was how different they language structure was from traditional human languages.
    - utx00 18y ago
      they are different domains of expression. so that should not come as surprise. maybe one day when computers are super powerful. for now "code is data and we write in the same data structures the compiler understands" seem like the bigger win. that of course means a lisp of some sort.
- fauigerzigerk 18y ago
  I never found this objects first idea very plausible. It's just OO dogma, not cognitive science. Which of the following expressions is most "natural" in your view? person.buy(house, agency, contract) agency.sell(house, contract, person) house.sale(person, agency, contract) contract.fulfil(house, person, agency) Of course the decision is not taken based on what's easiest to explain to non computer users but rather on which object's encapsulated data is most affected by the operation, or which inheritance hierarchy should be used to look up the operation. In most non trivial cases that's extremely subjective. Being forced to make that decision _every time_ you call or write a function is a complete waste of intellectual effort. Since there is always one name for what should happen (the name of the function) but potentially many objects that are involved in some capacity, it seems much more consistent to give a special syntactical place to the function rather than to any of the objects: sell(house, person, contract) or if you prefer (sell house person contract)
  - markessien 18y ago
    I'm not directly arguing for OO. In my opinion, a good language is one which forces the black box encapsulation of complex behaviour. 'House' as an abstraction for a house is a good model. Performing an action on an abstraction should be in an intuitive manner, for example: sell House That's pretty clear. To cause the interaction between two objects, then one should place the action between the objects: make "Agency" sell "House" where 'make' is equivalent to calling a function. Now, let's bring in a contract make "Agency" sell "House" using "Contract" this OO model works in my opinion because there is one path between the objects, and the arguments describe the contents of the path. make "Person" buy "House" using "TerribleContract" I believe that programming languages are too flexible. I believe that programming languages should be constructed in a manner that forces you to abstract complex structures into aggregates of behaviour, where the input to these aggregates consist of a very low number of paths. Java, C+++ fail in this in that they allow you to break out of the abstraction hierachy. They allow you to have callbacks and inheritance and so on, which breaks the black-boxiness of your program. A black-box should always take the same inputs and should always produce the same behaviour from those inputs. Now, what about other types of programming constructs? Let's say I wanted to send a file to another PC using sockets: create "File" using "/hello.txt" As the next step I'm trying to open a port. However, a port has a number. I could try to do this: create "Socket" using ("Port" using 8934) "Port 8934" is something that can be merged together into a composite structure and so the user should be forced to do so: "InputPort" is "Port" using 8934 create "Socket" using "InputPort" make "Socket" send "File" destroy "Socket" This is an example of how I think a properly abstracted language should look like. Force single paths to all abstractions, and force abstraction use.
- whacked_new 18y ago
  Sure, lisp syntax is itself not intuitive, but I was pointing out that the reasoning involved in lisp programming does not clash with how humans are wired. It could clash with how humans are trained, but inherently, s-expressions are a good representation of human speech.
- jimbokun 18y ago
  If the person knows the mathematical meaning of factorial and the underlying concepts, this will be very easy. If not, this will be really hard using any programming language.

markessien 18y ago

Take a look at this sample from wikipedia: (defun factorial (n) (if (<= n 1) 1 (* n (factorial (- n 1))))) Now imagine trying to explain that to a person who does not use a computer. Humans always start learning by looking for the objects, then applying an action on the object. With lisp, this object is not obvious, and the actions being applies are not obvious either.

utx00 18y ago
are the axioms of non-euclidean geometry obvious? what about special relativity?
- markessien 18y ago
  You are saying that I am using the solution for a tough problem as being representative of the use of the language? That may be so, but what I was pointing out was how different they language structure was from traditional human languages.
  - utx00 18y ago
    they are different domains of expression. so that should not come as surprise. maybe one day when computers are super powerful. for now "code is data and we write in the same data structures the compiler understands" seem like the bigger win. that of course means a lisp of some sort.
fauigerzigerk 18y ago
I never found this objects first idea very plausible. It's just OO dogma, not cognitive science. Which of the following expressions is most "natural" in your view? person.buy(house, agency, contract) agency.sell(house, contract, person) house.sale(person, agency, contract) contract.fulfil(house, person, agency) Of course the decision is not taken based on what's easiest to explain to non computer users but rather on which object's encapsulated data is most affected by the operation, or which inheritance hierarchy should be used to look up the operation. In most non trivial cases that's extremely subjective. Being forced to make that decision _every time_ you call or write a function is a complete waste of intellectual effort. Since there is always one name for what should happen (the name of the function) but potentially many objects that are involved in some capacity, it seems much more consistent to give a special syntactical place to the function rather than to any of the objects: sell(house, person, contract) or if you prefer (sell house person contract)
- markessien 18y ago
  I'm not directly arguing for OO. In my opinion, a good language is one which forces the black box encapsulation of complex behaviour. 'House' as an abstraction for a house is a good model. Performing an action on an abstraction should be in an intuitive manner, for example: sell House That's pretty clear. To cause the interaction between two objects, then one should place the action between the objects: make "Agency" sell "House" where 'make' is equivalent to calling a function. Now, let's bring in a contract make "Agency" sell "House" using "Contract" this OO model works in my opinion because there is one path between the objects, and the arguments describe the contents of the path. make "Person" buy "House" using "TerribleContract" I believe that programming languages are too flexible. I believe that programming languages should be constructed in a manner that forces you to abstract complex structures into aggregates of behaviour, where the input to these aggregates consist of a very low number of paths. Java, C+++ fail in this in that they allow you to break out of the abstraction hierachy. They allow you to have callbacks and inheritance and so on, which breaks the black-boxiness of your program. A black-box should always take the same inputs and should always produce the same behaviour from those inputs. Now, what about other types of programming constructs? Let's say I wanted to send a file to another PC using sockets: create "File" using "/hello.txt" As the next step I'm trying to open a port. However, a port has a number. I could try to do this: create "Socket" using ("Port" using 8934) "Port 8934" is something that can be merged together into a composite structure and so the user should be forced to do so: "InputPort" is "Port" using 8934 create "Socket" using "InputPort" make "Socket" send "File" destroy "Socket" This is an example of how I think a properly abstracted language should look like. Force single paths to all abstractions, and force abstraction use.
whacked_new 18y ago
Sure, lisp syntax is itself not intuitive, but I was pointing out that the reasoning involved in lisp programming does not clash with how humans are wired. It could clash with how humans are trained, but inherently, s-expressions are a good representation of human speech.
jimbokun 18y ago
If the person knows the mathematical meaning of factorial and the underlying concepts, this will be very easy. If not, this will be really hard using any programming language.