burjui

Yoy may want to check out Sean Carroll's book "The Biggest Ideas in the Universe" vol. 1. He explains a bit of calculus, how to read and understand equations etc. Basically, this book contains a crash course in physics-related math smeared out across a few chapters. Perfect for noobs like us.

I use sunglasses for that.

It indeed is a journey for the most patient of us. Or, at least, was about 8 years ago, when I needed to build gcc for the Cortex M3 target. I guess not much has changed since then, and one still has a great opportunity to learn what mpfr, gmp and the rest of scary words mean, before either giving up or pushing through that crap. It's like eating super hot peppers: first one suffers, then enjoys the knowledge that they are a tough one. And maybe an endorphin rush, if they have suffered intensely enough.

In contrary, you should stay with C++ to stay in shape. C is too simple (comparatively) to keep your mind sharp. You want what, a pleasant programming experience, like a sissy, or constant hard ass-pounding and mind games that make a real man?

As if C++ was the only statically typed language compiled to native code.

If you need a superhuman intellect (admittedly, a narrow one) in order to write sane code in a language, that means that language is no longer a good language for humans.

The current trend of slapping an AI onto everything makes me nervous about our future: why put effort into careful design when it's easier to feed terabytes of data to an AI and hope something good comes out? Nevermind that you now have to sift through tons of garbage it produces.

C++ is deeply flawed to say the least, you won't fix it with AI or anything. It's time to ditch it already.

IMHO, really there are no options for this idea other than to be disappointing. C++ is already a monster, way too complex and complicated, and unless one decides to revamp it from the ground up, effectively coming up with a different language that is no longer C++, the only way to improve the safety is to make C++ even more complex and complicated. I think in 202x's it's time to let it go, to stop layering complications and inconsistencies on top of one another. To continue trying to "fix" C++ is to continue to feed the sunk cost fallacy.

I had exactly the same side effect when turning my head, and 150 mg would also make me agitated. Also, my vision worsened a bit. But without sertraline, depression wouldn't have gone away, so the drawbacks were worth it.

A dumb one. The word "literally" is already used to specify that the phrase following it is not a figure of speech. There are plenty of ambiguities in natural languages, and layering them will only make things unnecessarily complicated.

Oh, this was written by Sean Carroll's wife. I am a big fan of his work and his podcast, Mindscape. Truly a power couple.

Or unless you iterate over randomized hashtables to produce some output, e.g. function sections in an executable. Though that doesn't change the semantics and is basically rearranging coins in your pocket.

After discovering Stewart Lee, I find most comedians incredibly boring, especially after seeing him deconstruct their usual material and delivery a few times.

- I am pretty sure that static verifiers are a subclass of static analysers.

- Prusti does not require you to write any "properties". I just ran it on a piece of code, which has no annotations for Prusti, and it still found a potential integer overflow. Maybe it has some internal annotations for std, but none for my code.

Sadly, D has its own set of problems and design flaws. It's better than C++ in many ways, but still far from Rust in terms of solid foundation in computer science and language design. Frankly, I see no point in integrating it with Rust.

And what do you mean by Rust being weakest in these categories anyway, and why do you think it is? What are "string-first apps"? And how is not adopting inheritance-based OOP a weakness? I think, many experienced programmers, especially those familiar with ML family of languages and otherwise well-versed in different paradigms, will argue that this particular flavour of OOP is more harmful than helpful.

That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful stuff in Clojure to warrant such an undertaking. Or just madness.

> "we do just fine with java"

Yeah, except they write 2-5 times more code in Java, than they would in Kotlin. I think it's unprofessional to reject a new language, that will make code smaller and easier to understand, just because somebody is afraid to step out of his comfort zone for a moment, and not because of some potential real problems.

I think you can justify anything with that stupid line of thinking: "I don't use for-loops, because a while-loop can do the same, and it's too hard for me to learn it." Sounds the same to me. Learning Kotlin is a must for any Android developer, unless he really likes to give handjobs to the Java compiler: "Oh, let my type the name of the type twice, even if it's quite long for clarity and you know it already from the right hand of the assignment. You want me to write 23 lines of boilerplate in a separate file for a POJO with 2 fields? Oh, you dirty boy!"