However, with JavaScript you have to avoid the old/outdated language constructs, and some warts need to remain, since browsers still need to support old websites. Perhaps in the future we can specify "ECMAScript version" (similar to perl) so old stuff can be thrown away and the VM can optimize without having to worry as much about backwards compatibility.
I'm not entirely sure what you're getting at (perhaps the fact that it mutates the original string, similar to `Array.prototype.splice()`) ... but I can say it's never gotten in my way.
I didn't know about the do BLOCK syntax that's (possibly) coming, that's interesting, thanks for bringing that up.
Regarding your last comment about Ruby and Python. I've been thinking about this for a while and I think a lot of the hate people have towards JavaScript is due to the fact that (being the only "official" web language) lots of people were forced to use it without any other choice, which adds a lot of resentment.
On the other hand, Ruby and Python are deliberate choices of which there are many options. People who choose to use it love it, and people who don't can move onto something else. It's not the same with JavaScript. If you want (or need) to do frontend development, you had to use JavaScript.
I observed this with Lua community in the past. I hardly ever see anything negative about it, but it has its own oddities (such as 1-based indexing, global by default variables) and is in a lot of ways similar to JavaScript being a prototype-based language (the only other one that I know of actually).
my $thing = do {
my $intermediate_1 = foo(...);
my $intermediate_2 = bar($intermediate_1, ...);
baz($intermediate_2);
};
type code is something I use quite a lot to be able to name the intermediates while keeping them from escaping into the containing scope. So
let thing = do {
let intermediate_1 = foo(...);
let intermediate_2 = bar(intermediate_1, ...);
baz(intermediate_2);
};
is going to make me a very happy camper.
My other major irritation these days is that 'let' is a statement in JS, whereas 'my' is an expression in perl, and I'm very used to writing
if (my $token = $user->admin_token) {
...
}
and similar constructs. In JS currently I have to write
let token;
if (token = user.admin_token()) {
...
}
(and wrap that entire construct in its own block if I don't want the 'token' variable to continue to exist afterwards, which generally I don't)
The javascript-viable version of that is probably to have a special cased 'if let' just like 'for let' was added already.
I'm unaware of a proposal for that - yet.
Though the 'match' proposal currently in flight IIRC assumes 'do BLOCK' is available, and that will probably give me something sufficient to stop grumbling about that one.
(learning lisp, then applying the same "lexically scope as tight as possible" aesthetic I developed there to my perl code, then trying to use ... pretty much anything else ... has been an irritating experience on occasion ;)
Considering how much I like TypeScript, kotlin-js sounds tempting based on your comment, but unfortunately it's a no-go for me the because I use React heavily, and the solutions I've seen for that look less ideal (for me) than using JSX.
You bring up a good point, but as you know, there's a certain amount of intuitive knowledge that gets carried over when learning another programming language (which is why it's much easier to learn additional languages than it was the first one you spent a considerable amount of time with). The problem is, JavaScript does look a whole lot like the languages you mention, it's just that some things behave vastly differently (ie. function scoped variables, behavior of double equals, etc.), which is what causes the confusion and sometimes you don't learn about these things until they bite you at some point.
I wouldn’t consider them business-only as most individuals interacting with the App Store have bank accounts, so that argument breaks down.
I wouldn’t consider them stictly “reader” apps as you can perform many non-passive things in many banking apps (make deposits, iniatiate transfers to and from accounts, pay bills, etc), so that argument doesn’t stick either.
You can’t use the app unless you have a (most of the time) paid account.
editor.fontLigatures has been expanded to allow you to specify stylistic sets, such as "'ss01', 'liga'" (and so on).
I was looking forward to this because I wanted to enable the "ss01" stylistic set for Fira Code, which takes away the downward slope at the end of the "r" character that I don't like, but it doesn't seem to be working for me.
Was anyone else able get this working for Fira Code?
From what I understand (although I didn't do much research) all you have to do is to use a new enough version of Xcode and that's it, so React Native doesn't really have to add any support. Ultimately, you build native apps anyway, all JS things are hidden inside.
I own a 15" MacBook Pro 2016 and already this keyboard has given me more trouble than any other laptop keyboard. Several of the keys are "mushy" and harder to press than most of the others, and there have been times where a spec of dust rendered some of the keys temporarily defective. None of the keys have outright stopped working, and I thankfully haven't run into the double-keypress issue, so at the moment the mushy keys are not worth risking getting an even worse keyboard if I were to try to get a replacement before my warranty expires (I purchased this less than a year ago Apple refurbished).
This petition may not amount to anything, but I'm sure someone in Cupertino has taken notice. Apple has "we know what's best for our customers, better than they do" engrained in their culture, and when it comes to design decisions, sometimes they are right, but I don't see how anyone there could justify a defective or unreliable (at best) keyboard being the right thing for any of its customers. You know what would take courage? To publicly acknowledge the issue and do right by your customers. That takes way more courage than removing a headphone jack.
Unless a recall actually happens (not likely, but I'm really hoping so), we'll never know what--if any--kind of impact this petition has had, but I'm hoping it will cause Apple to (at minimum) go back to the drawing board on this thing and give us a better keyboard the next time around. They should also expose the keyboard to more rigorous testing (that includes dust and other air debris). I just hope the keyboard I have lasts until I'm ready for an upgrade because I don't see myself spending $700 on a repair when this is already the most expensive laptop I've ever purchased (and the $700 is a gamble considering you could get an even worse keyboard).
The sad thing is, back in 2006 I was in the US Military stationed in Baghdad, and I had with me a cheap $600 Dell laptop. That thing survived sand storms that would leave the inside of our tent (and all of our belongings) covered in dust (even with the laptop lid closed and inside of a locker). I highly doubt this keyboard would have survived that deployment. It's sad that a low-end DELL computer from 2006 had a keyboard that's more reliable than Apple's top of the line notebook. If it weren't for macOS, which I love probably more than Apple does, this whole keyboard saga would have caused me to ditched Apple laptops and go with Lenovo.
At the time of this writing, 16,778 people have signed the petition. If each one of those people are a MBP owner, and let's round down the average cost to $2000, that's $33,556,000. That's a drop in the bucket compared to the 5.8 billion in Mac revenue in Q2; however, the Mac business seems big enough to at least please the thousands of customers who feel cheated.
However, with JavaScript you have to avoid the old/outdated language constructs, and some warts need to remain, since browsers still need to support old websites. Perhaps in the future we can specify "ECMAScript version" (similar to perl) so old stuff can be thrown away and the VM can optimize without having to worry as much about backwards compatibility.