TIOBE December 2015 - D rose 5 positions

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 7 January 2016 at 04:43:28 UTC, Joakim wrote:
> 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:

Well, I am not complaining, but they seem to focus on keeping 
complexity out of the Swift syntax and avoid infrequently used 
features in the context of app programming (rather than system 
programming).

>  Most programmers have a C-style parser wired into their heads: 
> you cannot replace it.

You get used to a different syntax rather fast if it is 
reasonably close to something familiar. I was sceptical to 
Python, but picked it up quickly.

> 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.

Java demands lots of memory, but Java is suitable for consumer 
applications on new machines. The problem with consumer devices 
is that the majority of users are on the low end.

> 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.

That would be a nice change of direction. I think the core 
language shouldn't require a runtime at all. But... probably too 
late for D.

> 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.

No, they are not going after C, but making it less necessary to 
drop down to C from Swift. If they have a fixed ABI then you can 
FFI Swift functions?

> 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:

I don't know much about it, but I've heard that Facebook have 
serious internal software development process problems resulting 
in bloat across the board. Just a rumour. I thought that implied 
to their mobile apps too? (I don't use it.)

> 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:

Ok, well, Facebook and other juggernauts can afford to develop 
their apps on all kinds of platforms (from scratch even).

> In any case, your point is still unclear: why would WebAsm not 
> have the same browser support?

We'll see, but less motivation (demand) is my guess. Webasm is 
unreadable, runs as machine language and you don't have type info?

> 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 really think the DOM is baroque. It is like a scene 
graph. The only really bad thing about it is that you set css 
values as strings. It could use a redesign, but it is more 
flexible than regular GUI libraries (which are rather ugly and 
tedious).

> 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:

There are 3 approaches for "re-architecting" gui-style components 
in the web DOM:

1. The approach taken by React which is to have a virtual DOM (a 
pure javascript DOM).

2. The approach taken by Angular which is to have special 
HTML-style attributes for templating functionality (like 
for-loops) and use observers (track change events).

3. The approach taken by Web Components using shadow DOM 
(invisible sub-DOM under custom elements/nodes).

> 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

Smartphones support p2p? That's new to me. I thought they were 
deliberately limited to servers.

> 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.

No, it will not kill the web. Nothing can kill the web... you 
want it, but it ain't happenin'.

That approach is what modern javascript frameworks is supposed to 
support! The web is further down that path than GUI libs. 
Angular2 is basically a client side templating system, and so is 
web components...