troad

Very interesting, thank you for the thoughtful explanation!

I note the rule reminder, but I very respectfully raise one hell of an eyebrow at the implication that discussions about ranking the significance of dead children by skin colour ought to be conducted curiously, dispassionately and substantively.

I imagine this will continue being walked back into nothingness. It's probably not even legal.

Why would the Papacy be exasperated with the Latin Mass movement if it's merely celebrating one of the allowable options?

(Genuine question, I'm sure I lack all context.)

[flagged]

Haha, I'm not too young for that, but I think that was a fairly fringe use case even then. Most people were never on IRC.

In the late 90s / early 2000s Internet radio would probably have made me think of RealPlayer, and shortly thereafter actual radio stations' own websites with embedded streams. Then I'd think of aggregators like the original iTunes, and now TuneIn.

It appears to take a folder of .opus music files and serve some kind of Opus live stream, and it is controllable via IRC (as in, you can tell it to queue or skip songs over IRC). Or at least that's my best guess based on the linked demo instance.

It would certainly benefit from a single line atop the README that clearly stated what this actually does. I certainly don't think of IRC when I think of Internet radio.

The US attacks on Iran is a different event altogether from the Israeli genocide in Gaza. You're conflating discrete conflicts with different parties and different modes of engagement.

The US attack on that school is atrocious and I condemn it. While possibly a war crime, it does not meet the definition of genocide, unlike Israel's conduct in Gaza, which certainly does. There's no evidence of recent US conduct amounting to genocide (much historical evidence vis-a-vis American Indians though).

To the extent you wish to penalise complicity in genocide, go for it, but I will notice if you're oddly selective in which genocides you apply that standard to, and which you don't. (Which countries traded with Burma during the Rohingya genocide? Do you know? Do you care?)

> brown children

What does the children's colour have to do with anything at all? Do we grade the severity of war crimes by the (perceived? assigned?) race of the victim? Horrific thought.

[flagged]

Russian is a nationality, not a race. You can say prejudiced, but not racist. In this case it's not even a person, but a product.

It's not prejudice when it's based on a post-facto assessment of the Russian government's mobilisation of their companies for obscene and evil goals like clamping down on free speech, persecuting LGBT people, or trying to destroy Ukraine.

"It's Russian and therefore it's out" is a valid stance in light of all the known consequences of using a Russian product. If Russian people do not like this, they are welcome to break their links to the Russian state by emigrating and founding companies elsewhere, or stay and overthrow their government. Either works for me.

Many Russians have learnt to keep quiet about politics so they can get ahead in Russia, and they seem to harbour some deep-seated delusion that everyone from abroad should play along with this for their own convenience and profit. They whisper 'no war' to one another, by which they mean Ukraine should surrender already, so that this whole unpleasantness (to them) blows over, and the rest of the world goes back to accepting their blood money. No.

Germany has been grappling with its own horrific genocide for a hundred years and still hasn't quite figured it out. Russia is, as of the time of writing, currently undertaking one. Come back in a hundred years, maybe we can talk about Russian products then.

The perfect ought not be the enemy of the good - the question isn't whether Wikipedia has solved all prejudice, the question is whether it is doing better on that question than its peers. And I'd say it is, relatively speaking. I'm always happy for it to do better, though.

Spending money to get people into editing Wikipedia that would never otherwise have done so seems like a very worthy goal to me.

Internal DEI initiatives are very helpful for an organisation trying to create a comprehensive knowledge base without falling to any group's bias. That requires diverse perspectives.

I don't care about internal DEI if the job is managing sewerage systems, but this is a perfect example of a context where fostering diverse engagement is both rational and improves the end product.

More broadly, I think it's "let's not hand over essential infrastructure to any foreign state". Friendly or not, it doesn't matter.

Private companies ought to have the freedom to do business with whomever they like, but for essential public services, better to assume essential public infrastructure simply must not be offshored at all.

Did anyone actually like StackOverflow?

Any question asked would be edited beyond recognition (and usually into brash rudeness). Half the answers were demanding ever increasing proof of work, and the other half told the OP that they shouldn't even be trying to do what they're doing. The only useful thing were opinion based posts from people with domain expertise, and SO kept trying to ban and remove those. It was the least helpful place online, but the most accessible, and it survived for lack of alternatives.

I'm no AI booster, but answering simple questions about well understood topics is a perfect fit for it. Good riddance to StackOverflow.

Perhaps it would help if stdlibs were be versioned, with the chosen version declared in the project file. For existing languages, a lack of version would simply indicate the original stdlib, meaning nothing should break.

I definitely don't think stdlibs should be changed often, but it seems fairly damaging to a language when things may be added to a stdlib but never removed, no matter how broken or misconceived (see C++).

Rust is a great language, but the poor stdlib + overreliance on crates + explosion of unvetted transient dependencies makes it a hard sell for a lot of projects.

No no, dead earnest. I'm a big believer in honest compliments, where merited.

Please start writing a blog, if you don't already. If I could compose a blog roll of people writing fun CS histories, I would replace my HN bookmark with it.

Having reviewed as instructed, I stand by everything I said here. Let's review the action replay.

I began by noting that TS has literals and set theoretic types, and that this makes sense for a post-facto type system bolted on top of a dynamic language. Jaen showed up to inform me that TS has literals and set theoretic types, implying he hadn't read my post.

I noted that typed string literals are not generally considered desirable within strictly typed environments. "Parse, don't validate", etc. Jaen seemed to follow this up by aggressively trying to prove that TS is somehow "better" than Haskell. His arguments comprised the fact that TS has literals and set theoretic types (again, yes, this was is in my initial post), and a mixture of personal insults and just straight up nonsense (I wasn't the one to bring Zod into a discussion of type systems... ). At that point I did have a little fun with things, since it had become clear Jaen was not a constructive or good faith interlocutor.

Jaen's central misapprehensions seem to be that (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".

As I repeated a number of times above, TS' type system makes sense for a type system bolted onto a dynamic language. It's extremely useful when the underlying language has oodles of untyped structs flying every which way. Conversely, Haskell's type system makes sense within a holistic strictly typed environment. Structural typing would be a gaping hole in Haskell's strict type safety, which is kind of Haskell's whole thing. Neither system is better, each has its use. Different strokes for different folks.

I don't usually put much stock in upvotes, but I do note I seem to have the edge there. Seems that our esteemed panel of armchair referees respectfully dissent from your narrative, nvlled. :)

It's not. The US green card process takes years, and being forced to be outside the country while the process is ongoing makes it very hard to continue working for a US employer, which is how most people are actually sponsored for a GC in the first place.

If you're looking for some objective rationale for this change, you're not going to find one. This is simply designed to make GCs much, much harder to get and dissuade prospective immigrants. That's the only goal.

I believe I was promised a respite from this.

Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher?

> You seem to know what I'm doing better than I am

Apparently so! Trust me, it gives me no pleasure, and I'd rather I didn't.

> Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.

My dear friend, this is almost completely incoherent.

I wish to strictly type myself as a function at this point, whereby your messages are my input, and void is my output. Zod, activate!

Haha, I knew you'd bring up Go. I even considered pre-emptively dropping Rust and Zig as counterexamples. I think most people who favour static typing consider the duck-typed interfaces of Go to be a mistake. Personally, I consider all of Go to be a mistake.

> these type system features were added by multiple experienced language designers for a reason

Oooh, an appeal to authority, where that authority isn't even named. I'll have you know a famous queen told me you're wrong on this, also for "a reason".

> TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.

Right, so TS typing is so amazing it requires runtime parser libraries from NPM, and Haskell is less sophisticated because it's not stringly typed.

You realise the entire, complete, exhaustive runtime schema for your zero-first non-empty integer array example looks like this in Haskell, right?

    sch (0:_) = True
    sch _ = False

That's a complete function that somehow manages to work without pulling in NPM dependencies. The best JavaScript minds of our generation remain baffled.

> The Person/Wine example is a pointless strawman

> I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.

So when you use illustrative examples, it is to "disambiguate what you meant" (huh?), and when I do it, they're "pointless strawmen". A little hypocritical, no?

> a bit ignorant

Honestly, I don't think you know what you're talking about at all. You clearly hadn't even read my comment when you started replying with Python and TS examples... that were already in my comment.

It also really sounds like you're using string literals to type input without properly parsing it, which is just a terrible idea. Haskell's type system is designed precisely to protect you from this sort of mistake. [0] No, you're not always going to get what you expect. No, your JS program will never let you know that's the case. No, a sane type system does not require mainlining runtime parser libraries from the biohazardous oceans of NPM. A schema in Haskell is going to be significantly shorter and sounder than anything in Zod, and you don't need a library for it.

As I said above, TS' type system makes sense for a type system bolted onto a dynamic language post facto. TS needs to more tightly link (even mildly conflate) values and types, since it needs to do a lot of clever narrowing to figure out what mad ball of JS it is dealing with at any given time. Haskell does not operate under any such constraint.

> I don't see a productive continuation to this discussion.

Phew. Timesaver.

Of course the irony of all this is that I use TS daily, and Haskell quite rarely.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Fantastic comment! Really lovely contribution. The sort of thing I come to HN for.

> You can go `</br/r/r>`, if you are really into solidi

Love it.

> By Haskell's type system do you mean with all the GHC extensions?

No? What extensions does `A | B | C` require?

> Haskell has neither subtyping nor structural typing

Is subtyping back in? Good news for Java and C++.

Re structural typing, I would ask what behaviour you're after, specifically. For example, this is a valid, typed Haskell function for any two values that can be added, including any user-defined ones:

    adder a b = a + b

If by structural typing you mean silently coercing types that the compiler deems structurally equivalent, then no, but I don't think many people writing Haskell would consider that desirable. A `Person` may have an age (40) and a `Wine` may have an age (2005), but you're not going to get sensible results if you start adding those two together, and your compiler should probably stop you.

Structural typing is the sort of thing that is very valuable if you're bolting a type system onto a language with a cornucopia of untyped structs, like JS objects. It is comparatively much less valuable if you're working in a typed ecosystem to begin with, since you're not liable to have loose untyped structs floating around that require coercion.

> "integration/glue" type of programs

It does sound a lot like you're using string literals in lieu of parsing foreign input, which strikes me as a pretty bad idea. Particularly in a language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways, and cause behaviour far removed from what any static analysis of the TS source would suggest.

> You can type a non-empty array that starts with zero

Can you please name me any possible actual use for this? Especially given the type doesn't even exist at runtime and will never be enforced on input data, so this is a once-off check for comptime constants?

Uh huh, sure. I didn't know the between a C union and a set theoretic union. I'm just so gosh darn confused, trying to use them set theoretical types in my C all the time!

You have come into a room full of CS practitioners to announce to them that you alone understand what unions are. Never mind fifty years of industry practices and nomenclature - never mind the fact we all already know set theory and unlike you don't confuse set theoretic unions with tagged unions - all that can now be set aside because you discovered set theory last week and now no one understands unions except for you.

Can't wait for next week when you discover some new band, and you'll be in here telling us how no one gets music except for you. :P

Yes, I mean hosts, not literal browser history. I should've been clearer.

I know. I literally gave the example of a Python Literal in the post you're replying to. TS too. :)

My overall point is that Haskell's type system is sufficiently expressive (you may not have "A" | "B" | "C", but you do have A | B | C) that there's no obvious remaining use case for string literals, unless you're thinking of typing input by way of expected literals instead of actually parsing it, which is... a choice. :P

I believe so! Though with a healthy set of global endpoints to route through, naturally.

I see no evidence the user is confused, they said they wished the syntax were similar to TS. Though they're not the same thing, they do have comparable uses, so it makes sense to wish for similar syntax to reduce cognitive overhead.

> Well, we disagree.

Most people here know the set theory definition of unions. It's simply a niche use, compared to the usual CS definition, which is the one used in the original article and now all the comments.

You're swimming upstream with a definition that doesn't reflect what is under discussion, which you decreed as though from on high, complete with the assertion that most people don't understand unions like you do. They do.

You're welcome! Knowing is half the battle.

That Haskell snippet is just syntax sugar for Left(string) | Right(string), which is trivial in any language with unions.

Not clear why it would be an improvement over just naming the alternatives something meaningful, but if you're wedded to Left and Right, go for it.

It's been interesting seeing the retrospective flattening of computer history. I suppose it's inevitable over time. I wonder how bad it will get.

"In the 1990s, 'hackers' would 'dial up' their flip phones to local BBSes (called 'phreaking'), where they played and exchanged small Flash games (the 'demo scene')." /s

I just permanently live on a US VPN these days. [0] Not Spanish, but my own country has started overregulating the web, and it seems prudent to develop a long track record of appearing as a US based user to the various online fiefdoms, rather than needing to do it all at once once they pass some digital ID mandate or other nonsense.

Not that there's any complete guarantee that the US web will forever remain open and free (no such guarantee is possible), but it's significantly more likely there than here. The state of the open web worldwide is pretty depressing. :(

[0] Mullvad, not the bad ones. Though with mandatory ISP-level retention of browser history here, pretty much anything is an improvement for privacy.