Interesting talk, as a side note: "spit, spit"(плевался, плевался) is translated from Russian as "to find disgusting/repulsive"

Thank you Katie for using "Use case" and actually understanding what it means.

Great talk! Nice to see how Haskell is used in production and giving us some hope that we can use it in our day to day work sooner rather than later,

Great presentation. My biggest barrier to using Haskell in production is how difficult it is to bind it to the platforms I care about. iOS/Android, and even web. There are some things that are working on this (especially web), but it still doesn't seem to be truly practical. It's very tempting to try to solve these problems and then use Haskell, but that's hard to justify the upfront costs, which is probably why it hasn't really been done.

Simon Marlow presented Haxl at Chalmers University last month

This is a great talk, I love to see companies along with more and more programmers see the light of many of Haskell's attributes. Haskell isn't the only way to get all these benefits, but it is currently the best! Haskell in production WORKS, you just need passionate developers who want to write robust and correct software.

People who think type errors are an annoyance sure must love running bugs on their client's machines lol. Like No Boilerplate said in their video on the Rust compiler, the only thing worse than bad errors is no errors.

Wait. Where's Katie 0?

Someone please travel back to 2016 and adjust the podum mic for Katie 1.

Are the slides somewhere publicly available?

That is an impressive rules based processing engine. Haskell. The engine seems to be applicable for many scenarios. Managing with policy and understanding and translating the policy bullets seems like the challenge step. I liked how she stated it just replicated out and reattached to the rules engine. They visualized this process in 1990. Wow.

Great talk! Great person!

Is that nine hundred Hz a secret tone suitable to indoctrinate us into using Haskell?

That "spit. spit" means you hate something.

Katy1 and Katy2 must be lua programmers

Programmers learn and use languages like Haskell because somebody above them usually wants them to.... after all, if a language thats stable and been available for years (there are many, and most of us know what they are) can do what you need it to, why learn something else, especially if there is no guarantee it will do as you want? Of course we all want to learn new things, thats how we progress, however, to have the desire to do that we need to know it will enable us to do more or to do better than with what we already have? Does Haskell? That is the question.

Great talk!

Great video!

¡ Like for a Visual Haskell in the future ! (GTK is hard to install, i can't do that jaja)

thanks

Oh how I disagree with the point at 38:18 - the compiler SHOULD yell at you here - that is important - if not then readability and maintainability goes down the drain. A good compiler should be strict and force you to stick to the rules in order to write code that exhibits the trait that two pieces of code that do the same should - more or less - look the same. This is the biggest problem with languages like Python and apparently also with this system!

Thank you for the truth about the Haskell!

So what sort of tools, IDEs are used in Facebook for Haskell?

Nice talk, and pretty interesting. That being said I want to learn Haskell and I feel that one main point has not been addressed and that is what I would call the Elitism of the language. I am a PHP programmer (mainly), and yes php has lots of problems, I'm not trying to say it's better than Haskell. But one thing I really hate about Haskell (not specific to haskell mind you) is the elitism of the code. It's difficult to read and understand. Most haskell code thrives to be "elegant" which is just another way of saying we crammed as much instructions as possible in the minimum amount of space, making it basically impossible to understand for an outsider. Take pretty much any Haskell tutorial and look at the function arguments: 'x', 'y', 'z' , '(x:xs)', '(y:ys)' etc... and this is considered standard practice. Why can't you give your parameters meaningfull names ? Can you at least comment your code to help me understand ? No ! How am I supposed to know what those parameters stand for ? Answer: I can't, I have to go read some kind of Documentation somewhere explaining what they are supposed to be, and generally that documentation just makes me feel dumb because I can't understand half of it so it generally boils down to "If you don't have a Phd in Mathematics and don't fully understand what Lambda calculus is, you are not worthy of using this code". Wheras in reality using meaningfull parameter names, adding some comments in the code and using a more explicit way of doing things would have enabled me to understand what the function does without even the need for documentation. I Hate this, I believe good code should be understandable by pretty much anyone, ideally even someone with no programming background should be able to get the idea of what is going on by reading the code. The prime example of this I feel is if/else vs ternary conditions, or explicit return statements vs directly returning the result of an operation in parenthesis. Yes the code is more elegant and requires less lines, but at the end of the day it doest exactly the same thing and is inherently less readable. If I show a simple if/else condition to my wife, she will probably get it, whereas if I show her the exact same condition in ternary form she doesn't have any chance at all of understanding what the code does. There it is, that's my little rant about Haskell and can definitely be applied to many other languages but I do feel Haskell is one of those languages that goes the extra mile to make sure that people who are "unworthy" are not able to understand the source code.

shit, I saw my id there! co-dh

Ultra white user? was that Simon Peyton Jones?

Languages are suited for their domain, the benefits if functional programming languages are only there of you have bunch of code to to run in parallel( coz that's where the benefits of pure kick in that you can parallelize) , when you are caching the requests and when you are writing some thing very high level like rules engine where even frequent changes in imperative language would be costly. I don't know why people need to jump the gun and exaggerate. They can simply present the differences in plain and easy style and not try to generalise.

In summary, every preconception you have about Haskell is true.

Isn’t Haskell just machine code in disguise?

Haskell is the new Perl: write once, read never.

i wish i could be on her team lol

I'd take c++, c, c#, even java, python or even fucking visual basic over something so convoluted and unintuitive any day. You are pressing a problem into a language that can be solved with any number of languages. and because your one example works with haskell still doesn't make it a viable programing language at large. people will use php or asp for server side programming, c#, c++, c, basic or python for general purpose programming and javascript and such for client side programming. anything else really is niece. I mean industry works like this: - Have a problem. - Need an automated solution to the problem. - Analyze the problem and here you select the language to use to solve the problem. will you spend time (money) learning something new, potentially only suited to that one single problem? or will you select a language that your employees already know and work with every day to solve any problem you can possibly solve algorithmically in the first place? Surely the answer is simple. you get a niece problem that can be solved with a niece language, or perhaps less elegant in a language you are already familiar with, but faster, then industry will always choose the second option. who wants to spend time learning something they use once only? especially where that would cost thousands of dollars for essentially doing nothing productive, and then perhaps find out that this or that is not doable because of limitations. coming from qbasic at the age of 8, i could easily pick up a c++ book and learn it rather quickly in my spare time. then going to pascal in school, again easy to learn. then java in university, same thing. then MC6809 assembler, different, but knowing how c translates into machine code made it simple to pick up as well, the concepts are the same, function calls are easy to implement, variables, stack, memory pointers, registers, all the same thing really. first in minecraft, then in logisim i found a hobby at doing some 'hardware engineering', building this and that logic circuit, again the mindset is already there, thinking logically about instructions and how to combine transistors to logic gates, and logic gates to multiplexers, and all those modules you already have to make something larger like an ALU. at work i now work with c#, which I had no experience with before. within a week I learned and wrote a program that works with bus systems and databases, expanding on it and adding functionality to it ever since. And now I see this and think, what the fuck is wrong with people? this resembles nothing of the above. it's math and formal languages pressed into a pancake that tries to be programming. I have an object oriented and procedural programming mindset, it's easy to understand and intuitive. It wouldn't cross my mind to go to something that forces me to bend my mind just to get behind the idea of it. I need to think in instructions and code and it needs to come naturally, something I just couldn't do with something this backwards. It's the same as using base root(15.7) as a number system. useless except for very few niece applications, and hard to wrap the mind around. Side effects can be useful, and even desirable. Disallowing them inhibits the freedom of the programmer. If you do not wish for side effects, then sticking to a few basic guidelines prevent them. a = b + (i++); is the same as a = b + i; i = i+1; and nobody in the right mind would write the first line, it's confusing, but possible. but should it be forbidden? i think not. even worse f(someBool && (i++) == 5) a nightmare. i will only increment if someBool is true, or if some specific compiler settings are set. but again, people don't do that sort of stuff. any oop language, and c like language have strong typing. i don't see how that's any better than those. python or javascript are a clusterfuck though. still i am able to wrap my head around them. class Id {private int ID; public int getID(){return ID;} ...}, strong typing, easy in oop languages. no haskell needed for same results. no one is gonna bother though, because you have names. even the most dumb monkey wouldn't confuse a variable name ID with something like breadrollsIHadThisMorning. To encapsulate a simple number into an object is possible and would have the same effect, but no one would really bother unless there are some critical requirements. usually classes would be used to create complex data types. right. teaching: just don't teach the language, just teach the simple stuff. try teaching c without structs and enums. or c++ without classes and overloading. sure you can still write your hello world, but it's just prohibitive to not know what tool you're working with. By the way, did you know the linux kernel, or any kernel, has no haskell code in it? I don't know even a single program at work or at home that runs haskell code. From what I can see, it isn't really suited as a program in itself anyway, but rather only as a layer between input and output. can you query a database? or can you even read a keyboard input? I don't know. What even is a keyboard to haskell? even the most basic concepts don't apply. When you say challenges, what you mean to say is problems. You have a new problem, haskell might be suitable, but no one knows, because nobody in the imaginary firm has experience with it. But they know the problem can be solved in what the firm's programmers are experienced in, say dotNet. Will they decide to learn the new, foreign and different language, basically from scratch where prior mindsets and ideas don't apply? fuck no, they won't. they will use the tools they are familiar with, the languages they can wrap their head around quickly and write elegant code swiftly to deliver a solution to the problem in a timely manner. Haskell might not solve all your problems. But c++ will, as will c, java, python, c# or basic. Because those languages don't have limitations. you put enough time into it, and they will solve any and all problems that are algorithmically possible to solve.