Hacker News new | past | comments | ask | show | jobs | submit login

To fix the ambiguous grammar, we need to add a url parser to markdown? This is a perfect example of how changes that seem simple to humans can have enormous impacts on software complexity. As you said, introducing that complexity wouldn't help in many cases:

  Blah blah blah (side note)[1](#ref_1).
  Blah blah blah (side note)[1](ref_1.html).
I don't mean to be hostile, but just because something is "doable" doesn't mean it should go in the spec. Adding things to a standard imposes costs that feature-proposers rarely consider. It forces programmers to write more code to support that feature. More code means more bugs. These bugs annoy users and cost valuable programmer time. Multiply these costs by the number of times the standard is implemented and you can easily end up with millions in lost value.

Vanilla markdown doesn't require a url parser. It doesn't have ambiguous grammar. It's small. It's simple. And that's a good thing, because markdown parsers have enough bugs in them already.




1. URL parsing is a solved problem. Since I so frequently have my competence questioned on HN, I have to conclude that if I can do it, anyone can.

2. There are a number of people in this thread, and many many many more on Reddit and on other forums that use markdown, that have had a specific UX problem with markdown which we can solve. The solution will not solve all possible problems, but it will solve many of them.

3. I subscribe to the Linus Torvalds camp of software development, which is that software exists to solve user problems.

4. While the trade-off between additional code complexity (and better overall user experience) versus simpler code (and poorer overall user experience) isn't always justified, in this case I think it is. I mean, HN parses URLs for you and makes them clickable -- would you really support removing that as a feature, in favor of having simpler code, and having to copy & paste links into your browser?

5. This particular feature rather nicely lends itself to extensive testing so that you can make sure you've covered most of your edge cases. If we decide not to implement solved, testable features out of fear that some other programmer might not implement it correctly or test it thoroughly enough, then I don't know what to say about our industry other than that it's going to come to a standstill.

I'm afraid that's all the energy I have tonight for arguing about things I don't really have any influence over on HN.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: