2 ms·

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 vari

by 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 tabtab 8y ago

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.