Are you seriously suggesting an encyclopedia should be packed with crackpot conspiracy theories, academic charlatanry, quackery, and agitprop? Or does that not defeat the point? Keep the author's biography, but his "theories" are best left for a footnote in the biography, or websites that explicitly serve as a museum for failed ideas.
I've produced a staggering variety of documents with Typst. Books, booklets, slides, cards, documentation, everything. In most cases I only need a minimum of custom styles and behaviors at the top, and very occasionally a whole styling module. Blows the rest of these tools out of the water full stop.
If you use Nim, it's value semantics by default. Everything (and I do mean everything, all types primitive to composite) is managed by the stack, including stuff that needs to hold a heap pointer. All lifetimes are scoped. You only get ref counted types when you opt in.
It's astoundingly easy to build software with that behavior set. Even if the occasional copy is necessary, you're paying a far lower cost for it than for an interpreted language. Slice off a couple important components into stateless executables built like this, and it's clean sailing.
My prolific Typst use, along with quickly improving side-by-side editors like Typesetter, are rapidly diminishing (in my eyes) the reasons for WYSIWYG to be. Sure, normies need it, yadda yadda. Is it worth the staggering cost? The file format and GUI complexity?
I really wish the FreeCiv team would focus on their SDL build instead of all these fiddly and very fickle UI toolkits. They have an incredibly cool hex-based hybridized Civ 2/3 ruleset that might be the best of all worlds, IF it could actually start consistently on all systems. Drop GTK and Qt, clean it up, add some modern quality of life keybinds and UI info, make it the universal target.
Speaking from personal experience, Godot has the sneakiest potential. It has all the UI components and flexible layout containers you could ask for, a signaling system that lets you put the methods from less relevant components in the scripts for more relevant ones (making for a more compact project), and you can also manually compile slim template builds for cleaner distribution. There's a future there.
The greatest failing of modernity is its refusal to accept an uncomfortable reality uncovered by biology and psychology: That certain strongly negative personality traits are built-in pathologies which nature tries out to explore what is possible. The neural pattern that is "Trevor Milton" is not him without those intensely compulsive lying behaviors.
The social taboos of cultures around the world are fighting a ceaseless battle to reign in these endemic outliers.
This resonates as true, as long as the fundamentals of your tools are there. Picking interpreted languages or browsers as targets shoots you in the foot and sets you magnitudes behind when performance starts to matter. But if you're using a native-compiled language with value- and move-semantics, immutable data, and a composable type system, it's shocking how easy it can be to write obvious, maintainable, fast programs that perform under pressure, even when you're not being clever.
Thankfully newer languages like Nim, Odin, and Swift lean hard into value semantics. They drastically reduce the cost of focusing on data structures and writing obvious algorithms. Then, when bottlenecks appear, you can choose to opt into fine-tuning.
More generally: LLM effectiveness is inversely proportional to domain specificity. They are very good at producing the average, but completely stumble at the tails. Highly particular brownfield optimization falls into the tails.
Side-by-side, it's incredibly clear that the newest version is total UX garbage. Monochrome icons were a complete mistake, in basically all cases everywhere. A mix of the Lion color, shape/texture, and spacing, plus the Catalina sidebar, would be the best.
I really REALLY love the Lion icons. Colorful but subdued with only mild saturation, distinctive shapes, strong line borders with very slight halo, and mild gradients to make them pop.
I've recently made a dozen vastly different projects with Typst, ALL of which would have created dependency hell, syntax noise, and hours of extra pointless work in Latex. It's such a clear win at this point it's embarrassing.
I bounced off of Objective-C not because of its message-passing OO. That was the actual cool part. I bounced off because of the insane amount of boilerplate prototyping and headers required to use it.
I think every OO language should be using Smalltalk's message-passing style rather than holding hard references, and Objective-C is a great model. But discard the rest.
True beauty. Wow. My only ask would be optional type annotations for function and type parameters, so it's easy to fully describe your interfaces in code.
Major syntactic structures definitely have an influence on my language choices. Outside of compilation and runtime model, modeling the domain (both data and procedures) changes drastically between paradigms. Syntax is what enables or hamstrings different modeling paradigms.
My two biggest considerations when picking a language are:
- How well does it support value semantics? (Can I pass data around as data and know that it is owned by the declaring scope, or am I chained to references, potential nulls, and mutable handles with lifetimes I must consider? Can I write expression-oriented code?)
- How well does it support linear pipelining for immutable values? (If I want to take advantage of value semantics, there needs to be a way to express a series of computations on a piece of data in-order, with no strange exceptions because one procedure or another is a compiler-magic symbol that can't be mapped, reduced, filtered, etc. In other words, piping operators or Universal Function Call Syntax.)
I lean on value semantics, expression-oriented code, and pipelining to express lots of complex computations in a readable and maintainable manner, and if a language shoots me in the foot there, it's demoralizing.
Same. Not only has using it been no trouble, but having a barebones core app selection, a few picks from F-Droid, and using the browser for the rest makes my phone feel refreshingly under my control. It lasts for 3-4 days of low usage to boot, when nothing is phoning home constantly.
Colossally awful take. Corruption is an intractable problem in human history. Power is a magnet for the worst people, and every system we invent can be exploited in innumerable ways. The only variable is how long the people of any individual society can remain free and prosperous before their decline. Temporary recoveries have only happened by lopping off massive chunks of empire, implementing extreme monetary reforms, and/or a switch to full autocracy. Every other outcome is terminal decline.
The feature list here has significant overlap with Nim. Maybe we need a website that categorizes languages with feature tags, so we can visualize the overlap!
I've been statically linking Nim binaries with musl. It's fantastic. Relatively easy to set up (just a few compiler flags and the musl toolchain), and I get an optimized binary that is indistinguishable from any other static C Linux binary. It runs on any machine we throw it at. For a newer-generation systems language, that is a massive selling point.
Nim has a similar, strong preference for value semantics. However, its dynamic heap types (strings, seqs, tables) are all implemented as wrappers that hide the internal references and behave with value semantics by default, unless explicitly escape hatched. It makes it incredibly easy to manipulate almost any data in a functional, expression-oriented manner, while preserving the speed and efficiency of being backed by a doubling array-list.
What @cheeseomlit said, plus: During the Age of Exploration/Colonization, competing European powers each minted metal currencies and couldn't reasonably debase their metals without immediately being out-competed (which is why the trusted purity of Spanish gold and silver coinage slowly dominated). The primary mode of failure for those empires was bankruptcy via war. The impossibly high cost of fielding armies around the globe was laid bare during that era. Paper money lets us (funnily enough) paper those costs over and live with the illusion that it's all a free lunch. But what we're actually doing today is debasement, and eating, vociferously, all of the deflationary efficiency gains won by 20th century technological progress.
There are also many Americans who have always desired de-dollarization, since the dollar has been the foundation of our imperial system and abuses of state power. Say what you will about how dated a gold standard is, but it forces immediate fiscal responsibility upon governments; fiat currencies defer responsibility, turning it into a Sword of Damocles that catastrophically falls upon future generations. You trade geopolitical dominance now for guaranteed future withering. Of course, fiscal responsibility and the rejection of imperial ambition were core principles of the Anti-Federalists, Democratic-Republicans, and Whigs. It's baked into our history and tradition to not want to be the unilateral arbiters of a global trade and alliance system.
I was surprised that for most of my smaller use cases, Zepto.js was a drop-in replacement that worked well. I do need to try the jQuery slim builds, I've never explored that.
The real question at the core of any production: What's the minimum performance cost we can pay for abstractions that substantially boost development efficiency and maintainability? Just like in other engineering fields, the product tuned to yield the absolute maximum possible value in one attribute makes crippling sacrifices along other axes.
I've used JSON as an additional options input to a native-compiled CLI program's various commands because 1) the schema of each option is radically different, 2) they need to be passed most of the way down the call stack easily for each stage of our calculation and report generation.
It works fantastically well, and don't let anyone tell you that you MUST bloat the CLI interface of your program with every possible dial or lever it contains. We should all be cogent of the fact that, in this very young and rapidly evolving profession, textbook and real-world best practice often do not overlap, and are converging and diverging all the time.
And so the size of your data structures matters. I'm processing lots of data frames, but each represents a few dozen kilobytes and, in the worst case, a large composite of data might add up to a couple dozen megabytes. It's running on a server with tons processing and memory to spare. I could force my worst case copying scenario in parallel on each core, and our bottleneck would still be the database hits before it all starts.
It's a tradeoff I am more than willing to take, if it means the processing semantics are basically straight out of the textbook with no extra memory-semantic noise. That textbook clarity is very important to my company's business, more than saving the server a couple hundred milliseconds on a 1-second process that does not have the request volume to justify the savings.