sieve

The biggest problem with a lot of northern languages is the awful schwa deletion. Even the Marathi of Maharashtra is subject to it. Strangely, the Marathi of Thanjavur has far, far less of it from what little I have heard of it.

Sanskrit does not do schwa deletion. So engines must map the phonemes to Kannada/Telugu (which support the full complement of Sanskrit sounds) if they want to get somewhere. A lot of this can be solved if the backend supports ipa.

But this is for classical Sanskrit. Vedic recitation is too complex (and I know too little about it) to handle without a LOT of work.

A lot of Hindu calendars do this. They use śukla and kr̥ṣṇa pakṣa (waxing and waning phases respectively). Days are numbered 0-14 with 0 referring to the full/new moon. Problem is each regional calendar is slightly different. And days might repeat.

I tried this yesterday using the hosted demo. The project info is being circulated in many Sanskrit-related WA and other groups.

The documentation of the `transliteration to Kannada` workflow is good. I (and I think a few others) was using this last year to produce story narrations of Chandamama and other Sanskrit stories using the audio models available on Google AI Studio. The schwa deletion on the Hindi side is infuriating with Sanskrit content.

Also, I wonder if this can support prose? Would be helpful for proofreading efforts because you can focus on the page image rather than constantly switch between two panes.

- The e-ink screen is great for reading. The feeling of ink on paper it produces cannot be replicated on any other screen. Not to my satisfaction.

- The microcontroller is so weak that you cannot add crappy features like more powerful e-readers are wont to do. This produces minimal distraction-free UIs. No messaging, no browsing.

- The form factor is the biggest win. It fits in a pocket and is great for the 5-10m you find when traveling or waiting somewhere. I cannot carry e-readers that way.

- It is great for fiction, and text-heavy non-fiction: history, philosophy etc. Stuff with a lot of images, tables, code blocks etc ... nope.

Every item you add to the device adds a failure mode. Light is fine. Touch ... I don't know. I like the tactile feel of buttons.

And Android means the device no longer runs on a microcontroller which has consequences for battery life etc. As long as they keep the original, minimal model active with minor QoL improvements, I guess it is fine.

Yes. I read multiple books in parallel. Each on a different reader. So syncing is not something I usually need though I did build myself a local sync server for fun.

It's not the best reader I own, but it's the best reader I have on me at any given moment

This. The form factor is almost the right one for an e-reader. The battery lasts for weeks. It is so open that you could probably write your own firmware for it based on CrossPoint or similar for your own needs.

Needs some iterative development while ruthlessly culling requests for random features.

epub is overkill for a vast majority of books.

A format that only supported

- headings

- paragraphs

- emphasis (bold/italics)

- bullets

- inline images

is good enough. A simple container with a TOC pointing to text blocks/files within it that can be processed very cheaply.

Unfortunately, with something like epub, you lose all the simplicity because you want to support every single feature even if rarely used.

Got the X4. Put CrossPoint on it. Works like a charm. The http server accessible over wifi makes transferring books extremely simple. (Shame on the Kindle for locking everything down.) This is proof-of-concept that a microcontroller is more than enough for something like an e-reader.

I have a Kindle and a Kobo. They are sturdy devices. But the X4 is the one that is a genuine e-reader. Would not get it as my one and only e-reader though as you tend to miss the size and backlight of the larger ones.

What would I want from future iterations?

- backlight even if it compromises on battery a bit

- a bit more DPI

Everything else is good enough.

It took some time but RuPay branded CCs are also available. I have been using them for the last 2-3 years at least. They work, mostly, with UPI.

Some merchants disable RuPay CC payments even when they don't get charged merchant fees till the payment crosses the INR 2K threshold.

Strangest thing is when I can pay the guy pushing a handcart around selling vegetables using a RuPay CC while a medical store refuses to accept it.

I like typst. But I am not a fan of the syntax. I use it as an intermediate format on the way to PDF. A document markup language should avoid building a programming language inside it. Pick python, or lua, or whatever.

Depends on the state and the political environment. Some people will deliberately sabotage projects for political reasons. The biggest problem with metros in India is the inability to provide last mile connectivity. Some cities will run buses in competition to metro lines, or provide free bus travel to women. Both actions compete against a fast mode of travel.

So, it is an India problem, not a government problem.

There are people running sites hosting old religious texts and hymns and a hundred other things that have nothing to do with programmers. A 4x jump in the bill for someone on limited income not gaining anything from it is not trivial. It results in the disappearance of a site that will not come back.

Datacenters are weird

In the same way that most public utilities are: train stations, railway lines, airports, garbage dumps, sewage treatment plants, military bases and a hundred other things. The negatives are concentrated to the locality and everyone else reaps the benefits.

I get it if you wish to put a 99% self-sufficiency condition (water/power etc) but everything else reeks of luddism and nimbyism.

This is very common as they have no conception of time. They are just using ballpark figures based on what they see in the wild. I see estimates for modules in weeks/months when it can produce it in a single afternoon of prompting.

Not comparable, but the story of Gerald Bull is interesting. I read Frederick Forsyth's The Fist of God in the late 90s and only came to know about Bull and Project Babylon when I chanced upon the Wikipedia article on the subject.

Any language that uses error codes instead of exceptions is a non-starter for me. Produces code that craps all over the happy path.

Python has a different problem: it is slow as f---. I did a micro benchmark comparison against 5 other languages in preparation for my python replacement language. Outside of dictionary lookups, it is 50-600 times slower than C depending on the workload.

Go, Rust etc are fine. They land at 1.25-3x slower than C. But I prefer the readability of python minus its dynamic nature.

A replacement for python.

- The base is a freestanding register VM deeply tied to the Linux kernel.

- It supports a set of primitives types, array types and record types.

- Concurrency is Erlang-ish --- an M:N scheduler that can manage tens of thousands of green processes. VM uses instruction fuel to preempt processes.

- GC is Cheney for the nursery + M&S for the rest. Each process has its own GC.

- tailcall support.

- first class functions.

- Phase One will only have Vm0, which is clean (it has access to a bounded set of Linux syscalls). Will think about Vm1 that handles the libc infection later.

- JIT is not on the table in Phase One.

- The language is statically typed and borrows syntax from python extensively, but drops OOP entirely.

- OOP is faked using UFCS.

- Operator overloading is supported.

- Exceptions are the default error handling mechanism. There are two hierarchies: Fault and Error. Fault cannot be trapped without rethrowing. Fault WILL crash the VM.

- It is being developed in private right now. As I am User # 0, all the choices I make reflect my own opinions and biases. I might release the code as OSS once the core is stabilized.

- I have done very basic microbenchmarking and the VM is so much faster than python right now that it is not a fair comparison anymore. I can also create and iterate over massive primitive arrays with ease. The principal comparison should be C, and here it is consistently about 8x slower and that performance profile will probably remain constant because dispatch has a real cost that cannot be magically wished away. I will be very happy with 5/6x.

Recovery is simple depending on your syntax (and whether your language supports exceptions). You pick a few places where you trap exceptions, add it to your log and continue. My current project is the first one that might becomes public. So it is the first time I have worked a little bit on usability. So multiple errors at a time, not one.

The older ones, no. The current project will be. I am developing in private and occasionally rewriting the jj tree to make each commit self-contained. So it won't contain all the false-starts and bad code, only the cleaned up version.

"ut" (https://github.com/s-i-e-v-e/ut) exists, but it is more of a POC for the syntax more than anything. So lexer+parser+typechecker. Did this during COVID in TypeScript but did not finish.

Every single book starts with regexes and DFA/NFA for lexical analysis. Too much ceremony for something you can write in 30 minutes and 300 lines

slowly

I cannot do slow. It is either burn the candle at both ends, or do nothing at all.

I am using LLMs this time as well, but I spent close to 400 hours over a period of 6-7 weeks on my project before I put it to the side temporarily (got bored once the thinking part was done). About 300 of those were spent on iterating over the language and VM specs and eliminating all ambiguities and needless features. The remaining 100 were used to produce the code --- the VM, the assembler and the compiler --- and to repeated rewrite it to conform to my way of doing things.

LLMs have let me become extremely choosy about which code I am willing to keep.

Yeah. I added the caveat because I haven't looked at the source of the major production compilers and didn't want to overreach. The hobbyist ones mostly stick to hand-rolled recursive descent.

I wish people would start with Nystrom's https://www.craftinginterpreters.com/ and avoid the dragon etc unless they really, really need it. Almost everything I have learnt about compiler/vm development, I have done so by reading random blogs and articles on various aspects and small tutorials on writing parsers and vms.

Even stuff like Crenshaw's Let's Build a Compiler was more useful to me than all these books that do lexical analysis using regular expressions. I have written lexers and parsers hundreds of times for all kinds of DSLs and config languages and not once have I used regular expressions to scan the text.

I think compiler courses teach from yacc, bison etc that's where this whole thing came from

Very true. I have a shelf full of books on compiler development and optimization. I have read them selectively, a chapter here, a chapter there. But that shelf is useless for a vast majority of people.

You might find it useful if you are developing a production-level compiler/vm (I cannot make this statement with a straight face while Python rules the world). But a simple and sensible architecture that uses recursive-descent parsing takes you a long way.

Most hobbyist compilers (and even some production ones) are written as a heavy front-end compiling down to C or LLVM. Very few people actually write their own backend.

I have written compilers for two families over the years: C and ML. My current preference is Python. I am currently working on a statically typed language that is inspired by Python (minus objects and OOP) that runs on a register VM.

Syntax is a minor issue but something that people are very opinionated about. You could technically build multiple front ends that share the typechecking, CFG validation, optimization, register allocation and byte code emission phases. But it is too much work for what is presently a personal project.

Anyone trying to do this... the first thing you do is avoid lex/yacc/bison/antlr. You do not need all this ceremony. A recursive descent parser that uses Pratt parsing will work for a vast majority of cases.

The lexer/parser is never the bottleneck. In fact, you can write those two by hand over a single weekend for a largish language. With LLMs, it takes 15 minutes if you have an unambiguous spec.

The biggest time sink, and the reason you will fail for sure, is the inability to restrict the scope of the project. You start with a limited feature set and produce the entire compiler/vm toolchain. Then you get greedy and fiddle with the type system, adding features that you have never used and probably never will. And now you have to change every single phase from start to end.

I mostly give up at this stage.

The equivalent analogy is charging lock/door/drywall/timber makers and suppliers for lapses if a thief entered the house by picking a lock or drilling/sawing through the wall.

The branch is the last place where a real person meets another real person. Even that person looks up everything on their terminal, and the whole thing is probably security theater, but I think having at least one physical backstop is a good idea.

My banks require physical presence for stuff like changing phone numbers and nominees. We get OTPs on our phones, so that makes perfect sense.

Claude is opaque as regards token usage. So you might end up using your 5hr limit in 7-10 minutes using regular Sonnet. Meanwhile, OpenCode etc give you exact breakdown in terms of how many cached tokens used per session etc which you can use to estimate burn rate.

All these coding tools are extremely wasteful as far as resources are concerned. Almost designed to make you move to the next tier. You have to consciously restrict their scope all the time to make your plans last. Even with Kimi/MiniMax a 3-4 hour session often ends up with 50-70M cached reads. Not a small amount at all.