Arc Forumnew | comments | leaders | submit | akkartik's commentslogin
3 points by akkartik 14 hours ago | link | parent | on: Ask ARC: Can I start with Arc?

I think "learning Lisp" is Arc's best niche. So yes, try using it and come ask us questions. Feel free to also ping me over email, that is sometimes faster. My address is in my profile.

One caveat: it can be easier to learn from a book if you follow the language it was written for. Land of Lisp is a fine book by all accounts, so if you use it you may be better off just using Common Lisp or whatever. But feel free to come ask questions anyway. Maybe we can show you both Common Lisp and Arc versions of programs.

reply


Whoa, I could have sworn I responded to this one :/

rocketnia is right that I tend to just run Arc from within its directory, keeping it alongside any Arc program I may be working on at the moment. As a result, I'd kinda always assumed you could run it from anywhere and find yourself in the Arc directory once you loaded up. Now I find this isn't the case:

  $ pwd
  /home/akkartik
  $ ./anarki/arc.sh
  arc> ($:current-directory)
  #<path:/home/akkartik>
This was initially surprising, but of course we're only parameterizing the current directory while loading libraries: https://github.com/arclanguage/anarki/blob/c3849efaf9/boot.s...

I'm not sure what to do about this. In addition to rocketnia's `current-load-file*` suggestion, should we just expose `arc-path` from boot.scm? I couldn't immediately see how to get to it from Arc.

reply


Found on the recent HN discussion about Gerbil Scheme: https://news.ycombinator.com/item?id=15394603

One interesting point here is how he prioritizes choice of language based on relationships. This connects up with my comment on avoiding dependencies at http://arclanguage.org/item?id=20221. The conventional wisdom that the community of a language matters more than its technical attributes is a diluted version of this idea.

reply

3 points by jsgrahamus 11 days ago | link

Thanks, akkartik. Also read the discussion on Gerbil.

reply


Mine would be COPYMORE. Or NODEPS.

I think I share your vision: http://arclanguage.org/item?id=17277

reply

2 points by shader 14 days ago | link

Do you have any references for those terms? Or a short explanation for them?

reply

1 point by akkartik 14 days ago | link

COPYMORE

I'm what I like to call a 'copyista': I think DRY is overrated, and abstraction is overrated, and people are too quick to create abstractions to compress code rather than for conceptual clarity. Some links: http://www.sandimetz.com/blog/2016/1/20/the-wrong-abstractio...; http://programmingisterrible.com/post/139222674273/write-cod...; http://bravenewgeek.com/abstraction-considered-harmful; http://akkartik.name/post/modularity; http://dimitri-on-software-development.blogspot.de/2009/12/d...; http://thereignn.ghost.io/on-dry-and-the-cost-of-wrongful-ab...; http://akkartik.name/post/habitability. You don't have to read them all, but hopefully this gives you as much flavor as you want :)

NODEPS

This is short for "no dependencies". I think a lot of software's ills stem from people's short-sighted tendency to promiscuously add dependencies. In fact, our fundamental metaphor of libraries is wrong. Adding a library to your program isn't like plugging a new block into your Lego set. It's like hiring a new plumber. You're not just adding a few lines of code to a file somewhere, you're creating a relationship. Everytime I see someone talk about "code smells", I wait to see if they'll bring up having too many dependencies. Usually they don't, and I tune them out. And the solution is easy. When you find a library that does something useful, consider copying it into your project. That insulates you from breaking changes upstream, and frees up upstream to try incompatible changes. As a further salubrious effect, it encourages you to hack on the library and tune it to your purposes. (Without giving up the options of merging further changes from them, or submitting patches upstream.)

As it happens, this worldview of mine was actually catalyzed by conversations here in the Arc Forum, most proximally http://www.arclanguage.org/item?id=13263. That thread led to me writing http://akkartik.name/post/libraries and (a little clearer) http://akkartik.name/post/libraries2.

I consider an example of exemplary library use to be how I copied the termbox library into Mu (https://github.com/akkartik/mu/commit/5f1285238b), periodically merged commits from upstream (https://github.com/akkartik/mu/commit/9ba313ab7f), gradually cleaned it up to fit better with my project (https://github.com/akkartik/mu/commit/9a31c34f0f), and gradually stripped out code from it that Mu does not require (https://github.com/akkartik/mu/commit/c04baba4f2; https://github.com/akkartik/mu/commit/8e7827dfcf; https://github.com/akkartik/mu/commit/547ec78bf2). In the process I made some wrong turns, deleting features that I later decided I wanted (https://github.com/akkartik/mu/commit/10a3b8cca2) and created bugs for myself (https://github.com/akkartik/mu/commit/3315a7d3bb; https://github.com/akkartik/mu/commit/0c0d1ea5cd). But when it did things I didn't want, I was now empowered to change them (https://github.com/akkartik/mu/commit/ee1a18f050). One of my patches was useful upstream, so I submitted it: https://github.com/nsf/termbox/commit/0730826a07. I would be in no position to submit that patch if I hadn't taken the trouble to understand termbox's internals. That's another benefit of copying and privately forking libraries: it makes you a better citizen of the open source world, because open source depends on eyeballs, and using a library blindly helps nobody except your (extremely short-term) self.

More broadly, Mu is suffused with this ethos. My goal is that if you have a supported platform you should be able to run it with three commands:

  $ git clone https://github.com/akkartik/mu
  $ cd mu
  $ ./mu
(That highlights another benefit: your software becomes easier for others to try out. Without giving out binaries, because what's the point of being open-source if you do that?)

Mu's also geared to spread this idea. I want to build an entire software stack in which any part is comprehensible to any programmer with an afternoon to spare (http://akkartik.name/about). Which requires having as little code as possible, because every new dependency is a source of complexity if you're building for readers rather than users. In chasing this goal I'm very inspired by OpenBSD for this purpose. It's the only OS I know that allows me to recompile the entire kernel and userland in 2 commands (https://github.com/akkartik/mu/wiki/Building-OpenBSD-on-Open...). People should be doing this more often! I think I'm going to give up Mu and build my next project atop OpenBSD. But that's been slow going.

---

Ah, here's an old HN thread where I managed to combine both these ideas: https://news.ycombinator.com/item?id=11158357#11189308

I'd have preferred to more directly call out my hatred for compatibility constraints, but I couldn't figure out how to fit it on a license plate :)

reply

2 points by breck 2 days ago | link

The Pike maxim "A little copying is better than a little dependency" comes to mind. I think the overhead of dependencies is underrated ("it's just a 1 line import statement!"), and often a little repetition is a good thing.

reply


I was just thinking about it yesterday, after reading https://www.theatlantic.com/technology/archive/2017/09/savin.... Very inspiring talk.

reply

2 points by shader 14 days ago | link

That's precisely where I found out about it :D

reply


This was my first thought as well. But why does `readc` (Racket's `read-char`) silently accept invalid utf-8?

reply

4 points by rocketnia 1 day ago | link

It's reading the invalid sequence as � U+FFFD REPLACEMENT CHARACTER, which translates back to UTF-8 as EF BF BD (as we can see in the actual results above). The replacement character is what Unicode offers for use as a placeholder for corrupt sequences in encoded Unicode text, just like the way it's being used here.

reply


The files seem to diverge after a 0 byte. Can you check if it's the first 0 byte in the file?

Edit: never mind, I was hallucinating.

reply

2 points by zck 31 days ago | link

I just checked; it's not the first 0 byte.

Just to provide a little extra information, the image I'm testing with is my favicon: http://zck.me/favicon.ico

reply

2 points by akkartik 66 days ago | link | parent | on: 3-Dimensional Source Code

"There's a mirage when you first look at it, like with a lake. What you see is just the surface of the lake, and that's a two dimensional view. But when you put your hand in, you find that there's depth to it. It's not just one dimension or two, but a three dimensional design." -- Carl Sassenrath on Rebol, 1996 (https://web.archive.org/web/20000830133509fw_/http://www.lin...)

-----

2 points by breck 15 days ago | link

Thanks for this link. I hadn't studied Rebol too closely before.

I do like Rebol's embrace of dialecting and I think there's opportunity in making composing languages better.

reply

3 points by akkartik 70 days ago | link | parent | on: 3-Dimensional Source Code

Wait, you're writing about "3-dimensional source code" and the dimensions aren't settled yet? That just makes me glad I didn't read your slides, and even less likely to put in the effort next time. I'll repeat my earlier comment: your MVPs are too M and insufficiently V.

How are you so sure that you won't settle on 2 or 4 dimensions? (Let us stipulate that 5 is right out.)

> empirically 99%+ of bugs occur in extraneous parts of the code

You'll need to show me these empirical studies.

I haven't actually ever heard a story that accounts for 99% of bugs. Pretty much every software engineering study ends up with a much flatter profile than that. You have to do many things right to eradicate 99% of bugs.

> ETNs start bringing us closer to the absolute minimum, perfect program necessary to solve a problem.

From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right? If so, is your claim that "99% of bugs" are hiding in the punctuation?

Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs? What about DRY? The value of good interfaces? Parnas's theory of information hiding? SOLID?

I'll trade my pulled-out-of-my-ass theory for yours. I think bugs arise because our representation of algorithms ("code") over-emphasizes the rules the algorithms performs, and under-emphasizes the input space that the rules are meant to operate on. Bugs arise when people modifying the code forget about rare areas of the input space, and the scaffolding around the project is unable to remind them. Nail down the input space, and bugs go down because your tests fail more often. You won't fix this problem no matter how much you tweak the superficial syntax with which you write code. (I work on this, so it was not pulled out of my ass just now: http://akkartik.name/about; https://github.com/akkartik/mu)

-----

3 points by shader 34 days ago | link

> ... trading of programming theories ...

Clear and simple syntax / representation is important; combined with matching editing tools it enables us to communicate ideas easily and fluently.

I also like the idea of well defined input spaces. Many theorems or algorithms only work under certain conditions, and much damage has been done by applying them outside of their intended domains. But I think that's only part of the problem.

My own theory is that programs are specifications, and the more clearly and precisely they specify the better. Programs can fit into a matrix of good/bad ideas and good/bad specifications. Of these, two kinds are interesting bugs:

  1) Incorrectly specified good ideas
  2) Correctly specified bad ideas
Well specified good ideas are correct programs, and incorrectly specified bad ideas are just hopelessly confused.

Improving the languages and tools will never fix bad ideas, but they can make them more obvious. Now the goal is to make programming as close as possible to 'saying what you mean'. In other words, making the semantics as explicit as possible.

Basically my goal is 'declarative programming', which turns out to be a very vague concept to most people. They all agree that it's better, but nobody seems to have a good explanation for why. I think the difference is that declarative programs specify the only the relationships which are important, leaving the rest up to the platform to optimize or interpret as it sees fit. This leads to powerful and concise languages such as SQL, but at the cost of placing the burden on the platform rather than the programmer. Good for communication and clarity, bad for development and adoption.

Basically, declarative languages can be more concise because they rely more on shared knowledge; predefined vocabulary. If the language doesn't already have a way to express the concept you want, however, it is much more work to add. Imperative / procedural programs are more flexible because they rely on implicit semantics. You just tell the computer what to do—you don't have to explain what it is doing or why. Everything the program "accomplishes" is imaginary and external to the specification. This leaves very little room for the computer to optimize your selection of operations, and leaves a lot of room for you to accidentally provide an incorrect sequence of steps.

It's like the difference between giving directions by saying "Go to the grocery store at 5th and Main" vs. "Take a left, go three blocks, take a right, go two more blocks, park on the right side of the street and enter the blue building." The first is much clearer, but places much higher expectations on the navigation abilities of the recipient, while the second can be followed by anyone even though they have no idea where they're going - and mistakes are correspondingly harder to notice.

Sadly, the nature of declarative languages makes them fairly domain specific, which may explain part of why they're so rare and hard to make. Creating a declarative language for solving a class of problems is much harder than solving a single problem imperatively; you actually have to think of how and why you're solving those problems. But I think we could probably create some general patterns and guidelines for defining them, and maybe even start building up some tools to reduce the effort required.

reply

1 point by breck 70 days ago | link

> Wait, you're writing about "3-dimensional source code" and the dimensions aren't settled yet? That just makes me glad I didn't read your slides, and even less likely to put in the effort next time. I'll repeat my earlier comment: your MVPs are too M and insufficiently V. > How are you so sure that you won't settle on 2 or 4 dimensions? (Let us stipulate that 5 is right out.)

Sorry, the language itself is fully settled, the only question is with our hardware prototypes, we've found a way to compute with the ETN programs mapped to 2-dimensions, and a machine structure where we can compute answers with a source program mapped to 3-dimensions. But really both are 3-dimensional, the former it's just the Z-axis doesn't vary.

In the 3-D version, the first word of a node (aka the head/base/instruction/type/command), is at z 1, and subsequent words go up the z-stack. In the 2-d version, subsequent words just go up the x-dimension. They actually both offer advantages, and we'll figure out which is better I'm sure in the next year or so.

Again, this stuff is at the cutting edge of the hardware research. We're talking about a whole new type of machine architecture without registers.

> You'll need to show me these empirical studies.

Totally agree. We will.

> I haven't actually ever heard a story that accounts for 99% of bugs. Pretty much every software engineering study ends up with a much flatter profile than that. You have to do many things right to eradicate 99% of bugs.

Agreed. And to hit that 99%, we're going to need the new hardware, so that is quite far off (3 - 20 years, hard to predict). But we can hit 90% fewer with ETN software alone.

> From what I can tell, ETNs are mostly about eliminating punctuation and replacing it with indentation. Is that right?

No. Forget about the punctuation of newlines and spaces. Think about it as Cartesian coordinates. ETNs are about giving source code physical dimensions. About making sure that source code could directly be built out of circuitry. Think of ETN programs like something you could build in a Voxel editor like MagicaVoxel. Each block holds a word, which is just a number from 0 to infinity, and problems are trees of these numbers connected in physical space. Sorry if that's not clear. I think the more code and tools we build the easier it will be to understand.

> Is upgrading the syntax to ETNs all that's needed to eliminate 99% of bugs?

No. To reduce bugs by 90% (99% won't be possible until we have ETN machines) you also need well designed ETNs. Which have good FPL things like no side effects, prefix notation, DRY, good naming, good interfaces, et cetera. Great question. Working on a release shortly with a lot more tools and help on building great ETNs.

> Nail down the input space, and bugs go down because your tests fail more often.

I like that! I'm a big fan of strongly typed languages and the idea they basically prove your program correct at compile time if you think more about your types.

Thanks for the feedback! I hope the next wave of ETN stuff will help start to demonstrate the benefits better.

-----

4 points by shader 34 days ago | link

While the concept of a cartesian program space is interesting, it seems largely unrelated to TNs. This is probably a good thing though, as programs require semantic relationships ("lines" between nodes) that are lacking in cartesian spaces. If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable. Otherwise the "dimensions" are just an irrelevant and cumbersome alternative to line numbers.

Additionally, a third dimension is meaningless as long as your fundamental representation is two-dimensional. Unless you use an editor that is natively 3-dimensional, mapping a two-dimensional representation onto three-dimensions will leave a lot of redundancy or sparseness, as demonstrated by your conflation of x and z.

reply

1 point by breck 33 days ago | link

> If there was semantic significance to adjacency or distance between points, or along each axis, that might be reasonable

Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).

We are approaching everything simultaneously from the highest abstract level and lowest logical level. We have some more stuff coming out soon that shows off the benefits of the dimensionality more. One of the cooler experiments is a new type of processor with a graph-paper-esque 2D grid that can load a high level tree program and then execute it directly (no cumbersome series of transformations to a bunch of 64 bit registers). AFAIK this is original, though I wouldn't be surprised if Lisp Machines, Thinking Machines, Alteryx, Nvidia, Intel, et cetera have dabbled in this space a bit (though to date haven't been able to find anything on machines that execute trees directly).

reply

2 points by shader 30 days ago | link

> Yes, there is semantic significance to adjacency & distance from the y-axis (which indicates an edge that connects parent and child nodes).

Actually, it seems like your tree relationships have a very confusing relationship to the coordinates. Adding a newline increments Y, and a space increments X, but children are those nodes such that that

  1) child.Y > parent.Y
  2) child.X == parent.X + 1
With additional complications that only the node with the lowest X value for a given Y becomes the child; all others on the same line become part of the content of that node.

This means that the relationships between two elements depends not just on their coordinates, but also the coordinates of nearby nodes. (6, 4) may or may not be a direct child of (5, 3); it depends on if (5, 3) is a full node, or just a content element that's actually part of (5, 2) or (5, 1).

So the coordinates do not actually define the relationships between nodes; they do not clearly relate to the tree structure at all.

reply

2 points by breck 30 days ago | link

You are right, this is great feedback thanks.

> have a very confusing relationship to the coordinates

Agreed. I sometimes get confused too.

One rule that always holds is this:

  1) One line === One node
So every node has an absolute Y coordinate (just the line number), but also a relative coordinate(s), relative to its ancestor(s).

Both are useful at various times. There's probably a better way to eliminate confusion here.

> So the coordinates do not actually define the relationships between nodes

Given an array of node coordinates {y,x} [{1,1}, {2,2}, {3,1}, {4,2}], one has enough information to define the whole tree structure of the program. But you are right, you need the full set of coordinates of a certain node's ancestors to properly know its coordinates, and having a line that begins with 1 or more spaces, it is impossible to deduce how many nodes deep it is without also having access to the previous line(s).

reply

3 points by shader 34 days ago | link

I think the TN/ETN parsing model is somewhat neat in its simplicity, which means it will probably have some longevity.

However, most of the work you have done is just a simplification of the syntax; it has no relation to the semantics whatsoever, and as such is unlikely to cause a major paradigm shift.

Perhaps the coolest part of your notation is the concept of constant validity, which in this case you achieved by simplifying the notation until it matched the medium. Every atomic operation on the text (add a character, new line, or space) is also a valid atomic operation on the tree. Especially because it works with any text editor, instead of fancy semantically (or at least syntactically) aware editors. However, I think any true advances in programming will require improvements in the semantics.

reply

1 point by breck 33 days ago | link

Thanks for the feedback!

> However, most of the work you have done is just a simplification of the syntax; it has no relation to the semantics whatsoever,

Agreed. However, I think one thing that is starting to emerge from our data (17 useful ETNs now compiling to Javascript, Rust, TypeScript, Logo, Haskell, C++, LLVM IR, SQL, HTML, CSS, JSON, and Regular Expressions) is how well this Tree Notation syntax can work for every programming paradigm (functional, imperative, declarative, dataflow, oo, logic, stack ...). Perhaps it is best explained as a universal syntax. The neat thing about this is that once you learn the TN syntax, you now know the complete syntax for languages with very different semantics. So while I agree we aren't changing semantics here yet, instead just leveraging the semantics and VMs of existing languages, this universal syntax could be big in that it can lead to better cross language static tools and enable developers who generally stick to one or two paradigms to make use of more.

> Perhaps the coolest part of your notation is the concept of constant validity

Agreed! The elimination of parse errors is one of my favorite features. Of course, the user can still make errors at the ETN level like mistyping a word or providing invalid parameters to a node. To help catch and fix these kinds of errors, I just launched version 5.0 of Ohayo (Ohayo still shitty, but the core is getting really solid) which includes a revamped compiler-compiler that supports 100% type checking of every word in your program. It makes it easy to create, as you say above "well defined input spaces".

reply

2 points by shader 30 days ago | link

> this universal syntax could be big in that it can lead to better cross language static tools and enable developers who generally stick to one or two paradigms to make use of more.

An alternate syntax will not allow you to use any additional paradigms unless you also provide alternate semantics. It might enable more powerful editing tools or effective macros and metaprogramming though.

reply

2 points by breck 30 days ago | link

> An alternate syntax will not allow you to use any additional paradigms unless you also provide alternate semantics.

Right. The syntax for ETNs is the same, but the semantics are different. For example, I have a language called "Flow" that is a data flow language, passing a matrix through a series of nodes. I also have a logic language called "Project", that can solve relational issues among nodes. Different semantics, identical syntax.

Right now to use different paradigms, a user generally has to learn different semantics and different syntaxes. This eliminates the latter.

reply

1 point by akkartik 30 days ago | link

Is that a good thing, though? A classic design principle is that similar things should look similar and different things should look different. Imagine a project with both Flow and Project files. Wouldn't it be nice to be able to tell them apart at a glance?

reply

4 points by akkartik 75 days ago | link | parent | on: Seeking new host for Try Arc

Is the REPL itself down at the moment?

-----

3 points by evanrmurphy 75 days ago | link

Ah yes it was! It's up again now.

Strange, I had just restarted it early in the day. (And that's what I had to do just now.) It used to stay on for weeks or months on average before konking out. Perhaps it was a fluke today but we'll see if there's something that's repeatedly interfering with it being allowed to run.

-----

More