Arc Forumnew | comments | leaders | submitlogin
2 points by akkartik 9 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 https://github.com/akkartik/mu#readme with details.
1 point by akkartik 15 days ago | link | parent | on: MakerLisp Embedded Lisp Machine

My MakerLisp machine is up and running!

https://mastodon.social/@akkartik/102555471982690487


>The big drawback: you have to give up '-' in symbol names.

I wouldn't have a problem with that, but I'm probably of a minority opinion, since that seems to be a Lisp thing. When I started with Arc it took me a while to realize that symbols with asterisks in the name weren't something special like pointers, and using angle brackets just seems wrong after years of writing HTML.

Although if it were possible to do something along these lines, one could have the best of both worlds:

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


    ))

https://groups.google.com/forum/#!msg/racket-users/HiC7z3A5O...

Have you seen my proposal for infix syntax for Arc? I think it's pretty nice: http://arclanguage.org/item?id=16775. The big drawback: you have to give up '-' in symbol names.

We already have syntax in the form of bracketed functions (or whatever they're supposed to be called) and {} for tables.

I'm speaking out of my depth here, but I think it would be nice if scoped syntax extension were a "first class" feature of Arc. It would be nice to be able to load, say, native support for XML syntax as a library or something, or to easily extend the language through grammar definitions.

Also, infix notation in a Lisp? If I had a monocle I would drop it into my coffee with shock forthwith!


In the "State of Racket" presentation, Matthew Flatt talked about how it was a ripe time to start seriously pursuing "Racket 2" and thinking about radical changes that could be made to the language. Then he surprised many people by showing a slide with some infix syntax ideas.

We've had many discussions about s-expressions with syntax here at Arc Forum, and it looks like the Racket community is going to dive into that topic now. It could be the best time ever for us to get involved with the platform we've relied on.

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

My critique: https://news.ycombinator.com/item?id=8503353#8507385

The final straw for me was when I tried to actually _use_ sweet expressions for something. I described it here: http://arclanguage.org/item?id=16699 (Warning: lots of bad ideas in this thread)

2 points by jsgrahamus 53 days ago | link | parent | on: Arc and Scheme in Emacs Lisp

Very nice. Thanks, Shawn!
1 point by akkartik 57 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: https://www.tindie.com/products/lutherjohnson/makerlisp-ez80... .)

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).


Very cool! The codebase (http://t3x.org/klong/index.html#download) or the book (http://t3x.org/klong/book.html)?

I’ve spent uncounted hours enjoying and pulling out my few remaining hairs with Holm’s Klong. Look forward to reading this.

Thanks for the heads up, akkartik!

2 points by i4cu 97 days ago | link | parent | on: Beunto an experimental app builder

Hmm, haven't seen that one. I've done a search on my entire code base tree and 'randid' is nowhere in my code (of course that may not matter when it's a compiled jar file that's running).

Can you tell me your OS? I've only been using OSX so it's possible it's chrome on Windows? Versions would be great too, if you can :)

And is that a js error or a server error? I'm hazarding a guess it's a js error given I'm not seeing any errors on the server.

Thanks!

2 points by mpr 97 days ago | link | parent | on: Beunto an experimental app builder

Hey -- I tried to go to the link but nothing loaded. This shows up in the Chrome console:

"Uncaught Error: No matching clause: :randid"

2 points by i4cu 98 days ago | link | parent | on: Beunto an experimental app builder

Hey thought I'd post this over here (even though it's not really arc related!).

note this is in the very experimental stages. I wouldn't try it on mobile or IE yet.

Posted it on HN too,

https://news.ycombinator.com/item?id=19902880

but I think maybe it's a little too Alpha for a general audience.

3 points by kinnard 99 days ago | link | parent | on: Lisp in Forth: a small lisp in Forth

What do you build in forth?

Thanks for this. 2 of my favorite languages.
3 points by shader 101 days ago | link | parent | on: EdgeDB

Two points that make this relevant:

1. The EdgeQL language seems like a significant improvement over SQL, and is interesting from a language design perspective

2. The EdgeDB itself also seems like it should be pretty easy to use from an arc application, since they provide http and graphql query interfaces out of the box.


The 'Datafy' and 'Nav' protocol interfaces look really interesting.

From what I gather using those along with Clojure 'Spec' allow you to create ad hoc, generalized interfaces as an abstraction layer accessing an infinitely large lazy tree of 'things' (provided these 'things' are data or can hold meta data).

Unfortunately I have yet to see anyone really use it in the way I imagine it can be. I'd like to see a web 'req' var with the ability to drill down through the server-code<->js-code barrier (via the session and connection protocol) all the way down into the dom and the js application state. That would be really, really cool.

Also, I've been building a general purpose app builder (for web apps). This app building process is currently working, but in the future I'll need build a more advanced inspector and a designer. Since my stack is Clojure from server to js I'm wondering if it makes sense to build the inspector on top of that trio of technologies then attach the designer to it.

Someday I'll get to do that! ... I just know it. :)

Edit: for those who wonder what this has to do with REBL... these are the core technologies that REBL is built upon.

https://clojure.github.io/clojure//clojure.datafy-api.html

2 points by akkartik 113 days ago | link | parent | on: Ask Arc: Arc forum RSS

I like http://yosefk.com/blog/what-worse-is-better-vs-the-right-thi... 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.

[1] https://github.com/akkartik/mu/blob/master/Readme.md

[2] https://github.com/akkartik/mu/blob/master/subx/Readme.md

4 points by shader 114 days ago | link | parent | on: Ask Arc: Arc forum RSS

Sounds good.

I guess these improvements will only affect people using the Anarki implementation of the forum? It would be nice if we could get some upgrades to the original arclanguage.org instance.

Specifically turning off the feature that disables replies on old threads, and probably switching to a most-recently-updated ordering scheme.

2 points by shader 114 days ago | link | parent | on: Ask Arc: Arc forum RSS

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.

_____

[0] http://theleanstartup.com/

[1] https://github.com/arclanguage/anarki/blob/master/lib/irc.ar...

3 points by shader 114 days ago | link | parent | on: New scoping idea

I saw that reddit thread recently, and was initially against the idea, but I could see why it might have some value. It may be more efficient, and can be more concise too.

Most of the time though I think that the additional nesting layer of a a let form helps make the code clearer, and probably simpler to parse too—it's obvious where the boundaries of the scope are. Also, I'm not sure there's a good reason to suddenly introduce new variables partway through an environment.

I could see restricting '= to only assign to declared variable names, if that would help with the typo vs global problem. Maybe introduce a separate 'declare or 'global form that can be used to explicitly introduce global variables, instead of accidentally making them. On the other hand, arc is the language of user power—adding complexity to prevent people from shooting themselves in the foot seems like a step in the wrong direction.

Pros and cons...

3 points by akkartik 116 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.)

[1] https://www.jwz.org/doc/worse-is-better.html

3 points by krapp 116 days ago | link | parent | on: Ask Arc: Arc forum RSS

>What exactly is it you're working on?

ATM, simplifying the HTML and CSS, removing obsolete tags (like font) where possible. Also eventually themes and having the base font size be selectable, since not everyone is comfortable reading 10pt grey on grey text.

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

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.

____

[0] https://www.gnu.org/software/guix/

2 points by shader 116 days ago | link | parent | on: Ask Arc: Arc forum RSS

Yeah, it does look pretty simple.

Actually, poking through the markup of the forum in general, I'm still impressed by how simple the site really is. 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.

3 points by shader 116 days ago | link | parent | on: Ask Arc: Arc forum RSS

I think a subscribe link for each thread would probably be overkill. Most threads don't last very long, especially since there's a time-limit on responses.

What exactly is it you're working on?

2 points by shader 116 days ago | link | parent | on: Ask Arc: Arc forum RSS

That looks good enough for now, thanks!

At some point it would be nice to have a feed of full-text items as they get posted (including comments), but I can work on that separately.

More