mklim

I bought a copy of "Auto Mechanics Fundamentals" based on this thread and I think it is definitely the book you're remembering. The exploding can image you describe is on page 9 and the first chapter builds up an engine from first principles like you've talked about. Thank you for recommending this, it's a great resource!

Depends on the context/language I think. Splitting a block of code into a function gives it a greppable name that (ideally) succinctly describes the point of the block. You can have that block just headed by a comment inline to try and do the same thing, but comments are extremely prone to getting ignored and left to grow outdated when the purpose of the code around them changes. It's easier for the reader to just mentally abstract away that block if it's separated into a function. And if that block is worth testing, it's much easier to do when it's isolated into its own function.

There's reasons to keep the block inline too--like if you're working in a more resource constrained environment, or if the block isn't really isolated/self-contained enough to cleanly abstract away, or if the block in question isn't really doing anything substantial. But I wouldn't say that you should only abstract away code into functions to save yourself from literally copy/pasting the lines in multiple places.

bargl asked aantix permission to directly quote them without the intro further downthread: https://news.ycombinator.com/item?id=14395143

Do you mind if I word for word quote your above to see if I get downvoted too? I want to repost with just the last two paragraphs to see what happens. I'm curious how this post would have been received without the intro.

Of course, that's not what I'm trying to argue against. The fact that the city is vastly underpopulated per square mile is arguably one of the core sources of its public infrastructure issues. What I was trying to say is that there's still ~700k people already living there, who have been living there for decades, but the angle of a lot of the "Detroit comeback" press is to focus entirely on how happy the new transplants and the surburban visitors are, and on their wants/needs, and to ignore the hundreds of thousands of people that have remained in the city this entire time. I'm speaking in generalities of course, but anecdotally it's an angle that I've seen come up in a lot of the press cycles about new developments in the city.

Yeah. I think we're on the same page. I think the flashy Greater Downtown development is generally positive, I don't mean to be down on it--that would be especially hypocritical of me, as a former Midtown young adult transplant--it's just that a lot of times it's portrayed through this lens where it's as if the city was this completely empty and barren wasteland and here is this new artisan coffee shop charging into the wilderness to save the world and Establish Civilization. When the city is not an empty wasteland. There are hundreds of thousands of people already living there, they've been living there for decades, and a fancy bakery is nice but probably isn't going to help them with any of the public infrastructure issues they've been actually struggling with and trying to get attention to for years and years now.

I lived in Midtown for ~5 years in 2010. I've heard it described by disillusioned longtime residents as "two cities" at once--there's the flashy Greater Downtown developments that suburban outsiders and young transplants take advantage of--the million and one microbreweries, the great dive bars and concerts, the locally grown organic handmade (artisan shop|bakery|barbershop|restaurants), the low (if rising) rents, the incredible art museums, etc. There's brands like Shinola that completely base their marketing off the image of an "authentic", scrappy city fighting back, even.

But the actual longterm residents, especially the ones living in the vast majority of the city that falls outside of the Greater Downtown area, still have to deal with trying to commute with DDOT, the abysmal public infrastructure, and the horrifically underfunded public school system, etc, and those multifaceted and crippling issues don't see the same kind of widespread attention/praise/improvements because there's no sexiness there and no short term money to be made off of it. And no easy answers, either, it's not as simple trying to fix public transportation in the city as it is opening a coffee house on Palmer. There's attempts being made, but at least anecdotally they don't seem to generate the same press or have the same kind of investment behind them.

I don't think it's as simple as whether or not the city is coming "back"--there's a lot of layers to that. "Back" by what definition, and for who?

Can't chime in on safety issues, but on usability: I know a physician who transitioned to using EMR roughly five years ago. It doubled the amount of time they need to take notes, to this day. They can't see nearly the same amount of patients they used to because so much of their day is spent going into and out of full screen surprise submenus in the EMR software and flipping through different tabs and re-entering information into multiple forms and scrolling through dropdowns with multiple hundreds of options. GP's post is 100% believable for me. It's nothing like Rust vs C89. It's more coding with punch cards vs an IDE, except the EMRs are the punch cards.

Agree in a lot of ways, but there's darker sides to this pro depending on context and who you are. One of the things that makes the Bay Area priceless to me (visibile minority) is that I'm consistently treated like a regular person/with friendliness by strangers instead of with general hostility/coldness like I was back home in the Midwest.

I'd second that the game is good enough to warrant a Switch purchase on its own, assuming you have that disposable income.

[BOTW puzzle spoilers below]

Comparing it to the Witcher 3 is actually a great way to highlight its strength--the insane depth of the mechanics. It feels almost like you're playing Nethack or Dwarf Fort in terms of how deep the mechanics go and how much the game designers allow you to do. Not _as_ deep, nothing's as deep as Dwarf Fort, but deep enough that I can make the comparison.

For example, both TW3 and BOTW have a mechanic where you can mix different ingredients together to give yourself stat bonuses. They both have you harvest the ingredients from the in-game world. Very similar so far. But in TW3, you mix them by going through some menu screens and clicking on the appropriate items. In BOTW, you take the items out of your inventory, hold them, and return to normal gameplay while holding them and can then choose to drop them anywhere in the outside world (ideally in a heated cauldron). But you can choose to drop them just in an open flame, and while you can't get potions this way, you _can_ cook ingredients like apples and meat to have them restore more of your health. But if you leave them in the fire too long, they'll catch fire themselves. And if it's a dry day and you're standing in the right (or wrong) kind of terrain, the grass underfoot may catch on fire, too. And it may spread (and start interfering with enemies--but that's another story). And there's more to it than that--if you drop certain ingredients in snowy landscapes or icy streams, they'll freeze over and give you heat resisting properties when they didn't before. And if you drop them in areas that are too hot (think side of an active volcano), they'll start cooking immediately, as if you had dropped them over an open flame in a standard area. You can distract certain a certain type of enemy by dropping food in front of it too.

The entire game is like this. For example, in another dungeon I got stuck on a puzzle that clearly wanted me to put two magic electric orbs on two switches, about 5m apart from each other. But for the life of me I could only find one of the orbs. After fifteen minutes of running around, I remembered that my metal weapons conducted electricity--I had found that out because I had gotten killed by a lightning strike while I was flying through a storm earlier, I ignored the warning sparking around my back and had to reload a save. So I dropped every metal weapon I had and dragged in a metal chest from another room in the dungeon and made a circuit from one switch to the other with the single electric orb in the middle. And it totally worked to solve the puzzle. (Looked up where the second orb was later and I was blind to not notice it, whoops.)

It doesn't have the depth of writing that TW3 does, the characters are more cartoonish and less nuanced and the plot itself is much more straightforward and doesn't have a tenth of the subterfuge. But the writing isn't poor, either, it's done extremely well for its style. It comes across as very Ghibli-esque to me. Zelda's character in particular is nuanced and an interesting examination of their old tropes without fully subverting them, and the way they reveal the story to you is through a series of clever small vignettes that overwhelmingly choose these small intimate moments that manage to imply so much more than they outright say.

It's unabashedly 11/10 GOTY and maybe "game of this generation" to me, though I'm trying to give myself some time to get over the initial rush before I make that kind of call. Blows TW3 out of the water, and I loved TW3.

Up until 2015 there was a related but more consequential issue that made it extremely hard to prosecute crimes committed on reservations by non-Natives. Tribal governments couldn't prosecute non-Native offenders, instead those crimes fell under federal jurisdiction--and the federal government itself is generally uninterested in prosecuting petty crime. [1] Off-reservation offenders would deliberately go onto the reservation and target the population there because they knew that it was practically impossible for them to be prosecuted, allegedly. Native American women experience sexual violence at much, much higher rates than the general population at least in part because of the jurisdiction issues. [2] VAWA passed in 2013 though, closing the loophole as far as I'm aware. [3]

[1] https://www.theatlantic.com/national/archive/2013/02/on-indi...

[2] http://www.nytimes.com/2012/05/23/us/native-americans-strugg...

[3] http://www.huffingtonpost.com/2015/03/06/vawa-native-america...

You could have made the same inane argument for all the uneducated factory laborers who have been replaced by machines.

There's nothing inane about the argument. Have you ever been to Detroit? I've lived there for years. It's a horrible thing for these people to have been replaced by automation in their lifetimes. They didn't see the benefits in the increased productivity like their employers did, they just lost their livelihood and had to scramble for jobs that paid much less while simultaneously trying to retrain into other fields, if they were enterprising. The entire region is obviously devastated from the effects of it. Their prior automated work being "unfulfilling" and therefore terrible is a) debatable and b) nothing compared to the struggle of having no income at all. One guy I knew ended up homeless after he lost his job, then with a leg amputation because of frostbite from sleeping outside. When I met him he was making a living ticket scalping in his wheelchair all day. The short term consequences are real and terrible for these people.

This is really impressive. I check out code poems occasionally and I don't think I've ever seen ones where executing them actually draws images related to the subject matter of the text itself. Love the piet one sort of doing it in reverse especially. Thank you for sharing.

Here's another old famous example of these for anyone interested, "Black Perl" (https://en.wikipedia.org/wiki/Black_Perl)

    BEFOREHAND: close door, each window & exit; wait until time.
        open spellbook, study, read (scan, select, tell us);
    write it, print the hex while each watches,
        reverse its length, write again;
        kill spiders, pop them, chop, split, kill them.
            unlink arms, shift, wait & listen (listening, wait),
    sort the flock (then, warn the "goats" & kill the "sheep");
        kill them, dump qualms, shift moralities,
        values aside, each one;
            die sheep! die to reverse the system
            you accept (reject, respect);
    next step,
        kill the next sacrifice, each sacrifice,
        wait, redo ritual until "all the spirits are pleased";
        do it ("as they say").
    do it(*everyone***must***participate***in***forbidden**s*e*x*).
    return last victim; package body;
        exit crypt (time, times & "half a time") & close it,
        select (quickly) & warn your next victim;
    AFTERWARDS: tell nobody.
        wait, wait until time;
        wait until next year, next decade;
            sleep, sleep, die yourself,
            die at last
    # Larry Wall

I was just thinking of its rogue mode. I remember each person having their own cursor and being able to work independently in the same session with it.

Not on its own, but I've used https://github.com/zolrath/wemux on top of tmux in the past to get that and it's worked well.

Put another way, there’s a risk of AIs learning to achieve their assigned task better by preventing humans from shutting them down.

Thought experiment/short story that goes into this in depth: https://gist.github.com/deanmarano/142df7a8a824ab05fc777d8e0...

The crux of the story hinges on the magical spontaneous development of general intelligence, so it's pretty unconvincing as a specific plausible scenario IMO. But the general idea, that an AI may take unethical/unprecedented actions to maximize a harmless goal, is a good one.

McDonalds specifically is starting to replace its cashiers with kiosks, though right now it looks like the former cashiers are switching to bussing tables instead.

http://fortune.com/2016/11/18/mcdonalds-kiosks-table-service...

I feel like we need a professional ethics code to handle situations like this.

But how are we ever going to get the rest of the world to afford us the same respect that doctors and lawyers get if we're unwilling to play ball?

I would love for you to point out the part of the Hippocratic Oath where doctors agree to personally call on patients at any time of day or night--as long as they're offered enough money. Or an Attorney/Lawyer's Oath that has a clause where they must take any client at any time if they're offered a generous enough consulting fee.

The distinction is that you're making a crappy general purpose framework, but you're making a really good problem specific framework that exactly fits the thing you're building.

Strongly disagree.

Your hand-rolled framework is undocumented besides whatever comments you've put in your code, full of bugs besides whatever you've personally stumbled into, and lacks anything except the features you've needed thus far. It's a means-to-an-end to get the actual features you need done done, instead of built for its own sake and tested and polished for its own sake.

The second your application grows in an unexpected way, you need to augment the entire framework to suit. If there's a bug, you can't search stackoverflow or the github page and just read the answer that 500 other people have found before you, and neither can anyone who has to take over the code after you and try to maintain it--you are the sole author, your internal comments and notes and email chains are all the documentation for the framework that exists in the entire world, there's no hope for the maintainers besides slogging through the source and discovering the solution from scratch. There is no cheerful dev community contributing PRs for the buggy edge cases that break your code on obscure browsers. There's no helpful blog posts out there on how to tweak it for performance optimization. It's all just you trying to maintain what really should be its own full time project while you're trying to build a real product on top of it at the same time.

IME, hand-rolling your own framework as you're building a product gets you the bare minimum (read: extremely poor) mess of code that could possibly address your core use case, not something good for your specific problem. Using multiple libraries instead of monolithic frameworks I think is generally a good idea, depending on context--but completely hand-rolling your own framework from scratch while you're actively developing a product, no, I've never once seen this work well.

BigScreen is great. Relevant article about using it for coworking: https://medium.com/@ftarnogol/co-working-in-virtual-reality-...

Haven't used it for coworking personally, but it's been fun using it to watch tv and hang out with randoms. Just having the body language goes a huge way in making it feel like you're really in a room with the other person.

There's a problem with your use case and the current tech--artificial locomotion in VR tends to cause people to experience motion sickness. It's similar to sea sickness in that some people don't feel affected at all and others can be full on vomiting within a relatively short time of exposure. It's a natural reaction to the dissonance between your eyes visually saying that your body is in motion but your inner ear saying your body is at rest. Skateboarding/rollerblading specifically are both pretty extreme sports in terms of movement, so any sims with current tech are liable to make him feel nauseous after any kind of serious exposure. Most current VR experiences have 1:1 movement in the real and virtual world to avoid this problem, and the ones that don't tend to limit artificial locomotion to slow forward movements to try and cut down on the effects. Actual skateboarding/rollerblading are going to be pretty risky for him to try and enjoy in VR. Odds are they're going to just make him feel sick to his stomach. (Also, as a former skateboarder--most of the skill in the sport is balance and footwork. None of the headsets are tracking your feet, so it would be pretty hard to get a realistic sim built for it.)

That being said, the best tech out there currently is the Vive IMO, with the Rift likely tied once its touch controllers ship this December. Both have 6 degrees of freedom when tracking you. But right now the Vive is the only system that officially supports tracking your movement within a few square meters, and has motion controllers supported. That means within a room, you can walk around in both real life and the game world simultaneously and reach out and interact with the virtual world. The presence you get from that kind of experience is impossible to describe. Once the Rift's touch controllers ship the two systems will likely be on par with each other.

The mobile headsets all have 3DoF tracking. That means that the rotation of your head is tracked, but not its position in 3D space--taking a step forward in real life won't also move you a step forward in the virtual world, but the direction in which you look will be 1:1. You don't have as immersive experiences on them because of that, but for experiences where you're a passive/seated observer you can still get a VR experience for a tiny fraction of the price of a Vive/Rift + VR capable PC. Their performance depends on the quality of your phone.

For your grandfather I'd actually recommend he try and get a demo of the Vive or Rift on the floor of a PC store. Microsoft and Micro Center stores were both giving demos of them when the Vive debuted. That way you could gauge how much he enjoyed the experience and see if it's something you want to invest in for him in general. Maybe pick up a cardboard and find 360* skateboarding videos on Youtube just for him to experience it, if you were going to buy anything blind--that would be a ~$20 investment, and for those sports specifically you probably aren't going to find anything better on the high end systems.

So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.

I think this is a reasonable claim, even though as you've said there's nothing strictly enforcing this behavior. Function names are generally highlighted by the editor/IDE, and the developer is forced to stare at them and at least begin to type them out while calling them. They're brief and repeated over and over again in the source code. They're just harder to ignore. Comments on the other hand only appear once per comment, tend to be italicized and greyed out by IDEs, are generally at least one sentence in length and can span multiple paragraphs, and are never going to be directly referenced from within the code itself. It's still very possible to change a function without updating its name to suit its new purpose. But I know for me personally I'm much more prone to missing comments that I need to now delete or reword. I have to acknowledge the function name when I write code calling it or read code referencing it, but comments are just sort of there, hovering in the background. It's easier to read them once and then tune them out and forget that they're there.

Related quote:

We are working with a number of smartphone manufacturers to create a specification for Daydream-ready phones. These smartphones enable VR experiences with high-performance sensors for smooth, accurate head tracking, fast response displays to minimize blur, and powerful mobile processors. [1]

------------------------

[1] https://blog.google/products/google-vr/vr-google-jump-expedi...

(Disclaimer: work at Google, but not speaking as a representative of the company.)

It depends on where you draw the line for "trivial". Does it need routing/browser history? What browsers are you supporting, any legacy ones? Does the frontend do any kind of translations or visualizations with the data it's getting from the server? Does the layout have a bunch of panes and reusable views? Do you want your frontend code to be testable? All of that is an order of magnitude simpler using an actual SPA library or framework. And if you're not doing any of the above, you're probably better off making a server side rendered app with some AJAX sprinkled in anyway. At that point making it an SPA at all is probably overkill.

The huge frontend frameworks have an upfront learning cost and tend to be unfortunately leaky abstractions, but they're still much easier to maintain than a jQuery/JS mess with a bunch of DOM-manipulation code and HTML strings living right next to the business logic. They at least force the code into an understandable architecture and separate the view from business concerns. Experienced developers know how to structure their frontend JS already, but novice ones--the same ones that would feel the pain of learning a framework/ecosystem on top of JS when they first try to pick it up for an SPA--almost certainly won't.

I've had the exact same experience. Every time I boot up SM64 or OOT everything looks so blocky compared to how I remember it looking as a kid, it momentarily surprises me every time. In my memories the graphics are on par with AAA games now.

Picked up a Vive a few months ago--Valve created a program for it called Destinations where people can upload 3D environments with optional simple animation triggers, and you can teleport through the environment in VR. Somebody uploaded the exterior of Princess Peach's castle and the Shadow Temple boss area to it. Checking out Peach's castle in the headset was breathtaking, got that same kick to my chest and feeling of wonder I remember having as a kid and felt like I really recognized the environment in a way I didn't when I booted the games up in emulators. Being there in VR made the graphics look worse--the tiny textures originally meant to be viewed on a CRT get blown up across the several literal football fields and the polygons are huge sharp edges several feet across for the hills. I'm not sure why it provoked that emotional response in me. I would guess that I felt more immersed, and that immersion affected my perceptions as a kid.

On the other hand, I lived in Detroit for years. I think most people conflate "visibly poor" with "actively dangerous" and feel scared when they shouldn't. So many people would come in from the suburbs and visibly panic because they saw a crumbling building or a homeless person and figured they were about to get mugged, even though they were by the DIA in broad daylight surrounded by a crowd of people. My university's campus had less reported crimes than U of M's while I was there, and I still had a middle aged suburban woman try to get my professor to end a 6-9pm class at 7pm because she was scared to walk the 100 well-lit feet from the lecture hall to the parking structure after dark.

If you find yourself passing parameters and adding conditional paths through shared code, the abstraction is incorrect. It may have been right to begin with, but that day has passed. Once an abstraction is proved wrong the best strategy is to re-introduce duplication and let it show you what's right.

I like this take on when go full DRY or not a lot. It's very easy to abstract out two things that look identical in their earliest implementation, but are actually different in intent and function--then when you get a new feature request on one of them they become obviously wildly different, and then to maintain the abstraction you have to throw in a bunch of conditional blocks into it and it turns into a nightmare to maintain.

I heard a rough rule of thumb to stay away from abstracting anything until you see it repeated identically at least three times, not two. It's just a rough rule of thumb to try and make sure you're not prematurely abstracting something and building the wrong thing, but anecdotally it's been useful for me.

I don't think those are mutually exclusive. It would make sense that a classist/segregated society would both cause and be reinforced by elevated crime rates in the lower classes. Less legal opportunities for the lower classes to make money, and if they were poorer they'd have a more desperate need for immediate wealth than the upper classes, so that would make crime more attractive for them on average. And reports of those crimes would be a reason for the upper classes to justify their classism/segregation to themselves (ie: "of course those people just can't be allowed into polite society, look how dangerous they are") and lead to them enforcing the segregation more strictly. And that's not even taking into account selective prosecution/policing by law enforcement.

soft sci fi is the usual boring eternal "human condition" story thats been told a million times before, but maybe if I put space ships in as my gimmick I can sell more copies.

This is a pretty unfair description of the category. Soft scifi is a story that has fantastical tech/physics that aren't completely explained. The tech is usually crucial to the story in some way, but the how of the tech's functioning is left unsaid. I find it unlikely that you've somehow lived through the entire range of events and emotions that can comprise the "human condition", but that aside: a lot of the soft scifi stories out there are focused around hypothetical inhuman conditions for which the fantastical tech is crucial. Do Androids Dream of Electric Sheep? is focused on whether artificial sentience is less worthy than organic, Whedon's Dollhouse on the potential personal and societal ramifications of being able to save/load our brains digitally, Ancillary Justice on what it might feel like to have your consciousness simultaneously inhabiting multiple bodies, "The Measure of a Man" from TNG on what it means to be sentient and if artificial sentience is possible (or even possible to measure once achieved), Her exploring how a truly sentient AI would relate to humans and impact our society. There are a lot of vague stories out there that use spaceships as an attention-grabber, but that isn't what defines the genre.

Possible. But there's still potential problems with that, tying in to the article's main issue of potential feedback loops/bias in ML algorithms. Let's assume pay is correlated to perf/job title, and members of group X are consistently rated 80% of what a member of group Y would earn for identical performance by unintentionally biased managers. Let's assume that they're all similarly 80% as likely to be promoted given identical performance. Anyone looking at the data would find that pay for X and Y members is fair given their perf scores/job titles, and that members of X tend to underperform compared to Y. They could suspect bias in perf from that, or they could conclude that members of X are fairly paid but statistically underperforming. An objective evaluation of a biased/unfair dataset doesn't necessarily guarantee a fair/objective outcome.

If group X is as effective as group Y but you can get away with paying them 20% less, why would you NOT hire group X?

Hypothetical possibility: members of group X are not perceived as 100% as effective as group Y because of pervasive bias by the employers that assumes their incompetence. They are generally perceived to be 80% as effective as a standard Y member despite actual 100% performance, and paid accordingly. A member of X needs to be 120% as effective as a Y member to be perceived at 100% Y efficiency because of stereotypes coloring their perception and an inability to objectively evaluate their performance.

Some non-hypothetical studies touching on this:

http://www.nber.org/papers/w9873.pdf http://www.pnas.org/content/109/41/16474.full.pdf+html http://advance.cornell.edu/documents/ImpactofGender.pdf http://www.socialjudgments.com/docs/Uhlmann%20and%20Cohen%20...