FB engineer checking in, I read lobsters. But I’m on infra, not mbasic.

some people won’t like the method_missing (define_method would need to stay in sync with the keys)

I did a quick benchmark: https://gist.github.com/localhostdotdev/bd97537dcbc4099bc05dd56bccd98cff

1 000 000 lookups is 0.12s with Hash, and between 0.4s and 1.4s with SimpleHash.

so something to consider if it becomes a bottleneck.

edit: thanks a lot, it made me think and I would rather have some future-proof data structures, e.g. I would move this to inherint from Hash, freeze it to be read-only and use define_method instead of method_missing

Yeah, I definitely plan notational improvements, as I say in a couple of places. For now the priority is to keep it easy to bootstrap :) I wrote about the rationale for the current “bottom-level” notation here.

Oh, perhaps I should describe how I’ve been putting up with the mnemonics. I have a couple of helpers in my editor (Vim).

:P opens up the opcodes file from the repo in a split window. (This file just contains the output of subx help opcodes.)

:G <pattern> opens up a split window with the results of:

grep -h <pattern> *.subx */*.subx

For example, :G add.*EAX.*imm32 for instructions adding a literal int to EAX.

I now often find the perfect line to copy over from somewhere else in the repo.

More details.

Porting is annoying, and ape (the ansi/posix emulation environment) is a separate world that’s no fun to use. It also comes with interoperability caveats and issues when using the native plan9 libraries. Additionally, the things that libgit2 helps with are the things I want to do in shell script. And finally:

  term% cd git9
  term% wc -l `{du -a . | awk '/.*\.[chy]$/{print $2}'}
     108 ./conf.c
     378 ./fetch.c
     839 ./fs.c
     174 ./git.h
      62 ./objset.c
     828 ./pack.c
     264 ./save.c
     489 ./send.c
     228 ./util.c
    3370 total

Compared to:

  term% cd libgit2
  term% wc -l `{du -a . | awk '/.*\.[chy]$/{print $2}' }
      <elided list of ~900 files>
      270404 total

Even ignoring tests, examples, and external deps:

  term% wc -l `{du -a . | \
           awk '/.*\.[chy]$/{print $2}' | \
           grep -v 'tests|deps|examples' }
      <elided list of files>
      138077 total

In other words, depending on how you count, there’s between 1.2% and 2.4% the amount of C code to maintain, update, and understand in this implementation. And sure, this implementation will grow, but it’s likely to stay within the single digit percentages of libgit2’s size.

You make a fair point. To temporarily tide you over, here is a brief description from Wikipedia: https://en.wikipedia.org/wiki/100_prisoners_problem

Thanks, Max! I hope that you’re well. What are you working on these days?

I have been using Lua as well, for about 12 years now. My main reasons are:

• The simplicity of the (reference) implementation. Lua is about 16000 lines of C, any experienced programmer can read them and understand how the whole interpreter works. The same cannot be said of most other mainstream languages.

• The wonderful language of the design. Nothing in Lua feels like a kludge to me. That is probably because it is designed and implemented by a very restricted core team, and not by committee.

• The syntax is not S-expressions. As much as I want to like Lisp, I cannot bring myself to find that syntax pleasant to use in practice.

• The ease of embedding it in C and sandboxing it. Some people do not like the Lua - C stack-based API, but to me it is one of the main selling points of the language. I have written bindings for other dynamic languages such as Python and Ruby, and compared to that experience doing the same for Lua is wonderful.

And over the years, I have found an extra reason, which is the community. The Lua community is small but great, maybe in part because it is one of the few mainstream languages that does not originate from the Western block (Europe / USA). Because of that, its community is a mix from people from all over the world, from very different industries, who use the language in very different ways. Going to a Lua-related conference such as Lua Workshop is always a great time.

The first two links in “can be made” are the same. Was that intentional?

I too use Lua, but at work, it’s more for LPEG (Lua Parser Expression Grammar). It takes a while to get used to it, but I find it much more expressive and powerful than the Lua patterns (or even regex). Not only can an expression be reused as part of another expression, but the resulting code is its own VM (distinct from Lua) that is geared directly for parsing.

Thanks for the mention at the end :) I haven’t touched that README in awhile, and reading over it reminded me to get cracking on that work!

Anathem is really wonderful, I would suggest it too.

Or php, or vim for that matter…