Comment by mihaic
2 years ago
For me, the closest modern successors to the Borland suite are Visual Studio (not VSCode) and the Jetbrains IDEs. The feel like they're the only one with a holistic, batteries included, design that actually focuses on debuggability.
I actually feel that the terminal-based focus of modern FAANG-style development actually hindered proper tool development, but I was never able to explain it to anyone that hasn't used Borland C++ or Borland Pascal in the past, except maybe to game developers on Visual Studio.
C++ Builder versus Visual C++ for RAD GUI development.
I never understood why Redmond folks have so hard time thinking of a VB like experience for C++ tooling, like Borland has managed to achieve.
The two attempts at it (C++ in .NET), and C++/CX, always suffered push back from internal teams, including sabotage like C++/WinRT (nowadays in maintainance as they are having fun in Rust/WinRT).
The argument for language extensions, a tired one, doesn't really make sense, as they were Windows only technologies, all compilers have extensions anyway, and WinDev doesn't have any issues coming with extensions all the time for dealing with COM.
Or the beauty of OWL/VCL versus the lowlevel from MFC.
DevDiv vs WinDev. The Windows group maintains the C++ compiler. So you get the resource editor for dialog templates and that’s about it. And that actually got worse from Visual Studio .NET onwards, my guess is that it got took over by the DevDiv people when they unified the IDEs.
Yes pretty much that.
Windows could have been like Android, regarding the extent of managed languages usage and NDK, if DevDiv and WinDev had actually collaborated in Longhorn, but I digress.
out of the loop, how is terminal-based development related to FAANG?
I guess it's caused by the "brogrammer" culture of Silicon Valley, where you would get hazed if you dared using a GUI-based tool. Also, being more focused on open-sourcing their tools (because other companies do not open source them, therefore being un-cool), which begets a "simpler" and "engineeristic" approach to UX, which do not need UI experts and designers.
Lots of companies end up with their own internal tooling. They have their own build systems, packaging systems, release systems, version control, programming languages, configuration languages, everything.
Some even have their own editors.
There is a lot of value in picking a transferrable editor and using that. From that point it becomes "what is the best editor that will _always_ be available". Emacs/Vim fit that.
Then the muscle memory can begin to grow, and there is one less bit of friction in starting a new job.
One of the best pieces of advice I received was "pick an editor and go deep".
> One of the best pieces of advice I received was "pick an editor and go deep".
Agreed, I'd be infinitely less productive if I couldn't use the editor I learned to master in the past 20 years.
A corollary to that would be "pick a company that lets you use your own editor". There's lots of friction from IT departments towards emacs and vim. The package/plugin system is a security nightmare with lots of potential supply chain attacks and more importantly no trusted vendor to blame when something goes wrong.
It became sort of a hackerish trend in the past decade, usinga hyper customized (neo)vim in lieu of an IDE.
Except maybe Apple, all the others are service-oriented companies. They run heterogenous pieces of code on their servers and their ideology is “move fast and break things”. It’s a hipster culture that reinforced the use of 1980s “video terminal” editors and CLI tooling because they were supposedly more flexible for their workflows.