Thank you for saving me the time writing this. Nothing screams midwit like "Em-dash = AI". If AI detection was this easy, we wouldn't have the issues we have today.
"Pattern matching" is not sufficiently specified here for us to say if LLMs do pattern matching or not. E.g. we can say that an LLM predicts the next token because that token (or rather, its embedding) is the best "match" to the previous tokens, which form a path ("pattern") in embedding space. In this sense LLMs are most definitely pattern matching. Under other formulations of the term, they may not be (e.g. when pattern matching refers to abstraction or abstracting to actual logical patterns, rather than strictly semantic patterns).
Seconding this, light themes cripple syntax highlighting, which in turn makes it far more annoying to quickly scan through code and glean structure. You can make up for this to some degree with text decorations, but, well, with dark schemes you have that too.
I have about 1500 lines in my VSCode settings.json dedicated to custom syntax highlighting and text decorations (this could be trimmed, some is from before the days of semantic highlighting), but regardless, the amount of differentiation I can achieve with this is simply not possible on a light background. I've tried! (Solarized light is a nice theme though)
This is a pretty awful post, the problem is his example uses a horrible syntax highlighting scheme that makes use of far too few colours and no other text decorations.
In a competent highlighting scheme, you have enough differentiation that every distinct type of thing indeed has a different way it pops.
You don’t see a for loop? Or don’t know where is the variable and where is the method? The list goes on. Never in my life I need a color to differentiate between a class name and a variable (they already differ in first-letter case). Or between language keyword and a variable (I’m not 5, I know those keywords by heart).
There is a reason we use nouns for variables, verbs for methods, stuff like isReady or hasAccess for booleans and what have you.
Color is overrated (or rather very nice for stuff that matters: like comments).
I like cursive though to highlight variables that are assigned more than once (bold cursive if it is a parameter, god forbid): instant attention to what is usually a code-smell.
Code can be read without any syntax highlighting or text decoration, obviously. But adding those things is an additional information stream that makes processing faster and more reliable (redundancy in general has this effect).
As you said, it is especially useful for making certain code smells instantly visible at a glance.
I also find that different kinds of code will get different "color rhythms" (e.g. low-level algorithmic code vs. high-level code that calls a lot of functions vs. code that does a lot of operations / mutation of object or class properties) when syntax highlighting is properly semantic. This makes scanning for certain types of things (where objects are being mutated, where variables are introduced, etc) extremely fast, since you don't even need to read the characters.
I also find that rich syntax highlighting makes the codebase easier to remember, since the color (along with things like the line-lengths) gives each function a sort of unique visual texture.
Of course, all of this is personal preference. I am a very visual thinker so this kind of stuff helps a lot for me. Some people are far more verbal in their mental imagery or may remember code chunks solely based on semantics. Then, obviously, a bunch of color and/or text decorations might not matter much, or even just be a distraction.
In my usage, the coloring allows my eyes to “snap” to relevant chunks of code and restrict scanning to the bounds of those chunks.
Functionally it seems similar to spatial memory where landmarks are used as navigation shorthand and is impaired in circumstances where everything looks the same (e.g. in one of those sprawling suburbs with 100 of the same house).
I remember colors better than I remember names. It's a difference in how I process text, and for code where there's already 'types' of syntax, colors help differentiate between all those. It's not that I can't find the for loop, it's just that visually it becomes more distinct to me if all loops are a certain color. And class names are a certain color. And those colors tend to stand out better on a dark background than a light one. Reading light themes, or even unthemed code just feels like an additional chore that's solved pretty simply by using a dark theme.
No one needs it, but it's nice to have. It's the difference between being partially or fully colorblind or not being so, in terms of being able to distinguish parts of the codebase more easily. That is what the parent means by "easier to parse code."
> I like cursive though to highlight variables that are assigned more than once
Exactly, everyone is different, as personally I'd hate cursive and ligatures. Think of it as, what works for you doesn't work for everyone, and what works for them (color) doesn't work for you. But let people have their preferences.
Agreed, they should be using color schemes that are TreeSitter compatible so for example "React" and "window.React" are not the exact same color, as they are semantically two different things.
99% of vscode themes are like the one he showed. IMO, the best themes do typically have minimal/functional highlights, which results in more text that is the base color.
I'd need a citation for that statistic, and I'd also need to see which themes are actually used.
> IMO, the best themes do typically have minimal/functional highlights, which results in more text that is the base color
And IMO, those are the worst themes.
These things are just preferences, but it is an objective fact that a good highlighting scheme makes certain information immediately visible, without requiring the reader to parse the actual characters. Whether or not this information is something you find helpful or annoying depends on your processing styles and preferences.
SeriousEats is great most of the time, and if you can "acquire" copies of any of the Modernist series (Modernist Cuisine, Modernist Cuisine at Home, Modernist Bread, Modernist Pizza), those are all done by mass with baker's percentages.
Cooking is only about proportions in some very narrow fields (e.g. baking), and, even then, adjustment to ingredients, environment, and other contextual factors is paramount, and most adjustments need to be non-linear (whether by mass, volume, or surface-area). If the proportions are anything other than guidelines, you are doing mediocre cooking, at best.
Sifting, IMO from experience, does not solve the mass-to-volume ratio problem enough compared to just going by mass.
As a quick sanity test, if it did, serious baking resources would just always specify to use sifted flour (as this is easier and requires less equipment than a scale), but since they don't (e.g. Modernist Bread/Pizza, if you really demand a citation), you can infer that sifting is not effective in making reproducible results. Also, note e.g. chemistry is not done using sifted volumes (peruse quickly the amount of articles trying to assess the bulk vs "tapped density" of various powders: https://scholar.google.ca/scholar?hl=en&as_sdt=0%2C5&q=%22ta...). This should cause some skepticism about claims that sifting your flour is going to make baking results particularly consistent.
Sifting definitely helps remove variance (especially if you always buy the same flour and use the same sifting method into the same bowl, and then put un-needed sifted powder back into the jar), but IMO is far inferior to just weighing.
You're still right everyone overthinks home baking. Precision only matters if you are aiming for perfection, and even a horribly misspecified recipe made at home, but consumed fresh, is still generally going to be good, and definitely better than anything you buy at a supermarket. (And this is precisely why using a slide rule for precision is massively missing the point). As you said, there are many indicators that are more important to pay attention to.
> you're going to be estimating anyway once you've gotten familiar with a recipe
I would disagree slightly for this when it comes to making precise doughs or other things like brines, syrups, candy, and etc. Or at least I would change "estimating" to "adjusting" in your statement above. When it comes to trying something new (whether in baking from a proper source, like e.g. Modernist Bread or Modernist Pizza, or otherwise), a scale is invaluable.
But yeah, once you have some something a few times and have the feel, you can convert to volumes and go based on your senses. There's a baseline science / formula to some cooking, but the rest really is art.
This feels like a nit, because really I am just glad to see someone else pointing out the obvious realities here. While I would be hesitant to try Mr. Slide Rule's cooking, I'd try your cooking without fear!
The imprecision of volumetric measurements can absolutely ruin much baking, and many other recipes based on things like surface areas, or where the perception of flavours does not scale linearly with things like either volume or mass of the ingredient.
You're right volumes seem easier, at first blush, but the cost of this easiness is a dramatic / considerable reduction in consistency, compared to when measuring by mass.
Once you switch to regularly scaling by mass (just as a guideline, and still adjusting to taste, texture, and other factors), you'll realize the apparent easiness of volumes is pure illusion, and actually makes getting good results much harder.
Baking--along with fermentation, curing, and certain brines or other solutions--is the subset of cooking where accuracy of the masses of ingredients matters more than most others.
And yet still you are right you must often adjust significantly in baking for other factors (temperature + yeast activity, humidity, flour grind and composition, and general feel on kneading).
reply