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.
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?
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).
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.
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.
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".
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.
I did not post the link here, nor did I call anything "beautiful," but I presume that the reason the original poster posted the link on a "discussion" site was to solicit "discussion." Immediate and forceful contradiction does not equate to discussion, even when the claim is "so false" as this one.
One of the primary benefits I get from HN is the pro and con discussion of technology, especially if it's something I might want to use. If there are good reasons not use a technology, then I would rather hear about them before I rediscover them from my own experience.
As the author of SHPAML, I have no problem with all the negative comments about lightweight syntax abstractions, as I've seen all the same arguments written against HAML. Most of the critics of SHPAML have probably never actually used it, nor do I expect them to if they don't share the same pain points as I do. Nowhere do I make any claims that SHPAML is going to cure all problems. It does make producing HTML easier for me.
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.
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.
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.
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.
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.
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.
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.
SHPAML replaces angle brackets and close tags with space-based indentation and pipes. The CSS sugar for #id and .classname is completely optional, and obviously if you know CSS, then the syntax should be familiar.
I agree that there are plenty of other useful ways to represent XML/HTML.
SHPAML does require or even support tabs. The "|" is not for line continuation; it is to separate markup from content.
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.
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.
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.)
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.
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?
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.
> 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.
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.
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.
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?
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.
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).
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.
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.
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!".
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.
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?
Pulling your leg. Hoffman, who had learned in the "method acting" schools, apparently stayed up all night to look properly harrowed for a scene. Laurence Olivier, playing opposite, is said to have told him something like "Why don't you try acting, my boy? It's so much simpler."
What is the problem with using one language to produce another? How do you think your primary programmin language gets converted to assembly and then to machine code?
As far as I am concerned this is a useful abstraction on a trivial problem.
My problem with HTML is not its lack of simplicity; it is its verbosity. SHPAML solves the (fairly) trivial problem of making HTML less verbose. The abstraction pays off for me insofar as I expect to use SHPAML for the next decade or so, and it's easy to remember the syntax, easy to share the output, etc.
Yeah, but how many other people will be using it? You may be planning on using it for a decade, but you will be in a very small minority. And so to share the output (the very common and portable HTML), you need to add another step to your workflow to convert things. This just seems like too much effort for very little gain.
Well machine language is pretty simple especially when you use something like MIPS. It can even be pretty fun to code in if you assembler has good macro support. However there is value is adding an abstraction layer on top of machine code. I think what people are really trying to say in these comments is that this new mini language does not provide useful value vs HTML like C provides vs. MIPS. Cheers.
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.
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.
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.)
