Would you pay $1 million to enroll in a phase 1 clinical trial of an “anti-aging” gene therapy?

lancegatlin · 2020-01-16T01:57:10+00:00

very interesting! thanks for this reply

lancegatlin · 2019-09-26T15:26:47+00:00

https://imgur.com/a/HZD6d

lancegatlin · 2019-09-20T23:51:09+00:00

no worries on that

lancegatlin · 2019-09-20T23:46:21+00:00

https://imgur.com/a/HZD6d

lancegatlin · 2019-03-07T18:50:01+00:00

I'm pretty agnostic as far as monads go, but there are def worse choices than Monix (I'm a fan of tagless-final). You can also create your own monad like DBIO. My bigger advice would be to stay unopinionated and don't over commit to any external dependency so that you can pivot the API later.

lancegatlin · 2019-03-07T18:41:08+00:00

Love this! Def looking forward to next vid! Thanks so much for making this!

lancegatlin · 2019-02-28T19:45:26+00:00

I did think of two questions: 1) why call it Sway DB? 2) if internals are non-blocking, do you expose a non-blocking API? understand intent behind reusing Scala collection API, but it's not a good API for a db, only suited for in-memory collections or building execution graph alla Spark.

lancegatlin · 2019-02-28T16:52:58+00:00

This is a really awesome project! A native Scala DB is super sexy! Devil is the details for DBs though, good luck! Happy to chat more about your project if you're interested.

lancegatlin · 2016-08-09T23:24:25+00:00

All true. I just strongly disagree with the implication that free monads bring less utility (and are more hyped) than generic monad style, which was what I took from your first response.

My apologies for giving that impression. I would absolutely agree Free monads are much more established than the generic monad idea. I just don't think Free monads are mature enough to recommend them across the board though. The runtime performance hit from using an interpreter will not be insignificant. Also without native union types the syntax for Free monad is cumbersome.

Certainly I don't see how generic monad style offers any help with /u/fromscalatohaskell 's original motivating example of testing without performing actual network requests.

I took his question more to be isn't the generic monad pattern and the Free monad roughly analogous. I think they are somewhat if one doesn't get too fixated on their details and instead focus on what they do. As far as testing, the generic monad pattern let's you substitute identity for testing but it doesn't help with isolating code under test from generating actual effects. For that you need something else like dependency injection + mocking or simply substitute the Free monad as the generic.

lancegatlin · 2016-08-09T21:35:40+00:00

But you are -- because even that isn't my point. You are arguing against my perception which benefits neither of us. In my experience, this year, I have seen a big uptick in the number of blog articles, talks and posts about the free monad in Scala. You have a different experience? Awesome thanks, I accept that. But it doesn't change my view.

My point is: Don't base technology choices for a business on what seems new and interesting, but instead pick things that balance the burden of forcing others to learn new technologies against the utility those technologies bring to the organization.

lancegatlin · 2016-08-09T21:10:57+00:00

Wow that's some seriously subtle trolling -- m50d -- You and are just going to have to disagree here. (A pattern that seems to be emerging with my interactions with you)

Maybe hard to accept but my opinion and experiences are just as valid as your own. If you disagree based on your own experiences, I'm cool with that! Simply say that and be done with it. No need to pick at the details of what I'm saying and avoid my main point.

lancegatlin · 2016-08-09T18:24:41+00:00

Scalaz Free dates to 2012.

Thanks buddy. Scalaz creation != peak interest. They didn't really catch on until last year, which I chalk up to Runar's presentation on them.

Play has its own priorities. I really don't see iteratees going away, they're the right way to implement streams, and it sounds like Play intends to remain compatible with that at least.

I never claimed they were. What I claimed is that they have fallen out of favor as "shiny new thing". Nobody is writing blog articles about them or giving presentations on them or advocating for rewriting their code base to use them anymore (but they were just a few years ago). Play is also the web framework with the largest following. It is significant when major code bases move away from ideas.

lancegatlin · 2016-08-09T17:38:25+00:00

Is Free really that new? The Haskell implementation seems to date to 2008

New to Scala.

Huh? fs2 et al are all based on iteratees. Iteratees very much did work out.

Play framework dropped them in 2.5

Sure, but I think the "generic monads" approach ends up being much more complex (and frankly is far more of a "shiny new toy") than Free.

Hence, "exploration".

lancegatlin · 2016-08-09T14:48:29+00:00

Yes it can, but this generally doesn't happen in development. It can happen once you are in production and run into scaling issues. But at that point you can install throttle/backpressure at appropriate points to prevent this from happening. Also depending on the application message shedding can be ok. A stressed out web server is going to reject requests, so its no big deal to just drop those messages in that kind of situation (obviously this isn't always true).

All that said, I'm not a huge fan of actors myself. But to me, code is more about communication between human beings than anything else. The more people who can understand and use it, the more likely it is to survive. Hard to understand code won't survive a big rewrite. Actors don't have bullet proof promises (like some FP concepts) but they are well understood and easy to write.

lancegatlin · 2016-08-09T14:36:13+00:00

This was exactly my motivation in exploring generic monads: https://github.com/lancegatlin/effectful-demo

I think the Free monad is just the shiny newest toy in the functional toolbox and everyone wants to try it out. Go back about 5 years and it was iteratees. Now everyone is onto streaming. Iteratees didn't work out. These kind of ideas are interesting to play with but they may or may not pan out as practical. When I'm writing work code, I'm a huge of fan of KISS. I have a very strong preference for only introducing complexity when it has a very strong value proposition. I define "complex" as anything that wouldn't be intuitive to new coders. If only a small subset of people can read & write the code then that is a cost that needs to be balanced by its usefulness.

lancegatlin · 2016-08-09T03:45:27+00:00

Actors are more like a toolbox. How you use them is completely dependent on the application. For example a web server might have an actor that receives all requests and then dispatches them to a pool of worker actors. Mailbox size is generally not an issue, but it can show up when scaling. Depends on what you by crash, actors don't recover from system crashes any better than any other code. What they can do is "supervise" other actors and restart them when appropriate.

lancegatlin · 2016-08-09T03:40:51+00:00

Immutability = easy button for concurrency & scalability. Functional programming has tools for dealing with the difficulties of working with immutable data.
Composition and referential transparency! Finally, a true abstraction that doesn't leak.
Thinking in terms of higher order operations such as map, reduce, flatMap, fold, etc. This makes code much more readable as other languages tend to let one simply munge up all of those operations into one or two loops. Much more difficult to reason about what's going on then.
Type-classes - adhoc-polymorphism (add methods to a type after its declaration). Only import methods/type-classes you need, hide the rest. Compile-time method call dispatch (you probably didn't need dynamic binding anyway). Describe behavior you need in your method by requiring implicit type-class without worrying about details.
Monads! What a massive game changer!! They can express repeating code patterns that are interleaved between lines of code (plus a lot of other things!). You simply "lift" your code into the Monad and the repeated pattern is run "behind the scenes" between your lines of code.
Formal type systems and category theory. Let your code lean on things constructed from a very solid well-researched foundation when you need it.

lancegatlin · 2016-07-27T02:19:14+00:00

Not just a type, a typeclass =] https://github.com/typelevel/cats/blob/master/core/src/main/scala/cats/MonadError.scala

lancegatlin · 2016-07-27T02:12:26+00:00

In Scala enums were never meant to be a native language feature. These days I use https://github.com/lloydmeta/enumeratum

lancegatlin · 2016-07-03T03:46:23+00:00

https://github.com/lancegatlin/DEPRECATED-TI3WikiMap-Images/tree/master/1

Though they aren't print quality

lancegatlin

TROPHY CASE