catpolice

This is a very strange claim. Just off the top of my head, this definition of "mainstream mathematics" would exclude, for instance, Gödel's more famous theorems, a good bit of Grothendieck, some of the Bourbaki collective, and a huge amount of work from rather high profile mathematicians working today.

I'm not usually one to poke fun at these things but my friends who study formal logic/model theory/category theory/homotopy type theory/etc. will be excited to learn that they are not in fact doing mathematics.

Yeah, I think there are reasons why a lot of big compilers use some recursive descent variant (even a few like gcc used YACC-generated parsers for a long time and switched back to hand-written recursive descent parsers) and error message generation is a big one.

IMO there's a kind of funny progression in which parsing approach turns out to be the most appropriate depending on the scope of your project that circles back on itself:

- For pretty simple languages a hand-written recursive descent is obviously easiest

- Once your grammar is complicated enough that you start hitting precedence and ambiguity issues, or get sick of rewriting a big chunk of your parser as the grammar changes, you look into generating your parser from a BNF-like specification and end up with some variant of LL or LR

- At some point your language's grammar has mostly stabilized and you're struggling with providing good error messages or parsing performance or you've had to add one too many hacks to get around limitations of your parser generator and recursive descent starts looking good again

For my money, I tend to think that Pratt parsing/precedence climbing can extend recursive descent in a way that makes a lot of the common complaints about the complexity of dealing with operator precedence and associativity seem overstated. The trick is just that as you're building an AST, some symbols will cause you to reparent nodes that you thought you'd already placed, according to various rules. See: https://www.oilshell.org/blog/2017/03/31.html

I wrote a compiler for a vaguely C-like language by hand in javascript a while back that's intended to show how simple a hand-written parser (and code generator) can end up: https://github.com/j-s-n/WebBS

It's not that hard to statically track type information along the way - the above example requires a second pass at the AST to nail things into place and make sure all our operators are operating on the right type of thing, but a lot of that information is captured during the first parser pass or even during lexing.

Related: I made https://j-s-n.github.io/WebBS/index.html#splash which is designed to look like an MSDOS era GUI application

A mess of my personal life

She presumably waited until 101 so as to die in her prime.

I like this a lot, not as an alternative to MVC but as a kind of conceptual refactoring of the same ideas behind good MVC implementations that's very easy to explain and doesn't have as much ambiguity.

I've posted a version of this comment before, but my main problem with MVC isn't that it's a bad architecture, just that in practice there's a huge amount of disagreement about what MVC (or MV* more generally) actually _is_, which can lead to confusion or weird/bad hybrid implementations.

I tend to use the "model" and "view" concepts a lot when discussing architecture, but in my experience it's almost always a mistake to try and reference any specific MV* pattern for explanatory purposes - it does not have the effect of making the discussion clearer.

The issue is that there isn't actually a consensus about what constitutes the definitional features of these patterns, especially when it comes to how the concepts involved actually translate into code. For any sufficiently notable discussion of an MV* pattern, you're going to find an argument in the comments about whether the author actually understands the pattern or is talking about something else, and typically the commenters will be talking past one another.

Note that I'm NOT claiming that there's anything wrong with MV* as an architecture, or your favorite explanation of MV* - it may be perfectly well defined and concrete and useful once you understand it. The issue is a feature of the community: lots of other people have a different (and possibly worse) understanding of what MV* means, so when you start talking about it and your understandings don't align, confusion arises. Getting those understandings back in alignment is more trouble than the acronyms are worth.

I've seen enough conversations about concrete development issues suddenly turn into disagreements about the meaning of words to realize that nothing useful is conveyed by mentioning MV* and assuming anyone knows what you're talking about - it's better to spell out exactly what you mean in reference to the code you're actually talking about, even if you have to use more words.

I like this MOVE scheme because it seems to me to divide up the conceptual space at the joints in a way that's relatively hard to misunderstand, and it seems a little easier to see how to directly relate those division back to code.

Last year I decided to write a WASM-targeting compiler in Javascript, completely by hand. The idea was to compile a vaguely C-like toy language to WASM without any external dependencies.

Part of the motivation was that while I've written many simple parsers, I mostly used parser generators with BNF grammars and I didn't feel like I had a good sense of how the code I ended up generating actually worked for something with complex syntax and semantics. I felt like I was writing specs for a parser, rather than writing a parser. And I didn't have a huge amount of experience with code generation.

My toy language has vaguely C-like syntax with block scope and infix operators with various precedences, so it was a bit more complicated than JSON, but I ended up using something like Pratt parsing/Precedence Climbing (see https://www.oilshell.org/blog/2017/03/31.html) and wrote the whole thing in a way that's - hopefully - pretty easy to read for folks interested in wrapping their head around parsing complex syntax (e.g. with scope and name resolution). The lexer, parser and language definition ended up being about 1000 lines of JS (counting some pretty extensive comments).

Code generation is pretty straightforward once you have an AST.

Any JS programmers that are interested in really getting into the nitty-gritty of writing your own parser/compiler should check it out. The source is here: https://github.com/j-s-n/WebBS.

If you want to play around with the language and inspect the generated ASTs and WASM bytecode, there's an interactive IDE with example code here: https://j-s-n.github.io/WebBS/index.html#splash

Fun fact: the creator of RSS, RDF and Schema.org is Ramanathan V. Guha, a former leader at Cycorp (currently at Google).

1. There are internal and external factors when it comes to Cycorp's secrecy. The external factors come from the clients they work with, who often demand confidentiality. Some of their most successful projects are extremely closely guarded industry secrets. I think people at Cycorp would love to publicly talk a lot more about their projects if they could, but the clients don't want the competition getting wind of the technology.

The internal factors are less about intentionally hiding things and more about not committing any resources to being open. A lot of folks within Cycorp would like for the project to be more open, but it wasn't prioritized within the company when I was there. The impression that I got was that veterans there sort of feel like the broader AI community turned their back on symbolic reasoning in the 80s (fair) and they're generally not very impressed by the current trends within the AI community, particularly w.r.t. advances in ML (perhaps unfairly so), so they're going to just keep doing their thing until they can't be ignored anymore. "Their thing" is basically paying the bills in the short term while slowly building up the knowledge base with as many people as they can effectively manage and building platforms to make knowledge entry and ontological engineering smoother in the future. Doug Lenat is weirdly unimpressed by open-source models, and doesn't really see the point of committing resources to getting anyone involved who isn't a potential investor. They periodically do some publicity (there was a big piece in Wired some time ago) but people trying to investigate further don't get very far, and efforts within the company to open things up or revive OpenCyc tend to fall by the wayside when there's project work to do.

2. I don't know that much about this subject, but it's a point of common discussion within the company. Historically, a lot of the semantic web stuff grew out of efforts made by either former employees of Cycorp or people within a pretty close-knit intellectual community with common interests. OWL/RDF is definitely too simple to practically encode the kind of higher order logic that Cyc makes use of. IIRC the inference lead Keith Goolsbey was working on a kind of minimal extension to OWL/RDF that would make it suitable for more powerful knowledge representation, but I don't know if that ever got published.

Java _code_. It's madness, though I'm assured it made sense at the time.

These answers are very personal to me. I joined Cycorp because Doug Lenat sold me on it being a more viable path toward something like AGI than I had suspected when I read about it. I left for a number of reasons (e.g. just to pursue other projects) but a big one was slowly coming to doubt that.

I could be sold on the idea that Cyc or something Cyc-like could be a piece of the puzzle for AGI.

I say "Cyc-like" because my personal opinion is that the actual Cyc system is struggling under 30-odd years of rapidly accruing technical debt and while it can do some impressive things, it doesn't represent the full potential of something that could be built using the lessons learned along the way.

But the longer I worked there the more I felt like the plan was basically:

1. Manually add more and more common-sense knowledge and extend the inference engine

2. ???

3. AGI!

When it comes to AI, the questions for me are basically always: what does the process by which it learns look like? Is it as powerful as human learning, and in what senses? How does it scale?

The target is something that can bootstrap: it can seek out new knowledge, creatively form its own theories and test them, and grow its own understanding of the world without its knowledge growth being entirely gated by human supervision and guidance.

The current popular approach to AI is statistical machine learning, which has improved by leaps and bounds in recent years. But when you look at it, it's still basically just more and more effective forms of supervised learning on very strictly defined tasks with pretty concrete metrics for success. Sure, we got computers to the point where they can play out billions of games of Chess or Go in a short period of time, and gradient descent algorithms to the point where they can converge to mastery of the tasks they're assigned much faster - in stopwatch time - than humans. But it's still gated almost entirely by human supervision - we have to define a pretty concrete task and set up a system to train the neural nets via billions of brute force examples.

The out-of-fashion symbolic approach behind Cyc takes a different strategy. It learns in two ways: ontologists manually enter knowledge in the form of symbolic assertions (or set up domain-specific processes to scrape things in), and then it expands on that knowledge by inferring whatever else it can given what it already knows. It's gated by the human hand in the manual knowledge acquisition step, and in the boundaries of what is strictly implied by its inference system.

In my opinion, both of those lack something necessary for AGI. It's very difficult to specify what exactly that is, but I can give some symptoms.

A real AGI is agentive in an important sense - it actively seeks out things of interest to it. And it creatively produces new conceptual schemes to test out against its experience. When a human learns to play chess, they don't reason out every possible consequence of the rules in exactly the terms they were initially described in (which is basically all Cyc can do) or sit there and memorize higher-order statistical patterns in play through billions of games of trial and error (which is basically what ML approaches do). They learn the rules, reason about them a bit while playing games to predict a few moves ahead, play enough to get a sense of some of those higher order statistical patterns and then they do a curious thing: they start inventing new concepts that aren't in the rules. They notice the board has a "center" that its important to control, they start thinking in terms of "tempo" and "openness" so-on. The end result is in some ways very similar to the result of higher-order statistical pattern recognition, but in the ML case those patterns were hammered out one tiny change at a time until they matched reality, whereas in the human there's a moment where they did something very creative and had an idea and went through a kind of phase transition where they started thinking about the game in different terms.

I don't know how to get to AI that does that. ML doesn't - it's close in some ways but doesn't really do those inductive leaps. Cyc doesn't either. I don't think it can in any way that isn't roughly equivalent to manually building a system that can inside of Cyc. Interestingly, some of Doug Lenat's early work was maybe more relevant to that problem than Cyc is.

Anyway that's my two cents. As for the second question, I have no idea. I didn't come up with anything while I worked there.

Yes, I probably can't talk about them though. There are companies that use Cyc as part of processes for avoiding certain kinds of risks and the financial impact (by the company's estimation, not Cycorp's) is an unfathomably large amount of money. The thing I'm thinking of seems like something Cyc (or something Cyc-like) is relatively uniquely suited for. But for large scale systems, which thing is more easy in the long term is really hard to estimate with any confidence.

Really when it comes to practical applications using Cyc, there are three alternatives to consider and only two of them actually exist.

1. There are custom domain specific solutions, involving tailored (limited) inference engines and various kinds of smart databases.

2. There's Cyc.

3. There's a hypothetical future Cyc-like inference system that isn't burdened by 30 years of technical debt.

I personally suspect that some of Cycorp's clients would do better with domain-specific solutions because they don't realize how much of their problem could be solved that way and how much of the analysis coming from Cyc is actually the result of subject matter experts effectively building domain-specific solutions the hard way inside of Cyc. With a lot of Cycorp projects, it's hard to point your finger at exactly where the "AI" is happening.

There are some domains where you just need more inferential power and to leverage the years and years of background knowledge that's already in Cyc. Even then I sometimes used to wonder about the cost/effort effectiveness of using something as powerful and complicated as Cyc when a domain-specific solution might do 90% as well with half the effort.

If someone made a streamlined inference engine using modern engineering practices with a few years of concentrated work on making it usable by people who don't have graduate degrees in formal logic, and ported the most useful subset of the Cyc knowledge base over, that math would change dramatically.

All the programmers at Cycorp, and most of the ones who've gone on to do other things, have a dream of re-writing the inference engine from scratch. Its just that those dreams don't necessarily align in the details, and the codebase is so, so, so big at this point that it's a herculean undertaking.

I'm not sure I'm able to answer that in a satisfying way just because my memory is fallible. The degree to which the system is unsure of something (to the degree to which that can be coarsely represented) certainly shows up in the results, and I suspect the underlying search heuristics tend to prioritize things with a represented higher confidence level.

The latter thing sounds like something Doug Lenat has wanted for years, though I think it mostly comes up in cases where the information available is ambiguous, rather than unreliable. There are various knowledge entry schemes that involve Cyc dynamically generating more questions to ask the user to disambiguate or find relevant information.

I don't work there anymore, though I know some folks that do. I suspect that they're reading this and don't want me to air out their dirty laundry too much.

Here's what I'll say: the degree of isolation between different mindsets and disagreement (that was typically very amicable if it was acknowledged at all) is emblematic of the culture of the company. There are people there with raaadically different ideas of what Cyc is for, what it's good at and even about empirical things like how it actually works. They mostly get along, sometimes there's tension. Over the years, the Cyc as its actually implemented has drifted pretty far from the Cyc that people like Doug Lenat believe in, and the degree to which they're willing or able to acknowledge that seems to sort of drift around, often dependent on factors like mood. Doug would show up and be very confused about why some things were hard because he just believes that Cyc works differently than it does in practice, and people had project deadlines, so they often implemented features via hacks to shape inference or hand-built algorithms to deliver answers that Doug thought ought to be derived from principles via inference. Doug thinks way more stuff that Cyc does is something that it effectively learned to do by automatically deriving a way to solve the general form of a problem, rather than a programmer up late hand-coding things to make a demo work the next day, and the programmers aren't going to tell him because there's a demo tomorrow too and it's not working yet.

If there are current employees reading, they might be able to give a better answer than me. Basically, the project is to build a huge knowledge base of basic facts and "common sense" knowledge and an inference engine that could use a lot of different heuristics (including ones derived from semantic implications of contents of the knowledge base) to do efficient inference on queries related to its knowledge. One way of looking at Cyc from a business point of view is that it's a kind of artificial analyst sitting between you and a database. The database has a bunch of numbers and strings and stuff in a schema to represent facts. You can query the database. But you can ask an analyst much broader questions that require outside knowledge and deeper semantic understanding of the implications of the kinds of facts in the database, and then they go figure out what queries to make in order to answer your question - Cyc sort of does that job.

The degree to which it's effective seemed to me to be a case-by-case thing. While working there I tended to suspect that Cyc people underestimated the degree to which you could get a large fraction of their results using something like Datomic and it was an open question (to me at least) whether the extra 10% or whatever was worth how much massively more complicated it is to work with Cyc. I might be wrong though, I kind of isolated myself from working directly with customers.

One issue is just that "useful" always invites the question "useful to whom?"

Part of the tension of the company was a distinction between their long term project and the work that they did to pay the bills. The long term goal was something like, to eventually accumulate enough knowledge to create something that could be the basis for a human-ish AI. Whether that's useful, or their approach to it was useful, is a matter for another comment. But let's just say, businesses rarely show up wanting to pay you for doing that directly, so part of the business model is just finding particular problems that they were good at (lots of data, lots of basic inference required using common sense knowledge) that other companies weren't prepared to do. Some clients found Cyc enormously useful in that regard, others were frustrated by the complexity of the system.

Cyc has a few ways of dealing with fallibility.

Cyc doesn't do anything Bayesian like assigning specific probabilities to individual beliefs - IIRC they tried something like that and it had the problem where nobody felt very confident about attaching any particular precise number to priors and also the inference chains can be so long and involve so many assertions that anything less than 1 probability for most assertions would result in conclusions with very low confidence levels.

As to what they actually do, there are a few approaches.

I know that for one thing, there are coarse grained epistemic levels of belief built into the representation system - some predicates have "HighLikelihoodOf___" or "LowLikelihoodOf___" versions that enable very rough probabilistic reasoning that (it's argued - I have no position on this) is actually closer to the kind of folk-probabilistic thinking that humans actually do.

Also Cyc can use non-monotonic logic, which I think is relatively unique for commercial inference engines. I'm not going to give the best explanation here, but effectively, Cyc can assume that some assertions are "generally" true but may have certain exceptions, which makes it easy to express a lot of facts in a way that's similar to human reasoning. In general, mammals don't lay eggs. So you can assert that mammals don't lay eggs. But you can also assert that statement is non-monotonic and has exceptions (e.g. Platypuses).

Finally, and this isn't actually strictly about probabilistic reasoning, but helps represent different kinds of non-absolute reasoning: knowledge in Cyc is always contextualized. The knowledge base is divided up into "microtheories" of contexts where assertions are given to hold as if they're both true and relevant - very little is assumed to be always true across the board. This allows them to represent a lot of different topics, conflicting theories or even fictional worlds - there are various microtheories used for reasoning events in about popular media franchises, where the same laws of physics might not apply.

Yes, quite a few. The prerequisite is basically that you have to be able to do formal logic at the first order level and also Doug has to be in a good mood when you do the interview.

1) The money situation has changed over the years, and they've had times where things have boomed or busted - it's been a while since I left but I think they're still in a "boom" phase. There are a lottt more projects with different companies or organizations than the ones listed on the wiki, but they tend to be pretty secretive and I won't name names.

The categories of projects that I was familiar with were basically proof of concept work for companies or government R&D contracts. There are lots of big companies that will throw a few million at a long-shot AI project just to see if it pays off, even if they don't always have a very clear idea of what they ultimately want or a concrete plan to build a product around it. Sometimes these would pay off, sometimes they wouldn't but we'd get by on the initial investment for proof of concept work. Similarly, organizations like DARPA will fund multiple speculative projects around a similar goal (e.g. education - that's where "Mathcraft" came from IIRC) to evaluate the most promising direction.

There have been a few big hits in the company's history, most of which I can't talk about. The hits have basically been in very circumscribed knowledge domains where there's a lot of data, a lot of opportunity for simple common sense inferences (e.g. if Alice worked for the ABC team of company A at the same time Bob worked for the XYZ team of company B and companies A and B were collaborating on a project involving the ABC and XYZ teams at that same time, then Alice and Bob have probably met) and you have reason to follow all those connections looking for patterns, but it's just too much data for a human to make a map of. Cyc can answer questions about probable business or knowledge relationships between individuals in large sets of people in a few seconds, which would be weeks of human research and certain institutions pay a high premium for that kind of thing.

2) Oh god. Get ready. Here's a 10k foot overview of a crazy thing. All this is apparent if you use OpenCyc so I feel pretty safe talking about it. Cyc is divided into the inference engine and the knowledge base. Both are expressed in different custom LISPy dialects. The knowledge base language is like a layer on top of the inference engine language.

The inference engine language has LISPy syntax but is crucially very un-LISPy in certain ways (way more procedural, no lambdas, reading it makes me want to die). To build the inference engine, you run a process that translates the inference code into Java and compiles that. Read that closely - it doesn't compile to JVM bytecode, it transpiles to Java source files, which are then compiled. This process was created before languages other than Java targeting the JVM were really a thing. There was a push to transition to Clojure or something for the next version of Cyc, but I don't know how far it got off the ground because of 30 years of technical debt.

The knowledge base itself is basically a set of images running on servers that periodically serialize their state in a way that can be restarted - individual ontologists can boot up their own images, make changes and transmit those to the central images. This model predates things like version control and things can get hairy when different images get too out of sync. Again, there was an effort to build a kind of git-equivalent to ease those pains, which I think was mostly finished but not widely adopted.

There are project-specific knowledge base branches that get deployed in their own images to customers, and specific knowledge base subsets used for different things.

I worked for Cycorp for a few years recently. AMA, I guess? I obviously won't give away any secrets (e.g. business partners, finer grained details of how the inference engine works), but I can talk about the company culture, some high level technical things and the interpretation of the project that different people at the company have that makes it seem more viable than you might guess from the outside.

There were some big positives. Everyone there is very smart and depending on your tastes, it can be pretty fun to be in meetings where you try to explain Davidsonian ontology to perplexed business people. I suspect a decent fraction of the technical staff are reading this comment thread. There are also some genuine technical advances (which I wish were more publicly shared) in inference engine architecture or generally stemming from treating symbolic reasoning as a practical engineering project and giving up on things like completeness in favor of being able to get an answer most of the time.

There were also some big negatives, mostly structural ones. Within Cycorp different people have very different pictures of what the ultimate goals of the project are, what true AI is, and how (and whether) Cyc is going to make strides along the path to true AI. The company has been around for a long time and these disagreements never really resolve - they just sort of hang around and affect how different segments of the company work. There's also a very flat organizational structure which makes for a very anarchic and shifting map of who is responsible or accountable for what. And there's a huge disconnect between what the higher ups understand the company and technology to be doing, the projects they actually work on, and the low-level day-to-day work done by programmers and ontologists there.

I was initially pretty skeptical of the continued feasibility of symbolic AI when I went in to interview, but Doug Lenat gave me a pitch that essentially assured me that the project had found a way around many of the concerns I had. In particular, they were doing deep reasoning from common sense principles using heuristics and not just doing the thing Prolog often devolved into where you end up basically writing a logical system to emulate a procedural algorithm to solve problems.

It turns out there's a kind of reality distortion field around the management there, despite their best intentions - partially maintained by the management's own steadfast belief in the idea that what Cyc does is what it ought to be doing, but partially maintained by a layer of people that actively isolate the management from understanding the dirty work that goes into actually making projects work or appear to. So while a certain amount of "common sense" knowledge factors into the reasoning processes, a great amount of Cyc's output at the project level really comes from hand-crafted algorithms implemented either in the inference engine or the ontology.

Also the codebase is the biggest mess I have ever seen by an order of magnitude. I spent some entire days just scrolling through different versions of entire systems that duplicate massive chunks of functionality, written 20 years apart, with no indication of which (if any) still worked or were the preferred way to do things.

I love articles about writing parsers by hand - it's really fun and teaches you a lot.

Last year I decided to write a complete compiler in Javascript, completely by hand. The idea was to compile a vaguely C-like toy language to WASM without any external dependencies.

Part of the motivation was that while I've written many simple parsers, I mostly used parser generators with BNF grammars and I didn't feel like I had a good sense of how the code I ended up generating actually worked for something with complex syntax and semantics. I felt like I was writing specs for a parser, rather than writing a parser.

My toy language has vaguely C-like syntax with block scope and infix operators with various precedences, so it was a bit more complicated than JSON, but I ended up using something like Pratt parsing/Precedence Climbing (see https://www.oilshell.org/blog/2017/03/31.html) and wrote the whole thing in a way that's - hopefully - pretty easy to read for folks interested in wrapping their head around parsing complex syntax (e.g. with scope and name resolution). The lexer, parser and language definition ended up being about 1000 lines of JS (counting some pretty extensive comments).

Any JS programmers that are interested in really getting into the nitty-gritty of writing your own parser/compiler should check it out. The source is here: https://github.com/j-s-n/WebBS (relevant files for parsing are in /compiler - start with lexer.js, parser.js and syntax.js).

If you want to play around with the language and inspect the generated ASTs and WASM bytecode, there's an interactive IDE with example code here: https://j-s-n.github.io/WebBS/index.html#splash

RIP screensavers

A while back I wrote a solver that uses no backtracking, just constraint propagation, and it wasn't substantially more complex than this.

One of the key insights comes from noticing a feature of groups of numbers in cells. For example, suppose you notice two cells in a given row and they're the only cells in that row that the numbers 1 and 2 can be placed in - then one of them is going to have 1 and the other will have 2, and you don't know which but you can eliminate any other possibilities in those two cells. This generalizes to groups of any size in rows/columns/squares. I think that and maybe one other heuristic along with the basic rules about number placement is enough to solve everything.

"For syntax highlighting, any form of OT or CRDT is overkill; the highlighting is a stateless function of the document, so if there's a conflict, you can just toss the highlighting state and start again."

I first became interested in CRDTs in a case where this wasn't really true. I was writing an IDE for a custom in-house DSL - think of the application as a special language for interacting with a gigantic and very strange database. Basically, the problem was that the use case really stretched the bounds of what is normally done with syntax highlighting. Some requirements:

- It had syntax and semantic highlighting, where the visual feedback associated with a term would depend on the results of queries to the remote database

- It had to be able to handle documents of several megabytes (and many thousands of terms) fairly smoothly, with as little noticeable lag or flicker as possible

- It couldn't swamp the database with unnecessary requests

- The document itself had implicit procedural state (e.g. if you wrote a command that, if evaluated, would alter the state of a term on the database, appearances of that term later in the document needed to be highlighted as if those changes had already been applied)

So I definitely couldn't throw out metadata and start over with every change. I ended up with a kind of algebraic editing model that allowed me to put bounds on what needed to be updated with every edit and calculate a minimal set of state changes to flow forward. It was extraordinarily complicated. I never got around to learning enough about CRDTs to determine if they'd be simpler than the solution I came up with, but they do seem to target some similar issues.

A few years ago I implemented a vaguely similar image compression algorithm just for kicks. I basically did a separate binary space partition for each color channel of the image, with the splitting points determined by minimizing an error function. It was extremely simple to implement and worked pretty well, except it represented big curves with little compression.

The fun part was when I dropped the error minimization in the partition choice function and set it to choose them randomly:

https://pbs.twimg.com/media/DMr5LaMUQAA2h2E?format=jpg&name=...

https://pbs.twimg.com/media/DMr4Vc4U8AAOlyn?format=jpg&name=...

I think the churn rate is higher with front-end stuff, but I don't think it's really due to any special property of the technology. Honestly, I suspect that the rate of change in a given ecosystem is roughly correlated with the number of programmers actively working in it.

The number of front end web developers has been skyrocketing since the late 90s - a lot of people who've been in the industry for a while don't realize how many more of them there are compared to 5, 10 or 15 years ago. There's been growth elsewhere too, but just in the past few years the number of new bootcamp front-end developers I've seen seems to sort of swamp most other sectors.

I suspect that since much of the innovation in that space has been driven by open source efforts, the amount of change is in part driven by the number of eyes on problems and the number of people interested in trying new things. There are a jillion new JS projects on github every month, and some of them catch on, so there are always new options.

A lot of the listed problems are basically verbose repeated patterns, which is pretty much what macros are for.

That's interesting - I didn't know Notepad++ still ranked so high.

Oddly enough, I'm actually pretty acutely aware of how much performance matters in this space - at my last job, I spent a year developing an IDE for a custom in-house language/environment with some unusual required features. I looked in to extending existing editors/IDEs. The web-based editors were too slow for my application (which required a very large number of page updates from remote sources) but extending the native editors was an unfathomable pain. When I looked into things that didn't use a browser back-end, I was budgeting a month just to learn enough about their plugin architectures to determine if what we needed was possible without rewriting the UI code from scratch, which I really wanted to avoid. From experience, working with raw Java/C++ UI toolkit code is a nightmare compared to html/js and requires orders of magnitude more LOC just to put anything on the screen that can be interacted with.

In the end, I wrote my own web-based IDE from scratch, using a lot of application-specific performance optimizations that would be really difficult for a more generic, modular system (lots more care about what parts of the DOM to touch and when went directly into the parser than would have been possible with Atom/VSCode/CodeMirror/whatever at the time). I spent 6 months optimizing it and it was only barely fast enough that you could type at close to 60fps in big documents, but I don't think I could have made a native version that worked at all in that time.

So I get it: performance is important, and there are cases where web-based things either don't cut it or are barely acceptable.

My point wasn't that performance isn't important, it's that it's not the only concern and pointing to the relative popularity of editors over time still illustrates that. Notepad++ was released 12 years before VSCode (which has only been around for ~3 years) and has had better performance this whole time, but in the 2018 Stack Overflow survey, VSCode beats it in popularity. So performance can't be the overriding factor in its relative popularity - it became popular in spite of being slower than things that already existed.

The author of the original piece argues that the whole web-stack is _wrong_ and should be thrown out and replaced with something else, because it's slow and people don't care about how easy it is to develop something if it's slow. I don't think that's true, and the easiest way to see that is to note that we already had faster things that were harder to develop and extend and they're increasingly being rejected in favor of the opposite.

I didn't mean to imply that, if I did. That said, Atom and VS Code did gain a big market share of the text editor/IDE space pretty quickly, and the author called out Atom as something built on a web platform that was slow and bad because it was built on the web platform, and further implied that we could build better a better version of it if we abandoned the web platform.

My point was just that the new editors were successful in the ways that they were (e.g. for web developers working with a quickly evolving language) precisely because of the fact that they were built on an extensible platform, and in spite of the performance issues.

I was an Emacs user a few years back. Then I started writing more Javascript than lisp and picked up React. IIRC the point where I switched to Atom was when the emacs syntax highlighting packages were choking on es2015, but I could get support for JSX and stage-0 ES extensions if I used Atom. If Atom had been built with a focus on performance over extensibility, those features wouldn't have showed up as quickly as they did and I wouldn't have had any reason to consider switching. Atom was extensible (and not uniquely so) because it was built on a browser and didn't have to reinvent the language and concepts that browsers already had for building basic UI features. I'm not sure we're going to see a new, successful IDE for quickly evolving languages that does reinvent that wheel, as it seems the author is suggesting that we do, in the name of performance.