3 ms·

Is this, like, a real thing that exists or just a blog post about a thing that should exist? I can't tell.

by paultopia 5y ago

georgyo 5y ago
Doesn't look to be real to me: https://github.com/dahosek/finl https://github.com/dahosek/finl
dhosek 5y ago
It's real, but at very early stages. I wouldn't have posted the link yet myself.
- skywal_l 5y ago
  "finl is not attempting to replicate TeX and LaTeX but to reimagine and replace it. It’s more like Java vs C++" So what will it be: Java or C++. No,... don't answer... Joke aside, LaTeX was a pain to use 20 years ago and still is, so good luck on your endeavor !
  - dhosek 5y ago
    The idea being that much as Java relieves some of the pain of writing object oriented code in C++, finl relieves some of the pain of writing documents in LaTeX. It helps, of course, to have a deep understanding of TeX and LaTeX in doing so. Looking at sile, for example, on my initial look, it seems that the creators didn't fully understand LaTeX or what makes LaTeX worth re-imagining. At the risk of being insulting, it kind of feels less like C++ to Java and more like Perl to PHP, where the creators of PHP were clearly influenced by Perl, but didn't understand why Perl works the way it does.
salamanderman 5y ago
From the blog posts, it looks like they were still deciding what language to write this idea in.
- dhosek 5y ago
  I've decided on Rust. I'm in the midst of a "short story" exploration of Rust and PDF typesetting with a replacement for gftodvi (gftopdf) which, while it will have a potential userbase in the high single digits, gives me a low-risk way to experiment with typesetting to PDF. One of the sub libraries of finl (the charsub module) will be part of this code in the 1.0 release and potentially other sub libraries will be incorporated as development continues.
  - jamincan 5y ago
    Out of curiousity, did you look at nom at all for parsing?
    - dhosek 5y ago
      I have a bit. I really want to avoid writing code as much as possible. The flip side is that I've noticed that a lot of people in the Rust community are too quick to reach for a library. For gftopdf, I had someone suggest that I use nom to parse the GF byte code, but there's enough impedance mismatch and missing functionality (I don't know that 24-bit integers exist outside of Knuthian binary formats) and the functionality was simple enough (four short functions to read values of u8, u16, u24 and i32 into an i32 container, plus a read a string with a 1–3 byte length parameter at the beginning) that it didn't seem appropriate to have the overhead of an external dependency. On the flip side, I was more than happy to use anyhow, thiserror and structopt for their functionality. I suspect though, given how input will get tokenized, though, that I may not be able to use a generic library.

Is this, like, a real thing that exists or just a blog post about a thing that should exist? I can't tell.

georgyo 5y ago

Doesn't look to be real to me: https://github.com/dahosek/finl https://github.com/dahosek/finl

dhosek 5y ago

It's real, but at very early stages. I wouldn't have posted the link yet myself.

skywal_l 5y ago
"finl is not attempting to replicate TeX and LaTeX but to reimagine and replace it. It’s more like Java vs C++" So what will it be: Java or C++. No,... don't answer... Joke aside, LaTeX was a pain to use 20 years ago and still is, so good luck on your endeavor !
- dhosek 5y ago
  The idea being that much as Java relieves some of the pain of writing object oriented code in C++, finl relieves some of the pain of writing documents in LaTeX. It helps, of course, to have a deep understanding of TeX and LaTeX in doing so. Looking at sile, for example, on my initial look, it seems that the creators didn't fully understand LaTeX or what makes LaTeX worth re-imagining. At the risk of being insulting, it kind of feels less like C++ to Java and more like Perl to PHP, where the creators of PHP were clearly influenced by Perl, but didn't understand why Perl works the way it does.

salamanderman 5y ago

From the blog posts, it looks like they were still deciding what language to write this idea in.

dhosek 5y ago
I've decided on Rust. I'm in the midst of a "short story" exploration of Rust and PDF typesetting with a replacement for gftodvi (gftopdf) which, while it will have a potential userbase in the high single digits, gives me a low-risk way to experiment with typesetting to PDF. One of the sub libraries of finl (the charsub module) will be part of this code in the 1.0 release and potentially other sub libraries will be incorporated as development continues.
- jamincan 5y ago
  Out of curiousity, did you look at nom at all for parsing?
  - dhosek 5y ago
    I have a bit. I really want to avoid writing code as much as possible. The flip side is that I've noticed that a lot of people in the Rust community are too quick to reach for a library. For gftopdf, I had someone suggest that I use nom to parse the GF byte code, but there's enough impedance mismatch and missing functionality (I don't know that 24-bit integers exist outside of Knuthian binary formats) and the functionality was simple enough (four short functions to read values of u8, u16, u24 and i32 into an i32 container, plus a read a string with a 1–3 byte length parameter at the beginning) that it didn't seem appropriate to have the overhead of an external dependency. On the flip side, I was more than happy to use anyhow, thiserror and structopt for their functionality. I suspect though, given how input will get tokenized, though, that I may not be able to use a generic library.