
Beautiful mini language for outputing HTML in Python - iamelgringo
http://shpaml.webfactional.com/examples
======
capablanca
I no longer fall for languages that only change the syntax for something the
author thinks it's cuter...

~~~
olalonde
Right. I don't see any use case for this syntax especially that modern IDEs
offer auto completion .

~~~
showell
Modern IDEs inject close tags and angle brackets into the source document. The
SHPAML preprocessor injects that syntax into the target document. The use case
applies to the person who wants clean syntax in the source document and
executable syntax in the target document.

------
nir
Why are most comments here negative? HAML already shown this technology does
have value to a significant amount of people. Someone took the time to write
this, seems to have done a pretty nice job and is releasing it for anyone to
use. I can't see why anyone would feel the need to put it down in the
comments. If you don't like, just don't use it.

~~~
njharman
Because;

1) by posting link to it on discussion site you are assumed to be soliciting
opinions.

2) it was called "beautiful". A claim so false as to require immediate and
forceful contradiction.

~~~
nir
1) As an HN submission, it's certainly better than most. Anything with code in
it beats "Startup lessons from J-Lo".

2) Beauty is a matter of taste. It might not be the Bar Rafaeli of languages,
but I wouldn't think it's so ugly as to require "forceful contradiction".

~~~
wensing
I like what I see of the DSL, but I don't believe meritorious beauty is a
matter of taste.

Coke vs. Pepsi - taste

Python vs. PHP - not-taste

For a better explanation, see: <http://www.paulgraham.com/taste.html>

~~~
nir
I think we're in agreement. My distinction is:

Beautiful vs Nice - taste.

Beautiful vs Ugly - not taste.

So, since it's obvious this DSL isn't ugly, being less than beautiful doesn't
really merit HN's negative response.

In any case, the negative comments seem to be doing great, which is sad for
HN. My experience is that people who actually produce stuff (in any field)
aren't usually publicly critical of other people's work, since they can
appreciate the effort involved, and don't want to be at the same spot when
they release their own work.

~~~
scott_s
Criticism is not a bad thing.

------
apgwoz
I'm not a big proponent of all of these new HTML replacers. They don't really
buy you anything--this one just gets rid of angle brackets as far as I can
see, and adds CSS style #id and .classname. Now, instead of angle brackets, we
have to use tabs, or spaces, or some other delimiter (I saw | in there for
continuing a line).

The best way I've found of representing XML/XHTML or even HTML for that
matter, is with X-Expressions--a subset of S-Expressions. But, they are most
useful in a language that fully supports S-Expressions, like Lisp, since you
can then use standard functions to generate your markup for you.

~~~
davidw
Yes, I think that for HTML, "better tools" is the right answer. HTML is
something that can be shared between people with various backgrounds, skills,
and toolsets. I can write it in Emacs on Ubuntu, and send it to some guy who
will work on it in Windows with Notepad, who can send it to someone else who
will open it with Chrome on a Mac.

These things might be ok for small, tight teams, but I don't see them as
buying that much in the long term, as opposed to tools that let you be more
productive with HTML.

~~~
mtomczak
I believe that I see your point, and I would agree that the verbosity of HTML
leads to sharability, and that is a strength.

But the verbosity is also one of its weaknesses for large projects; it adds a
great deal of overhead in terms of keeping track of the tags, especially if
the HTML needs to be re-arranged. And with no language-supplied rules for how
much whitespace to use or where (beyond "all adjacent whitespace is
compressed"), there is too much flexibility for a large team to work smoothly.
My usage case doesn't mesh with your example, because I'm working in an
environment with version control and multiple developers. The guy using
Notepad will be told to get a tab-aware text editor, because his changes will
mangle the whitespace in the file and lead to unnecessary noise when he
commits.

When structure in your whitespace is already desired (to avoid making your
version control noisy), you can leverage the fact that you are structuring the
whitespace to make it a semantic element. This greatly decreases typing, makes
the code easier to eye-scan, and allows details such as proper closing bracing
to be left to the compilation tool and not to the developer. I agree with
commenters who have noted that HAML has been proven useful for some
developers.

I would categorize both SHPAML and HAML as tools that let you be more
productive with HTML.

~~~
davidw
It's not the verbosity or lack of it that makes it shareable, it's the fact
that it's a standard.

Some of these inventions are a bit nicer than the original thing, but not so
much that I'd give up being able to share the code with pretty much anyone and
everyone.

I can do HTML pretty quickly with Emacs' psgml mode, and I'm sure there are
other people who specialize in it who can do it even faster with other tools.
I think that's the place to look for improvements, rather than generating it
like machine code.

~~~
showell
When you run SHPAML through the preprocessor, it produces HTML that you can
share with other people. So it's not that big an issue. Your greater point is
well taken, though--using SHPAML is particularly suited to small teams.

~~~
silentbicycle
Things can get messy if people sending you patches for something generated,
rather than patches for the original source, though. Most such transformations
aren't trivially reversible.

~~~
showell
I understand the use case, and if people are frequently sending you patches
for your HTML, you probably want to make HTML the authoritative source. Do
people frequently send you patches for HTML that you author? SHPAML does not
allow you to trivially reverse HTML patches, but it does allow you to manually
apply them without too much pain, as it lets most HTML pass through
unmolested. I actually source control my HTML output to be able to see diffs
on the HTML, for what it's worth.

------
Jim_Neath
I like HTML. I like the way it looks. I like writing it.

On the other hand, I don't like new DSLs for writing what is already a simple
markup language.

~~~
eru
HTML is a bit verbose.

------
nicpottier
I kinda like it.. sure it is one more level of abstraction, and good editors
will help with the tag balancing, but let's face it, (X|HT)ML syntax isn't
exactly natural to write, and I say this despite having written it by hand for
well over a decade.

This probably appeals more to people who have made the Python jump and like
that whitespace means something, as that's what really makes it terse.

~~~
showell
SHPAML is definitely targeted at Python users and people who like meaningful
whitespace (and associated terseness).

Glad you like it! I have also been hand writing HTML for well over a decade
too (as well as other means of producing HTML), so my goal in SHPAML was
simply to relieve pain points for an everyday task. It has worked for me.

------
amitu
One reason to use this would be to get well indented HTML.

Finding the potentially missing closing </div> tag has been a common problem I
have seen some people face.

------
andrewcooke
this could _almost_ be embedded, which would be much cooler i think. you'd
have to define objects with names from html tokens and do some ugly hacking
with python's operators. you'd also have to add something other than space
between strings (a "+" might be ok).

but once you've done that, this could be very neat. no processors - just
constructing html in python.

(i don't know if this sounds crazy or not, but you can see the same kind of
approach in lepl, which i wrote. the main problem is operator precedence.)

~~~
showell
Other folks have tried to solve the problem of cleanly creating HTML from
within Python itself, which I think is what you are alluding to. It's not a
goal for me. To the extent that my markup is pretty static, but the content is
dynamic, I try to use a templating language beneath SHPAML. If the structure
of the page itself needs to be dynamic, then I probably want to serve up JSON
to the browser, not HTML, and then let Javascript manipulate the DOM, taking
HTML (and SHPAML) mostly or completely out of the equation. I think there are
some cases when you want the power of the server-side programming language to
help you build documents, but that is often a smell that your documents are
overly complex, or that your templating language is weak, or that your UI is
too complicated for browsers, or that your client-side code isn't pulling its
weight, etc.

~~~
andrewcooke
so, if i understand right, you think it's better to implement it as a separate
language to stop people doing things that you don't think they should do, or
think they don't need?

apart from stopping people from doing things, are there any what you might
call "positive" reasons - advantages - to doing it your way?

~~~
showell
If my post made it sound like I am trying to stop people from doing anything,
then it just came out wrong. I do think there are legitimate reasons to mostly
build documents within a full-featured programming language, and I wouldn't
stop people from doing that. I prefer to build the markup itself in a markup
language with lightweight syntax, because documents should be readable, and
markup languages have syntax specifically tailored for document readability.
Then I supply dynamic content via the templating language.

------
RyanMcGreal
> If HTML were truly awesome, then you would not have Wikipedia; you would
> have Htmlpedia.

I don't buy this. The problem with HTML is not that it isn't expressive enough
or that it's too hard to use; it's that arbitrary user code can easily
compromise the integrity of your website.

~~~
showell
I wrote the comment about Wikipedia only to illustrate that HTML, like any
standard, is not perfect for every use case.

I find HTML expressive and generally easy to use. I wrote SHPAML in a way that
I hope preserves the useful expressiveness of HTML, while eliminating some of
the 1990s-style syntax.

------
wglb
Browsers care about how html looks. We should think of html and css as the
assembly language--generated by some server-side process.

------
mattmcknight
I prefer XML Builder templates (in Rails or Groovy) to this approach. It's
similar, but SHPAML just drops enough stuff to have to be learned. You
basically already know how to write Builder, it's that simple.

------
prodigal_erik
I'm disappointed they resorted to a one-way preprocessor. Is it really not
feasible to make a first-class domain-specific language like this in Python?

~~~
showell
The reason I made SHPAML a one-way preprocessor is that my use cases haven't
yet given me a compelling reason to write a round tripper, and preprocessing
is simple to automate.

I do not know what your criteria are for judging a "first-class" DSL in
Python, so I cannot comment on the feasibility. My goal was to create a simple
markup language that maps well to HTML and plays nice with templates. SHPAML
does that.

~~~
prodigal_erik
Sorry, I misread the title "Beautiful mini language for outputing HTML in
Python" as a DSL to be embedded _in Python code_ rather than a separate text
file (which is actually language agnostic after the preprocessor is done).

~~~
showell
No worries. I am actually curious to your thoughts about DSLs. I love Python,
but it is not really optimized for DSLs. You can obviously implement a DSL in
Python, but embedding it is another story.

------
teehemkay
The language may be prettier than HTML but the name looks rather ugly to me.
Doesn't sound as bad though :-)

------
dan_sim
Is HTML that hard to write?

~~~
olegk
Good HTML is hard to write. Look up HTML source of several major websites, and
you will see how badly indented it is. 95% of them won't validate. Look at
this page. It doesn't even have a doctype.

~~~
wensing
That's largely because it's hard to care.

Browsers don't halt when fed less-than-good HTML the same way an
interpreter/compiler dies when fed bad syntax.

------
drhowarddrfine
There's just something wrong about creating a language with a language to
produce about in a third language. As Brian Kernighan told Dustin Hoffman one
time, "Learn to code!".

~~~
nopal
While your language^3 comment is technically true, this seems to be simply
shifting one markup syntax to another, using a language to perform the
translation.

In addition, using something like SHPAML requires knowledge of the final
output syntax, so the person using it must already know how to code.

Edit: In reading my response, it seems too curt. I definitely see your point,
but more so in contexts other than this.

~~~
showell
It is not a promise, or even a goal, of SHPAML that it will relieve you the
burden of understand the final output syntax, whether that is HTML or HTML
combined with some template language.

SHPAML users are expected to be literate in both HTML semantics and syntax.
The semantics of HTML are not abstracted away at all. The syntax is only
abstracted away where it is redundant.

As a couple folks have pointed out, HTML is a pretty simple language. The
problem with HTML is not its lack of simplicity; it is its verbosity.

So, if you use SHPAML, you undeniably get the terseness of SHPAML and the
powerful semantics of HTML. So the question then comes down to simplicity.
Does SHPAML eliminate too much of the simplicity of HTML syntax in trying to
achieve terseness?

------
jmonegro
I don't see why I would use that over this: <http://lab.xms.pl/markup-
generator/> Not only does it have the same syntax (with some improvements),
but it also gives me the CSS to work with. AND I don't have to install python.
Hooray.

~~~
showell
You don't technically need to install python to use SHPAML. You can try it
online:

<http://shpaml.webfactional.com/tutorial/7>

SHPAML is mostly targeted at Python users for now. If you are not using
Python, but you like the idea of having a syntax layer on top of HTML, then
you should consider other solutions like the markup generator or haml.

~~~
jmonegro
Still, the markup generator gives you CSS markup as well.

~~~
showell
Ah, that is indeed a nice feature. When I first looked at haml, I was all
about the indentation (being from Python) and rather skeptical of the CSS
sugar. But once I ported the CSS sugar to SHPAML, I found I started writing
better markup. I haven't bothered to automate any CSS generation from SHPAML,
not because I don't think it would be a useful feature, but because I have a
lot less experience with CSS to know what the pain points are. (I have pain
points with CSS, but they are either just due to my own ignorance or problems
not easily solved.)

