4 ms·

> 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

by 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.)
- lispm 8y ago
  > root linguistic structure The root linguistic structure of Lisp are lists of symbols: (move ship harbour) (move ship :location harbour) (collide ship asteroid :with-speed 100) (differentiate '(x * 2 + 3) 'x) (loop from i below 100 when (evenp i) collect i) > even bigger than nested lists since lists have been used in Lisp for map-like data a lot, there is very litte advantage on a 'linguistic' level. (loop for (name age) in '((fred 10) (jane 21) (alfred 9)) ...) It makes not much different if the data map uses a different character. A Lisp user would probably layout the data so that it is easy recognizable as a map/table. A typical Lisp user is trained to read structure and not so much parentheses. It's a bit like bicycle riding - it looks difficult if you haven't learned it already. ((fred 10) (jane 20) (alfred 9)) What Lisp already makes usual to many is that it uses a data-structure - s-expressions - to encode programs in. > but it's not native Lisp-based maps were in Lisp since basically day one and were widely used. There was little demand for different maps for a long time. There is little added benefit from having 'maps' native. Lisp developers instead added flexible object systems, where the instances were map-like. There are really a zillion of them in all kinds of shades. Hash-tables were added to Lisp probably in the 70s not as a new notation, but as an efficient data structure for large amounts of key/value data - for example to implement the symbol table. There is even an example in CLTL2 how they looked like in Connection Machine Lisp: {moe->"Oh, a wise guy, eh?" larry->"Hey, what's the idea?" curly->"Nyuk, nyuk, nyuk!"} https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node192.html#READTABLESECTION https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node192.... There are many other examples of these, but generally people were working towards objects as maps, with types and inheritance, etc. Personally I don't think anonymous maps scale well for large interactive applications I'm interested in. I prefer to see at runtime, what type this map is about (is it price data, is it a product list, ...) - usually in form of an object-system, a frame system, or similar. If I don't need that and want to write literal data, I can just as well use a list (assoc list, ...). But then I've seen a lot of Lisp code and are used to it.
  - tabtab 8y ago
    You ignored my "stick" point; it still stands. Anyhow, I'd like clarification on "doesn't scale well". (Large apps should probably be partitioned into smaller apps that use a database or the like to share info/state.) And I think we have a different concept of "native". But anyhow, I don't want to continue a "language war": people like what they like.

by lispm 8y ago

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.)

lispm 8y ago
> root linguistic structure The root linguistic structure of Lisp are lists of symbols: (move ship harbour) (move ship :location harbour) (collide ship asteroid :with-speed 100) (differentiate '(x * 2 + 3) 'x) (loop from i below 100 when (evenp i) collect i) > even bigger than nested lists since lists have been used in Lisp for map-like data a lot, there is very litte advantage on a 'linguistic' level. (loop for (name age) in '((fred 10) (jane 21) (alfred 9)) ...) It makes not much different if the data map uses a different character. A Lisp user would probably layout the data so that it is easy recognizable as a map/table. A typical Lisp user is trained to read structure and not so much parentheses. It's a bit like bicycle riding - it looks difficult if you haven't learned it already. ((fred 10) (jane 20) (alfred 9)) What Lisp already makes usual to many is that it uses a data-structure - s-expressions - to encode programs in. > but it's not native Lisp-based maps were in Lisp since basically day one and were widely used. There was little demand for different maps for a long time. There is little added benefit from having 'maps' native. Lisp developers instead added flexible object systems, where the instances were map-like. There are really a zillion of them in all kinds of shades. Hash-tables were added to Lisp probably in the 70s not as a new notation, but as an efficient data structure for large amounts of key/value data - for example to implement the symbol table. There is even an example in CLTL2 how they looked like in Connection Machine Lisp: {moe->"Oh, a wise guy, eh?" larry->"Hey, what's the idea?" curly->"Nyuk, nyuk, nyuk!"} https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node192.html#READTABLESECTION https://www.cs.cmu.edu/Groups/AI/util/html/cltl/clm/node192.... There are many other examples of these, but generally people were working towards objects as maps, with types and inheritance, etc. Personally I don't think anonymous maps scale well for large interactive applications I'm interested in. I prefer to see at runtime, what type this map is about (is it price data, is it a product list, ...) - usually in form of an object-system, a frame system, or similar. If I don't need that and want to write literal data, I can just as well use a list (assoc list, ...). But then I've seen a lot of Lisp code and are used to it.
- tabtab 8y ago
  You ignored my "stick" point; it still stands. Anyhow, I'd like clarification on "doesn't scale well". (Large apps should probably be partitioned into smaller apps that use a database or the like to share info/state.) And I think we have a different concept of "native". But anyhow, I don't want to continue a "language war": people like what they like.