Hacker Newsnew | past | comments | ask | show | jobs | submit | slashnull's commentslogin

Thing seems to be built on top of Stack.

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.


Why don't we have affordable symmetric internet connections yet?


Noooo! All that wasted helium!


Is there a product called, or commonly referred to as "PSQL" that could be confused for PostgresSQL?

Because I think the project should start advocating "PSQL".

See,

The competition is called "MySQL". One syllable, then SQL. You know what it does, and you know how to google it. It googles great, too.

PSQL has the same advantages. Google even already understands it.


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 thought it was meant to be "Postgres-Q-L"

Edit: wow, the naming page says that Postgres-QL is a "weird derivation".


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.


But it is Postgres - QL, because you have Postgres, the server, and its Query Language. Straightforward.

... okay no I was trolling


For what it's worth I've also always pronounced it "Postgres-Q-L".


> 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.


That it was expensive in the mid 90's is no reason for it to be expensive today. Plenty of entities would host that data for free.


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.


I think the switching costs are there

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)


Ahhhh, *variance.

The definitive explanation of why inheritance should always be avoided in favour of implementation of abstract interfaces.


Interfaces have variance too, as long as they give rise to a subtyping relationship (which, in most languages that have them, they do).


Ha! Cunningham's law.

I see that many OOP languages (of various purity) have interfaces that may be extended by other interfaces. Is that what you're talking about?

I also found that *variance is used in the context of Haskell, but it seems to be far from being widely used.

Haskell being my template of a language with a good-looking interplay of polymorphism and algebraic typing.


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.


Oh my god it's written by David Foster Wallace, there is a javascript widget to display the footnotes, and some footnotes have footnotes.

Perfect.

Thank you so much.


If it starts to suck like MySQL, will it become popular like MySQL?

I think that'd be a fair tradeoff.


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_.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: