Why Co–Star Uses Haskell(costarastrology.com)
costarastrology.com
Why Co–Star Uses Haskell
https://www.costarastrology.com/why-haskell
269 comments
I've been getting lots of ads about IHP on reddit lately. The ads are really bad, which led me to believe IHP would be of equally bad quality, but looking at IHP homepage now I'll just have to try it out sometime.
Now, I have some questions. As a user, why should I use IHP instead of Yesod or Servant? Can I create rest and especially graphql apis or is it more focused on building old-school server side rendered pages?
Thanks for the feedback on the ads! We've been experimenting a lot with different ad formats recently. I'll make sure this is fixed. (Update: Fixed now, thanks again for the honest feedback)
In a comparison between IHP and Yesod I think that IHP is designed for people that have only very little to no haskell experience. IHP brings a lot of conventions and code generators to get you up and running very quickly, while Yesod gives you more flexibility (flexibility might be more challenging when you're just starting out with haskell. E.g. what DB library do you want to pick? In Yesod you have many options, in IHP we'll provide one out of the box). Check out the IHP documentation and compare it to the Yesod docs, you'll quickly see the difference :) Also if you want to check out some reviews of people already using IHP, you can find a few longer ones on our G2 page https://www.g2.com/products/ihp/reviews
> Can I create rest and especially graphql apis or is it more focused on building old-school server side rendered pages?
At the start IHP was focussed a lot on server-side rendering. Now you can also use it for building REST APIs. GraphQL is not yet supported, but it's coming in the future.
We're also right now working on a generic REST API layer with a bundled JS SDK. It will allow you to query your database, create and delete models and keep everything in sync with a realtime sync engine.
Here's a JS code example:
Here's a demo react component that uses the new JS APIs: https://github.com/digitallyinduced/ihp-datasync-demo/blob/m...
Docs are still in progress, but here's a draft https://github.com/digitallyinduced/ihp/commit/39baa4aa23cc6... :)
In a comparison between IHP and Yesod I think that IHP is designed for people that have only very little to no haskell experience. IHP brings a lot of conventions and code generators to get you up and running very quickly, while Yesod gives you more flexibility (flexibility might be more challenging when you're just starting out with haskell. E.g. what DB library do you want to pick? In Yesod you have many options, in IHP we'll provide one out of the box). Check out the IHP documentation and compare it to the Yesod docs, you'll quickly see the difference :) Also if you want to check out some reviews of people already using IHP, you can find a few longer ones on our G2 page https://www.g2.com/products/ihp/reviews
> Can I create rest and especially graphql apis or is it more focused on building old-school server side rendered pages?
At the start IHP was focussed a lot on server-side rendering. Now you can also use it for building REST APIs. GraphQL is not yet supported, but it's coming in the future.
We're also right now working on a generic REST API layer with a bundled JS SDK. It will allow you to query your database, create and delete models and keep everything in sync with a realtime sync engine.
Here's a JS code example:
const tasks = await query('tasks')
.orderBy('createdAt')
.fetch()
Here's a demo react component that uses the new JS APIs: https://github.com/digitallyinduced/ihp-datasync-demo/blob/m...
Docs are still in progress, but here's a draft https://github.com/digitallyinduced/ihp/commit/39baa4aa23cc6... :)
To me, IHP provides so many great features for making type-safe robust web apps, I have forgotten about GraphQL.
IHP looks like an impressive work, I'm seeing a lot of the kinds of things that drew me from Ruby/Rails to Elixir/Phoenix here, and all of those things are good... plus I love how the type safety is basically all implicit now, which seems like the best of both worlds- ruling out additional classes of bugs but without needing to be explicitly verbose all the time about types.
Quick question - when you change the schema def, does it generate a schema diff automatically and run that? What if you have to do some more complex things like add triggers or stored procs (such as might be necessary if you use Postgres' fulltext search features, which I am wont to do)?
Second question- Is there something I could read to catch up with what's happened to the Haskell language over the last 5-10 years or so, since I looked at it last?
Quick question - when you change the schema def, does it generate a schema diff automatically and run that? What if you have to do some more complex things like add triggers or stored procs (such as might be necessary if you use Postgres' fulltext search features, which I am wont to do)?
Second question- Is there something I could read to catch up with what's happened to the Haskell language over the last 5-10 years or so, since I looked at it last?
Thanks for the feedback! :)
Automatic migration generation has only been added in the last release a few weeks ago. Right now it works by keeping track of all changes you apply via the GUI based schema designer, and then writing that into the migration sql file once you generate a new migration.
When you add a trigger manually to the Schema.sql file of your app, you then still need to copy it over to the migration manually right now.
We're still exploring that auto migration space. In the future we might switch to a real schema diff approach (in fact there's a WIP PR here https://github.com/digitallyinduced/ihp/pull/1137)
> Second question- Is there something I could read to catch up with what's happened to the Haskell language over the last 5-10 years or so, since I looked at it last?
I'm not aware about a central place for this. The closest might be the GHC change log, but that also contains a lot of noise.
Automatic migration generation has only been added in the last release a few weeks ago. Right now it works by keeping track of all changes you apply via the GUI based schema designer, and then writing that into the migration sql file once you generate a new migration.
When you add a trigger manually to the Schema.sql file of your app, you then still need to copy it over to the migration manually right now.
We're still exploring that auto migration space. In the future we might switch to a real schema diff approach (in fact there's a WIP PR here https://github.com/digitallyinduced/ihp/pull/1137)
> Second question- Is there something I could read to catch up with what's happened to the Haskell language over the last 5-10 years or so, since I looked at it last?
I'm not aware about a central place for this. The closest might be the GHC change log, but that also contains a lot of noise.
>If you're curious about giving it a try and are doing web dev, check out IHP, haskell's largest web framework: https://ihp.digitallyinduced.com/ (Disclaimer: I'm founder of the company that makes IHP)
Something ironic about getting a 502 from your domain right now
Something ironic about getting a 502 from your domain right now
Haha yes :) Sorry, the IHP website is hosted via https://ihpcloud.com/ (like Heroku but for IHP) and the system just crashed because of too much activity (unrelated to the HN traffic, mostly too many deployments at the same time). We're about to roll out a new more stable system in the next days that fixes the root cause of the downtime today.
Two non-surprises here:
> We currently have exactly two backend engineers. A single Haskell engineer can support a 2:3+:1 data:FE:BE developer ratio and still have free BE time.
1) That they have 1-2 Haskell developers.
2) That backend is very straightforward once you separate it from data engineering and frontend, because you don't have to deal with hardware or wetware (pesky "side effects") like those other poor sods. This applies to virtually any popular backend language.
Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their real world utility beyond that.
> We currently have exactly two backend engineers. A single Haskell engineer can support a 2:3+:1 data:FE:BE developer ratio and still have free BE time.
1) That they have 1-2 Haskell developers.
2) That backend is very straightforward once you separate it from data engineering and frontend, because you don't have to deal with hardware or wetware (pesky "side effects") like those other poor sods. This applies to virtually any popular backend language.
Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their real world utility beyond that.
Evidence does not remain scant. For instance - ever used Starbucks Rewards? Congrats, you used Haskell software built by more than "two buddies." Ever shop at Target? Congrats, the inventory was likely in the store to fulfill your demand in part thanks to Haskell software built by a team.
However, a large engineer org that brings in senior non-Haskeller engineers/managers/leadership is bound to run into political troubles imo. Those types tend to blame Haskell and use it as an excuse for rewriting and re-orging - hence giving them newfound power. This isn't FUD or a strawman. This is observed behavior of many "respected" "old heads" I've had to work with/for.
That's just my experience from 3 different companies lol :) You can build software at any scale with Haskell - you just have to actually like and want to use Haskell for its cultural and technical benefits. Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out. That's just facts.
However, a large engineer org that brings in senior non-Haskeller engineers/managers/leadership is bound to run into political troubles imo. Those types tend to blame Haskell and use it as an excuse for rewriting and re-orging - hence giving them newfound power. This isn't FUD or a strawman. This is observed behavior of many "respected" "old heads" I've had to work with/for.
That's just my experience from 3 different companies lol :) You can build software at any scale with Haskell - you just have to actually like and want to use Haskell for its cultural and technical benefits. Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out. That's just facts.
> Sadly, a complainer at the top of the org chart who can't even read Haskell code can easily come in and force Haskell out.
It’s a lazy language so estimating real world performance is hard. It has a slow compiler and a very shallow pool of talents. You don’t really need to be a complainer to think that removing it from your organisation code base is a step in the right direction if you are not an Haskell shop. I would do the same with Ocaml despite liking Ocaml.
It’s a lazy language so estimating real world performance is hard. It has a slow compiler and a very shallow pool of talents. You don’t really need to be a complainer to think that removing it from your organisation code base is a step in the right direction if you are not an Haskell shop. I would do the same with Ocaml despite liking Ocaml.
> I would do the same with Ocaml despite liking Ocaml.
Ah yes, the language that's so famously bad at performance that its only noteworthy usage in industry is... a trading firm that needs to be able to handle data in microseconds to make money. If only they had chosen better.
Ah yes, the language that's so famously bad at performance that its only noteworthy usage in industry is... a trading firm that needs to be able to handle data in microseconds to make money. If only they had chosen better.
The key point is the shallow pool of talents. JaneStreet definitely qualify as an Ocaml shop if you didn’t notice. It is an awesome language but I would never use it in a company which is not purely banking on it.
If you hire remote, the Haskell job market has plenty of good engineers ime.
* For most real world use, laziness and performance don't even matter. That's definitely not a good reason. If you're an engineering leader and that's your argument for moving off Haskell for, say, a backend system..then you're either being disingenuous or are a bad decision maker.
* The full compiles can be slow, but incremental compilation with ghci and cabal is never so awful in practice. And I've worked on some big projects.
* I don't think the talent pool is especially shallow. I've never had trouble hiring Haskellers or finding a job as a Haskeller. If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture), it's even easier. I built some projects entirely with teams of new Haskellers. Went great.
* The full compiles can be slow, but incremental compilation with ghci and cabal is never so awful in practice. And I've worked on some big projects.
* I don't think the talent pool is especially shallow. I've never had trouble hiring Haskellers or finding a job as a Haskeller. If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture), it's even easier. I built some projects entirely with teams of new Haskellers. Went great.
> If you broaden your scope to the Haskell-interested (and have teaching and learning core to your culture)
So, first you have to hire quite senior Haskell engineers, and then at one point switch them to tracking Haskell to new hires.
There aren't many companies who are willing to do that, and for a good reason.
So, first you have to hire quite senior Haskell engineers, and then at one point switch them to tracking Haskell to new hires.
There aren't many companies who are willing to do that, and for a good reason.
Training new hires in Haskell isn't a full-time job. Nor one only doable by senior engineers. I've had interns teaching interns, juniors teaching juniors, etc.
Only prerequisite is a good attitude. If you start bean counting, you've already lost. If you think this level of software engineering cost optimization is necessary, you're just making your workplace worse.
Only prerequisite is a good attitude. If you start bean counting, you've already lost. If you think this level of software engineering cost optimization is necessary, you're just making your workplace worse.
> I've had interns teaching interns, juniors teaching juniors
If those interns and juniors came to you knot knowing Haskell, then this is a very bad way of teaching people. You end up with bad, non-idiomatic code, poorly understood concepts etc.
> If you start bean counting
It's not bean counting.
If those interns and juniors came to you knot knowing Haskell, then this is a very bad way of teaching people. You end up with bad, non-idiomatic code, poorly understood concepts etc.
> If you start bean counting
It's not bean counting.
We ended up with plenty of idiomatic code. They came in with 0 FP knowledge.
Turns out you can learn the ropes & values in a couple months tops. Then you can learn with anyone and grow together.
All the things you fear are barely consequential in practice in Haskell. All those things - who cares? What's the worst that can happen? The language puts such a high floor on the code it's okay. The main mistakes these newbies can make are stuff about database & distributed system design - orthogonal to Haskell and something they should be mentored on anyways.
Turns out you can learn the ropes & values in a couple months tops. Then you can learn with anyone and grow together.
All the things you fear are barely consequential in practice in Haskell. All those things - who cares? What's the worst that can happen? The language puts such a high floor on the code it's okay. The main mistakes these newbies can make are stuff about database & distributed system design - orthogonal to Haskell and something they should be mentored on anyways.
> Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their real world utility beyond that.
We (Mercury) have 60 backend engineers working on a monolithic Haskell backend. So at least there is one counterpoint to your hypothesis.
We (Mercury) have 60 backend engineers working on a monolithic Haskell backend. So at least there is one counterpoint to your hypothesis.
What does your onboarding process look like for Haskell engineers? Ballpark time-to-first-master-commit for new hires?
I'm another Mercury employee. When I joined there wasn't much of a specific onboarding process at all, beyond being given a few simple tickets to work on and pointed to some documentation.
I had written a very small amount of Haskell before, but IIRC correctly I think I made my first commit only a few weeks after joining. In general even people without an existing strong FP background seemed to become productive pretty quickly.
I had written a very small amount of Haskell before, but IIRC correctly I think I made my first commit only a few weeks after joining. In general even people without an existing strong FP background seemed to become productive pretty quickly.
First they said that functional programming is only used for toy/proof of concept/academic things. And that’s fine, to the extent that that is true. There is a sort of real world/academenia dichotomy.
But now you’re deriding functional programming because it is used on... a regular old boring backend. Used to power a non-FP-related domain (to dismiss the “I used FP to implement another FP language” critique...). On an ostensibly real-world application. And you contrast this backend with “real world utility”...
This is quite confusing.
But now you’re deriding functional programming because it is used on... a regular old boring backend. Used to power a non-FP-related domain (to dismiss the “I used FP to implement another FP language” critique...). On an ostensibly real-world application. And you contrast this backend with “real world utility”...
This is quite confusing.
> Yet another confirmation that pure functional langs work great when its just one or two buddies working on a "pure programming" project, but evidence remains scant of their utility beyond that.
Evidence is abundant if you look for it. FB, Microsoft, and Standard Chartered all have active internal haskell projects.
Evidence is abundant if you look for it. FB, Microsoft, and Standard Chartered all have active internal haskell projects.
Like all evidence, it is actually easy to find both sides. Notably, I have yet to come across a project in clojure, Haskel, or scala that wasn't abandoned as soon as the major advocate for that language left the group.
Sad in the cases where it was a well done project. Frustrating when it was bursting at the seams.
Sad in the cases where it was a well done project. Frustrating when it was bursting at the seams.
The main reason for that phenomenon is it's more personally advantageous to rewrite than to learn Haskell and extend what's there.
Haskell advocate quits? Blame them for selfishly using a toy language (they're gone anyways - who is gonna disagree?), and save the day by spending a long time reimplementing an MVP subset of what they already did. Congrats - you're a hero! The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code.
I've seen this happen multiple times. For shame - and yes people did get promotions for it. Pathetic.
Haskell advocate quits? Blame them for selfishly using a toy language (they're gone anyways - who is gonna disagree?), and save the day by spending a long time reimplementing an MVP subset of what they already did. Congrats - you're a hero! The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code.
I've seen this happen multiple times. For shame - and yes people did get promotions for it. Pathetic.
That would be the sad case. I have also seen the case where the code was impenetrable and did not at all lend itself to extension.
I've worked on a Haskell project supposedly like that. Took me a couple weeks of not complaining to improve it significantly. The trick was not closing my eyes at the sight of ugly bad code.
My problem with this, is you can replace "Haskell" with any other language in that sentence, and it still works.
Why's that a problem? It is true if any language.
But people act like Haskell can create a mess that is beyond what other languages can create. To the point where it isn't true that you can just..fix it by not complaining.
But people act like Haskell can create a mess that is beyond what other languages can create. To the point where it isn't true that you can just..fix it by not complaining.
Hmmm. I can see your point that folks act like it can create a mess beyond other languages.
I agree that that is not accurate. I suspect it is more a reaction to the seeming claim that it is immune to that. For my part, my claim was meant to be that it needs an advocate. That is all.
I do not know why they other languages have in built advocacy across the board. Python, in particular, is seeing a ton of good will in ways I just don't understand.
I agree that that is not accurate. I suspect it is more a reaction to the seeming claim that it is immune to that. For my part, my claim was meant to be that it needs an advocate. That is all.
I do not know why they other languages have in built advocacy across the board. Python, in particular, is seeing a ton of good will in ways I just don't understand.
>The end product has less functionality, but at least you didn't have to do something actually hard like learn Haskell and work with Someone Else's Code.
But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. I am currently rebuilding an application full of intractable bugs and proprietary DSLs that was implemented in Salesforce with lots of bells and whistles that nobody wants or needs to be a simple Golang/Mysql app hosted on AWS. Yes, it is a tiny subset of the current functionality. But it solves the business case and will save millions of dollars per year in Salesforce fees while simultaneously making the user experience an order of magnitude simpler and allowing faster onboarding.
Engineers allowed to run free can often times spend an inordinate amount of time building things out that no one really asked for. Your Haskell backend was probably a thing of pure beauty from a programmers point of view. But an expensive liability to the business.
But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win. I am currently rebuilding an application full of intractable bugs and proprietary DSLs that was implemented in Salesforce with lots of bells and whistles that nobody wants or needs to be a simple Golang/Mysql app hosted on AWS. Yes, it is a tiny subset of the current functionality. But it solves the business case and will save millions of dollars per year in Salesforce fees while simultaneously making the user experience an order of magnitude simpler and allowing faster onboarding.
Engineers allowed to run free can often times spend an inordinate amount of time building things out that no one really asked for. Your Haskell backend was probably a thing of pure beauty from a programmers point of view. But an expensive liability to the business.
> But did the business need all of that functionality? Rewriting a subset of an application that is far more maintainable and cost effective in the long run can be a huge win.
It was needed enough that the rewrite (which was slow) had to delay release and the legacy software had to be kept alive well past its sunset date (and plenty of people jetted by then.) Because the business had to keep the lights on!
The missing functionality at least was said to be missed by the business folks who made use of it. "If only we had feature X" definitely was said.
There wasn't anything too beautiful about the Haskell. It was mostly systems work. But incrementally evolving and improving would've definitely be cheaper long term than a rewrite .. but it does require people to learn Haskell, which seems to be a nonstarter for many. If people don't wanna, they don't wanna.
It was needed enough that the rewrite (which was slow) had to delay release and the legacy software had to be kept alive well past its sunset date (and plenty of people jetted by then.) Because the business had to keep the lights on!
The missing functionality at least was said to be missed by the business folks who made use of it. "If only we had feature X" definitely was said.
There wasn't anything too beautiful about the Haskell. It was mostly systems work. But incrementally evolving and improving would've definitely be cheaper long term than a rewrite .. but it does require people to learn Haskell, which seems to be a nonstarter for many. If people don't wanna, they don't wanna.
This sounds like a good thing to me actually. If your company's primary language is X and you only have one enthusiast for Haskell (or any other such language), it's a bad idea to let them build critical components in their pet language. It's worth longer time for a rewrite and maybe fewer features if you can now count on anybody in the company being able to start working on it fast, instead of having to learn a whole new language and ecosystem first. It might even be less work to learn that language, but that work has to be repeated anytime somebody new needs to touch the code.
If you wanna have a supported component in some new language, you need higher-level commitment to keeping a reasonable size bench of developers who know that language at various skill levels. Of course unless you're a rather big company, maintaining hiring and training pipelines for multiple languages can be quite inefficient.
If you wanna have a supported component in some new language, you need higher-level commitment to keeping a reasonable size bench of developers who know that language at various skill levels. Of course unless you're a rather big company, maintaining hiring and training pipelines for multiple languages can be quite inefficient.
The main problem in my experience is the initial engineering team that builds the MVP is very into Haskell, and then as the team/org/company grows, they bring in outside leadership.
Outside leadership doesn't embrace Haskell (they don't know it), so they see it as a threat instead of as something to value. So then the Haskellers bleed (either due to the culture clash or due to the leadership intentionally hiring against Haskell. I saw a VPE literally say that "wanting to work in Haskell" as a motivation is a "red flag"!) and now you have a Haskell project but no Haskellers.
It wasn't Haskell's fault. But it'll take the blame by the boneheads.
Outside leadership doesn't embrace Haskell (they don't know it), so they see it as a threat instead of as something to value. So then the Haskellers bleed (either due to the culture clash or due to the leadership intentionally hiring against Haskell. I saw a VPE literally say that "wanting to work in Haskell" as a motivation is a "red flag"!) and now you have a Haskell project but no Haskellers.
It wasn't Haskell's fault. But it'll take the blame by the boneheads.
Main problem that I have seen, is that new programmers jump on a lot of the higher level abstractions, mainly just because they can. It winds up obscuring more than it helps. Worse, it often locks them in to particular abstractions that aren't a good direction for where things are going.
Juniors write bad code in all languages. Why is Haskell's version of this so much worse?
My claim wasn't that the Haskell version is worse. Just that it isn't some super power that is free from this problem.
It does mitigate the problem. The worst Haskell mess I've seen is nothing compared to the balls of mud that can be made in less disciplined languages. They're not All the Same.
You may have just been lucky. The worst balls of mud I have inherited were in highly functional styles and systems.
Conversely, I may have just been unlucky. Would love to see studies and data.
Conversely, I may have just been unlucky. Would love to see studies and data.
> Notably, I have yet to come across a project in ... Haskell ... that wasn't abandoned as soon as the major advocate for that language left the group.
The Haskell OGs of Don Stewart, Roman Leshchinsky, Neil Mitchell, Lennart Augustsson and more left Standard Chartered. Haskell is now more widely used in Standard Chartered than it was when they were there!
The Haskell OGs of Don Stewart, Roman Leshchinsky, Neil Mitchell, Lennart Augustsson and more left Standard Chartered. Haskell is now more widely used in Standard Chartered than it was when they were there!
This furthers my claim that there is evidence on both sides. Would be amazing if there was a study.
I'm pretty sure Nubank has for years and continues to rely heavily on Clojure. (to the point where they acquired Cognitect)
Right, I meant my point to be that you can find evidence on both sides. Far as I can see, language is not a predictor of success.
Having an advocate for a program is a predictor. That advocate doesn't have to be a developer.
Having an advocate for a program is a predictor. That advocate doesn't have to be a developer.
Seems like you just haven't come across many projects then.
?? Do you have studies or collections of evidence that shows it skews in the other direction?
Yeah, myself. I have worked in multiple companies that used Scala and still do, even after the original people who introduced Scala already left.
That says nothing of the number of projects I have seen.
And note that I am not anti these languages. Just acking that there is plenty of experience on both isles.
And note that I am not anti these languages. Just acking that there is plenty of experience on both isles.
Do any of these projects have more than 1-2 active maintainers?
None of them are individual projects, all of those companies have several projects in Haskell. Standard Chartered, for one, have their own custom implementation of Haskell and it is used by dozens of developers across different projects.
I've always been fascinated by the fact that these claims are always completely unfalsifiable.
"A lot of companies use this <non mainstream language> in internal projects but since it's internal, we can't show you".
It reminds me of "I have a girlfriend but she goes to another school".
"A lot of companies use this <non mainstream language> in internal projects but since it's internal, we can't show you".
It reminds me of "I have a girlfriend but she goes to another school".
I mean, what are those of us in this category supposed to do?
For the last 5 years I have 7 developers that have been working on internal applications in Haskell for an enterprise company that I am not able to show you due to legal reasons. We have a small open source library or two out there, but they are not even remotely representative of how deep our development iceberg really is.
For the last 5 years I have 7 developers that have been working on internal applications in Haskell for an enterprise company that I am not able to show you due to legal reasons. We have a small open source library or two out there, but they are not even remotely representative of how deep our development iceberg really is.
Show corresponding Haskell vacancies—somebody has to maintain the code if it exists.
https://engineering.fb.com/2015/06/26/security/fighting-spam...
https://www.reddit.com/r/haskell/comments/phooqo/haskell_rol... https://www.reddit.com/r/haskell/comments/oee437/job_ad_seni... https://www.reddit.com/r/haskell/comments/nug8mw/haskell_job... https://www.reddit.com/r/haskell/comments/nn11sm/haskell_job... https://www.reddit.com/r/haskell/comments/n642ve/haskell_dev...
https://www.reddit.com/r/haskell/comments/8io3uk/job_work_on...
https://www.reddit.com/r/haskell/comments/phooqo/haskell_rol... https://www.reddit.com/r/haskell/comments/oee437/job_ad_seni... https://www.reddit.com/r/haskell/comments/nug8mw/haskell_job... https://www.reddit.com/r/haskell/comments/nn11sm/haskell_job... https://www.reddit.com/r/haskell/comments/n642ve/haskell_dev...
https://www.reddit.com/r/haskell/comments/8io3uk/job_work_on...
I've tech diligenced 200+ software companies and I've seen Haskell twice and Clojure once. The two that were using Haskell had to drop the project and rewrite because they couldn't find enough developers.
I have zero problems with the technical capabilities of functional programming languages, but it's simply not a smart decision to use them in for profit businesses writing CRUD apps. It simply doesn't make economic sense. When you get to scale and need to write <insert specific modular service that does this one thing really well> then it starts to make more sense.
I have zero problems with the technical capabilities of functional programming languages, but it's simply not a smart decision to use them in for profit businesses writing CRUD apps. It simply doesn't make economic sense. When you get to scale and need to write <insert specific modular service that does this one thing really well> then it starts to make more sense.
So if you can find developers then it makes sense to better software in a more powerful language? That seems like not really a problem with either of those two languages.
"more powerful language"
Heh. My pickup truck has more torque than my Ferrari, but my ferrari goes to 60 much quicker. "Power" requires context, especially when it comes to programming languages.
Heh. My pickup truck has more torque than my Ferrari, but my ferrari goes to 60 much quicker. "Power" requires context, especially when it comes to programming languages.
There are languages that objectively make it easier to manage complicated things. They enforce strong guards against user errors and they are easy to refactor even in a large codebase it means you can do more things with a smaller team.
Whether you can find people to work on hard problems easily seems completely orthogonal to the language used in the same way that its also very hard to find top Java/C++ etc developers capable of handling non trivial work but we don't throw our hands up and say "Welp we'll just have to write it in python then because this problem is too hard".
Whether you can find people to work on hard problems easily seems completely orthogonal to the language used in the same way that its also very hard to find top Java/C++ etc developers capable of handling non trivial work but we don't throw our hands up and say "Welp we'll just have to write it in python then because this problem is too hard".
Microsoft have their own functional language. Not exactly an internal protect.
[deleted]
Haskell is used in one "not real world" project doesn't mean it can't be used in "real world" projects.
Here is an article titled 7 Useful Tools Written in Haskell: https://typeable.io/blog/2021-10-18-haskell-tools
I think it's generational.
I believe we are limited by our own experience, a lot of software is built upon the idea that problems are solved through procedural steps rather than a series of transformations.
This does not lend itself to thinking in a way that aligns nicely with functional programming.
Future generations will naturally think in ways unfathomable to you and I, and this will cause a shift in the fundamental approaches to software development.
I believe we are limited by our own experience, a lot of software is built upon the idea that problems are solved through procedural steps rather than a series of transformations.
This does not lend itself to thinking in a way that aligns nicely with functional programming.
Future generations will naturally think in ways unfathomable to you and I, and this will cause a shift in the fundamental approaches to software development.
I think it’s subjective. I learned Haskell early on in university and I’ve learned Lisps and it still feels like extra work to reason about programs or model domains in functional languages.
I believe functional programming advocates when you guys say it works better. But I only believe it works better for you. In my experience there’s a minority of people who find functional programming to be a powerful paradigm shift but for most developers functional programming either doesn’t resonate or resonates at the level of an academic exercise that helps you think better about writing code but best remains an academic exercise.
I believe functional programming advocates when you guys say it works better. But I only believe it works better for you. In my experience there’s a minority of people who find functional programming to be a powerful paradigm shift but for most developers functional programming either doesn’t resonate or resonates at the level of an academic exercise that helps you think better about writing code but best remains an academic exercise.
It can be extra work to reason about the performance and efficiency of functional programs, such is the case with higher level languages. But modelling the domain is far easier. I can solve difficult problems using Haskell, e.g. writing a specialist DSL compiler targeting a GPU. I'm just not smart or patient enough to solve such problems in C/C++ or Java, although I do concede that many can.
I did the same path as you.
I think that the procedural programming is much more common because of the academic and work experience of many programmers. Functional programming is a transition of the way of thinking that seems not worth it. But after I got my hands dirty, I found myself writing much more clean and consistent code in every language. I enjoyed particularly Clojure because has a good ecosystem and tools, and also take some design decisions to steer you for a more robust code. https://clojure.org/about/functional_programming#_immutable_...
I think that the procedural programming is much more common because of the academic and work experience of many programmers. Functional programming is a transition of the way of thinking that seems not worth it. But after I got my hands dirty, I found myself writing much more clean and consistent code in every language. I enjoyed particularly Clojure because has a good ecosystem and tools, and also take some design decisions to steer you for a more robust code. https://clojure.org/about/functional_programming#_immutable_...
I broadly agree. I actually think most people are most at home in the procedural domain, and most just write procedural code in OOP languages. Which is hard to do in an FP.
Erlang is often described as having an imperative core. It was my gateway drug for FP, I certainly found it much easier to grasp and write than any Lisp.
As did I. I went imperative languages -> Haskell (wtf) -> Clojure (wtf) -> Erlang (love it) -> Clojure (love it) -> Elixir (love it).
My two favorite languages these days are Clojure and Elixir. Currently mostly Clojure because my main side project is more amenable to Clojure's methods of concurrency than Elixir.
My two favorite languages these days are Clojure and Elixir. Currently mostly Clojure because my main side project is more amenable to Clojure's methods of concurrency than Elixir.
Last time I checked, everything is still running on von Neumann/Harvard CPUs. Did I miss a major revolution in computing?
Forgive the tangent, but your comment reminded me of item #52 on the venerable "Things to say when you're losing a technical argument" list. :)
http://web.archive.org/web/20050131033632/http://www.skirsch...
http://web.archive.org/web/20050131033632/http://www.skirsch...
Yikes.
Yes, nowadays we have those machines, called computers (or automatic computers if you need the older name for reference), that can take software made for one architecture, no matter how unreal, and turn it into software made for another architecture.
Could you share a Haskell compiler that produces output that can execute on a real non-von Neumann/Harvard architecture?
Why would anyone have built one of those, if non-von Neumann architectures are so rare? Compilers aren't much of a weekend project. I don't get your point.
[deleted]
Yes
Honestly my first thought when I saw the title “why we use Haskell” was “because you have one engineer and they like Haskell?” I suppose I was wrong. It was two.
From https://www.costarastrology.com/jobs:
> Every day, we generate millions of hyper-personalized horoscopes using rules-based natural language generation that combines state-of-the-art AI models like GPT-3 with the insights of staff poets. Co–Star is the first synthetic text to be called wildly beautiful, brutally honest, or comparable to therapy.
So their horoscopes are largely auto-generated, and aren't even written by humans with knowledge of astrology? This seems like something you would only do if you knew astrology was a scam, and therefore that no real expertise was needed to engage in it. Makes you wonder...
> Every day, we generate millions of hyper-personalized horoscopes using rules-based natural language generation that combines state-of-the-art AI models like GPT-3 with the insights of staff poets. Co–Star is the first synthetic text to be called wildly beautiful, brutally honest, or comparable to therapy.
So their horoscopes are largely auto-generated, and aren't even written by humans with knowledge of astrology? This seems like something you would only do if you knew astrology was a scam, and therefore that no real expertise was needed to engage in it. Makes you wonder...
>This seems like something you would only do if you knew astrology was a scam, and therefore that no real expertise was needed to engage in it.
In theory someone could believe that astrology was real and could be learned by a machine learning model, no?
In theory someone could believe that astrology was real and could be learned by a machine learning model, no?
Alternatively, that astrology is so real, aleatoric methods are even better than human ones.
At that point, why even do the astronomical calculations? You could just do them and throw them away, or rebrand as an AI therapy app
So the code is largely auto-generated, and aren't even written by humans with knowledge of coding? This seems like something you would only do if you knew coding was a scam, and therefore that no real expertise was needed to engage in it. Makes you wonder...
The fact that there are only two backend developers seems like a big asterisk to me. It's admirable how productive their backend team has been, but tiny teams are often surprisingly productive. Communication costs and distributed decision-making often slow development a lot.
What I'm wondering, as someone who doesn't know Haskell, is how well will it work if the team needs to scale? Will they be able to find quality engineers? Will those new engineers be able to easily pick up the pieces if one of the two engineers leaves unexpectedly?
I certainly am biased here, but pure functional programming has always seemed unnecessarily abstract and constricted for the purposes of most applications. The communication of function and purpose to other engineers is an important responsibility of code. Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's.
To be clear, I am not suggesting all Haskell code is poorly-written or hard to understand. But writing clear code is not a priority for a lot of engineers, and in my experience, functional programming can lead to especially opaque codebases.
What I'm wondering, as someone who doesn't know Haskell, is how well will it work if the team needs to scale? Will they be able to find quality engineers? Will those new engineers be able to easily pick up the pieces if one of the two engineers leaves unexpectedly?
I certainly am biased here, but pure functional programming has always seemed unnecessarily abstract and constricted for the purposes of most applications. The communication of function and purpose to other engineers is an important responsibility of code. Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's.
To be clear, I am not suggesting all Haskell code is poorly-written or hard to understand. But writing clear code is not a priority for a lot of engineers, and in my experience, functional programming can lead to especially opaque codebases.
> Using long sequences of poorly-labeled, nested arrow function returns is great fun until you have the task of deciphering someone else's.
Something like that would be considered bad Haskell code, yes. Haskell is designed from the ground up to support the functional paradigm. When people try to use functional style in languages that were designed with primarily procedural style in mind, the result is often ugly and difficult to follow. You just don't have the same issue in a language that's designed from the beginning as a functional language.
Something that people tend to miss is that you can write code that very much looks like a lot of procedural code in haskell:
I think it's a fair criticism to say that Haskell code can become opaque when it relies on more advanced language features and esoteric GHC extensions. The solution to this is to be disciplined and selective as a team about choosing which features you believe are worth their complexity/onboarding cost, and sticking to those choices.
Conversely, I find Haskell code that doesn't use those extra features to be much easier to understand than equivalent code in other languages, due to the extra guarantees I have about the code. For instance, I know that variables won't be mutated out from under me, things can't be null where they shouldn't be, and there are plenty of other assorted guarantees that come from having access to an expressive type system.
Something like that would be considered bad Haskell code, yes. Haskell is designed from the ground up to support the functional paradigm. When people try to use functional style in languages that were designed with primarily procedural style in mind, the result is often ugly and difficult to follow. You just don't have the same issue in a language that's designed from the beginning as a functional language.
Something that people tend to miss is that you can write code that very much looks like a lot of procedural code in haskell:
let
x = 1
y = x + 5
z = 10 + y + z
in x + y + z
I think it's a fair criticism to say that Haskell code can become opaque when it relies on more advanced language features and esoteric GHC extensions. The solution to this is to be disciplined and selective as a team about choosing which features you believe are worth their complexity/onboarding cost, and sticking to those choices.
Conversely, I find Haskell code that doesn't use those extra features to be much easier to understand than equivalent code in other languages, due to the extra guarantees I have about the code. For instance, I know that variables won't be mutated out from under me, things can't be null where they shouldn't be, and there are plenty of other assorted guarantees that come from having access to an expressive type system.
Perhaps this is pedantic, but that doesn't look like good procedural code to me. Instead, it looks like a set of mathematical equations.
I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability. How might you write to a MongoDB document in Haskell, for example?
A common example in this space is how to specify a baking recipe. Do you list it as a series of steps to perform on the world, or do you reductively assert what a cake is from base principles?
I think Haskell developers need to realize that pure functional programming is intrinsically more difficult than other kinds. It requires a much higher ceiling for abstract thought.
What I'm essentially trying to assert is that you have to be smarter than average (whatever that means) to read and write Haskell code. I believe this accounts for the majority of the perceived efficiency. The cost is that you are excluding people who are not mathematically talented.
I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability. How might you write to a MongoDB document in Haskell, for example?
A common example in this space is how to specify a baking recipe. Do you list it as a series of steps to perform on the world, or do you reductively assert what a cake is from base principles?
I think Haskell developers need to realize that pure functional programming is intrinsically more difficult than other kinds. It requires a much higher ceiling for abstract thought.
What I'm essentially trying to assert is that you have to be smarter than average (whatever that means) to read and write Haskell code. I believe this accounts for the majority of the perceived efficiency. The cost is that you are excluding people who are not mathematically talented.
> I think there is intrinsic value in simple, procedural code that has state and produces side effects - it can even be typed! However, I think FP maximalism is bad for code readability
I agree with you, with the caveat that some program wins from a simple imperative core, indeed! In some other areas FP shines, so I think posing the question as either or is fundamentally wrong.
Fortunately nowadays most mainstream languages do support plenty of the FP paradigm, sometimes simple lambdas can take you far away. And FP languages could always either imitate state (Haskell for example has a State monad specifically for that), or straight up manipulate it through unsafes, IO monad, etc.
I agree with you, with the caveat that some program wins from a simple imperative core, indeed! In some other areas FP shines, so I think posing the question as either or is fundamentally wrong.
Fortunately nowadays most mainstream languages do support plenty of the FP paradigm, sometimes simple lambdas can take you far away. And FP languages could always either imitate state (Haskell for example has a State monad specifically for that), or straight up manipulate it through unsafes, IO monad, etc.
> A common example in this space is how to specify a baking recipe.
Is that because written language is sequential?
Is that an example given by expert bakers?
Is that because the baking recipe assumes a single baker rather than multiple bakers?
How much of a baking recipe requires sequence? How much can be done in parallel?
Why do expert programmers talking to expert programmers shift their reasoning to domains in which they may not be expert?
Is that because written language is sequential?
Is that an example given by expert bakers?
Is that because the baking recipe assumes a single baker rather than multiple bakers?
How much of a baking recipe requires sequence? How much can be done in parallel?
Why do expert programmers talking to expert programmers shift their reasoning to domains in which they may not be expert?
It's not supposed to be good procedural code, it's supposed to be illustrative of the fact that a lot of code which people are used to seeing in procedural languages, which only involves assigning to a variable once, can be translated into a pure haskell function very straightforwardly, and it doesn't look intimidatingly esoteric like many people seem to expect. I can just as easily do it with strings if you're concerned about it being mathematical.
I agree that there are many problems more naturally represented by procedural code, and as such it's important for every language, even functional languages, to have good constructs for representing a series of steps.
Luckily, Haskell has such a construct in do notation. It looks like this:
I've heard the cake argument many times, and I agree that it's more naturally modelled as a series of steps. But I find it frustrating, because I've never heard a convincing argument for why the fact that one particular problem is more intuitively modelled as a sequence of steps, means all problems are.
For example, imagine if you were never allowed to declaratively specify a DOM again using HTML, but instead you had to construct it as a series of calls to element.appendChild(). Would that really make your life easier? There are many problems for which a declarative description, not a procedure, is much more straightforward to understand.
Another point is that you can also think of applying functions in succession ("function composition") as a series of steps! I find this pretty intuitive.
For example, here's a function which takes a list of words and shouts them. The steps are: First concatenate the words together, then capitalize the resulting string, then append an exclamation mark:
I think it's very easy to assume that functional programming is inherently more difficult, when it might well be that all that's going on is that people are more used to procedural programming because that's what they were taught first. I really would encourage anyone who thinks FP is inherently difficult to have a crack at learning Elm.
[1] https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Dat...
I agree that there are many problems more naturally represented by procedural code, and as such it's important for every language, even functional languages, to have good constructs for representing a series of steps.
Luckily, Haskell has such a construct in do notation. It looks like this:
main = do
putStrLn "What's your name"
name <- getLine
putStrLn ("Hello, " ++ name)
I've heard the cake argument many times, and I agree that it's more naturally modelled as a series of steps. But I find it frustrating, because I've never heard a convincing argument for why the fact that one particular problem is more intuitively modelled as a sequence of steps, means all problems are.
For example, imagine if you were never allowed to declaratively specify a DOM again using HTML, but instead you had to construct it as a series of calls to element.appendChild(). Would that really make your life easier? There are many problems for which a declarative description, not a procedure, is much more straightforward to understand.
Another point is that you can also think of applying functions in succession ("function composition") as a series of steps! I find this pretty intuitive.
For example, here's a function which takes a list of words and shouts them. The steps are: First concatenate the words together, then capitalize the resulting string, then append an exclamation mark:
λ » shoutWords = unwords .> capitalize .> exclaim
λ » shoutWords ["i'm", "shouting"]
"I'M SHOUTING!"
I think it's very easy to assume that functional programming is inherently more difficult, when it might well be that all that's going on is that people are more used to procedural programming because that's what they were taught first. I really would encourage anyone who thinks FP is inherently difficult to have a crack at learning Elm.
[1] https://hackage.haskell.org/package/mongoDB-2.7.1.1/docs/Dat...
For one, yeah, I think in important part is that the choice of technical tools is made for good reasons. A default, boring choice is probably okay. A more exciting choice might be okay.
For people who pick NodeJS.. for some, it may be the only thing they know, it might be something they dislike, or it might be something that seems practical. -- I dunno how many people pick Haskell out of practicality but would rather be using something else.
It's lame if someone picks a technology for bad reasons, and then makes bad decisions to exasperate it. e.g. Kubernetes is not bad, but I think if you end up with 5x as many microservices as developers, you've made a mistake.
All the same.. I think it's easy to write hard-to-understand code in any language.
For people who pick NodeJS.. for some, it may be the only thing they know, it might be something they dislike, or it might be something that seems practical. -- I dunno how many people pick Haskell out of practicality but would rather be using something else.
It's lame if someone picks a technology for bad reasons, and then makes bad decisions to exasperate it. e.g. Kubernetes is not bad, but I think if you end up with 5x as many microservices as developers, you've made a mistake.
All the same.. I think it's easy to write hard-to-understand code in any language.
> in my experience, functional programming can lead to especially opaque codebases.
That's interesting because my first favourite language was Python, but I gave it up for Haskell because of the former's propensity to lead to especially opaque codebases.
That's interesting because my first favourite language was Python, but I gave it up for Haskell because of the former's propensity to lead to especially opaque codebases.
I appreciate and agree with the attitude/approach here.
I suspect the author may be a bit removed from modern python, as the community is increasingly taking a similar stance. Python is not Haskell, but Python in 2021 with tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable). I'm not aware of ways to enforce function purity in python (do any linters complain about input modification or out-of-scope references?), but I try to make functions as pure as possible regardless of language or domain anyways.
I don't mean this as a flamewar, Haskell seems like the right choice for OP. I love how a language like python is making more of these benefits available to a wider audience and I wish more folks embraced these recent advances.
I suspect the author may be a bit removed from modern python, as the community is increasingly taking a similar stance. Python is not Haskell, but Python in 2021 with tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable). I'm not aware of ways to enforce function purity in python (do any linters complain about input modification or out-of-scope references?), but I try to make functions as pure as possible regardless of language or domain anyways.
I don't mean this as a flamewar, Haskell seems like the right choice for OP. I love how a language like python is making more of these benefits available to a wider audience and I wish more folks embraced these recent advances.
No matter how many type hints you put in your python code, haskell type system is on another level altogether.
I honestly believe every developer should get to experience writing some haskell code at some point in their lifes to really understand what I'm talking about.
A lot of people seem to think that type systems are either "you have it or you don't", when in actuality there are languages with type systems that can express significantly more intricate relationships among data than the common languages.
The issue, of course, is that most common languages people use have a type system based on C's (with minor improvements). Those are all mostly interchangeable. But languages like Haskell and OCaml have the capabilities to directly express notions with types that Python, Java, or C would deeply struggle with.
(All this is to say: I agree with your point that people would benefit from doing a bit of Haskell to experience this first-hand!)
The issue, of course, is that most common languages people use have a type system based on C's (with minor improvements). Those are all mostly interchangeable. But languages like Haskell and OCaml have the capabilities to directly express notions with types that Python, Java, or C would deeply struggle with.
(All this is to say: I agree with your point that people would benefit from doing a bit of Haskell to experience this first-hand!)
Another big difference is in performance. If your language doesn't support immutability, adding it in with a library (like in JS) will add a huge runtime cost, while you get that for free in Haskell/OCaml.
>tools like type-hints, mypy, (frozen)dataclasses, Pydantic, etc. is trying to address at least the latter two points here (type-driven & illegal-states-unrepresentable)
At some point you have to admit to yourself that it's the wrong tool for the job, when is this going to be?
Dependency/environment management is poor as well given how popular the language is. I believe it's popularity is similar to that of PHP in the past; flooded with carefree users.
I would strongly advise against using python for anything other than PoC/experimental endeavours.
It's a scripting language, and should be used as such.
At some point you have to admit to yourself that it's the wrong tool for the job, when is this going to be?
Dependency/environment management is poor as well given how popular the language is. I believe it's popularity is similar to that of PHP in the past; flooded with carefree users.
I would strongly advise against using python for anything other than PoC/experimental endeavours.
It's a scripting language, and should be used as such.
> I would strongly advise against using python for anything other than PoC/experimental endeavours.
I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.
I agree with your points, but this seems to lean a bit too far the other way. Yes, Python has plenty of limitations and cases where there are better choices in programming language. But saying that it shouldn't be used in real production systems when there are so many examples of it being used effectively for precisely that seems a bit hyperbolic, no? It's like saying Javascript shouldn't be used in production.
> It's like saying Javascript shouldn't be used in production.
I mean… is that such an unreasonable point of view?
I mean… is that such an unreasonable point of view?
At least JS can be 50X faster than Python and it has TS.
I work in data science and engineering, so not using python is not really an option. I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet.
Python continues to earn its reputation as the second-best option for most problems.
Python continues to earn its reputation as the second-best option for most problems.
>> Python continues to earn its reputation as the second-best option for most problems
Never heard that line before but it resonates with me.
Never heard that line before but it resonates with me.
I agree absolutely.
It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
> I'd love to use Julia and Rust instead, but the ecosystems and users aren't there yet.
https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl
https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl
I don't know. I like Haskell, but practically I would still choose a dynamic language "with benefits" over Haskell for BE development. [1] For example, Python frameworks like FastAPI can enforce type discipline at the system boundary, and frankly it feels like a development sweet-spot. Rigour at the API level, but fast-and-loose reasoning can proceed as normal in the implementation.
It's a worse-is-better approach, to be sure, but it has a very appealing effort:result ratio.
[1] with the normal caveats -- every project is different, everybody's notion of a "backend" is different, etc. Haskell might be the sanest solution to some backend challenges.
It's a worse-is-better approach, to be sure, but it has a very appealing effort:result ratio.
[1] with the normal caveats -- every project is different, everybody's notion of a "backend" is different, etc. Haskell might be the sanest solution to some backend challenges.
FastAPI is hard to contend with for anything marginally complex, without having to dig deep in its internals.
If you want performance, or to apply more rigorous (read: enterprisey) development practices, you really are better off looking elsewhere.
However, you can get a Data Science python developer to front their code behind an API with minimal ceremony.
Type safety does not exist in Python. Type hinting does not solve this problem, neither does Pydantic. These are bandaids for huge shortcomings of using the wrong tool for the job.
If you want performance, or to apply more rigorous (read: enterprisey) development practices, you really are better off looking elsewhere.
However, you can get a Data Science python developer to front their code behind an API with minimal ceremony.
Type safety does not exist in Python. Type hinting does not solve this problem, neither does Pydantic. These are bandaids for huge shortcomings of using the wrong tool for the job.
Sure, but there's a continuum at play here. Haskell leaves some correctness on the table, right? -- you should be using Idris 2; or better yet, proving your API in Coq and extracting the code. From some perspectives, Haskell is the "worse" in "worse is better".
Personally I find python-is-wrong arguments to be a bit naive. "It's a crappy language that's only good enough to build prototypes..." -- like YouTube, for example? :) Ultimately, smart developers are smart, and can get work done with whatever tools they have at hand.
Personally I find python-is-wrong arguments to be a bit naive. "It's a crappy language that's only good enough to build prototypes..." -- like YouTube, for example? :) Ultimately, smart developers are smart, and can get work done with whatever tools they have at hand.
Just continually saying Python is the wrong tool for the job doesn't cut it. I've gotten a lot of mileage out of type hints in Python and have caught my share of bugs statically, so I disagree with your contention that it's merely a "bandaid for huge shortcomings". It's a helpful tool that serves a purpose.
You could pick at every tool, every language. What's better than Python at (since you brought it up) data science? Julia? That's hardly any more type safe, if that's an issue for you. Haskell? Good luck getting non-CS types to buy in to the restrictions, and good luck porting everything you need. R? Slower than Python, even! I mean, I dunno, if you have something in mind that's better in every way than Python then I'd love to hear it.
You could pick at every tool, every language. What's better than Python at (since you brought it up) data science? Julia? That's hardly any more type safe, if that's an issue for you. Haskell? Good luck getting non-CS types to buy in to the restrictions, and good luck porting everything you need. R? Slower than Python, even! I mean, I dunno, if you have something in mind that's better in every way than Python then I'd love to hear it.
R is way better than Python for most (all?) data science things. It's better at data munging, has more packages, it's array based so way more terse while being easy to reason about, has super easy C++ FFI, etc...
And no environment really beats RStudio.
And no environment really beats RStudio.
I dispute at least some of that. R has more statistical packages, perhaps, but can't compete with Python in terms of sheer array of packages and developer mindshare in general. This is no different for data science, where major tools are either Python-only or are accessed in R only through Python (like Tensorflow).
R is also hardly more terse in my experience, though perhaps that depends on style; I'm a tidyverse fan but it's not particularly concise.
Finally ... RStudio. It's just okay. If you're willing to use a language-specific editor that may not get keybindings right (I hope you're not an emacs user), it works fine. I like the RMarkdown integration. I don't use it, though, and I don't feel like I'm missing that much.
BTW, you don't mention what actually does make R better than Python: lazy evaluation allowing something close to syntactical macros. You'll never get a magrittr or a dplyr in Python.
R is also hardly more terse in my experience, though perhaps that depends on style; I'm a tidyverse fan but it's not particularly concise.
Finally ... RStudio. It's just okay. If you're willing to use a language-specific editor that may not get keybindings right (I hope you're not an emacs user), it works fine. I like the RMarkdown integration. I don't use it, though, and I don't feel like I'm missing that much.
BTW, you don't mention what actually does make R better than Python: lazy evaluation allowing something close to syntactical macros. You'll never get a magrittr or a dplyr in Python.
I agree and I really like that way of framing it; I want interfaces and contracts strong enough that I don't have to care about the implementation.
> do any linters complain about input modification or out-of-scope references?
I know Instagram was experimenting with something similar to this a couple years ago (“Python strict modules”).
It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust).
Definitely agree that Python is becoming more amenable to functional style programming over time. And it’s great!
I know Instagram was experimenting with something similar to this a couple years ago (“Python strict modules”).
It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust).
Definitely agree that Python is becoming more amenable to functional style programming over time. And it’s great!
> It might be possible to implement function purity with a decorator. (Kind of like declaring something “safe” in Rust).
Two parts to this. 1: Does it mutate variables. 2. Does the code have side effects.
1: def no_mut(func): @functools.wraps def new_func(args, *kwargs): new_args = tuple(copy.deepcopy(arg) for arg in args) new_kwargs = {k, copy.deepcopy(v) for k, v in *kwargs return func(new_args, *new_kwargs) return new_func
For the second point, gevent seemed to have a trick to identify side effecting code.
Two parts to this. 1: Does it mutate variables. 2. Does the code have side effects.
1: def no_mut(func): @functools.wraps def new_func(args, *kwargs): new_args = tuple(copy.deepcopy(arg) for arg in args) new_kwargs = {k, copy.deepcopy(v) for k, v in *kwargs return func(new_args, *new_kwargs) return new_func
For the second point, gevent seemed to have a trick to identify side effecting code.
Are there examples of moving from Python to Haskell? Would love to read and evaluate such options since I'm in dire need of moving away from Python to a typed language and Haskell seems like an interesting choice.
Not from Python to Haskell but Thomas Leonard[1] has a very nice series of blog posts about migrating 0install away from Python to OCaml, of which many points also apply to Haskell which he evaluated as a choice as well.
[1]: https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-...
[1]: https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-...
I moved from Python to Haskell, when I had had enough of debugging runtime failures. Excellent choice, go for it.
Can you please share codebases (if opensource) where you moved from Python to Haskell? It would help me understand how the porting was done and the design choices too.
Something lovely here about leveraging formal correctness for delivering astrology.
Mathematically-inclined people surviving by calculating outstandingly accurate and precise charts for producing superstitious bullshit is an ancient tradition
One of my favorites is Jantar Mantar https://en.wikipedia.org/wiki/Jantar_Mantar
Perhaps you are referring to the traditional sun-sign astrology found in tabloids/magazines? There are claims that you can get much more precise by looking at ascendant-based astrology which varies down to the minute and lat/long of the place you were born. Or are you referring to both? Are there sources out there in the literature proving/disproving modern Astrology? There is this article on Gauquelin's Mars effect for instance - https://en.wikipedia.org/wiki/Mars_effect
You mean "selection bias shows statistical significance whereas a larger study that eliminated this bias showed no correlation" precise looking?
On their front page:
> Most horoscopes ask what month you were born. Co–Star asks what minute.
> Access to astrology this accurate has historically been restricted to those with access to personal astrologers—now these predictions can be anyone's.
I mean, anyone can _ask_ what minute you were born. But what on earth can "accurate" mean in this context? I'm sure there's some modern tech we can use to measure your skull with great precision and detail, but I'm guessing that doesn't improve the predictions of phrenology.
> Most horoscopes ask what month you were born. Co–Star asks what minute.
> Access to astrology this accurate has historically been restricted to those with access to personal astrologers—now these predictions can be anyone's.
I mean, anyone can _ask_ what minute you were born. But what on earth can "accurate" mean in this context? I'm sure there's some modern tech we can use to measure your skull with great precision and detail, but I'm guessing that doesn't improve the predictions of phrenology.
Methods requiring minute level precision have been in use for centuries.
If it compiles your predictions are bug free
Astrology seems like such a strange thing for a Haskell developer to be spending her time on. I wouldn't think twice about it if the back-end was written in Python, but I just find it strange that she's sharp enough to be a Haskell pioneer, but still thinks the positions of stars influences what approach you should take in a relationship.
You probably don't need to believe in astrology to work there. Perhaps she just feels that this is a simple and mostly harmless way to separate some irrational individuals from their money. Which, on the whole, is probably a net benefit to society: If they weren't spending their discretionary funds on $20 astrology-themed in-app purchases they might instead put it toward something really dangerous.
It's possible to think that astrology is useful even if the positions of celestial bodies don't actually matter.
Useful in what sense then? The placebo effect?
I use it as a psychological projection tool. I use divinatory tools like astrology, tarot, or the I Ching to examine how I'm perceiving and processing my circumstances. Seeing what fits, what doesn't, what I want to fit, and what I want not to fit. imo, folks that say it "isn't real" are missing the point.
Haskell: recommended by the insight of human astrologers.
There’s a poetry in the merging of two new-age religions stemming from different communities. Unfortunately I’m an atheist, and so are most of us here I’d imagine.
There’s a poetry in the merging of two new-age religions stemming from different communities. Unfortunately I’m an atheist, and so are most of us here I’d imagine.
I see a lot of python and js/node as basis of comparison against Haskell which seems really odd.
I would be comparing Haskell more to Scala/Elixir/etc if you're trying to make an argument for Haskell.
I would be comparing Haskell more to Scala/Elixir/etc if you're trying to make an argument for Haskell.
The biggest advantage of running a Haskell shop is probably that it imposes a strong intelligence filter on the devs you hire.
yikes
> Powered by AI that merges NASA data with the insight of human astrologers
I honestly can't tell if this is parody.
I honestly can't tell if this is parody.
Sh*t... the horoscope I've been using all these years doesn't have functional correctness. So THAT's why I've made all the wrong decisions in my career and love life.
Very interesting and well thought out write up on a high level. Shame on me for being surprised at the technical clarity of an astrology app I suppose. On a lower level, I’m interested in how they balance the purity of Haskell with the necessity of a server actually persisting state and dealing with IO.
Doing IO stuff is very well-supported in Haskell. Printing to the terminal just looks like:
main = putStrLn "Hello World"Doesn’t this “contaminate” the entire calling function though, as in you now have to specify it is impure?
Yes, impurity (or rather the representation thereof) is contagious. This is where the common "functional core, imperative shell" comes into play. You generally try to push side effects to the edge.
There are other approaches you can take too, like encoding your effects in a monad which has a different runtime representation in tests. It's like mocking on steroids with type safety.
There are other approaches you can take too, like encoding your effects in a monad which has a different runtime representation in tests. It's like mocking on steroids with type safety.
Yes, a significant chunk of Haskell code usually does end up living in whatever monad (the context that represents IO computations) the app is using.
This doesn't negate the advantages of tracking effectful code in the type system, and there's still plenty of code that can be pure.
This doesn't negate the advantages of tracking effectful code in the type system, and there's still plenty of code that can be pure.
No contamination, main has a type ‘IO ()’. A readline function would be ‘IO String’, so in a way you can think of them as “upon execution, we have this type”, or the “execution wraps this type”. You can’t touch the inner type of such function naively, so this purity is viral.
This might surprise you, but Haskell can do IO. It even has a name. It's called "IO". Shocking, I know. (IO happens to be a monad, which I'm sure someone will point out soon, but that's not important right now.)
I see astrology as basically "folk data science". You make observations and try to find correlations (not causation, though some ancient literature does attempt to explain it). One simple one is Mercury goes into retrograde motion and takes down Meta with it.
You can model intrapersonal dynamics (basically found by looking at findings between positions of transiting bodies and those of the natal chart, namely the positions calculated at the time/place of the individual's birth). For example the current position of Jupiter (which symbolizes growth/expansion) is now conjunct an individual's natal midheaven (represents career/how you are seen in society) and all of a sudden this person is being recognized in a very positive way by their community or workplace.
You can also model the interpersonal dynamics, found by looking at the effects of just the transiting planets alone, say transiting Mars conjuncts the North Lunar Node or Pluto and all of a sudden you have these really violent transformational events that erupt. Maybe mass shootings, natural disasters etc.
The other interesting thing about astrology is it stands to unify many disparate concepts together. For example Jupiter is at the same time connected to the liver, to growth, to happiness, to biology, etc. if I recall correctly. Where else could you find this idea of unifying together seemingly unrelated things into the notion of a planetary symbol.
One thing I find sorely lacking is the complete lack of any statistical rigor applied to the predictions/indications given by astrological readings.
I do find it fascinating that co-star is throwing technology and data science to the problem. It may not be far off to see them publishing findings that actually meet the level of rigor to at least show statistically significant correlations. I don't practice or believe these things personally, but my ancestors used to try to help their communities understand their problems better using tools like ancient Indian astrology.
You can model intrapersonal dynamics (basically found by looking at findings between positions of transiting bodies and those of the natal chart, namely the positions calculated at the time/place of the individual's birth). For example the current position of Jupiter (which symbolizes growth/expansion) is now conjunct an individual's natal midheaven (represents career/how you are seen in society) and all of a sudden this person is being recognized in a very positive way by their community or workplace.
You can also model the interpersonal dynamics, found by looking at the effects of just the transiting planets alone, say transiting Mars conjuncts the North Lunar Node or Pluto and all of a sudden you have these really violent transformational events that erupt. Maybe mass shootings, natural disasters etc.
The other interesting thing about astrology is it stands to unify many disparate concepts together. For example Jupiter is at the same time connected to the liver, to growth, to happiness, to biology, etc. if I recall correctly. Where else could you find this idea of unifying together seemingly unrelated things into the notion of a planetary symbol.
One thing I find sorely lacking is the complete lack of any statistical rigor applied to the predictions/indications given by astrological readings.
I do find it fascinating that co-star is throwing technology and data science to the problem. It may not be far off to see them publishing findings that actually meet the level of rigor to at least show statistically significant correlations. I don't practice or believe these things personally, but my ancestors used to try to help their communities understand their problems better using tools like ancient Indian astrology.
Personally, I think astrology today is just an easy way to make money off of folks who don’t know any better.
While it would surely be one of the most incredible scientific discoveries in human history to prove that the normal motion of objects in the solar system can somehow affect people’s lives through some unknown force, it is incredibly unlikely.
To claim otherwise and sell some kind of product or predictions based on astrology is dishonest.
While it would surely be one of the most incredible scientific discoveries in human history to prove that the normal motion of objects in the solar system can somehow affect people’s lives through some unknown force, it is incredibly unlikely.
To claim otherwise and sell some kind of product or predictions based on astrology is dishonest.
On average literacy as to what astrology is in fact growing not shrinking. This is in particular due to social media and YouTubers who get into the nitty gritty details of birth time based astrology.
You don’t need to prove the causative relationship in many cases. Look at modern ML where “why does this model predict the outcome so well” is generally an open research question.
You don’t need to prove the causative relationship in many cases. Look at modern ML where “why does this model predict the outcome so well” is generally an open research question.
Astrology proponents on social media and YouTube are also taking advantage of people who don’t know better. You are not going to learn that astrology is baseless from its proponents, especially not from proponents who make money off of astrology content.
Even if we don’t know exactly why an ML model works well for a specific problem, we at least can verify that it does in fact work. And we do at least understand the mathematical principles behind the model.
But we have no credible evidence for astrology, even after thousands of years of claims and predictions. And there is no theory for how it could work other than basically magic. Again, it would be incredible to find such evidence, but I don’t think that will ever happen.
Even if we don’t know exactly why an ML model works well for a specific problem, we at least can verify that it does in fact work. And we do at least understand the mathematical principles behind the model.
But we have no credible evidence for astrology, even after thousands of years of claims and predictions. And there is no theory for how it could work other than basically magic. Again, it would be incredible to find such evidence, but I don’t think that will ever happen.
You don't need to prove statistical properties in deep learning models, but if that was something important, that's something you'd be able to do for any classifier that has positive predictive ability.
If a classifier is good, then there is an underlying association in the data. With astrology, there's no association in the data, unless you do something weird like constrain the size of your sample, systematically exclude people, or are measuring a different effect.
It's really totally absurd to use the methods of science on astrology. Just think about it, you have some data, and there's an effect you'd like to figure out. For whatever is going on in your sample, your explanation is "because the position of X on the day you were born?". It's a huge violation of occam's razor, and skips every plausible explanation for the most impossible.
No one that seriously does "data science" could approach a question, and come up with astrological answers, unless it was purely an exercise in B.S., with the express goal of creating content for people interested in astrology to consume. "Data scientists" spend years honing and refining their skills asking and answering questions, it's just incongruent with that set of skills and methodology.
If a classifier is good, then there is an underlying association in the data. With astrology, there's no association in the data, unless you do something weird like constrain the size of your sample, systematically exclude people, or are measuring a different effect.
It's really totally absurd to use the methods of science on astrology. Just think about it, you have some data, and there's an effect you'd like to figure out. For whatever is going on in your sample, your explanation is "because the position of X on the day you were born?". It's a huge violation of occam's razor, and skips every plausible explanation for the most impossible.
No one that seriously does "data science" could approach a question, and come up with astrological answers, unless it was purely an exercise in B.S., with the express goal of creating content for people interested in astrology to consume. "Data scientists" spend years honing and refining their skills asking and answering questions, it's just incongruent with that set of skills and methodology.
Science is inconsistent with astrology: the former is the systematic study of phenomena using reproducible and logical methods, and the later is basically sophistry with no practical value (or hypothetical mechanism) sold to people who either don't know better, or simply choose to believe.
I am interested in functional programming. Without a CS background I was wondering, if Haskell can provide these guarantees, why is it not more adopted?
If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?
If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?
> why is it not more adopted?
"We use Java here. We have always used Java here and we will always use Java here. We're a Java shop. No other languages exist." My personal experience with companies.
> If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?
Yes, but then you wouldn't be using Java.
"We use Java here. We have always used Java here and we will always use Java here. We're a Java shop. No other languages exist." My personal experience with companies.
> If, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?
Yes, but then you wouldn't be using Java.
I don't find this particular argument compelling, because there are other languages (e.g. Python and Golang) that have managed to make their way into the mainstream despite facing the same "we only use Java" challenge that hurts Haskell's adoption.
Yes, Go, the Google language. Very surprising that it became mainstream.
In the case of Python: it's imperative and somewhat object oriented and mostly without advanced features which makes it attractive for university courses, for example. Also sometimes languages just become popular, perhaps due to a certain library or sheer luck. That doesn't make it false for languages like Haskell.
In the case of Python: it's imperative and somewhat object oriented and mostly without advanced features which makes it attractive for university courses, for example. Also sometimes languages just become popular, perhaps due to a certain library or sheer luck. That doesn't make it false for languages like Haskell.
> Yes, Go, the Google language. Very surprising that it became mainstream.
It sure is. Dart, also a Google language, did not fare quite as well.
It sure is. Dart, also a Google language, did not fare quite as well.
Yeah... the Java monoglots.
Because the guarantees are largely exaggerated, require you to use specific language extensions (that you have to find out about somehow), and are often presented in a largely esoteric manner.
Yes, you can write some advanced type-fu to provide interesting guarantees on the type level. But by the time you've learned how to do that, your colleagues will have delivered multiple projects in most other languages with test suites that provide similar guarantees.
Yes, you can write some advanced type-fu to provide interesting guarantees on the type level. But by the time you've learned how to do that, your colleagues will have delivered multiple projects in most other languages with test suites that provide similar guarantees.
Mostly because it takes a lot of patience and dedication to get to a productive level. It's a bit like vim - steep learning curve, but fantastic to use once you know what you're doing.
It is hard to hire developers with Haskell XP since not a lot of companies use it. And not a lot of companies use it because it's hard to hire for.
This vicious cycle exists for a lot of very good languages.
This vicious cycle exists for a lot of very good languages.
I think the solution is to stop looking for people with explicit experience in Haskell (or any lang), and to simply take on friendly and open-minded individuals to be trained internally. Even cleverness doesn't have to be a criterion; if you're doing FP right, you shouldn't need to be too smart. I'm certainly not.
I was fortunate enough to be hired in this manner, and I'm always more than happy to help train up new members in a similar fashion. It pays off in the long run—and the short run too, since it doesn't take that long to get somebody playing with Maybes and Eithers in some internal module.
I was fortunate enough to be hired in this manner, and I'm always more than happy to help train up new members in a similar fashion. It pays off in the long run—and the short run too, since it doesn't take that long to get somebody playing with Maybes and Eithers in some internal module.
> simply take on friendly and open-minded individuals to be trained internally.
"simply".
So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?
"simply".
So, you have to hire senior Haskell devs and then switch them to teaching new hires. See how this isn't feasible for most companies?
Production and training aren't a binary. It's realistic enough to have a couple of senior devs write the scaffolding that segregates the nasty details, then have junior devs pair with them on the more logically pure modules. As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all. I've been on both sides of the equation and it works quite well in the long run.
Playing devils advocate: sounds pretty complicated. We'll just use Javascript and have access to an ever growing pool of cheap devs.
Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.
Not saying your approach isn't reasonable, but c suite execs are not always reasonable, and it may be hard to justify this whole setup just to use language X.
It's not just "c-suite execs".
If our department has 60 devs across 5-10 teams, the cost of "simply" bringing in people who don't know the language and expecting to both onboard them to business and teach them a new language becomes astronomical
If our department has 60 devs across 5-10 teams, the cost of "simply" bringing in people who don't know the language and expecting to both onboard them to business and teach them a new language becomes astronomical
I guess I'm not just speaking in favor of language x, but a broader culture of knowledge sharing, pairing, and educational development that naturally supports languages like x. I realize this is anathema to slavedrivers, but it can and does work.
> As long as you don't work for sweatshop that expects delivery on day one, it's no biggie at all.
What about "a big company with multiple dev teams that are expected to actually deliver things on time"?
What about "a big company with multiple dev teams that are expected to actually deliver things on time"?
I work for a large firm (hundreds of engineering staff) that invested in strongly-typed FP. We deliver things on time because we're not putting out fires caused by stupid runtime errors. There's more than enough time to teach the juniors along the way too. Once again, education is a ultimately a facet of productivity, not something that detracts from it.
Which languages are you using if I may ask?
I was looking at Haskell and Elm and some repositories show little activity.
Was the ecosystem a problem for you?
Haskell, Scala, Typescript, and Purescript. Ecosystem is better with Scala, but hasn't been too much of a problem in any of them, perhaps because we try to avoid too many dependencies.
If Betamax is so much better than VHS, why is VHS a market success and Betamax a failure?
The writeup appears to be about as well-founded as the domain.
"Increased abstraction means that you can write things much quicker and more simply than in another language."
Except for any other kind of higher level language.
> [Haskell is much more bullet-proof than] IF NATALPLANET == “MARS”
As is any other non-stringly-typed language, so everything other than Tcl. And even Tcl is misunderstood, it's actually pretty awesome for its intended purpose. And of course you can write stringly typed code in Haskell just as much as you can in any other language.
and so on.
"Increased abstraction means that you can write things much quicker and more simply than in another language."
Except for any other kind of higher level language.
> [Haskell is much more bullet-proof than] IF NATALPLANET == “MARS”
As is any other non-stringly-typed language, so everything other than Tcl. And even Tcl is misunderstood, it's actually pretty awesome for its intended purpose. And of course you can write stringly typed code in Haskell just as much as you can in any other language.
and so on.
From that same paragraph:
> That said, there are ways of dealing with this in languages like Python, they're just a little more verbose and you don't get the compiler checking that you've exhaustively handled all cases, for example. It won’t compile, it won’t accept that idea.
> That said, there are ways of dealing with this in languages like Python, they're just a little more verbose and you don't get the compiler checking that you've exhaustively handled all cases, for example. It won’t compile, it won’t accept that idea.
> [Haskell is much more bullet-proof than] IF NATALPLANET == “MARS”
And perhaps there might be something like a Python Enum HOWTO
https://docs.python.org/3.11/howto/enum.html
And perhaps there might be something like a Python Enum HOWTO
https://docs.python.org/3.11/howto/enum.html
Comparing to Python and Javascript, referencing an unused name in source without reaching it in your execution path will not cause an error.
a=4
3+a
3+a or 3+b
This isn't due to static typing (you appear to be mixing up strong vs. static typing).
This will also not compile in Smalltalk.
Nothing to do with static typing at all.
This will also not compile in Smalltalk.
Nothing to do with static typing at all.
I came across this interesting post touching on Haskell just recently:
https://www.drmaciver.com/2015/04/on-haskell-ruby-and-cards-...
https://www.drmaciver.com/2015/04/on-haskell-ruby-and-cards-...
[deleted]
Forgive me if I don’t want to read anything written by someone making an astrology product. I may be open-minded, but I have limits where it comes to people who I know are trying to influence me into believing stupid false things to their benefit.
I mean, if they’re fine with claiming that astrology is real to enrich themselves, why should I believe anything else they say?
I mean, if they’re fine with claiming that astrology is real to enrich themselves, why should I believe anything else they say?
Please don't take HN threads on generic flamewar tangents. They're tedious, predictable, and usually turn nasty.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I hardly think criticizing astrology is a generic tangent for an astrology company as per the rules.
It definitely is. It's a cliché, threadbare topic about which people adamantly repeat platitudes they settled on long ago.
If there were an article about Rust posted to HN from, say, the Church of Scientology, would criticism of CoS be disallowed? Some things should be called out when you see them.
You need to understand what we're going for on this site: curious conversation. Curiosity withers under repetition and burns under indignation. Therefore, topics that combine a lot of repetition with a lot of indignation are not what we're looking for.
They also have a habit of taking over an entire thread very quickly, much as fire consumes and spreads quickly through what it touches (which is why 'flame' is a good metaphor for the corresponding kind of internet comment).
There are a lot of past explanations of these principles in case any of it is helpful:
repetition is bad for curiosity https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
good discussion is specific, not generic https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
reflective responses are better than reflexive ones https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
trying to avoid the internet callout/shaming culture https://hn.algolia.com/?sort=byDate&type=comment&dateRange=a...
(and so on)
They also have a habit of taking over an entire thread very quickly, much as fire consumes and spreads quickly through what it touches (which is why 'flame' is a good metaphor for the corresponding kind of internet comment).
There are a lot of past explanations of these principles in case any of it is helpful:
repetition is bad for curiosity https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
good discussion is specific, not generic https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
reflective responses are better than reflexive ones https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
trying to avoid the internet callout/shaming culture https://hn.algolia.com/?sort=byDate&type=comment&dateRange=a...
(and so on)
I see. You could say that criticism is a dish best served cold.
Forgive me if I don’t want to read anything written by someone making an astrology product.
Typical Capricorn.
Typical Capricorn.
I know one of the founders, and she has a deep background in philosophy and psychoanalytic theory, as I do as well. Astrology as a contemplative and epistemological practice has deep roots; the idea that astrology is "real" in a physical causal sense goes back to Ptolemy and only persists because of the historical influence of the Christian church. I've written a bit on the topic here: https://listed.to/@simpolism/27322/what-is-astrology
As an engineer who's also studied a bit of astrology and has played around with how one might produce a description language to support the astrological symbolic apparatus, I think a functional language is a great choice. The idea of strict types defined as a set of symbols makes perfect sense in astrological terms. Although I'm much more familiar with OCaml/SML than Haskell, a basic outline would be something like:
type Planet = Sun | Moon | Mercury | ...
type Sign = Aries | Taurus | ... | Pisces
type House = 1 | 2 | ... | 12
Using this, you could represent a whole chart in a pretty straightforward way. And then you could have higher order constructs, which represent meaningful formal relationships, like:
type Aspect = (Planet, Planet, Degree)
type Rulership = (Planet, Sign)
etc. It's a pretty natural idea, to use a strong type system to represent what is effectively a formal language (astrology).
As an engineer who's also studied a bit of astrology and has played around with how one might produce a description language to support the astrological symbolic apparatus, I think a functional language is a great choice. The idea of strict types defined as a set of symbols makes perfect sense in astrological terms. Although I'm much more familiar with OCaml/SML than Haskell, a basic outline would be something like:
type Planet = Sun | Moon | Mercury | ...
type Sign = Aries | Taurus | ... | Pisces
type House = 1 | 2 | ... | 12
Using this, you could represent a whole chart in a pretty straightforward way. And then you could have higher order constructs, which represent meaningful formal relationships, like:
type Aspect = (Planet, Planet, Degree)
type Rulership = (Planet, Sign)
etc. It's a pretty natural idea, to use a strong type system to represent what is effectively a formal language (astrology).
> Astrology as a contemplative and epistemological practice has deep roots
I've never understood this as an argument for veracity. There are lots of ideas and practices with "deep roots". Blood letting has "deep roots", yet we've pretty thoroughly debunked humor balancing and good medicine.
Astrology, like other psuedosciences, seems built on the notion that if you add enough lingo it becomes valid. Yet a quick skeptical consideration of "Ok, what does the position of a rock in the sky have to do with my day to day life" seems like it should readily debunk it. Why does the position of Jupiter, for example, have more effect on my life than say the position of the moon? Or 624 Hector? If I throw a rock over someone's head does that have an appreciable effect on their "luck" or how their day will go? Does the composition of said rock impact a person's luck?
I've never understood this as an argument for veracity. There are lots of ideas and practices with "deep roots". Blood letting has "deep roots", yet we've pretty thoroughly debunked humor balancing and good medicine.
Astrology, like other psuedosciences, seems built on the notion that if you add enough lingo it becomes valid. Yet a quick skeptical consideration of "Ok, what does the position of a rock in the sky have to do with my day to day life" seems like it should readily debunk it. Why does the position of Jupiter, for example, have more effect on my life than say the position of the moon? Or 624 Hector? If I throw a rock over someone's head does that have an appreciable effect on their "luck" or how their day will go? Does the composition of said rock impact a person's luck?
> Why does the position of Jupiter, for example, have more effect on my life than say the position of the moon?
It doesn't particularly matter. You can use a randomly generated chart and it will still "work", because the use of astronomy in astrology is basically as RNG, and astrology itself is a psychological language.
> Blood letting has "deep roots", yet we've pretty thoroughly debunked humor balancing and good medicine.
Do you really think modern medical psychology has moved past the "blood letting" phase of knowledge? If so, then why are so many people still depressed, anxious, etc, despite all the supposed advances?
The fact is that psychology has a long way to go before it can be treated as a proper physical science, requiring researchers to bridge vast gaps in neuroscience and the structure of experience, which includes the huge and significant role of symbols in life.
As it stands, the person with the most knowledge of your own life is... you, and tools like astrology function as mirrors to help you avoid your own biases when developing self-knowledge. This is entirely unlike any medical intervention I'm aware of, and cannot be compared in kind.
It doesn't particularly matter. You can use a randomly generated chart and it will still "work", because the use of astronomy in astrology is basically as RNG, and astrology itself is a psychological language.
> Blood letting has "deep roots", yet we've pretty thoroughly debunked humor balancing and good medicine.
Do you really think modern medical psychology has moved past the "blood letting" phase of knowledge? If so, then why are so many people still depressed, anxious, etc, despite all the supposed advances?
The fact is that psychology has a long way to go before it can be treated as a proper physical science, requiring researchers to bridge vast gaps in neuroscience and the structure of experience, which includes the huge and significant role of symbols in life.
As it stands, the person with the most knowledge of your own life is... you, and tools like astrology function as mirrors to help you avoid your own biases when developing self-knowledge. This is entirely unlike any medical intervention I'm aware of, and cannot be compared in kind.
> Do you really think modern medical psychology has moved past the "blood letting" phase of knowledge? If so, then why are so many people still depressed, anxious, etc, despite all the supposed advances?
A common misunderstanding of psychology is that it's about "curing" psychological illnesses. Almost all psychological illnesses are chronic and not diseases that can be cured. As such, the work of a psychologist is almost always around managing, not curing.
You wouldn't, for example, look at the physical therapy an amputee receives and go "Physical therapy must be no better than blood letting because amputees still exist!"
> The fact is that psychology has a long way to go before it can be treated as a proper physical science, requiring researchers to bridge vast gaps in neuroscience and the structure of experience, which includes the huge and significant role of symbols in life.
That's happened perhaps more than I think you'd expect. This is where, for example, SSRIs have come from. It's not random shots in the dark and guesses. The unfortunate problem is there's a bunch of stigma around taking medicine for psychological problems.
A common misunderstanding of psychology is that it's about "curing" psychological illnesses. Almost all psychological illnesses are chronic and not diseases that can be cured. As such, the work of a psychologist is almost always around managing, not curing.
You wouldn't, for example, look at the physical therapy an amputee receives and go "Physical therapy must be no better than blood letting because amputees still exist!"
> The fact is that psychology has a long way to go before it can be treated as a proper physical science, requiring researchers to bridge vast gaps in neuroscience and the structure of experience, which includes the huge and significant role of symbols in life.
That's happened perhaps more than I think you'd expect. This is where, for example, SSRIs have come from. It's not random shots in the dark and guesses. The unfortunate problem is there's a bunch of stigma around taking medicine for psychological problems.
> You wouldn't, for example, look at the physical therapy an amputee receives and go "Physical therapy must be no better than blood letting because amputees still exist!"
And yet, we know the precise cause and details of their situation...
> This is where, for example, SSRIs have come from. It's not random shots in the dark and guesses.
SSRIs were designed with a specific neurotransmitter in mind, but the reason why serotonin can affect what we call "depression" is, as wikipedia puts it, "somewhat uncertain". Only in the last couple of years have theoretical frameworks appeared where we can kind of develop a causal understanding, like in Friston's REBUS paper: https://pharmrev.aspetjournals.org/content/71/3/316
The gist is that, if serotonin modulates high level neurological priors, then SSRIs lead to slightly increased plasticity wrt the environment, which can help people get "unstuck" from previous environmental priors i.e. trauma. But if their current environment is poor, then SSRIs will have no effect or make them worse. If this model is correct, then it necessitates a shift in the etiology of depression, back to the more classical psychoanalytic "epistemic" view (in which "mental illness" is equivalent to unwanted patterns of thought and action, a definition that should feel obvious to anyone who's dealt with their own psychic distress) vs the modern "neurotransmitter" view (i.e. "not enough serotonin = depressed").
The result is that any etiological understanding must include not only the present state of the individual seeking treatment, but also their environmental and historical contexts, i.e. their whole life. This problematizes the metaphor of mental illness, because, as you said, most people think you can treat mental illness like curing an infection, removing some sort of foreign element which resulted in whatever deviation from the "healthy" norm, without realizing it has to be a longer term intervention, because the foreign element is... still you.
Like physical therapy, there's plenty of stretches you can do on your own, and you're also in a unique strong position to evaluate your own environmental and historical context, compared with a therapist who can only know what you tell them (or what they can read between the lines). This is why reflective practices exist, like many religious exercises which give you a new pattern to consider (like on Yom Kippur, you think about your last year in terms of repentance, forgiveness, etc), but also like astrology, which "automatically" produces frames for contemplative reflection. The result of proper reflection is in action, which shifts the agent away from their old repetitive patterns and can actually provide the mythical-seeming cure for their mental illnesses. This form of "treatment" has been rediscovered in many traditions over the years, from Buddhism to Stoicism. It seems to only be in modern western culture where we delegate to experts the responsibility for our own psyches...
And yet, we know the precise cause and details of their situation...
> This is where, for example, SSRIs have come from. It's not random shots in the dark and guesses.
SSRIs were designed with a specific neurotransmitter in mind, but the reason why serotonin can affect what we call "depression" is, as wikipedia puts it, "somewhat uncertain". Only in the last couple of years have theoretical frameworks appeared where we can kind of develop a causal understanding, like in Friston's REBUS paper: https://pharmrev.aspetjournals.org/content/71/3/316
The gist is that, if serotonin modulates high level neurological priors, then SSRIs lead to slightly increased plasticity wrt the environment, which can help people get "unstuck" from previous environmental priors i.e. trauma. But if their current environment is poor, then SSRIs will have no effect or make them worse. If this model is correct, then it necessitates a shift in the etiology of depression, back to the more classical psychoanalytic "epistemic" view (in which "mental illness" is equivalent to unwanted patterns of thought and action, a definition that should feel obvious to anyone who's dealt with their own psychic distress) vs the modern "neurotransmitter" view (i.e. "not enough serotonin = depressed").
The result is that any etiological understanding must include not only the present state of the individual seeking treatment, but also their environmental and historical contexts, i.e. their whole life. This problematizes the metaphor of mental illness, because, as you said, most people think you can treat mental illness like curing an infection, removing some sort of foreign element which resulted in whatever deviation from the "healthy" norm, without realizing it has to be a longer term intervention, because the foreign element is... still you.
Like physical therapy, there's plenty of stretches you can do on your own, and you're also in a unique strong position to evaluate your own environmental and historical context, compared with a therapist who can only know what you tell them (or what they can read between the lines). This is why reflective practices exist, like many religious exercises which give you a new pattern to consider (like on Yom Kippur, you think about your last year in terms of repentance, forgiveness, etc), but also like astrology, which "automatically" produces frames for contemplative reflection. The result of proper reflection is in action, which shifts the agent away from their old repetitive patterns and can actually provide the mythical-seeming cure for their mental illnesses. This form of "treatment" has been rediscovered in many traditions over the years, from Buddhism to Stoicism. It seems to only be in modern western culture where we delegate to experts the responsibility for our own psyches...
> I know one of the founders, and she has a deep background in philosophy and psychoanalytic theory, as I do as well. Astrology as a contemplative and epistemological practice has deep roots; the idea that astrology is "real" in a physical causal sense goes back to Ptolemy and only persists because of the historical influence of the Christian church. I've written a bit on the topic here: https://listed.to/@simpolism/27322/what-is-astrology
Sorry, how does this justify lying and deceiving people for profit?
> she has a deep background in philosophy and psychoanalytic theory,
By "deep background" you mean she got a BA in psychology?
Sorry, how does this justify lying and deceiving people for profit?
> she has a deep background in philosophy and psychoanalytic theory,
By "deep background" you mean she got a BA in psychology?
> lying and deceiving people for profit?
Who here exactly is being lied to? Some people feel that doctors lie to them, so they don't go to doctors. Similarly, if someone feels like astrology is all a big lie, they don't have to use the app.
> By "deep background" you mean she got a BA in psychology?
I mean she's done quite a lot of reading on enlightenment and modern philosophy, can hold a conversation on Kant, Hegel, etc. as well as Freud, Lacan, RD Laing, and others. Humanities degrees tell me very little about the quality of someone's understanding.
Who here exactly is being lied to? Some people feel that doctors lie to them, so they don't go to doctors. Similarly, if someone feels like astrology is all a big lie, they don't have to use the app.
> By "deep background" you mean she got a BA in psychology?
I mean she's done quite a lot of reading on enlightenment and modern philosophy, can hold a conversation on Kant, Hegel, etc. as well as Freud, Lacan, RD Laing, and others. Humanities degrees tell me very little about the quality of someone's understanding.
You may disagree, but I read this comment as a gendered microaggression and I hope you will reconsider your stance to be inclusive of this sort of content on HN going forward.
I see astrology as an entertainment product. Some folks take it way too far, and it's fine if you'd prefer to abstain. But I think that it is the same as with other vices (porn, casinos, gatcha games, etc) who, otherwise, can have very interesting technical problems.
I see astrology as an entertainment product. Some folks take it way too far, and it's fine if you'd prefer to abstain. But I think that it is the same as with other vices (porn, casinos, gatcha games, etc) who, otherwise, can have very interesting technical problems.
You don’t know my gender, and the article has no author name attached.
> I have limits where it comes to people who I know are trying to influence me into believing stupid false things to their benefit.
The market for astrology already exists. Their whole thing is getting people who are into it to prefer them because their math is better.
I get the anti-pseudoscience reflex, but (1) it's the wrong way to think about astrology and (2) it's weird to pick on astrology apps for their 'ethics' when the practice is more or less benign. We're not talking about a cult where people refuse medicine for their children here.
From an employment perspective, Co-Star seems way cleaner than places where lots of people I know and like work. Better horoscopes than missile defense or spy drones or brutal retailers like Amazon. Better a stupid, fake typology than spyware that reads people's emails to hit them with more effective ads. Better to produce models of the positions of stars than models of human faces to power militarization of the Israeli border.
Re: (1)
Astrology as most people practice it is a low-stakes system of prompts for reflecting on oneself and one's environment in a way that is useful and healthy, but can easily be neglected when you're just trying to get from one day to the next. Taking it too seriously is a mistake, but it can be useful without being correct about the capacity of the power of heavenly bodies to determine human personalities or affairs.
If we had nobles using court astrologers again, I'd say attacking astrology as harmful would be valuable. But when it's more about prompting for reflection or producing a shared vocabulary of personality, I think it ranges from helpful ritual to benign nonsense.
The market for astrology already exists. Their whole thing is getting people who are into it to prefer them because their math is better.
I get the anti-pseudoscience reflex, but (1) it's the wrong way to think about astrology and (2) it's weird to pick on astrology apps for their 'ethics' when the practice is more or less benign. We're not talking about a cult where people refuse medicine for their children here.
From an employment perspective, Co-Star seems way cleaner than places where lots of people I know and like work. Better horoscopes than missile defense or spy drones or brutal retailers like Amazon. Better a stupid, fake typology than spyware that reads people's emails to hit them with more effective ads. Better to produce models of the positions of stars than models of human faces to power militarization of the Israeli border.
Re: (1)
Astrology as most people practice it is a low-stakes system of prompts for reflecting on oneself and one's environment in a way that is useful and healthy, but can easily be neglected when you're just trying to get from one day to the next. Taking it too seriously is a mistake, but it can be useful without being correct about the capacity of the power of heavenly bodies to determine human personalities or affairs.
If we had nobles using court astrologers again, I'd say attacking astrology as harmful would be valuable. But when it's more about prompting for reflection or producing a shared vocabulary of personality, I think it ranges from helpful ritual to benign nonsense.
Well... they're not really "making" an astrology product. They're an engineer "making" an application backend. It's almost kind of irrelevant what it's being used for in this context (a relatively technical discussion on the merits of a language).
Sure, they might be honest about this – who knows? But anyone known to be peddling snake oil doesn’t get the benefit of the doubt. If they’re telling the truth, there will be others, more trustworthy, who can make the same argument.
How is this not flagged?
> I don’t want to read anything written by someone making an insert religious/philosophical belief here product.
I'm not sure the what's being built takes a way from the correctness of the way something was built.
> I don’t want to read anything written by someone making an insert religious/philosophical belief here product.
I'm not sure the what's being built takes a way from the correctness of the way something was built.
Why should it be flagged? Seems like a perfectly reasonable comment, just like how in day to day life I think less of people when I learn that they are religious.
I'm an atheist, I say this because its against the hacker newsguidelines
> Please don't use Hacker News for political or ideological battle. It tramples curiosity.
https://news.ycombinator.com/newsguidelines.html
> Please don't use Hacker News for political or ideological battle. It tramples curiosity.
https://news.ycombinator.com/newsguidelines.html
> Forgive me if I don’t want to read anything written by someone making an astrology product. I may be open-minded
No. You are closed-minded. The article explained three reasons why Haskell was chosen, not about converting you to believe in Astrology.
"Haskell is optimized for developer efficiency. You can get a lot done, have a high degree of confidence that it runs reasonably without having to do too much thinking or ass-covering. We move fast & need things to be reliable. Rather than hand optimizing Doom 2 for ___, Haskell is the opposite. The computers serve us. Code is for humans to read, and only incidentally for computers to read. Code is how humans express themselves to each other and computers, and it’s up to computers to run it in a reasonably good way."
No. You are closed-minded. The article explained three reasons why Haskell was chosen, not about converting you to believe in Astrology.
FUNCTIONS IN THE MATHEMATICAL SENSE
TYPE-DRIVEN PROGRAMMING
HASKELL MAKES ILLEGAL STATES UNREPRESENTABLE
"Haskell is optimized for developer efficiency. You can get a lot done, have a high degree of confidence that it runs reasonably without having to do too much thinking or ass-covering. We move fast & need things to be reliable. Rather than hand optimizing Doom 2 for ___, Haskell is the opposite. The computers serve us. Code is for humans to read, and only incidentally for computers to read. Code is how humans express themselves to each other and computers, and it’s up to computers to run it in a reasonably good way."
I have enough to read already. I choose not to spend my time reading texts by known con artists, whatever the texts may contain. If the truths expressed therein are valuable, someone else with more authority can repeat or re-discover them elsewhere.
> I choose not to spend my time reading texts by known con artists
And yet you have the time to impugn other people's character here? I propose to you that your time might be better spent on your reading backlog.
And yet you have the time to impugn other people's character here? I propose to you that your time might be better spent on your reading backlog.
> I may be open-minded
You're not. If you were you will understand that astrology and other esoteric beliefs are culturally anchored to the human experience of many people in the world. In particular the self-development that many people seem to get from astrology. I don't need to believe in astrology to understand its cultural role.
I think it's completely fair to build a business around a cultural idea and use that idea as a thematic glue to teach people about self-development and self-care. If you donwload the app, you will quicky realize that's exactly what they are doing. Personally not my thing, but I respect what they do and their approach to building a business around this.
You're not. If you were you will understand that astrology and other esoteric beliefs are culturally anchored to the human experience of many people in the world. In particular the self-development that many people seem to get from astrology. I don't need to believe in astrology to understand its cultural role.
I think it's completely fair to build a business around a cultural idea and use that idea as a thematic glue to teach people about self-development and self-care. If you donwload the app, you will quicky realize that's exactly what they are doing. Personally not my thing, but I respect what they do and their approach to building a business around this.
Off topic!
I'm really curious about how hners think/feel about astrology. Do you "believe" in it or does it help in any meaningful way?
I grew up thinking these kind of things are for the "uneducated" but I'm surprised by how many smart people I meet nowadays who really care about this stuff. So, I'm really curious!
I'm really curious about how hners think/feel about astrology. Do you "believe" in it or does it help in any meaningful way?
I grew up thinking these kind of things are for the "uneducated" but I'm surprised by how many smart people I meet nowadays who really care about this stuff. So, I'm really curious!
I think of astrology, like tarot, as a storytelling tool. For myself, an astrology or tarot reading gives a narrative which I can consider and possibly act upon. For flattering or welcome aspects of the reading, do I actually manifest the desirable characteristics? Could I be more like these aspects of the reading? For unflattering/unwelcome aspects, the opposite.
Of course, this works just as well with a randomly shuffled tarot deck, or with a random astrological reading (I don’t think that there is anything special about the astrological reading which corresponds to my date of birth).
I haven’t written fiction in a long time, but I also think it might be interesting to use such readings to develop fictional characters or plots.
Of course, this works just as well with a randomly shuffled tarot deck, or with a random astrological reading (I don’t think that there is anything special about the astrological reading which corresponds to my date of birth).
I haven’t written fiction in a long time, but I also think it might be interesting to use such readings to develop fictional characters or plots.
I place zero stock in it as far as decision making or understanding myself/others goes, but it also doesn't really make me angry in the way that it seems to for a lot of other people. I think it's often quite fun to compare astrology charts or ask someone their sign as an icebreaker when getting to know them, etc.
I think it can be really damaging and there's a substantial proportion of the population that actually believes it and spends a substantial amount of time obsessing over it.
I hear the couple next door to me in SF get in shouting matches through the wall about how she doesn't feel like he takes her seriously because he doesn't believe in astrology, about how there are some things that science doesn't understand, etc. etc. And she's like a PM at Stripe or something.
I hear the couple next door to me in SF get in shouting matches through the wall about how she doesn't feel like he takes her seriously because he doesn't believe in astrology, about how there are some things that science doesn't understand, etc. etc. And she's like a PM at Stripe or something.
> there's a substantial proportion of the population that actually believes it and spends a substantial amount of time obsessing over it.
Is this actually substantiated?
Is this actually substantiated?
I feel you, but at the end of the day I don't think astrology as a belief system is any wackier or more harmful than most mainstream religions. And my capacity for holding a grudge against people for having beliefs that lack an empirical basis is not very high.
> I don't think astrology as a belief system is any wackier [...] than most mainstream religions.
Statements like these are problematic. Not only are there meaningful differences between religions that make them incommensurate in this context (e.g., a Catholic, while acknowledging that some glimmers of greater or lesser truth exist in all religions, will regard much of them as erroneous and even superstitious), but it seems you haven't done the philosophical due diligence here to make a sensible comparison.
For example, we have no reason to suppose that the relative positions of the planets has any effect on how things pan out. And additionally, from a Catholic perspective, not only is astrology generally taken to be superstitious (on account of its irrationality), but the impulse behind astrology is also taken to be evil. From the Catechism of the Catholic Church:
"All forms of divination are to be rejected: recourse to Satan or demons, conjuring up the dead or other practices falsely supposed to 'unveil' the future. Consulting horoscopes, astrology, palm reading, interpretation of omens and lots, the phenomena of clairvoyance, and recourse to mediums all conceal a desire for power over time, history, and, in the last analysis, other human beings, as well as a wish to conciliate hidden powers. They contradict the honor, respect, and loving fear that we owe to God alone” (CCC 2116)[0].
(N.b. the catechism is not a defense of these beliefs. I cite it only to show the Catholic position. Defenses can be found elsewhere, as well as pedagogical treatments like those in the Summa[1].)
The positions of the Church are rigorously defended over at least two millennia, some before that where natural theology and philosophy are concerned (the existence of God, for example, is knowable through unaided reason; the divinity of Jesus, on the other hand, requires faith in the sense that while the totality of evidence may be very strong in favor of that belief, it is not fully deducible in the way philosophical arguments for the existence of God are). To compare astrology to that intellectual tradition (I ignore here the petty superstitions particular Catholics might entertain) is ludicrous.
And part of due diligence is also an understanding of what constitutes an "empirical basis" and where and how it is an appropriate to draw on empirical observation. For example, does the claim "a belief P is reasonable if and only if there is an empirical basis for it" itself have an "empirical basis"? If so, in what way?
[0] https://www.vatican.va/archive/ENG0015/__P7E.HTM
[1] https://www.newadvent.org/summa/3092.htm
Statements like these are problematic. Not only are there meaningful differences between religions that make them incommensurate in this context (e.g., a Catholic, while acknowledging that some glimmers of greater or lesser truth exist in all religions, will regard much of them as erroneous and even superstitious), but it seems you haven't done the philosophical due diligence here to make a sensible comparison.
For example, we have no reason to suppose that the relative positions of the planets has any effect on how things pan out. And additionally, from a Catholic perspective, not only is astrology generally taken to be superstitious (on account of its irrationality), but the impulse behind astrology is also taken to be evil. From the Catechism of the Catholic Church:
"All forms of divination are to be rejected: recourse to Satan or demons, conjuring up the dead or other practices falsely supposed to 'unveil' the future. Consulting horoscopes, astrology, palm reading, interpretation of omens and lots, the phenomena of clairvoyance, and recourse to mediums all conceal a desire for power over time, history, and, in the last analysis, other human beings, as well as a wish to conciliate hidden powers. They contradict the honor, respect, and loving fear that we owe to God alone” (CCC 2116)[0].
(N.b. the catechism is not a defense of these beliefs. I cite it only to show the Catholic position. Defenses can be found elsewhere, as well as pedagogical treatments like those in the Summa[1].)
The positions of the Church are rigorously defended over at least two millennia, some before that where natural theology and philosophy are concerned (the existence of God, for example, is knowable through unaided reason; the divinity of Jesus, on the other hand, requires faith in the sense that while the totality of evidence may be very strong in favor of that belief, it is not fully deducible in the way philosophical arguments for the existence of God are). To compare astrology to that intellectual tradition (I ignore here the petty superstitions particular Catholics might entertain) is ludicrous.
And part of due diligence is also an understanding of what constitutes an "empirical basis" and where and how it is an appropriate to draw on empirical observation. For example, does the claim "a belief P is reasonable if and only if there is an empirical basis for it" itself have an "empirical basis"? If so, in what way?
[0] https://www.vatican.va/archive/ENG0015/__P7E.HTM
[1] https://www.newadvent.org/summa/3092.htm
The point of my comment really wasn't to denigrate anyone's belief system or to prop up empirical basis as an absolute standard for establishing the veracity or value of a claim.
The parent commenter expressed concern that people holding these unsubstantiated belief systems as truth was inflicting real harm to society. My point was to say that if this is a real concern, why are we singling out astrology as a punching bag? Basically all major religions entail beliefs which are unsubstantiated by empirical evidence. Do we as individuals really have the capacity harbor ill will towards anyone who chooses to believe things outside what can be verified empirically? I don't!
Your belief system may be incompatible with Astrology, and it may possess a richer intellectual tradition than Astrology, but this alone is insufficient to convince me that the faith-based beliefs of one system are inherently superior or more true than the other.
The parent commenter expressed concern that people holding these unsubstantiated belief systems as truth was inflicting real harm to society. My point was to say that if this is a real concern, why are we singling out astrology as a punching bag? Basically all major religions entail beliefs which are unsubstantiated by empirical evidence. Do we as individuals really have the capacity harbor ill will towards anyone who chooses to believe things outside what can be verified empirically? I don't!
Your belief system may be incompatible with Astrology, and it may possess a richer intellectual tradition than Astrology, but this alone is insufficient to convince me that the faith-based beliefs of one system are inherently superior or more true than the other.
People get mad about astrology because it's a clear cut case of rational people abusing less rational people, like Q-anon.
Is it that clear-cut? My impression is not that astrology as a practice has a rigid hierarchical structure, nor that the people disseminating horoscopes and the like do not believe it themselves.
This is illegible with that background (in portrait mode on an ipad pro).
On desktop the background follows the mouse. I couldn't focus on anything else, I move my mouse around while I read.
If the author is reading these, please consider using a static background.
If the author is reading these, please consider using a static background.
I couldn't finish anything past the first paragraph because the background made me nauseous
Firefox reader view FTW...
I only see that weird background stuff if I have my global dark mode browser extensions on
when I turn that off, I can't see any background effects at all
when I turn that off, I can't see any background effects at all
same with chrome 95.0.4638.69. whatever they intended it to look like, they failed.
edit. Its a dark mode issue, styling not being applied to the background rendering
edit. Its a dark mode issue, styling not being applied to the background rendering
Lucky you.
>> Co–Star is built by a small team of thirty.
LOL thats giant. How much does it cost to run the show? 30 x $100,000 for an astrology app?
LOL thats giant. How much does it cost to run the show? 30 x $100,000 for an astrology app?
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html
I have strong feelings against astrology myself, yet I find it frustrating that is the HN takeaway here, and not the fact that there's a successful company making enough money to fund 30 people's salaries and is written in what a lot of us consider an interesting functional programming language.
That's doesn't seem to be an accurate description of this thread. Maybe look again?
A fairly low quality article, imho.
The points listed could almost as easily apply to Java or C#
The points listed could almost as easily apply to Java or C#
Is this the "you can write this in X by implementing a compiler for Y"-joke? Or genuine? If so, I find it unfair.
Even at the most fundamental level, the mishmash of statement/expression syntax in those languages makes it cumbersome at best to compose functions and expressions in the style of an FP language. And the more you venture into conceptual things like values and functions you're fighting those languages left and right to achieve the same _basic_ semantics.
I'm neither pro nor contra static typing in general and I don't really know Haskell, but I think it would be obvious that Java and C# don't have the same sophistication, inference and expressiveness on the type level as Haskell. When they say "make illegal states unrepresentable" they don't mean "write a bunch of defensive runtime checks".
Not to bash on Java/C#, they are powerful and very useful. But the type of specific benefits the article talks about are not a given or even practical in those.
Even at the most fundamental level, the mishmash of statement/expression syntax in those languages makes it cumbersome at best to compose functions and expressions in the style of an FP language. And the more you venture into conceptual things like values and functions you're fighting those languages left and right to achieve the same _basic_ semantics.
I'm neither pro nor contra static typing in general and I don't really know Haskell, but I think it would be obvious that Java and C# don't have the same sophistication, inference and expressiveness on the type level as Haskell. When they say "make illegal states unrepresentable" they don't mean "write a bunch of defensive runtime checks".
Not to bash on Java/C#, they are powerful and very useful. But the type of specific benefits the article talks about are not a given or even practical in those.
I used to think that same thing
I recently found a very smart fellow who has been writing translations of a small Scala "expression interpreter" with monads and what.
But in Java. I kid you not.
He wrote it in JDK 8 Java (pretty far from Scala)
Then updated with JDK 15 features Java (getting closer)
I made a rough pass at JDK17 Java using records and ADTs (sealed types) with pattern match "switch" and the net result is an almost verbatim translation.
https://github.com/Randgalt/expressive-java/issues/1
There is one ugly line which JDK18 will fix, "destructuring in pattern captures/match".
See "Deconstruction Patterns" at bottom of page here:
https://openjdk.java.net/jeps/405
I recently found a very smart fellow who has been writing translations of a small Scala "expression interpreter" with monads and what.
But in Java. I kid you not.
He wrote it in JDK 8 Java (pretty far from Scala)
Then updated with JDK 15 features Java (getting closer)
I made a rough pass at JDK17 Java using records and ADTs (sealed types) with pattern match "switch" and the net result is an almost verbatim translation.
https://github.com/Randgalt/expressive-java/issues/1
There is one ugly line which JDK18 will fix, "destructuring in pattern captures/match".
See "Deconstruction Patterns" at bottom of page here:
https://openjdk.java.net/jeps/405
I don't think that JEP is part of JDK18 yet.
The points listed cannot "as easily apply to Java", and, really, not to C# either. You really need a functional language to meet the "requirements" listed, which are -from TFA, almost at the top-:
> Why? Three reasons: > Functions in the mathematical sense. > > No statements, no instructions, just expressions that don’t ever mutate. Everything returns something. You don’t mutate by default. > Type-driven programming. > > Start thinking generally, in broad concepts, about what kinds of info you’re dealing with – the inputs, the outputs, the steps – and then work down to implementation. Start in the center w/ a little implementation and work your way out. Haskell makes illegal states unrepresentable. > > You can't do the wrong thing with this data because this data can’t handle that, it just doesn’t accept that kind of thing.
> Why? Three reasons: > Functions in the mathematical sense. > > No statements, no instructions, just expressions that don’t ever mutate. Everything returns something. You don’t mutate by default. > Type-driven programming. > > Start thinking generally, in broad concepts, about what kinds of info you’re dealing with – the inputs, the outputs, the steps – and then work down to implementation. Start in the center w/ a little implementation and work your way out. Haskell makes illegal states unrepresentable. > > You can't do the wrong thing with this data because this data can’t handle that, it just doesn’t accept that kind of thing.
> You don’t mutate by default.
> makes illegal states unrepresentable
Maybe recent versions of Java are different, but I don't recall either of those statements applying when I used Java.
> makes illegal states unrepresentable
Maybe recent versions of Java are different, but I don't recall either of those statements applying when I used Java.
Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade.
See item 13, "Favor immutability", in Effective Java, the bible of Java programming, published in 2001:
https://www.pascal-man.com/navigation/faq-java-browser/java-...
I can't find a concrete citation for "makes illegal states unrepresentable" (does anyone know the history of this phrase?), but it was certainly part of conversations i was having in 2012.
See item 13, "Favor immutability", in Effective Java, the bible of Java programming, published in 2001:
https://www.pascal-man.com/navigation/faq-java-browser/java-...
I can't find a concrete citation for "makes illegal states unrepresentable" (does anyone know the history of this phrase?), but it was certainly part of conversations i was having in 2012.
"Make illegal states unrepresentable" is usually attributed to Yaron Minsky of Jane Street.
This video shows it at 28:02. https://blog.janestreet.com/effective-ml-video/ https://www.youtube.com/watch?v=-J8YyfrSwTk
This video shows it at 28:02. https://blog.janestreet.com/effective-ml-video/ https://www.youtube.com/watch?v=-J8YyfrSwTk
> Java doesn't force you to do either of those, but it allows it, and doing so has been standard programming advice in Java for at least a decade.
"You can do that" and "enforced by the compiler by default" are pretty different.
"You can do that" and "enforced by the compiler by default" are pretty different.
The whole idea of OOP is you have mutable data coupled with the methods that mutate it.
You can do immutable data structures with OOP. The problem is that you can also do mutation.
Compilers / runtimes for most OOP languages don't really put the same level of optimization into operations with immutable structures as they do with mutable ones, because the mutable paradigm is largely how the languages are (intended to be) used.
There are exceptions, of course, but you are leaving a lot on the table when you try to shoehorn one into the other.
There are exceptions, of course, but you are leaving a lot on the table when you try to shoehorn one into the other.
If you're curious about giving it a try and are doing web dev, check out IHP, haskell's largest web framework: https://ihp.digitallyinduced.com/ (Disclaimer: I'm founder of the company that makes IHP)