Arc Forumnew | comments | leaders | submit | akkartik's commentslogin
3 points by akkartik 14 days ago | link | parent | on: Mu no longer requires C

As of last night, Mu can package up a codebase (Assembly files in my special syntax) with a Linux kernel into a bootable disk image and deploy it to Linode. I've updated the top of with details.





2 points by krapp 33 days ago | link




    (defgrammar infix ...)
    (w/grammar 'infix (do



3 points by akkartik 46 days ago | link | parent | on: Readable Lisp S-expressions Project

My critique:

The final straw for me was when I tried to actually _use_ sweet expressions for something. I described it here: (Warning: lots of bad ideas in this thread)


1 point by akkartik 62 days ago | link | parent | on: MakerLisp Embedded Lisp Machine

I'm considering buying this machine in a month or so. (The author says the full system will be available in a month: .)


1 point by akkartik 21 days ago | link

My MakerLisp machine is up and running!


Very cool! The codebase ( or the book (


2 points by jsgrahamus 79 days ago | link

Hair loss would be due to trying to think in a Klongish manner. Have only gotten a ways into the Klong book.

Nils is a prolific author and has even written non-CS titles to include Yoga and Zen (in German).


3 points by akkartik 121 days ago | link | parent | on: Ask Arc: Arc forum RSS

> There's something to be said for minimalism like that. Not only does it make the initial development easier, but I imagine it's easier to do mashups and derivative works too.

If I may kick off a tangent, this is the part of "Worse is better" that tends to be forgotten/deemphasized in Pitman's formulation[1]. C and Unix succeeded because they focused on keeping the implementation simple and accessible for many years. (They eventually forgot that lesson, of course, and have been coasting on the initial momentum for a very long time.)



2 points by shader 119 days ago | link

Indeed. And Richard actually makes that point, that the "initial virus" has to be good and simple, and that having won it will have much more pressure to improve until it gets to 90% of "good". Unfortunately, in the process it conditions users to accept worse, and the patching process probably doesn't result in a simple end result.

In fact, reading the story about the "PC loser-ing problem", I realized that I was so conditioned by the Unix solution that I had never even _considered_ the former as a possibility. I do sometimes wonder how many amazingly good ideas we've lost, that would now actually be much simpler than the stack we have, but we're just used to it.

I think the concept could be better generalized by rephrasing it as "cheaper is better" though. Technically it's not "worse", it just has a different set of values. Obviously, users value it more, or they wouldn't adopt it. I see it as closely related to ideas like "compatibility is key", "customer is king", and "money is power", each of which builds on the following.

Customers adopt products that have the best cost-benefit ratio. It doesn't matter if the fancy "good" solution is 10% better (from 90% to 100%) if it also costs 2x as much. Maintenance of the ideal solution may actually be cheaper, but it's really hard to estimate maintenance in advance, especially in design fields like software development. Once the "cheap" solution is adopted, future adoption and upgrades are even cheaper compared to switching to the "good" solution, because the user is already invested, and has built a network of integrations that would be very hard to replicate.

The network effect and basic epidemiology probably provide good explanations for the rapid victory of "cheap" solutions—they spread faster because they are easier to "get", and that amplifies the infection rate to new nodes. Anyone can understand why to adopt something cheap. It takes a lot of effort to learn and understand the technical advantages of a superior system. Given the work involved in properly evaluating competing options to discover technically superior solutions, I think it's safe to assume that the percentage of potential customers that just pick the cheapest one that works, or that is already adopted by the largest number of other users, will always be higher than those who actually compare all the options to pick a better solution.

So "worse" solutions actually are "better", because they're cheaper to adopt. This is especially visible when you look at history and see how many times the systems focusing on backwards compatibility won out over those that merely tried to be "new." Compatibility reduces the cost of adoption. It's that simple.

Does that mean that we're doomed to a "race to the bottom"? I don't think so. In fact, I think with some care new solutions can be designed that are sufficiently better/faster/cheaper that they do disrupt the existing ecosystem. It happens all the time. We see Facebook beating Myspace, all the various chat programs killing XMPP, Slack starting to eat IRC, etc. Most of those did it by making adoption easier for new users. The secret is that a new system doesn't have to replace the existing system, just be easy to adopt. Lots of people use multiple chat programs at the same time. The Lean Startup book[0] was written by an entrepreneur working on a chat system, who initially thought that to make adoption easy he had to integrate with existing systems. What they learned was that people didn't mind adding it to their list of chat systems, and actually liked the ability to meet new networks of friends.

I've been very intrigued recently by a lot of early internet protocols, like IRC, SMTP, NNTP, etc. which are very clean and simple. So easy to use that you can literally connect to an SMTP server via telnet and send an email by hand with just a few simple text commands. I've seen people mention gopher a few times recently (the core doesn't change very fast, but people like to implement custom clients), and even HTTP is pretty simple. I think there's a lot to be said for simple, text-based protocols, because they're easy to understand and implement something that connects to them. I almost think a good test for how complicated an interface is, is how easy it would be to implement in arc, which has very little library support for most of these things. It turns out to be quite easy to build an IRC bot with arc[1].

It is interesting to me that arc may not be very widely adopted, but it is probably one of the few programming languages that has almost as many implementations as it has community members. If we made it just a little bit easier to pick up and start using (particularly in production), the community would probably grow a little faster.

I think there's a lot of opportunity now and in the near future for reintroducing simple foundations, perhaps slightly extended, but mostly made more accessible for new users. Our technology stack has gotten so tall and complicated in the name of shortcuts and simplicity, that a lot of efficiency can be gained by cutting out a few layers. Once people start targeting certain abstraction boundaries, like WASM + WASI, it should be pretty easy to replace everything under that boundary with a much simpler system. A lot of the disadvantages of "good" systems, like microkernels vs monolithic ones, are now so completely outweighed by the rest of the environment that it should be pretty straightforward to build an OS with much better security much closer to the metal than what we have now with 2+ layers of VM sandboxing.





2 points by akkartik 119 days ago | link

I like which slices through the ambiguous terms 'worse' and 'better' and focuses on the crucial ideological divide: do you think evolution is something to combat or something to go with the grain of? That fits with a lot of your comment as well.

But you should elaborate on your last 2 paragraphs. I'm not sure I buy either that Arc adoption can pick up or that the mainstream tech stack will ever cut out layers.

My synthesis of "Worse is better" for myself (with Mu[1] and SubX[2]):

a) I don't think of evolution as "bad". Building something incompatible is indeed maladaptive. I'm clear-eyed about that.

b) Mu doesn't try to come up with the perfect architecture that doesn't need to evolve. Instead it tries to identify and eliminate every source of friction for future rewrites.

c) My goal isn't to go mainstream. I'd be happy to just have some minor Arc-level adoption. I think it's better to have a small number of people who actually understand the goal (an implementation that's friendly to outsiders) than to have a lot of adoption that causes Mu to forget its roots. My real goal is to build something that outlasts the mainstream stack (the way mammals outlasted the dinosaurs). That doesn't feel as difficult. It's clear the mainstream has a lot of baggage bogging it down. It'll eventually run out of steam. But probably not in my lifetime.

Anyways, I hope in a year or so to give Mu an Arc-like high-level language. It won't improve Arc's adoption, but hopefully it will help promulgate the spirit of this forum: to keep the implementation transparent, and to be friendly to newcomers without burning ourselves out.




Yup, that's right.


3 points by akkartik 176 days ago | link | parent | on: Noob resources for Arc/Anarki?

On a tangent, I'm curious what bits you find are included with Python :) I use it for my dayjob, while it has lots of libraries I can't think of what IDE or commandline tools you're thinking of.


2 points by nupa 132 days ago | link

As of Python 3.7 at least, it comes with pip package manager and IDLE ide already installed. Yeah, you can use other tools, but it comes with the bare minimum all right there in the installer -- everything "just works" in a way I've never gotten with a lisp to date.

Although someone recently suggested I try Portacle, which is common lisp bundled with emacs and quicklisp already set up. That's definitely got my interest.

I still wish it was as "elegant" as arc, but maybe I'll find out it's complicated for good reason. We'll see.


2 points by akkartik 131 days ago | link

Interesting, I didn't realize IDLE comes bundled with Python. Looks like it came out in Python 2.6! That's from 2008.

Bundling a package manager for Anarki would be a little like being all dressed up with nowhere to go. There just aren't any libraries outside of the repo, to my knowledge. The community tends to add code directly to the repo since anyone can easily get commit access. That seems more elegant than a package manager, at least for this stage of Anarki's life.


3 points by nupa 131 days ago | link

I suppose that's fair. I guess I'm just angsty because arc clearly delivers on the promised elegance of lisp better than common lisp does, but arc isn't yet at a point where I can just press play and start using it to automate everything. Someday I hope to get to a point where I can contribute to anarki myself and make it into the power tool I know it ought to be, but I'm still at the stage where build tools scare me and everything seems needlessly complicated.


1 point by akkartik 131 days ago | link

I'm not following "..just press play and start using it to automate everything." Is there a specific task you're trying to use Arc for?

It's definitely true that Arc has lots of deficiencies when it comes to tooling. We're not going to fix them all at once. So if you have suggestions for the most important three (or dozen!) tools you'd like it to provide, I'd love to see them. More specific tool suggestions are superior here to general ones. "Package manager" means wildly different things and has wildly different responsibilities in different contexts and languages and platforms. So I'd particularly like to see suggestions that talk about a specific situation that applies to you. "In ___ context, If I run ___, Arc should ___."


2 points by krapp 131 days ago | link


I disagree. Most package managers for most languages share the same core functions and responsibilities: import and export code (likely from or to a repo), organize code into "packages" or "applications" according to some hierarchy, describe dependencies for packages using metadata and manage those dependencies when importing or updating.

The "special sauce" between them is in the way packages are defined and the metadata, and the way dependencies are handled, and those are details the Arc community could argue about until the heat death of the universe. But ~90% of what new people will want from Arc is to import News as an application or import libraries into their own local version of News.


2 points by akkartik 123 days ago | link

Hmm, we've had this conversation a few times, and I think I may be unfairly holding others back. To reiterate the obvious, you should absolutely feel free to create a package manager in Anarki. The way you put it suggests it may not even be that much work for a rudimentary tool. Why not try it? Let a thousand flowers bloom :)


2 points by krapp 122 days ago | link


From what little I know, it would be an exercise in suffering [0,1] and that's not even getting into arguments over how versioning should work. But I still want to do it... eventually.

I kind of suspect it would be pointless without some changes to the language itself which I don't know how to implement myself yet, and I don't want to just wait for other people to do the work. Basically, I don't think we can have useful packages until we can do something about the possibility of packages being able to globally redefine things and create unintended havoc. Namespaces would be nice too.

I am hoping to get something like plugins working in the forum, though. I've already combined the repo and what was the plugin manager and I've been trying to get hooks to work through it so that it would be possible to 'plug' scripts in or out of those hooks during runtime. It might also be useful as a way to add updates by hotpatching the existing code (which is really the only valid use I can even think of for being able to redefine things in Arc.)

Maybe, if that ever gets anywhere, something like a package manager can emerge from it.




3 points by shader 122 days ago | link

I'm actually somewhat intrigued with the idea of using guix[0] as a language package manager. It has really nice facilities for setting up "environments" that contain a set of packages, so you can use it for bundling together all of the deps needed to build a particular application. As a bonus, it uses scheme as its configuration language :)

It wouldn't solve arc side of actually loading packages, which probably still needs work, but it should work pretty well at managing them.




Is this thread part of a conversation happening somewhere else?