On Tuesday, 5 January 2016 at 16:54:32 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:
D probably should aim for a lower ceiling and keep focus on
"advanced features". Go and Swift will try to stay "dumbed
down", like Java and C# to remain attractive to businesses that
want low in-house training.
Swift is dumbed down? I'm surprised you started off by saying
that 80%/GC is the big market, but now believe D should be
"advanced."
Swift3 probably will try to get closer to C though. Apple seems
to be focused on making C less frequently needed.
So they too will try to straddle both horses!
Straddling both those horses appears to be the plan, taking
D's strength in 80%/GC and crossing over into low-level engine
dev with @nogc and C++ integration. Rather than splitting the
domains as you say Apple wants to, by complementing Swift with
C, I think the plan with D is to offer one language that does
both, ie a general-purpose low- to mid-level language.
Well... not sure how that works out. High risk! Hardware is
changing too. Runtimes/semantics can easily become obsolete
(inefficient) on new platforms. A reason to keep standard
libraries light.
Keeping things simple is good... Better to have 2 simple
languages than 1 big. Then you can replace 1 component when the
environment changes.
Traditionally, it's been C and C++. I could see D providing a
lighter version that went after C, especially in embedded, while
the current version competes with C++.
The situation for Apple is a bit different since they control
both hardware and software. Meaning, they can build in their
own Swift2Metal compiler if they want to...
I think Swift could go after that market, but they too will
probably have to add C++ integration to do it.
C++ is not big on the official iOS and OS-X frameworks. You
essentially have Objective-C and C as the legacy platform and
Swift and Metal with Objective-C compatible runtime as the
modern platform.
Objective-C++ is really only for binding to portable code from
other platforms.
We're talking cross-platform here, Swift isn't even in the game
till they get on other platforms than OSX/iOS.
It's not a significant enough source of revenue for them, I
doubt they care.
$100 per developer per platform + 30% is a pretty hefty charge.
I don't trust the current Apple CEO... Steve Jobs was more
"hacker" oriented IMO.
Yeah, but do they break 5% of yearly revenue on that? Probably
not, it's some small portion of the little purple chunk showing
Services revenue in this chart:
http://www.asymco.com/2015/08/26/much-bigger-than-hollywood/
That's why I don't think they care. They just do it because
they're disciplined about extracting money where they can.
They're not trying to maximize it by killing competition,
especially because such anti-competitive moves could spook devs
and maybe even some users, which might affect the all-important
iPhone cash cow.
Profit margins on hardware will drop as Android hardware become
commoditized. This is a typical trend. Margins go down over
time if you avoid monopolies and requirements stay the same.
And battery life and physical size limits requirements.
This is happening to some extent to Android OEMs but not to the
iPhone, which has maintained its margins while selling millions
more every year. Apple does it by continually staying at the top
of the performance heap, with their in-house designed custom ARM
cores blowing away the benchmarks year after year and paying top
dollar for the best components, like cameras, flash storage, and
fingerprint sensors.
So, iPhone is a gold-mine today, but more like a copper-mine
in 10 years? I guess flexible and unbreakable plastic phones
could be the next step, foldable LCDs are here already.
Popularity of fashion items are kinda bell-shaped (or
something). 10 years ago BIG SUVs were fashionable. Right now
Teslas are fashionable here in Norway... Just for show off, I
think. :-/ Kinda like JavaScript frameworks!
People have been predicting Apple's downfall for years, while
they grew to become the largest company on earth! Of course,
they have to level off and fall eventually, but who knows when?
The v8 compiler has certainly helped javascript on the server,
but like I said, practically every language will be able to
run the same code with WebAsm, and they'll have a _lot_ more
code already running on the server.
Well. I think we will see legacy applications wrapped up in
suitable containers and stuck into the cloud in maintenance
mode while new projects go new routes. Fast interconnects
(local networking) and fast compute nodes makes it possible to
continue development in a new language and integrate software
across machines... I think.
Maybe, but I don't see them willingly choosing javascript. :)
You can email him and take those issues up with him. I was
only linking it for the conclusion, that the current
client-side dev experience sucks and is likely to be disrupted.
My experience is that the client side dev experience is
improving greatly year by year! Both in general and as far as
cross browser compatibility is concerned. Safari is one step
behind, but... IE is moving. Microsoft is actually cooperating
with Google. I think they are better than Chrome in some
aspects now.
Mozilla developer network and caniuse.com is your friend.
Glad you like it, but many devs disagree with you.
The web stack is so tough to deal with, especially because all
the different browser incompatibilities kill the
cross-platform story, that it's fading fast on mobile.
[...]
A big part of that is the popular and mostly dumb reasoning
that a web app's UI is not really "native" to mobile, but
whether dumb or not, that widespread perception hurts webapps
on mobile.
Right, it is problematic on mobile not because of cross browser
issues, but because the vendors have deliberately created
completely different look and feel on their platforms. And that
sucks for most apps, because they are dominated by UI code...
I think most users are used to the web being different or don't
care about the "look and feel."
But it won't be unseated. Modern HTML5 has critical mass.
WebGL might be unseated.
Heh, I don't think either has gotten very far yet.
WebGL support is close to usable. HTML5 is dominant.
So "dominant" that Facebook ditched their HTML5 mobile app for
native and Snapchat doesn't even have a webapp! HTML5 may now be
fairly ubiquitously _implemented_ in current browsers, but you
greatly overestimate how many devs are using it or want to.
Well, at least we agree that it's massive. :) iOS will always
have the Apple tax, but as long as it's the leading mobile app
platform by revenue, which I hear it still is by a significant
margin, that's a tax most devs are willing to pay.
The tax is not the problem. The problem is that they dictate
deprecation and removal. So when you update to the next version
of iOS you might have to rewrite more of your app than you care
for.
Like... next year maybe they will ban using assembly code in
your app.
I wasn't talking about Apple's revenue cut as a tax, I was
referring to their policies that you referred to earlier as their
tax.
That's not tax, it is a monopolistic dictator state.
Many people enjoy living in Dubai or Saudi Arabia. ;) I could
never live in those places, but they seem to stomach it.
Why would you bother with ES7 if you could just code it all in
most any language of your choice and compile to WebAsm?
Convenience. If I don't need speed it is much much more
convenient to be able to use the REPL and debugger on a live
application/web app.
Scenario: customer calls in and reports a problem with the app.
ES7 solution: I look at the app in the debugger and do some
"poking" on live data to figure out what the problem is. Then I
can quickly call back and say how fast I can fix the issue.
AoT solution: I have to fire up a local environment with a
debugger and then try to replicate the problem that might not
show up for some weird border line reason.
I don't get it: you have access to a debugger _in the customer's
browser_ with ES7?
Or the web stack itself going away, which is very likely.
I'm not sure if you are serious or joking... I mean, the web
stack is not going away in my life time. I am barely been able
to get rid of IE9!
Dead serious, let me quote you Bray's conclusion again:
"On the client, I just totally don’t know. Historical periods
featuring rococo engineering outbursts of colorful duplicative
complexity usually end up converging on something simpler that
hits the right 80/20 points. But if that’s what’s coming, it’s
not coming from any direction I’m looking, so color me baffled.
Maybe we’re stuck with clients-in-triplicate for the long haul."
Every time this happens over the previous decades, something
simpler comes along and 80/20s the past bloated tech. The web is
_long_ overdue for this. They're finally trying to clean it up a
bit, with the recent HTTP/2 and WebAsm moves, but it isn't enough.
Critical mass, installed base and so on will keep the web stack
alive for decades!
Sure, COBOL is still around on some mainframe somewhere too, but
almost nobody knows it exists! :D
