not specific to OO, I like the concept of having standardised functions to update common files/variables/objects because if I need to change the structure of the data, I only need to make changes in one place as opposed to all over the code. it's not mandatory or anything but it's a good idea.

Sure, sure, separating what from how as important in FP as OO. I mean that was even a big lesson of structured programming. But there's a certain trend towards this rigid kind of runtime enforced access restriction that flows forth from the Java world and informs most of what we call OOP today that goes a lot further than that. Like some things really are just fields, and you're never going to need to inject code into accessing them. I think there's also this risk of expanding access methods to do more than they should.

Like I was reading this dude's code the other day and he had this setter that just did your normal set but then it checked the value afterwards and if it met a certain condition it would call something else and there's be this big call chain and the state of the whole program is up in the air when you're just trying to set one field. It gets to a point where enough information is hidden from you that you can't reason about how a program works anymore. Which is to say, that example was a bad design to start with and most OOP people could tell you that, but I think having those dumb getter/setters laying everywhere makes it much easier to make that mistake than if you were just passing around a value or something.

HAHAHA
what's up wit dat?

Nothing, just like every other day. Oh, I didn't know it was today, I thought it was tomorrow. Hadn't checked since holidays don't really mean anything if you have absolutely no one, not even a pet, to spend them with.

“I am gone quite mad with the knowledge of accepting the overwhelming number of things I can never know, places I can never go, and people I can never be.”

― Sylvia Plath, The Unabridged Journals of Sylvia Plath

Chronic severe depression, death by suicide. You just start seeing all these signs everywhere, stories of or writing from people who were in the process of losing their minds and barreling towards suicide, and you realize how it parallels your own life, when you've had similar experiences, thoughts. "The same thing is happening to me."

Have you read Under the Bell Jar? It's Plath's best work IMO but also def her most depressing sans a few short stories that may be harder hitting but don't have the volume/length to hit home as much as Bell Jar does. A peripheral member in this community (toraron) introduced me to Plath and to this day I think she's my favorite English language authors. I'm convinced that if you have a depressive personality Under the Bell Jar will make your life, at minimum, more comfortable. It exposed, to me at least, the sublime beauty of the hopeless soul. It exposes how when every thing is bad somehow there's an aesthetic beauty in that that transcends the traditional sense of self, and for some at least, show how suffering is actually the greatest aesthetic pleasure there is idk i dont really know what im saying but read her shiut Plath is a genius and you'd like her

I think there's some like sigma notation that can be collapsed into a none-recursive algebraic expression for this. Like it's fucking SIGMA n=14 from i=0 i*1.15 and then the amount of jizz an adolescent can produce per anum is weighed against this in conclusion sperm banks don't seem very lielkely to produce asperm profit if you konw what i mean

Yea. About time to take a new picture of myself. I am really starting to degrade.

Aww, I remember when you were just a yun'un nordic something something token northern european. You should post more m8.

anybody want there turkey stuffed?

great post, I approve, anyone who hasn't posted ITT grinning with a raging boner and full frontal nudity is a huge faggot.

Impressive. Javascript is truly versatile as fuck...

Yup. It can bite you in the ass for sure, but for all the terrible things about JS it can be really fun sometimes.

As to why I don't just access them directly obj->name or obj.name, I was told that is bad practice as it ends up fucking you on larger projects, not sure how but getters/setters must be a thing for a reason.

That is... an opinion that some people hold and for which seemingly convincing arguments can me made. There is a long running clash of ideologies in programming and the whole getters/setters thing is one paradigmatic place where that gets played out. There's the notion of "information hiding" that's really near and dear to people in the OOP world. The classic example that's supposed to illustrate this point involves rectangles (other shapes will do, but area is easy for rectangles):

function Rectangle(width, height) {
  this.width = width
  this.height = height
}

Rectangle.prototype = {
  getWidth: function() { return this.width },
  getHeight: function() { return this.height },
  getArea: function() { return this.width * this.height }
}

function CachedRectangle(width, height) {
  this.width = width
  this.height = height
  this.area = width * height
}

CachedRectangle.prototype = {
  getWidth: function() { return this.width },
  getHeight: function() { return this.height },
  getArea: function() { return this.area }
}

The notion here is that an instance of Rectangle can be substituted for CachedRectangle with no changes to any code so long as the getters are the only thing that's being used. This is a hedge which is supposed to save you programmer time if you decide that it's better to precompute area or whatever. And the example works, if you're using properties directly you really couldn't substitute one for the other without issue (well actually with ES6 you could, but being charitable (and practical, for the immediate future) that's irrelevant).

I'm not really a fan of the philosophy that informs people making this argument. I think this is a pretty example but in my experience at least (and it seems like others have the same experience) there is a tremendously greater amount of effort spent on other things like managing mutable state or concurrency issues than there is on swapping out implementations of equivalent abstract data types. In fact I'd argue more time is actually spent in writing these dumb getter/setter methods than is saved by them.

I'm pretty opinionated on the subject though, and it's worthing noting that the OOP approach (in favor of getters/setters on everything) is more popular today (in terms of numbers) than competing views. I think the important takeaway is that you should assess the situation for yourself, there is a strong enough argument for either position that which ever way you think is best, so long as it's based on evidence, is justifiable.

Nerds

u jelly JELLYFISH.JPG

So I've been doing a pretty big refactor of some client side code at work and one (among many) of the things I'm trying to achieve is a somewhat more functional/declarative style. I noticed that in doing this I had a lot of code that looked like this:

var foo = 42
foo = f1(foo)
foo = f2(foo)
foo = f3(foo)

// or
var foo = f3(f2(f1(42)))

neither of which are particularly pretty, so I wrote a nifty little way to manage function composition:

    function uOr(value, alt) { return (value === undefined) ? alt : value }
    function toArr(arrLike) {
      var result = []

      for (var i=0; i<arrLike.length; i++)
        result.push(arrLike[i])

      return result
    }

    function Chain(data, fnStack) {
      this._data = data
      this._fnStack = fnStack || []
    }

    Chain.prototype = {
      exec: function(data) {
        data = uOr(data, this._data)

        for (var i=0; i<this._fnStack.length; i++) {
          var args = this._fnStack[i].slice(0),
            fn = args.shift(),
            ins = args.pop()

          if (ins) args.unshift(data)
          else args.push(data)

          data = fn.apply(this, args)
        }

        return data
      },
      _push: function(insert, args) {
        var newStack = this._fnStack.slice(0)

        args.push(insert)
        newStack.push(args)

        return new Chain(this._data, newStack)
      },
      ins: function() { return this._push(true, toArr(arguments)) },
      app: function() { return this._push(false, toArr(arguments)) },
    }

So it's just a data structure that maintains a stack of functions that will be applied to and some magic to do a poor man's function currying. So you can do stuff like this:

>new Chain(42)
  .ins(function(x) { return x + 2 })
  .ins(function(x) { return x + " is really old" })
  .exec()
"44 is really old"

which is somewhat more manageable when you have a lot of functions in the lineup, and it looks similar enough to jQ's selection chaining that JS programmers seem to be able to grasp it. One of the cool things though is that data can be given at the end of the chain too:

>var sumOfSquares = new Chain()
  .ins(map, function(x) { return x*x })
  .app(reduce, function(x, y) { return x + y })
undefined
>sumOfSquares.exec([1, 2, 3, 4])
30
>sumOfSquares.exec([42, 31, 94])
11561

Chains are also immutable (well, so far as anything in JS is)

>var squares = new Chain().ins(map, function(x) { return x*x })
undefined
>var sumOfSquares = squares.app(reduce, function(x, y) { return x + y })
undefined
>squares.exec([1,2,3,4])
[1, 4, 9, 16]
>sumOfSquares.exec([1, 2, 3, 4])
30

This is probably just a boring language feature to anyone working in an actual functional language, but it was fun to write and since there's no real equivalent notation in JS I find it's pretty useful in my day to day work