One of your examples of one of your comments being unfairly downvoted is
It was designed for Lisp machines, without any regard to efficiency on lowly hardware.
You support this with a link to an article by Brooks and Gabriel, from 1984, that was part of the infighting of the ongoing standardisation process. They claim
The cost of invisible pointers was ignored for micro-coded machines and underestimated for stock architectures.
Later, on page 16
As a conscession to non-micro-coded machines, vectors, simple vectors and simple strings were included as types. The resulting tangle of types … is clearly a political compromise...
So part of Brooks and Gabriels critique is the ugliness that has resulted from considerations of efficiency on lowly hardware. Your precis is rather rough.
They won their fight over invisible pointers that year. On page one of Common Lisp the Language, also from 1984, we find
Common Lisp intentionally excludes features that cannot be implemented easily on a broad class of machines. On the one hand, features that are difficult or expensive to implement on hardware without special microcode are avoided or provided in a more abstract and efficiently implementable form. (Examples of this are the invisible forwarding pointers and locatives of Zetalisp. Some of the problems that they solve are addressed in different ways in Common Lisp.) On the other hand, features that are useful only on certain ordinary'' orcommercial″ processors are avoided or made optional. (An example of this is the type declaration facility, which is useful in some implementations and completely ignored in others. Type declarations are completely optional and for correct programs affect only efficiency, not semantics.) Common Lisp is designed to make it easy to write programs that depend as little as possible on machine-specific characteristics, such as word length, while allowing some variety of implementation techniques.
so your comment was 23 years out of date.
One of the consequences of trolling is that many people have wearied of posting long corrections to short posts. They don’t want to get trolled, but how can they avoid it? One simple algorithm is to assess the length and construction of the post in relation to a possible reply. If the original post is brief and if it is constructed so that a reply would have to be considerably longer just to untangle the original posts confusion, then people will just mod down and move on.
If you don’t want this happening to your posts I suggest signalling sincerity by putting work into them. If, for example, you tell the story of how you came by your beliefs you will reassure your troll-ridden readers
One of your examples of one of your comments being unfairly downvoted is
You support this with a link to an article by Brooks and Gabriel, from 1984, that was part of the infighting of the ongoing standardisation process. They claim
Later, on page 16
So part of Brooks and Gabriels critique is the ugliness that has resulted from considerations of efficiency on lowly hardware. Your precis is rather rough.
They won their fight over invisible pointers that year. On page one of Common Lisp the Language, also from 1984, we find
so your comment was 23 years out of date.
One of the consequences of trolling is that many people have wearied of posting long corrections to short posts. They don’t want to get trolled, but how can they avoid it? One simple algorithm is to assess the length and construction of the post in relation to a possible reply. If the original post is brief and if it is constructed so that a reply would have to be considerably longer just to untangle the original posts confusion, then people will just mod down and move on.
If you don’t want this happening to your posts I suggest signalling sincerity by putting work into them. If, for example, you tell the story of how you came by your beliefs you will reassure your troll-ridden readers