These are chat archives for got-lambda/expression

6th
Nov 2017
Marco Zocca
@ocramz
Nov 06 2017 04:35
sorry,I should elaborate. Was very tired yesterday evening
Marco Zocca
@ocramz
Nov 06 2017 05:43
Yes so, it's a long post which makes a number of claims of various magnitude which makes it a bit hard to unpack
first, your use of the word "abstraction". Typeclasses are more like constraints I'd say
constraints which compose, in particular
Marco Zocca
@ocramz
Nov 06 2017 05:55
and by saying that a type obeys certain constraints we get composite implementations for free
example: two functions {f, g} which return Either Exception a. If you say h = f >>= g , h short circuits if f throws, otherwise returns the result of g
Marco Zocca
@ocramz
Nov 06 2017 06:01
even though typeclasses are not first class by default, I find stuff like this pretty liberating
Marco Zocca
@ocramz
Nov 06 2017 06:11
it bypasses the need for tests, for one thing. Tests are just this other, separate, set of programs which are supposed to tell me something about my main program
under the assumption that the tests themselves are correct
there's a whole spectrum of uses of the Hs type system. You can happily live in value-land and just use a handful of typeclasses (usual Functor/Applicative/Monad) to write great programs
or you can go full Kmett and not talk about values altogether
programs become pure sets of constraints
Jean-Louis Giordano
@Jell
Nov 06 2017 06:16
I think there's something that was lost in my article, probably because I gave bad examples and wrongly phrased. I agree with with you say, the bit I was discussing was if you just look at >>=, it's hard to know what it does without context
because depending on the context (which monad you use it with) it can mean different things, although in all cases it means the same abstract thing
Marco Zocca
@ocramz
Nov 06 2017 06:18
btw good morning @Jell ^_^
Jean-Louis Giordano
@Jell
Nov 06 2017 06:18
morning to you too! :)
just waking up to see the conversation totally spinning out out control on reddit :(
Marco Zocca
@ocramz
Nov 06 2017 06:19
yeah I saw that too. There's been some Clj/Hs beef going on in the blogosphere these past few weeks
maybe that's why
well but again, this "context" you mention. It's as saying that arithmetic is hard because it forces you to keep in mind what ++ and ()\sqrt() do
on one hand, yes, but on the other, well, it made us reason about counting oranges and counting money under the same framework. Sorry for the square root bit, it's unrelated
Jean-Louis Giordano
@Jell
Nov 06 2017 06:29
arithmetic can be hard if abstracted to its essence. It's easy in the context of numbers? In any case you have to think of the operations, but if you abstract over the domain then you need either think about arithmetic in higher level of abstraction (harder?) or know the domain it's being applied to when used
if you have an algebra that works on numbers and quaternions, you might define your functions in terms of those operations without understanding the laws it's supposed to follow or something
Jean-Louis Giordano
@Jell
Nov 06 2017 06:34
and when you get a type error, you get feedback at the abstract level, so you can't really avoid that knowledge
Marco Zocca
@ocramz
Nov 06 2017 06:42
is it a bad thing?
Jean-Louis Giordano
@Jell
Nov 06 2017 06:51
no! why everything has to be either good or bad?
Magnus Therning
@magthe
Nov 06 2017 06:53
Is there a link to the reddit discussion?
it turned into "dynamic idiots" vs "static zealots"
really uninteresting :/
but it's my fault there, I was not careful enough in my wording and examples
Magnus Therning
@magthe
Nov 06 2017 07:01
So, I listened to ep 112 of functional geekery this weekend, and among all the talk by the interviewer the interviewee did say one thing that I thought was quite interesting. As I understand it his observation is that many in the FP community (or I think he actually said developers in general) have a very principaled view on programming languages, but the view on programming (the activitiy) is much less so, that is, we argue righteously about our languages and their features, while at the same time fumbling in the dark, applying ad-hoc methods when using those languages to create programs :)
Marco Zocca
@ocramz
Nov 06 2017 07:03
very true
Jean-Louis Giordano
@Jell
Nov 06 2017 07:03
yeah, it's the creative part of the process right?
Magnus Therning
@magthe
Nov 06 2017 07:07
Well, as I understood it having a more structured way to construct programs doesn't mean creativity is removed from the process... more of a methodical way to apply the creativity, an order of areas to be creative in, sort of... I'll see if I can find more information
Jean-Louis Giordano
@Jell
Nov 06 2017 07:09
not what I meant at all, very much that you can be as principled as you like in all kinds of areas as long at it stimulates your creativity
oh wait I misread your comment
Id be interested in that methodical way to apply creativity
sounds a bit counter intuitive to me
Magnus Therning
@magthe
Nov 06 2017 07:12
Yes, I suspected I over analyzed your comment a little, but thought it good to just cut off the "soon computers will write programs for us" discussion ;)
I'll see what I can find
Magnus Therning
@magthe
Nov 06 2017 07:26
@Jell excactly how do you use the Pareto Principle when making decisions relating to "producing things as fast and reliably" as you can?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:37
first you need to look at some sort of metric
cost of delay is my favorite
"we lose x for each unit of time that passes"
then you can start doing risk estimation
Magnus Therning
@magthe
Nov 06 2017 07:39
Yes, I'm with you so far, but where does Pareto come in? (So far you're talking risk estimation, and possibly real options and late decisions)
Jean-Louis Giordano
@Jell
Nov 06 2017 07:40
the pareto says most of the time 20% of the effort gives you 80% of the value
so it also mean not having an absolutist approach to bugs and features
Magnus Therning
@magthe
Nov 06 2017 07:41
indeed, it does
Sorry to be a pedant, but I still don't see how you relate this to static/dynamic types
Jean-Louis Giordano
@Jell
Nov 06 2017 07:42
well a lot of the arguments I hear about static typing benefits are "you don't have runtime type errors"
which to me is not a business value in itself
Magnus Therning
@magthe
Nov 06 2017 07:44
OK, please continue
Jean-Louis Giordano
@Jell
Nov 06 2017 07:44
reducing runtime errors in general is a business value
so I want to understand what price I want to pay for that
Magnus Therning
@magthe
Nov 06 2017 07:45
OK, now bring it home, 20% of what delivers 80% of what in this particular case?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:45
to me Clojure is small, can easily be taught, and reduces dramatically runtime error
to me that's the 20/80
Magnus Therning
@magthe
Nov 06 2017 07:46
Reduces compared to what?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:46
compared to ruby specifically in my case
Magnus Therning
@magthe
Nov 06 2017 07:47
ah, OK
but are you then using the Pareto Principle in relation to static/dynamic typing, to choose between two dynymically typed languages?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:48
well both
ruby vs clojure vs haskell
Magnus Therning
@magthe
Nov 06 2017 07:48
(I don't think I have to point out that I'm slightly allergic to people mentioning the Pareto Principle ;) )
Jean-Louis Giordano
@Jell
Nov 06 2017 07:49
why?
some will use the same argument for Haskell vs Idris as well
the bing is that principle is not absolute it is context dependent
Magnus Therning
@magthe
Nov 06 2017 07:50
Because, just as you did, they often just say, "I use the Pareto Principle to guide me", without explaining how, what's the 20% effort spent, what's the 80% value delivered
Jean-Louis Giordano
@Jell
Nov 06 2017 07:50
so I agree that taking it generally is bad
Magnus Therning
@magthe
Nov 06 2017 07:51
So, Clojure compared to Haskell delivers 80% of the value at 20% of the effort?
If that's the case, how do you ever decide to use Haskell?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:55
i didn't mean that
I said I use it to guide decisions
jolod
@jolod
Nov 06 2017 07:56
@magthe When "value" is defined differently.
Jean-Louis Giordano
@Jell
Nov 06 2017 07:56
experiment and risk assessment and learning gives you models to make those decisions
we have an excellent case for haskell and it will be put in production
Magnus Therning
@magthe
Nov 06 2017 07:57
@jolod how do you mean?
Jean-Louis Giordano
@Jell
Nov 06 2017 07:57
but also clojure is perfect for front end because designers can learn / use it
Magnus Therning
@magthe
Nov 06 2017 07:59
@Jell I'm with you so far, I agree with all you say, except I fail to see where and how I can apply the Pareto Principle :)
So, when it comes to bugs, there's empirical studies showing that fixing 20% of the reported bugs, brought down the complaints by 80%
And in economics Pareto reported that 20% of the landowners controlled 80% of the land
And one could posit that implementing 20% of the features would satisfy 80% of the customers
Magnus Therning
@magthe
Nov 06 2017 08:11
I'm just a little facetious and probably slightly stupid, but is it 20% effort in Clojure delivers 80% of the correctness of Haskell?
Jean-Louis Giordano
@Jell
Nov 06 2017 08:22
something like that
Magnus Therning
@magthe
Nov 06 2017 08:26
all right, I'll buy that :)
Magnus Therning
@magthe
Nov 06 2017 08:44

On another note, the article is good.

All decisions have trade-offs, but it's worth pointing out that choosing between languages (based on their features) are like all other decisions... there's no right or wrong, just trade-offs. As such I like it.

I also like your style of writing :)

Marco Zocca
@ocramz
Nov 06 2017 10:51
idk I feel the resource estimation/cost of delay argument is incomplete
rn I'm in sunny Stockholm but we should bring the knives to this ideological fight over a couple beers soon
on a more serious note, I feel the hidden cost of refactoring is never taken into account by dynamic typing arguments
jolod
@jolod
Nov 06 2017 11:19
@magthe The value might, or might not, be based on wether it is a one-off program. Etc.
@Jell You posted it before I has time to write my feedback. Anyway, were you by any chance inspired to write this after watching the last Rich Hickey talk? 🙂
Magnus Therning
@magthe
Nov 06 2017 11:52
@jolod sorry, but that doesn't clarify it any further to me... longevity of the program is something to consider when deciding how much effort to put into constructing the program, but where does Pareto come in?
But we can drop this now; I'm probably just daft :/
Jean-Louis Giordano
@Jell
Nov 06 2017 12:49
@jolod yeah sorry went ahead, it kinda picked up more steam than I expected oO I'm not written that often
I don't think pareto is exactly applicable to running things I think? might not apply, you have to look at other things like running costs and lifetime expectations. Different thinking applies there also
but you can take into consideration the "running" / maintenance cost to your lifetime expectation of the thing you're building
(integrate over the expected lifetime of your product)
say if technology A reduces maintenance costs by 50%, and your product has a lifetime of 5 years and a particular cost of delay (not putting it out is more expensive than maintening it afterwards)
basically you try to convert everything in terms of "money per unit of time"
then you can integrate over the expected lifetime
it's hard to carry all that knowledge in a few gitter comment though
Jean-Louis Giordano
@Jell
Nov 06 2017 12:55
(or a lengthy blog post for that matter :p)
@jolod I was actually "inspired" by the reaction to that rich hickey talk
like the talk itself did not provide anything new
but the reaction to it was unexpected
then I watched it and I thought the delivery was too antagonising
and then some other posts follow that were too apologetic
and I thought I could try to put another spin on it
but I think it was a bit of hubris because I think I might have made things worse?
felt like trying anyway, also forces me to put thoughts down more clearly
Magnus Therning
@magthe
Nov 06 2017 13:00
@Jell what talk are you talking about?
Jean-Louis Giordano
@Jell
Nov 06 2017 13:00
keynote at the conj
jolod
@jolod
Nov 06 2017 13:00
@magthe The talk where Rich Hickey says that types are an anti-pattern, iirc.
jolod
@jolod
Nov 06 2017 13:02
Yupp.
Jean-Louis Giordano
@Jell
Nov 06 2017 13:02
yeah
I was bothered by the way he said many of the things
and I'm always always bothered when people either put Haskell with C++ or Clojure with Python
I'm really bothered that individual features are not investigated in isolation
jolod
@jolod
Nov 06 2017 13:04
@Jell I don't know if it was more antagonising than usual. He's had the same delivery about TDD (bumping between guard rails), about OOP in general. Mutable state (incl. databases).
Jean-Louis Giordano
@Jell
Nov 06 2017 13:05
yeah I don't like his delivery in most cases
(from that perspective)
obviously you don't end up writing your own lang without being super opinionated
but not an excuse
jolod
@jolod
Nov 06 2017 13:06
Maybe the reaction got stronger because the types debate relate to ALL programmers, whereas immutable data only FP people care about. TDD stirred up things a bit as well, I think, and TDD is something every can have an opinion about.
But TDD is not as polarized, since most people agree that some tests are good. It's a matter of how much, or when. But static types are either or.
I don't know how people reacted, but I suspect that some people missed the point. That Clojure, and the comments about types, are in the context of "situated programs" or whatever he called it.
Jean-Louis Giordano
@Jell
Nov 06 2017 13:09
yeah...
it's just sad to me that static typing has to be either absolutely good or absolutely bad
and you're right that what he was saying was in the context of "situated programs"
but was still how types were "absolutely bad"
jolod
@jolod
Nov 06 2017 13:13
I think you're pushed to an absolute position because you either have static types, or you don't. (I know, gradual typing, but in e.g. Clojure core.typed didn't really catch on, and the only company I know that embraced it eventually abandoned it.)
Jean-Louis Giordano
@Jell
Nov 06 2017 13:14
yeah you can't have gradual typing without runtime contracts at the boundary otherwise the whole thing is unsound
and runtime contracts have runtime costs
jolod
@jolod
Nov 06 2017 13:15
@Jell (Unless you turn it off when you don't want that cost.)
Jean-Louis Giordano
@Jell
Nov 06 2017 13:15
right
hum on the other hand you make me think a bit @jolod
because people do love typescript
which is like javascript + types
even though it's added afterwards
is there something there?
like some insight?
jolod
@jolod
Nov 06 2017 13:51
@Jell Don't know. People seem to really come together is their dislike of JS, so it doesn't really relate to whether types are "good or bad" in the right context. Or, asked differently, can the (argued) benefits of types be realized without types?
Jean-Louis Giordano
@Jell
Nov 06 2017 13:52
I mean even just making it on "types or no types" instead of static verification and how much you verify is a bit frustrating
it would be cool to be more specific in terms of static verification of properties
instead of vaguely stating "you can express as much as you want in the type the rest you test"
(which I absolutely agree with)
Jean-Louis Giordano
@Jell
Nov 06 2017 13:57
dunno there's an understanding I'm after that I don't seem to fully reach
jolod
@jolod
Nov 06 2017 14:05
@Jell Btw, I'd rather not get drawn into the war, but ... ;-) I agree with @ocramz that the refactoring comment is often not addressed from the dynamic typing camp, and very often touted from the static typing camp. But I think that too is in need of a bit more nuance. In my fairly limited experience, the larger/more central the refactoring, the more the types get in the way. It's not easy to attack the refactoring piece by piece as you could without static types. It's easier to comment away/not run the tests for the knowingly broken parts.
Jean-Louis Giordano
@Jell
Nov 06 2017 14:09
yeah I agree, I would really really love to see better/clearer trade-offs being expressed in that domain
I think it's go hand-in-hand with all the tiny refactoring you have to do that you wouldn't need to do in a dynamic lang as well
jolod
@jolod
Nov 06 2017 14:10
@Jell Example?
Jean-Louis Giordano
@Jell
Nov 06 2017 14:11
hum... let's see: if you need to change something from a list to a set maybe for performances?
and you used list everywhere because convenient and expressive
it depends on the languages I guess
changing that type would not matter in say clojure, but you'd have to add some tiny tweaks here and there in haskell?
Magnus Therning
@magthe
Nov 06 2017 14:14
why can you change it in Clojure without code changes?
Jean-Louis Giordano
@Jell
Nov 06 2017 14:14
not code change
like...
not as much change?
Magnus Therning
@magthe
Nov 06 2017 14:14
I thought you were talking about chaning the type, without chaning the code consuming it? like list -> set
Jean-Louis Giordano
@Jell
Nov 06 2017 14:14
you'd need to go from Lists of things to either Sets of things or monoid in haskell
jolod
@jolod
Nov 06 2017 14:15
@Jell That's a rather niche example though, given that it exploits a core design choice of Clojure, i.e. the seq abstraction.
Jean-Louis Giordano
@Jell
Nov 06 2017 14:15
right, sure, I'm sure there are other examples
but that's also like the core thing of clojure
jolod
@jolod
Nov 06 2017 14:16
I mean, it's literary one of the reasons Clojure was created. To half-quote Rich: "Lists are not a good data structure. I'm sorry, it just isn't." :-)
(In context of why another lisp was needed.)
Magnus Therning
@magthe
Nov 06 2017 14:17
you mean there are other examples where Clojure has decided to implement an implicit interface on several types, allowing you to switch between exactly those types?
Jean-Louis Giordano
@Jell
Nov 06 2017 14:17
If I'm understanding what you're saying it's kind of one of the driving principle?
that you have a very small "set" of types
that are very compatible and interchangeable to some extent
jolod
@jolod
Nov 06 2017 14:18
@Jell How do you handle if you go from a Maybe to an Either in Clojure. I.e. nil to some other representation. In Haskell both are functors, but Clojure has a lot to deal with nil, all from the data structures to the various macros that exists also in "maybe-form", like some->.
Jean-Louis Giordano
@Jell
Nov 06 2017 14:18
(especially if you consider each possible record its own type)
ok ok I'm not going too deep in this conversation
like there are cases where Haskell helps with refactoring
(because abstraction)
so I'm not gonna argue that
jolod
@jolod
Nov 06 2017 14:20
@Jell So you can write f >=> g >=> h, but in Clojure when you have written it like (some-> x f g h) you need to re-write a lot. Or write an either-> macro. So at this level, you can argue both ways.
Jean-Louis Giordano
@Jell
Nov 06 2017 14:21
sure, but arguing both ways is exactly one being not absolutely better than the other
which was the only thing I wanted to state
jolod
@jolod
Nov 06 2017 14:22
@Jell Sure, this was about having to do micro-refactorings in static which you don't need in dynamic. And there's also the opposite examples. It would be fun, but tedious, to catalogue these cases. :-)
Jean-Louis Giordano
@Jell
Nov 06 2017 14:22
yeah but it would be really interesting to do that and see some patterns / deeper understanding
like how row polymorphism plays in that space as well in terms of open designs
Magnus Therning
@magthe
Nov 06 2017 14:23
Am I alone in thinking that Rich Hickey uses a lot of words to basically say that age-old Python-thing: we're all adults here?
jolod
@jolod
Nov 06 2017 14:24
Yeah. Row polymorphism, as done in PureScript, really didn't turn out how I expected it. I'm not sure how I feel about it yet.
@Jell We really need to sit down and discuss in detail a Clojure pattern I encoded as a library. It's a bit unorthodox, but I think that since core.spec and Rich's emphasis on namespaced keywords of late, it might actually be considered as not totally unclojuresqe.
jolod
@jolod
Nov 06 2017 14:32
@magthe I think it's a little more than that. For instance, his point about "everything would be maybes" in a "information-centric situated program" (please, correct me with the term he uses).
(Btw, people greatly over-estimate adults. ;-))
Magnus Therning
@magthe
Nov 06 2017 14:40
Yes, I think that's the term he uses... and yes, people do overestimate adults!
I don't understand what his point about "everything would be maybes" is about.
There's an information processing layer, that's massaging the input into a "perfect form" that's fed to the logic layer... now, where would "everything would be maybes" fit in?
jolod
@jolod
Nov 06 2017 14:42
My interpretation: If you do a web request, and get a response, what does that response contain? Maybe the server does not implement some standard, but in your case you might not care. But to avoid you rewriting the web library the library must allow also broken (but usable) responses.
This is the situated part.
And information-centric.
:-)
So in my example, maybe a field is missing. Then you'd have to have that it's a Maybe, to handle the broken responses. Similarly for all data that you cannot guarentee that it's as it should, which makes for almost all data.
Magnus Therning
@magthe
Nov 06 2017 14:45
So, you pick a web library that's "generous on input".
jolod
@jolod
Nov 06 2017 14:45
Or maybe you're integrating another data source with old data, and then a field is missing. Now you must update your model so it can represent both, and thus turn this field into a maybe.
Magnus Therning
@magthe
Nov 06 2017 14:46
however, if that field is necessary for your logic layer, what does a lack of maybe buy you?
jolod
@jolod
Nov 06 2017 14:46
Even if you don't actually use that in this particular program.
@magthe The point is that most programs (or subprograms) don't need all the data.
Magnus Therning
@magthe
Nov 06 2017 14:46
indeed, but the data you DO need has to be there
jolod
@jolod
Nov 06 2017 14:47
Of course. But that's another issue.
Magnus Therning
@magthe
Nov 06 2017 14:47
Why?
jolod
@jolod
Nov 06 2017 14:48
It just is. It's two different things. One is about now needing to update your program because you have inconsistencies in data you don't use. Another is to detect that the data you need is missing.
Magnus Therning
@magthe
Nov 06 2017 14:49
So, that just falls back to the old be "generous on input".
If you chose a library that isn't, well, that's a bad choice.
jolod
@jolod
Nov 06 2017 14:49
Yes, I'd say that is a core design of Clojure.
@magthe So things that do not have "everything" in the record as Maybe's is a bad choice, which is his point.
And if you know that the system your working against is consistent, then you "don't need to care" about nils.
The programs we talk about are situated, i.e. they work in a particular environment. So they're not "supposed" to work in all context.
Magnus Therning
@magthe
Nov 06 2017 14:52
Maybe I'm just thinking about it differently.
jolod
@jolod
Nov 06 2017 14:55
The discussion about programming and programming languages tend to be about the program. Rich Hickey has several times made the point that in the view of the system, the program (and programming language) is just one component. The goal (for Rich Hickey, as I understand it) is not to write a program, but to build a system.
He also specifically does not talk about GUI-heavy programs. And that I find interesting wrt ClojureScript.
Magnus Therning
@magthe
Nov 06 2017 14:57
Do you have an example of a protocol where this actually becomes a concern?
jolod
@jolod
Nov 06 2017 14:58
@magthe I'd have to refer to Rich Hickey. :-) I don't build systems myself. I do a lot of situated programming though. (Pretty much 100 % of my work programming is like that.)
Magnus Therning
@magthe
Nov 06 2017 15:03

I just find it to be a strange statement... in my ears he's saying he either

  • has a protocol where everything is optional, in which case I wouldn't use Maybe (I'd use a Map, just like in Clojure), or

  • he has an implementation of a protocol that's broken in that it omits mandatory data (implementing a parser of a protocol that assumes that the peer isn't following the protocol and still produce something intelligable sounds like a problem that no language can help with)

jolod
@jolod
Nov 06 2017 15:04
(My home project is the opposite though, GUI-heavy and rather stand-alone (akin to a desktop app). And coincidentally I found Clojure less good a fit for that.)
Magnus Therning
@magthe
Nov 06 2017 15:04
some native-react thingie might help? ;)
jolod
@jolod
Nov 06 2017 15:05
@magthe Ah, so, he's saying that if you have a record, then every field would be a maybe. And this is the default in Clojure. So precisely point 1 above.
Magnus Therning
@magthe
Nov 06 2017 15:05
yes, so in a statically types language, use a map
jolod
@jolod
Nov 06 2017 15:06
@magthe But a map is typically statically typed homogenously.
Hence records, right?
Magnus Therning
@magthe
Nov 06 2017 15:07
true, so you're saying that your protocol doesn't specify the types of the values sent over?
jolod
@jolod
Nov 06 2017 15:07
I am?
I'm really confused.
How do you put { foo :: Maybe Int, bar :: Maybe String } in a map?
Magnus Therning
@magthe
Nov 06 2017 15:12
well, {"foo": "seven", "bar": "hello"}, would be one way
jolod
@jolod
Nov 06 2017 15:13
Wait, which language is that?
Magnus Therning
@magthe
Nov 06 2017 15:13
but most likely I'd have a custom type PInt Int | PString String | PError String, and I could then have {"foo": PError "seven", "bar": PString "hello"}
jolod
@jolod
Nov 06 2017 15:14
So intead of Maybe you have another type. I think that doesn't change anything wrt the point.
Magnus Therning
@magthe
Nov 06 2017 15:15
If there are well-known keys, I'd create a type PKeys = Foo | Bar | Other String, and I could have {Foo : PError "seven", Bar : PString "hello", Other "Baz":PInt 42}
Well, my argument is that there really isn't a point there to begin with ;)
jolod
@jolod
Nov 06 2017 15:16
I think so. Instead of having { foo :: Int, bar :: String } you need to wrap and juggle to get to the data, because you need to handle the imperfections of the outside world.
Magnus Therning
@magthe
Nov 06 2017 15:16
in what way would you NOT have to handle the imperfections of the outside world in Clojure?
in my example foo isn't an int, how would that be encoded in Clojure?
jolod
@jolod
Nov 06 2017 15:17
I think that's precisely the point. And why Clojure has nil as default.
Magnus Therning
@magthe
Nov 06 2017 15:17
well, you still have to handle the nil!
jolod
@jolod
Nov 06 2017 15:17
Yeah.
I think Rich's point is that you first need to write a (relatively) elaborate data model to handle imperfections, which will permeate throughout your program, and then still need to case against it.
Just case against nil instead.
... is the argument.
Magnus Therning
@magthe
Nov 06 2017 15:19
Yes, that seems to indeed be the argument... I'm just failing to see that as a good argument... it seems, to me, like arguing that NullPointerException is a good thing!
jolod
@jolod
Nov 06 2017 15:20
Not at all.
Magnus Therning
@magthe
Nov 06 2017 15:20
How so?
Also, most languages do have catch-all cases, otherwise, default, etc (even though their use often is frowned upon)
jolod
@jolod
Nov 06 2017 15:25
Now, I'm the wrong person to argue the benefit of NOT having checks that you match against all cases, but that's not the point. The trade-off here is that you need to work more in one end, to not have to do "data type gymnastics" (such as the one you proposed above) in order for the program to be useful in contact with the rest of the system.
Magnus Therning
@magthe
Nov 06 2017 15:27
Indeed... but isn't that just a switch for another kind of gymnastics?
jolod
@jolod
Nov 06 2017 15:27
Not really. Because as I said, you might not need to do the nil gymnastics if you know your system.
So the language does not impose it into you and your program.
Might the program break in the future? Yepp.
Magnus Therning
@magthe
Nov 06 2017 15:28
But if the data type comes from a library... you don't have to write it yourself, you just have to consume it... and consuming a string from PString is just as easy as consuming a string from an untyped map, no?
jolod
@jolod
Nov 06 2017 15:28
Will the statically typed version also fail? Probably.
When would you consume your PString?
Magnus Therning
@magthe
Nov 06 2017 15:31
When I look up Foo in my map... the same as looking up :foo from my map in Clojure
magthe @magthe is feeling slightly contrary today :)
Jean-Louis Giordano
@Jell
Nov 06 2017 15:38
I think if you follow this line of though: if you know it won't happen in practice, and you have to deal with that case because of the uncertainty, you're handling a useless case. When handling that unexpected case what will you do? you loudly fail somehow at runtime
like really, if you have a Maybe that you know is alway a Just in practice and never expect a Nothing at runtime, what do you do when the Nothing happens
Magnus Therning
@magthe
Nov 06 2017 15:42
@Jell are you talking about missing something needed?
Jean-Louis Giordano
@Jell
Nov 06 2017 15:42
in that example yes
Magnus Therning
@magthe
Nov 06 2017 15:42
OK, then I'm with you
And where the Nothing/nil comes from doesn't matter much... whether you have a record with Maybes, or a map where lookup returns Nothing doesn't really matter
(In Clojure you'd have a map missing a key, that gives nil, in typed languages you'd have a map missing a key, that gives you Nothing.)
Jean-Louis Giordano
@Jell
Nov 06 2017 15:44
yes something like that
Magnus Therning
@magthe
Nov 06 2017 15:45
And the presence of unneeded stuff is handled as well.
I feel like it's a case of "måla fan på väggen" :)
Jean-Louis Giordano
@Jell
Nov 06 2017 15:47
I'm afraid I don't know that idiom :p
Magnus Therning
@magthe
Nov 06 2017 15:47
"assuming the worst"
jolod
@jolod
Nov 06 2017 15:48
@Jell @magthe Sorry, was away a bit. So yes, that's what I meant by the static version would also probably fail. Because what you do is that you cannot calculate something. If you know how to calculate it when missing, then you would have the nil check (ideally) in the dynamic version.
Personally I love Maybe and even think that Either is under-used.
Magnus Therning
@magthe
Nov 06 2017 15:48
Still, it's fun to watch his talks. Always something thought-worthy/-provoking, even though I don't always agree with him.
Jean-Louis Giordano
@Jell
Nov 06 2017 15:49
I truly love Clojure AND Haskell
jolod
@jolod
Nov 06 2017 15:49
But for certain domains, the Maybes and the Either are just noise and extra work.
Jean-Louis Giordano
@Jell
Nov 06 2017 15:49
but it's important to be critical of the stuff you love
jolod
@jolod
Nov 06 2017 15:51
There's one thing though that I think I would prefer in Clojure, and that's for the default to be to complain when you access a missing key. There's already a good version with the default, and that is (get m k nil).
If I want nil as a default, I can make it explicit. It's easier than guarding against it.
I can also have other defaults.
Jean-Louis Giordano
@Jell
Nov 06 2017 15:52
yes I strongly agree with you on that one @jolod
jolod
@jolod
Nov 06 2017 15:53
The same for update. assoc-in is a bit trickier.
@Jell As I said, I'd really like to get your input on my library. It's so very related to these topics. :-)
Jean-Louis Giordano
@Jell
Nov 06 2017 15:57
yes let's allocate some time maybe next week??
in Berlin for the week
(new Zimpler office!!)
jolod
@jolod
Nov 06 2017 15:57
Nice!