I would have killed for this back when I had an A500. It seemed like dark magic and all I could find was a book on ASM game programming tricks, which was too advanced for me.
I discuss this pretty deeply in my indie founder bootcamp but the main point is, if your revenue goals are something like $20k/month (and not to build a unicorn) then one of the lowest risk decisions is to try to get a very tiny percentage of a “proven” very large market.
The reason is that getting a few hundred or a few thousand customers in a proven market with millions of customers is a very achievable goal over a few years.
No need to compete on price, just compete on great customer service and support. Be someone that your customers know and like and love dealing with.
And of course you do need to make a great product and find a marketing channel(s) to reach that small segment of customers.
I don't understand why so many people glorify hand-written parsers. Maybe because they never used good parser generators (not unlike type systems and Java) ?
Personal opinion: writing parsers is the least interesting part of an interpreter/compiler, and your grammar should be boring if you want your syntax to be easy to understand by humans.
Boring, in this case, mean LL(*), LR(1), or another well known class. Just pick a damn parser generator and get the job done quickly, so you can spend time on the really difficult tasks. The grammar in this article is LR(1) and is trivial to implement in yacc-like generators, locations tracking and error messages included.
Bonus point: since your grammar stays in a well known class, it's much easier for other people to re-implement it. You can't introduce bullshit ambiguous extensions to your grammar (C typedefs, anyone ?). This article gives a good explanation of this: http://blog.reverberate.org/2013/09/ll-and-lr-in-context-why...
Exactly, this is a language that they want to run a new economy, not just payment processing, but banking, title transfer, legal resolutions, and the metric it was judged on was "looks like javascript" and not say:
* Built in formal verification features to ensure a function does what the developer (and reader!) thinks and no cases are missed.
* Explicit language design (so that the compiler isn't even required to do strong safety: every action must be spelled out, even if a compiler could deduce it).
* Paying attention to the fucking history of the field (and not doing things like: insane name mangling, case sensitive semantics (not even just names by convention fucking semantics are case sensitive), hard to reason about VMs). Like come on people, at least learn from 20+ year old mistakes.
You (and Ola ...) really should take a look at the APL / J / K family. All are 10-100x times more expressive than Ruby/Python, and 100x-1000x times more expressive than C and Java.
They are all quite fast, with K being super-blazing-fast.
I would have killed for this back when I had an A500. It seemed like dark magic and all I could find was a book on ASM game programming tricks, which was too advanced for me.