If programming is just my hobby, then maybe. But would you, for example, quit your current job and look for another, just to change the programming language? I know I'm not that sort of person.
I think it's not as much "if this guy becomes the lead I'm immediately quitting my Ruby job to return to PHP" as much as "if this guy becomes the lead I'm probably going to return to PHP for my next job."
I have my doubts, even for this softer version. These are things where one might feel very strongly in a moment, or even for a longer time, but facing a real life decision, there are so many other factors.
Of course we will never know the outcome of this, it's just my two cents.
Commendable action! If feel like it's a different case though. Two points:
1. Working for someone, even through a large company, is a much more directly supportive relationship, than using someone's free project. Especially since the project has a lot of large contributors.
2. A company is interchangeable, a skill is much less so. You can do the same, or very similar thing at the next company, but moving to a different language involves a lot of learning, even though both are programming languages.
For these reasons, if talking about a lot of people, I can see many of them leaving a problematic company, and only some of them changing their primary language. I'm sure there's someone out there throwing away two decades of experience for an ideal, but I don't think it's realistic, especially not for 1 problematic blog entry.
The obfuscation in question was just name mangling, so it was probably ~zero-cost. Possibly slightly negative cost, depending on the relative verbosity of method names.
I remember Graf Zahl threatening to leave the project because Zdoom lead dev Randiheit pitched to add Lua scripting to ZDoom which he vehemently opposed due to his high bias with C/C++ syntax which he found Lua very unlike, which led to him creating Zscript that had has a more familiar C/C++ syntax.
The thing is Graf Zahl has long treated GZDoom as its personal pet peeve project without regard to the community wishes and constantly disrespecting his contributors peers and bugreports.
I mean you could make that work in C++ too, with ref qualifier method overloads:
namespace std {
class string {
bool contains(const string& other) & {
//Check if 'this' is in 'other'
}
bool contains(const string& other) && {
//check if 'other' is in 'this'
}
};
}
using namespace std::string_literals;
int main() {
string foo("foo bar foo");
foo.contains("bar"); //returns true
"bar"s.contains("foo bar foo"); //returns true
}
But I hope not because this 'flipping the script' behavior just makes the code flow more difficult to reasonate about.
No, I guess you missed the point. Rust's contains isn't somehow magically upside down like your weird C++ example but it does work on the actual built-in string literal, whereas C++ can't do that because its built-in string literal is the weird C string literal that's a zero terminated char array for some reason.
Notice how you needed to write "bar"s to make your code compile? That trailing 's' says you want specifically to construct a std::string not use the language's built-in string literals. So you'll need a full blown hosted C++ environment (otherwise there's no allocator for the string class)
The Rust string literal was inherently a &'static str, which only needs the core language, it Just Works™.
There's a weird asymmetry, Bjarne wants user defined types to have all the features the built-in types have, but, not vice versa. So you can overload the short circuiting boolean operators on your own types (don't, this is basically always a bad idea) but you can't call methods on built-in literals like "foo" or true or 'X'...
With the string literal suffixes, I don't think it's all that different ("hello"sv.contains(username)). Yes, yes, for legacy reasons bare "" is the C-style string, but you can get a string_view string easily enough.
I agree that it's not "all that different". It's just that years later what C++ offers is slightly worse while having more awkward syntax.
Exactly like the article topic. Iterating over your maybe type was IMO an obvious thing you'd want, but it took C++ a decade to provide this behaviour in a slightly awkward way.
And likewise for their maybe reference, which C++ 26 also finally lands. The original discussion papers for std::optional explain the core ideas for std::optional<T&> but apparently the possibility that it's an assign through type, a thing nobody has ever wanted, and no other language has ever provided - was so important that it blocked all work on this idea for about a decade.
> I would like C++ would be a little more "batteries included" in some ways, like having a basic standard for signals, networking (just handling sockets would be a huge thing), and some basic system calls.
Isn't Boost library basically that? C++ has been slowly adopting freatures from it to its standard library.
C++ has been adopting features from a lot of different libraries into the stdlib. These libraries don't always do it "The Boost Way™", even when Boost has an equivalent library. Boost has a lot of good stuff though, it's just a little farther from being "std++, why care about std?" than commonly advertised.
That's because on mobile, PageSpeed (which is a hosted version of the Ligthhouse dev tools you also have in Chrome) simulates a low-end Android device on a slow 3G network, which is what a lot of website visitors actually use (as opposed to the web developer using the newest iPhone on great WiFi).
And not only that, Java was like 40 years late to the party. ML had Hindley-Milner type inference back in 1978! I can only imagine how foreign ML must have felt compared to other languages at the time.
One I noticed is j2me games often don't play music on the background and just resorts to sporadic sounds, any reason for that?
reply