111–120 of 193 posts
Earlier quoted context omitted.
All software has bugs. Any half arsed developer can create a lot of them in any language. C alone doesn't guarantee anything. Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back?
Yes, you're right. Tools don't matter at all. /s
Well the fact that C is going so strong guarantees we'll be dealing with easily preventable bugs for the next 100 years
All software has bugs. Any half arsed developer can create a lot of them in any language. C alone doesn't guarantee anything. Heck maybe there's fewer because C devs don't get lulled into thinking the language has their back?
You make the serious mistake of assuming all or the majority of C devs know how powerful the language is, or how to properly use a language like C. All software has bugs, true. It's just that C bugs tend to be a wee bit more dangerous than a lot of other bugs because of the raw power of low level languages like C.
Writing secure code in low level languages is tough, and it requires knowledge of all the pitfalls and nasty corners of the language, which many devs don't have the time, interest or desire to learn.
Earlier quoted context omitted.
C is a tadpole in the ocean of easily preventable bugs.
Then why do we see a major internet security bug that would be simply impossible in any other language every couple of months?
C++ comes to mind for writing browser engines, but those have their fair share (if not more) of security issues as well.
Well the fact that C is going so strong guarantees we'll be dealing with easily preventable bugs for the next 100 years
Or moving to C is something so exceptional nowadays that it warrants an explanation and thus gets included in this matrix, whereas everybody and their dog thinks moving away from C is the most natural thing in the world and doesn't blog about it.
Am I reading this incorrectly, or there is more movement from Swift to Objective-C than the other way around? Do I sense a methodological error?
So maybe that's a flaw in the whole exercise: it's only taking into account remarkable/unusual language switches, the ones people think are worth writing articles about.
Earlier quoted context omitted.
Or moving to C is something so exceptional nowadays that it warrants an explanation and thus gets included in this matrix, whereas everybody and their dog thinks moving away from C is the most natural thing in the world and doesn't blog about it.
If that were true wouldn't we see greater results from C to X? Seems like people are moving away from C less often than Java or even Python strangely enough
The research methodology in this blog post is fundamentally flawed. The author only counts how many people move from X to Y, but he doesn't count how many of them do not move at all. The whole diagonal of his (sample) transition matrix are actually missing values, but he treats them as zeroes. This greatly distorts the equilibrium distribution. As a result, he misinterprets each equilibrium probability as the "future…
> when it at best only represents the future popularity of a language among those who constantly switch their languages. This is literally in the title >The eigenvector of "Why we moved from language X to language Y"
Am I reading this incorrectly, or there is more movement from Swift to Objective-C than the other way around? Do I sense a methodological error?
1. Movement from Postgres to MySQL
2. Movement from Mariadb to MySQL (and NOT the other way around?!?)
3. Movement from PHP to Java (I remember the sort of people leaving Java for PHP 10 years ago, and I don't think they'd go back, or that PHP people would pick Java as their choice to move to)
I think maybe he has the axes labeled wrong?
I appreciate that the author wanted to implement their own eigen vector/value method, but really they should use: numpy.linalg.eig(x)[0] numpy.linalg.eigvals(x)[0] Numerical stability can be hard to get right...
Yes, but... The matrix has all non-negative entries, and the author is after the highest eigenvalue/vector so I think this means stability is just not an issue. The only possible issue is time to convergence. The nice thing about the power method is its conceptual simplicity. In cases like this, it's quite hard to screw it up. And it will scale far beyond those numpy functions (not that this is needed for this exampl…
It's actually the second highest eigenvalue. The highest eigenvalue is always 1 for stochastic matrices.
Earlier quoted context omitted.
Good Luck with your precious Rust to be compatible with your client's millions of lines of code. For larger, and legacy project, maintainability and continuity is the overwhelmingly top priority, being flashy is the least of their concern.
Writing Rust off as flashy is demeaning to the excellent work that has been going on in the Rust ecosystem to specifically address the area you mention with a safe language alternative.