Okay, I've had a look at the project, and it seems to me like these are two fundamentally different things solving two different problems.
Doesn't seem like a direct competitor - although the names are 60% similar.
750 karma · joined March 22, 2019
Doesn't seem like a direct competitor - although the names are 60% similar.
p {b This} {b text is} {b bolded} this isn't
p {b This text is bolded} this isn't
In Polymath, I'm planning on allowing basically arbitrary CSS styling by parent, id, class, etc. So if the user later wants to do something like put a rounded box around each span of bolded text, those two, while initially looking identical in WYSIWYG, end up completely different.
You wouldn't be able to tell the difference between
{b Bolded} {b text}
b Bolded text
Ultimately, Polymath is meant to provide a file format that will work for the long term, so I don't think users should be always getting an abstraction of the language through WYSIWYG, because then they don't understand the files they are preserving.
If you only care about having a nice blog, then sure, WYSIWYG might be convenient, but the whole reason for using Polymath instead of pure HTML/CSS + JS libraries is because it gives you the same/similar level of convenience as a WYSIWYG editor without losing exactness and understanding.
I think it'd be cool to do a side-by-side web app where you can type your Polymath code and see the resulting page at the same time.
But the language itself is open, it's just syntax, anybody can do whatever they like with it :)
Sorry, from your wording I'm not sure whether you are suggesting custom tags or saying there already are, but to clear up any confusion, there will be.
That's kind of what I was hinting towards at the end of the demo - you can define custom tags and styling behavior (either globally or at a block level, or site-wide in your preferences) with keywords like "@"
Trust me, I know the struggle of setting up like 500 custom math and environment macros in LaTeX. I'll try to find the best solution for this sort of thing - Polymath should work very well out of the box, but it should also allow for a fair amount of customization.
If the text editor doesn't support line folding spaced indentation, you can fall back to tabs, and if it doesn't support any indentation, you can actually write a paragraph all on one line. The manual wrapping is completely optional, I just like the way it makes my source code look.
Worst case scenario, you can always wrap any block in {brackets} and completely forget about all that indentation and newline stuff :)
The language itself will almost definitely be open source, and I've created a MIT-licensed GitHub repo to support it as of earlier today.
The site generator, maybe a hosting service, and other such things might have a paid or freemium model to support the development of the language - but I'm not sure what to do yet. Might also just do some kind of donation backed fully open source thing.
I've had a look at a lot of examples and it seems great, but I really dislike the idea of homodirectional delimiters because I fear it unnecessarily complicates formatting and introduces a pointless risk of collision.
That's why I want to only use two kinds of delimiter:
- EOL, unless content is continued on the same indentation immediately without a gap, defines a block separation
- Strictly heterodirectional delimiters, e.g. () [] {} <>, define inline blocks and nested blocks, or can provide a bypass of the first rule
I feel that this design decision will save a lot of time, even though
*italics*
{i italics}
i italicsIn my example I was referring to the Cartesian plane graph of x vs. f(x), but I do certainly hope to support the kind of general graphs / directed graph structures you're referring to. If there are open source libraries to process those kinds of things, I may be able to hack MVP-type usability quicker than otherwise.
Unfortunately Polymath is a side project that only has a limited resource pool available at the moment, as I have other work responsibilities.
I'm considering the options available to me in finding some way to fund a dedicated long term development of Polymath. Maybe a paid hosting service for ready-to-go blogs or something like that, or a Patreon-type deal if it's better to just keep the whole thing open source. Very early in the project right now - definitely open to any suggestions on expanding it.
I've also made a GitHub repo where I might keep code and a wiki, or I may host a wiki written in Polymath on my site. It will explain all the intricacies of the language and people can do a custom implementation if they don't like mine.
As of right now, the demo page (this article's link) showcases the language itself in the preformatted text sections below or to the right of the document content (depending on whether you have a mobile or desktop screen)
The primary goals of the syntax are:
- Human readability
- Clear, explicit nesting
- Very easy learning curve
Although I guess if you have an arbitrary number of divs, CSS just becomes a much more esoteric equivalent to SVG
I'd certainly much prefer to use the Polymath syntax when using something like Jupyter (although Markdown has been pretty good thus far ngl)
The real advantage of Polymath will come once things like CSS grid features and block-style-macros are fully functional.
Perhaps not only is the Earth a rare planet with the right characteristics to support sentient life, but perhaps too we have evolved in a very tiny window between two much longer periods in Earth's life where something like a human cannot evolve.
It's always good to remember that where you are right now in your life is just in the middle of what will one day be a much longer past.
I believe it is a humbler, more appropriate calendar for talking about human history. I use it on my personal site because I don't need to conform to societal standards on my own site (although I don't use arguably superior numbering systems like dozenal or base-60 because that would be far too confusing)
I feel that Gregorian makes it pointlessly difficult to talk about anything between 10k BC and 0BC, and warps intuitive understanding of some of the most important time periods in human history - for example, ancient Rome sounds ancient, but understanding that it existed 10,000 years into human society and we are only 20% later is helpful.
Personally, I think the ~0BC Mediterranean societies carried out some of the most important and interesting work of humanity, and I'd like to improve my feel for the course of history around and since those times.
I'll probably do a blog post soon with an interactive map and calendar from 0 HE to 12,020 HE that really showcases the true time in between important historical periods.
I haven't used TikZ too much, maybe only a dozen or so times, but definitely am hoping to have something great for interactive diagrams. Will certainly keep this in mind as I add more features.
I'd be interested in having a look at what are the most important and widespread types of diagrams and data visualizations in academic work and research, as I'd like to make that sort of thing better. I'm particularly inspired by the interactive visualizations on https://distill.pub , however I think those are painstakingly hand-coded in SVG+JS+CSS+HTML.
I actually haven't tried org-mode but I've been hearing about it for a while now. Can't comment.
> Besides not requiring emacs, is there a value-add with Polymath? Or is this mostly scratching your own itches — which is a fine thing to do but a different one?
I don't have a concise and perfect answer for this yet, as it is basically just a very early version of a personal project I've been itching to work on, but these are what I think I'd like to do:
- The vanilla implementation of Polymath as an SSG should be extremely easy to learn - even easier than doing a pure HTML (+CSS?) site. The reason why is because I see a lot of professors with really great content but their page is basically pure old HTML and looks absolutely awful on a modern computer or smartphone. I want something that supports 99% of the (static) features most people want right out of the box: video support, great typography and layout for all devices, interoperability with most of the other languages or formats they already use, and a very easy learning curve. It should basically be possible to have only a bunch of Polymath files and render to a beautiful static website without needing any other technical know-how.
- Super long term focus: I want to make this the right way now and then be able to use it for the rest of my life, so it will be done from a perspective outside of the status-quo technology, as in, I want to think about the best way to concisely format a specific kind of information, in a way that is easy to render out to any current or future format (PDF, HTML, LaTeX, ...) that way anybody who builds up a considerable base of Polymath files should have minimal friction in adopting future technologies and swapping their infrastructure.
- Support other kinds of pages and layouts, like for example https://jwmza.com/portfolio/switzerland
- Something maybe a bit crazy: I have this idea to read TeX or tables and automatically generate interactive graphs, which I think could be really useful for people who do a lot of STEM writing. Say you write {x f(x):x\mapsto x^2}, I'd like to automatically guess the relevant domain, codomain and bounds, and create a little interactive graph.
I think what I'll probably do is support both the raw CSS/HTML keywords as well as a subset of more human-readable keywords and presets (my gripe with border-radius is that more often than not when I use border-radius, I don't even have any borders, what I really mean is corner radius)
Another example is box-shadow: I think the syntax for this CSS feature is horrible for people who don't use CSS all the time. I think some presets like `shadow: soft` would be nice in addition, where
shadow: soft |--> box-shadow: 0px 2px 4px rgba(0,0,0,0.1)Not sure, I should note that I've only ever used MathJax and KaTeX with the client-side JS rendering option, primarily because it's just faster to hack onto an early prototype.
If you prefer to do server-side rendering to avoid scripts, I imagine that the end user performance is roughly the same, however it is my understanding that MathJax has some advantages here in (a) also supporting MathML and (b) rendering to PNG, SVG, etc, while I believe KaTeX only has one rendering option in fairly CSS/HTML heavy nested sets of HTML elements and an imported web font.
Thereby I could see a potential preference for MathJax (esp. to render just a few PNG/SVG equations into the static site and serve those) but I think for really long documents, pre-rendered KaTeX might still be superior because you only need to load a single web font and the HTML itself instead of numerous copies of the same symbols in hundreds of image files. KaTeX also seems much faster if you do client-side rendering with JS.
Btw, your site has been a big source of inspiration to improve my own (in both design and infrastructure). I liked your post about A/B testing CSS and HTML, and the margin footnotes are really cool.
I think it's always important to look at the full supply chain life cycle effects of energy sources - keeping in mind that they need to be built from processed materials, potentially repaired, and decommissioned after a lifetime.
Once you account for the emissions of material throughput in building power plants and renewables, the sheer volumetric density of nuclear energy compared to all other sources pushes it far ahead in terms of cleanliness. You need a lot less concrete and steel per kWh generated.
Also your point about batteries is really important, because we would need to scale production many (many) orders of magnitude in order to reliably power a modern grid with majority renewable energy, and we don't really understand how that supply chain is going to look.
Unlike processing and manufacturing industries which generally have positive economies of scale, the problem with resource extraction (esp. with metals) is that the cost to extract has a negative forcing function driven by our prioritization of the most profitable reserves.
If you mine all the cheap reserves first, you will eventually be left with only the expensive ones.
I am baffled by world leaders repeatedly suspending, cancelling, or shutting down nuclear reactors. Even after Fukushima Daiichi, nuclear energy remains in Japan and worldwide the (1) safest by far [deaths/kWh], (2) lowest emissions on average, (3) most reliable source of energy generation.
Every plant shut down / suspended / whatever you want to call it effectively increases the number of people who die in accidents each year because the production is offset by increased coal/solar/gas/hydro generation, and usually it's coal, which is the worst by far - which also means more air pollution, more deaths due to air pollution (already a gargantuan problem in Asia), and more greenhouse gas emissions into the atmosphere (for which it is also the worst by far, even 4x worse than natural gas).
Every politician or leader who moves to build more coal plants instead of nuclear or at least renewables (which are much much safer and cleaner than coal) or natural gas (which is also safer and cleaner) should be criticized by their people.
If you can build ANYTHING that isn't coal, you're saving lives and reducing the climate change problem. Coal is the worst.
Also, if you're under the impression coal is "cheaper" - forget about unit cost, and look at the real world data. German electricity is about 2x the price of French electricity - a coal / renewables mix vs. a nuclear majority. Ontario electricity ranges from 5-10x cheaper than German electricity as well - also a nuclear majority grid.
This isn't even including the significant externalized costs that the air pollution and GHG emissions from coal plants place on society, or the costs of the thousands of people who die due to coal power accidents.
The world needs clean, reliable, scalable energy more now than ever before, and we have a serious shortage of talented folk who have previous experience in the skills necessary to develop liquid fueled fission reactors.
So, if you're in highschool or entering university soon, consider this. By the latter half of this decade, there's going to be a lot of demand for these skills.
I've not made up my mind about this whole expanding universe thing (whether it's permanent, local, even real) but based on our current understanding it certainly seems that you're right - the world is getting a little bit smaller all the time. Time is of the essence - we need to move fast.
The space in the solar system alone is literally quadrillions of times the volume of the entire Earth.
This is an assumption that bad implementation is the only possible implementation, and it is wrong.
Obviously omitting content from missing features is bad UX - but it's absolutely not necessary to interoperate. It's easy (and should be expected) to avoid this by simply telling the user something from a missing feature has been sent - they can then inquire and get back the lost information / clear up the confusion.
Furthermore if interoperability is implemented on both ends, the sender's client should know to alert the sender before they attempt to use features missing on the receiver's end.
None of this is a difficult issue.