4 ms·

> JavaScript has fixed S-expressions Replacing them with a semicolon and curly brace riddled abomination; see CoffeScript and various syntax extensions that co

> JavaScript has fixed S-expressions Replacing them with a semicolon and curly brace riddled abomination; see CoffeScript and various syntax extensions that come with latest JS standards. Also note how many years it took for JS to get even very basic features, like `() => {}` lambda notationor multiline strings. In a language with a macro system you can implement both easily. > Macros are harmful to programming in the large. This is not true. Macros are mainly used to implement DSLs, and well designed DSL can shorten the code by an order of magnitude. Of course, when to create one is hard to say, but not harder than when to write a metaclass in Python. Would you advocate removing metaclasses from Python? When not for DSLs, macros are used as compile-time functions. You can easily write such macros in any language, provided you split your program in two parts: preprocessor (which parses and transform the code) and the code proper. That's a lot of work, which disappears with the introduction of a macro system. I don't think this has any impact on "programming in the large". Many "modern" and "systems" programming language feature macro systems. Haxe, Nim, Rust, Julia spring to mind immediately, followed by OCaml, Haskell, Elixir, Erlang and quite a few more. In other words: if you want to say that "macros are harmful" in some way you're going to need to provide some kind of argument and evidence. > creates a Babel tower of incompatible object systems instead of a common language. Three of the most popular Lisps - Racket, Clojure and Common Lisp - have an object system in the language. EDIT: Emacs Lisp might also qualify, but I don't remember if EIEIO is included by default in Emacs. > JavaScript got rid of linked lists (that are awkward and impractical for everyday use) Many languages outside of Lisps seem to disagree: Elixir and Erlang, Haskell, OCaml and Prolog, for instance. And btw: I disagree with this too. Linked lists are a very convenient and surprisingly universal data structure, but they really shine wherever you have a recursive algorithm. Which is, in the languages mentioned, almost all the time. > and introduced hash-tables into the language. Clojure, Common Lisp, Racket, Emacs Lisp and probably others provide a rich set of data structures, including vectors, bitsets, hashes, queues, sequences and more.

srssays 9y ago
> Linked lists are a very convenient and surprisingly universal data structure, but they really shine wherever you have a recursive algorithm. Which is, in the languages mentioned, almost all the time. Linked lists were way ahead of their time. Nowadays everything is so fast that we can probably use them without guilt, but there is still a sense of disgust associated them.
- klibertp 9y ago
  Linked lists are indeed wasteful in terms of memory usage, compared to simple arrays. There are ways of optimizing this, but you won't get away from having an additional pointer to the next element. However, linked lists offer many advantages that arrays do not. The length of a list need not be known at compile time, for one. It's trivial and very fast to insert a new element in the middle of the list. They are not optimized for random access, but they pose no performance penalty (over arrays) if you need to traverse them from start to end. But the most important advantage of linked lists is that they are their own iterators (in C++ parlance). You don't need an additional state for iterating over a list - you don't need to store and update the index, for example. Each element of a list is the beginning of the rest of the list, so if you hold a reference to one, you can stop and restart iteration without problems. Moreover, you can add elements to the list and still be able to use the previously captured element as a start of new iteration: no need to invalidate the iterator. In other words, Linked List has some very desirable properties and it makes sense to use it for almost anything other than a fixed-length, random-access collection. All Lisps provide vectors and hashes for the latter use-case. I think the problem with Linked Lists is that they are not hard to implement and taught on the entry-level courses, with C as an implementation language. This makes it very hard to see their usefulness. With a bit of tooling (library functions) and language support, they really shine.
  - lispm 9y ago
    > but you won't get away from having an additional pointer to the next element It was done on some Lisp Machines with CDR-coding. newly allocated lists did not have any CDR pointers. Optimizing lists that way could also be done by the garbage collector, when it needed to copy lists or in optimization runs before saving an image. Most other implementations did not implement it. http://www.faqs.org/faqs/lisp-faq/part2/section-9.html http://www.faqs.org/faqs/lisp-faq/part2/section-9.html

srssays 9y ago

> Linked lists are a very convenient and surprisingly universal data structure, but they really shine wherever you have a recursive algorithm. Which is, in the languages mentioned, almost all the time. Linked lists were way ahead of their time. Nowadays everything is so fast that we can probably use them without guilt, but there is still a sense of disgust associated them.

klibertp 9y ago
Linked lists are indeed wasteful in terms of memory usage, compared to simple arrays. There are ways of optimizing this, but you won't get away from having an additional pointer to the next element. However, linked lists offer many advantages that arrays do not. The length of a list need not be known at compile time, for one. It's trivial and very fast to insert a new element in the middle of the list. They are not optimized for random access, but they pose no performance penalty (over arrays) if you need to traverse them from start to end. But the most important advantage of linked lists is that they are their own iterators (in C++ parlance). You don't need an additional state for iterating over a list - you don't need to store and update the index, for example. Each element of a list is the beginning of the rest of the list, so if you hold a reference to one, you can stop and restart iteration without problems. Moreover, you can add elements to the list and still be able to use the previously captured element as a start of new iteration: no need to invalidate the iterator. In other words, Linked List has some very desirable properties and it makes sense to use it for almost anything other than a fixed-length, random-access collection. All Lisps provide vectors and hashes for the latter use-case. I think the problem with Linked Lists is that they are not hard to implement and taught on the entry-level courses, with C as an implementation language. This makes it very hard to see their usefulness. With a bit of tooling (library functions) and language support, they really shine.
- lispm 9y ago
  > but you won't get away from having an additional pointer to the next element It was done on some Lisp Machines with CDR-coding. newly allocated lists did not have any CDR pointers. Optimizing lists that way could also be done by the garbage collector, when it needed to copy lists or in optimization runs before saving an image. Most other implementations did not implement it. http://www.faqs.org/faqs/lisp-faq/part2/section-9.html http://www.faqs.org/faqs/lisp-faq/part2/section-9.html