AlexDenisov's comments

AlexDenisov | 1 month ago | on: Ask HN: What are you working on? (February 2026)

Building a tool for finding scientific papers behind real-world OSS projects: https://papergrep.dev/

This is a follow up to an idea I had years ago https://news.ycombinator.com/item?id=13022649, which is now semi-automated (with lots of manual curation as the last step).

The biggest challenges:

- how to organize all this info in a nice way

- where to find more time to read all the gems I've found so far :)

UPD: formatting

AlexDenisov | 6 years ago | on: Mutation testing based on LLVM (2018) [pdf]

This is a valid concern, for sure. In fact, these are called Equivalent Mutants. We observed it several times, here are some examples. You flip the if/then branches and the code essentially does the same, switching from a fast to slow implementation of the same algorithm. Another example is mutating the code in a C++ destructor, which is not easy to test.

With that being said, even despite the equivalent mutants, you can get a pretty good insight. Here is an example of finding from a proprietory real-time OS used in the space industry: https://gist.github.com/AlexDenisov/b5d2e23457b88813b5ab9d5d... (this is a part of an email which I could safely post online).

AlexDenisov | 7 years ago | on: Ask HN: Who is hiring? (August 2018)

PTScientists GmbH | Software Developers and Engineers for Space Industry | Berlin, Germany | ONSITE | Full-time | https://ptscientists.com

PTScientists is a private space company based in the vibrant city of Berlin. We are currently growing our team of engineers to support Mission to the Moon – which we hope will be the first privately funded mission to land on the lunar surface. We are working with key technology partners Audi and Vodafone Germany to enable a range of scientific, technological and cultural firsts with Mission to the Moon. Our team is made up of smart, passionate and ambitious people and we are proud to be contributing to the next chapter of space exploration.

Current openings:

Associate/Senior Software Developer: https://ptscientists.com/careers/associate-senior-software-d...

Embedded Software Engineer C/C++: https://ptscientists.com/careers/embedded-software-engineer-...

FPGA/Embedded Developer: https://ptscientists.com/careers/fpga-embedded-developer/

AlexDenisov | 8 years ago | on: Ask HN: Who is hiring? (May 2018)

PTScientists (http://ptscientists.com) | FPGA/Embedded Developer, Electrical Engineer, GNC Engineer | Berlin, Germany | Full time, ONSITE

PTScientists is a private space company based in the vibrant city of Berlin.

We are currently growing our team of engineers to support Mission to the Moon - which we hope will be the first privately funded mission to land on the lunar surface.

We are developing the transport and communications infrastructure required to enable future lunar missions and possible human settlement.

Find out more about the company and current openings here:

http://ptscientists.com/careers/fpga-embedded-developer/

http://ptscientists.com/careers/electrical-engineer/

http://ptscientists.com/careers/gnc-engineer/

AlexDenisov | 8 years ago | on: Uncle Bob and Silver Bullets

I think this is a fallacy. I believe another pipeline does not necessarily produce better doctors. They also make mistakes; sometimes those mistakes cost people lives.

AlexDenisov | 8 years ago | on: Uncle Bob and Silver Bullets

Exactly, this is what I mean by "do not scale." It takes many years, if not decades for one to become a decent developer. We simply cannot afford this.

AlexDenisov | 8 years ago | on: Uncle Bob and Silver Bullets

Discipline is a good thing, but it does not scale.

I work on a tool for mutation testing for C/C++[1] for a few years now. During this time I was thinking about tests, tools, people, etc. a lot. Here is the summary of my musings:

Quality of software depends on several factors such as hardware, operating system, programming language and tooling used to build the software in the first place, etc. For decades we try to improve each of those aspects. But, the most significant and most harmful factor is the human. Naturally, we cannot improve developers, but we can decrease the destructive influence of a human being by using better tooling.

[1] https://github.com/mull-project/mull

AlexDenisov | 9 years ago | on: Resources about programming practices for writing safety-critical software

I have seen so many comments and references like this one, so I went and read the whole investigation report.

1. There was a spacecraft (MCO) and a module that was sending some data from the Earth.

2. The module was delivered late when MCO was on its way for 4 (!) months already before that staff manually calculated the needed data.

3. Some teams switched into "defensive mode" not willing to communicate and fixing the problem when it was clear.

page 1