TIOBE December 2015 - D rose 5 positions

[Joakim via Digitalmars-d]

On Thursday, 7 January 2016 at 09:12:05 UTC, Ola Fosheim Grøstad 
wrote:
> On Thursday, 7 January 2016 at 04:43:28 UTC, Joakim wrote:
>>  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.

I haven't found Python to be that different, certainly not as 
much as the two I mentioned.  But the required spacing is one of 
the aspects that killed it for me.

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

OK, not a full C competitor, but taking some of the higher-level 
work.  I think D could take all of C's domain, Walter certainly 
knows how.

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

Regardless, the point is the greater efficiency of native worked 
better for them.

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

Yes, which is why many apps that are debuting now are native 
mobile-only, their devs can't be bothered with arcane and 
inefficient legacy platforms like the web. :)

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

You could always splice in the debug info if you're debugging, 
right?  I saw some talk on their github about using DWARF or some 
other debug format: they're considering those tooling issues now.

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

A scene graph jammed into an antiquated document layout, then 
stylesheet and scripting languages mashed on top: what could go 
wrong? :D

Complexity kills.  Try searching the Chromium issue tracker for 
"painting" and see how many issues pop up:

https://code.google.com/p/chromium/issues/list?can=1&q=painting&colspec=ID+Pri+M+Stars+ReleaseBlock+Cr+Status+Owner+Summary+OS+Modified&x=m&y=releaseblock&cells=tiles

Pick some of the obvious UI-related issues from that list and see 
what kind of bugs crop up.  I haven't been involved in Chromium 
development in years, but it was amazing how many painting issues 
would pop up, though perhaps not so amazing once you consider the 
complexity involved.

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

I suggested something completely different in my post, chucking 
the web stack altogether and starting from scratch.  The 
incremental approaches you suggest cannot really change much.

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

Sounds like you're joking, but I was surprised to find that the 
torrent client I ran on my Android tablet ran really fast, better 
than the one I tried on my laptop.  There's a p2p wave coming, 
that will kill off most of this stupid cloud stuff, and take down 
the web stack with it.

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

Let's see, I present arguments why it will happen, while you 
simply state that it cannot.  Who is it that's thinking wishfully 
here? :)

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

I'm not sure what you mean by the web going down that path, but 
I'm talking about not sending GUI info whatsoever, ie going back 
to something like plaintext email, where users simply send 
messages back and forth and the client figures out how to render 
it.  Of course, it will be much more advanced than email, as the 
messages will say what kind of data they contain, and the client 
will construct UIs tailored for the various kinds of message data 
it receives.

On Thursday, 7 January 2016 at 13:32:40 UTC, Russel Winder wrote:
> On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d 
> wrote:
>> […]
>> 
>> We're talking cross-platform here, Swift isn't even in the 
>> game till they get on other platforms than OSX/iOS.
>> 
>
> There is an Ubuntu version that also works on Debian.

Yes, I've mentioned the in-progress linux port in this forum 
several times: it's not finished yet.

>> […]
>> Sure, COBOL is still around on some mainframe somewhere too, 
>> but
>> almost nobody knows it exists! :D
>
> But those that do get £150k+ and almost all are over 60.

Those are both signs that it's so obscure and limited that nobody 
bothers to learn it.  Great paying work for those who grew up 
with it, but it's basically gone.