I have a love-hate relationship with LaTeX... in 2016, I wrote my PhD with it, for wich I defined lots of helpers and commands.I used xetex for some obscure reasons I don't remember.The final result was beautiful but I dread opening any of those files. And it doesnt compile anymore.
Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.
2014 Story Time, when I was a phd student working on programming languages (apologies for my broken English, non native speaker here).
The multidisciplinary lab I was in had a "Go or Rust" dilemma. As the language guy, I was asked for my opinion.
I had no experience with Go, and a small bad one with Rust: there was weird stuff going on with pointers, and even seemingly simple programs would fail to compile due to a less than happy borrow checker. Working with Rust required a heavy learning investment. On the other hand, Go looked simple, with amazing goroutine, fast compilation time (great for the code/compile loop), and backed by a big company, which is reassuring for then still young languages.
As I could not form my opinion on significant coding experience, I looked at the principles. It appeared to me that Rust design was guided by language principles, whereas Go was guided by system/engineering requirements. For example, Rust had generic and sum types, which Go lacked. Rust error are "naturally" dealt with using sum types, whereas Go relied on error codes. Go had that "operating system flavor", with features usually closed to the OS directly implemented in the language (goroutines, which are great).
Rust had that "things are complicated flavor", in both the language (borrow checker, several kind of pointers), and the library (several kind of string?!) which at first is of-putting.
Being a language guy, I argued for Rust's good use of language principles over Go's more practical approach. My bet was that Rust usability would improve. A mix of Java/Scala was chosen. I now code in C++...
--- --- ---
A note on simplicity. Simplicity is a lie. Things (not only programming languages) are not simple, they are messy, hard. Truly hard. In my experience, simplicity claims are usually superficial, and show their limits when going a bit deeper.
As programmers, we like to have simple, generic, abstracted constructs, because it makes our life easier. But the world is not generic; it is full of special cases, corner cases, situations that do not fall in a nice hierarchy, which is its beauty. It took me too long to "accept" this beautiful complexity, and to stop fighting it. If you are still looking for simplicity, maybe check that you are not fighting the world's complexity.
Rust was very much half-baked in 2014. Version 1.0 was released in 2015, and critical features for dev UX like non-lexical lifetimes or async weren't supported at all until late 2018. In fact, Rust would've been a terrible choice back then. Lots of people seem to miss that, but it's also why this whole anti-Golang flamewar is so pointless: a lot of the Golang stuff out there is not greenfield, but was written back when there was hardly any reasonable alternative to it, and certainly nothing like modern Rust was available.
Taken from the article (probably after an update):
Many people have asked, could viruses also use the Ψ technique to beat our immune systems? In short, this is extremely unlikely. Life simply does not have the machinery to build 1-methyl-3’-pseudouridylyl nucleotides. Viruses rely on the machinery of life to reproduce themselves, and this facility is simply not there. The mRNA vaccines quickly degrade in the human body, and there is no possibility of the Ψ-modified RNA replicating with the Ψ still in there. “No, Really, mRNA Vaccines Are Not Going To Affect Your DNA“ is also a good read.
I don't fully trust my actual knowledge of C++03, I always fear to get bitten by all the implicit things happening in the background (like how the compiler will defined the default constructors -- at least I know I might get bitten, so I'll be on the cautious side). For that reason, the book my be preferable in my case...
Thanks for sharing! I'll be sure to check that book.
Even if CMake is basically a defacto standard, I have a CMake trauma... Do you have experience with things like Scons/Ninja?
For the sanitizers, I had a look at the one from google: https://github.com/google/sanitizers
Did you work with any of those, or was it something else?
I definitely have my eyes on CLion, I'll have to convince my University to get a licence as they are already bulk paying for MS Visual Studio (but that one does not work on linux...)
CMake is the defacto standard for a reason. It's a great tool. However, it definitely has a steep learning curve. It took me many hours to get it, because the documentation is, I would not say 'bad' (it's actually really good) but it's really a reference more than a tutorial. So you'll have to hunt for good tutorials on the web, and just like C++ there is an old way to write CMake and a modern way :) I can't recommend a particular tutorial but make sure they talk about 'modern CMake'.
I used SCons a long time ago. It worked but it was extremely slow. Ninja is not designed to be written by hand, it's a back-end to be used by CMake, etc.
Yes, sanitizers are now included in GCC and Clang (it's the same code base, initially developed by Google). Support varies by platform but on Linux/amd64 all of them are available. UBSan, LSan are easy to use and have little impact on performance. ASan and TSan are more expensive but they work well; not unlike Valgrind but still faster. MSan is a pain to configure because all the code must be instrumented (that includes dynamic libraries you use). Not that easy in practice.
It was not the best class ever, for sure!
That's an interesting link, I never saw that way. Probably because how I learn them too, i.e. a mandatory thing to know.
I guess that the point was, Haskell is still developing patterns for solving common problems. Many of the uses of monads could be considered design patterns.
Sort of same kind of experience. I presented myself as a problem solver, with algorithmic skills and a deep understanding of language's principles as this is my research area...
"Sure, but can you do python"
Well, I definitely can learn it. But can I do it right their, right now? I never really worked in python, so no.
Among all the systems (tools, languages, devices...) I exploited professinaly, LaTeX is the one that remains the most obscure and frustrating to me. I'm not sure why.