Personally, I see Stripe as being a trustworthy source and I'd much rather use a non-free version from a trustworthy source than a free version from an untrustworthy source. Yeah you can read the code, but no one is going to do that anyways (besides there's more to it than just looking for something nefarious in the code, you also have to make sure there are no missing parts that lead to vulnerabilities and unless you know what the missing parts are....)

If you want to write JavaScript with Lisp syntax, then you may like ESLisp, https://github.com/anko/eslisp

https://docs.racket-lang.org/db/connect.html#%28def._%28%28l...

That's true, but the fact that we're both able to make analogies just suggests that analogies aren't a good defense for your system. It isn't self-evident that "eliminating different syntaxes" is always a good thing. You need to actually take the trouble to motivate it.

In my experience the hard part of dealing with polyglot systems is juggling the different semantics. Syntax is in the noise. Should it be the same or different? It just doesn't seem worth thinking about.

Don't get me wrong, I find Lisp's uniform syntax very helpful. But Lisp is helpful also because of its (relatively) uniform semantics. While adding Lisp syntax atop say Erlang seems useful, mixing LFE and regular Scheme would be a nightmare.

> What happens when 2 languages use the same keyword but with different semantics and it happens that a 3rd language embeds them both?

Yes, I can relate to this question. For example, here's a fragment from the Mu codebase where I embed tests containing Mu programs in my C++ implementation: http://akkartik.github.io/mu/html/040brace.cc.html#366. The Mu instruction is `return-if`, but because it's in a C++ file, just the `return` is highlighted. Super ugly.

My take-away from all this: polyglot systems are a bad idea. Mu's implementation being in C++ is hopefully a temporary state of affairs. We shouldn't be picking "the right tool for the job". Software is more malleable than past tools. We should be tweaking our one language to do everything the job needs.

So rather than try to come up with solutions for polyglot programming, I'd just discourage it altogether.

Agreed, but I think context eliminates such a need. If this comment were about cooking it would look the same. We reuse one writing system.

> Imagine a project with both Flow and Project files. Wouldn't it be nice to be able to tell them apart at a glance?

Ah, good point! So far it hasn't been a problem, but I imagine there may be issues as the number of Tree Languages (note--I took the feedback and dropped the "ETN" acronym) and combinations increase. It might emerge that there are some universal best practices so semantics won't change too markedly from one language to the next. But I think it could be that semantics vary a lot. Right now I have some languages where flow goes forwards (top down) backwards (children up), stack based, parallel, synchronous, et cetera. I personally haven't had trouble keeping them straight just knowing the context, but that is not necessarily a predictor of how it will go for other people (or even me), in the future. We shall see.

Another similar problem is when you have a file with both Flow and Project code (something that actually comes up a lot).

The stable branch uses the Arc tutorial unchanged. All I did was to make it a little easier to read: https://arclanguage.github.io/tut-stable.html

The master branch of Anarki has one major incompatibility with Arc 3.1, and I created a version of the tutorial with it highlighted in bold: https://arclanguage.github.io/tut-anarki.html

Yeah, this makes sense if you're making something that only you use, but if I'm trying to make something a little more portable, like (as you mention) a library.

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>

If the way Arc's lib/ directory has been used is any indication, the way to do it is:

- Start in the Arc directory when you run Arc, and never cd out of it.

- (load "lib/foo.arc"), or (require "lib/foo.arc") if you want to avoid running the same file multiple times

But I think for some Anarki users, the preferred technique has been somewhat different:

- Invoke Anarki from any directory.

- Ignore lib/ as much as possible. On occasion, load a library from there by using (load "path/to/arc/lib/foo.arc"), but a few libraries may make this difficult (e.g. if they need to load other libraries).

When I started writing Arc libraries, the first thing I wrote was a framework for keeping track of the location to load things relative to, so that my other libraries could load each other using relative paths regardless of which of the above techniques was in use. But the Lathe module system didn't catch on with anyone else. XD

The "latest" arc is Arc 3.1, but that came out in 2009. You can download it here: http://arclanguage.org/item?id=10254, and start it up with `racket -f as.scm`. (Note that you no longer need the specific version of MZScheme you used to; you can use racket.) No, this information has not been updated on the official Arc install page. Yes, this is frustrating.

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

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 think it would be great to live in a world where not only could you use your finger to create a sprite animation, but if curious, you could also more easily delve into all the black boxes that make that experience happen (down to the physical level).