mikelevins

Probably, if I could contact them. But all the links I turned up lead me back to the captcha black hole, and the only email address I've found elicits a reply telling me that nobody is reading it. Perhaps something is reachable through additional effort, but I'm not particularly motivated to keep searching further. Perhaps someone there reads HN and would like to know this happened to someone, in case they want to fix it (for someone else's benefit if not for mine).

I was interested in the Steam machine, but I might not get one because I cannot log in to my Steam account, for no reason that I know. Steam's web-based process for resetting my password always gets stuck after successful completion of the captcha, regardless of which device or OS I use to do it, the accessible-to-Google procedures for getting past that blockage have not worked, and the email address that one could once use in this situation now just sends an autoreply that says no one is monitoring it anymore.

So I have exhausted all of the obvious routes for logging into my Steam account. Perhaps there are additional routes to discover, but I'm not particularly motivated to look for them at this point. If just getting logged in is this painful, I'm not particularly optimistic about the experience of buying or owning the thing.

In the early 1990s I worked on a couple of different projects at Apple that were done mainly in Common Lisp. When I was working on one of those, another of them hired a guy named Dave Vronay a young skater and assembly-language game-machine hacker to work on graphics and UI stuff. The Lisp we were using is the one that started as Coral Lisp, became Macintosh Allegro Common Lisp, then Macintosh Common Lisp, then OpenMCL, and more recently Clozure Common Lisp.

I remember stopping with a friend to chat with Dave one day not too long after he joined the team and he was over the moon about how the Lisp exposed not just an assembler, but an interactive assembler: he could write assembly routines, evaluate them, and see them run immediately, and also inspect the in-memory data that they operated on. He seemed so happy.

It's going pretty well, though it took at least six months to get there. I'm helped by knowing the domain reasonably well, and working with a principal investigator who knows it well and who uses LLMs with caution. At this stage I use Claude for coding and research that does not involve sensitive matters, and local-only LLMs for coding and research that does. I've gradually developed some regular practices around careful specification, boundaries, testing, and review, and have definitely seen things go south a few times. Used cautiously, though, I can see it accelerating progress in carefully-chosen and -bounded work.

Yes, I successfully fixed it. The fix was about ten years of regular practice of Chen style Taijiquan with good instruction. It’s not a quick, cheap, or easy fix, and it’s pretty hard to find good instruction, but it solved my problem.

It also seems to have solved RSI issues, but that’s impossible to prove.

I'm finding that in several kinds of projects ranging from spare-time amusements to serious work, LLMs have become useful to me by (1) engaging me in a conversation that elicits thoughts and ideas from me more quickly than I come up with them without the conversation, and (2) pointing me at where I can get answers to technical questions so that I get the research part of my work done more quickly.

Talking with other knowledgeable humans works just as well for the first thing, but suitable other humans are not as readily available all the time as an LLM, and suitably-chosen LLMs do a pretty good job of engaging whatever part of my brain or personality it is that is stimulated through conversation to think inventively.

For the second thing, LLMs can just answer most of the questions I ask, but I don't trust their answers for reasons that we all know very well, so instead I ask them to point me at technical sources as well, and that often gets me information more quickly than I would have by just starting from a relatively uninformed google search (though Google is getting better at doing the same job, too).

I've been experimenting with that from a slightly different angle: teaching Claude how to play and referee a pencil-and-paper RPG that I developed over about 20 years starting in the mid 1970s. Claude can't quite do it yet for reasons related to permanence and learning over time, but it can do surprisingly well up until it runs into those problems, and it's possible to help it past some obstacles.

The game is called "Explorers' Guild", or "xg" for short. It's easier for Claude to act as a player than a director (xg's version of a dungeon master or game master), again mainly because of permance and learning issues, but to the extent that I can help it past those issues it's also fairly good at acting as a director. It does require some pretty specific stuff in the system prompt to, for example, avoid confabulating stuff that doesn't fit the world or the scenario.

But to really build a version of xg on Claude it needs better ways to remember and improve what it has learned about playing the game, and what it has learned about a specific group of players in a specific scenario as it develops over time.

Besides programming, my hobbies are writing stories, writing and recording songs, drawing, and painting. None of them needs to cost anywhere near $3000. Any of them can cost as much as you want.

Take the music hobby as an example. I have several expensive guitars now, but in the first 20 years of that hobby I probably spent under $1000 on guitars and related gear the entire time.

I think the decline in UI quality is real, but I don't think the web takes all of the blame. The blame that it does take is due to a sort of mixed bag of advantages and disadvantages: web technologies make it quicker and easier to get something interactive on the screen, which is helpful in many ways. On the other hand, because it lowers the effort needed to build a UI, it encourages the building of low-effort UIs.

Other forces are to blame as well, though. In the 80s and 90s there were UI research labs in indistry that did structured testing of user interactions, measuring how well untutored users could accomplish assigned tasks with one UI design versus another, and there were UI-design teams that used the quantitative results of such tests to deign UIs that were demonstrably easier to learn and use.

I don't know whether anyone is doing this anymore, for reasons I'll metion below.

Designing for use is one thing. Designing for sales is another. For sales you want a UI to be visually appealing and approachable. You probably also want it to make the brand memorable.

For actual use you want to hit a different set of marks: you want it to be easy to learn. You want it to be easy to gradually discover and adopt more advanced features, and easy to adapt it to your preferred and developing workflow.

None of these qualities is something that you can notice in the first couple of minutes of interacting with a UI. They require extended use and familiarization before you even know whether they exist, much less how well designed they are.

I think that there has been a general movement away from design for use and toward a design for sales. I think that's perfectly understandable, but tragic. Understandable because if something doesn't sell then it doesn't matter what its features are. Tragic because optimizing for sales doesn't necessarily make a product better for use.

It's called aging. Just wait until the first time you head back down the hall from the living room to the bedroom to get the thing you forgot to bring with you, get distracted for a moment by a pet or family member, and then can't remember if you were going down the hall to the bedroom or the living room.

The essence of Common Lisp (and other Lisps) is the metacircular evaluator from John McCarthy's Lisp 1.5 Manual:

https://michaelnielsen.org/ddi/wp-content/uploads/2012/04/Li...

This is the half-page of code that Alan Kay famously described as "the Maxwell's equations of software."

Common Lisp and MACLISP before it and Lisp 1.5 before that worked by providing a running program that implements the functions given in that half page and applies them and their effects iteratively to their own environment.

In other words, the basic model is that Lisp is a running program that you modify interactively by feeding expressions to it one after another.

Common Lisp's model still works like that: when you give it a source file it reads one expression after another from the file, evaluating the expressions as it goes, and altering the running environment to reflect any changes that they make, such as adding new definitions, updating data structures, and so on.

The Lisp reads the next well-formed expression, converting it into Lisp data structures. It then evaluates the resulting data structure, yielding some number of values and updating the environment at the same time. (In Common Lisp even pure functions have side effects if evaluated by the read-eval-print loop because the standard defines a globally-accessible variable named * that contains the value returned by the most recently-evaluated expression).

Common Lisp's design reflects this basic model, and much of its standard library is concerned with making it convenient to work this way. The ANSI standard likewise reflects this basic model of computation, including features specifically designed to support this style of interactive programming.

The process of evaluation allows, but does not require, compilation. Common Lisp interpreters (usually called "evaluators") do exist, but most practical implementations provide compilers that compile each expression in order to evaluate it. Some implementations are "compiler only": that is, every expression is always compiled in order to be evaluated, whether it's in a source file or typed at a repl prompt.

To answer some of your specific questions more directly:

is behavior when running a script in "interpreter" mode guaranteed to be the same as when running in "native compiled code"?

"Guaranteed" is a strong word. ANSI specifies the behavior, and it's generally the same whether code is interpreted or compiled. That may be hard to achieve for some expressions, but if you find an example of different behavior, that's most likely a bug in ANSI compliance.

(I should allow for the possibility that the ANSI spec has some corner somewhere that allows for a difference, but I can't think of any off the top of my head. Of course, the spec is large and my memory is imperfect.)

At what point does the compiler create an intermediate representation?

Depends on what you mean. Under some interpretations and in some implementations there may not be an intermediate form.

The normal lifecycle of an evaluation is:

- read: ingest text and convert it to Lisp data

- macroexpand: rewrite any macro expressions in the data

- eval: use eval and apply on the data to yield some result values

- print: convert the result values to text in a standard format and print it to *standard-output*

You might regard the result of the read function as an intermediate form, but I would say that what read produces is Lisp source code. In my view, the original text is not Lisp source code; it's a serialization of Lisp source code. Read converts the text into Lisp source code.

ANSI does not specify in detail exactly what eval has to do in order to yield results. It specifies abstractly what each function, macro, and special form is supposed to produce, and what side effects they are supposed to have on the running environment, but the details of how the code is generated and executed are up to the implementation. An implementation can simply walk the source code interpreting forms and producing the required effects; or it can convert them to some intermediate form such as bytecode and then let a byecode interpreter do the evaluating; or it can compile them directly to native code that does the evaluating when executed. These are implementation details not specified by ANSI.

One detail that is specified by ANSI is the expansion of macros. Macros are expressions that look like function calls or special forms, but which are implemented by applying a macro-expander function to the expression to produce a new expression that is then given to the evaluator. Macros may be defined by the system or by the user. They are expanded after read and before eval. The spec goes into some detail about how this process is supposed to work and what features of the language affect it.

Why does SBCL not use LLVM?

LLVM's first release was 2003. SBCL's first release was 1999. Moreover, SBCL is a fork of CMUCL, which was first released in 1980, though that was before Common Lisp existed. It was called SPICE Lisp at that time, and the compiler rewrite that would turn it into Common Lisp happened about five years later.

The point is that one important reason that SBCL doesn't use LLVM is that it's a large mature codebase that predates the existence of LLVM by about 23 years. I'm not saying it would be impossible to port SBCL onto LLVM, but if you did it would be so much changed that it wouldn't really be SBCL anymore. It would probably also be easier to just write a new Common Lisp on LLVM (which is what the CLASP project has done).

At what point are #-starting words(read macros?) evaluated and how is that different from interpreting to compiling.

An expression that starts with "#" is, as you alluded to, a reader macro. What that means is that when the read function starts to read the expression it encounters the "#" and that triggers it to look up the next character in a table of special read functions. If it doesn't find anything it signals a READER-ERROR. If it does find something then it applies the found function to the input to read it.

For example, if you feed it "#'+" then it looks up the quote character in the table of reader macros and finds a function that converts the expression to "(function +)". When "(function +)" is evaluated it returns the function that is globally bound to the symbol named "+".

So the sequence is:

  "#'+" -> READ -> reader macro -> EVAL (function +) -> return the function bound to +

How do I control the amount of optimization the compiler will do?

With the declaration OPTIMIZE: http://clhs.lisp.se/Body/d_optimi.htm#optimize

For example, (declare (optimize (speed 3)(safety 0)))

Will the interpreter ever try to optimize?

The answer is implementation specific, and may not even make sense (for example if you are using a compiler-only implementation).

Is garbage collection implementation-defined?

To a large extent, yes. The spec assumes that implementations provide automatic memory management, but I think the only directly-related feature specified by ANSI is the ROOM function. Every implementation I know of also has the GC function to trigger a collection, but I don't think it's in the spec. Different implementations also have different GC strategies, they may have more than one GC implementation, and they provide various different implementation-specific tools for inspecting and controlling GC behavior.

And Larry Tesler, who was a particular champion of usability testing and important in the development of the Human Interface Group. Larry cared a lot about usability.

When I was at NeXT, Steve Jobs told me that if it was up to him, Apple would get rid of the Human Interface Group. (Steve was rather hostile to Larry.)

Later, when it was up to Steve, he did exactly what he said: he got rid of HIG.

I think it’s easier to sell visual design than it is to sell usability because people see visual design immediately, but it takes time and experience to see and understand usability (and some users never seem to consciously notice it at all).

At some moments there has to be a singular decision taken, such as which of two possible options to take. In such a moment some particular consciousness makes the decision, if it’s a decision made by a consciousness (though consciousness takes credit for more decisions than it actually makes, I think).

But granting that point does not grant that there is a single consciousness that is always (or ever) in charge, and it does not grant that any specific consciousness is associated with any specific singular narrative.

We know, scientifically speaking, some things that call the idea of a single consciousness with a single narrative into question. We know, for example from psychology of testimony that the same person’s memory of the same events differs at different times, and that the act of remembering rewrites memories. We have reason to suspect that the brain attributes to conscious choice decisions that are made too quickly for sensory data to reach the brain (and which may therefore be made elsewhere in the nervous system, even though the brain claims to have made the choice after the fact).

And I know from personal experience that some phenomena that normally appear to be singular conscious experiences can devolve into something else under some circumstances. For example, I have experienced blindsight, in which I cannot see something but can nevertheless collect accurate information from it by pointing my eyes at it. I have also experienced being asleep and awake at the same time.

Experiences like these are hard to account for if I assume that my consciousness is singular and continuous and in charge, but not so hard to account for if I assume that it’s a useful illusion cobbled together by a network of cooperating processes that usually (but not always) work well together. For example, many people might claim that it’s nonsense to say that a person can be asleep and awake at the same time, but it’s nonsense only if asleep and awake are mutually exclusive states of a singular consciousness. If, on the other hand, they are two neurological processes that are normally coordinated so that they don’t occur at the same time (because it’s less than useful for them to do so), then it’s not nonsense to observe that under unusual circumstances that coordination might be disrupted. Similarly, if seeing something is one process and consciously experiencing seeing it is a different process—normally, but not necessarily coordinated—then blindsight is not so hard to account for.

Not to mention that it’s trivially easy to find examples of consciousness not being in charge of our behavior, although it likes to think that it is.

I suggest that the supposed singular consciousness, supposedly in charge, may be an illusion constructed by a system of mostly, but not perfectly, coordinated cooperating processes.

How do you know there aren't several different consciousnesses that all think they are Peter?

How do you know they aren't just constructing whatever narrative they prefer to construct from the common pool of memory, ending up with what looks like a single narrative because the parts of the narrative come from the same pool and get written back to the same pool?

Perhaps each consciousness is just a process, like other bodily processes.

Perhaps a human being is less like a machine with a master control and more like an ecosystem of cooperating processes.

Of course, the consciousnesses like to claim to be in charge, but I don't see why I should take their word for it.

What makes you think a singular consciousness controls the body?

Or perhaps they all leave traces, but all write to the same log? And when reconstructing memory from the log, each constructed consciousness experiences itself as singular?

I was mikel@apple.com for about a decade. I never got misdirected mail, probably because there aren’t all that many people with the first name "Mikel." The only other one I personally know of is Mikel Bancroft, who works at Franz, inc.

Of course the dialects are not so densely distributed in North America, and English has only been evolving in the Americas for a few hundred years, but there are a bunch of dialects, and I find them super interesting.

My paternal grandparents were honest-to-goodness Ozark hillbillies who spoke Ozark Midlands (also called South Midlands), which is very close to, and sometimes conflated with, Appalachian English.

I'm in the Ozarks now and at least in the region where I live, this dialect seems to be disappearing. I still hear traces of it, but I don't think I've heard anyone really speaking it in years.

That's too bad. I love that dialect--perhaps because it was the language that my grandparents spoke.

If you're curious about it, you could listen to some of Terry Gross' interview with Ralph Stanley. He spoke Appalachian English, but it's indistinguishable to my ear from the language my grandparents spoke.

Here's the interview at NPR:

https://www.npr.org/2016/06/24/483428938/bluegrass-legend-ra...

It is, but they borrowed it from Hegel. I’m not particularly a Hegelian myself (it seems to me more like a cute trope than a law of nature), but being a Hegelian doesn’t necessarily mean that you’re also a Marxist.

As a person with a graduate education in psychology who makes his living by being considered technical, who has made his living around 35% of my 37-year career as a technical writer, and whose technical writing has been described in glowing terms by professionals in the tech writing field and the engineering leadership at FAANGs, some of them famous for their technical contributions, I disagree with your assessment.

I think it's a rather well constructed piece about social boundaries that is incidentally somewhat technical (though, I'm guessing, its technical aspects are from outside your field).

To be clear, the construction I’m endorsing is: "were available only in Lisp until recently", which is the construction that my editors typically proposed for similarly ambiguous deployments of "only". The ambiguity in the original placement is that it could be interpreted as only available as opposed to available and also something else. My editors always wanted it to be clear exactly what the "only" constrains.

He says Lisp, rather than Common Lisp. Sure, given the context he's writing in now, maybe he means Common Lisp, but Joe Marshall was a Lisp programmer before Common Lisp existed, so he may not mean Common Lisp specifically.

We need art, too. We may not know what we need it for, but we evidently need it for something.

We've been making art for a really long time. We've been smearing colors onto surfaces for at least tens of thousands of years, and carving patterns into rocks and shells for at least hundreds of thousands of years.

Everywhere you find human communities, you find some kind of art. We must need it for something. If we didn't then it wouldn't be so ubiquitous.

It's perfectly good and idiomatic English, but it's an ambiguous formation and your suggested edit does clarify it.

The author of the referenced post is one of them, though.

Honestly, the short lifespan is the main disadvantage. It's made worse by how intelligent and sweet they are.

My daughter's rats hurled themselves at the sides of their cage when she woke up each morning, sticking their tiny hands out through the bars to clutch at her. When she did let them out they would run up her arms and sit on her shoulders licking her cheeks like tiny dogs.

Cedric died at the expected age of a little over two years. Bosco lived unusually long, dying at about five years of age.

You might want to consider what you know of your daughter's personality and how much of a trauma the rat's death is likely to be. My daughter was okay, but she was a young teen by the time Bosco died.

One potential downside, depending on how fastidious you are: they constantly leave scent marks everywhere, by depositing tiny drops of urine and rubbing fatty secretions from their sides on things. The amounts are truly tiny, maybe too small for you to even notice, but probably better to know about it in advance in case it icks you out. I don't think I or my daughter ever noticed them at all, though I did know about them.

I had a couple of hobbies (lucid dreaming and shamanic trance drumming) that enabled me to experience big disconnects between the subjective experience of time passing and objective measurable wall-clock time. Some dreams and trances subjectively appeared to be much longer than the wall-clock time recorded by clocks and human helpers.

I don't have any definite knowledge of what's going on with that, but I suspect some part of it is my brain retroactively manufacturing the memory of lots of time passing, and some part of it is my brain confabulating episodic memory about the dream or trance as I wake up and write it down.

Human memory is well known to be generally unreliable and full of confabulated details, so I think the most parsimonious explanation for differences between the time experienced in dreams and the objectively-measurable time that passes is that our brains are just making shit up.

Of course, the idea that your brain just lies to you about the past might be just as creepy as any other explanation.

You bet.

I feel like use of the term "homoiconic" is misguided. It seems like an attempt to turn an incidental attribute of some Lisps into a sort of Platonic ideal. I don't think that's helpful.

I think the property being discussed is more understandable if you just describe it simply: in some Lisps (notably Common Lisp and its direct ancestors) source code is not made of text strings; it's made of symbolic expressions consisting of cons cells and atoms.

The text that you see in "foo.lisp" isn't Lisp source code; it's a serialization of Lisp source code. You could serialize it differently to get a different text file, but the reader would turn it into the same source code. The actual source code is distinct from any specific text serialization of it.

We write programs in the form of text serialization because the reader will convert it for us, and because it's easier and more rewarding to write good and comfortable text editors than to write good and comfortable s-expression editors.

There are of course text editors and addons that attempt to make text editing act more like s-expression editing, but I don't know of many actual s-expression editors. The canonical one, I suppose, is Interlisp's DEdit, which operates on actual s-expression data structures in memory.

From this point of view, what people mean by "homoiconic" is just that source code is all made of convenient arrangements of standard data structures defined by the language that can be conveniently operated on by standard functions defined by the language.

Or, to put it another way, "homoiconic" basically means "convenient", and "non-homoiconic" means "inconvenient".

That's all there is to it, really, but it has far-reaching consequences. In a Lisp designed this way, basic manipulation of source code is trivially easy to do with operations that are all provided for you in advance by the language itself. That makes all sorts of code-processing tools exceptionally easy to write.

That's not true in most languages. Take C, for example: sure, a C compiler parses text and turns it into an abstract syntax tree before processing it further in order to eventually yield executable machine code. Is all of that machinery part of the language definition? Can you count on those APIs and data structures to be exposed and documented by any arbitrary C compiler?

No.

In that sense, any programming language could be made "homoiconic" if enough people wanted it. They manifestly don't, because most languages aren't.

But some programmers prefer working with a language implementation that makes it so very easy to manipulate code. So that's what we use.

It's not some Platonic ideal of language design, but it doesn't need to be. It's a pragmatic design decision made by certain implementors in a certain lineage, and it has consequences that a certain fraction of programmers find congenial. Congenial enough that it makes some of us prefer to work with languages and implementations that work that way.

The discussion has various conflations, omissions, and errors. It's been a long time since Dylan on the Newton was what I worked on every day, and my memory is no doubt faulty, but I'll do my best to correct a few things.

"Apple itself had a very nice system for UI development on Dylan that was arguable better in many way then the Next system. But when Steve Jobs came and they had Next, that wasn't developed anymore."

This one is misleading in a couple of respects. First, there was more than one Dylan development system at Apple: Leibniz for the Newton and Apple Dylan for the Mac (I think it was called "Hula" internally, but I may be wrong about which project got that name). Both were written in Common Lisp using MCL, but they were distinct projects with different goals. Neither had tools like NeXT Interface builder. The Lisp-based application builder that rivaled (and in my view surpassed) Interface Builder was SK8, which was unrelated to Dylan. SK8 was also written with MCL.

Dylan was not canceled because Steve Jobs returned with Nextstep. The cancellation happened several years before Steve came back and was part of Apple's normal product and project churn.

"Apple Dylan seems incredibly limiting and opinionated for no reason."

It didn't seem that way to me, but that's about all I can say to a vague subjective impression of this kind.

"I find it interesting the website lamenting its death only shows screenshots [2][3][4] of the "advanced" editor, rather than any successful applications made using Dylan."

There weren't really any successful applications made using Dylan, if you mean shipping products. It never got that far along.

There were projects written with Dylan that were successful on technical merit, but never shipped for reasons that had nothing to do with their technical quality. For example, the final review of bauhaus told us that we had met and exceeded every metric of success, but Apple management just didn't want to ship a Lisp OS for Newton, full stop.

But yes, Nextstep was dogfooded to a degree that Dylan was not, and it was much farther along than Dylan ever was.

"There were two teams fighting for delivering the OS, one using Dylan, other using C++, eventually the C++ team won the internal politics, even though the Dylan one was relatively ahead."

This characterization is misleading in a few ways. I wouldn't say the teams were fighting, and I wouldn't say the Dylan team was ahead, except in maybe a couple of narrow areas.

Initially all Newton development was done in Dylan (called "Ralph" at that time), except for work on the microkernel, which was C++, and the 7 "bottleneck" graphics routines from QuickDraw, which were C.

The Newton team did substantial work on the software system in Dylan, and it worked, but there were some objections. Larry Tesler objected that it was too much like a desktop OS and needed to be redesigned for a handheld device with touch input. Meanwhile, some discussion took place with John Sculley during one of his trips to Japan and when he came back he ordered Larry to move main system development to C++. Larry did so, but reserved a small group of programmers (of which I was one) to continue experimenting with Dylan to see what we might accomplish.

We accomplished too much: we ended up making a whole second OS in Dylan. That's not what Apple management wanted, and they canceled our effort. That was no surprise to me; what surprised me was how long they tolerated our experiment before pulling the plug.

Then again, Apple in those days was a sort of constellation of skunkworks projects. Apple engineers would go off in random directions when not under threat of looming deadlines, and cook up all sorts of wacky things, and it was sort of tolerated because sometimes those wacky projects turned into things that made money.

"> The platform which Dylan was originally designed for, the Newton had no C to begin with. These platforms had no development tools. The firmware and software runtimes were created outside. I would guess that there definitely C was involved for much of the firmware and that an on device Dylan runtime had C and assembler code."

I don't know of a Newton platform for which C tools did not exist.

The Newton originally targeted the AT&T Hobbit (https://en.wikipedia.org/wiki/AT%26T_Hobbit), which was a RISC chip designed to run C efficiently. By the time I was recruited the boards were using ARM chips, but the Newton microkernel was already written in C++. Perhaps there was a time when a Newton existed without a supporting C compiler, but I never saw it.

Now it might be that you meant that no C compiler or development tools ran on Newton hardware, and that much is true. The Dylan development didn't run on the Newton hardware, either. All dev tools ran on Macs and cross-compiled to the ARM platform.