jpochtar

`starts()` looks like it's not checking if len(source) < len(query), but if, say, query="foobar" and source="foo", when i = 3 the line

   if (source[i] != query[i])
      return false;

   if ('\0' != 'b')
      return false;

Always if len(source) < len(query), we'll return false when we get to i=len(source), because source[len(source)] != query[len(source)] as source[len(source)] == '\0' and query[len(source)] != '\0' since len(query) > len(source).

The 1st commit in this sequence is a pure refactor, and definitionally should change no behavior. The "snapshot test" described sounds perfect for this, especially in unfamiliar code. Ideally, I'd go even further, and have a compiler prove for me that my refactor produced a perfectly equivalent program from a black-box perspective. Snapshot testing is great because it gets pretty close, very cheaply, whereas the full program equivalence problem is impossible.

HTML is the view layer. The "program" layer is JS manipulating JSON (ultimately fetched from a DB).

Separating HTML and CSS made sense when content lived in HTML, and styling lived in CSS. Content hasn't lived in HTML in a long time— it lives in a DB now. (Maybe markdown if you're making a static site.) Separating HTML from CSS is separating view layer from view layer— just an unnecessary and expensive indirection

If you've heard "separate content from presentation" all your career, you might autonomically hear it as "separate HTML from CSS". I used to.

In a React app world, your content hasn't lived in HTML for a long time. It lives in your DB, and comes to you through JSON.

Your React codebase exists to style that JSON. That includes "HTML" (JSX), CSS, and whatever else you've got in there.

Since your HTML is for styling, and your CSS if for styling, why separate them? If you do, you're not separating content from presentation, you're separating presentation from presentation, and that's just wasteful.

Personally, I'd prefer to use inline styles for everything, though of course will use CSS for :hover of @media queries where I have to.

Docker users are mostly folks who specialize in other areas of programming, to whom Docker popularized affecting "fat binaries" out of PHP/Ruby/Python/node apps via chroot. Chroot was already well known to ops folks, but was arcane to most webapp devs.

We're not ops experts who have been confounded by marketing, we're ops amateurs for whom Docker cracked the nut of chroot legibility.

The author hates on Docker in comparison to other fat binary techniques; he ignores that pro-Docker advocates are comparing it to not using fat binaries at all.

There's little control flow to speak of in there, so if they had a problem, they could just dump locals() to get a good view of everything that happened.

When I went back to doing compilers work, I missed my debugger dearly. I also realized why I needed a debugger and my friends didn't: debuggers like this are particularly useful for work with compiler-like characteristics, of which there is unfortunately not enough.

Easier to work with -> fewer people needed -> fewer people hired -> fewer people learn -> fewer people know.

Now there's fewer people in the market who know Simple, vs many people who've learned OverEngineered (TM). Leadership wants to pick a language/style they'll be able to hire for as-needed. OverEngineered has a much larger talent pool.

  [
    ["the ", {}],
    ["JSON format", {"link": "https://www.json.org/"}],
    ["was invented by ", {}],
    ["Douglas Crockford", {"bold": true}],
    [".", {}]
  ]

For CRUD apps, you really just want HStacks, VStacks, and ZStacks like they have in SwiftUI.

They nicely express reflow behavior without driving you crazy or bloating your code. They're a bit more work than drag-and-drop because they make you be explicit about resizing/reflow, but you should be thinking about that anyway.

You'll want to skip that step when iterating quickly on design, but that's why you design in a separate design tool, which is visual and uses position:absolute.

When you're ready to parameterize the design over varying content and screen sizes you'll have to specify resizing constraints somehow, and in my experience, VStacks/HStacks in code are a pretty good way to do it.

I recommend adding building these abstractions on top of flexbox, and adding them to your standard library.

This is all specifically for CRUD apps. If you're making an animation, or something else that would feel wrong to call a "document", you probably want a completely different set of tools.

This code passes that test. Before reading it I would have never thought that could be a goal— I couldn't imagine it was possible to know what a program does without comments and documentation.

When I heard the word "readable" from others, I understood it as "parsable". From an OO context, I thought readable meant neatly formatted lines that let you say "ah, yes, this is an if statement", "this is a constructor", and so on, but with no idea what the code actually does or means to do.

Norvig's spelling corrector is better read without comments. The names of the functions tell you what you need to know— their purpose, and their implementations tell you exactly what the author thinks they mean.

It's "declarative": "def correction(word):..." means exactly "the correction of a word is ___", "def candidates(word):..." means exactly "the candidate corrections of a word are ___". There's a strong functional/LISP influence here, which I only learned later.

Because this code demonstrated it was possible, my standard for all code is that it should tell you what it does from one reading. Most code (including my own!) doesn't come close, but aiming for that goal has tons of good effects on difficult code.

Changed the way I think about code

They'll ask interview questions like "what's sizeof(int)" expecting a number, and will find "it depends on the compiler/architecture" evasive, unless you follow it up with "but it's always 4". To be fair, this is how 99% of people use C in practice, and x86/arm behave pretty similarly to each other in the scheme of things (vs, say, a LISP machine).

Taking into account ABI constraints, including x-{language,module} call safety, threading expectations, and more, a typical C programmer has to have a decent idea of how the machine works, relative to a Python/JS/Ruby programmer.

I don't love that someone "learning C to learn how the machine works" will think malloc()/free() are how the machine works, and will get have wrong expectations ideas about memory when using, say, V8's bump allocated nursery + compacting GC. But it's not a bad first step for someone who doesn't know what a pointer is to the machine.

React is great for Figma, Dropbox Paper, Coda, and Pagedraw: apps that are basically entirely local, and may or may not happen to be syncing with a server in the background.

CRUD is a special case of app, and the modern HTML/CSS/JS browser is pretty well tailored to handle all the needs for the client side of one. Maybe sprinkle in some Turbolinks [1] if you want some fancier page transitions.

It'll take time before someone makes a good CRUD framework on top of React. Until then, Rails is a great CRUD framework, and isn't missing much I'd expect to see React solve.

[1] https://github.com/turbolinks/turbolinks

[1] https://www.youtube.com/watch?v=L0N3C6DsisQ

https://norvig.com/spell-correct.html is like poetry— or at least what I imagine poetry is like to people who like poetry.

Reading it changed the way I look at code, and inverted what I consider good code.

If it's not in a super high level language it probably won't be beautiful, at least not in the same way as Norvig's spelling corrector. For lower-level code, approaching it like a scientist, as OP suggests, may be right; I wouldn't give up on a reading group for sufficiently high-level code.

[0] https://youtu.be/w-wbWGwZ7_k

Non-auto-updating software is the problem

Now that the major browser everyone's coding against is open source, and competitors can freely borrow their engine, I'd say we don't really need the W3C anymore.

Personally I prefer a functional style, but if you're going to use an imperative style, just use JS's built-in imperative for loop and assignment operators.

Also Tokyo seems pretty great, but I haven't lived there.

I'd push that yes, you do have to maintain your state externally in an immediate mode UI, but when you have a lot of "state" that's really just a function of other state, that's exactly what you want.