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.
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.
Anecdotally, it's vastly reduced debugging time in my own personal projects. My most notable problems have all turned out to be the result of things like using the wrong input, or misunderstanding some external spec. At first it was actually a little unnerving that things weren't breaking, but with time I've come to expect that. I came from C++, where I always joked that if things appeared to work correctly the first time around something serious was broken.
It's not free though. You do end up spending more time getting the compiler to actually accept your code. With time I've gotten much better at this, although at first it could be quite a fight. But a compiler error is so much nicer than a bug, so I do think it's very worth it.
And when it comes to coding, how long it takes to type is pretty irrelevant as long as you can type half decently. Typing the code is really the easiest part.
Rust can give stronger static guarantees in simpler instances. When it comes to more complex cases, neither language can guarantee much. Ada however has better mechanisms for handling them safely. For example, you can specify a particular allocator for individual types rather than relying on each allocation to use the custom allocator.
If you're outside the realm of the Rust borrow checker and want to use an arena to keep the memory side of things simple and safe, it's much easier to do properly in Ada.
Ada is also significantly safer than C. Between the much stronger type system, memory safety facilities, bounds checking, non-nullable pointer types, generics, contracts etc. it's clearly a much safer option than C.
I'm pretty familiar with most of these issues, except for the one about verbose generics. What do you find so verbose about them?
To my thinking they aren't much more verbose than C++ templates. They end up being a short little section above the place they are used. However I don't really feel like it's a verbose language in the first place (even if there are a few more characters around) so perhaps I'm just missing something entirely.
It's not just a question about the magnitude of the possible upside or downside though, it's also about how likely they are to occur. If you offer me the opportunity to almost certainly make every day slightly better with the risk of killing me at a rate of once in the current age of the universe I'm going to take it. It's a tiny upside with a massive downside, but it would be irrational not to take it given the chances involved.
Medications absolutely are controlled. That doesn't mean they don't have issues, but are you willing to suggest medications are less controlled than food? I don't need to hope I've washed my medications well enough, nor do I need to ensure I've heated them to at least a certain temperature for a length of time, nor do I need to worry about cross contamination or any such thing. This isn't to say medications are without risk, but compared to produce, meat, or eggs I have a much better idea about what exactly is entering my body when I consume it.
>All I'm saying is that going to the doctor has risks that need to be considered.
I doubt that very much. Are the risks significantly greater than the risk you likely took getting to the doctor in the first place? I'd be shocked.
Everything has risks. Maybe you change your diet and end up doing an unfamiliar food preparation and you screw it up and end up with a case of salmonella or e. coli. Or you do your usual thing and it happens anyway.
It's inane to suggest anything labeled "medication" should only be taken in life-threatening circumstances. Everything you ingest is going to have an impact on your body - some good, some bad, many both. Medications have a particularly strong impact, but are also highly controlled. You can judge the probability of various outcomes very well, which makes it a lot easier to come to a clear conclusion about using them or not.
And I'm going to assume you didn't intend to say that merely going to the doctor should be avoided except in life-threatening circumstances.
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?