fghgfdfg

Really? I had a very different experience. I mostly just used the official Phoenix docs and never touched ecto. It was a strictly optional thing I didn't need, so I didn't touch it.

I did look at some other tutorials and I don't recall ever having issues because I wasn't using ecto. Either they weren't using it or I got what I needed anyway.

This was probably about a year ago or so. Maybe things changed at some point?

I think you're thinking a little too big. All I think that is really being suggested is an automatic window cracker/closer.

If the goal is just to maintain a temperature I don't think you need to go to most of the lengths you mentioned. You have a window that is currently adequately insulated when shut. This is intended for maintenance so no need for a fan to speed things up. However the room is getting too hot now will suffice to heat it back up if needed, but again being slow means it shouldn't overshoot badly either.

It still may not be worth your time, but if just cracking a window would be sufficient cooling for most of the year it could be.

As I mentioned, it ends up being the thought of it that's the worst. I can grin and bear it - as you mentioned that just tends to be part of life.

I think we're probably talking about this a little too broadly. I wasn't thinking so much of the semiannual office party. On that side of things I'd probably completely agree with you.

I was thinking more about things that were some kind of event designed to "raise morale" or something with dedicated activities, potentially run by outsiders, for "team building." The sorts of things that have a strong "drink the koolaid" feel. Those are the things I start to think about (and dread) when that ultra-optimistic corporate speak shows up.

And I've seen at least one blog post on HN advocating for that sort of thing to be as frequent as possible for company size, down to even weekly IIRC - although at such a small size it might be harder for it to get too terrible.

Perhaps I'm just reading too much into the phrase "deeper issues" but I think you're reading too much into the whole "nightmare" phrasing.

I don't think it's so much of an issue of feeling left out as it is feeling pressured to suffer through it with a smile on your face.

Being visibly unhappy or disinterested while you are there usually brings additional pressure to engage. Leaving early invites later questions that require you to lie to be socially acceptable. And if the events are frequent enough it'll be obvious you are lying sooner rather than later.

And then add in considerations about what those above you in the company will think.

It's enough that I do have similar responses to such things. And it's also true that it's probably a somewhat too extreme of a response. Thinking about it is usually worse than actually being there, as it's usually possible to end up off in a corner with one or two other like-minded people which is mostly tolerable.

Although as things get more structured this gets harder, and the structure is usually accompanied by even more "optimistic language" so... again, the response seems fairly justified without invoking a need for "deep issues."

I've never understood what people actually mean when they say things like "dynamic languages let you express yourself more easily."

I tend to find it significantly harder in dynamic languages. Yeah, there is way more flexibility in small decisions (like right now, is it easier to return a string or an integer or whatever) but it's not free. Your little decision interacts, directly or otherwise, with potentially the entire rest of the program that might ever exist. There is probably a best choice, and it's hard not to try to find it every single time. Doing the easiest thing right now might mean you need to go and adjust many other things. In order to know what is overall easier you need to keep the rest of the program in mind.

I find dynamic languages kind of exhausting to write anything but one-off scripts in. I can't make good choices without holding far more of the program in my head than I would in a static language. Sometimes I don't even realize I'm making such a decision because I don't have a correct or full view of the rest of the program. To make matters worse those errors won't even show up as being a problem at the decision-site.

I feel like I express myself much easier in a language with a strong static type system. I can write down clearly exactly what the model is, and then the compiler or types let me know when I try to stray from it. From there I can decide if it's better to adjust what I'm doing in the small or the large.

> That's why we have floating point processing units instead of the fixed point.

I'm not sure what that is supposed to mean. I was talking generally. Not every situation has a single appropriate value to represent it. I don't particularly care if this one example could have used a floating point or not.

> This piece of program catastrophically failed because some input was a just somewhat bigger than before.

As far as the software was concerned the rocket had already catastrophically failed. It actually hadn't, because it was a different rocket than the software was designed for. It was "somewhat bigger" in the sense that it was large enough that the rocket the software was designed for would have been in an irrecoverable situation.

> Properly programmed components that are supposed to handle "continuous" inputs and provide "continuous" outputs (and that is the specific part we talk about) should not have "discontinuities" at the arbitrary points which are the accidents of some unimportant implementation decisions (leaving "operand error" exception for some input variables but protecting from it for others!).

That's theoretically impossible. If you want to account for every possible value you're going to need an infinite amount of memory. There will be a cutoff somewhere, no matter what. Even if that cutoff is the maximum value of a double precision float - that's an arbitrary implementation limitation. You can't just say you can more than count the stars in the sky and that's clearly and obviously good enough for everything. It's not.

There will be a limit, somewhere. It will be an implementation-defined one. As long as the limit suits the requirements, it effectively doesn't matter. In this case, the limit was set such that if it was reached the mission had already catastrophically failed. That's all that can practically be asked for.

These days I don't blame them. I'm guilty of it myself. After Microsoft repeatedly dropped in the Windows 10 "updates" (including nag) under new names it got to be enough of a hassle to avoid them that I've basically stopped updating. Finding the latest update names to ignore, then actually finding them in the update listing is enough of a pain to get me to continually put it off.

From a quick google search, it appears the methyl group gets converted to methanol.

I don't really see that as the main point. Perhaps I shouldn't have mentioned it at all.

I don't see the practical issue with a model being brittle in the face of imminent mission failure. The model breaking down shortly before you self-destruct the whole thing seems like a rather minor concern. It's entirely irrelevant at that point what the model is.

It turns into an issue when somebody throws the software into a new environment without looking at it or it's requirements and then doesn't do any testing with it. But that's not on the original developers. Their solution was entirely valid for their problem.

Even if they had done something like report the maximum value instead, the rest of the software for the Ariane 5 could well have been expecting it to do something else entirely which would still result in a serious problem.

It's an issue of inappropriately using software in a new situation. Without knowing and account for how it behaves, you can't just use it and expect everything to work perfectly the first time around. It doesn't matter how well the software accounts for various issues - at some point something won't have only a single correct answer and the software you are using will have to pick how to behave. If you aren't paying attention to that, it can/will come back to bite you.

> Not quite. If you read the details about the case you can find that it didn't have the handler for the overflow in the calculations(!) It's similar to this case now that both were developed with under the assumptions "can't happen," in the sense, developed to be too brittle, for the inputs that were certainly possible to happen as soon as the trajectory (in the case of Ariane 5)

I'm not sure that's entirely fair. The software was intended for the Ariane 4 which wasn't intended to have as much horizontal acceleration as the 5. If the 4 had experienced such an acceleration it wasn't intended to be capable of recovering from it. That area of the code also explicitly had some protections provided by the language removed for the sake of efficiency. So it wasn't a total oversight that just happened to work out - there was a decision made based on the fact the rocket had already irrecoverably failed if the situation ever occurred.

While I agree it's somewhat distasteful not to cover all the bases in the most technically correct way all the time, I'm not sure how important it is to have an overflow handler fire in the inertial reference system just as the rocket self-destructs.

But you don't know which IMU is misreporting. Now, given the nature of the situation you could probably say it's best to err on the side of acceleration. If you've stopped accelerating and haven't initiated landing procedures you're either wrong or somehow already landed and can afford to wait.

It's also not clear to me that this was an issue of erroneous data. All they said so far was that a rotational sensor maxed out for about a second. I don't think a simple delay-and-retry would have sufficed here. When attempting to land a second seems like a pretty long wait.

I think it's also important to note that the inertial platform was developed for the Ariane 4 where it worked correctly.

The software was actually developed correctly, and functioned as intended. At least for it's intended use. Then it was tossed at a new use-case without any accounting for any differences in the new situation.

I think you're actually completely wrong about that. I think most people will assume it's an actual update when the animation moves. It's the devs that will stop to think if they're actually doing that or not, and have the knowledge to check for themselves.

> Having a 1-to-1 correspondence between types and allocators screams of lack of separation of concerns. In any case...

It's a 1-to-1 correspondence between an access type (aka pointer) and an allocator. There isn't an issue with separation of concerns.

> Arenas can be given safe interfaces in Rust just fine

I never said they couldn't. I said, they require the arena allocator to be used explicitly for each and every allocation. So if you screw that up, it's a problem.

> The article literally says: “Tasks are awesome, but sometimes they're not quite what you want --- particularly as there's no protection against two tasks modifying the same variable at the same time.”

And if you bothered to read another few sentences, you would see the article mention controlled types. These are types that exist to be task-safe. It's entirely safe.

> <bounds checking> Implementable as a library feature.

Which makes it more difficult or impossible (depending on other language features) to detect such errors at compile time. It's also much harder or impossible to optimize away the checks when possible. And finally being a separate library means it's not part of the core language. You might call that bloat, I call it good design that not only requires safety but fosters an environment that encourages safety. You can have all the best most safe features in the world, but if they are hidden off in a library then programmers must explicitly reach for them and by default start off playing around in unsafe ways. It becomes a cultural thing.

> (non-nullable pointer types)In an unusable way.

What? Care to expand? I've used them before, so they are usable in some sense at least...

> Parametric polymorphism buys you non-repetition, not safety.

Non-repetition buys you a single place to screw up, rather than many.

> Contracts don't buy you safety. Your code will just crash at more predictable places when a contract assertion fails. But it will still crash. Hard. Static analysis buys you safety.

Where possible Ada contracts are checked statically. Contracts that are checked at run-time do buy you safety too, though. Not in a given build, but unless you are in the habit of shipping as soon as you get a successful compile, having crashes occur as soon as there is a problem is a wonderful way of being able to quickly identify not only that a problem exists, but what the problem is. In terms of actual software development, it very much helps with producing correct software.

Sure, you can do things like that too in Ada. To some degree that might make sense sometimes, but having the option of an equally safe type that's used in a "normal" fashion, rather than something that has to go through the proper library interface has some advantages as well.