4 ms·

I've always been intellectually fascinated by Lisp, but would NOT want to use it in a production (team) environment. It has two problems: First, is that it's t

by tabtab 8y ago

I've always been intellectually fascinated by Lisp, but would NOT want to use it in a production (team) environment. It has two problems: First, is that it's too "meta" in that one can shape it to be just about anything they want. This can make it difficult for others to read your code, for they have to know your mind's style. Our typical "office" languages tend to hard-wire idioms, such as control structures (if, while, case, try, etc.) which make it easier for other readers to digest. It may be less parsimonious (more code), but it's overall easier for an outsider to come in and read it. Second is that nested lists are the wrong base structure for humans. Our natural languages are closer to maps or ordered maps (AKA "associative arrays"), not nested lists. I was working with others at the C2.com wiki to form something similar for maps: a meta-heavy map-oriented language. We nicknamed the project "MASP". C2 fell apart, but I have some new ideas for MASP that I may write up one of these days. MASP may never go mainstream because of its heavy meta-ing, but could be great for experimental, hobby, and rush-to-market startup projects. Paul Graham has said Lisp's meta ability gave him an edge in the "stores race". Being first-to-market matters in dot-com-ville more than team-friendly code.

dang 8y ago
> This can make it difficult for others to read your code This is solved simply by making the program have suitable conventions. A good team does that anyway.
taeric 8y ago
I'd actually argue that strict "maps" are the wrong choice. Instead, human learning is much more akin to an alist of data that you periodically garbage collect. Sometimes, having multiple "entries" for a single key makes a ton of sense and you essentially key key->value mappings based on recency and overall capacity of your entire experience, not experience in just a single mapping. For your first point, you seem to be making an assertion with no data. I get the fear. I have never actually seen it play out. Worse, I have never seen it play out that these other languages are easy to just jump into. You can soften the claim to "easier" but you have not established a baseline. Just blindly claiming it would have been harder in lisp.
- tabtab 8y ago
  As I mentioned above, it probably varies per person. Nobody has reliable "head data" (studies) either way. If you can donate for a formal study, that would be great. But until then, my experience with other programmers is that people think different from each other. One's own head is not necessarily extrapolate-able to other heads. It's too small a sample size. For my head and a couple of others who have agreed with me, an ordered map is a better root linguistic structure than nested lists. It's more natural to OUR heads. No language will make everyone happy, but map-oriented languages are under-explored. I intend to explore. Call me "Ferdinand Mapgellan".
  - taeric 8y ago
    I didn't say a nested list in this regard. I specifically think alists is more natural to me. Basically, give me the first meaning I can think of for "Dust". Is it applicable here? No? Go down the list to the next definition of Dust. That said, I'm not trying to stonewall where you are searching. :) Good luck!
lispm 8y ago
> This can make it difficult for others to read your code Actually I found that one can write very nice code with macro heavy code. Reading the code is not the real problem - the problem is debugging/extending. There are some macros, which are difficult to use - but Lisp has all the mechanisms to write very clean code with excellent error handling. > but it's overall easier for an outsider to come in and read it. That's not different from a large layered object-oriented architecture - like in Java. There are enough stories of Java teams where the architect went fully generic and reimplemented all kinds of layers in his/her own style. That's no less difficult to understand than a layered language in Lisp - with the added advantage that the layered languages can be made much more problem specific and thus is easy to read - because the code is actually shorter. > Second is that nested lists are the wrong base structure for humans. That would be surprising, since people are used to work with lists. Actually lists in Lisp are only a carrier for things. A property list or an assoc list is a map. The really first object-systems were based on property lists hanging of from symbols: CL-USER 1 > (setf (symbol-plist 'hans) '(:class :computer :machine-type :lispm :vendor :symbolics :model :3600 :memory-size 20 :site (:city hamburg :project :hamans))) (:CLASS :COMPUTER :MACHINE-TYPE :LISPM :VENDOR :SYMBOLICS :MODEL :|3600| :MEMORY-SIZE 20 :SITE (:CITY HAMBURG :PROJECT :HAMANS)) CL-USER 2 > (get 'hans :model) :|3600|
- deleted 8y ago
  [deleted]
- tabtab 8y ago
  Re: people are used to work with lists. To a degree, yes. But it's not the best root linguistic structure, by my observation. But I do realize it probably varies from person to person. Others have agreed with my map observation more or less, and thus there is a potential audience for it, perhaps even bigger than nested lists. And I do realize one can emulate maps in Lisp, but it's not native, and ends up getting mixed in with lists unless somebody with a big stick stops it. I'm working on a "native" map language so sticks are not necessary. (Similarly, MASP drafts can emulate lists, it's not just as easy or natural.)
a_lieb 8y ago
Common Lisp doesn't have first-class maps (although lispm is right that you can think of lists as a thin abstraction around all kinds of data structures). But Clojure does have first class maps complete with their own syntax: {:key1 "Value 1" :key2 "Value 2"} as well as sets, and a few other native types.
- lispm 8y ago
  In libraries of CL there are many types of maps. List-based, hash-table based, object-based, ... In Lisp, the list-based map is 6 decades old: (:key1 "Value 1" :key2 "Value 2")

by tabtab 8y ago

dang 8y ago

> This can make it difficult for others to read your code This is solved simply by making the program have suitable conventions. A good team does that anyway.

taeric 8y ago

I'd actually argue that strict "maps" are the wrong choice. Instead, human learning is much more akin to an alist of data that you periodically garbage collect. Sometimes, having multiple "entries" for a single key makes a ton of sense and you essentially key key->value mappings based on recency and overall capacity of your entire experience, not experience in just a single mapping. For your first point, you seem to be making an assertion with no data. I get the fear. I have never actually seen it play out. Worse, I have never seen it play out that these other languages are easy to just jump into. You can soften the claim to "easier" but you have not established a baseline. Just blindly claiming it would have been harder in lisp.

tabtab 8y ago
As I mentioned above, it probably varies per person. Nobody has reliable "head data" (studies) either way. If you can donate for a formal study, that would be great. But until then, my experience with other programmers is that people think different from each other. One's own head is not necessarily extrapolate-able to other heads. It's too small a sample size. For my head and a couple of others who have agreed with me, an ordered map is a better root linguistic structure than nested lists. It's more natural to OUR heads. No language will make everyone happy, but map-oriented languages are under-explored. I intend to explore. Call me "Ferdinand Mapgellan".
- taeric 8y ago
  I didn't say a nested list in this regard. I specifically think alists is more natural to me. Basically, give me the first meaning I can think of for "Dust". Is it applicable here? No? Go down the list to the next definition of Dust. That said, I'm not trying to stonewall where you are searching. :) Good luck!

lispm 8y ago

> This can make it difficult for others to read your code Actually I found that one can write very nice code with macro heavy code. Reading the code is not the real problem - the problem is debugging/extending. There are some macros, which are difficult to use - but Lisp has all the mechanisms to write very clean code with excellent error handling. > but it's overall easier for an outsider to come in and read it. That's not different from a large layered object-oriented architecture - like in Java. There are enough stories of Java teams where the architect went fully generic and reimplemented all kinds of layers in his/her own style. That's no less difficult to understand than a layered language in Lisp - with the added advantage that the layered languages can be made much more problem specific and thus is easy to read - because the code is actually shorter. > Second is that nested lists are the wrong base structure for humans. That would be surprising, since people are used to work with lists. Actually lists in Lisp are only a carrier for things. A property list or an assoc list is a map. The really first object-systems were based on property lists hanging of from symbols: CL-USER 1 > (setf (symbol-plist 'hans) '(:class :computer :machine-type :lispm :vendor :symbolics :model :3600 :memory-size 20 :site (:city hamburg :project :hamans))) (:CLASS :COMPUTER :MACHINE-TYPE :LISPM :VENDOR :SYMBOLICS :MODEL :|3600| :MEMORY-SIZE 20 :SITE (:CITY HAMBURG :PROJECT :HAMANS)) CL-USER 2 > (get 'hans :model) :|3600|

deleted 8y ago
[deleted]
tabtab 8y ago
Re: people are used to work with lists. To a degree, yes. But it's not the best root linguistic structure, by my observation. But I do realize it probably varies from person to person. Others have agreed with my map observation more or less, and thus there is a potential audience for it, perhaps even bigger than nested lists. And I do realize one can emulate maps in Lisp, but it's not native, and ends up getting mixed in with lists unless somebody with a big stick stops it. I'm working on a "native" map language so sticks are not necessary. (Similarly, MASP drafts can emulate lists, it's not just as easy or natural.)

a_lieb 8y ago

Common Lisp doesn't have first-class maps (although lispm is right that you can think of lists as a thin abstraction around all kinds of data structures). But Clojure does have first class maps complete with their own syntax: {:key1 "Value 1" :key2 "Value 2"} as well as sets, and a few other native types.

lispm 8y ago
In libraries of CL there are many types of maps. List-based, hash-table based, object-based, ... In Lisp, the list-based map is 6 decades old: (:key1 "Value 1" :key2 "Value 2")