Very cool that the language allows specification of a type in this way.
I added a similar type — “non-empty-string” to a typechecker for PHP, and it’s been adopted widely in the PHP ecosystem. It turns out to be pretty handy, especially when there’s a full type system to support it.
I bought a leather wallet from them in 2016 (the Hide & Seek) and it is still holding up well despite a few loose stitches. It’s much slimmer than my older wallet.
I've had a Bellroy bag, they're not the most fashionable but super high quality and well thought-out. Just like Haskell code—maybe that's why they like it.
In the backpack community bellroy is often seen as “meh”. Eg. they frequently don’t live up to the guarantees they give and to the quality they promise. Also overpriced.
The starting point of casting a horoscope is calculating the apparent locations (this means "where you would have seen them had you looked up there and then") of a whole bunch of celestial objects at the time and place where a particular person was born.
You won't (write software to) do that without knowing a whole bunch of linear algebra and ODEs.
The fortune-telling part is not what needs the math degree.
Are you sure? I can see for Astronomy that's a branch of physics so sure, there's loads of tricky practical mathematics so if you're bad at mathematics you'll get stuff wrong, but surely for Astrology since it's just bullshit anyway you don't need to do mathematics as it wouldn't make a difference?
A horoscope is a fine mixture of fortune-telling bullshit and verifiable astronomical facts. The latter have the form of "where the celestial bodies could be seen at the hour of the client's birth", or "does Jupiter currently appear to be moving forward or backward in the sky".
The average Visual Basic programmer and the world's best mathematician are going to be about equally good at writing the fortune-telling part, but the mathematician will have a much easier time getting the factual part right.
Astrology is a mixture of factual verifiable information (such as apparent positions of celestial bodies at the time and location a certain person was born) and random baseless divinations.
The "whale" users who account for a disproportionately large percentage of an astrologer's revenue tend to know the factual information surrounding their birth fairly well. An app/astrologer who doesn't get these facts right, even for a handful of clients, will get a bad reputation fairly quickly.
I reckon the same principle would hold in cultural bubbles where reading tea leaves is a customary means of divination. If the client recognizes recognize black tea, but the fortuneteller insists it is rooibos, there won't be much trust in the rest of the prophecy.
Advertising that the horoscope shop uses Haskell is actually a solid business idea. It pre-filters for the sort of dev who will be able to do the math.
OK, I replied elsewhere without realising where you were going with this.
My impression (not interested in pseudo sciences so I haven't looked into this hard) was that Astrology froze before Kepler explains how the planets move, and so the model used by astrologers is just wrong and won't actually tell you what was in the sky when you were born for example?
You don't need Newton (who figured out why they do that) but you do need Kepler or your physical data will be wrong surely? It won't matter because this isn't actually a way to divine the future, but it will be wrong AIUI
Astrology didn't really freeze. The apparent position of celestial objects was important for mundane reasons such as navigation until the 1970s, and the people who compiled nautical almanacs kept doing astrological fortune telling on the side for extra cash, using the very same math for both. Kepler himself cast horoscopes as a side hustle, including for the Holy Roman Emperor, using the same (back then cutting edge) techniques and data that he used for serious work.
Modern ascendant calculations are "correct", in the sense that they'll match what you see in the sky. Apps like AstroMatrix work from NASA data.
As you rightly observed, it doesn't make a difference when it comes to foretelling the future. But it does make a difference if your aim is to make money selling it. The big spenders on these applications often care a great deal about getting the particulars just so.
Daily reminder that the unsoundness in Typescript's type checker is a practical compromise applied to a language that was never designed to be type checked in this way, and furthermore that many developers feel that it strikes a good balance between formal correctness and practical usability.
This example is not only wrong for what you intend to demonstrate but even if it wasn't, it's not problematic. In typescript the proper way to do this is using branded types and exporting only the safe constructor, making anyone who wants to violate the invariant go out of their way, which is no different from the situation in any number of programming languages or scenarios.
declare const brand: unique symbol;
type NonEmptyString = string & { readonly [brand]: 'NonEmptyString' };
// the ONLY non-cast way to produce one
export function nonEmptyString(s: string): NonEmptyString | undefined {
return s.length > 0 ? (s as NonEmptyString) : undefined;
}
export type { NonEmptyString };
Very cool that the language allows specification of a type in this way.
I added a similar type — “non-empty-string” to a typechecker for PHP, and it’s been adopted widely in the PHP ecosystem. It turns out to be pretty handy, especially when there’s a full type system to support it.
"Huh never heard of Bellroy... I wonder what they're using Haskell for..."
Turns out it's some kind of bags and accessories brand!
I bought a leather wallet from them in 2016 (the Hide & Seek) and it is still holding up well despite a few loose stitches. It’s much slimmer than my older wallet.
I've had a Bellroy bag, they're not the most fashionable but super high quality and well thought-out. Just like Haskell code—maybe that's why they like it.
In the backpack community bellroy is often seen as “meh”. Eg. they frequently don’t live up to the guarantees they give and to the quality they promise. Also overpriced.
I pondered for a while, it IS the company I used to know
I once saw a job ad for a company selling a horoscope app that required Haskell. An unusual conjunction for sure.
Astrology and Haskell are quite similar in that both are much much easier to do if you have a math degree.
Ok, I'll bite. How does a math degree help with astrology?
The starting point of casting a horoscope is calculating the apparent locations (this means "where you would have seen them had you looked up there and then") of a whole bunch of celestial objects at the time and place where a particular person was born.
You won't (write software to) do that without knowing a whole bunch of linear algebra and ODEs.
The fortune-telling part is not what needs the math degree.
Are you sure? I can see for Astronomy that's a branch of physics so sure, there's loads of tricky practical mathematics so if you're bad at mathematics you'll get stuff wrong, but surely for Astrology since it's just bullshit anyway you don't need to do mathematics as it wouldn't make a difference?
A horoscope is a fine mixture of fortune-telling bullshit and verifiable astronomical facts. The latter have the form of "where the celestial bodies could be seen at the hour of the client's birth", or "does Jupiter currently appear to be moving forward or backward in the sky".
The average Visual Basic programmer and the world's best mathematician are going to be about equally good at writing the fortune-telling part, but the mathematician will have a much easier time getting the factual part right.
Using Haskell for a horoscope app is like hiring a mathematician to read tea leaves
Astrology is a mixture of factual verifiable information (such as apparent positions of celestial bodies at the time and location a certain person was born) and random baseless divinations.
The "whale" users who account for a disproportionately large percentage of an astrologer's revenue tend to know the factual information surrounding their birth fairly well. An app/astrologer who doesn't get these facts right, even for a handful of clients, will get a bad reputation fairly quickly.
I reckon the same principle would hold in cultural bubbles where reading tea leaves is a customary means of divination. If the client recognizes recognize black tea, but the fortuneteller insists it is rooibos, there won't be much trust in the rest of the prophecy.
Advertising that the horoscope shop uses Haskell is actually a solid business idea. It pre-filters for the sort of dev who will be able to do the math.
OK, I replied elsewhere without realising where you were going with this.
My impression (not interested in pseudo sciences so I haven't looked into this hard) was that Astrology froze before Kepler explains how the planets move, and so the model used by astrologers is just wrong and won't actually tell you what was in the sky when you were born for example?
You don't need Newton (who figured out why they do that) but you do need Kepler or your physical data will be wrong surely? It won't matter because this isn't actually a way to divine the future, but it will be wrong AIUI
Astrology didn't really freeze. The apparent position of celestial objects was important for mundane reasons such as navigation until the 1970s, and the people who compiled nautical almanacs kept doing astrological fortune telling on the side for extra cash, using the very same math for both. Kepler himself cast horoscopes as a side hustle, including for the Holy Roman Emperor, using the same (back then cutting edge) techniques and data that he used for serious work.
Modern ascendant calculations are "correct", in the sense that they'll match what you see in the sky. Apps like AstroMatrix work from NASA data.
As you rightly observed, it doesn't make a difference when it comes to foretelling the future. But it does make a difference if your aim is to make money selling it. The big spenders on these applications often care a great deal about getting the particulars just so.
Language is not mentioned in a title, so my first thought was about TypeScript type wizardry. Turns out it's as simple as `Exclude<string, "">`.
https://www.typescriptlang.org/docs/handbook/utility-types.h...
Edit: nevermind, LLM fooled me.
It's simple, and it doesn't work as `Exclude` only applies to union types. For type `string` it just returns the same type `string`.
yup, it's not possible to do it safely with a simple unparameterised type: https://www.typescriptlang.org/play/?#code/C4TwDgpgBAcg9gOwK...
It is very much mentioned in the article title and the first sentence. It's just HN that's truncated the title.
Speaking of TS, there's stuff in there for typing strings / string formats: https://www.typescriptlang.org/docs/handbook/2/template-lite...
Daily reminder that TypeScript's type checker is not sound.
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAcg9gOwK...
It is true, but it wasn't meant to be sound, so it's okay.
You can do this trick for type-checking emptiness of string literals
https://www.typescriptlang.org/play/?jsx=0#code/C4TwDgpgBAsg...
Daily reminder that the unsoundness in Typescript's type checker is a practical compromise applied to a language that was never designed to be type checked in this way, and furthermore that many developers feel that it strikes a good balance between formal correctness and practical usability.
This example is not only wrong for what you intend to demonstrate but even if it wasn't, it's not problematic. In typescript the proper way to do this is using branded types and exporting only the safe constructor, making anyone who wants to violate the invariant go out of their way, which is no different from the situation in any number of programming languages or scenarios.