TIOBE December 2015 - D rose 5 positions

[Joakim via Digitalmars-d]

On Wednesday, 6 January 2016 at 18:52:05 UTC, Ola Fosheim Grøstad 
wrote:
> On Wednesday, 6 January 2016 at 16:52:34 UTC, Joakim wrote:
>> Swift is dumbed down?
>
> Yes, they are streamlining for apps.  It is ARC through and 
> through. They are removing things like "++", currying and 
> C-style for-loops; in order to make the language simpler for 
> programmers. Cutting complexity where it isn't really adding 
> much to the language in _typical_ scenarios.

Eh, those removals are all well though-out and sensible, D has 
similar opinions.  I was impressed that most of the stuff they 
say they _won't_ remove is related to C-style syntax:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

They aren't making the mistake of many other languages- cough, 
Haskell, rust, cough- of inventing new syntax for no real reason. 
  Most programmers have a C-style parser wired into their heads: 
you cannot replace it.

btw, maybe Walter and Andrei should write up a similar list on 
the wiki, would be easy for us to point noobs who want one of 
those features to it.

>>  I'm surprised you started off by saying that 80%/GC is the 
>> big market, but now believe D should be "advanced."
>
> It is the bigger crowded tooling-demanding market where you 
> have Java, C#, Go, Swift and a slew of others. Without tooling 
> you don't stand a chance in that market.

D aimed for the niche right below that, with higher efficiency, 
that Swift is now also going after. It turns out that efficiency 
matters, which is why Java and C# never made much headway in 
application programming, certainly not outside their enterprise 
niches, ie consumers don't use Java/C# apps, and are now both 
AoT-compiled on mobile.

> And really, if you want to compete with C, you can't really be 
> in that market. Do it well, or not at all.

C is so old and outdated that you could wrap up both.  It may be 
harder, but it can be done.  C++ certainly took some share from C 
over the years, D could do even better with a lighter runtime.  D 
hasn't really focused on that yet, but I think Walter wants to 
one day.

>>> 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!
>
> No, they aim for ABI stability and portability. No concurrency 
> features.
>
> https://github.com/apple/swift-evolution

Not sure how ABI stability/portability hurts that, but is Swift 
going after C or not?  You seem to say they are, then they 
aren't.  Going after lower-level code that would use C is the 
other horse you mentioned, so if they are, they're trying to 
straddle both.

>> 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++.
>
> With at different team?

Walter is the team. :) He's done embedded work before, he's aware 
of the challenges.

>> We're talking cross-platform here, Swift isn't even in the 
>> game till they get on other platforms than OSX/iOS.
>
> But who are using D for cross platform development today? Isn't 
> Linux the primary platform in real world use (i.e. deployment)?

I don't know, and probably.  But D runs well on all the major 
desktop/server platforms and soon the two major mobile platforms, 
not to mention upcoming platforms like wearables and smart TVs, 
which D devs are currently testing.  Get back to me when Swift 
can say that.

>> 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
>
> I don't really think consumers know what they buy, but people 
> tend to want the same UI experience... so switching over takes 
> time.

The latest iPhone always blows away any Android phone on measures 
of UI lag.  Users don't know what makes a phone fast- the 
components mentioned before, along with not using Java and its 
GC-caused lag for your apps- but they can see when it is.

>> Maybe, but I don't see them willingly choosing javascript. :)
>
> They'll be forced to. Managers will choose whatever readymades 
> carry name recognition... ;^) Java, .NET, node.js, Angular...

And with javascript losing its browser monopoly, it will slide 
down that list. :)

>> I think most users are used to the web being different or 
>> don't care about the "look and feel."
>
> Most users probably don't care, but people who spec mobile apps 
> put it into the requirements.

Which is why I said it's dumb, because most users don't actually 
care about that.  One of the biggest herd behaviours I've seen in 
recent years is the crazy drive to build mobile apps to replace 
perfectly functional webapps, whose CSS UI could be simply redone 
for mobile too.  Unless you have a compelling reason to be 
mobile-first, many are just wasting money.

>> 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.
>
> Not sure what you mean, Facebook invest a lot of money into web 
> tech like React. If anything Facebook is heavily pushing 
> WebApps by funding the frameworks that enables it.

Perhaps you haven't heard, but the original Facebook mobile app 
was simply their HTML5 site bundled on mobile, then they switched 
to native years ago for efficiency:

https://facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920

They may still use and release legacy HTML5 frameworks, ;) as 
that's where they started, but almost half of their users now 
only use the native mobile apps, and that mobile-only user share 
keeps growing:

http://venturebeat.com/2015/07/29/nearly-half-of-facebooks-users-only-access-the-service-on-mobile/

Others have followed them in ditching HTML5.

>> I don't get it: you have access to a debugger _in the 
>> customer's browser_ with ES7?
>
> All browsers have debuggers built in...

I wouldn't know as Chrome is all I use in recent years, and I 
thought that was the only browser that always came with one.  In 
any case, your point is still unclear: why would WebAsm not have 
the same browser support?

>> 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.
>
> I don't see HTTP/2 and WebAsm as  a big thing. It is just 
> another step to make web a more solid cross platform deployment 
> platform.

They cannot fix the real problem, the baroque architectural pasta 
of HTMl/CSS/DOM, but those moves make those two components much 
more efficient, which certainly helps.

> I don't spend much time on compatibility tweaks anymore. I 
> don't mind spending 1% on cross platform. That's actually 
> pretty impressive. Try to get there with native apps on 5 
> platforms: Linux, OS-X, Windows, Android, iOS... Impossible.

It can be done, but it's not actually what I'm suggesting.  I 
think there will be some new cross-platform approach that takes 
over the web's spot.  I've suggested a re-architecting of the web 
approach before, to focus on efficiency and extreme simplicity of 
graphical layout in the client:

http://forum.dlang.org/post/dqddjhccpmxhgcssqtol@forum.dlang.org

I used to want to work on that approach, but I now actually think 
that entire client-server model is outdated.  I suspect what's 
coming is more of a p2p approach, where smartphones simply pass 
data to each other, then construct UIs customized for the user 
out of the data they want to see.  That's my guess, but whatever 
it is, it will kill the web.