PuercoPop

No, he took action to bring pain and suffering to a group of people because of their sexual orientation

And when Norvig made that claim in from of McCarthy, McCarthy disagreed.

> Peter bravely repeated his claim that Python is a Lisp.

> Yes, John?" Peter said.

> I won't pretend to remember Lisp inventor John McCarthy's exact words which is odd because there were only about ten but he simply asked if Python could gracefully manipulate Python code as data.

> "No, John, it can't," said Peter and nothing more, graciously assenting to the professor's critique, and McCarthy said no more though Peter waited a moment to see if he would and in the silence a thousand words were said.

http://smuglispweeny.blogspot.pe/2008/02/ooh-ooh-my-turn-why...

A better alternative is to have no comments at all (not joking). If the 'activation energy' of replying is higher, more thought will go into the reply.

I'd say no, design patterns are about mechanism, 'I want to do X, this pattern is how I do it'. In that way they are similar to monads. Pardigms are about a perspective, a vantage point from which you structue your application.

Say dataflow programming, for which Norvig's sentence generator in PAIP is an excellent introduction, one can use a switch/case or an object with functions as values. Both accomplish the same, but in the latter I change the flow of my program by changing a value in a map.

I used Vis full time for a two weeks a couple of months ago. It was pretty nifty. (I'm Emacs user so this was an time-bounded experiment).

Vis is a great of example of the suckless philosophy and of Guy Steele's point about removing the need of features by having synergy between other features. For example they have an immutable piece table to support undo by just moving a pointer. This would mean that as the buffer remains open one would use more and more memory. Instead of implementation a 'garbarge collector' they chose to automatically close a file when its not shown on the screen.

It is fast.

They are implemented in Emacs as well. There is no meat in the article, no proper comparison between Emacs and VSCode

It is only going to be called once (per componented used in) upon loading the page. No biggie

It is also because CLISP is unmaintaned. But the only implementation dependant code I remember is the socket code.

But CLISP wasn't unmaintaned when the book was written más its default REPL is much better than other implementations. It was a good choice at the time.

Can't find the quote I was remembering, but it said that Lisp didn't had lexical scope. The book was published in '92, so Lisp already had lexical scope. (Which was introduced by Scheme IIRC)

Here is another one I found looking for the quote I was remembering.

> "It has higher-order functions, meaning that a function can be passed as an argument and return as the result of another function – as in Scheme, C and Haskell, but not Pascal and Lisp.

> Lisp trolls existed even back the

Recently while reading, Appel's Compiling with Continuations, I read some mistaken claims about Lisp and scope, one doesn't have to be a troll, which requires intent, to make ignorant claims about Lisp, parsing or any subject. Although the amount of ridiculous arguments from people who clearly haven't used it (or at most used it very briefly) does make one's blood boil at times.

For more low-level Lisp see

https://github.com/kingcons/cl-6502/blob/master/README.md

And the corresponding book

http://redlinernotes.com/docs/cl-6502.pdf

Apropos vc-mode comes with vc-annotate-mode (C-x C-v g) which is the best way to go through the history of the file

If one pays attention to SystemD bugs, it is pretty clear that SystemD is sorely lacking in engineering.

Yes, it certainly a gaping security hope. Yet I cant bring myself to submit a patch

They are talking about this issue

https://github.com/slime/slime/issues/286

If it has being left unaddressed because no one thinks it is enough of a problem. That is how free software works

Yes, Clojure is a Lisp. Lisp is also the shorthand way people refer to Common Lisp. Lisp in the context of OP means Common Lisp.

Common Lisp has an implementation, ABCL, which runs on top of the JVM. Access to the Java ecosystem is a shared trait, not a difference.

Being a multi-paradigm language CL has a wealth of features That Clojure doesn't and they all play well together. Except for the type system and the class system.

For example, it has places and the ability to define your own setf forms.

Common Lisp makes iteration easy with the lisp macro.

Common Lisp has tagbody and gotos so one compile FSMs efficiently

Common Lisp has an object system were the semantics are describe using the same object system. So users can extend the object model according to their needs.

Clojure is designed to support one style of programming envisioned by its hypemaster. Rich Hickey is a brilliant person, and has done an excellent job designing Clojure, but

Clojure approach to 'user erros' is we don't guarantee to signal an error, we may do w/e.

By momentum you mean it is trending. We know mainstream programming is a pop culture, but we shouldn't encourage it by recommending one language over another based a FAD.

History says otherwise, they been ignoring Slime's swank for at least a decade

> Has anyone ever built a useful and successful decentralized service.

E-mail fits all of your requirements. Even the now being centralized (Gmail)

The question was how do they compare. 90% of your list applies to CL as well. (CL has sheeple as its prototype based Object system).

The statement about macros is more nuanced that you let on, language decisions like being a Lisp-1 w/o a symbol namespace (CL packages) make hygiene a necessity which in turn complicates writing macros. One thing I do like about racket is that it comes with support for writing pattern directed macros, that although possible to write in CL has no built in tools for it. Another point for racket is that it has support for macros with better error reporting (ej the elipsis).

15 is really the main selling point for racket. It is a Language creating toolbox (I forget the term they use for it). It's module system stands out in that regard compared to CL, which has read tables as a way to customize the reader. Racket's solution is more general and extensible in that regard.

16 is not true when compared to CL. The IDE of racket is way behind slime/sly, however it doesn't require setup.

The other big difference is that CL is image based and suited for interactive development while Racket is batch oriented, 'python-style' of interactivity. If you come from Python you will think racket is interactive, but if you come from smalltalk you'll know what you are missing.

As Aiden said, both are great languages, flip a coin.

It baffles me that people refer to languages as interpreted or compiled. That is a property of the implementation of the not the language.

They mentioned the census as a use of database (tool) that is not immoral not as being equivalent to a Muslim/Jewish registry. You seem to be missing their point

Can't say that matches my experience, I've never encountered any problems with sending patches as an attachment. And find the process simpler than github.

No need to git diff. Git format-patch does the work for you. Apply the patch with git apply-patch. Less work than sending a PR and the receiver has to do less work to merge locally in a branch should they want to modify something. Github does make it easy for drive by commits for typos an trivial changes like that.

> For instance you will never see GPLv3 code running on iOS because you just can't have it there

That would be a case against iOS, take it up with the masters of your walled garden.

Len/Mathematics runs on Cuis Smalltalk. Which has the goal of being small and easy to understand and extend. So it should be to your liking.

I found the difference of the image with the book similar to little exercises to test what I had learned so far.

Also being able to easily introspect the code of what you are interacting with is what makes Smalltalk easily discoverable in my experience.

Disclaimer: I only dabble with Smalltalk every now and then.

Has anyone tried installing it? Earlier today on a recent checkout of Cuis-smalltalk-dev and encountered an error.

Someone already has: https://github.com/eschulte/curry-compose-reader-macros

Recur only handles a limited case of tail call elimination, not when the function calls another function on the tail position. Also you can implement TCE on the JVM Kawa Scheme does, just not efficiently. It is a limitation resulting from the design decision of Clojure.

SBCL does TCE on some circumstances/optimization levels, not on every instance. Nor is it portable nor idiomatic CL. (Although I certainly write code that depends on it sometimes)