mrcsd

Logged in just to say, for me reaching into my past has been one of the most transformative and healing acts I've ever done.

I really disagree with the straightforward reduction of engineering to 'math but practical', but I'm finding it hard to express exactly why I feel this way.

The history of mathmatical advancement is full of very grounded and practical motivations, and I don't believe that math can be separated from these motivations. That is because math itself is "just" a language for precise description, and it is made and used exactly to fit our descriptive needs.

Yes, there is the study of math for its own sake, seemingly detached from some practical concern. But even then, the relationships that comprise this study are still those that came about because we needed to describe something practical.

So I suppose my feeling is that, teaching math without a use case is like teaching english by only teaching sentence construction rules. It's not that there's nothing to glean from that, but it is very divorced from its real use.

I don't think this is quite the same comparison. In Rust, multiple mutable pointers to the same object can exist at the same time. So, it's similar to C in this way. It is mutable references that must be exclusive.

Words are not reducible to technical statements or algorithms. But, even if they were, then by your suggestion there's not much point in talking about anything at all.

This is abhorrent. The feeling of safety underpins emotional well-being. What you advocate is only the repetition of past suffering. Without safety, what is left but fear?

I am often left confused by responses like this. I think it would be fair to suggest that some significant percentage of chidren suffer in schools or have harrowing experiences that they are going to carry with them through life until dealt with. If this is the case, why on earth should a conclusion about school _not_ be drawn? I don't believe you are meaning to suggests that the situation as it stands doesn't need change, but that is nonetheless implicit in your statements.

From my position, saying: "I'd be wary of drawing too many wide-ranging conclusions about school education as a whole from it." Comes close to invalidating the experience of another.

I'm 34, grew up in London, went to state primary school and private secondary school. dijit's account of schooling ressonates strongly with me.

If all disrespecting is to belittle and look down upon, then fair enough, I agree with you. What I meant, in perhaps an ill-phrased manner, was that overemphasised respect can often lead to stasis, where people might not want to change in case they are seen as disrespectful. Hence my use of disrespect, in that it is a relative judgement, and which can and has been used to discourage creative difference or just difference in general.

Disrespect is part of progress, respectful humans are liable to blindness of flaws. Just as part of youthful creativity is disregard for what has come before.

So, just like normal then?

I don't disagree with being cynical about social media, but community belief is the overwhelming mechanism by which fact is decided throughout history, including now.

Care to expand upon the issues you were running into with hypothesis? I'm genuinely curious as I may soon be evaluating whether to use it in a professional context.

Surely an ability to balance requires that both sides of an issue be deemed somehow legitimate, no? In which case, surely there must be some sort of "right" which forbids injuries to nature, without which there can be no legal standing to prevent such injuries. In other words, why is there a procedural right to pollute and yet no right to stop pollution?

> Writing a substantial amount of unsafe Rust really sucks the beauty out of the language.

I really disagree with this take, given the examples of unsafe code the article chose to exhibit. Trying to write C in Rust totally goes against the grain of Rust's ergonomics, which are oriented towards discouraging unsafe code patterns. It should be a pain to attempt something dangerous, and it should feel really easy to write safe code, because this setup naturally encourages the vast majority of code to be written safely.

I agree with the spirit of your comment, but not the literal fact of it. Sure, interesting proofs require pulling out some interesting knowledge in the reasoning, but notions like "surprising" or "interesting" are about human subjectivity and don't really exist as a property of a deduction. Surprising or interesting knowledge is not somehow new knowledge that wasn't there before, it's just that we didn't see it previously.

Just thinking on my feet as to how I separate abstractions from indirections and it seems to me that there's a relatively decent rule of thumb to distinguish them: When layer A of code wraps layer B, then there are a few cases:

    1) If A is functionally identical to B, then A is a layer of indirection
    2) If A is functionally distinct from B, then A is likely an abstraction
    3) If A is functionally distinct from B, but B must be considered when 
       handling A, then A is a leaky abstraction.

The idea is that we try to identify layers of indirection by the fact that they don't provide any functional "value".