Why I Write on eiffel.org Blogs
Finnian Reilly
Why I Write on eiffel.org Blogs
I've been writing on eiffel.org's blog platform for a long time, and recently it's become even easier. Here's why it remains my preferred place to publish technical content.
You can revise in response to discussion. A blog post is a living document. When someone comments and raises a point I hadn't considered, or spots an error, I can update the article there and then. The post improves over time rather than accumulating a trail of corrections buried in replies.
It maintains a full revision history. Every version of a post is preserved, and you can compare revisions to see exactly what changed and when. That's a level of transparency and accountability you rarely get from informal publishing platforms.
AI tools take the tedium out of formatting. Wikitext markup has always been a chore — wrangling table syntax, remembering the right incantation for links and headings. Writing in a modern editor and letting AI handle the structural formatting means I can focus on the actual content rather than fighting the markup language.
You get a table of contents for free. For longer technical articles this matters more than it might seem. Readers can orient themselves immediately, jump to the section they need, and get a sense of the scope before diving in. It makes the difference between an article that feels navigable and one that feels like a wall of text.
Syntax highlighting just works. Code fragments for Eiffel and a wide range of other languages are rendered with proper highlighting out of the box. Given that most of what I write involves code, this is not a minor convenience — it's essential for readability.
It's more public-facing. A blog post on eiffel.org is more likely to surface for developers who are simply searching for a technical solution and happen to encounter Eiffel for the first time. That kind of casual discovery matters for a language community.
Tags make content discoverable. Being able to tag articles by topic means related content aggregates naturally. Someone exploring class design, tooling, or a specific library can find a body of relevant writing rather than having to know what to search for.
It's owned by the community, not Google. The eiffel.org platform is community-owned infrastructure, which means the content stays where the community can govern it, rather than living at the pleasure of a third-party host. That's a meaningful difference in the long run.
You retain a local copy. The source for each post lives on your own machine, which means you're never entirely dependent on the platform. Your work is backed up by default, portable if you ever need it elsewhere, and yours in a way that a purely web-based editor doesn't quite guarantee.
Alejandro Garcia
https://elviejo79.github.io
Too brief? Here's why! https://www.emailcharter.info
EOM – End Of Message. The whole message is in the subject don't need to open it.
NNTR – No Need To Respond. Help cut down on all those “cool” and “thanks” emails.
SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
CLEAR CALL TO ACTION: Ask for some specific result very clearly.
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/0be99e47-d304-4f38-a299-fe7184c7d2c7n%40googlegroups.com.
