Honestly I used to think the same way about JS, because not having types allowed for very concise code sometimes.
But the more I used Swift I realized how powerful type inference can be, and the difference in conciseness shrunk to basically nothing.
Heh, yeah, everyone's journey is different :) I started out being a big fan of static typing but eventually found that I'm usually hit by different issues than "this was a int but I expected a string" that were more important to be solved, so I'm mostly using dynamic languages nowadays.
But that's what so great with programming languages, there are so many that work so differently, so there is at least one language for everyone, no matter how different your brain works :)
By the way, if you're a fan of "conciseness" you should give a lisp-type languages a try if you haven't before, will show you a completely different level of conciseness! Clojure is a great introduction to lisps. And if you still need validation of data somehow, clojure.spec et al works great and will introduce you to some cool new things you probably haven't come across before :)
Doesn't TypeScript – as mentioned above – solve all JavaScript type problems? I have, in 6 years, never encountered a single type error originating from a TS file.
Biggest problems with TypeScript IMO are that it’s a layer rather than a language proper and that untyped JS problems can too easily worm their way in if you’re using any libraries at all. Also depending on the group of developers involved, the ease at which one can pull the escape hatch and opt out of TS is a liability and can render much of its benefit moot.
But you’re only capable of handling so much. You’re under no obligation to process every piece of information you think you might like, and moreover - you shouldn’t. You’d be setting yourself up for disappointment.
The way I work is I acknowledge my limits and follow my gut. Sounds vague but that’s what I got.
IIRC the main appeal of CoffeeScript was syntactic sugar like lambda expressions etc that were missing in ECMAScript 5.
I think ECMAScript 6 made most of the appeal of CoffeeScript obsolete
When CoffeeScript came out, I vowed never to write plain Javascript again. I kept to that vow for a couple years, but eventually broke it when ECMA 6 came out. Really the only thing that put real technical justification behind CoffeeScript was the double arrow function, and maybe the neat class syntax. Beyond that CoffeeScript is just prettier. Even though I was in charge of choosing the technologies, you got to skate where the puck is going, and the puck was clearly not staying with CoffeeScript.
ECMA 6 copied all the good parts out of both CoffeeScript and jQuery, effectively obsoleting both. Modern JavaScript is almost unrecognisably different from what it used to be, and that's a very good thing.
The Swift code that's generated is pretty good, but I found myself pretty much immediately wanting to edit it.
I now maintain a separate copy of the templates that implemented some missing features of the spec that I needed, and adjusted access control etc to suit my needs. And I also feel like checking the generated code into source control is the way to go, if only for the build time improvements. I mean it doesn't change often enough to warrant being rebuilt all the time.
Wikipedia says the iPhone 5S was released in September 2013, So that's about 6-7 years of updates.
The chart you linked seems wrong to me. Am I missing something?
You're right, the chart is showing OS releases not precise iPhone releases.
It still closer to 7-8 years for the 5S of OS/security updates (just because a new OS version came out doesn't mean security updates stopped completed).
But the existence of competition or lack thereof can have its own effects, some of which are actually desirable and make the iPhone have the draw that it does.
If Facebook had a worthy competitor for example, surely you'll agree Facebook would be a considerably different product now.
You might say that doesn't help my case, because it would actually be a better product, but it's not an inevitable outcome in every comparable scenario.
> If Facebook had a worthy competitor for example, surely you'll agree Facebook would be a considerably different product now.
No, I don't think I would. The vast majority of people are not going to leave facebook as long as they can't take their social contacts with them, and Facebook knows this. They'll let you have your pictures and videos, but the graph? No way, and they know most people won't leave entirely because recreating all those links is a large undertaking for most people. Even young people that originally shun Facebook as their parent's social network eventually join because the network effect is too large to ignore.
The fact that Facebook very quickly buys anything that looks like it might have a draw that could possibly affect this in any way doesn't help it. Neither does that they blatantly lied to congress about things they would/wouldn't do with some of these acquisitions when asked about it.
"I like that TrueCaller on my iOS device works for most features without getting any permission from me, while on Android it refuses to buzz from the splash screen unless you give it every permission - including full contact access and phone.
I like that on iOS a famous payment app from India (PhonePe) works flawlessly with zero permissions but on Android? It needs both location and contacts to even function - neither of these are mandatory for their functioning but still they do and can get away with that.
You know WhatsApp doesn't let you use "Status" feature unless you provide Storage permission to it on Android (I doubt they need it just to shows those images, videos, and texts)."
I think it's important to note that the mere existence of controls, i.e buttons that do a thing, don't actually end up achieving their goal of improving user privacy unless there's also enforcement of usage patterns. You can't get away with stuff like this on iOS, and it's clear by these accounts that the same companies would do the same on iOS if they could.
Apple doesn't have to change it's policies when (not if) it is forced to allow people to install alternative stores. Those companies will still have to play nice with apples terms if they want to remain on Apple's app store.
