Their website is a slide-show demonstrating their amazing work:
Generating servers from state machines and such:
SMT kernel for portable, multi-threaded, fast code:
Web server (old and new)
One of best middleware ever
An internal, interpreted DSL can be written to do similar, but I think the point of this tool is to ease the process of writing the DSL itself, and to make the resulting runtime efficient.
I'll miss him. (sighs) Wrote that here in case he sees the higher ranked article. He said he didn't want negativity. ;)
tldr; Define a model in xml, and a provide it a template script and it'll output some text.
Sound like XSLT? yep. With a custom DSL taped on the side for scripting.
Template-driven code generators that use symbolic insertion to inject
meta- data into a template. This technology makes it much easier to
write new ad-hoc templates. Typical examples are any technology that
produces dynamic web page.
Scripted code generators that use a high-level language to manipulate
meta- data and then inject it into templates. This technology makes it
much easier to write new ad-hoc code generators. Typical examples are
XSLT, GSL and some other scripted code generation languages.
Lots of template engines support the ability to manipulate the data before injecting it into a template.
Having a special limited little DSL for scripting that is an antipattern, not a good thing.
Lots of people use translation tools (coffee script, typescript, babel, sass, etc) that map from one language to another 'similar' language, even code, and it works well.
I think we can comfortably say that these days, people are pretty happy with the idea of code generation; ...but I think few people will find anything in GSL that is not covered elsewhere, better.
Perhaps there's some use for this sort of stuff in protocol serialization, but you have to do so much of the heavy lifting yourself for it, I'm not sure why you'd bother over an existing solution like protocol buffers.
Note: I used XML and XSLT back then when they first came out. I had to write custom tech in Perl, etc to get them to work and speed was not in the description. While they were garbage, his methods produced Xitami web server that kicked all kinds of butt. Too bad he switched to XML-based tech as that was my only gripe with it.
As I understand it, you do it by hand.
For context, protocol buffers did not exist when GSL was devised in 1995 (3 years before google was founded). So in fact GSL _was_ the existing solution when google came up with protocol buffers.
Given GSL is still going strong 21 years after inception is a pretty solid testament to its utility.
No one is denying this is a tool, a useful one at that... Im just not sure why you use it now, given the alternatives that do now exist.
I just installed it yesterday so haven't been able to fully suss out how I will use it.
Hintjens also wrote the CLASS style guide/ subset of C usage which is used for ZeroMQ etc. I don't program in C, thus, can't offer an informed opinion about it - but perhaps another HN'er can chime in on the quality of it.
For example, "GSL is likely a good choice at <abstract problem description>, such as <some very concrete examples>. And it may not be appropriate for <abstract problem description>, such as <other concrete examples>. Because of <some specific reasons>."
I looked through the GSL website and also Scalable C and wasn't able to find any descriptions that place limits on the applications of GSL. A description of what a complex something isn't, from an expert, is almost as important as what that thing is.
Your writing style in Scalable C is incredible and enlightening. I will be studying and referencing that book, even if I'm not directly coding C.