But research fraud does delay finding treatment. How many hours of wasted time chasing dead ends.

In the last 25 years, tens of billions almost all spent chasing the amyloid beta hypothesis, with other theories getting the short end of the stick.

It didn't start changing until outside researchers wrote a major editorial about how bad it was in Nature.

The biggest alternative is the infection hypothesis - amyloid beta is left by our immune reaction to diseases that manage to get into the brain. If that idea had been pursued for 25 years, we might actually know by now what the real connections are with HSV1 (warts), gum disease, and so on.

That presumes there is a treatment, and the proposal to research it would have been funded, and it would have been found to be effective. But yes, research dollars are somewhat of a fixed pie, and there are always people who don't get a slice.

So I have very little experience with elixir, but I appreciate the effort to bring static typing. With that said, I find the use of parenthesis pretty hard to read. As in I need to spend more time than a quick glance to grok what's going on. Maybe it's because I'm not familiar with the ecosystem, but coming from a typescript, python, and go background mostly, I find this

negate :: ((integer() -> integer()) and (true -> false) and (false -> true) and (a -> a) when a: not(integer() or boolean()))

harder to reason about quickly than say this

negate :: (int -> int) & (true -> false) & (false -> true) & (a -> a) when a: ~(int | boolean)

Is there a reason that syntax was chosen? Is it just for showcasing purposes or is that basically just how the language works?

For the paper, we have decided to go as precise as possible, since its goal is to discuss the type-system semantics and not its syntax, so parentheses are everywhere.

You will for sure be able to drop the outer parens in your case and you _may_ be able to drop them on the function types too (to be decided). Ending up with something like this:

    $ (integer -> integer) and (true -> false) and (false -> true) and (a -> a) when a: not(integer or boolean)
    def negate(arg)

We will also allow intersections to be broken across multiple declarations:

    $ integer -> integer
    $ true -> false
    $ false -> true
    $ a -> a when a: not(integer or boolean)
    def negate(arg)

In your example, how can the compiler (or a human) know that int is a concrete type as opposed to an unconstrained type variable?

Consider these two function signatures:

map :: ([a] -> [a])

map :: ([int] -> [int])

Furthermore the syntax that Elixir uses here let's you do something like

map :: (list(a) -> list(b))

list_to_other_data_structure :: (list(a) -> other_data_structure(a))

It all reminds me a bit of how Haskell does it https://medium.com/functional/haskell-basic-types-and-type-v...

I'm now curious to know if/how the above 'generics' would be expressed in TypeScript/Python/Go without a similar 'type constructor' syntax construct?

A simple syntax would be something like

map :: forall a. ([a] -> [a])

or

map :: <a> ([a] -> [a])

At least in the current system I think the parens are optional if it doesn't have arguments so if you really need to leave them off when writing the type you probably can. But like someone said it's erlang convention going back decades.

Anyway coming from ocaml I don't aesthetically like this but coming from ocaml I have no grounds to talk shit about any language's aesthetic choices. The parens make sense to me when I think of them as type constructors, rather than concrete expressions of the type itself.

It’s how types have been specified in erlang for 20+ years: https://www.erlang.org/doc/reference_manual/typespec.html

If you look at any erlang api doc, you’ll see predicate-like type specs. Conveniently, it naturally supports generics by just adding “parameters” to the predicates, so a dict would have type.

It works fine, and makes things less ambiguous, as erlang “types” can contain enumerations of values, in the original spec it’s clear that `integer()` is a type and `false` is a value, in your version not so much.

This looks really clean, congrats!

But also from my end, this leaves me pretty unmotivated. I've been working on an mvp to launch my own startup the past month, and today I find out it already exists in your product.

Don't let us discourage you. There is room for multiple companies in any space worth building a startup in.

Happy to build this space with you, together. Competition is good for customers and ultimately that's who I'm serving.

Email me brennan at hypercontext.com and I'd be happy to collaborate.

This is, if anything, a good sign for your project. It means the idea is _somewhat_ validated by YCom. That's far better than doing something that isn't validated at all!

as a new manager, had the same exact idea and found a few companies in this space[0][1] (and now this one too)

ultimately decided there's just too many competitors. my only gripe with all of these is that they're heavily subscription based/pay to use monthly, etc. i want something more personal that i can just purchase for like $10-20 (more like an app on my mac that i can just use forever)

my other gripe is that i don't want to have to onboard my entire team onto it. i want to only use it myself as like a reference guide for the health gauge of my team. i dont need them all inputting their OKRs into these products

[0] https://www.15five.com/

[1] https://www.small-improvements.com/

We have a small team starter plan that's $5 total for your first 5 users.

Also, we'll only charge you for additional users if you a) invite them and b) they sign in and become active.

So definitely can stay at $5/m and use it as a personal tool for as long as you want to. It's on the product to convince you your life can be significantly easier through inviting people, not me

Cool, good to know! thanks for the reply