One is never proficient in C++. One merely... learns to adjust ones ignorance to practical constraints. I.e you choose such a subset that you can deal with it. But which subset? Hence, a shitload of books. The point is to read about all sorts of styles and pick whatever feels practical for you.
And I'm completely serious. I've earned my living with C++ for over a decade, am considered a valuable contributor and still... so clueless towards so many details.
Then C++ has failed. If it has so many competing standards and subsets, then it is too fragmented. This is why when you see C++ written in one standard it looks like a whole other language when you look at other C++.
If after a decade there are so many details still obscured from you, then that's pretty much again a fault of the overly-engineered and tacked on language called C++.
Other mainstream language work fine and allow you to still write clean and modern code without having literally dozens of subsets and implementations. So why is it that C++ feels the need to have so many?
On the contrary, the one nice thing about C++ is that it is 'multi-paradigm'. Don't like boost's philosophy of overengineering every little detail? Then don't use boost. C++ without exceptions, RTTI, or even the whole STL? Perfectly fine. Other languages don't have this freedom. It's a double-edged sword of course. Less freedom also means wasting less time with pointless discussions about which combination of C++ features is 'right'.
After using boost in several projects and regretting it each time (slow compile times, painful to configure), I finally learned my lesson and "don't use boost" is now one of my guiding principles when programming in C++.
While I would mostly agree, I would humbly suggest a small nudge in perspective: Boost does not equal Boost. While I passionately hate most of Boost, I find boost::optional to be one of the most useful template classes. So you shouldn't treat Boost as one library, but as a collection of different libraries. Same goes for STL in my opinion.
I think boost has definitely had a positive impact on c++ and the fact that large amounts of it are now in (or had a major influence on) the std library certainly makes it much easier to forgoe using it.
Sure, threads and datetime has been in certain implementations, too. I think anyone can appreciate the fact that these libraries are not compilation hogs (such as phoenix or mpl) and are portable and save a lot if time.
We use C++ because of the C++ the ecosystem not because of the C++ the language.
There really is no other language that fits all of the constraints C++ fits. If there was, I'd be using it. And before you ask 'Have you looked into...' the answer is yes, unless the language is obscure, in which case it lacks the ecological robustness of C++.
Gotta say I'm looking forward to it too, even though I might not ever use it.
There are some things I disagree on with it, but most of those are orthogonal to the domain of which the language was meant to be applied, namely game programming. For that end, I can get behind those.
That said - the main things I don't like are the lack of exception handling, and no automatic memory management. I understand for game programming why these aren't going to be a part of the language. At the same time, I fear that without these, it may relegate the language to something of a niche language only used for game development and nothing else. While it is laudable to think that these features aren't needed, there is a reason they became available - and it mainly has to do with the fact that even "good programmers" aren't "perfect programmers"; we are all humans, not machines.
Features that make the language stand out, though, are the ideas of functions that run at compile time, which allow for a build system that is written in Jai and builds on compile (so you don't need to learn some other "language" just for building your world), the whole AOS/SOA mess that is made simple to implement with only one keyword (kinda neat!), plus the whole "uplift" of code from inner to global usage, with minimal changes, as it morphs from "lines of code" to "capture" to "anonymous function", etc - that's pretty powerful.
The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor. There's one part on this that I question - namely that variables are declared like:
name: type = value
...so:
foo: int = 0;
...but functions are defined as:
name := () -> return_type {}
ie:
bar := () -> float {}
I would have thought that a function would be defined as:
name: return_type = () {}
so:
baz: float = () {}
...thus more like the variable declarations (plus it would allow for turning a variable into a function easier, perhaps). There is probably something about compiler design, parsing, etc that I don't know that pre-empted things? That would be my first guess as to why this difference exists, but I would love to hear the actual reason from the author, if he reads this.
> The inverted typed declaration syntax for variables and functions will take some getting used to, but that part is very minor.
Go, Rust, Swift, Ada, Pascal - languages both modern and old also use that inverted syntax and it's not such a burden to get used to.
> I don't like are the lack of exception handling
If done properly, it's possible to do without exceptions and have more robust and readable code - see for example Rust with its Error type and the try macro/? operator, which I've found I much prefer to exceptions.
I'm not an expert at parsing, but one main issue I can imagine with having the same syntax for declaring functions and variables is that you need to look at six tokens to understand if it's a function declaration or a variable declaration. I say six because you have the name, colon, type, equal, parentheses (certainly you can't use this because then I couldn't declare a variable using parentheses, e.g., foo: int = (4 + 5) * 3;), and finally a pair of curly braces. And even then, I don't know Jai at all so it may be legal to use them in variable declarations.
With the name := () -> return_type {} syntax, you know whether it's a variable declaration or function declaration after two tokens: name (for either), then colon or colon-equal to differentiate the two.
Then by that point of view, C (hello UB), Python, Ruby, JavaScript, Java, among many other programming languages have failed as well.
Using my favorite scripting language (Python) as an example, I always need to check which version is installed on a given OS and then validate at https://docs.python.org/ if all the features I want are actually available on that version.
Not to mention CPython, PyPy, Cython, JPython differences on top of that.
Which other systems language allows the same style of programming while giving the same performance? You pretty much know if and when you need C++ - which is rare unless you live near the hardware.
That said, I'm not sure how you wish to engage people here with that comment. Do you have any specific criticisms of C++ (there are many!) that we can discuss beyond your personal feelings?
I would disagree that C++ is only useful "near the hardware" I have spent the bulk of my career not near the hardware and have found C++ to be the most useful of languages I have learned. My current job is as close to the hardware as I have gotten, I am even on the "Firmware Team" and I feel pretty removed.
If you need interop between two languages you almost always have to drop to C, if you want to do that while keeping high level concepts like object, then use C++.
If you need more performance and you have already maxed out perf in some "higher" language. Then a naive C++ rewrite is often just faster. Then when you start breaking out C++ profiling tools and carefully managing memory you get insane speeds that didn't seem possible before.
With some of new stuff in C++11/14/17 it is actually fun to work in C++, not as fun as Ruby... up until 3d things start appearing on the screen.
>I would disagree that C++ is only useful "near the hardware"
Okay, but I didn't say that? I said C++ has limited uses, _unless_ you're near the hardware, where its much more common. You can disagree, but its better if you disagree with what I actually said :P
But to your reply, Personally, I don't agree that C++ is fun to work with. Like any other language, I tolerate it as and when I need to. And like I said in the previous reply, sometimes C++ is the only choice, and you accept that and do the best you can. I've found that good tooling does reduce some of the headaches, especially when it comes to debugging (although stepping through optimized production code still remains a giant pain in the ass). I'm happy that the language is progressing and with all of the new features, its like a cafeteria where you chose what you like and what works for you and your team. I certainly don't agree with all the advice that the C++ cheerleaders put out on the internet about inserting every new feature into production code. Personally I take a very conservative approach and only use features that have shown tobe useful across the entire dev cycle of - helping to conceptualize an idea, being easy to reason about by everyone on the team, being easy to debug, and being reliable enough for 24/7 execution (though this applies more to the library side of things). My code runs automation machinery, and it has to have zero bugs in it. I choose C++ because currently its the best tool for the job.
I figured that by providing examples of where C++ was required that cases near those were it is used but not required would be evident.
In pretty much every type of application domain there are a large number of C++ applications. It is used in finance, business, games, medical, as you point out it is used very close to the hardware particularly when that hardware is custom and image the web with many fewer browsers and servers. The only kind of developer that might outnumber C++ devs is Java devs because there are so many custom internal enterprise applications that place higher emphasis on being barely functional than performant (and they are largely correct in their decision).
I find no need for your needlessly specific separation of limited vs whatever my wording used. I hope that whatever your take from this, should you choose to continuing nitpick, is that C++ is hugely useful in many places it just is new and glamorous so it doesn't get much press.
Fun to work with? Perhaps not. But 99% of the software you're using to post your reply (and generally do just about anything on your computer) is written in some derivative of C or C++. So C++ has that going for it, which is nice.
My philosophy is "If you have fewer than 5 years' experience with C++ and think you are an expert, you just don't know how much you don't know. If you have more than 5 years', then you're a liar."
Only time I had C++ on my resume was when I was looking for my first internship and was desperate to pad my resume with _something_... Hey, I took a course in C++, so I can put it down, right?
I soon removed it afterwards after knowing what "knowing c++" implied.
> "If you have fewer than 5 years' experience with C++ and think you are an expert, you just don't know how much you don't know.
That pretty much applies to any subject. Some bachelor's degrees take longer than that, and no one becomes an expert with a bachelor's or even a master's degree.
Therein lies its strength. It filters out both those too weak and those who want to appear smarter than they are. The first group just never can get anything done in C++, the second writes code they can't understand themselves 3 months after they wrote it, so it either ends up in Boost or nobody uses it.
My subset is the one that I require to interoperate with managed languages (Java, .NET, Swift,...) and makes me feel as I if am using Ada/Turbo Pascal with curly bracket syntax instead.
And I'm completely serious. I've earned my living with C++ for over a decade, am considered a valuable contributor and still... so clueless towards so many details.