4 ms·
After a quick read through, I personally find this syntax much harder to read using operator overloads than it would have been using a series of comparison func
by gizmo385 7y ago
After a quick read through, I personally find this syntax much harder to read using operator overloads than it would have been using a series of comparison functions. Tilde is a very obtuse operator and I don't know that this really buys you anything.
Feels like a case of preferring cleverness over readability/usability/maintainability.
- mark-r 7y agoExactly the road C++ tries to go down. How's that for a ringing endorsement?
- wolco 7y agoC++ is one of the most successful languages.
- nine_k 7y agoDespite its flaws, not due to them. Same can be said about e.g. Cobol.
- eru 7y agoDespite the flaws, and because of being in the right place at the right time. Cobol also was a good idea back in the day. And some of the ideas in Cobol we know recognize as bad _had_ to be tried to gain that recognition.
- otabdeveloper4 7y agoFalse. There have been dozens of working C++ competitors over the years, each one technically as good as C++. They all failed because their authors are good at writing languages, but very bad at knowing how languages are used in the real world. The C++ committee really knows what it's doing, you're not going to do anything useful in this space without actually understanding the problem domain. TL;DR - yes, C++ is complex, but that is because programming is complex. Your attitude of "programming is hard, let's go (language) shopping" will not displace C++.
- nine_k 7y agoC++ made a number of... unfortunate decisions early in its development, which resulted in a much worse language than it could have been. (Hindsight is 20/20, of course.) I totally agree that C++ of 21st century is way better than C++ from 1998, and is becoming better. The problem is that maintaining backwards compatibility requires to keep a number of footguns in place, and some of them are cornerstones of the language :( I have high hopes for Rust becoming the more sane competitor in the space traditionally occupied by C++. Its authors seem to understand the problem domain from a very practical standpoint, and are proficient in C++, to begin with. They also strive to apply reasonable design principles, and some actual math hopefully will keep the core of the language from logical pitfalls. Another example of hitting a sweet spot is Go. I dislike many Go's language decisions. (Some are definitely great, though, e.g. the whole OOP approach lifted from Oberon.) But its authors definitely understand both the problem domain, and the target audience. This is what I mean by talking about success despite the flaws. C++ has both flaws and merits, and merits outweighed the flaws. But the flaws are still painful.
- raobit 7y agoRust:- Am i a joke to you?
- mark-r 7y agoHow much of that success can be attributed to the features that were added in the last 10 years?
- cortesoft 7y agoPretty good?
- MichaelMoser123 7y agoPython is adding features, maybe they want to be as expressive as perl, when they grow up; however that comes with the price of decreased readability.
- kolinko 7y agoI actually had a series of comparison functions initially, but those weren't that readable. To give you an example, let's look at this statement: if exp ~ ('mask_shl', int:size, int:offset, -offset, :e): ... It is the same as writing: if type(exp) == tuple and len(exp) == 5 and exp[0]=='mask_shl' and type(exp[1])==int aand type(exp[2])==int and exp[3] == -exp[1]: size, offset, e = exp[1], exp[2], exp[4] ... If you can figure out syntax that makes this sort of matches more readable, I'll gladly use it :)
- kolinko 7y agoFixing formatting for above: if exp ~ ('mask_shl', int:size, int:offset, -offset, :e): ... vs if type(exp) == tuple and len(exp) == 5 and exp[0]=='mask_shl' and type(exp[1])==int aand type(exp[2])==int and exp[3] == -exp[1]: size, offset, e = exp[1], exp[2], exp[4] ...