yes, c++ is the cruelest most insane joke, on the same level of perhaps embedding malware inside a compiler and distributing it to the developers. no really, it was a nice try making an object-oriented language on top of c, but then why not build on top of the superior oo features of smalltalk or lisp?
C++: Is It Really a Cruel Joke? (2003)
111–120 of 155 posts
Re: C++: Is It Really a Cruel Joke? (2003)
#112I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..
People often think of C++ as a Object Oriented Language. That's understandable, as it was the key feature back in the earliest days. OOP got hyped and over used. Now OOP is (almost) considered harmful in C++ community.
If you look at modern C++ libraries (like boost), you will see a lot of templates and free functions, and not a lot of inheritance or dynamic polymorphism.
Re: C++: Is It Really a Cruel Joke? (2003)
#113Dr. Stroustrup took a lot of pain to ensure the language was useful and did not break backward compatibility. He also always maintained that if you don't use a feature you shouldn't pay for it (in terms of performance). Eventually, it became even more popular and there is now a whole organisation behind the international standards for the language. The book "The Design and Evolution of C++" helps one understand why s…
The book "The Design and Evolution of C++" helps one understand why some things are the way they are
As I've said quite recently elsewhere, C++ is an archaeological dig of a language. There are something like 4 major strata. If you would learn and use C++, it behooves you to pick a particular style, then stick to that. (RAII and smart pointers are very useful!)
There's something called the Taligent coding standards, which were once popular, then later castigated as turning C++ into "a poor man's Smalltalk." Small teams can write some dandy code using that style. Everything can fall apart at scale, however.
(EDIT: Here's an example from elsewhere in these comments: https://news.ycombinator.com/item?id=17463569 )
Re: C++: Is It Really a Cruel Joke? (2003)
#114I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..
D has potential
Yes, it is having potential for 11 years and will probably continue doing so.
Re: C++: Is It Really a Cruel Joke? (2003)
#115I know C++ isn't really dying off, but what is the best platform-agnostic compiled object-orientated language these days? I liked Borland Pascal, and I know Delphi is kind of ticking along, but I'd rather invest in a language that is growing. Swift looks nice but still seems too Apple focused. Don't want to start a war, just open to some tips on the ecosystem..
If you really want to keep getting things done today, especially on Windows, and not just learn something new, then stick with Delphi/Lazarus for now.
Every year I keep looking to see if a language will become available that will be able to replace Delphi, and there have been some close candidates, but nothing quite there yet. The close candidates right now are: AOT-compiled C# and Go. If you like the OOP in Object Pascal, then the type handling in Go will probably seem wonky to you, and as far as I know, AOT C# isn't quite ready, but I may be wrong on that front (it's hard to find information on the AOT progress with C#) and someone else can chime in with more information. I cannot understate what a game-changer AOT C# will be on multiple platforms, especially if they can keep the binary size down.
Re: C++: Is It Really a Cruel Joke? (2003)
#116The only joke here is somehow this author thinks the success of your project is dependent on the language you pick
Funny how many people believe that language choice influences success. I guess they're all wrong? Sure, there are an uncountable number of other factors, but picking the wrong platform/language can be fatal.
Yes, but that goes both ways: choosing a popular language can be just as fatal as choosing an unpopular language.
If you're a "body shop", then choosing an unpopular language could be fatal, whereas if you're building a specific software product that needs to do certain things on certain platforms, then choosing the language becomes less of a popularity contest and more about how it can help you finish the product quickly with the highest level of quality and performance.
Re: C++: Is It Really a Cruel Joke? (2003)
#117Earlier quoted context omitted.
Only if it need to have backward compatibility. Rust doesn’t so it can be vastly simpler.
How is Rust simpler than C++?
Rust is a much smaller language and stdlib than C++ (though still quite large). Rust makes an effort to make many things explicit that are implicit in C++, such as numeric type conversions. Rust's traits are conceptually simpler than classes, especially if you want multiple inheritance. Rust's templates/generics are much closer to the core language than C++'s template language.
And then there are all of the safety features of Rust; while there is a learning curve, it is much easier to learn the concepts of lifetimes and ownership when the compiler is helping to enforce proper usage.
Re: C++: Is It Really a Cruel Joke? (2003)
#118The only joke here is somehow this author thinks the success of your project is dependent on the language you pick
"Almost perfect"[1] disagrees with you. [1] http://www.wordplace.com/ap/index.shtml
which part? I skimmed through it and it mostly seemed to be group interplay, direction and competition. This is what kills products, not language of choice.
Re: C++: Is It Really a Cruel Joke? (2003)
#119The only joke here is somehow this author thinks the success of your project is dependent on the language you pick
"Dependent" is a strong word, but tool/job fit is still important. I've personally never grown comfortable enough with C++ to get to a point where, were I to be the one calling the shots, it would ever be my first choice. But I also recognize that it's dominant in certain spaces for a reason. At the same time, I have a lot of sympathy for people who prefer C over C++. There's a lot of cognitive overhead involved in u…
I've been in the business for 15 years, I have never seen a successful product fail because it was written in language x or y. It fails for a lot of other non programming language reasons though
Re: C++: Is It Really a Cruel Joke? (2003)
#120Earlier quoted context omitted.
I would encourage you to use Cython instead of Nim if you're looking for Python-like syntax combined with C performance.
This is just my situation, but I gave up on Cython when I started moving forward with it (distributed graph algorithms). I found that I had more things to learn. With Nim, it took me half a day (after seeing the language for the first time) to get a basic numerical process going and another few days for distributed data communication involving messaging and postgres/mongo (Nim has a modern JavaScript (ES6) promise/as…
I find that strange, but I concede you know your use case better.
I work on a very similar type of application that manages async workers who process large distributed NLP tasks. Writing it in Cython was extremely easy, because for the modules that have zero need for static typing, such as the part using async/await in Python 3, or when we supplement with gevent, I can just write those parts in plain Python and it’s quite a bit easier than Nim or Cython or whatever else, while still having great performance from those tools’ low-level implementation.
Then for the parts that do possibly benefit from static typing and compilation (unlike the async layer), I can have precise module-level control over what has a C-level implementation and if or how it interacts with anything in Python.
The inability to separate the two situations in Nim (as with many statically typed languages) just doesn’t work out well enough for my use cases.
In fact, I’d even go as far as to advocate that in today’s language landscape, if you want to write a new greenfield project in C or C++ for performance reasons, it’s unequivocally your best option to write the whole thing in Cython, and avoid what you might call “premature static typing optimization” by profiling and leaving the things with no bottleneck in Python.