That does not mean having a favorite paradigm or language is useless, of course I love Rust and I find functional programming elegant, but if you are working in a 5 years old app written in C# in a place where no one knows F#, then that should be part of your considerations.
That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HTML/JS than C#/.NET, Qt/C++ etc.
What should be just one of the factors has become the most influencing factor.
It's true that performance is often ignored for no good reason at all, but it's not such a pressing concern for most applications. Very little software needs to be performant to the point that what language it's written in even matters.
here it is compared to qtcreator. it is so damn frustrating when you are used to computers responding near-instantly to have something that... takes its time or stutter to say the least
I really dislike having to use microsoft stuff. No, I don't want to install the app. no I don't want to enable what you think I should enable. No I don't want cortana reading my email messages. No I don't want to use your OTHER product too.
VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as they can.
This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature.
Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switched away from ST3 because the development of their current version stagnated, and there are unresolved bugs and limitations that affected my everyday usage.
In other words, the performance/features (and let's throw flexibility) balance of VSC is, for me, better than ST's (others may have have different requirements and different balances, of course).
Ultimately, VSC is a bad example of tradeoff performance/ease of (internal) development. If people wants to find an example, Slack is by far the best (worst).
I don’t think this has to be the case. I’ve found that it’s not really that much harder to develop in a language like C++ compared to JS. You can develop the same feature set using better tools and end up with a more performant product (plus you get a typechecker). Performance is a feature, and if you use good tools and a language that enables efficiency without much effort, it doesn’t have to be a fixed cost added on to development.
Writing similar imperative code in C++ as you would in JS with no effort spent on optimizing is almost guaranteed to be much, much more efficient. I guess my point is that to some extent performance vs. more features is a false dichotomy.
That's a part of the problem. We're so used to web apps that many of us just learned to live with constant delays and simply treat it as a part of our lives.
But that's a difference between developers and engineers
Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with a veteran.
Okay, sure there are exceptions with very different paradigms. Kotlin devs may take more time with low-level memory managed C code. C hackers may struggle with Haskell. But Pythonistas can write pretty good Typescript in their first week.
In contrast starting with wrong tool for the job, just gets continuously worse as the project progresses. The friction of constantly cutting against the grain is an accumulated drag. As the project grows more complex, the kludges and workarounds become an increasingly heavy burden on a day-to-day basis.
A good lead will demand good code and support it with mentoring, pairing and time to refactor.
It still doesn't give them license to do tech for the sake of tech. Every architectural choice and added complexity has to be justified by the value it brings.
But programming for the lowest common skill level on a team is generally a bad idea.
When I program I basically think in terms of abstraction and state - if the code is obviously going to be multi-threaded then I will focus on the latter. Being stateful can slow you down on one thread but fuck you hard if it's in multi-threaded environment. Abstraction should really be free if you know what you're doing (in your language if choice I suppose)
Functional programming while a valid form, is inherently better expressed by constraining the possible use cases. It's closer to electrical engineering or mechanics then "programming."
"Programming" inherently rewards extendability, interoperability and readability, therefore it rewards OOP. Now obviously computers have Both mechanical and extendable use cases so it's up in the air.
Stuff that's written better functionally tends to be optimized into oblivion very quickly, it becomes more of a hardware/math/physics problem. But you know that's fun too.