I would love to hear more about this code hotloading solution. Does anyone have any experience in this area? Seems really cool.
Short answer: Most code goes into a dylib, and the executable (which contains the main game loop) reloads the dylib in between iterations if it notices that the dylib has changed on disk.
I have been experimenting a little with that, especially around keeping a stable boundary that could vanish at runtime. Would you be open for bikeshedding somewhere else? Maybe users.rust-lang.org?
Happily! Feel free to kick something off and send me a link.
I got kind of lost about what part of this was the “easy” stuff. Fixing flaky tests can be quite hard. The whole Maslow’s hierarchy of needs also seemed completely unrelated.
One interpretation of Maslow’s hierarchy of needs is “if you’re having trouble finding enough food to survive, it’s gonna realllly tough to do things like maintain friendships or produce incredible art or scientific research.”
One interpretation of Dix’s hierarchy of software needs is “if you’re having trouble getting your tests to pass consistently, it’s gonna be realllly tough to do things like deploy continuously or split your monolith apart into microservices.”
Yes, but I don’t know what that has to do with being “easy”.
Finding food is basically always easier than doing scientific research (partly because it’s inherently easier; partly because if finding food is hard, then malnourishment makes doing scientific research harder).
Similarly, (assuming the point that dix is making) getting your tests to pass is basically always easier than migrating to microservices (partly because it’s inherently easier; partly because making large-scale changes to your software is going to be to be very tough if you can’t be confident that those changes are correct).
Fixing flaky tests can be certainly be quite hard, but if your reason for not doing it is “it’s too hard”, then tackling even more challenging problems seems like a bad decision.
It depends on your definition of easy. If one’s version of primitive or generic human lives in the topics, where there are low hanging fruit, by all means pick those. But in full generality, finding food could involve anything from long hours hunting and/planting to long hours at the fastfood joint making the money for the food.
Scientific research might involve sitting around speculating, it might well be “easy” though it’s payoff time might be long.
And so, what I see is there’s a confusion between “easy” and “has an immediate payoff”. It’s definitely important to tackle some tasks with an immediate payoff while the stuff with a long payoff percolates along. And it’s good to tackle tasks that are really-easy and have a semi-immediate payoff. But acknowledging this, we’ve got a complex situation, which can’t be that easy, right?
So what’s easy? Thinking about it, it almost seems like “figuring out what’s easy” isn’t always easy itself. That leads to a paradox. But it might be a “paradox of finite regress” rather than infinite regress. Go for the low hanging fruit, if you can see them. Otherwise, maybe look carefully and you might see them or put out the darn effort, climb the tree and get other if you’re lucky or you’re speculation has borne fruit. It’s altogether not easy, sorry…
Part of “easy” here has to do with dependence of the “harder” activities on the “easier” ones. It’s entirely possible that cost(eat_low_hanging_fruit) + cost(climb_to_high_limbs_on_a_full_stomach) is less than cost(climb_to_high_limbs_on_an_empty_stomach), despite involving more activity. Similarly, a scientist who has spent most of the day hunting might get more research done in the remainder of the day than the scientist who is plagued by hunger pangs and malnutrition does with their whole day. Similarly, a team that maintains a robust test suite might able able to tackle hard architecture changes more quickly than a team with no test suite at all, despite the total amount of work that has to be done being larger.
cost(eat_low_hanging_fruit) + cost(climb_to_high_limbs_on_a_full_stomach)
In fact, I’d argue that anyone who writes automated tests believes this implicitly. There’d be no reason to write non-production code if it didn’t make you more effective at writing production code. (That said, it is entirely possible to write tests in a way that actually slows you down.)
This whole thing is getting a bit ridiculous. Clearly “easy” is the wrong adjective to use for this. If one only do easy things you’ll never do hard things. In general, I pick things with high impact. They may be easy, they may be hard.
“Easy” is maybe not the most clear word here, but in the context of the entire post it seems understandable enough.
Notice how the title of the post is “Do The Easy Things First”, not “Only Do The Easy Things”. Dix is not advocating to not do things with “high impact”; he’s advocating to set yourself up for success while doing those things, even if that means delaying starting on them to take care of foundational work.
And I am saying if you always do the easy thing first you’ll never get to the hard thing.
[Comment removed by author]
I’d also argue that if you never have a compelling reason to do the hard things, you shouldn’t do the
Your whole argument is to do the easy things first. If that’s the heuristic you want then you won’t do the hard things until you have nothing else to do. This is why I think impact is a more valuable way to look at it.
Posted on 4/1. Not sure if I should take it seriously.
I see no reason to think it’s a joke.
wasn’t trying to troll. Annoyed by the ridiculous 4/1 tradition and how it seriously does make me question anything I read on 4/1.
Interestingly, the scala style guide goes directly against this, saying that only functions without side effects should be invoked without parentheses. In scala, parentheses are not required for method chaining.
This fireside chat only address method that take arguments but not getters. In scala’s case, you can only choose to not use parentheses for getters and operators. Since the point of getters is to look and act like an attribute, it seems like both the scala style and the OP would agree that nto including parentheses is ok.
I think you are mistaken. Scala doesn’t have the concept of operators distinct of methods, and getters are not the only case in which you can use infix operators. If you look at the examples in the scala style guide that I linked to, none of them is a getter except maybe getOrElse. For example, List(3, 6, 12) map (_ * 2) is valid scala, but is not a getter.
edit: I was thinking of this semantically as being about infix operators, so my example actually has parentheses. A similar example which does not have parentheses is List(“one”, “two”, “three”) map println
This talk repeatedly put me on the defensive in spite of me wanting to learn from it. He’s against layering sugar on top of a core, but I see that as a big part of what software and computing is. At the core level we’re just shuffling around 1s and 0s. There’s already a huge pile of sugar on top of that.
I didn’t gather that he was against layering sugar on top of a core, but that he believes we’re limited (not necessarily in possibility, but in how much time and effort we have to spend dealing with it) by the crappiness of the core.
Also this classic: http://codahale.com/how-to-safely-store-a-password/
Is this on topic for lobsters? Seems too general tech-news-y.
I will venture to say that one link is reasonable. I don’t need a repost of every blog about the most disappointing iPhone ever, but an anchor where people can talk about it seems useful. The HN discussion is wholly useless.
For my part, to say something, I plan to upgrade. Looking forward to a lighter phone.
I can’t believe my own pair would call me out.
In all seriousness I think you might have a point. The main reason I posted this was I saw the new Amazon Kindle announcements hit the top on Lobsters.
Isn’t that what voting takes care of? If people are interested, they will upvote it and it will rise to the top.
A few of my other favorite features