2012-07-23 20:52:02 UTC <bob> seems to me that this (by default) laziness is more pain than good (but perhaps it's just how my mental model works, never having used a lazy language)
2012-07-23 20:53:46 UTC <chrisdone> it's a trade-off no doubt. it gives first-class macros and lets me not care about order and is composable in exchange for being a performance nusances
2012-07-23 21:05:16 UTC <chrisdone> yeah it's hard to imagine what it brings without working in it
2012-07-23 21:05:30 UTC <chrisdone> i was thinking that on the way home
2012-07-23 21:05:45 UTC <chrisdone> if you haven't working in lisp you have no idea what a macro system is about
2012-07-23 21:06:02 UTC <chrisdone> if you haven't worked in haskell you have no idea what type system is about
2012-07-23 21:06:10 UTC <chrisdone> etc
2012-07-23 21:07:38 UTC <chrisdone> (“or an equivalent system”, anyway)
2012-07-23 21:08:02 UTC <chrisdone> java, ruby, python doesn't tell you shit
2012-07-23 21:09:01 UTC <chrisdone> ah, an appropriate use for 'grok' finally
2012-07-23 21:10:40 UTC <chrisdone> To understand. Connotes intimate and exhaustive knowledge. When you claim to ‘grok’ some knowledge or technique, you are asserting that you have not merely learned it in a detached instrumental way but that it has become part of you, part of your identity. For example, to say that you “know” LISP is simply to assert that you can code in it if necessary — but to say you “grok” LISP is to claim that you have deeply entered the
2012-07-23 21:10:40 UTC <chrisdone> world-view and spirit of the language, with the implication that it has transformed your view of programming. Contrast zen, which is similar supernal understanding experienced as a single brief flash. See also glark.
2012-07-23 21:11:18 UTC <chrisdone> ^ exactly :) this meaning of grok is perfect
2012-07-23 21:11:56 UTC <bob> heh, I didn't think it means “so deep”
2012-07-23 21:15:31 UTC <bob> any case, back to the laziness item — you're using it most of the time because it's on by default; just wondering, wouldn't you prefer to turn it on in just a few cases, instead of using it every time?
2012-07-23 21:16:05 UTC <bob> it's just hard to believe, to me, that it's useful in more than 50% of cases
2012-07-23 21:17:08 UTC <chrisdone> not sure, i thought about that yesterday; someone suggested a strict mode for fay
2012-07-23 21:19:48 UTC <chrisdone> it becomes your default way of thinking. i think i make use of it without having to think about it now
2012-07-23 21:20:15 UTC <bob> true, I can understand that; but isn't it just wasteful in most situations?
2012-07-23 21:20:17 UTC <chrisdone> so if i write foo (print 123) i'm not wondering about the laziness aspect, i just know that i'm passing the action print 123, not evaluating the result and passing that to foo
2012-07-23 21:21:09 UTC <bob> right.. I'd certainly want to be able to do this every now and then, but not generally (macros come close when I need that)
2012-07-23 21:25:13 UTC <chrisdone> well, like, functions like withBlah or when or whatever which are macroey i can pass around like normal functions -- they ARE normal functions, i don't think twice about the distinction. that's what i mean by 'first-class macros'
2012-07-23 21:25:43 UTC <bob> yeah, and I agree that's totally awesome
2012-07-23 21:26:04 UTC <chrisdone> in terms of not caring about order there are things like this… not sure whether this crops up a lot, but:
2012-07-23 21:26:10 UTC <bob> it just doesn't seem to be the ordinary use case, so probably I'd be happier with a language where laziness doesn't happen by default
2012-07-23 21:26:37 UTC <chrisdone> if somecondition
2012-07-23 21:26:38 UTC <chrisdone> then abc
2012-07-23 21:26:38 UTC <chrisdone> else xyz
2012-07-23 21:26:38 UTC <chrisdone> where abc = <something that would error if !somecondition>
2012-07-23 21:26:41 UTC <chrisdone> xyz = <something that would error if somcondition>
2012-07-23 21:27:14 UTC <chrisdone> that's a super contrived example, but in real code it basically means you can keep your declarations and logic separate. in non-lazy code you would have to restructure your code to avoid it breaking
2012-07-23 21:27:48 UTC <bob> if “if” is a function, right; if it's a special operator like it is in most languages, then you don't have the problem
2012-07-23 21:28:18 UTC <chrisdone> in lisp:
2012-07-23 21:28:39 UTC <chrisdone> (let (abc <something that would error if !somecondition>)
2012-07-23 21:28:39 UTC <chrisdone>      (xyz <…
2012-07-23 21:28:39 UTC <chrisdone>   (if …
2012-07-23 21:28:43 UTC <chrisdone> you've already thrown an exception at this point
2012-07-23 21:29:02 UTC <chrisdone> instead you have to have two LETs in each branch
2012-07-23 21:29:21 UTC <chrisdone> (assume that it's not a contrived example and you need to bind some variables)
2012-07-23 21:29:26 UTC <bob> ah, I see what you mean..
2012-07-23 21:29:47 UTC <bob> the “where” defines what symbols refer to, but lazily — right?
2012-07-23 21:29:47 UTC <chrisdone> that's a nice feature. but i'm honestly not sure how often i take advantage of it. i'd have to pay attention to it when i'm coding
2012-07-23 21:29:52 UTC <chrisdone> yeah (or let x = … in …)
2012-07-23 21:31:01 UTC <bob> yeah, doing that in lisp would involve some boilerplate, though it can probably be abstracted with a macro
2012-07-23 21:33:06 UTC <chrisdone> the final third advantage of composability is a harder to explain. performance-wise, that map f (map g (map k …)) = map (f.g.k) are speed-equivalent is nice, you can compose all sorts of looping/filtering/transposing functions that would have to be custom syntax or one big macro. the other composability thing is how things can just fit together but i'd have to think about that
2012-07-23 21:33:06 UTC <bob> hmm, doesn't seem trivial though, that'd be a macro which would implement lazy semantics
2012-07-23 21:34:55 UTC <chrisdone> those are the three benefits that become just "don't even have to think about it" second-nature in a lazy language. but yeah, i'll think about how often i make use of that in reality, it's an interesting topic