A Zero-sum game is a situation where for one contestant to win or gain, the other contestants must lose or have a loss. Thus for contestant A to have a +5 then contestant B must have a -5, resulting in a sum of 0.
Programming languages, and the battle for supremacy, is not such a contest. Many developers know more than one programming language, and they use different languages for different situations. Different languages influence each other; Delphi heavily influenced C#, and then C# influenced Delphi. Even when one language doesn’t change another, knowing one influences how we use the others.
Liking one language does not mean all other languages are garbage. Celebrating the benefits or advantages does not discount strengths of other languages. Not all languages are equal. They all have strengths and weaknesses, advantages and disadvantages, and that is what makes it great to have so many languages to choose from.
I used to prescribe to the idea of “we are the best because everyone else sucks,” but not anymore. What makes us the best is the progress we make and the projects we complete. Celebrating the success of others doesn’t diminish our success, nor does it keep us from competing or innovating.
Anders Hejlsberg is frequently quoted as saying “we all stand on the shoulders of giants” when talking about the influences of different programming languages on each other. If we don’t strive as developers to be bigger and better, then we are no longer giants with shoulders to stand on. We do a disservice to not compete and grow and do the best we can. It is when we innovate and build on others that we make the world a better place.
6 replies on “Sum(Programming Languages) > 0”
An interesting post but a reflection on the wisdom of trying to succeed by wearing the clothes of your competitors (or trying to) might be even more revealing.
As you yourself say, not “all languages are equal” and the biggest mistake that Embarcadero has made with Delphi in recent years is to try to fly in the face of that and make Delphi equal, casting envious eye over the managed fence and trying to shoe-horn things from the other side that they covet (or think that their users – more potential than current – do) into the language that simply don’t fit.
The problem being, that once you have polluted a language with the results of such misguided thinking, there is no way back. You can’t unscramble eggs.
While not all languages are equal, they also influence each other. That influence and learning from other languages is what makes the whole ecosystem amazing! It is a good thing to see what works great in other languages and tools and find a way to adopt them.
What new features specifically do you take issue with? If mobile doesn’t float your boat, then don’t use it.
Just one recent example of the half-baked mess that the Delphi language has become. If there are compelling reasons that these sorts of “features” were added other than “we wanted to have them so that we could say we had them because other languages have them” then I have yet to hear or see them.
There’s languages influencing one another, and then there’s languages slavishly copying syntax and half-assedly copying the semantics without full consideration of the implications on the existing language and how – at least – such a feature should best be introduced.
It is a shocking indictment in a case such as this that the Product Manager of the compiler itself cannot say with 100% certainty – as is confessed in the comments on this issues – whether a compiler behaviour is desirable or not. You would have thought that some thought would have gone into what a compiler should or should not do with a feature that is being introduced, especially when the area of impact involved is one that is such an obvious conflict with the existing language features, as in this case.
@Jolyon I cannot see how that example supports the point you are trying to make because if I am not overseeing something that behaviour should be the same in 10 years old Delphi versions.
@Stefan It’s not against new features. It’s the way, how it is implementet. Delphi had great potetial, but EMB did implement it half backed or not the Delphi way. For Example: LiveBindings. So much RTTI stuff which is a nightmare if you have to refector your code …
@Stefan, I am pretty certain that the “static” directive as applicable to class methods did not exist in Delphi 10 years ago.
Now it may not be an entirely “fresh” example in that this language change was introduced some time ago (albeit not 10 years), but that makes it even more questionable that the Product Manager – with a background as a supposedly experienced Delphi user to boot – is still unsure as to what is or is not desirable behaviour.