The pigeons surely concluded that RFC-1149 cannot compete with satellite broadband on technical merits alone, so they started sabotaging competitive installations with any means they have!

You may want to check https://whereby.com/, it works on the same principle, but you get to choose your own URL suffix, thus making link sharing easier.

Non-paywalled article

https://www.seattletimes.com/nation-world/chaser-border-coll...

Also paywalled, but useful because a lot of people who have maxed out their NYT limit won't have hit it here.

There is! It is called Qooxdoo, exists for years, and works wonders around the impedance mismatch.

When it comes to APIs, every now and then someone say "X is dead, Y is the future".

APIs are not a one-size-fits-all problem, and while general trends and paradigms are a nice thing to have, developers should not be restricted by whatever is the hottest buzzword today.

A nice and clean API will always be pleasant to use, and this has nothing to do with RESTful awesomeness or SOAP verbosity.

Greek startup owner here. Our government is trying to recover from a mistake by commiting a bigger one. Our Varoufakis-illusioned prime minister thought that he could force a better deal from Eurozone members by blackmailing with a worldwide economic Lehman Brothers moment. This obviously didn't work, and the referendum theatre was setup to cover up the failure. That in turn, is a huge gamble, putting the country's prospects for generations to come at risk.

>Our Varoufakis-illusioned prime minister thought that he could force a better deal from Eurozone members by blackmailing with a worldwide economic Lehman Brothers moment.

"Better deal" meaning "a deal which doesn't involve breaking promises they made to the electorate".

Clearly such a deal wasn't possible, hence here we are.

The idea that this is somehow blackmail is ludicrous.

Don't pin everyone on "that's what the people want though!!!"... there's a reason we don't simply setup government so that whatever passing whim the populace manages to latch onto gets adopted and then cast aside once the populace gets bored with it.

Greece has already voted in one government that promised an end to austerity and then reneged upon its promise when threatened by the Eurozone.

I think that if the successive government also reneged upon its promise, that would signal the true end of democracy is Greece.

Or it would signal that ending austerity is actually impossible for Greek politicians. If several parties in a row had promised to double the number of moons, they would also have had to renege on that promise.

The main difference is, of course, that it wasn't clear that it would be impossible to end austerity, with some thinking that the Troika would give in. But that doesn't mean the end of democracy.

>Or it would signal that ending austerity is actually impossible

It basically signaled that the Troika will cajole, threaten, blackmail and generally do everything in their power to keep the austerity train going.

Ultimately, though, that's the way to destroy the currency union. An economic policy based upon wage suppression and privatization of monopoly industries is nice for some people, but it isn't sustainable.

So they promised something they couldn't deliver and now haven't delivered it. This appears to have done nothing to help the situation. "Blackmail" might not be precisely the right word, but you could perhaps argue it's some kind of fraud? It's certainly a failure of their entire platform.

If they have a referendum, that gives renewed democratic legitimacy to whichever side wins. Considering how much is at stake, that seems entirely reasonable to me. Democracy is something Europe in general could use a whole lot more of these days.

Right now, Greece is stuck between a rock and a hard place: agreeing to the Troika’s demands for continued austerity and see another 5 years of economic depression with no end in sight in a way that sells out their campaign promises, vs. leave the Eurozone and see possibly immediate even more dramatic economic collapse but with a potential way out of the mess through a currency under Greek control more appropriate exchange rates.

AFAIK they made no promises to stay in the Eurozone. They just said that they would try.

Given the way that the negotiations are going, they were essentially faced with a choice of slashing pensions and wages to the bone (wouldn't have helped with paying the debt back, incidentally) or... plan B.

What your perception of Varoufakis is? He seems reasonable in his assumption that more austerity will not work, and Greece needs a new approach to solve its economical woes?

I second that; Java has solutions for all problems described by this post.

- constructors, private fields, methods, addressing the "separations of concerns" - how about Enum.valueOf(enumClass, text.toUpperCase()) to avoid the "classic shadow array of string literals"?

Here is an example of what can be achieved by Java enums

  enum Type {
    ANIMAL(null),
    MAMMAL(ANIMAL),
    DOG(MAMMAL) {
      public void makeNoise() {
        System.out.println("Woof");
      }
    },
    CAT(MAMMAL) {
      public void makeNoise() {
        System.out.println("Meow");
      }
    };
    private Type parent;
    Type(Type parent) {
      this.parent = parent;
    }
    public boolean isA(Type type) {
      if(this == type) return true;
      if(parent != null) return parent.isA(type);
      return false;
    }
    public void makeNoise() { }
  }
  assert Type.DOG.isA(Type.MAMMAL) == true;
  assert Type.CAT.isA(Type.DOG) == false;
  Type.CAT.makeNoise(); // "Meow"

This demonstrates a different problem - enums are closed. If I want to add an Owl, I can't do it without editing Type. This might break the API contract (if you own the library) or not be possible (if it's a third part library).

There is very little reason to use an enum over classes in this example. It's rare that I've seen a Java class style enum that wouldn't have been better served by classes (including some that I've written myself and regretted!)

The main point of an enumerated type is that it should be closed. You control all instances of the type, so that you and the compiler can benefit from the fact that it's closed.

If the fact that enums are closed ever presents a problem, then it's a good indication that you shouldn't be using enums. That's not a problem with enums, it's just a bad design decision that needs to be reversed.

Agreed that Vehicle is a poor choice for an enum, because it's something that isn't really closed. But if you're modelling something like states of a TCP connection, there's nothing dangerous about it being closed.

For this example, I agree that it makes very little sense. The question you really need to ask yourself whenever you are making an `enum` is: Does it make sense that this type is restricted to a predefined selection of instances? There are times when the legitimate answer to this question is "yes", and in those cases go ahead and make an `enum` and enjoy its benefits.

Historically, I've used rich enums in Java to be able to use switch statements to reason about a system state and as poor man's type pattern matching. Sometimes the switch is handy for making a state machine clearer, and sometimes it makes it easier to explain the relationships of these states as an ordered list. Another important use of enums is if you're trying to create a rich set of annotations that take parameters, which would force you into dropping a lot of the Java OOP typing available. I can't have a closure or even an anonymous class as an argument to parameterized annotations - and this is definitely by design.

I got bit pretty hard before trying to design an annotation-driven convention for a library I was writing (I had been writing a lot of Python for a while) and realized I'd have to squash a bunch of my carefully arranged classes into an enum. You run into similar problems when marshalling your objects to, say, a Thrift structure definition.

XPath for JSON? Who would have thought of that! Now add namespaces and you reinvented XML 10 years later

Except that, with certain caveats, XML has a slightly nicer syntax for text-heavy documents, and JSON is slightly nicer for hardcore data representation. For example, I'd much rather have a web page in HTML than JSON, but I'd rather have a config file in the latter.

There is a fairly straightforward generalization of the 'axis' concept to allow graph traversal: 'GPath'. (You have to add an annotation for a traversal kind, and an identifier for a property map.) XPath can be straightforwardly desugared to GPath. I implemented this years ago for an EDG IPR[1] back-end, hooked up a number of 'standard queries' over C++ to Todd Veldhuizen's live OpenGL force-directed graph-viewer [2], and watched EDG compile code---pretty wild stuff watching expressions 'bloom', and classes 'become referenced', etc.

[1] https://parasol.tamu.edu/pivot/ [2] http://ubietylab.net

Probably most people would have thought of it.

You wouldn't make that same comparison with regular expressions(tool) and a text document(data) would you? As in, the tool is not part and parcel of the data.

XPath(and JSONPath) are powerful tools for programatically pulling data from complex data structures.

How about Xpath for every configuration file?

    http://augeas.net/