NeoCities (neocities.org)

I fail to see how using equal signs for assignment (or for defining assignment methods) is a problem with syntax, rather than an enhancement to clarity.

> unquoted regular expressions

What's wrong with that? Regexes are a different type than strings. Why should they look like strings?

> exclamation points

...again, so, what?

> absolute value bars

vertical bars used to set off block argument lists aren't absolute value bars. (Neither are vertical bars used for logical-or.)

> at signs

Again, so?

> You can't even sort-of follow what this code is doing without searching through the manual every third character.

Yes, I can, and not just "sort-of follow" it.

> Ruby syntax is worse than C++ and almost as bad as Perl.

There's no accounting for taste, I suppose.

> there are a large number of syntactical ambiguities, so writing a parser for it should be completely impossible

As Ruby does exist, and is parsed, this is clearly not the case. That said, ruby's syntax is not optimized for machine parsing, its designed to be ruby-developer-friendly rather than ruby-parser-developer-friendly.

If you want something optimized for the developer of the language's parser, look to Lisp.

Oh, the inability to parse Ruby shouldn't be held against it. It has (at the least) a context-sensitive grammar. So do lots of languages, including HTML and perl.

Not being able to parse it doesn't really mean what you think it means. It just means that in order to figure out what it does programmatically, you have to evaluate it. Its unparseability makes certain things impossible, like writing a perfect syntax highlighter. Also makes building certain tools you'd normally see in an IDE difficult.

    // Parse tags string.
    // Example:
    // "tag1, tag2" => {"tag1", "tag2"}
    // "tag1, very long tag" => {"tag1", "very long"}
    string[] NewTags(string tags_string)
    {
        //Allow only letters, numbers and spaces in tag.
        tags_string = new string(tags_string.Where(c => char.IsLetter(c)
            || char.IsNumber(c) || c == ' ' || c == ',').ToArray());

        //Separate multiple tags with commas.
        string[] tags = tags_string.Split(',').Select(s => s.Trim()).ToArray();

        //Two word per tag maximum (extra words in a tag will be removed).
        for (int i = 0; i < tags.Length; i++)
        {
            List<string> validWords = new List<string>();
            string[] wordsInTag = tags[i].Split(' ');
            if (wordsInTag.Length > 2)
            {
                tags[i] = wordsInTag[0] + " " + wordsInTag[1];
            }
        }
        return tags;
    }

That said, I do really enjoy reading this code. It's indeed very, very clean!

1. How blocks work, and how their minimalist syntax is beautiful. You see absolute value bars but believe me, getting used to that barebones function syntax is a gift. (No other programming language that I know of has an absolute value operator with vertical bars so it is not as hard as you think.)

2. Every time you see a dot, do NOT think attribute access. Think message sending a la Smalltalk.

Suddenly then, things like the tags.collect! line become pretty for encapsulating a callback on one line unlike the ugly function() {} crud of JavaScript, and things like defining a newtags= method become sensible, because everything including traditional attribute getting and setting reduces to message passing.

Keep in mind that while your protest does sound intuitive - e.g. that Ruby can be syntactically ambiguous, ergo it is unparseable, it turns out that that doesn't stop us from writing a parser. We can parse most things even if we can't parse the "general case." When we DO encounter something unparseable, the compiler can a) guess or b) fail, hopefully with a message that will help us investigate and rectify the failure.

You point out that Perl's syntax may be worse than Ruby's, and I assume that implies that it is more syntactically ambiguous, ergo, writing a parser should also be impossible for Perl. It turns out that Perl is provably unparseable in the general case - in fact, it's been done rather rigorously: http://www.jeffreykegler.com/Home/perl-and-undecidability

Regardless of Perl's general unparseability, we have compilers for Perl and even large projects manage to compile to what appear to be functional executables. The same is true for Ruby.

I wrote this comment mostly a reminder that while something may appear to be insoluble, we may be able to solve for sufficient cases that we don't care about the rest, particularly if we have an oracle to fix the number of cases that we can't solve. (In this case, the oracle is the developer.)