masak
Joined 17 years ago
Karma
119
Submissions
46
Member since
Jan 20
Recent submissions
Comment · 4 years ago
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.
Comment · 4 years ago
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...
Comment · 4 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 5 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 6 years ago
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.
Comment · 7 years ago
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.
Comment · 7 years ago
...but then the television would be turned to an actual channel, not to a dead one...?
Comment · 7 years ago
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.
http://masak.org/carl http://strangelyconsistent.org/ https://github.com/masak/bel