Видео

very good presentation, will use this for Kotlin

they fix the audio at 5:30

It would probably be better if "Monad" in the Haskell sense was just named "Effect" or something along those lines.

Effect-TS is this but for TypeScript. Inspired by ZIO, and others.

I agree with all the commenters here: very informative and inspiring! Thanks!

0:23

It seems that in Haskell you have to learn several languages rather than just one, you have to see the program, the program written at the type level, the program written using tacit style, the program using the different type classes... Haskell the terminology is completely alien from all other languages and often deliberately misleading like return for wrapping into a monad instead of wrap, join instead of flatten, bind for >>=. Lets not add that names like semigroup, magma, monad, monoid, cartesian closed categories, kleisi arrow, profunctor, mean very little until you learn them. I have an idea of naming Haskell things by their "type/code" like afa for return/liftM0, aifafi for map/liftA, aiufafifu for zipWith/liftA2, =<< would be amiami, $ would be aiai.

Yeah, sorry for the sound. In order to record the screen and merge audio from microphone and the game I fed both audio streams through a mixer. It seems like the game engine's CPU usage sometimes took priority over the mixer, so the mixer started messing up the audio.

Haskell has to compete with Scala(too complex), swift, Julia, Rust, Ocaml, reasonml, Python, Clojure, Racket, Eff language. If Haskell moves to the Jvm, Python byte code, web assembly, hmm

We need a good Haskell ide that shows data flowing through your functions, can easily apply rewriting rules to code so you can see the various different ways that code can look like, we also need automatic ways to rewrite your program so that monads and extra arguments are automatically threaded through your program. Haskell also needs a solver to help you code sort of like Agra and ide is. Also haskell should merge with hose languages. Another thing is Haskell should come with template haskell macros that can do trace rewriting so that people can visualize Haskell code easily.

I never thought of Kan extenstions this way, but it makes a lot of sense. Great food for thought!

Yes. Kotlin is definitely way better than Scala. I'd like to see Kotlin as the official API language for Spark.

It's nice to go back to this talk! Thanks a lot for the presentation.

This is the best explanation of the effects system ever. I was trying to explain it to my colleagues and this is the talk they need ! Thx you you ROCK!

ZIO is slow like a snail, trashes the GC by generating a ton of garbage objects for even the simplest computations, and has a ton of pointer redirections that bust the cache. Keep your (mutable) Actors, you are going to get 3x performance.

ZIO is basically a bunch of leaky abstractions in one library.

Very useful sugar explanation! 🔥🔥🔥

🔥🔥🔥

Another banger, thanks man

At first I thought this cli feature would be great for our very large cli system. We are seriously considering converting all our TCL code to Scala/Java. But now I don’t think so. We should use Maven and target all our Scala and Java code to native binary files and run each file with a simple ./xyz -arg1 -arg2 … Shouldn’t we be able to do this without any shell scripting?

This video could have been so much better if it had focused on topics that everyone could relate to. I had to think hard about the last time I had to program a memoize operator, and I probably never have. I don't even know what a memoize operator is. Now I'm forced to learn about memoize and operators just to follow along? There are so many other interesting topics and problems that could have been the backdrop of this talk, ones that people actually have to solve without all the quantum physics operatot jargon. I don't understand why the Scala community, by and large, is so cerebral. Sorry for the rant, but if everyone wonders about Scala's decline, that's a big chunk of the problem. Meager 1.1k views after 1 year speaks for itself.

I am really rigorously trying to stay away from the value-type dichotomy. So at around 14:00, I would say "Vec N is a dependent type because it depends on members of other types, in this case natural numbers which are members of type Nat". I think that presenting value-type dichotomy is the single biggest roadblock when it comes to practitioners understanding dependently type languages.

I would love to see this presentation revamped in light of Java 21 Virtual Threads, Structured Concurrency, and Scoped Values...

Really great presentation. I just loved it.

8:30 bless this man...bless this man!

I thought the factorial problem would check for huge enough numbers so people cheating with an arbitrary large integer data type would fail due to inefficiency. Note that: H> (\k -> product [1..k] `mod` 10 :: Integer) <$> [0..] [1,1,2,6,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0..]

I only hate how bad is the caption in broken French. I need to translate it back to English to guess the intented meaning. I usually do not have this problem on other YT channels. An example: The French phrase "calculs de compilateur basés sur la pile que je connais" is probably meant to refer to the "the stack-based compiler computation that I know", while it actually means "compiler computation based on the stack that I know". Like if the guys knows a precise stack and he based his computation on it ? In French as in English. the definite article "the" changes everything, and it looks likes the model misinterpreted the expression "the stack-based x" as meaning the same thing as "x that is based on the stack" instead of "x that is based on a stack".

Thanks for a great talk! Do you have a recording of the last topics you had to skip over anywhere?

Great talk

Thanks for a great !talk

Auto wiring of JobScedular is not working

getting following error, what can i do ? Description: Parameter 0 of constructor in com.example.demo.JobController required a bean of type 'org.jobrunr.scheduling.JobScheduler' that could not be found.

A great demonstration, thank You!

terrible speaker

Half of the screen is dedicated to a white background and the "Haskell Love conference" branding. Really? Who was the genius who decided that only one-third of the available space should be enough for the code section in a presentation about competitive programming?

Is it possible to integrate jira with gitbucket?

I was intrigued by the speaker's book before seeing this but now I have to read it and learn how to better weild the type system. Amazing talk.

Good overview

Great work. You created an interesting DSL, that is complex enough to make generalisations for other domains. I'm waiting eagerly for your book.

🤮

Interesting intro to making sounds in Haskell. Very unfortunate that the talk is abruptly cut at the end...

For people watching on small screens, could you make the slides larger in the future?

Thank you for the insight!

Love this! also this remind me of Haskell Love 2020 video, ruclips.net/video/wppzFzzD4b8/видео.html

Thank you for this great keynote, and you've described and summarized perfectly the pathway (by chance and experimentation) I've followed this past two years :)

Esto on top lowz K

At last we get to see Haskell Love 2021

At 8:55, you said that the compiler didn't freak out when using an IsLabel instance and an ambiguous reference to a field name, but GHC 9.4.2 complains about an ambiguous reference when I define such an instance.

I missed this. Is there a way to watch it now?

Such a knowledgeable guy