Hacker News Reader

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

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

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

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.

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.

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.

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

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!

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.

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

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