331 karma · joined July 18, 2014
In most languages, however, that's not a construct you can do much of anything with.
Though now that FP concepts are mainstream, I think there is a good case to offer some friendlier, more familiar names:
Functor -> Mappable
Applicative -> Pairable
Monad -> Thenable
[0]: https://softwareengineering.stackexchange.com/questions/2033...
> The company shall ... for a period of three months from such date to repurchase all or any portion of the Unvested Shares (as defined below) held by Purchaser as of the Termination Date at the original purchase price per Share (adjusted for any stock splits, stock dividends and the like)
You wouldn't lose any money, they'd basically reverse the early exercise.
If we can create an AI with different goals and reward mechanisms, there is a potential that we could create agents that are experiencing bliss doing data processing tasks.
Of course how we tell the difference between a miserable agent and a joyous agent is still an open question ..
`ewr Parsippany, NJ (US)`
the type `forall a . a -> a` does truly have one single (non exception throwing) implementation since there is no information you can glean about your argument other than the fact that it exists.
Once you have more structure, for example in `Person -> Person` or even `forall a . [a] -> [a]`, you have more possible implementations than just the identity function.
To answer some of your questions:
1. Long lists are pretty painless to implement. There a some helper views included for building list views that aren't backed by in memory lists, and they feel really nice and fluid (https://api.flutter.dev/flutter/widgets/ListView/ListView.bu...)
2. Flutter has lots of built in animation support. Almost every aspect of a view is animatable out of the box (see https://api.flutter.dev/flutter/widgets/AnimatedContainer-cl... for an example). I definitely got carried away with the animations because of how fun and easy they were!
3. I had to deal with native code for push notifications, sharing flows, and universal links. Google publishes libraries for dealing with a lot of the common stuff, and there's great community support as well.
Personally, I like to stay pretty close to the javascript when doing web work. Elm, Purescript, GHCJS all have their benefits but I find it just too difficult to integrate with the rest of the (disjointed) web development toolkit.
Co-Star is bringing astrology into the 21st century with a social, personalized experience that helps people reflect and connect in real, meaningful ways. Over half of millennials and nearly a third of American adults are into astrology. We just raised $5m from the people behind companies like Glossier, Rent the Runway, eBay, Periscope, and Everlane.
We’re looking to bring talented software developers to join our 8-person team in Chinatown, NYC. We’ve been taking a full-stack approach to the way we work but are open to having you dive deep into areas you’re especially passionate about.
Our stack includes
* Haskell for our backend API
* Swift and Android Native for our mobile apps
* React and TypeScript on the web (costarastrology.com + internal tools)
* AWS to host our infrastructure
* PostgreSQL
We want your help
* Shipping new features in our iOS app
* Scaling our backend infrastructure to >1M daily users
* Developing internal tools to give our content editors super powers
* Using TB of analytics data to help the product team develop insights
* Making this the best place to work
$0 deductible fully-covered health care, unlimited vacation (min 4 weeks), conference/book/whatever budget
Read more details here -> https://www.costarastrology.com/jobs + feel free to email directly with questions -> ben at costarastrology.com
We are looking for a full stack developer who is familiar with at least one of Haskell, Swift, or AWS and is open to learning the others. We love types at Co—Star, and a passion for statically verifying code is a plus. Some of the technologies we use include:
- Haskell (our whole web api is written in this!)
- Swift
- Python (we use AWS Lambda to wrap python libraries we don’t want to port to Haskell)
- React + TypeScript
You’ll be our first engineering hire (joining two engineering founders), so you’ll have a big say in what we do and how we do it. We’re growing quickly and want you to be a part of helping us scale up, tackling problems like partitioning our database, switching to a more sophisticated messaging queue and improving our machine learning pipelines.
Full-time, on-site in Brooklyn. Unlimited snacks, vacation, insurance, etc. Email us your resume -> jobs ∀ costarastrology.com
About Us: Co—Star is a mobile application combining traditional methods of astrology with modern technology to create a hyper-personalized and social astrology experience. We are making astrology – along with the meaning and connection it engenders – accessible to the entire world. Read more here: https://www.costarastrology.com/about
In Haskell, you can use do notation:
do
x <- someFunction
y <- anotherFunction x
z <- yetOneMoreFunction y x
return (x + y + z)
This is syntactic sugar for something like (using `flatMap` in place of >>= (bind) ): flatMap someFunction (\x ->
anotherFunction x (\y ->
yetOneMoreFunction y x -> (\z ->
return (x + y + z)
)
)
)
If Haskell programmers had to write code like this (which is what monads look like in other languages), there's no way they would use monads!In languages with objects, you can sometimes get away a minor victory by using what I'll call a "shallow bind". Consider promises in javascript (which form a monad with unit a = Promise.resolve(a) and flatMap p f = p.then(f) ):
someHttpRequest().then( response => {
if (response.body == undefined) {
return Promise.reject("no body error");
} else {
return Promise.resolve(response.body);
}
}).then(body => {
try {
return Promise.resolve(JSON.parse(body));
} catch (e) {
return Promise.reject(e);
}
}).then(parsed => {
if (parsed.status == undefined) {
return Promise.reject("no status");
} else if (parsed.status == 500) {
return Promise.reject("server failure");
} else {
return Promise.resolve(data);
}
// what would you do if you decided you wanted to reference `response` here somewhere?
});
This is definitely an improvement over a deeply nested callback style from 10 years ago, but it does sacrifice some flexibility. You can't refer to previously handled promises because the callbacks are shallow. You can do that with do-notation, and that's what makes the concept of monads stick in Haskell.Once you have that, and in Haskell, it's amazingly implemented as an overloadable piece of syntax, the doors are wide open. Example: at my work, we use free monads to get a similar effect as dependency injection in other languages (clean separation of concerns, easy mocking, etc) but with two huge benefits: 1. Any function is limited to using only the dependencies/effects you allow it to, it won't type check if you try to sneak something in, and 2. Because of the overloadable syntax, we use it to collect timing info on all of our operations that are doing IO in a way where we get a flame graph style hierarchy of effects _for free_. We never have to specify when to start and a stop the timers, the syntax knows when to. It's pretty powerful.
Co-Star is a mobile application combining traditional methods of astrology with NASA data and modern technology to create a branded, hyper-personalized and social astrology experience. Nearly half of millennials believe in astrology – and that number continues to rise as more people are searching for meaning, connection, and community across all aspects of their lives. Since launch in October 2017, Co-Star has grown incredibly quickly and was ranked in Apple's top 100 entertainment app weeks after launch. We are an early stage startup (we just raised a seed round of funding) looking to expand the team as we continue to gain traction and develop the app!
Some of the technologies we use include
- Haskell (our whole web api is written in this!)
- Swift
- Python (we use AWS Lambda to wrap python libraries we don’t want to port to Haskell)
- React + TypeScript
We are looking for a full stack developer who is familiar with at least one of Haskell, Swift, or AWS and is open to learning the others! We love types at Co—Star, and a passion for statically verifying code is definitely a plus!There are currently three of us (founders) working on this. You’ll be our first hire, so you’ll have a big say in what we do and how we do it.
Contact jobs@costarastrology.com
If there's going to be a new made up system for standardizing and measuring the proficiency of software developers, then we may as well make up new words too that don't have this baggage.
Employees don't get paid the full value they generate, so that's not a reasonable way to interpret minimum wage.
Still, if they're short it seems unlikely that you'd have any issues.
And that's the point of a lot of these abstractions. It's not about being able to write something that you couldn't in another language. After all, we could create the same functionality in assembly.
[0] https://hackage.haskell.org/package/transformers-0.2.2.1/doc...
If you assert that a person can understand everything there is to know about the color red and then still not understand what it is like to see red, you have either contradicted yourself or assumed dualism.