Nice to see the Haskell community aligning itself so fast around a package manager/build tool created first and foremost for ease of use and convenience.
The good thing about the current name is that there's a clear distinction (at least to users "in the loop") between "psql", the command-line client, and "postgres" the backend service. I'm quite aggressively against renaming the product to "psql".
I think you misunderstood what that bullet point is trying to say. It IS "Postgres-Q-L". That bullet point is talking about someone theoretically thinking that the name is logically two parts: "Postgres" and "QL". When really it's "Postgres" and "SQL" and the middle S is elided.
> Traditionally, most journals were published by non-profit scientific societies. But when journals shifted from print to online digital formats, those societies couldn't afford the cost of the equipment needed to make the switch. Instead, they sold their journals to large, for-profit publishers
wait, what
I can't figure out how it would be possible that shifting from physical paper to online hosting could be more expensive
I can't figure out how it would be possible that shifting from physical paper to online hosting could be more expensive
Developing and hosting something like JSTOR in the early to mid 90's was no where near as cheap and easy as it might be today (and let's face it even today it isn't completely trivial). Doubly so if you had no staff with the relevant skills and had to do everything via consultants.
No, but it does explain why the traditional publishing societies didn't do it themselves back in the day and instead had to rely on for-profit entities.
Cost is half of it. The other half was very resistant. I am told that when my office started going digital in the late 80's there was a lot of turmoil and it split the organization. That attributed greatly to a period where we had 3 presidents for a year. Digitization won of course.
We sold our journal I think for two reasons. The first was to digitize them. We have a large electronic database that we are still not completely finished converting from microfiche. We've been working on it since the late 80s. The second was time commitment. We are small. 10-15 people on average. Only two real developers. The hosting commitment was daunting at the time.
Honestly, I don't know the whole story. I've only been around here for a few years.
I don't buy this. The real issue is prestige. Many journals use a large publisher for their brand name. As schools themselves manage to establish significant international brand awareness, they no longer need this service. There is currently no online/open access platform with academic prestige--because that can only come with time and a track record of proper review and rejection. When the larger players come together and form or use such a body, the smaller players will be able to migrate to it.
Especially if you have no domain knowledge in running a paywalled website, you could end up getting charged an insane amount of money by some consultants to set it up for you.
Based on a couple of years working for an academic publishers, I'd guess commonly it's lack of domain knowledge + switching cost + switching of mental models + sunk equipment costs. Most are very small, with very established ways of working; I found it incredibly frustrating at the time that my employer wouldn't even consider even minor shifts away from what seemed an enormously wasteful print model, it seemed utterly ridiculous at the time, but with some objectivity I find it completely understandable (still daft, and I'm glad to be out of the sector, but understandable)
variance is used in Haskell all the time. Haskell's subtyping/type-subsumption relation is less pervasive than an OO language's, but it's critical. Furthermore, variance is more fundamental than subtyping. It is not at all a stretch to say that the type mechanics of function composition are based on contravariance/covariance matching.
There's that bit which made me chuckle at first, then think. A lot. When he shows an algorithm written in prose, then in modern mathematical notation.
The real leap forward here? User interface.
Everywhere I look, I see instances of that same pattern:
One person or small team of very clever people develops a given technique or algorithm, and a gigantic army of technological lumberjacks go out and progressively make it easy to use.
And it's not just UI as in "the paying consumer of a product"; it's UI as in the person which will build the previous UI, and to person which builds that person's tools, and so on, turtles all the way down.
Progress is not algorithms, progress is not ease of use; it's (power of an algorithm / ease of its use).
In the end, progress in user interface is progress, _period_.
Nice to see the Haskell community aligning itself so fast around a package manager/build tool created first and foremost for ease of use and convenience.