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 spe

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.