48 karma · joined October 1, 2016
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?
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 don't know if this is because Google and DuckDuckGo require different phrasing of terms to do well and I'm just highly adapted to Google, or if it's something I can't help.
- In practice I don't find the case insensitive identifiers to be much of an issue. GNAT (and perhaps other compilers?) will check for consistent casing if you ask. I'm pretty happy with that middle ground - things that look different are different, and you don't have identifiers that vary by case only.
- You're right that it was designed to be able to accept a garbage collector, but it was never intended to be required either. If you really wanted it, you could try targeting the JVM. I haven't found anybody with much experience with it, but it does look like an option. Apparently there is also a 13 year old patch for GCC GNAT [1] but I imagine that's mostly a historical curiosity.
- I've gone back and forth on this one. It basically treats classes as any other type, which I like. It would seem pretty strange if you had to change to completely different syntax structure for declaring a tagged or non-tagged type. So if you wanted to do a more traditional 'class' syntax for tagged types, you'd need them for non-tagged types too. That could be both strange and nice. But that wouldn't really fly with the way primitive operations work right now - it can be primitive for more than one non-tagged type, so where does it go? It's actually a pretty complex issue that would have a large impact on some core parts of how the language works. The rules around this sort of stuff are probably some of my least favorite parts of Ada. It's a lot more implicit than the rest of the language, which has gone out of the way to be explicit. I don't think it has an easy syntax-level fix though.
Hopefully Nim works out for you, but I found it seemed to mostly be inspired by a few of the complaints you just raised about Ada. It also seems to lack the things I enjoy most about it.