The author is surprised that angular is holding up. I've been learning angular2 the past few weeks after having never used a single page application framework before and I'm loving every second of it. I'm never going back to ASP.NET MVC except to use it as an API.
The eigenvector of “Why we moved from language X to language Y”
21–30 of 193 posts
Re: The eigenvector of “Why we moved from language X to language Y”
#22Earlier quoted context omitted.
Really? Why can't the C bits be replaced with e.g. Rust?
They could be. But you'd need a reason in order to be able to fund it (or maybe you just want to scratch an itch). But the codebase numbers in the 100's of millions of LOC, and replacing that with Rust (or anything else for that matter) will come with a number of requirements: - it really needs to be better in terms of bugs - it needs to be about as fast or faster - it would have to come with similar start-up times f…
The Linux ecosystem was created with the userland already having being rewritten from scratch, by the GNU Project. Then a Finnish student came along and wrote a kernel. So you can probably start anywhere, but maybe starting with a working kernel would be better.
Linux doesn't really resemble UNIX anymore. It's starting to look a little like Plan 9, to be honest... give it 20 more years.
Re: The eigenvector of “Why we moved from language X to language Y”
#23Anyone else routinely roll their eyes at "why we moved from x to y" blogs?
They are always just "We wanted to do this in a particular way. So we fought the framework till we decided to move to another that does things the way we thought they should be done. Now things are much better but we will fail to mention down the line all the new compromises we have to deal with"
Re: The eigenvector of “Why we moved from language X to language Y”
#24The author is surprised that angular is holding up. I've been learning angular2 the past few weeks after having never used a single page application framework before and I'm loving every second of it. I'm never going back to ASP.NET MVC except to use it as an API.
Consider vue js https://vuejs.org/v2/guide/
* I find the template syntax is more sensible than react.
* It's not as total as angular. You can use just the small parts you'd like.
Re: The eigenvector of “Why we moved from language X to language Y”
#25I really appreciate his method of breaking it down per-niche.
When it comes down to it, all languages are DSLs. Even LISP/Scheme are DSLs for making DSLs (like Butterick's "Beautiful Racket" earlier today).
Presenting them as per-niche directed graphs is probably less likely to steer newbies (and sadly, not-so-newbies) into another round of "let's redo everything in X!"
Re: The eigenvector of “Why we moved from language X to language Y”
#26Anyone else routinely roll their eyes at "why we moved from x to y" blogs? They are always just "We wanted to do this in a particular way. So we fought the framework till we decided to move to another that does things the way we thought they should be done. Now things are much better but we will fail to mention down the line all the new compromises we have to deal with"
This is not a "why" post. He did an N x N contingency table of how many people moved from language X to language Y, then rendered his findings as a set of directed graphs.
Re: The eigenvector of “Why we moved from language X to language Y”
#27The author is surprised that angular is holding up. I've been learning angular2 the past few weeks after having never used a single page application framework before and I'm loving every second of it. I'm never going back to ASP.NET MVC except to use it as an API.
> I'm never going back to ASP.NET MVC except to use it as an API
Angular isn't going to help you write your server. That's such a strange statement.
Re: The eigenvector of “Why we moved from language X to language Y”
#28I really appreciate his method of breaking it down per-niche. When it comes down to it, all languages are DSLs. Even LISP/Scheme are DSLs for making DSLs (like Butterick's " Beautiful Racket " earlier today). Presenting them as per-niche directed graphs is probably less likely to steer newbies (and sadly, not-so-newbies) into another round of "let's redo everything in X!"
Agreed. Nevertheless, everything will be redone in JavaScript, by the look of things.
Re: The eigenvector of “Why we moved from language X to language Y”
#29The 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 popularity" of a language as well, when it at best only represents the future popularity of a language among those who constantly switch their languages.
Re: The eigenvector of “Why we moved from language X to language Y”
#30Earlier quoted context omitted.
Sadly getting rid of C means getting rid of UNIX, as they are symbiotic and UNIX vendors will surely never rewrite them in anything else or replace POSiX standard.
Really? Why can't the C bits be replaced with e.g. Rust?
No because UNIX requires C semantics, so even if someone writes a UNIX like OS in Rust, Ada whatever language it might be, for compatibility with UNIX software it would require a POSIX API to be available.
POSIX is defined in terms of C semantics, which includes C unsafety, like managing pointers and the respective length as separate entities, using null terminated strings or casting void* to specific data structures.
Which means the POSIX translation layer would need some sprinkles of unsafe code to be able to comply with the required semantics, thus opening it to the same exploits as C code.
This issue is visible in OS that aren't written in C, but do expose POSIX runtime layers like mainframes.
As mainframes, they usually restrict possible security exploits thanks to running POSIX applications on their own containers or enclaves.