Dylan: A New Language Is Blowin' in the Wind (1992)

> That was my point. Lisp s-expressions are used in Lisp not just because one can implement macros with them.

Right, and I held up macros as an example of manipulating the ast.

I may be wrong, but for many types of data, you would not typically use s-expressions - other than as an intermediary representation - your sql is "compiled" to binary datastructures, as are your images - and the machine won't be "running" s-expressions directly either. I think acknowledging the complex nature of our systems can be a benefit - and insisting on a simplistic abstraction can do the users (programmers) a disservice.

>> The fact that you have to choose between not being able to represent text (ascii) and a variable length encoding, also makes s-expressions less appealing today, than it once was.

> It's not clear to me what you mean with that. Can you give an example?

Ascii can't represent international text - but is a simple encoding to work with.

We've pretty much landed on a complex (by necessity) representation: variable length Unicode with support for different reading directions.

While a the high-level the parsing rules are similar "give me the parenthesis-like grapheme, parse numbers based on various local representations" - Unicode s-expressions aren't really simple any more - they are opaque binary streams that need parsing into reasonable abstract syntax tree-structures. Even utf32 doesn't really change this.

And I think languages like nim (or even to a degree python) show that such structures can be made pleasant, intuitive and powerful to work with. And doesn't limit us arbitrarily to simple symbolic data (eg the unpleasantness to work with a megapixel bitmap represented as s-expressions) - and helps lift our minds from "we can/should force everything to be text", to we should be able to work with our code and data in many representations, accepting the underlying tree structure - and (subjectively, obviously) I think that on the program/dsl/logic side, s-expressions are less human-friendly than something more like python.

It's one important reason why many of us don't prefer s-expressions for pseudo code.

Please read this: https://news.ycombinator.com/item?id=15113804

The only way that's been studied is running the code and inferring types based on the runtime behavior of the program.

This is still extremely error prone since you never have a guarantee that these runes are exhaustive enough to present the entire type spectrum that certain objects can receive. Besides, it's also obviously completely impractical (and defeats the purpose) to actually have to run your code before you can gain some type information about it.

No, there is really only one way to acquire the type information necessary for safe automatic refactorings, and it's to have type annotations in your source.

> Have you seen NewSpeak, a Smalltalk dialect by Gilad Bracha? I admit I was thinking more about it and similar systems than about pure Smalltalk of the '80s. Sorry about the confusion.

Yes, I followed NewSpeak when Gilad was working on it but I had little interest in it since Gilad perservered in the dynamically typed approach that is flawed on so many levels. StrongTalk was a more interesting experiment, in my opinion.

> I of course completely disagree that there are no such refactorings at all

There are very few of them, such as renaming a local variable. That's pretty much it. Anything else that goes beyond a very tiny lexical scope is impossible to automate safely.

> Then please stop stating unconditional superiority of static type systems.

It's pretty much a fact today. A decade ago, you could have argued that dynamically typed languages let you prototype faster and are less verbose than statically typed languages.

With today's generation of statically typed languages, these two advantages no longer apply and there is really no good reason to start a large project with a dynamically typed language.

This Wikipedia describes frames: https://en.wikipedia.org/wiki/Frame_language

Newton's frames were much simpler than full-blown frame systems designed for knowledge representation--just mutable finite maps, really. Basically, soups were persistent graphs of maps, (or dictionaries, or hashes, or objects, depending on your language background). Newton apps were also soups.

I didn't actually work on the shipping soups. I worked on bauhaus, the Lisp-based Newton OS, which had its own frame system that was a little more like what the Wikipedia article describes, though still simplified when compared to a full-blown knowledge representation system.

Apple had one of those, too, by the way. It was called MacFrames, and it was invented by Ruben Kleiman. Both Matt Maclaurin and I had been MacFrames users before getting involved with Newton. MacFrames later evolved into SK8, the Hyoercard-on-steroids project that never made it past management gatekeepers into the wild. I worked on SK8, too, after I returned to Apple post-NeXT, and when I ultimately left Apple it was to go to work for folks that I had met working on SK8.

That's yet another story. Those folks founded a startup named Reactivity, where I worked for another 7 years. Some of them are famous now--for example, one of the founders was John Lilly, formerly of Mozilla and now with Greylock; and another was Mike Schroepfer (everyone called him "Schrep") who is now Facebook's CTO.

I loved Reactivity, too, but I left it because of a health catastrophe. It was later acquired by Cisco, where, coincidentally, I'm doing some work now.

I'm compressing several more tomes worth of stories into the last couple of paragraphs there. I figure I can only ramble so much before it becomes a bore.

To my surprise, https://manuals.info.apple.com/MANUALS/1000/MA1510/en_US/New... is still up at apple.com. It says:

"Object Storage System

This system is key to the Newton information architecture. The object storage system provides persistent storage for data.

Newton uses a unified data model. This means that all data stored by all applications uses a common format. Data can easily be shared among different applications, with no translation necessary. This allows seamless integration of applications with each other and with system services. Data is stored using a database-like model. Objects are stored as frames, which are like database records. A frame contains named slots, which hold individual pieces of data, like database fields. For example, an address card in the Names application is stored as a frame that contains a slot for each item on the card: name, address, city, state, zip code, phone number, and so on.

Frames are flexible and can represent a wide variety of structures. Slots in a single frame can contain any kind of NewtonScript object, including other frames, and slots can be added or removed from frames dynamically. For a description of NewtonScript objects, refer to The NewtonScript Programming Language.

Groups of related frames are stored in soups, which are like databases. For example, all the address cards used by the Names application are stored in the Names soup, and all the notes on the Notepad are stored in the Notes soup. All the frames stored in a soup need not contain identical slots. For example, some frames representing address cards may contain a phone number slot and others may not.

Soups are automatically indexed, and applications can create additional indexes on slots that will be used as keys to find data items. You retrieve items from a soup by performing a query on the soup. Queries can be based on an index value or can search for a string, and can include additional constraints. A query results in a cursor—an object representing a position in the set of soup entries that satisfy the query. The cursor can be moved back and forth, and can return the current entry.

Soups are stored in physical repositories, called stores. Stores are akin to disk volumes on personal computers. The Newton always has at least one store—the internal store. Additional stores reside on PCMCIA cards.

The object storage system interface seamlessly merges soups that have the same name on internal and external stores in a union soup. This is a virtual soup that provides an interface similar to a real soup. For example, some of the address cards on a Newton may be stored in the internal Names soup and some may be stored in another Names soup on a PCMCIA card. When the card is installed, those names in the card soup are automatically merged with the existing internal names so the user, or an application, need not do any extra work to access those additional names. When the card is removed, the names simply disappear from the card file union soup."

I had some experiences working with the guy that were good in some ways and bad in others. The bad parts might have been his fault, or my fault, or both, or might have been because of environmental things that neither of us controlled. There's a good chance that they were caused by a combination of such factors. As always, it's hard to be sure.

He approached me when I was at NeXT. He wanted me to work for his startup. I had reservations. I thought there was a fair chance that it would go badly because of the bad things from before. On the other hand, I still liked him and I wanted my reservations to be unfounded.

They weren't. In fact, it was worse than I feared.

The language I was referring to was the version of Dylan that the bauhaus project used for our OS work. It was basically Scheme plus CLOS plus some functional-programming extensions, and a type system in which all datatypes were CLOS classes.

The development environment, named "Leibniz", was a greatly-extended version of Macintosh Common Lisp that included both the Common Lisp compiler (whose output ran on the Mac 68K-family processors and which was used to implement the whole development environment, including the Dylan compiler) and also the Dylan compiler and runtime, which was initially written for AT&T's Hobbit chips and later ran on ARM.

When bauhaus started our development machines were Mac IIfx boxes with great big Nubus cards sticking out the top. Later they were actual working Newton hardware ribbon-cabled to daughterboards in the Nubus slots.

Leibniz had two sets of everything: one for Common Lisp and one for Dylan. You'd think it would be confusing, but it wasn't, not after the first day or so. There were Common Lisp editor windows and Dylan editor windows. There were Common Lisp Listener windows and Dylan Listener windows. And so on.

That's still my favorite programming language.

I liked the development environment, too, but my favorite development environment ever was SK8, Apple's HyperCard-on-steroids-with-a-built-in-knowledge-representation-system.

If I won the lottery, I'd hire some smart friends to make a new SK8 with an updated version of the old Dylan and a 3D game engine designed for building immersive environments by modifying them as they ran.

Fair enough. I don't actually use #'compile all that much in my code. But I've been burned by these compromised pseudo-Lisps so much in the past that I tend not to trust them. And I wasn't aware that Lispworks had an ios solution; I'll check it out. Thanks.