masak

I'm curious how this sentiment of pg's rhymes with his two languages, Arc and Bel. As a person who has written a Bel implementation, I find one of the traits the language has is that it's trying to be "straightforward" in the same way spoken language is.

Fun side note on this:

Bel's macros are definitely macros and not Kernel-style operatives. Here is a comparison, for clarity:

(A) Bel's macros do a syntax->syntax transformation, but this expansion happens (according to the spec) in the evaluator, after concluding that the operator is a macro and not a function. (B) In the greater Lisp-and-Scheme tradition, macros do a syntax->syntax transformation, but at compile time. (Usually after "read" but before "eval".) In this sense, they are small compilers themselves. (This puts limitations on macros: they have to be "statically visible" in the code. You can't late-compute a macro at runtime in this system.) (C) Kernel's operatives do a syntax->"side effect" transformation, at that same late stage as Bel's macros. Kernel operatives are essentially functions, except that the evaluation of the operands (syntax) into arguments (values) has been suppressed. In this sense, operatives are small interpreters.

If an (A) macro is well-behaved, you can often "optimize" it either to a (B) form or a (C) form. In my Bel implementation, it took me ages to notice that I could do the latter. I documented it here: https://github.com/masak/alma/issues/302#issuecomment-992556...

Hooray! Another Bel implementation!

As someone who is on their third year of Bel implementation -- getting there -- I recognize many of the insights in this post about continuations and about the well-chosen Bel built-ins. Great work, and thanks for writing this post.

As a westerner living in mainland China, I might be able to weigh in on this. China's data does indeed look hard to believe from basically anywhere outside of China (and New Zealand). I don't expect to sway anyone who doesn't want to be swayed.

But I can say this: (a) there really is a pervasive nationwide effort to track and trace, which affects everybody and everything, and (b) the minor outbreaks that do happen get shard pretty faithfully on social media -- even if there is also censorship, it seems it's not as fast as the grassroots spread of news.

Neither the type system of C++ nor the type system of TS is sound, in the sense of "the type system rejects all incorrect programs".

If what you meant by "strong" is just "you can declare types on variables", then both TS and C++ qualify as strong, but JS doesn't.

Your use of the word is based on feeling, not fact. Which was my point.

This reply is a good example of how "strongly typed" ends up meaning practically nothing -- except possibly "the kind of type system I prefer".

I once attended a talk where the speaker had identified half a dozen axes that papers or projects were calling "strong"/"weak" with relation to type systems. Some were not even consistent with themselves, switching definitions halfway.

Type systems are tools, whose formal properties can be described and analyzed in precise detail. Unfortunately, that kind of precision is hard, so semantically empty words like "strong" get used a lot instead. This message is intended to raise awareness about that fact.

The two behaviors don't seem very related.

In `if a == b == c`, the value of `b` is evaluated only once, even if `b` is in fact a bigger/side-effecting expression, and `c` might not be evaluated at all.

In `a = b = c`, the `c` is evaluated first, and then `a` and `b` are assigned to, left-to-right.

If I may be so bold as to recommend my in-progress Bel implementation: https://github.com/masak/bel

Caveat: I'm still working towards being able to recommend Bel _unconditionally_, not just for small programs. Right now you'll experience unreasonable slowness, terse/uninformative error messages, and missing documentation -- probably in that order. All of those are being addressed. But already today, it's fun to play with.

He's poking fun at himself with the whole "programming has never been my forté" -- the fact that he kept count of all the bugs in TEX and METAFONT is the amazing thing.

At the risk of stating the obvious, iTeX is not a real successor of TeX, it's a deliberately-vaporware joke.

I know the Swedish like to repeat that there is no second wave like in the other European countries, but... I've been looking at this graph for the past few weeks: https://ourworldindata.org/coronavirus/country/sweden?countr...

Now, it might be that the new cases this time are less severe, I don't know. But it's a second wave.

So, I've been thinking about this comment a lot over the weekend.

It is interesting to consider a "cool kids" demographic, of developers who stray far enough outside of the mainstream to find small but worthy languages. These would include Scala, Haskell, Kotlin, Clojure, Racket, and Rust. (Plus anyone's favorite non-mainstream language, which I in my haste totally forgot!)

Earlier this year I found that, at a rough approximation, language mind-share in 2020 consists of 25% Java, 25% JavaScript, 25% Python, and 25% everything else. (My source for that is https://www.youtube.com/watch?v=Og847HVwRSI -- and I'm sure there are any number of possible objections against those numbers... but I think my point holds even if they're several percentage points off.) We live in the strongest language oligoculture since FORTRAN and COBOL in the 1960s. These top three languages, and their communities, act as strong attractors. People flock around these languages because they're popular and established.

Despite that, I'm hopeful. I think there's room for experimentation and playfulness. I think evolution in programming languages is still happening, and that solid/interesting ideas are coming mostly from that fringe, not from the established languages.

Both Arc and Bel have a decidedly hobbyist feel. Maybe that's why they are not drawing large crowds. I think the target audience consists of people who like to "sketch in code" and whip something up in 10 minutes using a REPL and highly interactive development rather than something heavyweight and serious-feeling. A language that "sparkles joy" a little bit, where easy things feel easy. And I don't think it's too late for that, or that the fringe has run out of room for such language attempts.

There are a few more hobbyist implementations out there, at various stages of completion:

    - https://github.com/ajlopez/beljs
    - https://github.com/erdos/carillon
    - https://github.com/luksamuk/believe

Due to how Bel is specified, all the mentioned implementations have "speed issues". I believe I can fix most of these, and the path forward is fairly clear (faster internal data representations, compiling to efficient bytecode). But I want to hold off announcing/releasing the project until most of the egregious performance problems are fixed. I'm biting my tongue so I don't make any promises/deadlines... but it's coming along. Help appreciated.

The good news is that it seems to be possible to make Bel run fast. I just need to put in the work to get there. Really looking forward to having a fast Bel at my fingertips.

Along the way, I've also discovered a few (minor) bugs in the Bel specification, as well as some things that are underspecified and don't really have answers. I'm also actively thinking about how to build a static type system around Bel's runtime typechecking, analogously to how TypeScript extends JavaScript with static types.

Yes. Somewhat simplified, hyphens inside of identifiers are allowed and not taken to mean infix minus.

I remember when this was switched on. Larry Wall tried it out on the entire spectest suite, and nothing broke (or at most one random thing broke), because basically people already put whitespace around their infix operators.

Incidentally, apostrophes are also allowed inside Perl 6 identifiers.

Personally, I used to conservatively use underscore (`_`) in my Perl 6 identifiers for some years. Then I got used to hyphens, and it's hard to go back.

...but then the television would be turned to an actual channel, not to a dead one...?

The (old) MIX programs in The Art of Computer Programming by Knuth were often self-modifying, in the sense that they modified jump addresses at the end of routines to return to the right caller. (That is, they set the address to right after the call.)

The book chose that way to do it because it was standard practice at the time. It quickly fell out of fashion, though. Nowadays, we do it with a call stack, and each stack frame holds a return address. (Which is better anyway, since it allows routines to be re-entrant.)

The newer MMIX architecture (in some of the newer books) don't rely on such self-modification.

Or maybe we needed to scale to some point with the Turing model for the Church model to assert itself and prove its merits in comparison.

It's a bit more thrilling to think of it that way, as a matter of scale. When space and time resources are scarce, thinking of the computer as a big piece of RAM that we mutate in-place makes the most sense. As we push upwards and outwards into enough resources and a bigger need for parallelism, it suddenly makes more sense to switch perspectives and reason in terms of binding and substitution.

Oh, we'll get unquotes, don't worry. It's more a question of not-yet-implemented than anything else.

Here I might as well ask HN what syntax I should go with for unquotes in 007. In Perl 6, unquotes are written as three nested braces: {{{$ast}}}

Almost no-one is happy with that syntax. It manages to be distinctive (and can be easily syntax-highlighted, too) but pretty it ain't.

The difficulty of finding something better is that it has to be orthogonal to basically all other syntax in the language. And that's a challenge in Perl. :) People keep proposing Unicode sigils and stuff, but I haven't seen something I like yet.

Author here. Thanks for all the kind words. README files are important, and I worked quite a bit on this one. Had some fun writing it.

A quick summary of the language itself: I felt I needed a smaller language than Perl 6 to "think" in as I mapped out exactly what we want from macros. If you're curious about the latest shape of that thinking process, you'll want to read https://gist.github.com/masak/13210c51f034f931af0c .

Implementing 007 has been a fun thing, and largely easier than I thought. Mostly bottlenecked by available tuits. Somewhat surprisingly, I found it much tougher going to implement user-defined operators than to implement macros. (But now that we have both, you can also haz custom operator macros!)

Next up, I plan to use 007 to map out as much of the terrain as possible covered by that gist above. That is, I want 007 to get synthetic Qtrees, really good handling of hygiene and lexical scoping, statement macros, maybe multis if I feel it's worth the trouble, introspection of Qtrees, and visitor macros.

The postcircumfix {} is still there, and used. It just unambiguously takes an expression, and doesn't try to intuit string quotes in some cases. So you use {} for indexing with a general expression, and <> for string indexing.

Here's the Perl 6 solution:

  multi infix:<+>(2, 2) { 5 }
  say 2 + 2;  # 5

I just wrote a post about MoarVM, too: http://strangelyconsistent.org/blog/a-vm-for-6model . Slightly more slanted towards how this fits into the evolution of Perl 6 implementations.

I'll make sure to link to previous years. In the meantime, here are the links to the 2010 edition:

Tasks: http://strangelyconsistent.org/blog/masaks-perl-6-coding-con...

Code reviews: http://strangelyconsistent.org/p6cc2010/

Perl 6, using Rakudo:

perl6 -e 'loop { print <9585 9586>.roll.chr }'

In fact, perl6 -e 'loop { print <╱ ╲>.roll }' will work too if your terminal is set up properly.

You should never "wait" for a programming language. :) I say this as someone who is deeply involved in Perl 6 development.

Learn Perl 5 if you want to learn how a full-featured, complete, and liberating-to-use programming language works.

Check out Perl 6 if you want to see what some of us are building, and if you value ideas as such, even when they haven't all been put together into a finished, polished product.

Reference: http://perldoc.perl.org/perlhist.html

Well, being a rational number, it has to wrap around somewhere. And since 999 + 001 == 000 (with the caveats for carries that people have explained elsewhere), it makes sense for it to wrap around at that point.

No, it's still too early for that.

That said, there's two of us in the company I work for: http://www.edument.se/english/ . I got hired mostly on my merits as a Perl 6 core contributor. We're eager to hire more Perl 6 programmers.

I've been an active Perl 6 user since 2008; during that time, I've often had too high expectations on then-current Rakudo implementations: I've been dabbling in wiki software, etc. It was slow. Sometimes it was unstable.

Seen from ten thousand meters, Rakudo 2008-2010 was about features, and Rakudo 2011 has been about performance. As moritz' retrospective states, the fruits of that work are only coming online now. That will enable more people to move into performance-sensitive fields such as web development with Perl 6. That's already starting to happen; see tadzik's Bailador project, for example.

Meanwhile, my Perl 6 production code has been getting by with slightly lowered expectations on performance and memory frugality. Crashes/segfaults are no longer a problem (as they were in 2008/2009). Tradeoff example: My blog, which runs on Perl 6, is statically generated rather than dynamically. That's been working out pretty nicely.

When I need more speed and/or regex/grammar features, I go with Niecza. Otherwise, I mostly develop on Rakudo. But Niecza's main developer is developing at an almost intimidating pace, and I expect to be using Niecza even more in 2012.

I'm trying to think of a way to read your question that doesn't make it dismissive and condescending. Why wouldn't the current three implementations be angled for real-world use?

I'm using Perl 6 "in the real world". I use it on my spare time. I use it at work. I have production code running in Perl 6. I use Perl 5 even more heavily, but with each month I use Perl 5 a little less and Perl 6 a little more.

Example: checking out a repository where someone named (say) a file 'foo' and a directory 'Foo'. It happens. Most of the time that checkout will simply fail. Having this not work is less than enjoyable.