showell

Yep, my mention of do/end or squigglies was just a caveat on the Ruby-is-more-terse-in-this-example statement in the context of anonymous functions or blocks. I wish there was a language that won on both terseness metrics--i.e. a Ruby with indentation or a Python with anonymous functions.

First of all, your objection to anonymous functions with an example that names the function in two different places kind of takes us off topic from the discussion of "anonymous" functions, but I will still respond.

Second of all, multiline-lambdas are already possible in Python, but they are not anonymous functions.

Anonymous functions, as I said, allow for rich syntax; they do not affect the Turing completeness of the language. The context I am speaking of is "expressibility" in the sense of natural language, not whether or not something is expressible at all.

Ruby allows you to do stuff like this fairly naturally:

def process_event_until_timer_expires # check time, then call block only if # timer not expired end

process_events_until_timer_expires { |t, event| puts t fire_event_downstream(event) }

Having an anonymous function here allows you to read from outside in, which is more natural. From the outside, you know you are in some event loop, then you can look inside the block to see the details of how the event are handled. It's really that simple. Not earth-shattering different than Python, just subtly different and more expressive.

I've been using Python for a decade, and Ruby's still overly exotic to me, so I am sympathetic to people that defend the more Pythonic approach. But Ruby does allow for a different kind of expressiveness here.

Javascript also makes heavy use of anonymous functions, and if you use anonymous functions in other languages, you realize that they have value, even if they are occasionally abused and technically unnecessary.

I don't think the fights should be vicious, but I think the stakes are fairly high, and even though Ruby and Python are close cousins in the grand scheme of things, they really do represent profoundly different philosophies when you look more closely at the languages. It would be nice if these differences could always be discussed with civility, of course.

I use both Ruby and Python enough to appreciate that both languages generally make important tradeoffs with good intentions, but I don't always agree with the results (in either language). I also find Javascript often has an interesting relationship to both languages.

You might be taking the statement out of context, and you are certainly quoting it out of context (although brevity is appreciated.)

The statement in the talk was made to illustrate the differences between Ruby and Python, and it was not made to suggest that Ruby was replicating all the benefits of Lisp.

Decorators and annotations are very useful in Python, but I still like the terseness of Ruby--no need to define "hello()". Of course, Python wins on a different kind of terseness--no do/end--but that is mostly orthogonal.

I wholeheartedly agree that all languages should be judged on the quality of their libraries and implementation, as well as the success of the projects implemented on top of them. Ruby and Python have a pretty good track record there.

One of the themes of Gary's talk was that Ruby is more expressive/flexible than Python, and lisp was thrown into the discussion as sort of a "gold standard" of expressiveness/flexibility, without necessarily passing any judgment on overall merits of the three languages.

To the extent that Ruby strives for more flexibility, it is probably way more influenced by Perl than lisp.

As somebody who has used both Ruby and Python fairly extensively, I think Ruby is undeniably more expressive than Python at times, but also more arcane at others. Some of the differences probably come from irreconcilable tradeoffs, where you cannot have your cake and eat it too, but other tradeoffs are probably less necessary, which is why people continue to discuss it. In the case of Ruby, it's a pretty young language, so there are probably opportunities to make it more appealing to a Python mindset without losing its great flexibility, although I do not have specific proposals.

The conference Gary spoke at was a Python conference, so most people were more interested in ways that Python could learn from Ruby, without sacrificing Pythonicness. Gary seemed to reach the conclusion that the number one feature he envied in Ruby was blocks. Speaking for myself, I wish Python just had some kind of anonymous function syntax that was more rich than lambdas, even if it were not exactly semantically similar to Ruby blocks.

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.

The Laurnence Olivier analogy is stupid, inaccurate, and irrelevant.

If 0.001% of the world's population uses it, I think that comes out to something like 60,000 people.

You can see here that I've already solved the problem of sharing SHPAML output using HTML:

http://shpaml.webfactional.com/

You are right about it adding a step to my workflow. If only there was some kind of machine that could automate things for me...

This seems like a wild exaggeration:

"The behaviour of every function in a mutable, imperative environment is dependent upon the state of all of the other (variables|attributes|bindings|whatever) in your program at the time the function is invoked."

You can write a function in an otherwise mutable and imperative environment like Python:

pi = 3.15 # damn, typo for the value of pi! pi = pi * 15 # mutate it, wrongly again

def sum(a, b): return a + b print sum(7, 8)

Please tell me how sum() depends on pi. The program correctly prints 15.

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?

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.

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?

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

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.

The movitation behind SHPAML isn't necessarily just to make the markup easier to write; it also tries to make it easier to read.

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.

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.

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.