> how proficient your team is in a given language and how easy it will be to maintain afterwards that are simply more important.
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.
I’d agree with this. In my experience, choosing a language/platform based on the teams experience instead of the best tool for the job is a siren song. It’s less pain upfront, but way more amortized pain over the life of the project.
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.
In agreement and I'd add that I think it is a bit arrogant to assume a more junior programmer or a team of them can't learn better programming practices.
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.
You might learn 95% in two months, but the last 5% might take decades.
One fun thing is that the less you know the more productive you are. So a good strategy is to leave before you learn how horrible your code is, don't stay longer then two years so you don't have to deal with maintainability, performance, scaleability, security, etc.
I'm all for the 'right tool for the job' mindset, but why would it be bad in principle to write an application in JS? Leaving aside the fact that modern JS is ~3x slower than C++, i.e. slightly slower than C# and Go but in the same league as Java/Haskell, not in the same league as Ruby and Python, programs like VSCode are written in JS and they have no performance issues.
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.
> VSCode are written in JS and they have no performance issues
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.
> 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).
> This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature.
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.
> 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).
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.
Thing is, I'm not advocating for performance over functionality or premature optimisation. We're talking about text editors here, as an industry we've done this before, we can write a fast cross-platform text editor, it feels like we've either forgotten this or don't care.
The thing that matters when engineering a solution using software is meeting the specifications. There's no real reason to look at the efficiency when it's not affecting whether you meet the specification.
But that's a difference between developers and engineers
> programs like VSCode are written in JS and they have no performance issues.
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.
Even if it's suboptimal from a technical standpoint, a company that went all in on an HTML/JS Frankenstein is likely to have seen more success than one that went all in on a more appropriate native desktop client. There's a reason we see a lot of the former and not much of the latter.
It's lowest common denominator thinking, which isn't necessarily wrong. If the majority of cross-platform UI code is done in HTML/JS and the toolchain is mature, that becomes the default choice and you would need a compelling reason to not use it. And that has generally been my anecdotal experience.
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.