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.
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?
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++.
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++.
jblow, I know you read HN, lots of us are looking forward to Jai.
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.
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.
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.
Pretty sure Jai is already powerful enough that you could add this dynamically to any program.
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.
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?
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.
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.
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.
I soon removed it afterwards after knowing what "knowing c++" implied.
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.
I'm not kidding.
I've got several linear feet of C++ books on my bookshelf, have read most of those books, and I consider myself an average C++ programmer, not a language guru by any means.
It's easily one of the most complex mainstream languages and one with the most pitfalls which is why higher level languages are preferable when feasible.
I also wouldn't bother with Effective STL or More Effective C++. They're ancillary to the main books of that series and are somewhat outdated.
I don't know if you know the meaning of "proficiency", but if you are trying to argue that it takes work to become an expert in a subject then it seems you aren't aware of what being an expert actually entails.
Moreover, Those books appear to be a lot mainlyl because the subjects covered by half of them actually overlap.