I love Markdown. I'm a bit surprised, though, that you still can't open a .md file by default in most web browsers. It seems like it should be quite trivial to have the browser automatically convert it to html and display it.
As I was griping above, you usually can't just view a Markdown file with formatting applied at all. I think MAYBE Notepad has been updated just recently to render it, but otherwise... you're looking at plain text with a bunch of formatting characters in it. Why? It's baffling. Where are the simple Markdown READERS?
It really would be nice to have a convenient renderer for it though. It's genuinely surprising something like firefox doesn't have a markdown reader builtin already.
There should be only one correct interpretation of that according to CommonMark. Software is faulty for sure and a lot of the these "markdown converters" are pre-AI slop code but at least there is a carefully written spec now.
(That dude who coined the name Markdown is being a dick about other people finishing his abandoned idea is another issue and not the fault of CommonMark.)
Why is this a problem? To me it sounds like a it would be an advantage because you have everything you need to render it already built into the software.
Rendering is trivial. The issue is standards, and the DOM. No-one can write a Markdown implementation for the core of any major web browser in a form that is simultaneously acceptable to both their technical and political governance.
Best you’ll get is a plugin. Strictly arm’s reach. Translation only.
I'm not quite sure I understand what you are saying. Is the essence of what you are saying that it is hard to agree on a spec for the Markdown (and how it is translated to HTML or directly to DOM?) Or that this represents a technical challenge I don't understand?
I don't think so. I think it would be sufficient to document the exact markdown it supports and let the chips fall where they may. Yes, it would push markdown in a certain direction, but that's OK as long as it stays faithful to some variant most people already know. For instance whatever variant Github or some other major, main stream tool uses. And then just ignore the critics.
It'll certainly make some people angry, but if we try to please everyone we can't get anything done. And I suspect that it is the fear of not being able to please everyone that is the reason browsers do not have markdown support. It takes a bit of courage to say "this is the variant we'll implement".
HTML was originally said to be an application of SGML. It wasn't. It was vaguely inspired by its syntax and that is the only reason HTML saw wide adoption. Had they tried to actually implement anything close to ISO 8879:1986 we would NOT have adopted HTML for the web. Mostly because it would have been too costly to implement. (Anyone doubting that: have a look at the ISO standard. You can get it in what is essentially annotated form in Charles Goldfarb's "The HTML Handbook").
Of course, Markdown is nowhere near as complex. So this is where perfect is the enemy of good and we end up getting nothing.
You write your markdown file, but add the code snippet at the bottom of yor document and save it with a .md.html extension. Then when you double-click it it opens and renders in your browser.
I save my notes in a Google Drive, and it's now replaced all the note taking apps I've tried over the years
This is a good call. I know it's been suggested multiple times over the years; I wonder what the rationale was for rejecting the format, or at least having the option to render a file when it's loaded. (Maybe a "display as HTML" button or the like would be required before it would be rendered.)
The overlap between these Markdown formats is actually larger than with many other formats. Possibly even larger than HTML’s overlap back when MS Explorer was the dominant browser.
> Possibly even larger than HTML’s overlap back when MS Explorer was the dominant browser.
No way. You were never left in doubt about whether a normal HTML tag would work, or whether tables were available or would become a jumbled illegible mess, or whether a line break in the source would become a space or a hard break. And that’s just the first three things that occur to me.
You have to be willingly ignoring CommonMark, these days.
I understand it doesn't have all the extensions one might hope, but to not parse the basics like the examples in the spec say is just doing everyone a disservice.
Yeah, also missing a built-in JS API for turning Markdown into safe HTML. Sure, there are lots of different implementations, but maybe start with something small at least.
Computing entropies of high-dimensional random vectors for a theoretical neuroscience study. The journey is mostly a repetition of (1) almost giving up because it's completely hopeless, (2) taking a hot shower, (3) realizing there might actually be a path forward, (4) almost giving up because it's completely hopeless.
A notable and interesting point of this article is that convolutions and correlations (convolutions without flipping the filter) are quite a bit more subtle on the sphere than on Cartesian spaces. For a convolution between a function and a filter on R^N you just "slide" the filter around, integrating at each shift, which produces another function on R^N. On a sphere, however, there is not a clear cut way to slide a filter around a sphere. For instance, there are multiple ways to slide a filter centered at the north pole to the south pole, which will result in different filter orientations.
More generally, the space of rotations, which is the argument of the convolution (analogous to the shift amount being the argument of a standard convolution), is 3D (3 Euler angles), whereas the space of points on the sphere is 2D (polar and azimuthal angles). Thus, whereas convolution over R^N returns a function over R^N, convolution over the sphere actually returns a function over the 3D rotation group SO(3). This has interesting consequences for e.g. the convolution theorem on the sphere, which is not as clear cut as simply rewriting the standard convolution theorem in spherical terms.
Sagawa was mistaken in this article; he failed to appreciate the role of mutual information in computing, which is the proper basis for understanding Landauer's principle. I discussed this in https://www.mdpi.com/1099-4300/23/6/701.
If you don't mind my asking, how much does the role of mutual information in linking logical and thermodynamic reversibility depend on considering quantum systems? I.e. does your footnote 37, which discusses independent systems vs "subsystems of correlated systems" hold for classical systems as well?
There are a few folks working on this in neuroscience, e.g. training transformers to "decode" neural activity (https://arxiv.org/abs/2310.16046). It's still pretty new and a bit unclear what the most promising path forward is, but will be interesting to see where things go. One challenge that gets brought up a lot is that neuroscience data is often high-dimensional and with limited samples (since it's traditionally been quite expensive to record neurons for extended periods), which is a fairly different regime from the very large data sets typically used to train LLMs, etc.
This reminds me of a project I worked on during my PhD, where you create a network of scientific documents and notes/threads via Markdown, with a similarly structured "rabbit-hole" linking system: https://github.com/rkp8000/hypothesize . I'm not really a software engineer so never made it ready for general use, but I'm very happy to see a similar idea turned into something real! Kudos to the authors.
MSR has a very clear and accessible tutorial on quantum computing for anyone interested in getting up to speed with the fundamentals: https://www.youtube.com/watch?v=F_Riqjdh2oM .
reply