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.

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".