@Snowman FYI, there is a whole bit in Freakanomics about how the total mortality rate walking short distances drunk is higher than driving the same distance drunk.

speaking of drunk

\o/

expensive boxers anyone?

amazon.co.uk/Kathmandu-Merino-Blend-Boxer-Shorts-y/dp/…

^^^ trying very hard to abstain of recommending BDSM

Hey folks.

hey

How you doing, Ixrec?

fine

and you? (nothing interesting going on over here)

Typical lazy saturday. Wife is out with the son getting her mani with a friend or whatever. So I'm just chilling in pyjamas.

looks like we've got a spammer: programmers.stackexchange.com/users/212355/john

had two great optimisation ideas as I went to bed last night

can only remember one of them and I'm not even convinced now that it was all that great

alcohol's a wonderful drug

Boy, I have done literally nothing productive today.

@DavidPacker it's still morning for me, presumably it's evening for you :-)

@enderland 5:30 PM here. Where are you from? The US?

@DavidPacker yup

@enderland Oh. :)

lazy saturday mornings are probably my biggest luxury in life

@enderland Saturdays are usually the only day of week where I have literally no work responsibilities as well, but today I was not even out of the house :D.

:)

@MichaelT My wife and kid hop on a plane to North Carolina tomorrow morning

enderland is doing taxes

So this week I closed a merge request by a PHP developer containing returning a plain two dimensional array simulating a DTO out of a method instead of an object implementing the Iterator interface, so you could get type-hinting later in the code. His reasoning: "It's too much of a hussle and sacrificing readability is not that big of a problem." Do you guys think it is too much sacrificing a few minutes by creating a new object in sake of better readability later?

@DavidPacker When I write code in a language with a usable type system that allows me to easily define new types, I have types everywhere. I love that the compiler helps me ensure correctness.

In dynamic languages, nominal types are worthless. Objects are still useful because all of the wonderful stuff OOP provides, but they add little documentation, little safety, and more often than not get in the way. If a function returns an associative array, that might be better and more maintainable long-term than definining a custom class. Would you ever need that type-hinting for the return value?

Balance YAGNI versus clean code versus overengineering.

@amon Later in code another method is supposed to perform foreach within foreach on the returned array and work with the values, so you have to remember the indexes which are actually in the array. I don't like you being forced to remember, what is actually in the array. The IDE should give you a hint, should it not?

Naturally I know not everybody works using an IDE, that's just my experience.

Could you give an example of the data? ["a" => 42, "b" => [1, 2, 3], "c" => "foo"] is fine, whereas [42, [1, 2, 3], "foo"] is not, because the resulting code isn't self-documenting. Except in the most trivial cases (3 or fewer items or clear connection to the problem domain), tuples without named fields are a bad idea. With associative arrays, the structure is clearly visible in the using code.

@amon Sure, wait a moment.

@amon The data is only for placeholding, the structure looks to something like this. pastebin.com/Wk0eRPc7

@amon +1, I was going to say, in languages that don't enforce type safety, types become a totally tertiary piece of documentation for me.

@DavidPacker hmm, I could argue that one either way. The most likely candidate for objectification would be the prices value since that looks like something that might see custom behaviour or values calculated on the fly. On the top level, it isn't clear what the keys are. Unless these are used to look up a record, they should be part of the record.

The whole point of types is type safety. You don't need types to get all the benefits of encapsulation, separation of concerns, code reuse, etc. If you have a language that gives type safety then use them for that.

@JimmyHoffa That's why I like languages with static typing, they don't let you do the shit a PHP or JavaScript would.

@DavidPacker that's kind of a lame reason that everyone uses - it lacks substance

Don't like or dislike languages just because everyone says things to be members of an in-group with a rah-rah-rah slogan.

@JimmyHoffa I don't quite follow. What do you mean by that?

"it doesn't let you do shit PHP or JavaScript would" identifies absolutely no substantive point for or against type safety

@JimmyHoffa You can return null from a function in PHP, which is annotated to return bool. That's just wrong.

The counter-argument to “languages without type safety suck” is “languages with types are too restricted to be useful”. Yesterday, I lost an hour because C++'s std::function cannot be move-constructed from an rvalue function object. That type system is so difficult to use that even the people writing the standards are not capable of designing interfaces without unnecessary restrictions.

@DavidPacker and "That's just wrong." is just an ad hominem argument. I like type safety, but don't much care for rah-rah-rah arguments. Explicate particular things that cause problems why / how and you'll be better off for it. Everyone repeats rah-rah-rah crap without looking closer to their own detriment.

but … that was a real problem: type annotations lie, or lack good rules for nullability. Of course, within the rules of that type system, this behaviour might be totally fine. In fact, many statically typed languages share that problem: when I return a Boolean in Java, the same problem occurs ;-)

In JavaScript if I want a piece of functionality to be reused easily in different scenarios, I don't meddle with types because the type system's a wreck, I just write a var createCalculator = function(base) { var calculator = {result: 0}; calculator.add = someAddFunctionCreator(base, calculator); calculator.subtract = someSubtractFunctionCreator(base, calculator); return calculator; }

you don't need a type for a constructor, and with such a terrible type system you're better off avoiding them

@amon true enough. Many languages will let you return null from anything though; if I recall correctly the Eiffel creator who is creditted with the NPE concept feels harribly guilty for having done so heh

@JimmyHoffa The argument is because language does not have a types, you sometimes end up returning values which, in a typed language, you would create an object for instead, because returning it that way would be very difficult.

@DavidPacker objects are awfully overused and vastly overrated IMO. Primitives are far better choices everywhere possible.

@JimmyHoffa When you need to return more than one value from a method?

@DavidPacker It's nice when a language has a tuple primitive, they don't always. Creating an arbitrary type that's barely going to be reused will get in the way of reuse where a primitive tuple or keyvaluepair would enhance the reusability of the piece of code

@MichaelT Could be anything, string, int, float, int, int, string, perhaps.

lots of languages don't have a natural tuple/pair type though unfortunately

@MichaelT In that case, could be name, number, value, length, age, address, in that specific order.

@DavidPacker now you have a semantically meaningful composition, and this is likely going to provide value to your code overall. Doesn't necessarily need a type, but I would at the least create a constructor function that generates a consistent object for it. In a typeful language I'd create a type for it, this can be seen as a "domain object" or "domain record" as it's a composition of data that is meaningful in the problem domain you're working within.

@JimmyHoffa So you think that returning that as a raw array, although the language supports it, might necessarily not be the best approach? To add, because I think it should be an object. My developer thinks an array is fine.

@DavidPacker depends. Like I said, if it were a language with a reasonable type system I'd use it, when languages have unreasonable type systems I avoid them for they typically cause more headaches than value. That said, an associative array provides growth potential a fixed object does not. I've used an associative array for communicating person-registration-data before specifically so that the client or server could add / remove fields without breaking eachother's compatibility.

I see.

@DavidPacker as I said above, think through the implications of things, don't just repeat the ideas you've read/heard. Every problem is worthy of it's own solution specific for it, utilizing the same approach / solution for every single problem instead of trying to think through each scenario individually is how most software ends up the mess it is.

(that said I may use an actual object for the scenario you described above, but I don't frankly know the PHP type system well enough to have any stance on correct/incorrect uses of it)

@JimmyHoffa PHP is much like JavaScript, type-wise. Perhaps a little bit stricter, when it comes to passing an object to a function.

got my computer working - finally

old board had a friggin bent pin

needless to say I'm a little upset about that

yeah. A week later

now I have to get windows re-activated

ugh

then I can reset back to base - and then I can be done for a few weeks til I get my waterblocks for the GPUs in

dang these new e-haswell processors sip power when not in use

idling at ~4W consumption for the processor

is it too late to just buy a new computer?

@Duga Deleting his only answer along with it. Sad times.

love the BBC

lol that's great

@Ampt old board? You mean the new one that wasn't working? Or was a bent pin on your old board one of the main reasons you were trading up anyway?

BTW Rocket League's on sale