Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 02 23:58
    @SethTisue banned @fakubishes:nerdsin.space
  • Dec 15 2021 05:01
    som-snytt commented #12516
  • Dec 15 2021 04:38
    SethTisue edited #1312
  • Dec 15 2021 04:38
    SethTisue opened #2273
  • Dec 15 2021 04:31
    jackkoenig opened #12516
  • Dec 15 2021 04:29
    SethTisue edited #1312
  • Dec 15 2021 04:28
    SethTisue edited #1312
  • Dec 15 2021 04:27
    SethTisue labeled #9831
  • Dec 15 2021 04:27
    scala-jenkins milestoned #9831
  • Dec 15 2021 04:27
    SethTisue labeled #9831
  • Dec 15 2021 04:27
    SethTisue opened #9831
  • Dec 15 2021 03:35
    som-snytt commented #11339
  • Dec 15 2021 03:27
    som-snytt labeled #12494
  • Dec 15 2021 03:07
    SethTisue edited #1312
  • Dec 15 2021 03:07
    SethTisue edited #1312
  • Dec 15 2021 03:05
    SethTisue edited #1312
  • Dec 15 2021 03:05
    SethTisue edited #1312
  • Dec 15 2021 03:05
    SethTisue edited #1312
  • Dec 15 2021 02:58
    SethTisue edited #1312
  • Dec 15 2021 02:58
    SethTisue synchronize #1312
Fabio Labella
@SystemFw
wait a min
but basically when you pattern match on an Option you are checking to see if a value of type Option[A] has class Some or None
the problem is that most OO languages mingle these two aspects
trepidacious
@trepidacious
But Some and None are also types?
Rich
@Rich2
I've long thought that "objects" in "object orientated" are misnamed. They usually mean smart objects that have self knowledge as opposed to dumb data. Smart object is a bit of an oxymoron.
Fabio Labella
@SystemFw
so Some defines both a type Some and a class Some
trepidacious
@trepidacious
Yup
So every class defines a type, but not every type is a class
Fabio Labella
@SystemFw
from the article:
All of this is simply to say that we must be working with two separate concepts here.

The runtime shape and properties of the values that end up flying around when a program actually runs. This we call class.
The compile-time, statically-discoverable shape and properties of the expressions that fly around when a program is written. This we call type.
which should resonate (with some differences) from the talk about types and tags
trepidacious
@trepidacious
My opinion on OO is probably completely facile, but I really think the good bit is syntactic sugar and name-spacing, everything after that is normally a bad idea
@SystemFw Yes the compile-time / run-time distinction definitely makes sense
Rich
@Rich2
Pattern match on AnyRef should be a different function to a match on an Int or or Double. I don't think they should even have the same syntax.
Jose C
@jmcardon
omg
what on earth is happening with gitter
@SystemFw same thing in the scalaz room now
Fabio Labella
@SystemFw
it's been two days of hell
trepidacious
@trepidacious
@jmcardon I've not seen anything weird, what's up?
Jose C
@jmcardon
it shows 1 unread message but there's nothing there
Fabio Labella
@SystemFw
ghost notifications today, dropped messages yesterday (and who knows now)
Martijn Hoekstra
@martijnhoekstra
I've had dropped messages today as well
Jose C
@jmcardon
I've had it all weekend
dropped messages that require a gitter refrehs
trepidacious
@trepidacious
Maybe it's when they filter out the coin-mining :)
Rich
@Rich2
I think inheritance is a great idea, but primitive value types should not inherit.
Jose C
@jmcardon
I don't. There's other methods for code reuse
Fabio Labella
@SystemFw
@trepidacious Note that this is still relevant to scala: a lot of people for example expect to be able to resolve an implicit based on the class of something, whereas you can only do it on the type
Rich
@Rich2
Dumb data should not be confused with smart objects.
Jose C
@jmcardon
"smart objects" are, in practice, not smart but rather fickle and brittle
Fabio Labella
@SystemFw
so if you have a value of type Option and an instance for Some, you need to have the value to have type Some
OO means basically nothing, btw. And the only slightly coherent definition comes from languages like SmallTalk that have nothing to do with Java or Scala
Jose C
@jmcardon
Means nothing to you
Fabio Labella
@SystemFw
true :P
Jose C
@jmcardon
Loads of academics will debate with you on this.
Rich
@Rich2
Smart objects should be used for less numerous, larger, longer lasting pieces of data, while dumb data should be used for numerous, smaller, transient data.
Jose C
@jmcardon
but it's unreal how the OO part is never really debated
Martijn Hoekstra
@martijnhoekstra
subclassing and dynamic dispatch seems pretty core to OOP-in-practice
Jose C
@jmcardon
I'm fine with not holding state in "smart objects" at all
and the only design pattern I conciously use, and very occasionally, is the builder pattern
I have to write some java currently, and the design decisions made with pure OO as the codebase grows become awful.
coupled hierachies, overrides everywhere, config hidden in factories.
I'm half-waiting for @Ichoran to disagree with me here whenever he gets on, but from my experience in working with other people writing OO it just becomes a mudfight
like building a mud hut where you find some structural weakness somewhere and you patch it by slapping more mud into it.
trepidacious
@trepidacious
@SystemFw I disagree on OO meaning nothing, I think there is one useful syntactic thing that always seems to go with objects - being able to associate a function f with a type, and call f a b as a.f b
Rich
@Rich2
Is there even a single major game that's been written without mutation?
Jose C
@jmcardon
I Don't think so. FP isn't prevalent in game programming
trepidacious
@trepidacious
@SystemFw I'm probably wrong because I know so little about Haskell, but it seems for example like having a top-level function for accessing fields of a record type is really really annoying. Purescript seems to have decided to just have the dot notation for fields thing anyway.
Jose C
@jmcardon
there's also the duality that all the thunking in FP makes it hard to reason about performance
which is in particular why performance critical applications aren't written in haskell most of the time