Cramming an api for one product on top of another is absolutely not “the open source way” I’d expect a much better explanation for this Frankenstein’s monster. This seems like it would work but never scale.
Just a few of the things you need to build if you don't do it this way. 1. A storage layer, 2. A network protocol with clients and servers, 3. A replication system, 4. an authentication system. 5. Administrative tools.
If you roll everything yourself, you pretty much have to reinvent everything PostGres has except the SQL and relational aspects.
I don't think it's necessarily (just) for a love of 80s editors. I think it's more of a litmus test that your developer experience is too tightly coupled with specific tooling.
i.e. if you can't (realistically) choose your own tools, then your experience with the ecosystem is that of your experience with the tool. No tool can be a good experience for everybody.
I think you may be projecting others' arguments onto the parent.
I did not read it as "everything should support the UNIX IDE" as much as expressing a preference for it and that it's a red flag if you can't even use standard vanilla tools (e.g. grep) to do basic things in an ecosystem.
I think it's fair to say that you should be able to edit code in your editor of choice and not have a terrible time.
Which brings back to having a language designed for poor developer experience, given that tooling support cannot be part of the overall experience.
So if for language X, if I as language designer want to provide the same experience as Smalltalk, either I consider the interaction with IDE workflows, or I design command line tooling to go along the language (e.g. Go).
And the command line experience comes back again to the universe where it is more prevalent, POSIXy systems.
So I don't think I am making false assumption here, as one cannot have it both ways.
>If basic shell commands, environment variables, a vanilla vim/nano editor etc... can’t be used to hack on your system then I think it’s far too coupled to tooling.
The above does not evince a fear of modern text editors. Nor does it equate to clinging to 1980s technology. Why do you think it does?
Why are people still flying 737's? Why cling to 1970's airliners?
Just because something was created long ago does not mean it hasn't improved. Vim and Emacs are both extremely featureful and powerful editors and many people prefer to be able to pick and choose specific tools that do their jobs extremely well.
It's not about using "old" technology - it's about using a tool that excels at its targeted task, and letting you choose the best tool for ancillary tasks like searching, formatting, testing, debugging etc.
while I agree VS Code is starting to get a lot of traction, it's far from the only solution for polyglot development (IntelliJ...) and it certainly has the facilities to support large java codebases.
Probably because most people who know JS only as a front-end developer have never had to work on the back-end. If a developer knew JS and something like python, java or ruby then sure... that's a good candidate.
