What I love the most about this, is that even though the author only intended (in the near-term, anyway) to use this once, they still A) took care to use some degree of engineering practice, and B) open-sourced the result.
I really love seeing an example of DTP-style typesetting using Java. It's one of those problems that seems really easy, but then you look into it a little bit and decide it's not really worth the effort (and there aren't many practical, independent examples of it in practice). This person not only took the effort – to make something more personally pleasing than TeX – but also took the time to organize their code and share it, in order to decrease the scarcity of such examples.
That is an incredible story of successful yak shaving. I have the same experience, but ultimately my attempts end in failure as I lose interest and sight of the end goal. Kudos!
The author of the piece here has something to say about that, too: write code top-down.
> There are two ways to architect a program and write code: top-down and bottom-up.¶ […] The correct way to architect and write a program is top-down. This is not a matter of taste or preference. Bottom-up design is fundamentally busted and you shouldn’t use it. Every system I’ve been involved in that used top-down succeeded and those that used bottom-up failed. [...]
> At every level there’s pressure to do bottom-up programming. Avoid it. Instead, start at the top, with `main()` or its equivalent, and write it as if you had all the parts already written. Get that to look right. Stub out or hard-code the parts until you can get it to compile and run. Then slowly move your way down, keeping everything as brutally simple as you can. Don’t write a line of code that isn’t solving a problem you have *right now*. Then you may have a chance of succeeding in writing a large, working, long-lived program.
I found "Java for Everything" really interesting, so thanks for posting it. It also seems it's been featured on HN many times[1], and the progression of comments (from 10 years ago to 4 years ago, to 1 year ago where nobody commented) feel like an archaeological strata that shows how things change and how they stay the same.
FWIW, while I'm not sure I agree that JVM is the right solution for every problem, I agree with much of the author's sentiment from that time, which is: programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns.
> programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns.
Taking this to its logical conclusion all programs should be written in assembly.
The reality is that there's a tradeoff: Programmer time vs performance, and which parts of performance matter. I've worked using anything with performance from assembly to shell scripts (including C, C++ and Java). It is all tradeoffs. Do users want more features, or more speed? Are we running at a scale or situation where ultimate usage of hardware matters, or not?
Saying we should do ultimate amounts of investment in performance when there's three users and one programmer doesn't make sense. They'd typically rather have more features and adequate performance.
What I love the most about this, is that even though the author only intended (in the near-term, anyway) to use this once, they still A) took care to use some degree of engineering practice, and B) open-sourced the result.
I really love seeing an example of DTP-style typesetting using Java. It's one of those problems that seems really easy, but then you look into it a little bit and decide it's not really worth the effort (and there aren't many practical, independent examples of it in practice). This person not only took the effort – to make something more personally pleasing than TeX – but also took the time to organize their code and share it, in order to decrease the scarcity of such examples.
Kudos.
shortcut to the repo https://github.com/lkesteloot/teamten-typeset
That is an incredible story of successful yak shaving. I have the same experience, but ultimately my attempts end in failure as I lose interest and sight of the end goal. Kudos!
The author of the piece here has something to say about that, too: write code top-down.
> There are two ways to architect a program and write code: top-down and bottom-up.¶ […] The correct way to architect and write a program is top-down. This is not a matter of taste or preference. Bottom-up design is fundamentally busted and you shouldn’t use it. Every system I’ve been involved in that used top-down succeeded and those that used bottom-up failed. [...]
> At every level there’s pressure to do bottom-up programming. Avoid it. Instead, start at the top, with `main()` or its equivalent, and write it as if you had all the parts already written. Get that to look right. Stub out or hard-code the parts until you can get it to compile and run. Then slowly move your way down, keeping everything as brutally simple as you can. Don’t write a line of code that isn’t solving a problem you have *right now*. Then you may have a chance of succeeding in writing a large, working, long-lived program.
<https://www.teamten.com/lawrence/programming/write-code-top-...>
See also: Java for Everything <https://www.teamten.com/lawrence/writings/java-for-everythin...>
I found "Java for Everything" really interesting, so thanks for posting it. It also seems it's been featured on HN many times[1], and the progression of comments (from 10 years ago to 4 years ago, to 1 year ago where nobody commented) feel like an archaeological strata that shows how things change and how they stay the same.
[1] https://hn.algolia.com/?q=java+for+everything (just searching for the URL doesn't work, because it started as http and changed to https 5 years ago)
FWIW, while I'm not sure I agree that JVM is the right solution for every problem, I agree with much of the author's sentiment from that time, which is: programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns.
> programs are written much less frequently than they are run, so surely developer keystrokes are laughably unimportant compared to runtime performance and other user-facing concerns.
Taking this to its logical conclusion all programs should be written in assembly.
The reality is that there's a tradeoff: Programmer time vs performance, and which parts of performance matter. I've worked using anything with performance from assembly to shell scripts (including C, C++ and Java). It is all tradeoffs. Do users want more features, or more speed? Are we running at a scale or situation where ultimate usage of hardware matters, or not?
Saying we should do ultimate amounts of investment in performance when there's three users and one programmer doesn't make sense. They'd typically rather have more features and adequate performance.
The post is a lot more about Java-the-language and has very little to do with the JVM.
Wow! I expected a Markdown to LaTeX tool, but the author ended up writing their own engine.
I don't understand why. Why not use one of the numerous typesetting markup languages?
Precision, control, contribution and fun.
mostly for fun!
This is just amazing! Really like the result, and also the other personal projects on the site!