The post How Functional Programming Shaped (and Twisted) Frontend Development from four days ago provides great broader context about the history and concerns. It ends with what this post seems to primarily concern itself with: The alternatives, improvements, innovation, and opportunities we may be missing / should evaluate.
Coloring is categorization of code. Much like indent, spacing, line-breaking, aligning, it aids readability.
None of the examples they provided looked better, more appropriate, or more useful. None of the "tests" lead me to question my syntax highlighting. Quite the contrary.
By reducing the highlighting to what they seem important, they're losing the highlighting for other cases. The examples of highlighting only one or two things make it obvious. When you highlight only method heads, you gain clarity when reading on that level, across methods, but lose everything when reading the body.
I didn't particularly like their dark theme choice. Their initial example is certainly noisy, but you can have better themes and defaults with more subtle and more equal strength colors. The language or framework syntax and spacing can also influence it.
Bolding is very useful when color categorizes code to give additional structure discoverability, just like spacing does.
I failed the question about remembering what colour my class definitions were, but you know what? I don’t care. All I want is for it to be visually distinct when I’m trying to parse a block of code
Between multiple IDEs, text editors, diff viewers and editors, and hosted tools like MR/review diff, they're not even consistently just one thing. For me, very practically and factually. Colors differ.
As you point out, they're entirely missing the point. What the colors are for and how they're being used.
That's a very one-dimensional view of technical debt.
I was about to write something more, but I think if I don't know what they refer to when they say "knowledge", then it's too wishy-washy and I may be talking about something different than they intended.
Contrasting “resolving technical debt” and “investing [improvement] knowledge” we're moving the reference view point.
I document state and issues as technical debt, and opportunities for change as opportunities. They cross, but are distinct concepts, and do not always cross. Some technical debt may be documented without a documented opportunity. Opportunities may be open improvements that do not tackle technical debt.
In my eyes, technical debt is about burdens that reduce maintainability where better alternatives likely exist.
"Investing knowledge" is something different, and not necessarily about known burdens, but may be improvements unrelated to known burdens.
UZDoom is a feature centric port for all Doom engine games, based on ZDoom, adding an advanced renderer, powerful scripting capabilities, and forked under a
It ending with 'forked under a' is probably a reference to that comment? lol, nice reference joke, but I hope they change it after a while, because as a description it's quite confusing.
Great comment on there links two code comment threads I found significant and interesting.
While it was primarily about ethics, it should also be noted that the code was described as being "impressively wrong", as well as not actually compiling. I mean, it basically checked if a theme was dark by if it had the word "dark" in the name - which is not a good heuristic - when better ways of doing it exist.
I love SonarQube (previously called SonarLint). I/We use it at work in dotnet/C# and web/Blazor projects.
Their free offer is great.
The dotnet and Visual Studio analyzer suggestions are already a great tool. Adding SonarQube on top, and recently I've added Roslynator Analyzers as well gives great free tooling, linting, suggestions of various levels, and quick actions to apply.
With the commercial backing they have, SonarQube is very well maintained/developed as well, with regular updates.
Build rich, interactive console applications using familiar Razor syntax and the power of Spectre.Console
RazorConsole bridges the gap between modern web UI development and console applications. It lets you create sophisticated terminal interfaces using Razor components, complete with interactive elements, rich styling, and familiar development patterns.
My experience seems to be the opposite from yours. On every point you listed.
CSS has certainly grown into something with a historic legacy and backwards compatibility and stability directly contributes to a more mixed implementation than clean, streamlined and clear approach, but that's a consequence of combining evolution and backwards compatibility.
I haven't seen a better alternative yet, for web or other UI development approaches.
When programming.dev became practically unusable most of the time in the last several days I was considering moving elsewhere. No post or announcement even acknowledging the issue here in meta didn't make me hopeful in the issues subsiding at all. (I've experienced instance death before on feddit.de.)
It's intended to become a spiritual successor to ThiefMD.
What does it want to or already do different or better than ThiefMD?
I see the release has a flatpak. A Windows binary or installer would be great too, attached to the release, so it doesn't require cargo toolchain and build to use.
Wait. Does it even support Windows? I guess not? I read Rust and GTK and assumed it would.
The post How Functional Programming Shaped (and Twisted) Frontend Development from four days ago provides great broader context about the history and concerns. It ends with what this post seems to primarily concern itself with: The alternatives, improvements, innovation, and opportunities we may be missing / should evaluate.