[HN Gopher] Augmenting the Markdown Language for Great Python Gr...
___________________________________________________________________
Augmenting the Markdown Language for Great Python Graphical
Interfaces
Author : nevodavid
Score : 89 points
Date : 2024-01-21 09:15 UTC (13 hours ago)
(HTM) web link (www.taipy.io)
(TXT) w3m dump (www.taipy.io)
| grazio wrote:
| Python Graphical interface apps are getting really good at their
| job. You've mentioned Plotly, Stream and now Taipy. Reflex is
| also another one.
| ryanjshaw wrote:
| This is really cool. Unfortunately Markdown tables are quite
| limited, lacking concepts like filtering, sorting, row/column
| spans etc. Also, more flexibility around styling would be great.
| Maybe they can add attributes to the Markdown and support for a
| simple scripting language.
|
| To show-off these "hyper-markdown" capabilities and avoid
| compatibility issues with "md" files, we could name the new file
| format with an "html" extension (HyperText Markdown Language).
| lioeters wrote:
| Or, to emphasize that the new features provide a significant
| _up_ grade from Markdown, we could call it Markup.
| jsdwarf wrote:
| The big problem with Markdown is that it is horribly
| underspecified. Everything beyond basic text formatting and
| hyperlinks behaves differently in each markdown dialect (e.g.
| tables). What is the benefit of bolting additional use cases like
| UI rendering onto this mess?
| greazy wrote:
| Is this still true with the commonmark spec?
|
| https://commonmark.org/
| Kwpolska wrote:
| CommonMark is a very basic Markdown specification -- simple
| inline formatting, headings, lists, code blocks. It's pretty
| much Gruber Markdown + fenced code blocks. Many documents
| need some more features, like tables, but CommonMark doesn't
| support them, and there are a few table styles in use in
| different Markdown implementations.
| TuringTest wrote:
| There is a fully specified markup language, asciidoc, that
| reads similar to markdown and provides everything you'd need
| (as it's equivalent to docbook).
|
| Unfortunately, it's much less known and there is much less
| software support for it.
| ta988 wrote:
| That's the reason why I have not used asciidoc, the libraries
| are either incomplete or inexistant for many languages.
|
| Too bad because I found it superior to markdown for my uses.
| explodingman wrote:
| How do you pronounce "taipy"
| nmstoker wrote:
| I'd guess as "tie pie"
| Ferdie wrote:
| Yes, this how we pronounce it at Taipy R&D !
| magnio wrote:
| Every time I see people doing something with Markdown, I wish
| they just replace it with support for Djot[0] instead. It is a
| Markdown alternative by the creator of Pandoc and CommonMark that
| fixes all of the most egregious mistakes, while being legible and
| visually pleasant as-is. It is also syntactically similar to
| Markdown, which should ease adoption.
|
| [0] https://github.com/jgm/djot
| James_K wrote:
| Why not just HTML?
| rmbyrro wrote:
| Too verbose for some applications is one reason not
| bluGill wrote:
| Too annoying to write by hand. also too annoying to read the
| raw text. Markdown is easy to write by hand and looks good
| enough without a viewer.
| enriquto wrote:
| Apart from the p tag, that gets annoying when you have long
| stretches of prose, I find plain html5 much less annoying
| than markdown. Moreover, tables and hyperlinks are clearer
| and easier to type in html5 than in any markdown flavor.
| subtra3t wrote:
| Easier to type? Sure, but I don't think HTML5 tables are
| easier to read than markdown tables
| enriquto wrote:
| Thanks to optional closing tags, html5 tables are quite
| neat: <table> <tr>
| <td>first row, first column <td>first row,
| second column <td>first row, third column
| <tr> <td>second row, first column
| <td>second row, second column <td>second row,
| third column </table>
|
| Does it get any better in markdown?
| eviks wrote:
| The fact that you need to list columns in rows already
| makes it NOT a table
| bluGill wrote:
| Both are diffult to read and work with.
| subtra3t wrote:
| I'll convert your example to GFM. | first
| row, first column | first row, second column | first
| row, third column | | ------------------------ |
| ------------------------- | ------------------------ |
| | second row, first column | second row, second column |
| second row, third column |
|
| To me, this is more readable than the HTML version.
| kotborealis wrote:
| It's not fun to manually reformat those tables for
| readability. If I add something to the `second row,
| second column`, I have to add extra spaces to the `first
| row, second column`, or it will look janky.
| | first row, first column | first row, second column |
| first row, third column | |
| ------------------------ | ------------------------- |
| ------------------------ | | second row, first
| column | exceptionally long second row, that makes second
| column look worse | second row, third column |
| James_K wrote:
| This is an eminently solvable problem. I've been writing my
| personal website in a variation of HTML for a while now
| which is perfectly easy to write and read.
| {main {h1 Title} {p Paragraph 1.
| {{a {href google.com}} Here is a link.}} {p
| Paragraph 2, now with {b bold} text.}}
|
| The nice thing about HTML/XML is that it's a clear data-
| structure, so you can essentially read it in any format you
| like and convert that to the underlying tree structure
| without much issue. That's why it's been so successful,
| basically the same philosophy as a lisp. Why someone would
| look at that and think "let's go back to a document with no
| clear structure" is beyond me.
| lelanthran wrote:
| You solved it with s expressions.
|
| Replace the braces with parens and you can parse that
| into a tree with only a handful of lisp macros.
| James_K wrote:
| The braces are quite deliberate. Firstly, parens are used
| often in writing and it would be a pain to have to escape
| them. Secondly, it integrates much easier with the Scheme
| code of my site generator this way. I can write in a
| file, something like: (define (code-block
| file-name) {pre {{code {class block}}
| #(cmd "highlight" (thisdir (string-append "posts/" file-
| name)) "-O" "html" "--inline-css" "--
| fragment" "--line-numbers" "--line-
| number-length" "3")}})
|
| And it fits quite nicely with surrounding code. The
| mapping of these curly expressions to Scheme ones is
| relatively simple, though there is a special case for
| joining words to brackets. {a {b} #c #@d}
| => `("a" ("b") ,c ,@d) {a {b}c} => `("a" ("b") join
| "c")
| perpil wrote:
| Markdown lacks prompting for inputs and running javascript
| but is easier to write and offers a quicker update, preview,
| deploy cycle. Preview and deploy is often a simple save vs. a
| build and deploy process. By extending markdown to support
| prompting for inputs and running javascript, you close some
| of the gaps and get the best of both worlds.
| ravenstine wrote:
| It depends on the intent. Markdown is meant to be readable on
| its own. If you don't plan on reading Markdown files in some
| sort of plain text editor, then the benefit of Markdown is
| greatly diminished.
|
| Also, no one has implemented a really good experience for
| writing HTML, not for _webpages_ , but simple documents. It
| could be really easy to write HTML mostly by hand if an
| editor could dynamically convert Markdown-like syntax into
| HTML tags on the fly. That way, the resulting document is
| definitely HTML, and not up to the interpretation of some
| flavor of Markdown.
|
| Such an editor can also do things to try and soft-preview
| what emphasis the HTML represents. Here's an example of an
| experiment I worked on in this direction a long time ago:
| https://codepen.io/Ravenstine/pen/gyMVNx
|
| ^^ Never mind the pompous attitude I had when I wrote the
| placeholder text for it.
| eviks wrote:
| Unfortunately, not all, ignoring the linebreak is one of the
| most
|
| Not sure, but isn't using _ instead of the more intuitive
| /italics/ a big mistake on the syntax side?
| mst wrote:
| Lots of things use underscore for italics, if you asked me to
| guess I'd certainly try it first (and asterisk for bold).
|
| ... in fact I just tried it and underscore apparently works
| in WhatsApp, TIL.
|
| OTOH /italics/ reads to me as a regular expression, which ...
| is apparently not what you meant.
|
| (as ever, "intuitive" varies wildly between people, and the
| trick is to pick the option that's intuitive for the highest
| possible percentage of your expected user base)
| eviks wrote:
| / intuition is pretty simple: slanted mark for slanted text
|
| What's that wild intuition of underscores???
|
| Also, why would you ever read it as a regex in a human
| /text/ markup language?
| mst wrote:
| Underscores indicate emphasis, just like underlining
| would, but in text you usually get italics (I'd note that
| this is often an <em> tag so it being italics is a
| browser default style).
|
| Plus underscores get used -lots- of places for italics;
| I've yet to see the / form in the wild.
|
| A markup language being (as here) used for technical
| purposes can easily be interpreted according to geek
| writing conventions.
| adrusi wrote:
| At least in English, typographic conventions have
| historically equated underlining with italics, and the
| reason the underscore key is present on your keyboard is
| because it was used on typewriters to format text that
| would have been italicized in printed text.
|
| Surrounding text with underscores to indicate
| italicization is intuitive to anyone who is familiar with
| that convention.
|
| Personally, I find surrounding text with forward slashes
| _exactly_ wrong for italicization, because I mentally
| apply a skew-transform to the text to make the slashes
| into vertical lines, which leaves the text itself slanted
| in the wrong direction. Backslashes would make more
| sense, and also avoid looking like regular expressions.
| But literally no one uses that convention and we do _not_
| need a new one.
| bobbylarrybobby wrote:
| Why not just asciidoctor?
| deafpolygon wrote:
| Why not XML?
| kspacewalk2 wrote:
| Sadly there doesn't seem to be a Python implementation.
| jonhohle wrote:
| When the markup's first design goal is to be parsable in linear
| time (and then proceeds to have a bunch of rules to support
| that goal instead of flexibility for humans) I don't think
| there is much chance of catching on as a general markup
| language.
|
| Markdown was originally a loose formalization of how people
| already wrote text only emails. It was how _people_ wrote, not
| how to optimize for the computer.
| civilized wrote:
| It's not like all humans are born knowing how to read and
| write Markdown. A standard that is _slightly_ less flexible
| or intuitive for (some) humans while enabling _vastly_ more
| machine applications could be a win.
| Shog9 wrote:
| Could be, but mostly isn't. This thread and others like it
| are always full of folks lamenting that some other markup
| language isn't as popular or well-supported or both, even
| though said language has more features, a better spec, and
| got there first.
|
| Maybe Markdown just hit the sweet spot. But I actually
| suspect it's something else: as soon as it's _very_
| convenient to have machines ingesting and producing a
| language, it becomes tempting to create tooling that is
| unnecessarily strict in what it will accept while at the
| same time spitting out markup that is unusually difficult
| for humans to read. A sort of specialized violation of the
| Robustness Principle.
|
| The most famous example of this was probably XHTML, but
| even HTML5 suffers from it. And so we end up with stuff
| like Markdown because HTML tooling is too hostile to work
| with directly, and AsciiDoc because DocBook XML is
| similarly awful. They don't _have_ to be, but...
| 0x3444ac53 wrote:
| I second this. I discovered Djot last year and it's been my
| preferred markdown ever since. Very extensible, easily
| parsable.
| jerpint wrote:
| The author didn't mention the arguably most popular python
| frontend library: gradio
| ForHackernews wrote:
| I've never heard of this and I've worked with Python for
| decades. Maybe it's only popular in certain corners of the ML
| world?
| Ferdie wrote:
| Taipy is 2 years old. It was developed not only for Data
| scientists but also with end users in mind. First, Taipy was
| created because we failed miserably when we tried Python GUI
| tools on real data/AI projects. We tried with tools like
| Streamlit or even with Gradio. These are ok for having a
| quick pilot for data scientists not for real projects. In
| addition, we wanted to embed the concept of scenarios in our
| backend to easily perform what-if analysis, compare your
| executions, etc. We can go into more details if you are
| interested to delve deeper into the advantages of Taipy:
| performance, support for large data in your gui objects,
| style kit customization, gui events, sync/async calls, etc.
| ForHackernews wrote:
| ...this really sounds like an ad.
|
| I am not in the market for any of this stuff, but as a
| piece of advice HN readers respond much better to technical
| marketing than anything that smells like sales copy.
|
| If you were you going to rewrite this, I would expect to
| understand WHY your thing is different or better. Does it
| render faster? Does it have a cleaner API? Is it built on
| different primitives?
|
| "These are ok for having a quick pilot for data scientists
| not for real projects." <- this sentence doesn't mean
| anything.
| fzumstein wrote:
| Never heard of it either. "Build and share delightful machine
| learning apps, all in Python." I am wondering what the heck is
| so special about "machine learning apps" that would
| differentiate them from any other app that has a UI with a
| Python backend.
| mitjam wrote:
| It is optimized to demonstrate models, to create interfaces
| for training, and to gather feedback, Interface is input ->
| model -> output. All in browser, has many good and easy to
| use components and you can let it run on Huggingface with a
| oneliner.
| Kwpolska wrote:
| That's an advertisement. And the idea isn't really groundbreaking
| or novel, just some custom tags in Markdown that can run
| arbitrary Python code and offer some basic two-way interactivity.
| dpflan wrote:
| Agreed, plus I must imagine that Python's opinion on syntax and
| whitespace may not make this a most ergonomic solution.
|
| Where does this verge into the realm of a Jupyter notebook? And
| why would this be better than such a notebook? The usecase for
| this markdown and rendering is... vs. a notebook? Genuinely
| curious about this, because sure you can make code do stuff,
| but is it worth it?
| 7thaccount wrote:
| I haven't really looked into Python GUI stuff much since the old
| TKinter, WxPython, and Qt days (5-10 years lol). Every now and
| then I check if a decent table widget exists like C# has had
| forever, but it seems like I'm always disappointed as the ones
| I've found can't handle much data or don't have filtering or
| whatever. Has this changed yet?
|
| Eventually, I settled on a workflow with Python as a scripting
| language, but I avoid any UI stuff. If I need good charting, I
| just build Tableau or Power BI displays to consume the Python
| outputs that I've already pushed to a SQL database for analysis
| anyway as the data I'm dealing with is generally fairly large
| (i.e. gigabytes were generated while I wrote this reply).
|
| I certainly get the appeal of doing everything in one language
| and there are some efficiency gains for sure, but sometimes
| (especially dealing with data science folks), I feel like they'd
| be much better off if they could learn common unix command line
| tools and SQL and add that to their arsenal. They all say they
| know SQL, but can't do much outside of "Select * from table;" and
| then spend a ton of time working around local Python memory
| limitations, which sometimes just means using a tiny dataset that
| they can actually fit into memory. I got a little off topic
| there, but wonder if anyone else has experienced something
| similar?
| SonicScrub wrote:
| I gave up a long time ago attempting to write GUIs in pure
| python. I've come back to them periodically to see if the
| landscape has changed, but I'm always disappointed.
|
| My current go-to python GUI solution is to use the Eel library.
| It renders GUIs in a web-browser like window with
| HTMl/CSS/JS.It lets you expose your python functions to
| JavaScript, so data can be easily transferred back and forth
| between the python and the JavaScript. And since it's just web-
| dev, it's pretty easy to make things look and feel good enough.
| Any other web-dev libraries like bootstrap and jquery can be
| used. It works pretty well for writing GUIs that put data
| analysis tools in front of my colleagues.
|
| https://github.com/python-eel/Eel
| lifeisstillgood wrote:
| The major problem is having me visualise what is going to come
| out of the process
|
| Every markdown-like language has some underlining and bullet
| points. I can handle that. Once we get into using graphviz / some
| other tool for drawing charts and graphs I simply lose it.
|
| It is in the end much easier to knock up something in PowerPoint
| / Visio / paint tool than be clever with graphviz.
|
| The only arguments against this are
|
| 1. Maintenance - and yes it's a good argument. Changing the name
| of one box should be easy - but it is with some paint tool too.
|
| 2. Graphviz etc are much more "programmable". Slapping together 6
| boxes for your network diagram is easy. 150 is what graphviz is
| _for_.
|
| The problem is that you stopped using markdown the minute you
| went "oh, 150 boxes with edges between them." At that point you
| have to use "some other tool".
|
| Maybe that tool is taipy, or graphviz or he'll LaTeX is great for
| this - but you need to master the tool _then_ you get great
| results.
|
| So things like this should be
|
| "If you are already fluent with graph production in LaTeX, use
| this tool That links latex to markdown"
|
| Otherwise spending a large chunk of your undergraduate thesis
| learning how to use the tool might not work so good.
|
| Summary:
|
| Just use dead simple plotly graphs in your sphinx docs. Something
| like "total number of words bar chart".
|
| Then it's there and you can expand it as much as you can before
| you hit the complexity limit that is just simpler to grab a
| visual drawing tools and store a binary.
| rogue7 wrote:
| Looks cool !
|
| Makes me think of Voila [0], in my opinion one of the most
| powerful solutions to build interactive app with python. It
| requires Jupyter notebook, IPywidgets and e.g. BQPlot.
|
| [0] https://voila.readthedocs.io/en/stable/
| Jenk wrote:
| I've started using asciidoc[0] and find it much more friendly
| because it is both better specified and flexible.
|
| [0]: https://asciidoc.org/
| goodpoint wrote:
| https://asciidoc.org/
| networked wrote:
| Is there a Python library that uses Markdown or another
| lightweight markup language like reStructuredText for TUIs?
| verdverm wrote:
| I've been using MDX and really loving it. Mixing code and markup
| fluidly is really nice.
|
| Was hoping this was the analog for Python, but it seems the
| content is still strings.
|
| i.e. parse markdown with code vs parse code with special strings
| tambourine_man wrote:
| Mobile version of the website is broken by image overflow
|
| https://i.postimg.cc/05btvjQ5/IMG-1590.jpg
| throwaway892238 wrote:
| Every developer needs to learn two lessons about great
| interfaces:
|
| 1. Layout, format [aka style], and interactivity, is both hard
| and necessary
|
| 2. Interfaces are subtly complex
|
| Number 2 is the reason that "simple" formatting markup, like
| Markdown, will never be good enough to make a great interface.
| You can make a poor interface with Markdown, and that poor
| interface is good enough for very simple use cases. But people
| quickly get annoyed by simple use cases. They create friction,
| both for the designer and the user. More useful functionality is
| desired, and you need something more complex to enable that.
|
| I've written a lot of tech docs. Markdown is one of the worst
| methods I've found to write them. Not because its formatting
| isn't intuitive, easy to remember, and easy to use. But because
| the documents it creates are not conducive to the purpose of the
| document: making it easy to read and remember information.
|
| As for more general interfaces, the easiest way to understand why
| you need more elaborate methods, is HTML. When HTML was created
| by Tim-Berners Lee ~1990, he intended for format and layout to be
| independent and configurable. However, for years it lacked both
| formatting and layout options, and lots of people complained. It
| took _six years_ for CSS to eventually become a standard, and
| before that, lots of hacks and incompatibility (and it turned
| out, more of them afterwards). The entire time people were
| complaining about how any document editor could easily format and
| layout exactly what the author wanted, but web browsers persisted
| in being difficult and inferior. Tables were only added in HTML
| 2.0, five years after the Web 's birth.
|
| You can still get by with not-very-good markdown, for not-very-
| good interfaces. But you will never have a Great interface
| without the ability to control layout, format, and interactivity,
| in subtly complex ways.
|
| There is no easy way for a human to do that _with text_. But
| there is an invention that enabled users to create complex and
| rich layout, formatting, and interactivity: the WYSIWYG
| interface. With this tool, the human no longer needs to remember
| control characters, markup syntax, or formatting codes. The user
| no longer needs to spend endless time typing in code, displaying
| the result, being unsatisfied, and tweaking the code again,
| trying desperately to just get the screen to show them what they
| know they want. A WYSIWYG editor enables a human to completely
| discard any knowledge of _how_ to format or layout content, and
| instead simply move things around on their screen with a mouse,
| completely eliminating complexity for the human, and enabling the
| creation of better content.
|
| I think the reason modern software abandoned WYSIWYG, is that
| modern software isn't created for users. Most modern software is
| open-source (or close), and as such, it's created by developers,
| for developers. Developers don't want to spend time engineering a
| WYSIWYG, because they have no need for a good interface, and they
| don't care about wasting their time writing code. To them,
| writing code is the whole point, regardless of how long it takes,
| or what the outcome is. That's why Markdown was invented, and why
| people persist in trying to force Markdown to make something
| better, without realizing that that's impossible. They want to to
| build a castle, but they don't want to use anything other than
| the twigs and rocks lying about their feet.
| MilStdJunkie wrote:
| Every time you glue on an extension to your markup language - or
| do a specialization with DITA, or modify S1000D via the BREX, or
| combine a dozen different MIL-STD DTDs to write your snowflake
| publication - you've reduced the volume of the tools ecosystem
| needed to render and write the thing. If _everyone does this_ ,
| you're effectively using a bespoke doc spec for each application,
| or even for each program or product.
|
| Not all computing platforms allow users to do whatever.
| Eventually these disparate doc platforms will need to get merged,
| updated. What happens when _Restrictive Platform X_ needs to
| update your Special Format? They fork, and they use a doc markup
| that 's workable on a generic platform. Welcome to Double Work
| Town.
|
| Anyway, it's pretty important to select a markup whose core
| specification does all the things you _need_ on a generic
| computing platform[1]. Many different paths branch from that one
| singular fact, but I 'll stand by that singular fact. Seen too
| many decades flushed down the toilet of churning doc/markup
| formats.
|
| [1] That _doesn 't_ require _frickin admin access_ for trivial
| writing tasks, like changing DTDs.
|
| _< cough>Arbortext</cough>_
| 0thgen wrote:
| I think it would be nicer if the tool worked in reverse; that is,
| rather than making a markdown string inside a python script, just
| run the python from markdown (similar to the approach r-markdown
| takes).
|
| Then, the part where you do "Gui(page=my_page).run()" just
| becomes a build script that happens in the background, rather
| than requiring the coder to have a bunch of isolated markdown
| snippets throughout their code
___________________________________________________________________
(page generated 2024-01-21 23:01 UTC)