Developers can continue to build Chrome apps and eventually Android apps for Chrome OS, when Google Play store is brought to Chrome OS. However, I agree there is the problem of losing incentive to maintain a native Chrome app from the developer POV.
I have the same problem. Then there are so many tabs and I have to use a Chrome extension to automatically save and close inactive tabs. Guess I should set some time to look at that limbo place.
If you write your project that even has no circular deps among files and all files are small (like me in https://github.com/h8liu/e8vm), you can draw the similar graph but at a much finer granularity, like this:
dependency graphs and code analysis are huge topics. this is probably the hard part with libraries like npm or Bundler.
the graphs can have cycles, multiple references to the same dependency, multiple distinct versions of the same dependency, et cetera. it's also all very, very language-specific. in many languages, the order of the require or import statements matter; in others, they don't. you can also have something like Clojure, with several different ways of bringing in a dependency, which makes the whole issue much more fine-grained.
prior to writing these scripts, I tried to do something more ambitious with auto-refactoring tools. these exist in Eclipse and can even be graceful in Smalltalk but my own results were not so amazing. I got somewhere with regular expressions, code generation, and shell scripting. but I also built a thing in Ruby which could auto-refactor a tiny, TINY subset of the most obvious refactorings in JavaScript. it took me months, maybe harmed my sanity, and was definitely not the best code I ever wrote.
I am under the impression that a large part of engineering effort at established companies go into porting existing components to a deemed to be more appropriate language for that task.
Is it plain impossible to pick the best fit language without implementing a solution in the first place and fleshing out the requirements and challenges that specific to the problem space? Or do the problems evolve fast enough that no matter how well you design the system, it will need to be deprecated once in a few years?
It's rarely "just" a port. It's usually because the new language has better characteristics. These days porting can be a very gradual, as-needed process - partly because of thrift, another Facebook tool!
One of the big parts of becoming a professional for me was accepting that code has a lifecycle; code is written to make the business money at the time, but it's entirely normal for it to change and die as time goes on.
(That said, you should just write everything in Haskell and then you won't have these problems. When was the last time you saw a company port code away from Haskell?)
It's tricky picking a "best fit language" when you're not sure at project inception what you're fitting it to. Say, for instance, that you're developing v. 1.0 of an application in a new application space. Your CEO catches wind that another company is looking to enter that same space. She is also adjusting requirements to find a business model that works. You would choose a development stack that allows rapid prototyping and refactoring.
Once you win user-share in the space the application starts having problems with scalability or debugging becomes an issue or a myriad of other problems that come with success. Now you need to consider writing parts (or possibly the whole application) in a development stack that allows greater scalability or has built-in semantics for core functionality in your application, thus allowing less reliance on 3rd party libraries, etc.
The other factor is that the team who authors an application may have a totally different skill set from the team who takes over the mature application. The authors may have been VB developers with good SQL skills. Your current team has more people who have dealt with Haskell in large-scale applications.
There is some parallel to home-building. A homeowner does a room conversion for more space, more privacy, etc. The builders of the home didn't install tracks and sliding-panel walls for better room configuration. At the time, they didn't see a need. The homeowner now has a need, so he goes through a much more expensive (relatively speaking) building effort.
The problem with this is just how often the story seems to involve porting of solutions. Not necessarily refinement or advancement, but pure porting. With lots of debate/fighting on the syntactic properties of the solutions.
All software tends to unmaintainability, even if you don't touch it (libraries change/deprecate etc). Given enough time, the problems that you are experiencing, say, memory allocation in C, get solved by something else, such as garbage collectors, and the amount of time it takes to solve the headache in what you've got is longer than just rewriting into the new language.
