What are your thoughts on HAML and SASS? They aren't simply "cuter" they are a full-blown templating and stylesheet meta language. I've been using SASS in a Python project and love it. The more I use SASS, the more envious I grow of people who get to use HAML.

I was intending on eventually writing my own HAML-type language in Python, but it looks like with SHPAML, I won't have to. Because SHPAML supports raw HTML and doesn't do anything with the {} characters, I can use SHPAML in conjunction with my existing Jinja2 templates. This will enable me to convert my templates organically. The intermediate HTML/Jinja representation doesn't need to appear on disk, so this really looks like an easy way to add "cute" HTML syntax to and existing Python text templating language.

i use Markdown (http://daringfireball.net/projects/markdown/) regularly rather than directly writing HTML. like this thing, it's also just syntactic sugar, but it's well-designed and makes it so that i can concentrate on writing and not on formatting syntax. my raw text files are much more source-control friendly, since the diffs are clean.

Markdown is different, though. Rather than trying to cram HTML into a yet another pseudo-programming syntax, it tries to generate HTML that matches common plaintext-formatting conventions. You might not guess Markdown-formatted text was written with a formal markup language in mind.

FWIW, there's a C implementation of Markdown called "discount" (http://www.pell.portland.or.us/~orc/Code/discount/) which is crazy fast, easy to embed, and has a couple nice extensions.

(Also, "SHPAML"? Gross.)

First of all, sorry about the name.

SHPAML is not a pseudo-programming syntax. It is purely a markup language, so there are no programming constructs.

SHPAML very deliberately tries to be a lightweight abstraction on top of HTML, unlike wikis and Markdown, which operate at a higher level abstraction. I am a huge fan of wikis, so I value the higher level abstraction at times, but I also see the need for an in-between solution.

I have not used Markdown much, but I see its merits as well.

That came off more harsh than intended. It sucks to post something you're excited about and have lots of people digging into it.

I'm not being critical of your tool in particular so much as wary of the flock of thin syntax transformers that have come out lately. They're fun projects, but adding yet another mutually incompatible data format is probably only a net gain under relatively specific circumstances (small teams, for starters). I like Markdown in this regard because it's downwardly compatible with how people would write anyway. You're right that it's at a different level of abstraction, though.

And about the name - I'm really tired of hearing the same Monty Python jokes all the time, but that's my problem.

I understand the objection to having too many mutually incompatible data formats, but I don't understand how Markdown is exempt from that concern. It achieves the goal of looking like what "people would write anyway," but at a higher cost in terms of departing from HTML semantics. For example, how do you indicate semantic structure via Markdown to allow for CSS styling or Javascript manipulation of the DOM?

Is it just cuter if it means less typing?

The difficulty of programming isn't from having to type too much, it's from solving problems.

The difficulty of writing HTML is mostly having to type too much. Writing HTML isn't programming.

HTML isn't meant to be written directly. It's an output form, like Postscript or PDF.

Gravedigging a bit here, but WTF dude?

I've started authoring websites in 1996 with just Notepad and I still hand-write my HTML on a daily basis.

The problem with HTML has been (and will be, for a long time) that there is no WYSIWYG editor that can offer quite the same quality as handwritten HTML.

In fact, if you're dealing with HTML from a WYSIWYG perspective, you're most likely ignorant of the language. The distinctions between divisions and paragraphs, between links and spans, are not something that is adequately reflected by an input editor purely concerned with visuals.

Just as the purpose of CleverCSS or it's Ruby predecessor is making it easier to write CSS by cutting down on the redundancy (and even by increasing the level of abstraction a fair bit), the purpose of SHPAML is making it easier to write HTML by cutting down on the redundancy of closing tags, angle brackets and the verbosity of divs, spans, ids and classes, thus letting you express more directly what you mean.

You don't have to like it. It's mostly a stylistic choice, but it means little overhead and can help HTML authors a lot by cutting down on the usual boilerplate. Just like frameworks and syntactic sugar make it easier for programmers (though the argument could easily be applied to them as well -- how dare they find it easier to code with less boilerplate if the actual writing is the smallest part in creating a functioning program).

I agree. Nor do I call them beautiful.

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

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.

While it's less significant for HTML than code, verbose languages are problematic during reading as well as writing.

While generating stub code for class declarations, getters, setters, etc., can help with writing boilerplate-y OO code quickly, anyone trying to read it to decipher its intent will still have to deal with all the clutter. That's more likely to cause problems in the long run.