bakul

> The binding constraint appears to be engagement: realizing the promise of AI tutoring will require getting students to use it, not just giving them access.

This seems backward. Engaging students should be the primary goal, not AI tutoring. Great teachers engage students. Perhaps AI can somehow aid teachers in becoming better? [Though, I doubt it]

Yes.

Penrose tiling with kites and darts would be neat!

Strict Vegetarians don’t eat eggs. No D vitamin fortified milk in his days. Many vegetarians don’t eat mushrooms, the only plant based source of vitamin D.

Darker skinned people in northern latitudes. Made worse for vegetarians like Ramanujan in England.

It’s now one day only, at least through my library.

forums.freebsd.org may be a good place to discuss these sort of questions.

I just want a terminal that can also run fully graphical interfaces and that scroll as more lines are typed or a later command outputs text! Next level up from sixels or escape sequences.

Poul, have you looked at the Mill Architecture? It doesn't provide capabilities but provides "turfs". A turf is a set of [base..limit) regions in a single address space. Threads within a turf can only see what the turf allows them to see. Regions can be shared between turfs if so desired (& how one may communicate large amounts of data). When a thread makes a "portal call" it is in another turf and can only see what is in that turf (+ call args, passed on the "belt"). Not clear if this will go anywhere & might get forgotten but it is an interesting architecture worth exploring.

May be you need to have "scheduled downtime" when your undergirding system is down for "maintenance" and they will notice! [Half joking... Probably not possible but better to have scheduled maintenance than have to do firefighting under extreme time pressure]

The default serial build of V (tcc backend) takes 0.6 (with production compiler) to 1.3 seconds (with tcc backend compiler).

The production (clang backend) parallel build of V language takes about 3.2 seconds. All on an m1 mac. Even the go compiler seems slow in comparison.

I have used both Go (extensively) and V (not so much). Go's cross compilation, concurrency support, GC & stability are much better than V's. V compiles much much faster in spite of generating C (unless you use clang), plays better with C, its syntax choices seem better (default to const, less onerous error handling, sum types, option type, not relying on Capitalization for exporting etc.), optional GC (though far from perfect), etc. I can see writing an OS in V (but not in Go). I am in two minds about whether it should try to simulate concurrency like Go does (goroutines are coroutines, mapped to system threads only for blocking syscalls) as that might not be the right choice for kernel level code.

V hasn't had the resources or backing that Go continues getting. Most of its work is done by volunteers. AFAIK it hasn't had the benefit of the experience of multiple world class programmers like Go's designers. Good language design also involves leaving out features and that involves discussing or experimenting with such features. IMHO V can use more of that. But so far I like a lot of what I see in V.

Read the author’s “Raja Yoga Revisited”.