dmbaturin

Delegating the complexity to the user was my biggest motivation behind many features of soupault.

Hugo has two different Markdown libraries baked in and you have to choose them, and it also had hardcoded commands to call rST and AsciiDoc processors. If you are migrating from a different SSG, Markdown processors behavior differences can bite you and there's no way out.

With soupault, you just configure a command to convert a file with a certain extension to HTML, and all features (ToC, footnotes, anything provided by plugins...) work the same because they they are implemented by manipulating the parsed HTML element tree.

Want a CSS preprocessor? You can pipe <style> tag contents through any external program if you feel like it. Want to re-compress or manipulate images? You can write a Lua script that gets their paths from <img> and <picture> tags and calls an external program on their files. And so on.

I was wondering if that part should have been the main page slogan: "Soupault’s DOM manipulation is as powerful as client-side JavaScript (without interactivity, of course), but the result is a static page."

>Maybe this table of comparisons should go on the landing page

The elephant in the room is that none of the popular tools' websites make any sense to people who aren't already familiar with that class of tools. I happened to accidentally come up with a tool that's too unlike anything else to be easy to explain by "it's like {alreadyPopularTool} but with {importantDifference}".

I also hope that people from the Web 1.0 revivalist circles who hate typical SSGs for their hostility to handwritten HTML on board, although that development was ironic: the reason I included the HTML post-processor mode was to help those folks inject consistent navigation into otherwise handwritten pages or similar — in reality they just told me they were _proud_ of wasting their time on that completely automatable task, but the post-processor mode was a surprise hit with people who wanted to fix up outputs of inflexible HTML generators.

The comparison table is not very helpful for people who might not have seen an SSG before, placing it on the main page might create a confrontational tone (because it's focused on things that soupault made possible compared to other tools), and I'd have to constantly watch those projects to see if anything is no longer true.

For example, it would be pretty easy to allow Hugo call AsciiDoc and other external processes with custom CLI options — I'm sure someone will eventually do it and it will be a big improvement for those who want to use Hugo.

For soupault, library availability was actually a key factor: lambdasoup [1] is one of the best HTML parsing libraries if you want to automatically edit element trees, not just extract data from them.

The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design.

My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use.

Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own.

It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`).

Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility.

The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.

[1] https://github.com/aantron/lambdasoup

[2] https://github.com/dmbaturin/otoml

[3] https://github.com/lindig/lua-ml

[4] https://github.com/dmbaturin/ocaml-tsort

The key idea of soupault is that it works on the HTML element tree level and can automatically call external convertors on pages (based on page file extensions, see [1]), so the input format doesn't matter to it.

You can bring your own convertors and pass any options to them. I'm not saying it's a perfect SSG for everyone, but at least uncommon input format support isn't an intractable problem for it.

[1] https://github.com/dmbaturin/soupault-website/blob/master/so...

There's a users page (https://soupault.app/users/), most come with source code links.

ocamlbook.org may be the most illustrative one: it exploits soupault's ability to pipe HTML element content through an external program to automatically type-check code examples in <code> tags with the compiler and also syntax-highlight them with an external tool. The approach would translate to any language without a need for language-specific tools.

I'm glad someone recognized the CHIM reference, but I'm surprised that the entry for AASR (Ancient and Accepted Scottish Rite) hasn't caught anyone's eye as being just as out of place. :)

I'm a bit confused by its pictures. It has a scroll wheel, right? How's the build-in wrist pad? I'm still using a Kensington Expert Mouse.

Anyone tried those vertical mice? To me it looks like a pointing device for people with RSI rather than something one may choose for better usability whether they have RSI or not. I was introduced to trackballs by a friend who has RSI, and I loved them, even though I don't have any wrist issues.

I'm not against the REPL (perhaps I should even describe its usage in more detail). In fact, I use it all the time. I'm against books like Learn You A Haskell that leave the reader wondering how to make and distribute executable programs. Or, worse, create an impression that it is not even possible, if the reader is not motivated enough to read another book or blog posts.

I haven't used gRPC as such, but for protobuf specifically, ocaml-protoc works well for me.

This would work:

   let _ = 
     let this_integer = read_int () in
     print_int (this_integer * this_integer); print_newline ()

I agree part 1 should explain more of the basic syntax. The whole thing is a work in progress so I keep improving it as I get feedback.

It will appear when (and I hope it's when rather than if) I complete the series. Then I'll typeset it properly and release the source under CC-BY-SA or another free license and make PDFs from it.

Do you have a (more or less) formal description of the type system?

OCaml has separate compilation, a REPL, and it's very fast. None of those things is incompatible with global type inference (although particular type systems can be).

Some languages, like ML family or Haskell, make it an organic part of the language, so beginners doesn't need to worry about the concept to use it.

When first exposed to ML/Haskell code, they may use simple mental models such as "you write function arguments without parens and commas" and "the last type in foo -> bar -> baz is the return type". Then it gets replaced with realization that "oh, so 'let f x y = x + y' is just a sugar for 'let f = fun x -> fun y -> x + y'".

If one is learning the concept in a language that supports functions of multiple arguments and uses something else than currying for built-in partial application mechanism, I can imagine them having problems with it. Learning how familiar things works internally is usually easier than learning "this is what you can do and why you may want it".