<     May 2017     >
Su Mo Tu We Th Fr Sa  
    1  2  3  4  5  6  
 7  8  9 10 11 12 13  
14 15 16 17 18 19 20  
21 22 23 24 25 26 27  
28 29 30 31
00:20 runeks joined
00:20 mbrcknl joined
00:23 ysgard joined
00:40 dni- joined
00:40 acarrico joined
00:44 Axman6 joined
00:51 kadoban joined
00:58 kadoban joined
01:00 Youmu joined
01:01 vaibhavsagar_ joined
01:03 davesq joined
01:05 aarvar joined
01:14 moei joined
01:21 kadoban joined
01:22 cschneid_ joined
01:45 texasmynsted joined
01:48 cschneid_ joined
01:52 carlomagno1 joined
01:54 ysgard joined
02:00 gothos joined
02:13 jacob joined
02:29 dni- joined
02:30 ysgard joined
02:39 exferenceBot joined
02:42 wedens joined
02:43 hexagoxel joined
02:45 mengu joined
02:59 shayan_ joined
03:02 takle_ joined
03:02 bno1 joined
03:02 jacob joined
03:04 shayan__ joined
03:04 blissdev_ joined
03:05 Youmu_ joined
03:05 AlainODea_ joined
03:07 jackhill_ joined
03:07 bengt__ joined
03:07 __red__ joined
03:08 Cthalupa- joined
03:09 watersoul_ joined
03:10 glguy_ joined
03:14 louispan joined
03:15 ycheng joined
03:16 c0dehero joined
03:19 jmiven joined
03:22 ridho joined
03:23 malaclyps joined
03:25 systemfault joined
03:25 argent0 joined
03:28 louispan joined
03:29 conal joined
03:32 takle joined
03:35 takle_ joined
03:42 zacts joined
03:43 <zacts> is there ever an advantage to not use static types for certain applications? like when might I want to use Clojure over Haskell for an app?
03:44 <zacts> or can I pretty much use Haskell for everything that I would use Clojure for?
03:44 <zacts> (if I don't care about Java interop)
03:46 <qu1j0t3> zacts: depends who you ask.
03:46 <qu1j0t3> zacts: you're going to get diametrically different answers, so in this situation, best to do some experiments yourself.
03:50 <kadoban> zacts: There is very little objective information about questions like that.
03:51 <kadoban> It's hard to say, objectively, what makes a language better than another or if that question is even generally useful or meaningful. But IMO, static types are a generally useful tool.
03:53 <zacts> ah I see
03:53 <zacts> sorry
03:53 <zacts> :-P
03:53 <thang1> Also, when people think of static types, they're usually thinking of "oh gee, instead of using Int, I can use PositiveInts, why the fuck would I care?"
03:54 <zacts> what is the claimed advantage of static types?
03:54 <thang1> but the real benefit, to me, of very strong type systems is that they are usually combined with concepts such as typeclasses so you can write code that is "not" typed and is very generic
03:54 <zacts> hm... cool
03:55 <thang1> So I can write a function that has a type "Num a => a -> a" which means "a implements 'Num', this function takes an a and returns an a"
03:55 <zacts> thang1: I think that Gerald J. Sussman is not a fan of pure type systems, from what I recall, for certain applications
03:55 <zacts> let me find the lecture
03:55 <zacts> I think this is what sparked my curiosity in this
03:55 <qu1j0t3> zacts: better performance is one thing. but i like the fact that many properties of values in my program have been proven to hold.
03:55 <thang1> You can (insert handwaving) think of typeclasses as interfaces
03:55 <glguy> Better support for refactoring is a big one for me
03:55 <qu1j0t3> zacts: i don't much like trial and error for that.
03:55 <zacts> ah yeah
03:55 <qu1j0t3> and what glguy said is huge.
03:55 <thang1> So you get tons of code reuse and other benefits of inheritance and things like that... but without /any/ of the pain and bullshit that comes from OOP
03:56 <zacts> oh thang1 cool
03:56 <thang1> And it allows you to specify behavior between things that satisfy properties
03:56 <zacts> yeah I'm coming from Ruby right now
03:56 <thang1> For instance, why should addition care what kind of number I'm adding together?
03:56 <zacts> glguy: oh that's nice indeed :-)
03:57 <thang1> And further, why should I have to redefine "+" for every single number type I ever make in my life?
03:57 <zacts> ah yeah
03:57 <thang1> Instead, I can just say "my new number type implements Num, so it's a number..." and so on to get all the properties of numbers I need
03:57 <thang1> Now you have highly modular, highly generic code
03:57 <zacts> I think it may have been in this lecture, but I can't remember https://www.youtube.com/watch?v=O3tVctB_VSU
03:58 <thang1> which can, at the same time, be given very stron gguarantees about its behavior
03:58 <thang1> allowing for "proofs" and correctness, which is what glguy mentioned.
03:58 <zacts> yeah
03:58 <zacts> I guess I see for many industrial apps type systems like this sound awesome
03:58 <thang1> You can write correct code pretty easily if you're willing to make it only work for certain things. Or you can write generic code pretty easily if you're willing to not care about its correctness
03:59 <thang1> Very strong type systems allow you to get the best of both worlds. Easily written generic code that is easily made correct
03:59 <zacts> but for creative Processing language or musical apps, it seems like maybe non-pure static types might actually provide some effect towards that goal as well?
03:59 <zacts> https://processing.org/
04:00 <thang1> http://music-suite.github.io/docs/ref/ :p
04:00 <zacts> oh cool
04:01 <zacts> neat!
04:01 <zacts> thanks for the link, yeah
04:02 <thang1> https://www.youtube.com/watch?v=4S8dOZ6A8ww
04:02 <thang1> live-coded music in Haskell :p
04:02 <zacts> oh nice
04:02 <zacts> even live music poetry!
04:02 <zacts> :-)
04:03 <thang1> Think of it this way: Types allow you to express the domain in which your function behaves
04:04 <zacts> ok
04:04 <thang1> the more confident you are about where your function will act, the more powerfully and grandoise you can be in your expression of program behavior
04:04 <zacts> I see
04:05 <thang1> If I know multiplication will take two Reals and return a Real, I know it works for literally any number in the Reals
04:05 <thang1> If I know multiplication will take two Natural numbers and return a Natural number, I know I can never have a negative number, I know my answer will be an integer and never a fraction, etc
04:06 <thang1> So if I know these types of things, I don't have to guess about things or check things or what-not. I can confidently go ahead and do stuff
04:06 <zacts> ok
04:06 <thang1> On the other hand, when programming in C. I have to take two numbers, put them in a type (pray it's large enough that it won't overflow), multiply stuff, check for overflow, check for other errors, and finally once I'm mostly confident the answer is right, I can use it
04:07 <thang1> But C has tons of implicit type conversion, and I can insert /anything/ into the multiplication function. Put an int in there? Sure. Float? Sure. Function pointer cast to an integer? Why the fuck not.
04:08 <zacts> hrm... now haskell can generate validated C right?
04:08 <zacts> so I can code a C app in Haskell
04:08 <thang1> Haskell can be used to verify C in a sense because it's easier to verify haskell code and then you can use that to verify C code. Haskell doesn't really generate C, it generates machine code. However, you can use a C app in Haskell
04:09 <zacts> ah ok
04:09 <zacts> hrm... I really need to begin the haskellbook.com
04:09 <zacts> I've been wanting to do this for a while, I've just been so busy
04:09 takle joined
04:09 <zacts> maybe I'll start this weekend
04:10 <thang1> haha, just do it. I'm on chapter 11. I started it knowing I would have no time
04:10 <thang1> You just gotta start it and then you'll find plenty of time to do it :)
04:10 <zacts> ah ok! :-)
04:10 <zacts> the 1st ch was kind of boring, but I'm guessing after that it gets more interesting.
04:10 <zacts> although, I do see how important ch1 is to the rest of the book
04:10 <thang1> 15 minutes of netflix? Or 15 minutes of haskell book. Your brain optimizes for the time give it
04:10 <zacts> ah yeah
04:11 <zacts> maybe I'll start tonight actually.
04:11 <thang1> I tell people to breeze through chapter 1. It's not important to fully understand it, it's important to get it sitting in your brain so that you can start to see connections between that and the rest of haskell
04:11 <zacts> I had a wisdom tooth pulled, but I'm doing ok. :-P
04:11 <zacts> ah I see
04:11 <thang1> nice! Glad you're doing ok. My brother had four pulled at once and it wrecked him for almost a week lol
04:11 <zacts> ah yeah :-P
04:11 <thang1> Start tonight for sure, it's lots of fun
04:11 <zacts> ok
04:12 <zacts> thang1: what kinds of haskell projects have you worked on?
04:12 <zacts> what interested you with haskell in the first place?
04:12 <thang1> I'm only on chapter 11 of the haskell book so I haven't worked on much yet
04:12 <thang1> I was interested because of the expressiveness of the language, functional programming itself, and the theoretical properties of haskell
04:13 <zacts> ah yeah
04:13 <zacts> I like the idea of it. A new playful language that is really powerful, with lots of research backing up the concepts the language introduces
04:13 <zacts> I like the Mathematical aspect of the language as well
04:14 <zacts> It seems like it gets close to pure mathematics in terms of expressiveness, without worrying so much about mechanics and state.
04:14 <zacts> you can get very abstract with your design and expression of concepts
04:14 <zacts> with lazy-eval and things like that.
04:18 dni- joined
04:18 <thang1> definitely
04:18 <thang1> You do end up worrying about state a lot in more advanced haskell code. Monad transformers are essentially giant stacks of managed mutation for your state
04:18 <thang1> But other than that, it's pretty clean and declarative :p
04:19 <zacts> oh cool! :-)
04:20 <zacts> but haskell does have an intelligent way of dealing with state
04:21 <thang1> You should also look at Erlang
04:21 <zacts> I've heard of erlang
04:21 <thang1> it's got a really nice way of managing asyncronous stuff
04:21 <zacts> I don't like the syntax, but there is elixir and lfe
04:22 <zacts> oh cool
04:22 <lpaste> qmm pasted “How does this work?” at http://lpaste.net/736521139609665536
04:24 <thang1> qmm: you used it correctly, congrats
04:24 <thang1> oh did you mean how does the code work?
04:26 <qmm> thang1: i am asking how the code works
04:26 <thang1> Did you write it yourself? Because this just looks like a really simple grammar for a language
04:26 takle joined
04:26 <qmm> ex1 is given an env in example1, but how does it use env?
04:27 <geekosaur> `Var x` case
04:27 <geekosaur> and the only way this can produce a `Nothing` is when the `lookup` fails
04:28 <qmm> ooh, it's a Map lookup
04:28 <geekosaur> which short-circuits out of the evaluator and produces `Nothing`. otherwise it produces `Just` the value, and `eval` produces that
04:28 <geekosaur> well, list lookup
04:28 <geekosaur> and Data.List.lookup is the main reason we always have to import Data.Map qualified >.>
04:29 <qmm> this is about the time I could use Cale's typical hand holding / deep dive into why something works :)
04:29 <geekosaur> `env` is what is sometimes called an "associative list" or (mainly by Lispers) "alist"
04:29 <qmm> oh right, i knew that
04:30 <qmm> is eval looking using ex1 to look up items in env?
04:31 <qmm> i didn't mean to type looking
04:31 <geekosaur> specifically, the `Var "x"` is triggering the lookup through the `Var` case of `eval` (line 22)
04:31 <Cale> qmm: Sorry, what?
04:31 pungi-man joined
04:33 <qmm> Add (Val 2) $ Add (Val 1) (Val 2)
04:33 <qmm> Add (Val 2) 3
04:34 <qmm> Just 5
04:34 takle joined
04:36 <geekosaur> the second step is actually Add (Val 2) (Val 3)
04:36 <qmm> aha, i finally matched the types up. sorry for the false alarm
04:36 <qmm> this is the first time i sat down and try to understand ReaderT
04:37 <qmm> geekosaur: how so?
04:37 uglyfigurine joined
04:38 <geekosaur> you're confusing the current state of the evaluator with the current reduction of the AST. internally, you don't have the Val markers because eval always produces an Int --- but if you substitute that Int back into the AST, it needs to be a Val mode
04:38 <geekosaur> *Val node
04:38 <geekosaur> but if you don't keep these two things straight, you can easily get confused especially with a more complex AST
04:39 <geekosaur> the point is more that you can't write (Add (Val 2) 3) as a value for `ex1`, it would be a type error
04:40 <geekosaur> because the parameters to Add must both be Expr-s
04:42 <geekosaur> anyway to avoid getting confused about the AST vs. the current evaluation result, you could either wrap the reslt in Val when showing it as part of the AST, or you can --- since you're just writing about it, not writing it as code --- somehow delimit the part that is the current evaluation result
04:43 <qmm> is there a way to visualize the tree somehow in ghci?
04:43 <qmm> or is there a way to step through evaluation?
04:44 <benzrf> qmm: kinda!
04:44 <qmm> you were just saying they aren't the same thing, and so i hope not to confuse them, but i am curious if either of these facilities exists
04:44 <benzrf> http://felsin9.de/nnis/ghc-vis/
04:44 louispan joined
04:45 <geekosaur> ghc-vis is what I was going to suggest as well
04:45 <benzrf> :)
04:45 <geekosaur> but I got diverted by the other [art of the question >.>
04:45 <benzrf> ]
04:45 systemhalted joined
04:45 <geekosaur> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#tracing-and-history
04:46 <qmm> ghc-vis looks nice!
04:46 <geekosaur> sadly what ghci means by "single stepping" has little to do with what most programmers mean by it (it steps by *breakpoint*, not subexpression or line)
04:46 <qmm> it would be useful to have that as part of ghci output
04:47 <qmm> http://felsin9.de/nnis/ghc-vis/#combined-debugger
04:48 <qmm> thank you all for the help
04:51 <qmm> would the linked code above change if you were using a variant of the ReaderT monad from mtl or transformers?
04:53 <qmm> the lpaste code
04:59 takle joined
05:04 takle joined
05:09 louispan joined
05:13 wedens joined
05:18 takle joined
05:25 takle joined
05:40 takle joined
05:42 uglyfigu_ joined
06:00 takle joined
06:00 yellowj joined
06:07 dni- joined
06:08 eatman joined
06:21 takle joined
06:22 louispan joined
06:24 uglyfigurine joined
06:24 takle_ joined
06:25 conal joined
06:29 nickolay joined
06:31 takle joined
06:33 uglyfigurine joined
06:37 hvr joined
06:37 hvr joined
06:41 takle joined
06:42 uglyfigurine joined
06:50 takle joined
06:51 uglyfigurine joined
06:58 dni- joined
06:59 takle joined
07:03 mattyw joined
07:09 conal joined
07:09 uglyfigurine joined
07:11 ridho joined
07:16 ysgard joined
07:19 cur8or joined
07:21 sbrg joined
07:26 geekosaur joined
07:37 uglyfigurine joined
07:37 thc202 joined
07:39 hphuoc25 joined
07:41 ridho joined
07:41 louispan joined
07:43 takle joined
07:45 nacon joined
07:45 nacon joined
07:55 uglyfigurine joined
08:14 louispan joined
08:19 colt44 joined
08:22 uglyfigurine joined
08:23 galderz joined
08:24 madjestic joined
08:24 bvad joined
08:28 ysgard joined
08:32 grdryn joined
08:41 colt44 joined
08:43 Levex joined
08:45 zero_byte joined
08:46 takle joined
08:47 zph joined
08:47 nitrix joined
08:50 Levex joined
08:51 pilne joined
08:52 Iceland_jack joined
08:52 Gurkenglas_ joined
08:54 noumenon joined
08:58 xificurC joined
08:59 mstruebing joined
09:04 ysgard joined
09:08 uglyfigurine joined
09:17 colt44 joined
09:18 bytesighs joined
09:20 deank joined
09:23 kritzcreek joined
09:26 uglyfigurine joined
09:26 jkachmar joined
09:29 runeks joined
09:31 romank joined
09:32 haskelleksah joined
09:33 haskelleksah left
09:34 wedens joined
09:39 ridho joined
09:44 uglyfigurine joined
09:46 madjestic joined
09:47 seanparsons joined
09:50 geekosaur joined
10:02 uglyfigurine joined
10:03 Uniaika joined
10:11 qu1j0t3 joined
10:11 uglyfigurine joined
10:26 netheranthem joined
10:52 mengu joined
11:18 hphuoc25 joined
11:27 Durz0 joined
11:34 nobodyzxc joined
11:35 amuck joined
11:46 madjestic joined
12:13 Gurkenglas_ joined
12:18 Pupnik joined
12:22 cschneid_ joined
12:23 cur8or joined
12:54 geekosaur joined
13:08 geekosaur joined
13:12 TCZ joined
13:15 iAmerikan joined
13:29 <GreySunshine> Hello, I've been trying to setup 'interactive-haskell-mode' on haskell-mode. I want it to suggest imports statements and suggest completions from the imported modules. Here is my .emacs file(http://lpaste.net/938582110887739392). I think line 10, 11, 12 does what I ask for but it doesn't work, what should I do?
13:29 mizu_no_oto_work joined
13:33 chlong joined
13:35 pbrant joined
13:43 jathan joined
13:47 <xificurC> I've read waitForProcess shouldn't block the main thread if -threaded is used. I have this code http://lpaste.net/355191 , which basically runs git pull on a series of git projects. They run sequentially even with -threaded. I guess I need to write the code differently to achieve parallelism?
13:50 <Akii> line 19 looks like it blocks
13:51 <Akii> you could probably use forkIO for each runGitPull to make it concurrent
13:51 <Akii> or better: use the async library and wait for all asyncs to complete
13:52 takle joined
14:06 ridho joined
14:07 <xificurC> Akii: was away sorry
14:09 <Akii> np
14:10 matp joined
14:11 <glguy> xificurC: you'll need to use something like the async package to perform the actions concurrently
14:11 <xificurC> and how would that look like? I can keep the runGitPull function as is and call it with some async wrapper?
14:12 <glguy> ?hackage async
14:12 <lambdabot> http://hackage.haskell.org/package/async
14:12 <glguy> there should be a mapConcurrently
14:12 <Akii> mapM_ waitAsync (fmap async dirs)
14:12 <Akii> should do it
14:12 <Akii> oh
14:12 <Akii> or that
14:12 <Akii> ^^
14:13 <xificurC> let's see
14:13 <Akii> mapM_ waitAsync (fmap (async . runGitPull) dirs)
14:13 <glguy> Akii: fmap isn't good enough
14:14 <glguy> you'd need mapM there and join the two with =<<
14:14 chlong joined
14:15 <xificurC> brilliant. Replacing mapM_ with mapConcurrently_ and done
14:15 <Akii> glguy: right
14:15 <Akii> I thought :t async was IO a -> Async a
14:15 <Akii> but it is IO a -> IO (Async a)
14:15 <Akii> (of course)
14:16 takle_ joined
14:16 <xificurC> that was easier than I expected, I'm pretty bad at haskell
14:16 <xificurC> any other tips on the code? :)
14:17 <Akii> use do notation in getGitDirs? :D
14:18 <xificurC> Akii: whyyy, looks so cool, no anonymous functions along the way
14:18 <Akii> ye, you're right
14:19 <xificurC> @pl \path -> listDirectory path >>= pure . map (path </>) >>= mapM makeAbsolute >>= filterM doesDirectoryExist >>= filterM isGitDir
14:19 <lambdabot> (filterM isGitDir =<<) . (filterM doesDirectoryExist =<<) . (mapM makeAbsolute =<<) . liftM2 (>>=) listDirectory ((pure .) . map . (</>))
14:19 <xificurC> look at that :)
14:19 <Akii> perfectly readable now
14:19 <Akii> :D
14:23 <bitemyapp> for when you really want that pointfree one-liner real bad
14:24 <xificurC> I thought you don't follow the IRC anymore :)
14:24 takle joined
14:24 <bitemyapp> I watch quietly, but I haven't needed to do much lately.
14:24 <Akii> :D hi!
14:24 <bitemyapp> Akii: hi!
14:24 <bitemyapp> my IRC session is persistent, I usually keep it open whenever I'm at my work computer (8+ hours a day)
14:29 <xificurC> bitemyapp: how's the book getting along?
14:38 ysgard joined
14:38 <bitemyapp> It's been content complete for awhile
14:39 <bitemyapp> just final editing and getting print version sale ready to go
14:41 <xificurC> great
14:41 <xificurC> gotta run, thanks for the help guys
14:44 <Akii> another satisfied customer
15:01 bvad joined
15:02 <bitemyapp> http://bitemyapp.com/posts/2017-05-03-what-a-haskell-study-group-is-not.html
15:03 skeet70 joined
15:07 dni- joined
15:08 ridho joined
15:12 uglyfigurine joined
15:14 moei joined
15:14 <MarcelineVQ> "Given Haskell’s rather esoteric reputation in the world of professional developers, you are likely to be issued demands to defend Haskell’s general usefulness, the practical utility of certain concepts, or the viability of functional programming as a whole." I don't barely even talk to anyone and I've ran into this, so weird
15:14 <MarcelineVQ> *I barely
15:15 cschneid_ joined
15:17 bvad joined
15:22 Xion_ joined
15:23 <tuturto> MarcelineVQ: I have had opposite too. In previous place I worked, there was programmer who really liked Haskell and found it a beautiful language
15:24 <tuturto> granted, his first programming language ever was Haskell and now he's writing C#
15:24 <tuturto> and javascript
15:27 tom7942 joined
15:29 <Xion_> One day I'm gonna remember that it's not just types that are CamelCase, but data constructors too.
15:36 bvad joined
15:40 tom7942 joined
15:40 merijn joined
15:44 sigmundv_ joined
15:51 haskelleksah joined
15:51 haskelleksah left
15:52 <reptar_> anyone have opinions on how to make this prettier? https://github.com/fishyFrogFace/hackerrank/blob/master/structures/tree/test/Spec.hs
15:54 <glguy> reptar_: You can get rid of a bunch of the uses of 'do', like on line 31. Add whitespace between your major 'describe' sections. There's not that much you could really eliminate
15:55 <reptar_> ah ok, i was more thinking about the trees i specify
15:55 <reptar_> although it looks a lot less messy on github
15:55 <reptar_> thanks :)
15:56 <glguy> You could define: b = Branch
15:56 <glguy> and save a bunch of space, perhaps
15:58 <reptar_> what i could do is create an arbitrary tree
15:59 <glguy> That wouldn't help you to have a tree and the expected output for it, would it?
15:59 <reptar_> aww, no it wouldn't
16:13 meandi_2 joined
16:20 aarvar joined
16:22 Deide joined
16:32 ysgard_ joined
16:37 bytesighs joined
16:40 runeks joined
16:40 delexi joined
16:41 zph joined
16:43 pilne joined
16:45 yellowj joined
16:47 jkachmar joined
16:57 madjestic joined
17:01 conal joined
17:02 ysgard joined
17:02 conal joined
17:04 iAmerikan joined
17:06 haskelleksah joined
17:08 dni- joined
17:28 <uglyfigurine> Why are there 2 channels - #haskell and #haskell-begineers?
17:28 argent0 joined
17:28 <merijn> uglyfigurine: Because some people thought #haskell was too noisy and intimidating for beginners and started a new channel dedicated to beginners
17:53 <Cale> uglyfigurine: It's certainly not because beginners are unwelcome in #haskell, they most assuredly are.
17:54 <uglyfigurine> yeah i asked my question there since there are more people there but wasnt sure about the etiquettes in the community
17:54 <uglyfigurine> tx for clearing it up
18:01 ysgard_ joined
18:02 majjoha left
18:06 ralu joined
18:09 mengu joined
18:10 ridho joined
18:10 mlehmk joined
18:14 jship joined
18:14 <Xion_> This channel seems to be pretty dead though.
18:16 malaclyps joined
18:17 <Cale> Xion_: I for one would be happy if it just got reabsorbed into #haskell
18:21 <monochrom> Every channel looks dead sometimes.
18:21 <monochrom> (Deliberate ambiguation of quantifier scope!)
18:22 <Xion_> I hang out in #rust-beginners for comparison, and it's basically constantly busy, esp. during West Coast daytime.
18:23 <monochrom> Oh that just means it's dead when you're sleeping.
18:23 <merijn> Xion_: It's pretty active, but usually during CEST working hours
18:23 <merijn> Xion_: At least, I always see activity during work
18:24 <Xion_> Oh cool, maybe I'll see it more lively when I come back to Europe :)
18:24 <monochrom> Even #haskell, whenever I look away and play a game, it's alive; then I finish the game and come back, it's dead.
18:25 <monochrom> Approximately only #ubuntu can sustain 24/7 because all sorts of users from all sorts of timezones need help.
18:26 <Akii> I'm in a channel where there is stuff happening once a week or so
18:26 <Akii> still worth it
18:27 <monochrom> whereas Rust and Haskell for example are more like first-world problems.
18:28 <Cale> There are only a few people using Haskell professionally thus far, and usually they're the ones who are answering the questions ;)
18:28 ysgard joined
18:28 <Cale> (if they're on IRC at all)
18:28 <Xion_> Yeah, I came here hoping for some help because I may end up having to write Haskell for work.
18:28 <Akii> sad times
18:29 <Akii> forced to write Haskell, oh gawd
18:29 <Xion_> ;)
18:30 <monochrom> A lot of 1st year students do resent being forced to write Haskell :)
18:30 <Xion_> Sorry, didn't want to sound like someone with a #firstworldproblem :)
18:31 <Akii> Cale: I'm at least able to catch the noob questions now
18:32 malaclyps joined
18:36 albertus1 joined
18:36 carlomagno joined
18:38 eacameron joined
18:39 ysgard joined
18:46 mizu_no_oto_work joined
18:46 haskelleksah joined
18:57 dni- joined
19:03 <qu1j0t3> Xion_: it's a problem many would like to have :D
19:04 conal joined
19:11 carlomagno joined
19:16 <Xion_> qu1j0t3: Precisely why I'm skeptical about joining that team. They do high throughput / highly scalable distributed system, though, it's their main appeal to me. (And they are also apparently pretty rare that they're doing such stuff, which is SUPER confusing given we're talking about a company with almost 2B users).
19:17 <* qu1j0t3> doesn't understand why 'skeptical'
19:17 madjestic joined
19:18 <Xion_> It's the same phenomenon as game industry really.
19:18 <Xion_> Everyone wants to work there, but it means you have put up with ton of crap. I'm curious what kind of crap they kind to put up with :)
19:18 <qu1j0t3> oh.
19:18 <qu1j0t3> hm, well, that hasn't anything to do with haskell though.
19:19 <qu1j0t3> i was just commetning on that part.
19:19 <qu1j0t3> are you worried that you might not be skilled up enough?
19:20 <Xion_> That too.
19:21 <qu1j0t3> yeah i can see that
19:22 <qu1j0t3> still, sounds like a great opportunity
19:23 <Xion_> Well, at least I can say 'screw it' and go work on frontend Javascript tooling, which is the other team I'm considering joining :D
19:23 madjestic joined
19:26 mengu joined
19:31 fluffystub joined
19:31 ebw joined
19:37 conal joined
19:45 iAmerikan joined
19:47 Iceland_jack joined
19:48 yellowj joined
19:56 eacameron joined
20:01 carlomagno joined
20:06 carlomagno1 joined
20:08 Iceland_jack joined
20:09 carlomagno joined
20:12 ridho joined
20:16 ebw joined
20:21 eacameron joined
20:22 yoanna joined
20:28 whiteboyfly joined
20:46 dni- joined
20:49 iAmerikan joined
20:51 uglyfigurine joined
20:51 mengu joined
20:57 uglyfigurine joined
21:08 takle joined
21:11 conal joined
21:12 ridho joined
21:20 sivs joined
21:22 peterbecich joined
21:22 romank joined
21:34 conal joined
21:36 iAmerikan joined
21:38 carlomagno joined
21:40 carlomagno1 joined
21:43 conal joined
21:46 mac10688 joined
21:53 hiratara joined
21:54 carlomagno joined
21:58 Levex joined
22:06 Levex joined
22:09 zero_byte joined
22:13 romank joined
22:14 ridho joined
22:21 ego joined
22:23 Sose_ joined
22:24 Levex joined
22:25 carlomagno joined
22:31 hiratara joined
22:31 Levex joined
22:35 dni- joined
22:40 yoanna joined
22:58 romank joined
23:02 pixelfog joined
23:02 Levex joined
23:15 cschneid_ joined
23:15 ridho joined
23:16 <pixelfog> I'm confused about how to understand precedence in Haskell expressions. Consider the function "let length' = sum . map (const 1)". On the one hand, I thought that function application had the highest precedence and associates to the left, so the function "sum" would be applied to the argument ".". But instead, the function (.) is applied to the argument sum. Why is that?
23:17 <Xion_> . is not an argument of `sum` here, it's an operator acting on `sum` and `map (const 1)`
23:17 <Xion_> To treat an operator as a "function name", you need parentheses.
23:18 <Xion_> So this is still consistent with the application-is-highest-precendece rule: `map (const 1)` binds tightest, followed by .
23:19 <kadoban> That ^ You'd be right if . could actually be a function argument, but it syntactically can't be.
23:20 <kadoban> sum (.) map (const 1) would work like that, then ``(.)``, ``map`` and ``(const 1)`` are arguments to ``sum``
23:22 <pixelfog> So, as a human reading that expression, I see "sum" and I think it's a function, and then I see the ., and I say to myself, wait a second, . can't be an argument, so I start over, realizing that . is the function and sum is the argument because of *syntax*, not because of any precedence rules?
23:23 <kadoban> Sounds right I guess. It's pretty automatic after a while, so it's hard to examine internally.
23:24 <Xion_> pixelfog: It's same as seeing `a + b` and interpreting it as addition, not the application of `a` to `+` and `b`
23:24 Cale joined
23:30 carlomagno1 joined
23:30 <MarcelineVQ> more info here https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-220003 including a handy table and links to clarifications
23:36 <pixelfog> Okay. `a + b` used to be obvious to me, but then I started seeing mind-bending code using multiple composition (.) operators, and I tried to get more mechanistic in how I'm interpreting expressions, and that's when I really got confused. :-) Thanks for the link. That helps.
23:36 carlomagno joined
23:42 <kadoban> Once you have a bunch of operators to figure out, then you have to start looking at precedence. But most expressions shouldn't be using a ton of different operators in ambiguous ways, unless they're *very* well known operators that you're just expected to learn.
23:56 <thang1> Yeah if you see code that's doing some weird stuff like (flip (.)) foo $ x <$> q r =(~^_^)= w t f i s d i s
23:57 <thang1> just run the other way :p
23:58 louispan joined