5 ms·

C++ succeeded because it was Object Oriented, people didn't start talking about RAII as C++ killer feature until years later python succeeded because it wasn't

by systems 1mo ago

C++ succeeded because it was Object Oriented, people didn't start talking about RAII as C++ killer feature until years later python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened swift succeeded because apple pushed it to replace objective c, that if you consider swift succeeded anyway, i agree with your premise, languages need one key strategic advantage feature to succeed, but you just got it wrong on few of them .. and if i am wrong too, then the premise is weak, if we are not sure what the killer feature is, we then have no idea why the language succeeded

Zak 1mo ago
I don't think C++ succeeded because it was object-oriented. I think C++ was object-oriented because classes were an abstraction that could layer on top of C with fairly low overhead, giving it more expressive power without much mandatory cost to size or speed. In other words, object-orientation was the means, not the end.
- mojuba 1mo ago
  Agreed and that's probably the second major killer feature of C++.
- IsTom 1mo ago
  Back then OOP was all the hype and inheritance was cool.
  - Zak 1mo ago
    C++ predated the OOP hype cycle and triggered, or at least accelerated it.
shagie 1mo ago
> python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened Ruby allows (and to some extent encourages) unreasonable code. It's not bad code (and in some cases extremely elegant), but it's code you can't reason about. Being able to open any class (or object) and add new methods to it makes tracking how execution works extremely difficult. The language allows for very undisciplined things to work - its great for the "scripting" and rapid prototyping - but unless you're going to throw it away the next day of having to maintain that code it starts weighing on the future speed of working. Undisciplined code can be handled by making sure everyone on the team is disciplined in its use and documenting how things work... but that rarely reflects reality. And so, you move to a language that enforces more discipline in how one uses it and is more reasonable in its execution.
- smaudet 1mo ago
  Ruby felt like a better Javascript, but JS ran in the browser, and so had the constraint of the DOM... Aka you have to be (more) disciplined within the constraints of the browser. I'm not saying JS was good... The lesson here being, complete freedom is fine, as long as you are also able and willing to implement a strategy to verify your operation, ruby on rails, js in the browser, python PEP or pythonic ways...
  - shagie 1mo ago
    I came to ruby from the perl side. It was "here's a Redmine server, here's a feature request for one of the in house built plugins." I forget the specifics (it was 2011) ... but trick of the feature was to add a function to the object being created so that it would have the function some other module was expecting. And it worked... Things like that made me give it the sideye for anything more than I could keep in my head at once... if I started needing to look at other files to determine if there was anything odd there... "can I create a function here in this parameter passed to me? What if someone else created a function of the same name before they passed it to me and expected it to remain?" It can work... but it requires a bit more discipline than the developers I was working with had as a baseline (for that matter, a decade and a half later at a different job with a lower baseline and AI code - the idea of that terrifies me). It's a "powerful" language, but I think it has too much power. I like groovy for much the same reason that I liked perl and ruby (to an extent) - but it too is too powerful. It's great for writing scripts where it's a file or two or three... but if the "what does it do" gets too large to keep in my mind at once then it requires more discipline. I like to think that I have that discipline when working solo in groovy (and people will tell me I don't need to be that explicit in the objects... creating a class file rather than just shoving anonymously built objects into a hashmap), but that's how I can come back to old code more easily. Ruby Conf 2011 Keeping Ruby Reasonable by Joshua Ballanco https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs Abstract Heresies : First-class environments https://funcall.blogspot.com/2009/09/first-class-environments.html https://funcall.blogspot.com/2009/09/first-class-environment...
jandrewrogers 1mo ago
C++ succeeded twice. Initially, it provided a thin object-oriented abstraction over C. This solved many problems scaling large C projects. It set baseline expectations for languages that came later. Being a "thin object-oriented abstraction over C" has significant limits. By the 2000s, it was clear that C++ couldn't scale complexity in the way we needed it to. It was slowly dying. C++ reinvented itself as a functional metaprogramming language starting with C++11, providing an even higher level of abstraction. Many deficiencies in the older language and systems languages generally were addressed. This was a huge success, creating a large resurgence in adoption and setting new expectations for what a systems language should be capable of. C++20 looks like a completely different (and much better) language than C++98. I view C -> legacy C++ -> modern C++ as the evolution of a single language. Each was wildly successful on its own up to some level of complexity. Every time it runs into a practical limitations on scaling complexity, it adds a new layer of abstraction. As much as people complain about it, this strategy has clearly been successful.
- smaudet 1mo ago
  This is an interesting take, although I'm not sure the legacy -> modern evolution is perhaps quite as significant as you make it out to be. Smart pointers and better std library constructs are absolutely welcome, metaprogramming is nice, but perhaps out of reach for many programmers (so not the "fun" or "successful" part of the language)... If you were to compare the transformation with another major systems language, or a popular dynamic language, it doesn't feel like the evolution is quite as dramatic as is made out to be? Rather, the staying power comes from elsewhere, and the language continues to modernize, perhaps at a slower pace than other contemporary languages experiencing similar staying power(s)...

by systems 1mo ago

Zak 1mo ago

I don't think C++ succeeded because it was object-oriented. I think C++ was object-oriented because classes were an abstraction that could layer on top of C with fairly low overhead, giving it more expressive power without much mandatory cost to size or speed. In other words, object-orientation was the means, not the end.

mojuba 1mo ago
Agreed and that's probably the second major killer feature of C++.
IsTom 1mo ago
Back then OOP was all the hype and inheritance was cool.
- Zak 1mo ago
  C++ predated the OOP hype cycle and triggered, or at least accelerated it.

shagie 1mo ago

> python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened Ruby allows (and to some extent encourages) unreasonable code. It's not bad code (and in some cases extremely elegant), but it's code you can't reason about. Being able to open any class (or object) and add new methods to it makes tracking how execution works extremely difficult. The language allows for very undisciplined things to work - its great for the "scripting" and rapid prototyping - but unless you're going to throw it away the next day of having to maintain that code it starts weighing on the future speed of working. Undisciplined code can be handled by making sure everyone on the team is disciplined in its use and documenting how things work... but that rarely reflects reality. And so, you move to a language that enforces more discipline in how one uses it and is more reasonable in its execution.

smaudet 1mo ago
Ruby felt like a better Javascript, but JS ran in the browser, and so had the constraint of the DOM... Aka you have to be (more) disciplined within the constraints of the browser. I'm not saying JS was good... The lesson here being, complete freedom is fine, as long as you are also able and willing to implement a strategy to verify your operation, ruby on rails, js in the browser, python PEP or pythonic ways...
- shagie 1mo ago
  I came to ruby from the perl side. It was "here's a Redmine server, here's a feature request for one of the in house built plugins." I forget the specifics (it was 2011) ... but trick of the feature was to add a function to the object being created so that it would have the function some other module was expecting. And it worked... Things like that made me give it the sideye for anything more than I could keep in my head at once... if I started needing to look at other files to determine if there was anything odd there... "can I create a function here in this parameter passed to me? What if someone else created a function of the same name before they passed it to me and expected it to remain?" It can work... but it requires a bit more discipline than the developers I was working with had as a baseline (for that matter, a decade and a half later at a different job with a lower baseline and AI code - the idea of that terrifies me). It's a "powerful" language, but I think it has too much power. I like groovy for much the same reason that I liked perl and ruby (to an extent) - but it too is too powerful. It's great for writing scripts where it's a file or two or three... but if the "what does it do" gets too large to keep in my mind at once then it requires more discipline. I like to think that I have that discipline when working solo in groovy (and people will tell me I don't need to be that explicit in the objects... creating a class file rather than just shoving anonymously built objects into a hashmap), but that's how I can come back to old code more easily. Ruby Conf 2011 Keeping Ruby Reasonable by Joshua Ballanco https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs Abstract Heresies : First-class environments https://funcall.blogspot.com/2009/09/first-class-environments.html https://funcall.blogspot.com/2009/09/first-class-environment...

jandrewrogers 1mo ago

C++ succeeded twice. Initially, it provided a thin object-oriented abstraction over C. This solved many problems scaling large C projects. It set baseline expectations for languages that came later. Being a "thin object-oriented abstraction over C" has significant limits. By the 2000s, it was clear that C++ couldn't scale complexity in the way we needed it to. It was slowly dying. C++ reinvented itself as a functional metaprogramming language starting with C++11, providing an even higher level of abstraction. Many deficiencies in the older language and systems languages generally were addressed. This was a huge success, creating a large resurgence in adoption and setting new expectations for what a systems language should be capable of. C++20 looks like a completely different (and much better) language than C++98. I view C -> legacy C++ -> modern C++ as the evolution of a single language. Each was wildly successful on its own up to some level of complexity. Every time it runs into a practical limitations on scaling complexity, it adds a new layer of abstraction. As much as people complain about it, this strategy has clearly been successful.

smaudet 1mo ago
This is an interesting take, although I'm not sure the legacy -> modern evolution is perhaps quite as significant as you make it out to be. Smart pointers and better std library constructs are absolutely welcome, metaprogramming is nice, but perhaps out of reach for many programmers (so not the "fun" or "successful" part of the language)... If you were to compare the transformation with another major systems language, or a popular dynamic language, it doesn't feel like the evolution is quite as dramatic as is made out to be? Rather, the staying power comes from elsewhere, and the language continues to modernize, perhaps at a slower pace than other contemporary languages experiencing similar staying power(s)...