3 ms·

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

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
Isn't the abstraction, and sticking to the abstraction, the job of the programmer, and not the language? We all speak English here; you can say, "let's all speak like Yoda now." Quite easy, that is. But the underlying language doesn't need to change; other people can invent different rules and create different settings where these rules apply strictly. So imperatively, your socket program is like this: f = file("/hello.txt") p = makeport(8934) s = makesocket(p) s.send(f) s.destroy() which is perfectly fine. This is basically a line by line translation from your English-looking pseudocode to this OO-code-looking pseudocode. Using s-expressions would make the whole process read much more like speaking: Let's say I wanted to send a file: Using the socket that uses the port 8934, send the file hello.txt, and destroy the socket. Plain English, right? Reorder into: Destroy the socket that is used to send the file hello.txt and is created with port 8934. Translate to s-expr: (destroy-socket (send-file (make-file "hello.txt") using (make-socket (make-port 8934))) I'm taking liberties with the send-file function syntax. Looks ugly, but that's pretty close to the natural language representation. If you parse the syntactic tree it will almost overlap completely.
- delackner 18y ago
  The inversion you applied to the plain english makes it into a format that is, while technically english, the sort of construct that one imagines an alien or robot might produce when trying to talk to us. If you actually spoke like that people would look at you very strangely, and this is the difficulty in understanding s-expressions that I think a lot of people have. That said, since my own programming style in C-derived languages seems over the years to slowly be attempting to imitate s-expressions, I think a lot of the mental difficulty people mention is just being overly comfortable with the familiar.

whacked_new 18y ago

Isn't the abstraction, and sticking to the abstraction, the job of the programmer, and not the language? We all speak English here; you can say, "let's all speak like Yoda now." Quite easy, that is. But the underlying language doesn't need to change; other people can invent different rules and create different settings where these rules apply strictly. So imperatively, your socket program is like this: f = file("/hello.txt") p = makeport(8934) s = makesocket(p) s.send(f) s.destroy() which is perfectly fine. This is basically a line by line translation from your English-looking pseudocode to this OO-code-looking pseudocode. Using s-expressions would make the whole process read much more like speaking: Let's say I wanted to send a file: Using the socket that uses the port 8934, send the file hello.txt, and destroy the socket. Plain English, right? Reorder into: Destroy the socket that is used to send the file hello.txt and is created with port 8934. Translate to s-expr: (destroy-socket (send-file (make-file "hello.txt") using (make-socket (make-port 8934))) I'm taking liberties with the send-file function syntax. Looks ugly, but that's pretty close to the natural language representation. If you parse the syntactic tree it will almost overlap completely.

delackner 18y ago
The inversion you applied to the plain english makes it into a format that is, while technically english, the sort of construct that one imagines an alien or robot might produce when trying to talk to us. If you actually spoke like that people would look at you very strangely, and this is the difficulty in understanding s-expressions that I think a lot of people have. That said, since my own programming style in C-derived languages seems over the years to slowly be attempting to imitate s-expressions, I think a lot of the mental difficulty people mention is just being overly comfortable with the familiar.