We need constrainable lightweight markup languages | Hacker News Reader

We need constrainable lightweight markup languages

everypageispageone.com

49 pointsbootload32 comments

I'll keep saying it: The most cost-effective way to advance math and hard science research in the United States would be for some person or organization to put down $1 million to hire some developers to produce an enterprise-quality replacement of LaTeX, with an editor. It ought to be somewhere between LaTeX and Markdown in complexity. The amount of grad student, post-doc, and professor time that is wasted dealing with LaTeX is staggering. There's just no reason any should need to spend, e.g., an hour to figure out how to get columns working.

SILE looks promising: http://www.sile-typesetter.org/

Sphinx and restructured text are getting pretty close.

http://www.sphinx-doc.org/

Shouldn't be hard to create a GUI around it. Looks like audreyr started one, just needs some help. https://github.com/audreyr/sphinx-gui

I would say Sphinx has the exact problem grandparent describes. I've spent a lot of time and frustration trying to figure out what syntax it wants to link to another doc, for example.

Yes, it was harder than it probably should be but now that I've written a book in it I've got it down by heart. Probably needs to be more prominent in the docs:

    # doc1, the destination
    
    .. _introduction:

    Introduction
    ---------------

    asdf asdf…

Then in the source document:

    # doc2, the source

    In the :ref:`Intro <introduction>` or 
    simply :ref:`introduction`,
    blah blah blah.

I made snippets in my editor to help with common tasks such as this.

I completely agree with this sentiment. LaTeX is far too complex for what needs to be highly accessible and Markdown, while super easy, is too limited for showing things like complex data sets (or really even simple ones to be honest).

The biggest problem with the idea of getting people to make a new format is essentially this: https://xkcd.com/927/

What's to say the ultimate result will be something most think is usable? Design by commit is rarely the answer as well.

Have you really read that article? Their main focus is on how to enforce customizable writing styles/rules/constraints. They want a lightweight markup language like XML+DTD.

I did read it, and I'm suggesting that a lightweight markup language is needed to replace LaTeX as it is used in academia, i.e., the language that people actually write in. (If that language gets compiled into TeX or some other lower-level typesetting language, all the better.) So I don't understand your objection.

I mean you make the subject too broad. You can see this file in their repo:

https://github.com/mbakeranalecta/sam/blob/7f9eece97b30a2a5f...

It is like YAML+Markdown+(Custom Schema for Semantics). They are also considering embedding LaTeX document, not replacing LaTeX. "Lightweight" as they said.

Couldn't agree with you more! Unfortunately there's no "golden accolades" in such a endeavor and even more difficulty getting it to be a community standard. Academics (especially professors) tend towards using it only if their advisor used it or another prestigious lab does. Actually having a NSF/NIH (TM) sponsored projects could help with that.

In the meantime, checkout Madoko: https://www.madoko.net -- some research folks at Microsoft basically made an extensible markdown format that compiles nicely to Latex or Word (-ish).

When I was a grad student, those of us in the lab had this conversation on a weekly basis.

Now I wonder...

NSF has these big cyberinfrastructure programs. I wonder what they'd say if you proposed such a thing.

http://www.nsf.gov/div/index.jsp?div=ACI

To have even a slight chance at success in this, you'd definitely need to have your story straight from the very beginning. You'd need to show a very low-risk plan for replicating all the features of LaTeX that really matter, with measurable improvement in usability.

Probably a super-long shot, but it would be very cool.

I don't think that rewriting LaTeX is the right route, but rather compiling something else into LaTeX or making a good LaTeX editor(one where you wouldn't actually be writing straight LaTeX). I think a sort of SASS or Coffeescript type language for Latex would be excellent.

A language that compiles into TeX would be fine. However, there is a huge danger that the abstraction isn't robust, and everyone would just need to keep "opening up the hood" to fix things in the original TeX, and then things are worse than they started.

lyx? personally, I think it takes less time to learn latex

Totally agree.

What do you think of Pandoc?

http://pandoc.org/

And the output format should be

    1. executable
    2. machine readable

So that it is searchable/discoverable in digital libraries.

You just described AsciiDoc.

I agree that we need extensible lightweight markup languages, but I'm not sure how the OP distinguishes between a grammar and a constraint. And if by "language" he didn't mean "grammar," then what did he mean? An example would have gone a long way.

My experience---and I've seen others comment to this effect---is that James Clark's nXml mode for emacs is as good as it gets for authoring in XML. If you already know the commands for structured editing, you have a great headstart. Also from James Clark is compact Relax NG. It's basically like regex for the DOM, and I find it pleasant to use. Until you hit something that it can't specify. But if you really must have a schema, and you have control over it, it can be worth making your schemas RelaxNG-able.

And anyway, even if you're using markdown or anything else, using it without a "really sophistocated editor" is (IMHO) "next to impossible" (edit: I mean, just as painful as anything else).

But yes, I've been ruminating over what I would use to replace Org Mode for literate programming, where I don't want all of its features (or an Emacs dependency), yet I do want to create ad-hoc constructs with arbitrary transforms during export. I haven't tried it, but it looks like Quaint might be of interest in that area. (http://breuleux.github.io/quaint/)

Good question. In my head I simplified it to "he wants XML schemes without having to write XML." That's probably a bad assumption or too simplified.

I totally agree with the article. I have been working (as a university project) on a semantic markup language which has a well defined, user specified semantics (comparable to a DTD, yet much easier to write) with user definable syntax and a TeX-esque markup language, which deduces as much structure as possible from the DTD, allowing users to write very little while still being able to transform the document into a semantic graph structure which can (theoretically) be transformed to any output format.

While the software we've developed is fully usable and quite mature (including clang-like error messages), there is virtually no documentation. However, a poster and a presentation of the project, along with all source code (including the source code of the website) can be found at

https://ousia-framework.org/

I'm looking forward to continue the project as soon as I find some time.

It is in the nature of such languages to grow. We've seen this happen to MIT Runoff, which begat nroff, which begat troff, which begat ditroff, which resulted in TeX. We've seen it happen to HTML, which started as a lightweight markup language. It's happening to markdown right now.

One of the few approaches that hasn't become bloated is Rich Text Format, and that's because nobody uses it.

Hey! I use it for many of my personal notes. When I'm not using txt.

We have a lightweight extensible markup language. It's called XML.

When HTML web components are fully supported in all browsers, it'll be possible to create custom markup elements to extend HTML to include custom DSLs (Domain Specific Languages).

I already have a library (ng2-markdown) that provides a template tag that can parse markdown (incl syntax highlighting) in the same manner that the script tag can parse javascript.

If a parser is already available in javascript, it's not exceedingly difficult to create new HTML elements.

Did you consider troff/nroff programs?

They were/are the programs used to write unix/linux manpages. Such documents are usually rendered in our terminal via the man utility, but they can export to html and pdf too (man man).

I used to read a bit about the format and it does not look bad at all.

If you didn't know, Ken Thomposon's "The Go Programming Language" was typesed using troff (and it looks okay to me).

i have an entry: zen markup language (z.m.l.)

> https://medium.com/the-bower/beyond-markdown-part-1-23006656...

built specifically to handle the features of books, as identified by using the project gutenberg corpus, but can easily be extended to handle whatever other structures might be required by any long-form docs.

still don't see enough interest in overthrowing markdown to work at raising the z.m.l. profile at the present time, but i am continuously monitoring the scene for that sign.

also see my 2013 review piece: "markdown considered harmful"

> https://medium.com/the-bower/markdown-considered-harmful-495...

The article says “and before too long everyone is complaining and saying they should be going back to WYSIWYG tools”

I wonder what’s wrong with WYSIWYG tools?

Personally, I use MS Word all the time.

It works very well for me and for various people I interact with (clients, colleagues, bosses, subordinates, friends, family, etc.), for decades already.

Since it's 2016, the answer is JSX. Define a core set of react components that are at feature parity with markdown. Extend it willy nilly.

Are you implying that the answer will be different in 2017? ;)

If parent hadn't combined JSX and React, you'd have a fair point. However, JSX can stand alone, and that would also be my technology of choice.

Forgive me, but what does any of this have to do with authoring documents? Aren't JSX and React about coding models and views?

It doesn't. They are either joking, being snarky, or over estimating the coding aptitude of people like scientists.

Sure, most scientists are not going to have time to learn all the ins and outs of JavaScript. But you may be underestimating the potential convenience of composable components. It seems plausible that well-built components, using JSX and whatever rendering engine you prefer, could be much easier to work with than a language like LaTex.

Of course building these components would not be a simple task.

Reply on news.ycombinator.com