bmn_

You're missing the point here. Slice works with only part of the compound about to be ripped apart. However, destructuring with commas is generic. Example that has no simple slice method call:

    let [,second,,fourth,,sixth]

No, it's worse. I'm talking about the part where you want to pull only parts off a compound:

ES6:

    let [,,,,,,,,, tenth_item] = somearray;

Perl:

    my (undef x 9, $tenth_item) = @somearray;

The ES language designers got that wrong. You carefully have to count the number of commas, and use an invisible nothing in between. Instead they should have made it so that you assign to undefined, or perhaps null, or make up a new special identifier named _ (like it is used in some other languages) and then the assignment operation is smart enough to discard the value.

This is not only better because now there is a visible thing to see and talk about, but also allows the comma operator to be much less restricted and frees the programmer to be more expressive. In Perl, multiple commas are collapsed similar like multiple whitespace collapses in HTML. The expression a,,,,,,b is identical to a,b – also it does not matter where in the expression the multiple commas are.

In ES5 and later multiple commas at the end are collapsed into one, but otherwise multiple commas are kept. This is lame because inconsistent.

Not quiet. The last 25%, i.e. ports 49152-65535, are by design excluded from registration. See RFC 6335 §6.

The proper name is "netloc".

Yes.

I write software professionally and can't afford hobbyist conduct. I have all right to be pissed, era v4 ruined KDE's promise of full customisability. I assure you the KDE devs don't care what anyone says, they just do what they want, not what the users want.

Source: I've been at Desktop Summit (incidentally, that's where the v5 library reorganisation was announced that's just now bearing fruit). The keynote speaker was ripping the devs a new one over that attitude not listening to users; apparently that went into one ear and out of the other.

If I have to recompile to get properly coloured tray icons and a unified colour scheme (not split between applications and task bar), then the software is designed wrong.

A big raised middle finger goes to the developers who thought it was a good idea to make it impossible to opt out of akonadi, nepomuk, baloo, activities, monochrome tray icons, that fucking cashew icon and having an additional separate colour scheme just for the task bar. All of KDE is configurable and can be switched off, except these "innovations".

Still using KDE, because it's the least bad desktop environment, but these v4.x era additions annoy me to no end. v5 does nothing to improve this.

HeaderControlRevived has all of RefControl's features, but is able to manipulate more headers, plugging more potential privacy leaks.

https://addons.mozilla.org/firefox/addon/headercontrolrevive...

> and another implementation in Perl

[sslh in Net-Proxy](https://metacpan.org/pod/release/BOOK/Net-Proxy-0.03/script/...) predates that even longer - first release in 2006.

The branding will not change, for BDFL reasons. The best all we can do is coming to grips with Perl 6 not being a successor, but a sibling.

Too many people arguing about about function signatures are under the impression that this needs to be part of the core language. Turns out, it doesn't: Perl is flexible enough to have its syntax amended.

As a practical programmer, I have enjoyed signatures and run-time type checking for years, provided by libraries. Even now, these libraries are more featureful than core signatures.

Because that's how [require](http://p3rl.org/require) works:

> to indicate successful execution of any initialization code

Other dynamic languages have problems with "half"-loaded code. This mechanism is a defense against that.

comparison charts between HTTPSB (the predecessor of this topic's software) and Ghostery, inter alia: https://gigaom.com/2014/05/11/not-all-ad-blockers-are-the-sa...

Because that would require translators to become programmers.

That's incorrect, that interrogation particle (for making the question in your example) is か. ね is different.

The Russian demo does not work. Must be 1 котёнок, 2 котёнка.

The article is outdated. Gettext does have reordering syntax.

https://www.gnu.org/software/gettext/manual/html_node/c_002d...

With reordering syntax.

https://www.gnu.org/software/gettext/manual/html_node/c_002d...

Miyagawa makes two claims.

1. L::M::L::G enables PO-based work-flow. This is not correct except for trivial lexicons. L::M::L::G cannot parse the plural extract from the article, so it is incompatible with properly working PO emitters.

2. Maketext is used on typepad and "works really well". This claim is not backed by any evidence. The verifiable facts from the article pointing out the pluralisation problems of L::M still stand unchallenged.

If the text is not a whole sentence or paragraph, it cannot be accurately translated anymore into a number of languages with different word order.

As a programmer with i18n responsibilities, you learn to identify and fix fragmented text problems first.

Article is from 1998 and very much out of date. Read: http://blogs.perl.org/users/aristotle/2011/04/stop-using-mak...

Why?

There are outstanding ecosystems for packaging and dependency management in place. That makes it easier to embrace than to avoid dependencies as a library developer.

No need to get so agitated. Your reply comes across unnecessarily hostile for no good reason.

> How do you draw that conclusion? I see nothing in the article which says that he did or didn't know about Earley parsers.

Simple inference from it not being mentioned, even though I thought it deserved to be. Since that does not prove anything, I wrote "apparently" – I anticipated my assessment could be wrong, and indeed it was.

> the Wikipedia page for GLR says

I'm not happy with that article. It gives people the wrong ideas, it's not realistically useful to make comparisons with the decades-old original algorithm. Modern Earley parsers do contain optimisations that makes those distinctions mentioned there moot. And unless I completely misunderstand what the WP contributor aimed to express, the Earley algorithm is "online", too, and that is the case even for unmodified/unoptimised Earley parsing. See http://web.stanford.edu/class/archive/cs/cs143/cs143.1128/le... or just step through an implementation with a debugger. I think the reasons are not as "sound" as you concluded them to be.

To me it appears after all that GLR and Earley are equal in power, so Cox shouldn't simply reject, and implementations compete in areas other than the algorithm, e.g. sensible error reporting, simple interface for simple use cases, ability to consume grammars in standard formats, coverage by number of programming languages and such like.

Please explain how you arrive at the conclusion that an Earley parser optimises entirely for the wrong thing. What is the wrong thing?

Competing with a manually written parser is easy: Earley parsers are derived from a CFG in standard format, such as ISO EBNF or IETF ABNF. Such a grammar is much easier to reason about than parser in a general programming language such as C.

> you don't want your parser return some arbitrary parse tree

You have a mistake in your assessment of Earley parsers. For ambiguous grammars and input, they do not return an arbitrary tree, but all possible trees. In this regard they are no worse than yacc: "the user resolve[s] these manually" by picking the correct result(s). To a human, it's visible at a glance which is the correct result(s), entirely without needing to learn how to decipher these bizarre warning messages you mentioned.

> conflicts are a strong sign of a bad specification of the language

So what? That's not pragmatic thinking. We cannot go back in time and influence the design of ambiguous computer languages so they are not ambiguous. Natural languages never are without ambiguities!

The parsing job needs to be done, no matter the complexity of the language. Instead of wishing it weren't so, just use a tool that can deal with it. Earley parsers can, yacc cannot.

LR parsers like yacc are obsoleted by Earley parsers, which Cox apparently didn't know about in 2010. Quoting <http://loup-vaillant.fr/tutorials/earley-parsing/what-and-wh...:

    The biggest advantage of Earley Parsing is its accessibility.
    Most other tools such as parser generators, parsing
    expression grammars, or combinator libraries feature
    restrictions that often make them hard to use. Use the wrong 
    kind of grammar, and your PEG will enter an infinite loop.
    Use another wrong kind of grammar, and most parser
    generators will fail. To a beginner, these restrictions feel 
    most arbitrary: it looks like it should work, but it doesn't.
    There are workarounds of course, but they make these tools 
    more complex.

    Earley parsing Just Works™.

    On the flip side, to get this generality we must sacrifice 
    some speed. Earley parsing cannot compete with speed demons 
    such as Flex/Bison in terms of raw speed. It's not that bad, 
    however:
    • Earley parsing is cubic in the worst cases, which is the 
    state of the art (and possibly the best we can do). The speed 
    demons often don't work at all for those worst cases. Other 
    parsers are prone to exponential combinatorial explosion.
    • Most simple grammars can be parsed in linear time.
    • Even the worst unambiguous grammars can be parsed in 
    quadratic time.

    My advice would be to use Earley parsing by default, and only 
    revert to more specific methods if performance is an issue…

In 2014, we now have Earley parsers in C, JavaScript, Lua, Perl and Python.

Further discussion on killing yacc:

http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv... http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv... http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv... http://jeffreykegler.github.io/Ocean-of-Awareness-blog/indiv...

Since the page is not dated, I wanted to find out whether the challenge has just been released currently or not.

Inspecting HTTP headers gives a hint: Last-Modified: Sat, 22 Mar 2014 04:33:36 GMT