TIOBE December 2015 - D rose 5 positions

Joakim via Digitalmars-d digitalmars-d at puremagic.com
Wed Jan 6 08:52:34 PST 2016


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


More information about the Digitalmars-d mailing list