|
Gazpacho posted:hoare is wrong, null is good what a terrible post. the worst
|
# ? Sep 25, 2016 19:27 |
|
|
# ? May 18, 2024 14:39 |
|
null is much more than a billion dollar mistake under generous back of the envelope estimation
|
# ? Sep 25, 2016 22:08 |
|
JewKiller 3000 posted:what a terrible post. the worst nice sig i wrote a perl script this weekend. it was far less bad than i remember.
|
# ? Sep 25, 2016 22:08 |
|
i wish elm would just let you use nothing instead of the stupid maybe/just syntax
|
# ? Sep 25, 2016 22:58 |
|
hifi posted:i wish elm would just let you use nothing instead of the stupid maybe/just syntax not sure what you mean by this, elm maybes work pretty much the same as any other maybes
|
# ? Sep 26, 2016 00:01 |
|
Asymmetrikon posted:not sure what you mean by this, elm maybes work pretty much the same as any other maybes Yeah, nothing esoteric here: code:
|
# ? Sep 26, 2016 00:08 |
|
hifi posted:i wish elm would just let you use nothing instead of the stupid maybe/just syntax i dont think ive ever seen a more wrongpinion
|
# ? Sep 26, 2016 00:17 |
|
3 weeks into writing elixir full time and i dont want to write anything else ever again. i dont even care that it's dynamically typed, for some reason it doesn't seem to matter.
|
# ? Sep 26, 2016 01:00 |
|
Volte posted:3 weeks into writing elixir full time and i dont want to write anything else ever again. i dont even care that it's dynamically typed, for some reason it doesn't seem to matter. it's the pattern matching, it gets you most of the way there also dialyzer
|
# ? Sep 26, 2016 01:02 |
3 weeks into elixir n chill and your type system gives you this look ¯\_(ツ)_/¯
|
|
# ? Sep 26, 2016 01:28 |
|
welcome to BEAM town
|
# ? Sep 26, 2016 01:52 |
|
MononcQc posted:welcome to BEAM town
|
# ? Sep 26, 2016 01:59 |
|
i'm fine with having nothing be something you specifically use in elm but it feels like you get zero benefit having the just and maybe keywords instead of explicitly using nothing in your type definition. am i missing something? i guess, what more do you need beyond having nothing be a reserved type and making you have a clause for it whenever you use it?
|
# ? Sep 26, 2016 02:49 |
|
hifi posted:i'm fine with having nothing be something you specifically use in elm but it feels like you get zero benefit having the just and maybe keywords instead of explicitly using nothing in your type definition. am i missing something? i guess, what more do you need beyond having nothing be a reserved type and making you have a clause for it whenever you use it? Just and Maybe aren't keywords, they're values like everything else in Elm. If you didn't have Just, you'd have to let anything of type a implicitly coerce to Maybe a, which is really awful. I think you're thinking that Nothing is more special than it really is, perhaps? MononcQc posted:welcome to BEAM town it's pretty great my only complaint right now is having to do deployments to windows (wanted to use distillery, but it only has scripts for unix, so i'm probably going to have to write some powershell to start the thing)
|
# ? Sep 26, 2016 03:05 |
|
hifi posted:i'm fine with having nothing be something you specifically use in elm but it feels like you get zero benefit having the just and maybe keywords instead of explicitly using nothing in your type definition. am i missing something? i guess, what more do you need beyond having nothing be a reserved type and making you have a clause for it whenever you use it? do you mean instead of having a type like type Lomarf = Chome | Mome and then having a Maybe Lomarf value, you wish you could do type Lomarf = Chome | Mome | Nothing because you could do that right now
|
# ? Sep 26, 2016 03:20 |
|
fart simpson posted:do you mean instead of having a type like yes, but i was wondering if there was any reason why Maybe was such a killer feature
|
# ? Sep 26, 2016 03:23 |
|
the killer feature isn't the actual Maybe type, it's the type system itself and how the compiler checks for exhaustiveness the fact that the standard and community libraries actually adhere to the convention because in order to get the equivalent of an unhandled null value you literally need to type Debug.crash
|
# ? Sep 26, 2016 03:24 |
|
the only benefit of using the built in Maybe type over defining your own versions of it is you get all the map and andThen and withDefault type functions in the standard library already implemented
|
# ? Sep 26, 2016 03:26 |
|
fart simpson posted:the only benefit of using the built in Maybe type over defining your own versions of it is you get all the map and andThen and withDefault type functions in the standard library already implemented that's a good point. you need that for those OOP-y interface operation things.
|
# ? Sep 26, 2016 03:31 |
The other advantage of having type Lomarf = Chome | Mome and then having Maybe Lomarf, instead of defining type Lomarf = Chome | Mome | Nothing is that sometimes you will have a function which always returns a Lomarf (i.e. Chome or Mome), and sometimes you will have a function could return a Lomarf or which could return nothing. Having a Maybe Lomarf lets you distinguish these at the type level, and lets the caller know whether it can return Nothing just by looking at the type signature of the function.
|
|
# ? Sep 26, 2016 03:47 |
|
right - you want to limit Maybe values to as small a scope as possible, but you have to accept that they may happen sometimes for some things. so you don't want to bake Nothing into your types, because it'd be nice to spend a majority of your time assuming that the value does actually exist (and having to pattern match on Nothing all the time is tedious), but you need to have nullability sometimes. hence, Maybe
|
# ? Sep 26, 2016 04:11 |
|
Asymmetrikon posted:Just and Maybe aren't keywords, they're values like everything else in Elm. If you didn't have Just, you'd have to let anything of type a implicitly coerce to Maybe a, which is really awful. have you considered that, instead, it is cool and good?
|
# ? Sep 26, 2016 04:28 |
|
rjmccall posted:have you considered that, instead, it is cool and good? ive considered that, op. it's bad.
|
# ? Sep 26, 2016 04:34 |
|
rjmccall posted:have you considered that, instead, it is cool and good? nullability should remain explicit as a punishment to the programmer for adding a pseudo-bottom to their delicate artisanal type ecosystem
|
# ? Sep 26, 2016 04:35 |
|
Volte posted:3 weeks into writing elixir full time and i dont want to write anything else ever again. i dont even care that it's dynamically typed, for some reason it doesn't seem to matter. i wish i could write erlang full time, it's just so pleasant every time i pick it up
|
# ? Sep 26, 2016 04:48 |
rjmccall posted:have you considered that, instead, it is cool and good? Could you expand on that? I really don't see any downside to Maybes over nulls. It's not even really more typing, since knowing that a value can't be null/Nothing means you don't have to sprinkle in null checks everywhere. I guess syntactic sugar like C#'s .? can alleviate this, but you can have syntactic sugar for Maybes as well--see the proposed ? operator in Rust. Are you just saying that Foo should automatically coerce to Maybe Foo and not the other way around? I would disagree with that as well (I think type conversions should be as explicit as possible), but I could see arguing for that.
|
|
# ? Sep 26, 2016 06:54 |
|
type classes for .net http://www.mlworkshop.org/2016-7.pdf (extended abstract, not the whole paper) looks like a clever use of the existing type system
|
# ? Sep 26, 2016 07:38 |
|
using a Maybe-like type instead of pervasively nullable types has absolutely zero downsides and only upsides; there is not a single reasonable argument in favor of pervasively nullable types
|
# ? Sep 26, 2016 09:14 |
|
comedyblissoption posted:using a Maybe-like type instead of pervasively nullable types has absolutely zero downsides and only upsides; there is not a single reasonable argument in favor of pervasively nullable types Come now, this isn't true at all! Using explicitly nullable types makes me spend extra keystrokes and slightly more thought about whether a value can be null or not
|
# ? Sep 26, 2016 11:14 |
|
pedantic argument: nullable types (and by extension pointers) are an implementation of maybe types if there is a value, the thing is not null; if there is not it is null
|
# ? Sep 26, 2016 12:39 |
|
Mahatma Goonsay posted:after using some Haskell I never want to go back from Maybe and Either. either is terrible and left and right should have been named fnargle and blargle VikingofRock posted:Could you expand on that? I really don't see any downside to Maybes over nulls. It's not even really more typing, since knowing that a value can't be null/Nothing means you don't have to sprinkle in null checks everywhere. I guess syntactic sugar like C#'s .? can alleviate this, but you can have syntactic sugar for Maybes as well--see the proposed ? operator in Rust. presumably hes talking about swift , where the "maybe" is explicitly nullable types, and a non-nullable type can be assigned to a nullable type so you can write Swift code:
Swift code:
|
# ? Sep 26, 2016 13:12 |
|
suffix posted:either is terrible and left and right should have been named fnargle and blargle
|
# ? Sep 26, 2016 13:19 |
|
Charlie Mopps posted:I agree Left and Right makes no sense. Should have used good names. Right even kinda makes sense as in ''the Right answer'', so i guess they figured they needed the opposite for failure so that is of course Left. Either is not always used for error/ok values, and using Rust's result of Ok and Err always feels weird to me when talking about two different success cases. Then you end up defining your own ADT and you can't use any of the std machinery. I agree though that Ok/Err is far more common though. Haskell has the weird ErrorT which is kind of redundant with EitherT.
|
# ? Sep 26, 2016 13:31 |
|
leper khan posted:pedantic argument: nullable types (and by extension pointers) are an implementation of maybe types
|
# ? Sep 26, 2016 13:43 |
|
leper khan posted:pedantic argument: nullable types (and by extension pointers) are an implementation of maybe types Yeah, but the problem is that languages with nulls effectively make every type a maybe type by default.
|
# ? Sep 26, 2016 14:35 |
|
thank you all for beta testing these programming language features for those of us with jobs. i look forward to using the good features after you've filtered them out and they reach C#.
|
# ? Sep 26, 2016 15:15 |
|
GameCube posted:thank you all for beta testing these programming language features for those of us with jobs. i look forward to using the good features after you've filtered them out and they reach C#. it would be nice if they could remove nulls from c#, yeah. too bad that's basically impossible
|
# ? Sep 26, 2016 15:17 |
|
GameCube posted:thank you all for beta testing these programming language features for those of us with jobs. i look forward to using the good features after you've filtered them out and they reach C#. Shaggar alt account spotted
|
# ? Sep 26, 2016 15:45 |
|
Asymmetrikon posted:it's the pattern matching, it gets you most of the way there yeah, pattern matching and the convention of using a symbol as the first member in a tuple to indicate success imo erlang would probably be not nearly as nice without a really strong stdlib + the fact that the community follows OTP conventions. it makes non standard libs behave predictably. DONT THREAD ON ME fucked around with this message at 15:56 on Sep 26, 2016 |
# ? Sep 26, 2016 15:54 |
|
|
# ? May 18, 2024 14:39 |
|
gonadic io posted:Shaggar alt account spotted i mean this sincerely. i used to gently caress around with these toy languages and wonder which features were actually worth using and which ones would just be a waste of time. now i know: if a feature makes it into c#, it's worth using
|
# ? Sep 26, 2016 16:24 |