My first ever big boy language was C++ (after Basic, and Logo, does anyone remember that lol). I was in middle school, tried to self-learn from learncpp.com, only to realize that I had mostly learned C, with cin-cout instead of printf-scanf. So I just decided to migrate to C. Nowadays, I mostly code in Rust, Go, and Python. But my experience with C has been extremely helpful. Can’t say the same about C++ though.
I used Imagine by Logotron (Czech-localized, including keywords - yes, with diacritics) as my IDE, and I still have it installed because the accompanying graphics editor (LogoMotion) is just so good. I never got to the OOP part because the textbook didn’t cover it and there are no materials onlone about the Czech version (not even a keyword dictionary), and I couldn’t speak English back then. I stopped programming for way too long because I couldn’t get another IDE working and I didn’t know how to make arrays and text I/O in Logo, the tutorials I had stopped at variables.
C++ is useful for learning object oriented programming: Describing what really happens in constructors and destructors, the pros/cons of reference counting and how it actually works (using std::unique_ptr)
These are things that most modern languages try to hide/abstract away, but the underlying problems and limitations never go away, but with C++ you’ll have a better understanding of why they happen.
However, if you go down the rabbit hole of Template Metaprogramming, I agree with the original post: it takes decades to learn and really only usefulexploitable in C++.
I don’t disagree that the language is a great way to build an understanding of object lifecycles, but in my experience C++ ctors and dtors are also the biggest source of confusing footguns I’ve ever encountered in any programming language.
Separately, template metaprogramming is a whole different beast. It’s an extremely powerful tool, but to me it also feels like finding the correct incantation to get it to do exactly what you need for more complex scenarios. It can be really fun if you know what you’re doing, but it also tends to make me very upset at the compiler when my incantations are a bit off.
I’ve always preferred the functional approach to programming, so OOP never really intrigued me. That’s one of the reasons why I never liked C++ or Java, but instantly fell in love with Rust. It lets me do a lot of functional style programming, while still being somewhat practical. (I’m looking at you, Haskell.)
I’ve been a long time believer that some problems are better solved via OOP, others through functional programming. The perfect language would be a successful blend of the two.
Many popular OOP languages are horribly lacking on FP or it looks like an eyesore (golang, python, etc). …and FP languages trying to do OOP are kinda awkwards (see common-lisp).
I thought Crystal Lang (a statically type checked dialect of Ruby) was going to be the “perfect language”… but the compile time performance and the lack of 3rd party libraries (like an aws SDK) really made it hard to use.
Hearing what you said about Rust has renewed my hope.
That said, I did notice that features like Coroutines have been “experimental” for nearly 9 years.
I hope I’m missing something obvious, but how would you create any sort of heavy-lifting, long running, multi-session daemon/application without having some sort of asynchronous mechanism that goes beyond threading (which is limited to the number of cores the host machine is running).
edit: cleaned up a few thoughts (prematurely hit submit)
I don’t think there’s an std-way of doing it, but the Rust ecosystem has this thing where people usually settle around one library. In this case, it is tokio. Afaik, most async stuff is done using tokio. What little async I’ve used, it’s been using tokio or some library like actix-web that uses tokio under the hood.
Also, side note, I never understood the idea of why golang is ugly. I think it’s fine, except for maybe the repeated if err != nil guards. Those are ugly. I wish it used additive types for error handling.
Quite a while ago, I wrote this to document my understanding what OOP actually is.
This sentence at the end is interesting:
On the other hand it sounds unlikely that there will be a popular language without object-oriented influences some day, so at least minimal syntax-level support is desirable.
Rust was published like one year later and it can be considered popular by now. Does Rust support OOP via traits? Kind of yes, but so does Haskell with typeclasses.
My first ever big boy language was C++ (after Basic, and Logo, does anyone remember that lol). I was in middle school, tried to self-learn from learncpp.com, only to realize that I had mostly learned C, with cin-cout instead of printf-scanf. So I just decided to migrate to C. Nowadays, I mostly code in Rust, Go, and Python. But my experience with C has been extremely helpful. Can’t say the same about C++ though.
Yay, Logo
I used it way too long because my clumsy asa couldn’t get another IDE to work
Seriously, three cheers for Logo!
Incidentally, I’ve found that
import turtlein interactive Python opens a pretty good logo clone on most operating systems.Memory unlocked!
If you are feeling nostalgic the project is still there, with the same old interface from the past: https://fmslogo.sourceforge.io/
I used Imagine by Logotron (Czech-localized, including keywords - yes, with diacritics) as my IDE, and I still have it installed because the accompanying graphics editor (LogoMotion) is just so good. I never got to the OOP part because the textbook didn’t cover it and there are no materials onlone about the Czech version (not even a keyword dictionary), and I couldn’t speak English back then. I stopped programming for way too long because I couldn’t get another IDE working and I didn’t know how to make arrays and text I/O in Logo, the tutorials I had stopped at variables.
Around 5th grade I animated the sinking of the Titanic in LOGO
C++ is useful for learning object oriented programming: Describing what really happens in constructors and destructors, the pros/cons of reference counting and how it actually works (using std::unique_ptr)
These are things that most modern languages try to hide/abstract away, but the underlying problems and limitations never go away, but with C++ you’ll have a better understanding of why they happen.
However, if you go down the rabbit hole of Template Metaprogramming, I agree with the original post: it takes decades to learn and really only
usefulexploitable in C++.I don’t disagree that the language is a great way to build an understanding of object lifecycles, but in my experience C++ ctors and dtors are also the biggest source of confusing footguns I’ve ever encountered in any programming language.
Separately, template metaprogramming is a whole different beast. It’s an extremely powerful tool, but to me it also feels like finding the correct incantation to get it to do exactly what you need for more complex scenarios. It can be really fun if you know what you’re doing, but it also tends to make me very upset at the compiler when my incantations are a bit off.
How does unique_ptr teach reference counting? It’s just a way to interface with RAII and move semantics
You’re right. I was thinking of shared_ptr (it’s been a blissful long while since I’ve dived deep into C++ stl and boost)
edit: a word
I’ve always preferred the functional approach to programming, so OOP never really intrigued me. That’s one of the reasons why I never liked C++ or Java, but instantly fell in love with Rust. It lets me do a lot of functional style programming, while still being somewhat practical. (I’m looking at you, Haskell.)
I’ve been a long time believer that some problems are better solved via OOP, others through functional programming. The perfect language would be a successful blend of the two.
Many popular OOP languages are horribly lacking on FP or it looks like an eyesore (golang, python, etc). …and FP languages trying to do OOP are kinda awkwards (see common-lisp).
I thought Crystal Lang (a statically type checked dialect of Ruby) was going to be the “perfect language”… but the compile time performance and the lack of 3rd party libraries (like an aws SDK) really made it hard to use.
Hearing what you said about Rust has renewed my hope.
That said, I did notice that features like Coroutines have been “experimental” for nearly 9 years.
I hope I’m missing something obvious, but how would you create any sort of heavy-lifting, long running, multi-session daemon/application without having some sort of asynchronous mechanism that goes beyond threading (which is limited to the number of cores the host machine is running).
edit: cleaned up a few thoughts (prematurely hit submit)
I don’t think there’s an
std-way of doing it, but the Rust ecosystem has this thing where people usually settle around one library. In this case, it istokio. Afaik, most async stuff is done usingtokio. What littleasyncI’ve used, it’s been usingtokioor some library likeactix-webthat usestokiounder the hood.Also, side note, I never understood the idea of why
golangis ugly. I think it’s fine, except for maybe the repeatedif err != nilguards. Those are ugly. I wish it used additive types for error handling.Quite a while ago, I wrote this to document my understanding what OOP actually is.
This sentence at the end is interesting:
Rust was published like one year later and it can be considered popular by now. Does Rust support OOP via traits? Kind of yes, but so does Haskell with typeclasses.