I wish I had known about cog some 14 years ago when I implemented exactly the same thing (https://github.com/ot/inpytex).

It was made for LaTeX files but could have worked with anything. It even uses the same checksum protection!

I wonder how many people independently came up with the same idea.

I think the closest "standard" tool for this is m4, which doesn't seem powerful enough for most applications.

Lips seems similar, but for Lisp/Scheme (e.g. https://github.com/zc1036/lips https://github.com/rbryan/guile-lips )

I’m disappointed by the HN crowd in this thread. Almost nothing brought up as a “similar tool” to Cog actually does what Cog does. Except ‘ot’ who gets it because they actually implemented something similar. I guess this is evidence of Cog’s uniqueness.

My immediate thoughts:

• PHP, the poster example for template-based languages, seems to have spent all its recent years in development trying to get away from its HTML templating roots. I basically never see a PHP file in the wild which is using the old style with mostly HTML with sprinkles of PHP; it’s almost all pure PHP.

• Python has a perfectly good templating system in Jinja2, used by Flask and many others. Last I looked, even Django seemed to imply that they’d themselves would rather be using Jinja2 than Django’s own templating language. IIRC, Django even natively supports replacing its templating engine with Jinja2.

• For small-ish templates embedded inline in code, Python now has f-strings.

Therefore, I wonder: In what situation, exactly, would Cog, a PHP-style inline code templating system, be better than Jinja2 and/or f-strings? And would this benefit be worth the added cost of having yet another model of abstractions which few people would be familiar with?

Cog works line-by-line, which sidesteps thorny quoting concerns, and makes it applicable to more syntaxes. It lets you use regular Python code instead of "html-ified" code in Jinja (for example).

Certainly if you are happy with Jinja, you should use it.

Yes, I mean, I can understand how it works technically. But in what situations is something like Cog so beneficial that it offsets using something more well-known like Jinja? Are these situations common?

Have you looked at TFA? there are some tweet messages of people using it

By focusing on the templating aspect i think you completely missed what cog does and what makes it valuable: cog is an in-place repeatable generator.

You don’t output to a separate location, the output is embedded right after the generator itself, and if the inputs have not changed re-running cog is a no-op.

Cog’s “templating” is a mean, not an end, and in the interest of providing maximal flexibility it’s no templating at all but straight python code procedurally generating an output.

You haven’t taken the time to understand what Cog does. It’s not equivalent to a tempting engine like Jinja or PHP… or f-strings.

I also immediately thought "why is this not jinja?", but then I realized that jinja cannot do what cog can: run arbitrary Python code. Yes, jinja includes a small subset of python things as filters, but jinja on purpose does not include arbitrary code.

Typical jinja use is you have a controller or some outside code like Ansible that creates objects for jinja to operate on.

Cog is less like PHP templating, or jinja, and more like a standalone jupyter static text generator.

Looking at this reminds me strongly of texthon, but with a less attractive syntax. A quick skim through the source appears to show a similar use of eval.

Too bad texthon is essentially unknown and unmaintained, as far as I know. I worked on a project with it for several years and it always worked really well and was much more pleasant to use than something like jinja. Maybe I need to make a modern fork…

Anyway, anyone interested in cog should check it out as well.

Texthon seems like a bog-standard templating langage, nothing to do with cog but in the barest most remote commonalities of executing code to output text.

You’re right, I realize now that cog doesn’t process an input template but the actual output file, modifying it in place. Perhaps that why it took so long to gain popularity: that fact seems somewhat non-obvious from the documentation. Even the examples on a cursory glance are not obviously not templates. At least to me.

Re-reading the docs I realize that sure enough, they say very clearly what it does. But I think it just doesn’t click immediately.

Now that get it, I have a few problems coming to mind that I can solve with cog that I didn’t have a great solution to before. So I’m jumping on the bandwagon.

I both like and dislike the "immediate inline" nature. I guess it depends on what you're using it for. It's great when the output is small, but I just imagine folks using it to generate enourmous classes or such inline, forcing programers to scroll through all of that, as well as giving false signals when searching code.

Like any tool, you need to use it well or it will be a foot gun.

Might be a good instance to use folding markers for your editor.

Similar: https://sustrik.github.io/ribosome

That doesn’t seem similar to Cog, in that it doesn’t maintain the templating code in the output.

Oh whoops, I didn't realize that was one of the important aspects of Cog.

This is possibly worse than the C preprocessor.

s/worse/different/

Have you tried to understand what cog does? It's a completely different use than the C preprocessor.

In a way, if you only consider the C preprocessor as part of the C compilation pipeline (rather than as a separate tool), there are at least similarities.

Much more so than e.g. php or jinja comparisons anyway.