HerrmannM's comments

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.

Great work! I'm curious about what could be achieved in this space in the future.

I'm curious about why you cannot share the GTA5 mod and collection script? I'm curious about that part too -- obtaining good data is always hard.

Cheers and all the best!

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.

In the end, I went for

- Principles and Practice Using C++ by Stroustrup, covering C++11:14

- C++17 - The Complete Guide by Nicolai M. Josuttis

- using CLion

Going back in time; good tip!

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...

All right, thank you for the feedback!

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...)

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.

Now I mostly wonder why/how did they get so big.

I did a bit of haskell, but not that much. From what I could see, it was more about stack of monads and compositions... Can you elaborate a bit?

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.

And so... no.

Joke aside, it is supposed (I have some interesting bugs at the moment) to be an evaluator for the pure lambda calculus. So, I guess you can encode monads in it, but that is not really the point, and I definitely did not make an example with monads. I'll try to do such an example later.

Of course not, monads are so 20th century... The October 2019 way is to only work with stacks of TripleZippersInvertedStateTransformerLens, and I know you know it!

A tricky beast indeed! No, the formal proof is a work in progress, so I'm also looking for counter-examples. And since posting on hackernews, someone found some problems (thank you so much Ekdohibs). However, there is for sure an implementation issue so they do not count as counter-examples yet. I'll investigate and fix that asap, then we'll see...

I'm glad you find interest in this work.

Thank you for the links, I did not know we could do computation with... chemistry! As I'm not familiar with that, I do not understand everything. Can you point me to a list of the interactions of your system?

Formality indeed looks promising. I still have a lot to learn about EAL in order to forge my opinion, but maybe it is the "sweet spot". For example, Formality does not need a GC, whereas Éole does, which is time consuming. On the other hand, Éole (if it works) is completely general. But then, not being "completely general" isn't necessary a problem, and Formality seems to do very well.

Please note that Éole is not proven yet, and I'm looking for counter examples that might settle the case. I will actually be happy if someone "break" the system!