creepycrawler

Good points, I could definitely be wrong in my estimate of the proportion of installations coming from the package manager. It may be that enough utility will be found in a fork. Nothing but to wait and see ;)

I hope software packagers for the various Linux distributions will disable this behavior, one or way or another, with or without the assistance of the Go developers. The official Go documentation can say whatever it wants, but in my experience the installation on Linux mostly happens via the distribution's package manager. The result would be that the software running for the majority of users will not send information to Google. It's not perfect, and won't do for some people (like me; I will remove Go and not write Go code in the future), but I think that'll remove the need for a fork for many people.

In practice, I can imagine the software packagers of various Linux distributions would set an environment variable to disable the offending behavior. This may be good enough for the majority of the software's stakeholders (users).

Not sure what your point is. With regards to the last sentence, I don't see the irony. People who don't like being tracked like local software, yes.

The world was already there, your bubble just burst. In recent decades tech companies and their programmers have done everything they can to collect data about users. Are you now surprised that the same companies apply the same practices for technical users of their software?

The solution, at least for me, is to remove that software from my life. Personally I vowed a long time ago to never work for a company whose business is to track people. It's no big deal for me, but I understand at least some may have hard decisions to make.

If they add "telemetry" my response would not be to set an environment variable, but to uninstall golang. I used it a few years ago, both personally and in a work setting, but I'll do so no more in the future. Just my opinion.

a..ac..ab..ac..ac..ac..ac..ab..ac..ac..ac..ab..ac..ac..ac..ac..ab..ac..ab..l..a..ab..ac..ac..ab..ac..ac..ab..ac..ac..ab..ac..ab..ac..ac..ab..ac..ac..ab..ac..ac..ab..ac..ac..ab..aca..ba..ca..ca..ba..ca..ba..ca..ca..ba..b..l..aa..ca..ba..ca..ca..ba..ca..ca..ba..ca..ca..ca..ba..ca..ca..ba..ca..ca..ca..ba..ca..ca..ba..ca..ca..ba..ca..ca..ca..ba..ca..ca..ba..ca..b..l..aa..ba..ca..ca..ba..ca..ca..ba..ca..ba..ca..ca..ba..ca..ca..ba..ca..ca..ba..b

Right, I just wrote about it in my reply to "lisper". The name "dotted list" may not have been the best choice, but that's not an outlier in human history.

The point was that dotted-list-p doesn't have anything to do with the "serialized form" (printed representation) of the list. Dotted lists are important because they are one of the two types of improper list, the other type being circular lists. Many Lisp functions work on proper lists.

Of course NIL is an ordinary symbol. It has roles, the same way other symbols have roles. Are you saying the symbol &BODY is not an ordinary symbol because it is a lambda list keyword? Are you saying the symbol T is not an ordinary symbol because type boolean is (member t nil)? Are you saying symbol * is not an ordinary symbol because it is a special variable bound by the REPL, it is used in declaration syntax, and also is the name of the product function? Are you saying MUMBLE:VAPORIZE is not an ordinary symbol because it names the most dangerous operation in the mumble library? They are all ordinary symbols, sometimes with unique roles. Because NIL was chosen to satisfy the role of the empty list, is it any wonder that type list is (or cons null), type null is (eql nil), LENGTH and ASSOC and other list functions can deal with it etc.? Of course not. That doesn't make NIL qua symbol any weirder than any other symbol that has particular roles in a given context.

There are many symbols in Common Lisp that you cannot DEFUN. See section 11.1.2.1.2 in the hyperspec. Since NIL names a constant variable but not a standardized function, macro, or special operator, you can bind it to a function lexically using FLET or LABELS.

Once again, NIL is not a cons, it is an atomic symbol that also represents the empty list, so it's no wonder that LISTP returns true and CONSP returns false. CAR and CDR take lists (again see their entries in the CLHS) so it's no wonder that they can work with it. RPLACA and RPLACD take conses only so it's no wonder that they don't. At the risk of stating the obvious (again and again) the type null is (eql nil) so it's no wonder that NULL returns T for it. That operators treat a symbol specially does not make a symbol weird. It merely means that it serves a particular role. Any symbol can take any number of roles within a program. That doesn't make the symbol weird. I will repeat once more, because I've a feeling you didn't get this. It doesn't make a symbol weird.

It is a basic matter, definitely. I learned all this stuff about conses, atoms, symbols, lists, etc. very early on, as baby Lisper. I don't know why someone who spent 35 years programming Lisp should have trouble understanding all this, and has to keep bringing up new irrelevant/incorrect claims instead of just opening a beginner's Lisp book and re-reading the first chapter or two, where they talk about all this stuff.

The name "dotted list" comes from how the list is serialized, yes, but not the concept. You can write a function dotted-list-p that takes an object and returns the value of (and (consp object) (cdr (last object))). Indeed, it is not related to the NIL issue, and I made no such assumption. You can read an equivalent definition that uses different words in the CLHS glossary.

You admit to talking about "how NIL is implemented internally", hence my original remark that you are conflating implementation tricks with language semantics. From language semantics point of view, NIL is not weird, it is an ordinary symbol, like NIK or NIM. Lisp tradition assigns it certain roles, like representing the empty list, representing the false value, representing the empty type, and also has conveniences like having NIL evaluate to itself or having CAR and CDR take lists instead of conses.

I didn't mean to be condescending. I know you are not a baby Lisper. The matter at hand is very basic, and I understand the desire to present a more sophisticated take, but believe it leads to (and reflects) a distorted ontological view of Lisp if taken seriously. NIL is not weird, it is a simple symbol. We just assigned it a few roles and made a few conveniences. Why did we pick it for those roles? Arbitrary choice. Why did we choose to extend the domain of CAR and CDR? Practical choice. Let the puritans complain and build their own ivory tower languages. Lisp is pragmatic. Could an implementor choose to represent NIL as a closet cons for simple CAR and CDR implementations and special case everything else? Sure. But this has nothing to do with the ontology of Lisp.

When baby Lispers are born, the first thing they are taught is a dichotomy: the universe is split into conses and atoms. Cons cells are simple and composed of two components, which are called the car and cdr. There are functions to retrieve what's stored in these components, which are called CAR and CDR. Atoms may be as complex as you like. They include objects like numbers, characters, strings, arrays, symbols, etc. NIL is not a cons cell, but a symbol. We can represent lists by chaining cons cells. We may start with an empty list, and by convention this is the symbol NIL. If we also choose to designate NIL as the false value, and everything else as true values, then it is useful to modify CAR and CDR so that they take not only conses, but also the symbol NIL, and return NIL, which is false, and the empty list. We then say that CAR and CDR take a list, i.e. an object of type (or cons null). We do not say that NIL is a cons.

Your [UPDATE] shows that you still don't understand what is meant by "dotted list". I already gave a definition of one, but did not give an example. An example of a dotted list is (a b . c) i.e. the last cons has a cdr that is (i) an atom (otherwise, it wouldn't have been the last cons) and (ii) not NIL (which is the conventional empty list designation).

You are conflating implementation tricks with language semantics. In Lisp, NIL is always an atom, never a cons.

Also, a dotted list is a nonempty list where the cdr of the last cons is not NIL. It is not a notational convention. A list (a b c) is not a dotted list, even if you write it as (a . (b . (c . nil))).

Replying to self because HN doesn't show me reply buttons to this comment's children.

This account is 52 days old, but the user behind this has been reading and posting on HN for a bit longer (let's say since PG decided to put HN online).

For the other comment, my point is that "genuinely wise" is much rarer nowadays, and instead we're drowning in "genuinely clueless". This is why you shouldn't learn about something's worth by reading HN comments nowadays. Instead you can put a limited amount of time actually studying the subject and then decide if it's worthy of more of your time or not.

Indeed, this type of threads always remind me that HN is not the same as it used to be. If you wish to learn about something (including about its worth), it's not the right place. Read books; read and write code; form your own opinions.

> Aside from signaling an error, the #\) reader macro is also useful because it changes the rules when reading symbols.

This is wrong. See http://www.lispworks.com/documentation/lw50/CLHS/Body/02_ad....

Sure you can.

    CL-USER> (set-macro-character #\) (get-macro-character #\())
    T
    CL-USER> )format t "Hello")
    Hello
    NIL

Instead of a general mushroom identification app, it could be a poisonous mushroom identification app. The dataset would only include poisonous mushrooms, and it will be made clear that it is not exhaustive. This could be useful to rule out some mushrooms.

It seems you're suggesting making CDR into an O(N) operation. So for example ordinary list processing algorithms that take O(N) will now be O(N^2).

Anyway, these kind of weird arguments from people who don't get it have been proposed and shot down a million times before, and I'm not sure there's any value reiterating. I suggest anyone interested in Lisp (or any programming language, really) ignore weird HN critiques and just read a book, like the one linked here.

To me this code just looks like a lot of boilerplate to just say:

    (replace (make-array count) batch)

Nemo judex in causa sua.

What does "refuse to collaborate" even mean?

There are multiple people who submit patches to free Lisp software. There are companies where Lisp people work together. There is free help offered in various Lisp fora.

Perhaps the author didn't receive free help on his own projects? Perhaps he didn't offer free help on other people's projects?

He did publish some elisp code, which you can see traces of in GNU Emacs and SLIME.

I did not mean to be aggressive, just direct.

There is no "Lisp community". In this family of languages, there are a bunch of individuals that sometimes form communities around areas of interest or particular fora.

If you looked into Clojure and Elisp, looking into Common Lisp or some Schemes could still be valuable, sure. All of them are in use. You can visit the relevant subreddits or chat channels or mailing lists to "get connected". Maybe even find some meetups or submit pull requests.

As far as I know there are no Emacsen in popular use today except GNU Emacs. There are some editors "inspired" by Emacs that are developed and possibly used by a few. These may be interesting and you may find them usable, but I'm not sure their authors would consider them part of the family of Emacsen just yet.

As a rule whenever the question starts with "do people consider", the answer is going to be: some do, others don't.

If you wish to "look into" Lisp, do the work: look at a bunch of resources, skim them, pick the ones that look intersting.

Asking whether to look into something is sometimes just a way to procrastinate. Questions like yours (not just about Lisp, but definitely about Lisp as well) are asked every day, and answers are (i) repetitive and (ii) abound. Just do the work.