lmitchell

Hey now, don't make me sad. In my heart I still like to pretend that Discworld will always have more books to read :'(

This feels spectacularly Pratchett-esque. I would not be surprised to see this as the first sentence of a Discworld novel :P

Part of the message, aside from just quantifying how limited time is, would be to find enjoyment where you can in your 'mandatory' activities too as they'll represent the bulk of your life.

I wish I could give this comment more upvotes. I'm slowly learning this lesson in my personal life - I wish I could learn it faster, but the goddamn brain is just too much more insistent than the body..

The only thing 'unspecified' guarantees you in this context is 'safe to destroy'. It specifically does not guarantee the safety of any other member functions - only the destructor. So either push_back() or pop_back() could potentially cause UB here (specifically, it's quite possible that the move swaps some internal pointers for nullptr, so you end up dereferencing null here - but morally, it's just never okay to continue using a moved-from object).

Right, this is what I was alluding to with 'choosing what to feature'. But I honestly am not sure whether a line should be drawn here, and if it should, where it should be drawn. I know that one feels distinctly creepier than the other, though, so I'm sort of hoping someone chimes in and can clarify my thoughts better than I can :)

Aren't they different, though? When I go into a grocery store, the deal is, they put out a selection of things, I pick the ones I want, then I go home. This is actively trying to manipulate me personally into buying something that is not one of my original desires.

I mean, I guess grocery stores already do this in some ways, in choosing what to feature... they do effectively 'advertise' certain products. But this seems more like it's trying to manipulate my behaviours, rather than trying to fulfill my desires as well as possible. I'm not sure how different it is... but it feels a lot different to me.

'Ultron is designed with OOP in mind and has not failed to live up to the promise at all possible places.'

Would that more professional programmers had this humility. :)

I... definitely did not just watch this play itself for like five straight minutes...

I think I need to get more fresh air or something.

Presumably 'developer experience', given how it's used in conjunction with 'user experience' for a developer-focused product :)

Admittedly not the most easily understood acronym, and I'm sort of guessing.

I was convinced it would be something about realistic hair simulation and/or rendering.

I was surprised, but I was not disappointed.

Not gonna lie, I still can't parse what this is supposed to be after a number of readings. What's the actual sentence? I'm so curious :P

Thank you for posting this, I found it both very enlightening and a pretty fun internet-drama read :D

Interesting that the original complaint of that article/thread and this one are both the same - ie. quaternions are 'too hard to understand', and people 'use them without knowing how they work'. With this being posted so soon after https://news.ycombinator.com/item?id=18310788 , I feel like that complaint is less valid now than it ever has been, but it's kind of interesting to think about why quaternions in particular draw so much fire when, honestly, I found matrices to be equally challenging at first. Is it just an education thing, since matrices are generally taught much earlier? Or is there some intuition in matrices that isn't present in quaternions? Both of them seem to be just 'do this math, then magic happens' unless you think about them a fair bit, and that was pretty challenging for both the first time round imo.

So I've actually thought about this a fair bit recently, since I'm making some changes to C++ code that touch a lot of files in reasonably straightforward ways. The changes should be possible to merge conflict-free in basically 100% of cases, but since so many lines are touched, no VCS merge tool can manage it. Most of my changes are just typenames, so I figured, you could do some sort of AST-based merge to allow those changes to merge with semantic changes to the surrounding code.

But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines.

So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.

I really really hope this was a joke, because it was incredibly funny if so and terrifying if not.

Shameless plug: At EA we've open-sourced our C++ standard library implementation that focuses on games. While it's not necessarily focused on embedded development, you might be interested in checking it out - it provides a number of fixed_* containers (fixed_vector, fixed_set, etc) which can be configured to use stack allocations only, among some other things you might find interesting :)

https://github.com/electronicarts/EASTL

(In case it wasn't obvious, disclaimer: I work at EA, and frequently do work on EASTL, though I'm not the primary maintainer.)

This ignores both the fact that RMS is much more than just the maintainer of glibc, and the fact that 'just forking' glibc doesn't stop the maintainer from having a significant amount of public influence.

The problem is not anything to do with glibc - it's the conduct of someone who, like it or not, is a role model for a lot of people in the community, and has taken on a very public role.

I guess I understand the downvotes here, but I really do think you've hit on at least an issue. Maybe not the issue, but it's a pretty big problem.

RMS's conduct here is just... pretty inappropriate. Jokes about abortion, rape, race, sexual orientation, etc, etc, are not something you should be touching as the maintainer of a public project, no matter what your opinions are or how strongly you hold them. The glibc maintainers (completely reasonably) decided that the man pages weren't a good place for potentially-charged jokes like this, and removed it. RMS overruled them in a pretty childlike and insensitive fashion, and that's not appropriate when you're the public face of anything.

I don't give a shit about the politics of glibc - but I do care that someone who is a role model and a public figure acts like this.

I dunno, I find it pretty easy to understand... seems like the main instruction loop is in tvm.c, in the function tvm_vm_run(), which is exactly the first place I looked and seems totally sensible to me.

  for (; vm->prog->instr[*instr_idx] != -0x1; ++(*instr_idx))
    tvm_step(vm, instr_idx);

Not quite. Multiple dispatch (as mentioned in sibling comments) is basically 'virtual on both object and argument types', so like:

  class Vehicle {
    virtual void Collide(Vehicle other);
  }

  class Car {
    void Collide(Truck other) { /* hit a truck */ }
    void Collide(Car other) { /* hit another car */ }
  }

  class Truck {
    void Collide(Truck other) { /* hit another truck */ }
    void Collide(Car other) { /* hit a car */ }
  }

  Vehicle c = Car();
  Vehicle t = Truck();

  c.Collide(t); // with multiple dispatch, calls Car::Collide(Truck)

I moved from git to perforce when I switched companies, and even though I actually really like git and consider myself reasonably proficient, I don't mind perforce.

My one real pain point with it isn't so bad, but I dislike how perforce tends to work at a file level instead of a commit level. It's hard for me to make several related changes which all touch the same files, like a series of patches which all refactor the same area of code, but which I would like to review and discuss separately, and potentially revert some/all of.

It's hard to manage this with shelves, because perforce can't handle unshelving the same file in two different CLs. I could submit all the changes to a separate stream, but perforce streams just don't usually work well for us, and it's still hard to experiment by constantly making and rolling back changes.

I guess I'm probably only used to this workflow because I have experience with git, but this is the time when I really miss the granularity of a git commit (and I'm doing a pretty gigantic refactor right now... so it's hitting me quite hard).

Diminuitive of 'nope' :)

I think the relevant quote from the judgment is: 'criminal forfeiture serves no remedial purpose, [and] is designed to punish the offender...'

So they don't actually care about compensation, they just have the right and want him to bleed.

And I'm lucky enough to have clicked on the comments first, otherwise I would have been #6.

You might be looking for the term 'SOLID' ;)

e: it may be worth noting that I can't for the life of me remember what the I and D stand for... clearly I am much more of a KISS kind of programmer.

I knew I recognized your name from somewhere! Presumably you are the iEchoic of http://wiki.teamliquid.net/starcraft2/IEchoic_Build_(vs._Ter... fame? :)

Never knew you personally but I spent a lot of time lurking on TL after SC2 release, and further on into the Dota days, congrats on the launch!

I've been clicking on your 'hacker news best comments' button for like twenty minutes now... you weren't kidding when you said 'basically a time waster' :P

Seriously, really good looking stuff for your early projects! I'm not surprised someone picked you up :)

http://www.opusnota.com/hnbc

I know this is a bit irrelevant... but did you mean 'bonhomie'? (I only think that because I was really, really confused by that sentence - then I realized I had been mispronouncing 'bonhomie' in my head this whole time, quite badly. I guess I learned it by reading and you learned it by speaking :P)

I don't even think it's about pretty code - I think it's more related to what one sibling of the post you replied to mentioned, which is that there are tons of communities (among them machine learning, but including tons of stats-heavy academic programming) which would REALLY like to do some extremely heavy work in Python, not because it's necessarily the best, but because it's what they know. Academics in particular (not CS academics, but stats and experimental sciences people) can be forgiven for wanting to stick with Python - they aren't programmers, they don't want to waste time learning programming language skills that are largely irrelevant to their job. All they want is to pick up an easy language and be able to do their work in it, but once their work gets heavy, the language starts to fight them. And that's a really popular use case for Python, I think.

Inasmuch as I want everyone to be guided by their moral convictions, yes. I mean, even if I don't agree with them, I'd much rather an engineer's decisions be guided by 'what they feel is right' rather than guided by nothing at all, which seems to be what parent was implying.

Also, this is why we have engineering codes of ethics, at least in Canada and the US (and while I'm not familiar with elsewhere in the world, I would assume similar things hold in most first-world countries). We don't necessarily have to agree on everything, but there is a baseline for what we consider ethical, and engineers are expected to uphold that baseline, otherwise they are not permitted to practice engineering. Unfortunately the line between 'engineers' and other practicioners isn't as well-defined for software engineering as it is for most engineering fields - but that doesn't mean we should ignore it completely.

'Once the rockets go up, who cares where they come down? That's not my department! says Wernher Von Braun.' https://www.youtube.com/watch?v=kTKn1aSOyOs

I really really really strongly disagree with this. As the ones who are most knowledgable about the systems they're building, I definitely think engineers have a moral responsibility to make sure they're at the very least following applicable laws and regulations - I would argue that we have a moral responsibility to act ethically even in cases where it's not covered by laws or regulations, but I'll admit that's a bit more controversial.