Why Co–Star Uses Haskell
costarastrology.com
costarastrology.com
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)
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... :)
Something ironic about getting a 502 from your domain right now
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?
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.
> 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 is abundant if you look for it. FB, Microsoft, and Standard Chartered all have active internal haskell projects.
Source: Used to work there.
Sad in the cases where it was a well done project. Frustrating when it was bursting at the seams.
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.
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.
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.
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.
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.
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.
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.
Conversely, I may have just been unlucky. Would love to see studies and data.
Having an advocate for a program is a predictor. That advocate doesn't have to be a developer.
And note that I am not anti these languages. Just acking that there is plenty of experience on both isles.
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!
"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".
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...
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.
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.
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.
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".
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.
http://web.archive.org/web/20050131033632/http://www.skirsch...
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.
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.
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_...
We (Mercury) have 60 backend engineers working on a monolithic Haskell backend. So at least there is one counterpoint to your hypothesis.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
> 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...
In theory someone could believe that astrology was real and could be learned by a machine learning model, no?
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.
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.
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.
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 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...
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.
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?
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 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.
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.
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.
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.
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.
Tools matter. However the community and ecosystem behind Python makes it extremely hard to beat at many games.
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.
And no environment really beats RStudio.
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.
Python continues to earn its reputation as the second-best option for most problems.
It's always a matter of choosing the least worst solution with Python, and additionally patching over shortcomings of the language with afterthought-tooling.
Never heard that line before but it resonates with me.
https://github.com/JuliaPy/PyCall.jl https://github.com/JuliaInterop/RCall.jl
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 mean… is that such an unreasonable point of view?
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!)
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!
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.
[1]: https://roscidus.com/blog/blog/2013/06/09/choosing-a-python-...
> 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.
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 would be comparing Haskell more to Scala/Elixir/etc if you're trying to make an argument for Haskell.
I honestly can't tell if this is parody.
main = putStrLn "Hello World"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.
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.
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.
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.
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.
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.
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, on an enterprise scale, you can avoid the majority of bugs, would that not be a clear win?
"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.
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.
It sure is. Dart, also a Google language, did not fare quite as well.
This vicious cycle exists for a lot of very good languages.
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".
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?
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.
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
What about "a big company with multiple dev teams that are expected to actually deliver things on time"?
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.
"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.
a=4
3+a
3+a or 3+b
This will also not compile in Smalltalk.
Nothing to do with static typing at all.
And perhaps there might be something like a Python Enum HOWTO
IF NATALPLANET == “MARS"> 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.
https://www.drmaciver.com/2015/04/on-haskell-ruby-and-cards-...
I mean, if they’re fine with claiming that astrology is real to enrich themselves, why should I believe anything else they say?
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).
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?
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.
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?
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.
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.
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...
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."
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 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.
> Please don't use Hacker News for political or ideological battle. It tramples curiosity.
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.
Typical Capricorn.
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.
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 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'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 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.
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?
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.
Is this actually substantiated?
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.
edit. Its a dark mode issue, styling not being applied to the background rendering
If the author is reading these, please consider using a static background.
when I turn that off, I can't see any background effects at all
LOL thats giant. How much does it cost to run the show? 30 x $100,000 for an astrology app?
The points listed could almost as easily apply to Java or C#
> 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.
There are exceptions, of course, but you are leaving a lot on the table when you try to shoehorn one into the other.
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.
"You can do that" and "enforced by the compiler by default" are pretty different.
This video shows it at 28:02. https://blog.janestreet.com/effective-ml-video/ https://www.youtube.com/watch?v=-J8YyfrSwTk
> 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.
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 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: