It's interesting to see a somewhat widespread shift away from the separation of code, templates, styles, and text model of publishing things (mostly websites, but most publishing can be boiled down to that if you squint), where code/templates/style get merged into one. React does this. Pollen seemingly takes it even further and sticks the text in the code, too. Or, rather sticks the code in the text, I guess.
It's a surprising shift. "Separation of concerns" is still a thing everybody wants to do, it's just flipping the idea of what should be the same "concern", where React considers every piece of a component to be one concern...and, it seems to work. I'm not sure I'm on board with this for writing, but the results certainly do look very nice; the books the author has published with Pollen all look gorgeoues and are very navigable.
I've been tinkering with Hugo for converting my projects docs to something that isn't in a wiki or a CMS (because I find I dread working with either a wiki or a CMS for large documents). I think it's probably "enough" for all of my needs, so I doubt I'll take the time to learn a bigger system like Pollen...but, it's hard to argue with the quality of the results.
When I learned HTML in the 90's and early 2000's you got a strong notion that they were separate concerns.
When I was learning react when it came out I had such a visceral reaction I just wanted to run away.
After coding within react for the past couple years I strongly feel that react has got it right.
A concern is after all a generality that has the potential to generate a strong bias.
My lesson is that concerns should be taken with a grain of salt, and be willing to try new things with as little as bias as possible; and then form a new opinion, maybe a slightly different concern.
P.s I have also started writing CSS in our presentational focuses react components and I couldn't be happier. It naturally did a BEM-like architecture. I highly recommend it. I say this with extensive experience of CSS architecture for applications.
At the moment my favorite thing to do is think about each web page as a cohesive collection of components that are the sum of what it takes to make that web page work.
ie css, html and javascript for that page contained within that page.
Then, as you notice common use cases accross pages start to abstract them to a central library (be it js, css).
This way it makes it easy to develop any size application because each page is coded as needed and code relevant to each page is always right there with it.
I've worked on plenty of codebases that start out with a central library and then build outward but they always seem harder to maintain due multiple layers of abstraction.
I guess, in summary, this method is a way to lazy load abstraction.
Of course React got it right because there's no violation of separation of concerns involved.
JSX is just syntactic sugar on top of method calls. One is perfectly free to extract the `render` functions into separate files and call them "templates". Unless the argument is that virtual DOM libraries are an inherently bad idea, I don't see what's to complain about separation of concerns.
Separation of concerns is about both the structure of a piece of code (which is what you refer to) and about how it is organized in files, folders and mentally (which is what others refer to).
I don't find it that surprising. It's the Literate Programming Knuth came up with ages ago. I own a book called 'Physically Based Rendering' which deals with rendering images through, essentially, simulation of the physics of light which is written in the same manner. As far as I know, Knuths work and the Physically Based Rendering book are the only ones published which are of that type... well until I saw this posting this morning, that is!
There are others as well. "A Retargetable C Compiler: Design and Implementation" by David R. Hanson, Christopher W. Fraser is the first that comes to mind.
Well, these are separate concerns. If you have a document, with no interactivity, using just standard elements, but lots of different themes, then separating into content and style makes perfect sense.
And I’d prefer if we could go back to that as much as possible.
Yes, a general template defined in an external style sheet or whatever format makes sense. However, revealing a message when there is an error, for example, is business logic and should be defined in code - be it styled components or something else.
Note that e.g. TeX is a programming language, and for a reason.
Personally, I quickly become disillusioned about "separation of concern". It was a webdev slogan that ignored the fact that form is also content. I mean, it makes sense if all you're doing is hyperlinked free-form documents. But the web ended up being used for web sites (and later web apps), where how you say something matters just as much as what you say. Separation of concerns is not an adequate rule for those kinds of works. You could see its death in every site that had its HTML littered with divs that existed only to hang JS code and CSS rules off them (and for some reason people still believed they're "separating concerns" there).
And books, again, are different from free-form documents. Their layout/typesetting decisions are often important part of the content.
I think the shift you noticed is a welcome breath of sanity into this space.
> "Separation of concerns" is still a thing everybody wants to do
Separation of concerns was a problem twenty years ago when source code looked like [this](https://github.com/kmainyu/EveHQ/blob/c3406c9cffca744500213f...). Since then the tools & languages have reached, maybe not the optimal abstraction level, but at least damn close to it. Everything is here to build apps as fast as possible ; the only thing left to do is write the actual software.
I'm a CS teacher and use Pollen to write my assignments (sample: https://drive.google.com/file/d/0B9DAZWpkQIDuUlA4SU5lcHItRDg...). It allows me to type assignments as fast as I can think them, in a specialized mark-up language for exactly the type of assignments I give. I can then apply various post-processing operations (like doing syntax highlighting, converting straight quotation marks to curly but not when inside sample code, numbering of problems, inserting special CSS to make the assignments print with nice margins / without breaking up headings and paragraphs that belong with them, etc.) all with very little pain.
It's also neat to show students, after they've spent months learning Racket, that all sorts of useful things -- including the writing of their assignments! -- can be automated with their new skills.
Thanks! Happy to :-) Here's the code for this assignment, as well as the pollen.rkt and HTML template/CSS files. (Disclaimer: this was written as code to get something done, not for others to see, so it's not always pretty!)
By the way, I use Atom, which has an excellent Pollen plugin, to write. Typing '@' then pressing tab turns into ◊{}, with the cursor between the lozenge and the braces.
Is the ‘lozenge’ a Racket-ism or is it unique to this project? I understand the logic around using a character that’s hardly used in regular writing – to avoid escaping – but it seems as though it would be hard to use in practice.
I might be remembering wrong since it's been a while since I went through the tutorial, but I think you can use any character you want for the delimiter because lisp. He just likes the lozenge.
This is certainly not the case. Some, but by no means all, of the core maintainers prefer the unicode glyph, but the vast majority of the code uses a spelled-out lambda.
In my current checkout of the codebase, I see the following:
~/src/racket/racket/share/pkgs$ ag lambda **/*.rkt | wc -l
1041
~/src/racket/racket/share/pkgs$ ag λ **/*.rkt | wc -l
163
I realize it's the norm, but anyone wonder why we're pushing around static content about dynamic programs? Why the dynamic program snippets do not work inline, even though the computer you're reading them on is fully capable of running them?
Quibble all ebooks were produced by programs in a computer?
Your looking at it as if the output is the programming piece. Heck markdown outputs to HTML. You wouldn't look at markdown as a programming language in the general sense?
Look a little closer my friend and you will see that this is very unique and special.
"Pollen gives you access to a full programming language (Racket) with a text-based syntax that makes it easy to embed code within your documents."
Sure, it goes farther than, say, Pandoc, in giving you access to an underlying programming environment as a writer.
But to double down on my quibble, when I go into a bookstore, or on O'Reilly (or now, Amazon, sniff), what's on offer are books. Even if on github and similar, what's on offer there is source of various languages and markup, which go to produce a book.
I just can't see any final, static rendering of source as a "program." I would consider Stephenson's Young Lady's Illustrated Primer, or anything that aspires to that, as a program. https://en.wikipedia.org/wiki/The_Diamond_Age
these short descriptions I've read don't seem to answer this question for me - how is this different from orgmode + org-babel + HTML/PDF export? See like reinventing the wheel for one language, or am I missing something?
Pollen is a Racket language, and gets parsed into an AST and evaluated. You can programmatically generate correct markup using all of Racket.
Org Babel is more about evaluating code snippets in a variety of languages. Even if you can evaluate to produce org markup that's processed it doesn't have the same level of structural integration.
I'm not sure about that combination of tooling, but I consider pollen to be useful as markdown + customization. Ofc its a full general-purpose language to work with, but I myself just wanted it to solve adding sidenotes, footnotes and simple references.
I also noted others using to handle blog publishing tasks like latest post pages and tags and such
I guess in total its a general html publishing framework, and at least partly notable for being built in a lisp, given htnl's usage of basically s-expressions
This looks lovely and near perfect. But what happened to Docbook? I worry about tool longevity and thus ongoing editability of source assets. I imagine groff still might grind old tbl and nroff and docs into Postscript.
Like many computer things, Docbook had (and as I understand it still has) a life in a certain domain. But, for reasons that are perhaps not perfectly clear, it never made the jump to hyperspeed. It just never became the thing.
The idea of literate programming is to write explanations of programs in human language as the primary form of communicating what a program does to others.
OP link is about using code to create a document.
Probably you could use OP tool to write literate programs but that is not the primary intention.
Hmm, is there a cheatsheet or crash course for it? Not particularly interested in reading a book just to get my editing game on. Just throw me in the deep water with the basics, and then I'll jump around to what I need.
Would consider using this instead of LaTeX for my thesis, but not so much if the time investment is too much.
If your university has requirements around formatting (most do), then you'll likely spend many hours making anything that isn't LaTeX (or, blech, Word) do the right thing. For a thesis, your best case is to just use a university provided LaTeX template and then spend as little time bike shedding as humanly possible.
Luckily they don’t :) My Bsc thesis I did in a template another student had made years ago, which swims around, but honestly LaTeX is quite tedious and time wasting to write in for most non math heavy content, which is why I’d prefer something else, that stills allows the same flexibility if needed.
My masters thesis had strict formatting requirements, and I bikeshedded the hell out of building my own LaTeX template in part because I needed an excuse to distract myself from... writing my thesis. And of course there were some ambiguities in the formatting spec that resulted in me needing to track down an advisor to resign a page in my thesis before she boarded a plane to Europe.
If I had it to do over again, I'd have spent the time I spent bikeshedding doing something more properly restorative such as exercising or video games or... anything else other than grokking the internals of my home-built LaTeX template :-)
Then again, if there are no formatting requirements, a digital version will suffice, and writing Pollen rather than your thesis brings you joy, then go for it.
Yes, the "Uncharted" series and "The Last of Us". Our team built a large system in Racket that built all kinds of data for the game. The front end could and often did have many layers of DSLs using Racket syntax macros.
Overall it enabled us to do many things that would have required lots of specialized tools. The downsides were things like people ramping up on editing s-expressions in text files and lots of gotchas with hygienic macros.
Well, that wasn't the answer I expected! Super cool, I wouldn't have guessed any AAA titles were using a Lisp/Scheme heavily in their toolchain (but I'm not particularly knowledgeable about the game industry).
I'm fascinated by procedural generation and constrained randomness in games, and I'd think something like Racket would be a fun choice for that. Do you reckon you'd make the same choice if you were starting today?
That's awesome. Do you think this is still a viable career? I know very little about what sort of DSL you would make for games, what would they even cover? map gen? Also, why Racket?
I think it'd be useful to learn, but nobody in the industry will hire you specifically to work in Racket.
We used DSLs on top of a data pipeline to create things like particle effects, animations, sound, and scripting.
We chose Racket because it seemed to be the best supported open source scheme implementation at the time I started working on this system (back in 2005).
Practical Typography is gorgeous. I have a lot of respect for what Butterick's accomplished. He does great font work as well. I also admire his experiments (hopefully successful) in making this worth his while:
So i follow a link, supposedly about a book, and i see a wall of text trying to sell me something with no information what that something is.
That reminds me of this:
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
It is checking the referrer value and only displaying it to people from reddit, HN, etc. -- because when traffic spikes due to those communities, it can be expensive.
Given the choice between this and advertisements, I much prefer this.
I understand his argument against ebooks[1], but I still wish I could buy a copy in that format. On a Kindle you do give up something with respect to typography and you have to accept non-standard formats, but you gain something in readability.
I respect his choices though and I hope future devices eliminate his typography and format concerns.
I have not used it at all. I posted it moments after learning about it. I've been looking for something like this though so I will likely being playing around with it in the near future.
There's nothing from a readers perspective that you can accomplish with Pollen that couldn't be accomplished in some other way. But if it makes author's lives easier they'll publish more which improves the reader's experience.
Making texts that are active is currently a hard job. There is a fairly large set of technologies to know, and an author can worry that each of those will have a limited life.
People who have something to say, and who know all the techs, and who are willing to keep their work up, may well be a small set.
> I chose the lozenge as the command character because a) it appears in almost every font, b) it’s barely used in ordinary typesetting, c) it’s not used in any programming language that I know of, and d) its shape and color allow it to stand out easily in code without being distracting.
> If you’re using DrRacket, you can use the Insert Command Char button at the top of the editing window to — you guessed it — insert the command character.
> If you’re using a different editor, here’s how you type it:
> Mac: Option + Shift + V
> Windows: holding down Alt, type 9674 on the num pad
> GNU/Linux, BSD: Type Ctrl + Shift + U, then 25CA, then Enter
> For more information on entering arbitrary Unicode glyphs, see Wikipedia.
> He also advocate not using underline to denote links.
>In his practical typography book he practically hides all hyperlinks.
I think that's a fine, defensible stylistic choice. When reading a paragraph of prose, I find it INTERRUPTS MY FLOW if there is a jarring style change in the middle of a sentence, as in this one.
The visual style of a hyperlink is only relevant to the point that you know the hyperlink is there and can find it when you want to click on it. Most of the time, that's not a goal, so you want it to fade into the background unless the user has indicated that is their goal.
So my preferred style for hyperlinks in prose is a color that's right at the just-noticeable difference [1] relative the normal text. When you mouse over the paragraph, which indicates you are intending to click, the contrast increases.
> hyperlinks in prose is a color that's right at the just-noticeable difference
The problem with trying to achieve JND for online publishing formats is that you have to account for variable monitor settings and lighting conditions. What stands out on my monitors at home might be barely noticeable on the crap displays at the office or my laptop under some lighting conditions or when I have it set to low power.
On top of technological differences, you also need to contend with variances in people's eye-sight.
Underlining is far simpler and more reliable. Perhaps highlighting with an underline as the link is drawn or scrolls into view, and fading the underline out soon after, to be drawn again if the pointer hovers over the paragraph or the page scrolls, would work?
Ooh, that's a great question. I haven't thought about that (though I do generally try to make my designs responsive and mobile-friendly). I like your idea of a slow fade after scroll.
Things blinking/fading/shifting/changing when I'm taking completely unrelated actions (or, worse, all on their own) is one of the most unreadable/unusable design decisions I regularly face. It's a good way to get me to close a tab, regardless of any other factors.
I agree. His book Practical Typography is very hard on the eyes, even looking at the text is uncomfortable. I think he fell into a trap of overdoing things. Like some people when they learn about what you can do with javascript and css add all sorts of annoying visual effects with no unified theme to the whole. They just enter some sort of trance and keep adding.
If you actually need to use this seriously there are ways of customizing keyboard layouts and text input on every platform and every reasonable text editor.
Sure, but it's absurd to have to set up custom text entry for an unusual character just to use a programming language. Especially when every other template language manages to do so with characters I don't have to customize my text editor to simply type.
Presumably your usage is limited enough not to cover the entire unicode space, and even if you hit the current operator, it should be trivial to update all previous work with a new character, since its prior usage was unambiguous (literally character replacement).
Tbh if you're assuming unicode input (which pollen does), and assuming its easy to write the character (which it is, given that system hotkeys for unicode are available or can be made available on most/all target systems), then it seems to me absurd to use the normal ascii character + escape character operators for embedding functionality in text
I say this because when installing a new OS and it defaults to en-UK locale, some of my buttons on the right side of the keyboard do unexpected things (US here), and I always have to look up where exactly the single-quote button is. I believe sometimes that angle pops up.
It's a surprising shift. "Separation of concerns" is still a thing everybody wants to do, it's just flipping the idea of what should be the same "concern", where React considers every piece of a component to be one concern...and, it seems to work. I'm not sure I'm on board with this for writing, but the results certainly do look very nice; the books the author has published with Pollen all look gorgeoues and are very navigable.
I've been tinkering with Hugo for converting my projects docs to something that isn't in a wiki or a CMS (because I find I dread working with either a wiki or a CMS for large documents). I think it's probably "enough" for all of my needs, so I doubt I'll take the time to learn a bigger system like Pollen...but, it's hard to argue with the quality of the results.