phpnode

> If there's a "small" or "simple" FORMAL language specification, it means there's a "large" INFORMAL language out in the wild.

This is exactly right, pushing language features into user-land just leads to a load of competing equivalent solutions that developers must learn. The language is simpler but it becomes harder to actually use.

That looks very much like a hostile takeover, it's unsurprising that it failed.

or someone else could have stepped up much earlier?

Hey, this looks really fantastic, it solves a real problem for UK drivers and I think you'll be fantastically successful. However, I couldn't find any information about who's behind the site, and I wonder about the mechanism through which the insurance is provided, how is it backed?

Out of interest, did you use skiplists to reassemble the streams in order?

The fact that your tests are flaky at all means that the integration tests have revealed a bug that you need to fix. The tests have done their job. The fact that people aren't looking at the results speaks to a larger cultural issue.

inglor is a contributor to Bluebird, so I'd guess he'd say Bluebird. Bluebird is the much faster option and has a lot more features, if you're using babel (and a recent node/io.js) you can transpile async/await to bluebird coroutines for maximum performance and syntactic beauty.

Seriously Luca, how stupid do you think people are?

Do you do that more or less frequently than writing strings with apostrophes?

I never really understood how Arel is any different to the query builders which exist in most frameworks, does anyone know the details?

Well it's pretty straightforward, if turnaround time is only 10 minutes and your competitors take an hour then you can simply make more flights per aircraft per day than them. This is amplified when your flights are short distance domestic. Depending on destination it probably allowed them to make 2 - 3 extra flights per aircraft per day, at a time when jet fuel was not so expensive. That could make a massive difference to profitability.

Possibly diet. Obviously it's anecdotal but all of the Dutch people I know consume far more dairy products than those from the UK.

Edit: Turns out the Dutch are the third biggest consumers of milk per capita in the world[0], looking at the list of "tallest" countries on wikipedia[1], there seems to be a great deal of overlap at the top of the two lists. I wonder if a secondary factor could also be related to vitamin D exposure, but I couldn't find a data source for that.

0. https://en.wikipedia.org/wiki/List_of_countries_by_milk_cons...

1. https://en.wikipedia.org/wiki/Template:Average_height_around...

Why is this distinction important when it comes to actually using the language?

I see this line of thinking a lot and I think it's a mistake. Are classes in other languages consistent with each other? Clearly not, so why is this distinction made here? ES6 classes ARE classes, it's not just sugar, that is what they are.

This is a very silly comparison. There's a huge difference in terms of features and reliability between node's http module and this - http://pietersz.co.uk/software/dandelion-server

I'm sure an equally minimal http implementation using the net module would match or beat that, but since you'd never use either of them in production, the results are meaningless.

Labour costs. TBMs are amazing but they are slow and require a whole lot of infrastructure. It's not just a case of sticking them in the ground, turning them on and waiting for a nice tunnel to materialize. For instance, what do you with the excavated dirt? To give you an indication of the sheer cost here, London's crossrail project runs at approximately £4m/day - https://en.wikipedia.org/wiki/Crossrail

It's my opinion based on working with OrientDB a lot and ArangoDB a bit for the last 12+ months. I used to be a big cheerleader for OrientDB, but now I don't recommend it. I'm sure Luca will have some comments but he's interested in selling his product.

Some people build "graph databases" on top of storage backends that are ill suited for such workloads. e.g you can build a "graph database" (or K/V store) on top of MySQL, but the performance is terrible - http://java.dzone.com/articles/mysql-vs-neo4j-large-scale

a "native graph database" is one that is actually designed for the task.

OrientDB fails to deliver on its promises. It has a load of features but they are poorly thought out and/or broken.

ArangoDB is OrientDB done right, but it's a lot younger.

If you're considering using either, you owe it to yourself to investigate whether postgres's Common Table Expressions [0] can do what you want instead. If you can stick with something more mature like postgres, then you'll be saving yourself a lot of pain.

[0] http://www.postgresql.org/docs/9.1/static/queries-with.html

It's a database that stores a "graph" of vertices that are connected by edges. If you were say, creating the next LinkedIn and you wanted to find the shortest path between two users based on their connections, a graph database would be a good choice.

Let's imagine you want to see how Fred is connected to Steve, their network looks like this:

    [Fred] <-knows-> [Bob]
    [Bob] <-isMarriedTo-> [Sally]
    [Bob] <-knows-> [Alice]
    [Alice] <-workedWith-> [John]
    [John] <-wentToSchoolWith-> [Sandra]
    [Sandra] <-knows-> [Steve]

Diagram: http://yuml.me/6ff3074e

A "traditional" database like MySQL or Mongo makes this kind of query prohibitively expensive and complicated, as it must perform a new join for every connected person in the user's graph.

Graph databases come into their own because they are designed specifically for efficient traversal of these connecting edges. They typically do this by storing "pointers" on each vertex to its connected edges, so while a normal RDBMS requires something like a hash table lookup to resolve a join, a graph database can simply "jump" to the relevant record via a pointer. This means that things like Dijkstra's algorithm [0] can be implemented efficiently.

However, "traditional" graph databases like Neo4j require everything to be structured in terms of vertices and edges. This is often quite inconvenient, so Multi Model databases like ArangoDB integrate this graph approach with a document store as well, the idea being that if you can keep everything in the same db your app gets a lot simpler, you regain things like ACIDity that you'd normally lose by using 2 separate dbs, and performance should be a lot better too.

[0] http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

> What is the difference between a graph vertex without edge and a document at the storage level?

Nothing, most multi-model dbs store vertices (and edges) as documents

SEEKING WORK - Remote

Hi, I'm Charles, the founder of codemix [0], we're a distributed team of 4 experienced developers + 1 designer, who're known for delivering very high quality web/mobile apps quickly.

We're based in the UK but we work with companies from all over the world who value our relentless pace and our ruthless user-centric pragmatism.

We focus on shipping quality software and making sure that software truly delivers on its full potential. Sometimes that means us taking on the entire project design/development ourselves and sometimes it means embedding ourselves into a larger team to really drive the project forward.

If you have a project that you need to take to market quickly, and you don't want to compromise on the user experience, I'd love to talk to you about it, email me at charles@codemix.com.

[0] http://codemix.com/

In the UK a lot of taxi drivers seem to believe this, the superstition is reinforced whenever they happen to flash when the lights were about to change anyway. It's also a comfort thing, similar to a placebo button[0] - people want to believe that they have some control over the mundane parts of their lives.

[0] http://en.wikipedia.org/wiki/Placebo_button

The other part is that many attackers see this kind of site as "fair game", compared to more upstanding companies. By its very nature the adult industry attracts the ethically challenged.

Those two examples are really poor, the usability is terrible in both cases, and the effects are not impressive enough to be worth giving up core features like zoom and copy / paste.

I'm also keen for Flow to improve, but for now it's possible to turn off the `flow` transformer in Babel and pass the compiled output to flow - this preserves type annotations in the output

I suppose if CoffeeScript were reimplemented from scratch today, it would make sense to compile to an ES6 AST that could be passed on to Babel for further processing and code generation.

I guess I failed to make this point properly, but Babel already supports static typing - you can use a plugin[0] and/or you can use it with Flow[1].

[0] https://github.com/codemix/babel-plugin-typecheck

[1] http://flowtype.org/

Macros for JavaScript have been available for a long time[0], you can even use the C preprocessor[1]. Also I wrote a macro plugin for babel just yesterday [2]

[0] http://sweetjs.org/

[1] http://www.nongnu.org/espresso/js-cpp.html

[2] https://github.com/codemix/babel-plugin-macros