31–40 of 411 posts
Earlier quoted context omitted.
In other words you’re concerned that some Array methods mutate the array (push, pop) and some don’t (map, concat)? If so then yeah, that can be annoying and/or confusing.
For me the worst is slice/splice.
seems like a real missed opportunity to add string.leftPad()
seems like a real missed opportunity to add string.leftPad()
seems like a real missed opportunity to add string.leftPad()
Even the trim operations they added fall short of the target. In Python (and tcl, by the way) you can specify which characters to trim.
So close, yet, so far.
Earlier quoted context omitted.
Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i Proper immutable support (or a stronger concept of const) would also help with this.
> for(let e of arr) e = b Is that just arr.map( e => b ) ?
That’s a surprisingly small amount of change. I’ll leave it to others to determine if that’s a good or bad thing.
The part about parameter less catch reveals a lot about the philosophy of the language. For me, silencing error like this is a bad practice. You may still produce a sane error in the catch, but the design goes toward silencing things. I really love languages that force you to handle errors up to the top level.
In Java it led to lots of exception wrapping and leaky abstractions.
Not sure what the answer is - although my golang experience was better.
Earlier quoted context omitted.
Mutation is a real weakness of Javascript. I think the general idea is "methods don't mutate unless they are ancient". For example Array.map (an IE9-era feature) doesn't mutate, Array.sort (an IE5.5-era feature) does. Similarly a "for(let i=0; i Proper immutable support (or a stronger concept of const) would also help with this.
> for(let e of arr) e = b Is that just arr.map( e => b ) ?