Hello Everyone Out There Using LaTeX -

Cristiano Lacerda — Sun, 29 Sep 2024 02:39:44 +0000

An Audacious Plan for the Future of Document Processing

This is kind of an answer to @hoffmann on lets find something better then latex.

LaTeX was revolutionary, for its time. It empowered generations to create beautifully typeset documents. But the '90s are over, and so is the era of paper and tools that slow you down. It’s time for a 21st century document processing system that keeps the best of LaTeX and ditches the rest. Here’s how to build something better:

1. Stand on the Shoulders of Giants

We're leveraging the proven power of Pandoc, SQLite, and GNU AutoGen. Together, they form a solid foundation that handles all the heavy lifting involved in parsing, semantic analysis, and synthesis. These are all performant, robust, widely used tools with some of finest pedigree on open-source. It is not about reinventing the wheel, we are just about to break it.

2. A Compiler for Documents

LaTeX showed the world that compiling isn't just for code but for documents too. We're definitely keeping that. Think of DocLiteGen as a compiler:

Parsing: Pandoc parses your Markdown (or any format) into an Abstract Syntax Tree (AST), giving your textual elements and floating objects structure, organized into nodes that can be easily and meaningfully traversed.
Semantic Analysis: SQLite handles the semantic analysis, just like an attribute grammar, controlling how each node interacts to inherit and synthesize attributes across the AST.
Synthesis: AutoGen gracefully inserts generated content, like dynamic numbering, tables of contents, or entire sections back into the AST before Pandoc takes over again to produce the target format.

3. Hybrid Publishing

In today's world, the web is the default. Your documents need to be easily accessible in a browser, richly linked, and beautifully rendered as static sites with intuitive and predictable URLs. But sometimes, you still need to print, and when that happens, it has to be pixel-perfect.

Web and Print Harmony: We keep the very best of LaTeX, mostly TeX, so you can still enjoy paper print outputs that uses your favorite classes.
Multiple Formats, No Compromises: Need to collaborate with the office crowd or create e-reader-friendly documents? DocLiteGen handles it all from a single source.

4. Built for LSP Integration

This is document authoring at it's finest. Forget the days of cryptic errors and waiting ages for LaTeX to compile just to find out a reference was wrong. With DocLiteGen, you get:

Real-Time Feedback: Autocomplete your intentions, lint your style, jump to references, and get diagnostics flagged as you write.
Modern Editing Experience: You're not just writing; you’re programming your document with the support of an assistant that provides semantically meaningful, context-aware help.

5. Extensibility is Key

Much like LaTeX's core distribution—a basic collection of packages and macros extended by millions to meet all kinds of document needs—DocLiteGen operates on the same philosophy of extensibility.

DocLiteGen comes with the basic compiler infrastructure that puts everything together, along with a collection of Lua filters, SQL queries, and templates that cover most of what the core LaTeX offers, updated for the modern age. You shall extend it to cover any need:

Need a new syntax or to change how an element is parsed? Write a Lua filter.
Want to give it semantic meaning and interact with the rest of the document? Write an SQL query.
Need to control how it looks? Write a template.
Want editor integration? Some JavaScript wizardry will do.

That's it. Extend the system to do anything you imagine, while keeping things maintainable and collaborating with the community.

6. Database Publishing

The power of DocLiteGen lies in its ability to manage document elements at a granular level with associated relations and metadata. This allows:

Custom Views: Create versions of your document without certain sections, or filter content created after a specific date or by a specific author. SQL lets you query your document's structure and content in ways LaTeX could never dream of.
Work like a CMS Systems: Enjoy the flexibility of database-driven publishing, complex reporting and advanced search, including full-text, making documents come alive easily, all from flat text files.

7. DevOps for Docs

It's the automation century:

Cloud Native: Ship your documents straight to and from the cloud. Build them into your CI/CD pipeline. After you push a change to the repository, you can trigger actions to publish to the web, send it straight to the office printer or email the docx to your dinosaurs colegues.
Docs-as-Code: Version control, collaboration, deployment, all the DevOps goodness applies. Generate, test, and deploy your documents just like you would with software code.

8. Build It, Profit, Change the World

This is the blueprint for the future of electronic publishing. Go build it, make a SaaS and profit - or release it into the wild, open-source, and watch it change the world one document at a time. The choice is yours.

Are you ready to start this revolution? Because if this doesn't kill LaTeX, nothing will.

Continuous Delivery Is Killing Software Quality

Cristiano Lacerda — Sun, 11 Aug 2024 00:18:43 +0000

The recent disaster at CrowdStrike is just the latest symptom of a much larger illness plaguing the software industry: continuous delivery is killing software quality. Agility, when applied correctly, is a powerful force in software development. However, the relentless pursuit of rapid and frequent releases has led to a situation where quality is sacrificed in the name of speed. It's as if the whole software industry has turned into a fast-food factory, where delivering software fast is more important than making software that is good.

Remember the golden age of gaming? When a game was released, it was printed on a cartridge or burned onto a DVD. There was no turning back, no patches, no hotfixes. If your game was full of bugs or incomplete, it was a financial disaster. The pressure to deliver the best possible product was immense. The result? Games were usually impeccable.

Fast forward to today, and we find ourselves in the era of "early access" releases. Games, and increasingly other software, are launched unfinished with the promise of "fixing it later." Continuous delivery has become the perfect excuse for shoddy work. We are literally telling our customers, "Don't worry that your product isn't ready now; we'll finish it eventually."

This mentality is spreading like wildfire. It's not just games anymore. Critical infrastructure, financial systems, even medical devices and transport infrastructure are being subjected to this reckless approach. The CrowdStrike incident is a harsh reminder that when software fails, the consequences can be catastrophic.

We need to return to the principle of formal releases. Software should only be launched after rigorous processes that validate real-world usage in controlled environments. The idea of putting software that is just done, after passing some pipeline of tests, into production is crazy dangerously. While automated tests are crucial for ensuring code quality, they are complete meaningless for validating the overall system correctness and reliability.

We can learn a lot from other engineering fields. Take civil engineering, for example. When a bridge is built, no one would open it to the public traffic before it is fully completed and has undergone rigorous safety tests. In Brazil, the ART (Technical Responsibility Annotation) requires engineers to sign off on their projects, assuming full responsibility for their execution. A mistake, caused by lack of skill or negligence, can have severe criminal implications. Why should we expect any less from software, which is increasingly becoming a vital component of our lives?

We know it is possible to create safety critical software that works correctly. This happens when the responsible organizations are motivated not by economic forces, but by significant regulatory pressure. The problem is that as software continues to "eat the world," more and more critical systems are being developed by industries that face no regulatory pressure.

We can therefore expect things to go very wrong, and a major disaster involving the loss of many lives is a question of "when," not "if." Perhaps then developers will stop treating their work as a perpetual beta and start treating it as the critical component of our lives that it truly is.

DEV Community: Cristiano Lacerda