www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - TIOBE December 2015 - D rose 5 positions

reply Bubbasaur <bubba gmail.com> writes:
Good news!

D rose from 28th to 23th!

2015 - 
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

2014 - 
http://web.archive.org/web/20141230025738/http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Bubba.
Jan 01 2016
next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Friday, 1 January 2016 at 20:38:31 UTC, Bubbasaur wrote:

 Good news!

 D rose from 28th to 23th!

 2015 - 
 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 2014 - 
 http://web.archive.org/web/20141230025738/http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 Bubba.


doesn't seem very reliable
haskell at 39? go at 50?
doesn't even seem remotely close to Google Trend's data for 
programming languages, for example
https://www.google.com/trends/explore#cmpt=q&q=/m/01kbt7,+/m/03j_q,+/m/09gbxjr&cat=0-5-31
Jan 01 2016
next sibling parent Bubbasaur <bubba gmail.com> writes:
On Friday, 1 January 2016 at 23:12:39 UTC, rsw0x wrote:

 doesn't seem very reliable
 haskell at 39? go at 50?
 doesn't even seem remotely close to Google Trend's data for 
 programming languages, for example
 https://www.google.com/trends/explore#cmpt=q&q=/m/01kbt7,+/m/03j_q,+/m/09gbxjr&cat=0-5-31


I see your point, but if you see the google trends "related 
searches" for "D" in the link you gave, you will see 2 terms that 
are not related:

%d 	
java d

So again I don't know how the google trends works, because if you 
see "Regional Interest" for D, it only shows: USA.

About TIOBE for what I saw the metric is based on search and 
articles related to each language.

And there is at least some reasonable points there, like for 
example: Java which is now in first like swift going to 14th 
place, both I think because mobile market.

Others languages seems reasonable too.

Anyway like I said at least it is a good news for D community.

Bubba.
Jan 01 2016
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 1 January 2016 at 23:12:39 UTC, rsw0x wrote:

 On Friday, 1 January 2016 at 20:38:31 UTC, Bubbasaur wrote:

 Good news!

 D rose from 28th to 23th!

 2015 - 
 http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 2014 - 
 http://web.archive.org/web/20141230025738/http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

 Bubba.


 doesn't seem very reliable
 haskell at 39? go at 50?
 doesn't even seem remotely close to Google Trend's data for 
 programming languages, for example
 https://www.google.com/trends/explore#cmpt=q&q=/m/01kbt7,+/m/03j_q,+/m/09gbxjr&cat=0-5-31


Nobody can measure actual usage, TIOBE seems to be an 
approximation of buzz, since they mostly look at search engines:

http://www.tiobe.com/index.php/content/paperinfo/tpci/programminglanguages_definition.html

Look at the big drop for Obj-C they show this year, there is no 
way _usage_ dropped 80% in the last year.  But with Swift coming 
on strong, buzz could certainly have dropped a lot, as many iOS 
developers shift Obj-C into maintenance mode and stop buying 
books or talking about it as much.

With Android dominating and Java making a comeback on the server, 
its rise this year makes some sense.  People are writing articles 
about Java gaining use again (written two years ago, but I was 
surprised to see Java being hyped up again):

http://www.wired.com/2013/09/the-second-coming-of-java/

As for D, with more talks on youtube and certainly many more 
books coming out this year, it likely trended up on the youtube 
and amazon search components.
Jan 01 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 2 January 2016 at 05:19:49 UTC, Joakim wrote:

 As for D, with more talks on youtube and certainly many more 
 books coming out this year, it likely trended up on the youtube 
 and amazon search components.


If we look at the search trend for "D tutorial" and "D compiler", 
the interest was falling until 2013. It is still falling, but so 
is the overall interest in "programming".

https://www.google.com/trends/explore#cat=0-5-31&q=d%20tutorial%2C%20go%20tutorial%2C%20d%20compiler&cmpt=q&tz=Etc%2FGMT-1

The interest in "Go tutorial" is rapidly increasing though.
Jan 03 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 1 January 2016 at 23:12:39 UTC, rsw0x wrote:

 doesn't seem very reliable


TIOBE is completely unreliable. It's basically a hoax, IMO. I 
guess the company only keeps it alive as a means of marketing for 
their services.

Languages like "D" and "rust" will have so many false positives...

Github gives a better perspective on actual engagement outside 
the close source commercial sector.
Jan 03 2016
next sibling parent reply Bubbasaur <bubba gmail.com> writes:
On Sunday, 3 January 2016 at 12:43:13 UTC, Ola Fosheim Grøstad 
wrote:

 Github gives a better perspective on actual engagement outside 
 the close source commercial sector.


Well if you take for example Linux, which is one of big open 
source project out there and I use it, but if you compare against 
desktop usage vs Windows, it's what 7% of market?

I'm not saying that TIOBE is reliable or not, but it has some 
reasonable numbers like I said above.

Some are shocked because Go language, but most of the time that I 
see an article about Go on Hackernews or Reddit for example, I 
see a lot of bad commentaries against it. IE: Generics.

Bubba.
Jan 03 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 14:15:46 UTC, Bubbasaur wrote:

 Some are shocked because Go language, but most of the time that 
 I see an article about Go on Hackernews or Reddit for example, 
 I see a lot of bad commentaries against it. IE: Generics.


Yes, Go is more of a business language than a fun language, but 
it has fairly strong presence in open source friendly business 
environments such as cloud containers and web services.

TIOBE does not follow sound principles for data collection. You 
even have to be careful when using Google Trends. For instance 
will "d compiler" include searches for "java d compiler".
Jan 03 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Sunday, 3 January 2016 at 14:15:46 UTC, Bubbasaur wrote:

 On Sunday, 3 January 2016 at 12:43:13 UTC, Ola Fosheim Grøstad 
 wrote:

 Github gives a better perspective on actual engagement outside 
 the close source commercial sector.


 Well if you take for example Linux, which is one of big open 
 source project out there and I use it, but if you compare 
 against desktop usage vs Windows, it's what 7% of market?

 I'm not saying that TIOBE is reliable or not, but it has some 
 reasonable numbers like I said above.

 Some are shocked because Go language, but most of the time that 
 I see an article about Go on Hackernews or Reddit for example, 
 I see a lot of bad commentaries against it. IE: Generics.

 Bubba.


because it's not in any way accurate
e.g,
https://github.com/golang/go/wiki/GoUsers
vs
http://wiki.dlang.org/Current_D_Use
Jan 03 2016
next sibling parent reply Bubbasaur <bubba gmail.com> writes:
On Sunday, 3 January 2016 at 14:22:39 UTC, rsw0x wrote:

 because it's not in any way accurate


I can't tell with that list is 100% accurate or not, but wouldn't 
agree that Java as first place? Even with all mobile trend and so 
on? Or C in second, Swift ahead of Object-C?

You showed a link with Go users around the world, but they only 
use Go? Or they use Go and another language, or even Go is their 
second or third language?

Back to the problem... looking that TIOBE's list or the first 10 
entries:

1	Java	21.465%	+5.94%
2	C	16.036%	-0.67%
3	C++	6.914%	+0.21%

5	Python	3.854%	+1.24%
6	PHP	2.706%	-1.08%
7	Visual Basic .NET	2.582%	+1.51%
8	JavaScript	2.565%	-0.71%
9	Assembly language	2.095%	+0.92%
10	Ruby	2.047%	+0.92%

What's so wrong or inaccurate there?

Bubba.
Jan 03 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 14:43:00 UTC, Bubbasaur wrote:

 9	Assembly language	2.095%	+0.92%
 10	Ruby	2.047%	+0.92%


This... haha... Do you really think people spend more time 
writing assembly code in 2015 than Ruby?

2% assembly? That's highly unlikely.
Jan 03 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 14:50:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 14:43:00 UTC, Bubbasaur wrote:

 9	Assembly language	2.095%	+0.92%
 10	Ruby	2.047%	+0.92%


 This... haha... Do you really think people spend more time 
 writing assembly code in 2015 than Ruby?

 2% assembly? That's highly unlikely.


And javascript at 2.5%, what the heck? It should be way way way 
higher.
Jan 03 2016
prev sibling parent Bubbasaur <bubba gmail.com> writes:
On Sunday, 3 January 2016 at 14:50:48 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 14:43:00 UTC, Bubbasaur wrote:

 9	Assembly language	2.095%	+0.92%
 10	Ruby	2.047%	+0.92%


 This... haha... Do you really think people spend more time 
 writing assembly code in 2015 than Ruby?

 2% assembly? That's highly unlikely.


If you take for example C in second, should we glance for 
relationship between languages and embedded system market.

Anyway, you're pointing 1 item in 10.

Well "very inaccurate" list.

Bubba.
Jan 03 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 14:43:00 UTC, Bubbasaur wrote:

 1	Java	21.465%	+5.94%
 2	C	16.036%	-0.67%
 3	C++	6.914%	+0.21%

 5	Python	3.854%	+1.24%
 6	PHP	2.706%	-1.08%
 7	Visual Basic .NET	2.582%	+1.51%
 8	JavaScript	2.565%	-0.71%
 9	Assembly language	2.095%	+0.92%
 10	Ruby	2.047%	+0.92%


Sorry for spamming you, but ok. Let's take a look at github 

languages (number of stars) as an attempt to not favour languages 
with a few popular applications:











Then let's move to Swift, Objective-C, Go, Rust, Nim and D:








Now, this is not extensive, so the following ranking might be 
missing some, but if we reorder top 7 based on this we get the 
following popularity score, with TIOBE in parentheses:

JavaScript: 100 (12)
Python: 49 (18)
Java:  45 (100)
Swift: 32 (6)
Objective-C: 25 (5)
C: 24 (75)
Go: 23 (<1)
C++: 22 (32)
Ruby: 18 (10)
Rust: 3 (1)

TIOBE isn't very useful for tracking trends.
Jan 03 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 3 January 2016 at 14:22:39 UTC, rsw0x wrote:

 On Sunday, 3 January 2016 at 14:15:46 UTC, Bubbasaur wrote:

 On Sunday, 3 January 2016 at 12:43:13 UTC, Ola Fosheim Grøstad 
 wrote:

 Github gives a better perspective on actual engagement 
 outside the close source commercial sector.


 Well if you take for example Linux, which is one of big open 
 source project out there and I use it, but if you compare 
 against desktop usage vs Windows, it's what 7% of market?

 I'm not saying that TIOBE is reliable or not, but it has some 
 reasonable numbers like I said above.

 Some are shocked because Go language, but most of the time 
 that I see an article about Go on Hackernews or Reddit for 
 example, I see a lot of bad commentaries against it. IE: 
 Generics.

 Bubba.


 because it's not in any way accurate
 e.g,
 https://github.com/golang/go/wiki/GoUsers
 vs
 http://wiki.dlang.org/Current_D_Use


As Bubba says, in what way is it not accurate?  You list 
corporate usage of Go and D, but his comment wasn't about that.

Also, is there a company like Sociomantic on that Go list, ie 
built on the language primarily and externally valued at a couple 
hundred million dollars?  Of course, Sociomantic could be a 
one-off special case and they're still on D1, but a bunch of 
corporate dabblers in Go doesn't say much.  You'd expect that of 
a simpler language that's currently hyped more.
Jan 03 2016
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Sunday, 3 January 2016 at 15:17:46 UTC, Joakim wrote:

 On Sunday, 3 January 2016 at 14:22:39 UTC, rsw0x wrote:

 On Sunday, 3 January 2016 at 14:15:46 UTC, Bubbasaur wrote:

 [...]


 because it's not in any way accurate
 e.g,
 https://github.com/golang/go/wiki/GoUsers
 vs
 http://wiki.dlang.org/Current_D_Use


 As Bubba says, in what way is it not accurate?  You list 
 corporate usage of Go and D, but his comment wasn't about that.

 Also, is there a company like Sociomantic on that Go list, ie 
 built on the language primarily and externally valued at a 
 couple hundred million dollars?  Of course, Sociomantic could 
 be a one-off special case and they're still on D1, but a bunch 
 of corporate dabblers in Go doesn't say much.  You'd expect 
 that of a simpler language that's currently hyped more.


docker
twitter migrated most of their backend to go from python
a ton of google stuff uses go now
etc
Jan 03 2016
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 15:17:46 UTC, Joakim wrote:

 As Bubba says, in what way is it not accurate?  You list 
 corporate usage of Go and D, but his comment wasn't about that.


In every way!!! Tiobe is a cultural viral marketing phenomenon, 
but a statistical and scientific disaster.

Go may have a slight bias on github, and there might be a slight 
bias against Microsoft products on github, but there is 
absolutely no reason to think that D is in disfavour on github 
compared to Rust and Go.

The trend is that Go and Swift dwarfs the AoT competition and 
that Rust destroys D and Nim.

(And it should be rather obvious to anyone that a listing that 
does not have JavaScript close to the top is 100% bogus. 
JavaScript is the most widely deployed language, with most 
professional working with it, part time or full time.)
Jan 03 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 3 January 2016 at 15:54:53 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 15:17:46 UTC, Joakim wrote:

 As Bubba says, in what way is it not accurate?  You list 
 corporate usage of Go and D, but his comment wasn't about that.


 In every way!!! Tiobe is a cultural viral marketing phenomenon, 
 but a statistical and scientific disaster.

 Go may have a slight bias on github, and there might be a 
 slight bias against Microsoft products on github, but there is 
 absolutely no reason to think that D is in disfavour on github 
 compared to Rust and Go.

 The trend is that Go and Swift dwarfs the AoT competition and 
 that Rust destroys D and Nim.

 (And it should be rather obvious to anyone that a listing that 
 does not have JavaScript close to the top is 100% bogus. 
 JavaScript is the most widely deployed language, with most 
 professional working with it, part time or full time.)


You missed the context of that quote, it wasn't about TIOBE.  In 
fact, we're not sure what rsw0x is saying is not accurate, as a 
list of corporate usage has little to do with the comment he was 
replying to.

I have no real opinion on the validity of TIOBE, but I think you 
overrate the importance of github and overestimate use of 
javascript.  Of course, there's no good way to settle that 
question.
Jan 03 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 16:10:49 UTC, Joakim wrote:

 I have no real opinion on the validity of TIOBE


That's sad!!!


 but I think you overrate the importance of github and 
 overestimate use of javascript.  Of course, there's no good way 
 to settle that question.


Actually there is. If you look at businesses that use Javascript 
every single small community has javascript programmers, one way 
or the other. Be it a web site company or a advertising company. 
All these businesses that dabble with Javascript one way or the 
other account for way more employees than the focused software 
engineering companies.

A quick search for open positions in norway shows that there are 
twice as many matches for "javascript" than for "c++". And 
usually such positions are more easy to fill.
Jan 03 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 3 January 2016 at 12:43:13 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 1 January 2016 at 23:12:39 UTC, rsw0x wrote:

 doesn't seem very reliable


 TIOBE is completely unreliable. It's basically a hoax, IMO. I 
 guess the company only keeps it alive as a means of marketing 
 for their services.

 Languages like "D" and "rust" will have so many false 
 positives...

 Github gives a better perspective on actual engagement outside 
 the close source commercial sector.


Github has the same problem, btw.  I recently spent some time 
going through the top repositories in this list, and it's 
surprising how many are miscategorized as D, despite having the 
source:

https://github.com/search?l=D&q=stars%3A>1&s=stars&type=Repositories

For example, this one:

https://github.com/2youyouo2/Flash2Cocos2d-x

On Sunday, 3 January 2016 at 15:23:51 UTC, rsw0x wrote:

 On Sunday, 3 January 2016 at 15:17:46 UTC, Joakim wrote:

 Also, is there a company like Sociomantic on that Go list, ie 
 built on the language primarily and externally valued at a 
 couple hundred million dollars?  Of course, Sociomantic could 
 be a one-off special case and they're still on D1, but a bunch 
 of corporate dabblers in Go doesn't say much.  You'd expect 
 that of a simpler language that's currently hyped more.


 docker
 twitter migrated most of their backend to go from python
 a ton of google stuff uses go now
 etc


I don't know much about Docker: is most of their stack built on 
Go, as opposed to a few key components?  Also, they value their 
company at $1.1 billion, but that's  an _internal_ valuation.  
Nobody external has ever valued them that much, as they're still 
private.  They're attracting a fair amount of VC investment, but 
that's actually a negative.

I thought twitter was on Scala, :) I don't think anybody knows 
what grabbag of languages they're currently using.  Also, their 
valuation keeps dropping like a rock, down two-thirds from its 
peak a couple years ago.

Google is certainly not built on Go.

etc
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 15:58:21 UTC, Joakim wrote:

 Github has the same problem, btw.  I recently spent some time 
 going through the top repositories in this list, and it's 
 surprising how many are miscategorized as D, despite having the 
 source:


Yep, Github isn't neutral, but it is the best source for trending 
information I know of, although enterprise technologies 
(Microsoft, Oracle etc) are underrepresented there.

But search engine bias is worse I think. For instance, when I 
search for javascript technologies I never use the phrase 
"javascript". I often search for the specific API since 
JavaScript is so popular that the APIs themselves already get 
good ranking! But when I search for info on C++ I usually start 
with "c++" in every single search, since C++ isn't as popular as 
JavaScript.

Also ranking a search "rust tutorial" fails because Rust already 
have _very_ good standard documentation, so fewer people need to 
search for it.

In one instance I also noticed that the search for "d tutorial" 
matched "d-link tutorial" (how to set up a router). :-) And even 
"d vitamin tutorial", or something like that. :-D

I think the big swooping "automated data collection" lists are 
way too noisy to be useful. The timeline on some specific phrases 
on Google Trends do say something though.


 I don't know much about Docker: is most of their stack built on 
 Go, as opposed to a few key components?  Also, they value their


If you look at github, you'll see that several of the high 
ranking Go projects are related to Docker, Kubernetes and such. 
So Go seems to become a defacto replacement for C in areas where 
C isn't really neededspeed isn't crucial (e.g. configuration etc).

Not so strange, for companies that deals with a specific 
application area it makes sense to standardize on one language.

So, commercial uptake appears to be driving Go adoption in the 
area of "cloud deployment" of various kinds?
Jan 03 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 3 January 2016 at 16:19:49 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 15:58:21 UTC, Joakim wrote:

 Github has the same problem, btw.  I recently spent some time 
 going through the top repositories in this list, and it's 
 surprising how many are miscategorized as D, despite having 
 the source:


 Yep, Github isn't neutral, but it is the best source for 
 trending information I know of, although enterprise 
 technologies (Microsoft, Oracle etc) are underrepresented there.


It's more than not being neutral: I pointed out that github 
suffers from similar categorization errors to the ones you list 
below.  But yes, github stats are really only good for languages 
used in open source, and OSS is still a small fraction of all 
software written.


 But search engine bias is worse I think. For instance, when I 
 search for javascript technologies I never use the phrase 
 "javascript". I often search for the specific API since 
 JavaScript is so popular that the APIs themselves already get 
 good ranking! But when I search for info on C++ I usually start 
 with "c++" in every single search, since C++ isn't as popular 
 as JavaScript.

 Also ranking a search "rust tutorial" fails because Rust 
 already have _very_ good standard documentation, so fewer 
 people need to search for it.

 In one instance I also noticed that the search for "d tutorial" 
 matched "d-link tutorial" (how to set up a router). :-) And 
 even "d vitamin tutorial", or something like that. :-D

 I think the big swooping "automated data collection" lists are 
 way too noisy to be useful. The timeline on some specific 
 phrases on Google Trends do say something though.


Those are definitely real issues with those methods, no question.


 I don't know much about Docker: is most of their stack built 
 on Go, as opposed to a few key components?  Also, they value 
 their


 If you look at github, you'll see that several of the high 
 ranking Go projects are related to Docker, Kubernetes and such. 
 So Go seems to become a defacto replacement for C in areas 
 where C isn't really neededspeed isn't crucial (e.g. 
 configuration etc).

 Not so strange, for companies that deals with a specific 
 application area it makes sense to standardize on one language.


Are you stating that Docker is built on Go or suggesting it would 
make sense if they were?  Sounds like the latter.


 So, commercial uptake appears to be driving Go adoption in the 
 area of "cloud deployment" of various kinds?


I'm actually glad D isn't jumping on a hot trend like "cloud," as 
they're usually fads.  This goes for Sociomantic and ad-tech too: 
they could just be in a hot field and really not mean much for 
the long-term future of D.  Better to focus on making the best 
language you can, and people will find uses for its unique 
strengths.

On Sunday, 3 January 2016 at 16:24:17 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 16:10:49 UTC, Joakim wrote:

 I have no real opinion on the validity of TIOBE


 That's sad!!!


Heh, why should I spend any time thinking about it whatsoever?  
I'm not interested in jousts about programming languages.


 but I think you overrate the importance of github and 
 overestimate use of javascript.  Of course, there's no good 
 way to settle that question.


 Actually there is. If you look at businesses that use 
 Javascript every single small community has javascript 
 programmers, one way or the other. Be it a web site company or 
 a advertising company. All these businesses that dabble with 
 Javascript one way or the other account for way more employees 
 than the focused software engineering companies.


Sure, because you're lumping all the non-Javascript employees 
from any companies that "dabble with javascript" and contrasting 
that number with the companies that don't use it all.  Since 
practically every company has a website that likely uses a little 
javascript, that's trivially true, yet completely irrelevant.

If you were able to compile something like billable hours for 
javascript, it would do well, but nowhere near the top.  
Unfortunately, that key is not available under the lamppost we 
have: TIOBE. :)


 A quick search for open positions in norway shows that there 
 are twice as many matches for "javascript" than for "c++". And 
 usually such positions are more easy to fill.


C++ has been retreating into a niche, along with other 
AoT-compiled languages, even TIOBE shows that in its graph of C++ 
buzz dropping significantly over the last decade.  But javascript 
is primarily a frontend language on a single platform, web apps, 
it will never get "close to the top" of the programming language 
heap.
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 16:56:46 UTC, Joakim wrote:

 It's more than not being neutral: I pointed out that github 
 suffers from similar categorization errors to the ones you list 
 below.  But yes, github stats are really only good for 
 languages used in open source, and OSS is still a small 
 fraction of all software written.


I didn't notice any miscategorization in the trending lists I 
used, there might have been some, but even then the surrounding 

that the numbers would be significantly effected for most 
languages.

Open source is a good indicator of trending. It is also a 
indicator for the productivity of new languages when a new 
language produce many popular open source applications. It is 
also a good indicator of what programming areas a new language is 
going to be popular in. If a language has a long tail of popular 
applications, that's a pretty strong indicator that it will take 
off, IMO. Go is there. Rust isn't quite there (yet). D and Nim 
doesn't show any signs of going there (yet).


 Are you stating that Docker is built on Go or suggesting it 
 would make sense if they were?  Sounds like the latter.


Docker is based on Go.

«Under the hood, Docker is built on the following components:

The cgroups and namespaces capabilities of the Linux kernel
The Go programming language
The Docker Image Specification
The Libcontainer Specification»


 for the long-term future of D.  Better to focus on making the 
 best language you can, and people will find uses for its unique 
 strengths.


Yes, but the trends show that D has been going down over the past 
8 years and has been stagnant over the past 2 years if you look 
at statistics for github and google trends.

So, D has to make a change. Most likely a language change that 
makes it easier to deal with. People say that Go and Swift are 
doing well because they are easy to deal with. I think they are 
right.


 Heh, why should I spend any time thinking about it whatsoever?


It doesn't take any thinking to see that Tiobe is bogus! ;^)


 all.  Since practically every company has a website that likely 
 uses a little javascript, that's trivially true, yet completely 
 irrelevant.


First we need to define what we want to measure. But claiming 
that the marketshare of Javascript is 2.5% is outragous no matter 
how we measure it.


 If you were able to compile something like billable hours for 
 javascript, it would do well, but nowhere near the top.


I think it would be on the top now, yes.


 Unfortunately, that key is not available under the lamppost we 
 have: TIOBE. :)


A broken lamppost without electricity that went out of date over 
a decade ago.


 C++ has been retreating into a niche, along with other 
 AoT-compiled languages, even TIOBE shows that in its graph of 
 C++ buzz dropping significantly over the last decade.


C++ is going down slowly, but probably will reach a plateu with 
enterprises that can afford "large" C++ teams.


 javascript is primarily a frontend language on a single 
 platform, web apps, it will never get "close to the top" of the 
 programming language heap.


I wish. Unfortunately this isn't true anymore. Electron, node.js 
and other frameworks are projecting JavaScript as a VM into more 
and more application areas.

We are just not following the youngsters. They grew up with 
JavaScript. They will make it pervasive.
Jan 03 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
I just discovered another interesting trending list on Github, 
trending developers. Let's see why they are popular.

1. FreeCodeCamp: JavaScript
2. Google:  JavaScript (traceur), Go, C++...
3. Facebook: JavaScript (react)
4. hacksalot: JavaScript
5. oneuijs: JavaScript
6. sindresorhus: n/a
7. AllThingsSmitty: html5...
8. rackt: JavaScript
9. tldr-pages: Shell
10. Airbnb: JavaScript
11. tj: JavaScript
12. angular: JavaScript
13. Microsoft: JavaScript/TypeScript
14. gaearon: JavaScript
15. vuejs: JavaScript
16. Square: Java, JavaScript...
17. diafygi: Python
18. Atom: coffeescript/JavaScript
19. mxstbr: JavaScript
20. Apache: Java, C, C++...

Totally dominated by JavaScript and related technologies (Reach, 
Angular, TypeScript).
Jan 03 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 3 January 2016 at 17:25:13 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 16:56:46 UTC, Joakim wrote:

 It's more than not being neutral: I pointed out that github 
 suffers from similar categorization errors to the ones you 
 list below.  But yes, github stats are really only good for 
 languages used in open source, and OSS is still a small 
 fraction of all software written.


 I didn't notice any miscategorization in the trending lists I 
 used, there might have been some, but even then the surrounding 

 think that the numbers would be significantly effected for most 
 languages.


I gave you a specific example, the 32nd most starred "D repo" 
according to github, which has nothing to do with D (there are 

list).  The amazing part is that if you click on the D link on 
the language breakdown for that cocos2d repo, it'll say it 
couldn't find any D files!  So it somehow miscategorizes that 
project as primarily built on D, despite github's filename 
analyzer not finding any D files. :)


 Open source is a good indicator of trending. It is also a 
 indicator for the productivity of new languages when a new 
 language produce many popular open source applications. It is 
 also a good indicator of what programming areas a new language 
 is going to be popular in. If a language has a long tail of 
 popular applications, that's a pretty strong indicator that it 
 will take off, IMO. Go is there. Rust isn't quite there (yet). 
 D and Nim doesn't show any signs of going there (yet).


Those are good hypotheses, not sure you can say OSS usage is a 
good _indicator_ yet, especially since I wouldn't say Go has 
taken off.


 Are you stating that Docker is built on Go or suggesting it 
 would make sense if they were?  Sounds like the latter.


 Docker is based on Go.

 «Under the hood, Docker is built on the following components:

 The cgroups and namespaces capabilities of the Linux kernel
 The Go programming language
 The Docker Image Specification
 The Libcontainer Specification»


You seem to have gotten that quote from the README for the OSS 
project, but we were talking about the stack at Docker, the 
company.  I highly doubt that OSS github repo is all they have to 
their stack, as they would have tons of competition and wouldn't 
be able to garner that ridiculous private valuation if they did, 
so my question was if they've talked about whether Go also powers 
the rest of their stack.


 for the long-term future of D.  Better to focus on making the 
 best language you can, and people will find uses for its 
 unique strengths.


 Yes, but the trends show that D has been going down over the 
 past 8 years and has been stagnant over the past 2 years if you 
 look at statistics for github and google trends.


I'm not sure what to make of the google trends data, but it's 
possible that much D code is simply not OSS.  Certainly you'll 
find very little of Sociomantic's codebase on github.


 So, D has to make a change. Most likely a language change that 
 makes it easier to deal with. People say that Go and Swift are 
 doing well because they are easy to deal with. I think they are 
 right.


I think D has a real complexity problem, so anything we can do to 
make it simpler _while still maintaining its power_ would be 
welcomed.  But D is a machine shop, it's not a screwdriver like 
Go.  You can't make a machine shop as easy to use as a 
screwdriver, unless you plan on staffing it with robots.  If you 
have a proposal to replace all D programmers with robots, then 
I'd like to hear it. :)


 Heh, why should I spend any time thinking about it whatsoever?


 It doesn't take any thinking to see that Tiobe is bogus! ;^)


It takes time to examine their process, something I don't care to 
do since I don't care what their results are!  If I did, I 
wouldn't be working on D, which has never featured very highly in 
their ranking.


 all.  Since practically every company has a website that 
 likely uses a little javascript, that's trivially true, yet 
 completely irrelevant.


 First we need to define what we want to measure. But claiming 
 that the marketshare of Javascript is 2.5% is outragous no 
 matter how we measure it.


It's a measure of buzz, not usage or share, as I said with Obj-C. 
  I could see JS buzz going down in recent years, but 2.5% does 
seem low.


 If you were able to compile something like billable hours for 
 javascript, it would do well, but nowhere near the top.


 I think it would be on the top now, yes.


You think there were more hours billed by programmers for 

it.


 Unfortunately, that key is not available under the lamppost we 
 have: TIOBE. :)


 A broken lamppost without electricity that went out of date 
 over a decade ago.


It would be more succinct and accurate to say that you don't 
think the key is anywhere near that lamppost. :)


 C++ has been retreating into a niche, along with other 
 AoT-compiled languages, even TIOBE shows that in its graph of 
 C++ buzz dropping significantly over the last decade.


 C++ is going down slowly, but probably will reach a plateu with 
 enterprises that can afford "large" C++ teams.


Which are also a dying breed.


 javascript is primarily a frontend language on a single 
 platform, web apps, it will never get "close to the top" of 
 the programming language heap.


 I wish. Unfortunately this isn't true anymore. Electron, 
 node.js and other frameworks are projecting JavaScript as a VM 
 into more and more application areas.

 We are just not following the youngsters. They grew up with 
 JavaScript. They will make it pervasive.


On the contrary, I suspect that we've passed "Peak JS", with 
WebAsm about to cripple it.
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 4 January 2016 at 05:47:40 UTC, Joakim wrote:

 according to github, which has nothing to do with D (there are 

 list).


Yes, DTrace files also end with ".d"...


 Those are good hypotheses, not sure you can say OSS usage is a 
 good _indicator_ yet, especially since I wouldn't say Go has 
 taken off.


I think it has, it might taper off early and be displaced by 
Swift, but it seems healthy. Rust appears to have hit an early 
plateu.


 You seem to have gotten that quote from the README for the OSS 
 project, but we were talking about the stack at Docker, the 
 company.


I have no idea. They appear to have both Go and Python projects 
on Github, and some other languages.


 I think D has a real complexity problem, so anything we can do 
 to make it simpler _while still maintaining its power_ would be 
 welcomed.


That's a good starting point! :)


 You think there were more hours billed by programmers for 

 doubt it.


Yes, I think Java and JavaScript are on top.


 On the contrary, I suspect that we've passed "Peak JS", with 
 WebAsm about to cripple it.


How come? I would expect new programmers to be focused on 
JavaScript as they grew up with the less dysfunctional 
implementation.

I don't think we are anywhere near "peak js". WebWorkers are 
coming now, and they change the game by providing isolated 
threads with fast message passing of heaps/arrays. Which I think 
is pretty good.
Jan 04 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 4 January 2016 at 08:34:06 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 4 January 2016 at 05:47:40 UTC, Joakim wrote:

 according to github, which has nothing to do with D (there are 

 above list).


 Yes, DTrace files also end with ".d"...


Not the cocos2d files though, no excuse there.


 Those are good hypotheses, not sure you can say OSS usage is a 
 good _indicator_ yet, especially since I wouldn't say Go has 
 taken off.


 I think it has, it might taper off early and be displaced by 
 Swift, but it seems healthy. Rust appears to have hit an early 
 plateu.


I don't think Go's even hit the second tier yet, ie python and 
ruby, certainly not in the first tier with Java and C, though 
tough for such a young language to get up there.


 On the contrary, I suspect that we've passed "Peak JS", with 
 WebAsm about to cripple it.


 How come? I would expect new programmers to be focused on 
 JavaScript as they grew up with the less dysfunctional 
 implementation.

 I don't think we are anywhere near "peak js". WebWorkers are 
 coming now, and they change the game by providing isolated 
 threads with fast message passing of heaps/arrays. Which I 
 think is pretty good.


WebAsm will provide some form of concurrency also.  Further, 
there are plans to eventually provide access to the DOM and all 
web APIs:

https://github.com/WebAssembly/design/blob/master/GC.md

Javascript use was driven by its monopoly in the browser, but 
that's soon going away.  The most common reason given for using 
it on the server was to use the same language on the server and 
client, but that reasoning will now work _against_ javascript, as 
you'll be able to compile your server language to WebAsm instead.

That will cripple javascript, and full access to the DOM from 
WebAsm will kill it off.

Of course, the entire web stack could be obsoleted in the 
meantime, which I think is actually the most likely outcome.
Jan 04 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 4 January 2016 at 11:12:49 UTC, Joakim wrote:

 I don't think Go's even hit the second tier yet, ie python and 
 ruby, certainly not in the first tier with Java and C, though 
 tough for such a young language to get up there.


Well, Go and Swift are the two languages that are having a steep 
increasing curve on Google Trends. The other languages are either 
flat or going down (Java and C++).

I think the curve matters more right now. People don't want to do 
manual memory management and want simple syntax and decent speed, 
but not necessarily optimal speed (80% is good enough?). That's 
what I perceive anyway.


 WebAsm will provide some form of concurrency also.  Further, 
 there are plans to eventually provide access to the DOM and all 
 web APIs


Yes, but it will take like 2-5 years before it gets adopted. 
WebWorkers are getting available now. (I am using it already.)


 Javascript use was driven by its monopoly in the browser, but 
 that's soon going away.  The most common reason given for using 
 it on the server was to use the same language on the server and 
 client, but that reasoning will now work _against_ javascript, 
 as you'll be able to compile your server language to WebAsm 
 instead.

 That will cripple javascript, and full access to the DOM from 
 WebAsm will kill it off.


I don't know. EcmaScript7 with TypeScript gradual typing might 
turn out to beat other scripting languages like Lua, Dart and 
even Python, Ruby...

I am thinking of using WebAsm for the application engine and 
TypeScript + Angular2 for user interface.

Unfortunately I don't know of any suitable WebAsm runtime-less 
language. D3 maybe? :)


 Of course, the entire web stack could be obsoleted in the 
 meantime, which I think is actually the most likely outcome.


In 20 years.
Jan 04 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 4 January 2016 at 20:25:09 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 4 January 2016 at 11:12:49 UTC, Joakim wrote:

 I don't think Go's even hit the second tier yet, ie python and 
 ruby, certainly not in the first tier with Java and C, though 
 tough for such a young language to get up there.


 Well, Go and Swift are the two languages that are having a 
 steep increasing curve on Google Trends. The other languages 
 are either flat or going down (Java and C++).


Because they're much higher up.


 I think the curve matters more right now. People don't want to 
 do manual memory management and want simple syntax and decent 
 speed, but not necessarily optimal speed (80% is good enough?). 
 That's what I perceive anyway.


That's D's corner of the market, it was there long before Go and 
Swift came after it. :) Of course, D doesn't get the hype and 
automatic usage that those languages get because they're from 
Google and Apple, but quality wins out in the medium-term.


 WebAsm will provide some form of concurrency also.  Further, 
 there are plans to eventually provide access to the DOM and 
 all web APIs


 Yes, but it will take like 2-5 years before it gets adopted. 
 WebWorkers are getting available now. (I am using it already.)


Maybe not 4-5, but yes, they're over-engineering a lot of this 
stuff and adoption will take years.


 Javascript use was driven by its monopoly in the browser, but 
 that's soon going away.  The most common reason given for 
 using it on the server was to use the same language on the 
 server and client, but that reasoning will now work _against_ 
 javascript, as you'll be able to compile your server language 
 to WebAsm instead.

 That will cripple javascript, and full access to the DOM from 
 WebAsm will kill it off.


 I don't know. EcmaScript7 with TypeScript gradual typing might 
 turn out to beat other scripting languages like Lua, Dart and 
 even Python, Ruby...


I have not looked at ECMAScript 7, but I have difficulty 
believing any variant of javascript can ever beat out most of 
those other scripting languages on the server.


 I am thinking of using WebAsm for the application engine and 
 TypeScript + Angular2 for user interface.

 Unfortunately I don't know of any suitable WebAsm runtime-less 
 language. D3 maybe? :)


I'm sure it will be pretty easy to recompile D2 to WebAsm using 
ldc, as llvm will support it, so ldc can be easily modified to 
support it.


 Of course, the entire web stack could be obsoleted in the 
 meantime, which I think is actually the most likely outcome.


 In 20 years.


Unlikely, did you read that Tim Bray article I linked last summer?

https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014

Any time a tech gets so bloated and complex, it's ripe to be 
unseated by something simpler.  Look at how Windows made no 
headway on mobile and Intel has almost no share in smartphones, 
largely because they haven't been able to get their power budget 
down.  The bloated web stack is long overdue for similar 
disruption.
Jan 04 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 04:19:33 UTC, Joakim wrote:

 Because they're much higher up.


Yes, but the languages that are on the rise are cutting into the 
existing languages. It is difficult to predict when they hit a 
ceiling though.


 That's D's corner of the market, it was there long before Go 
 and Swift came after it. :) Of course, D doesn't get the hype 
 and automatic usage that those languages get because they're 
 from Google and Apple, but quality wins out in the medium-term.


I think D will loose the market for 80% efficiency and automatic 
memory management without a redesign of syntax/language semantics:

1. It cannot add ARC etc without becoming too like Swift, because 
then Swift will win on tooling alone. Keep in mind that Swift is 
getting "hygenic macros".

2. It cannot compete with Go GC, not even in theory.

3. The current approach to C++ integration will become less and 
less useful as C++ libraries are moving more and more heavily 
towards templating.

Seems to me that D's easy market is "embedded C++" and "better 
C", with good platform support. Meaning: easy programming for 
engines. That means the only real competitor is Rust.

But a focused choice has to be made, either D will go for the 
"80% and ARC" or it will have to focus on beating "C/C++/Rust" in 
the "engine"/embedded programming market.

Riding two horses won't make it. The design complexity for 
enabling "easy programming" across the board grows non-linear as 
the feature set expands. Apple is hellbent on making Swift 
excellent for low level application programming ("80% 
efficiency") and have C as a fallback for "100% efficiency" and 
engines/libraries.

But "easy programming" for embedded/engines/libraries is still 
open as I think Swift won't make it, C/C++ is locked into a 
corner and Rust have some barrier to entry issues (e.g. some 
programmers won't get over the syntax and borrowing memory 
management semantics).


 Maybe not 4-5, but yes, they're over-engineering a lot of this 
 stuff and adoption will take years.


I think it will take 2-4 years before we see compatible "native" 
WebAsm in Safari, Firefox, Explorer and Chrome. Then add 1-3 
years for debugging and tooling... So actually, I think 2-5 years 
is a low estimate, maybe 3-7 years is more reasonable.

Apple might decide to delay the process to protect App Store..


 I have not looked at ECMAScript 7, but I have difficulty 
 believing any variant of javascript can ever beat out most of 
 those other scripting languages on the server.


It will have performant JIT and the ability to run same code on 
server and client.


 I'm sure it will be pretty easy to recompile D2 to WebAsm using 
 ldc, as llvm will support it, so ldc can be easily modified to 
 support it.


Well, I think emscripten had to fork clang, so it takes more than 
just llvm. Also, you need to do it well, so you have to build a 
new runtime etc.

And worse: solve debugging issues. JavaScript is debuggable. Code 
translated into JavaScript is somewhat debuggable by using source 
maps.

What will WebAssembly provide for debugging?

It is easy to forget that tooling is critical and can delay 
adoption many years.


 Unlikely, did you read that Tim Bray article I linked last 
 summer?

 https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014


1. No, but I don't agree with him. Http is not so important. 
Browsers support SPDY and HTTP/2. And websockets are coming.

2. Functional programming is not sufficient for solving 
concurrency issues. Reactive programming does not scale. If you 
want concurrency, you have to look to actor programming. It 
scales in a robust way and allows you to mix different 
technologies/languages.

3. No idea what he meant with storage. Scalable key-value stores 
are commodity and a semi persistent version of it is built into 
the browser.

4. The only way that EcmaScript7 is not going to take over on 
mobile for regular apps is to make langauges/tooling for 
solutions like ios/Swift much better. If it isn't much better 
then cross platform gravity will win. So it really depends on 
what Apple/Google want.

Apple can sabotage EcmaScript7 on iOS in order to sabotage cross 
platform apps on iOS.

I don't think Google will sabotage it on Android as they are 
working on Dart-on-mobile-frameworks. And Android is the bigger 
market over time.


 Any time a tech gets so bloated and complex, it's ripe to be 
 unseated by something simpler.


Well, JavaScript isn't bloated and complex. It is the 
layout/render/animation engine for HTML5 that is complex.

But it won't be unseated. Modern HTML5 has critical mass. WebGL 
might be unseated.

Browser vendors will try to deprecate features instead. Google is 
claiming that they will remove SMIL for instance.


 budget down.  The bloated web stack is long overdue for similar 
 disruption.


Nope. HTML5 is massive and fully cross platform. Other platforms 
are highly unstable. Just look at iOS. It forces developers to 
upgrade/rewrite for strategic reasons.

I don't want that. I don't want Apple to dictate when I have to 
reimplement an app.
Jan 05 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Here is an overview of ES6, ES7:

http://kangax.github.io/compat-table/es6/
http://kangax.github.io/compat-table/es7/

As you can see, even ES6 has features that D lacks, like 
destructuring, and it brings ES close to existing scripting 
languages.

With ES7 you also get SIMD and language level async. At that 
point only tooling will keep ES7 out of broad application 
development.

I can totally see ES7 + C/C++ bottom layer take over cross 
platform app development. Compile C/C++ to WebAssembly/native and 
build the app in ES7 (or a language close to it).

Only sabotage can prevent it, IMO.
Jan 05 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 5 January 2016 at 10:49:06 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 5 January 2016 at 04:19:33 UTC, Joakim wrote:

 Because they're much higher up.


 Yes, but the languages that are on the rise are cutting into 
 the existing languages. It is difficult to predict when they 
 hit a ceiling though.


I think Go's hitting its ceiling now.  It will be interesting to 
see what Swift's ceiling is: we'll find out if and when they ever 
get it on Android.  Of course, some would say D already hit its 
ceiling, ;) but a rebound is sometimes possible.


 That's D's corner of the market, it was there long before Go 
 and Swift came after it. :) Of course, D doesn't get the hype 
 and automatic usage that those languages get because they're 
 from Google and Apple, but quality wins out in the medium-term.


 I think D will loose the market for 80% efficiency and 
 automatic memory management without a redesign of 
 syntax/language semantics:

 1. It cannot add ARC etc without becoming too like Swift, 
 because then Swift will win on tooling alone. Keep in mind that 
 Swift is getting "hygenic macros".


Walter seems against ARC anyway.


 2. It cannot compete with Go GC, not even in theory.


Dunno about that, but Go cannot compete with D's  nogc.


 3. The current approach to C++ integration will become less and 
 less useful as C++ libraries are moving more and more heavily 
 towards templating.


That's a separate issue from efficiency with automatic memory 
management, but since I don't care about C++ integration at all, 
not one I can say much about.


 Seems to me that D's easy market is "embedded C++" and "better 
 C", with good platform support. Meaning: easy programming for 
 engines. That means the only real competitor is Rust.

 But a focused choice has to be made, either D will go for the 
 "80% and ARC" or it will have to focus on beating "C/C++/Rust" 
 in the "engine"/embedded programming market.

 Riding two horses won't make it. The design complexity for 
 enabling "easy programming" across the board grows non-linear 
 as the feature set expands. Apple is hellbent on making Swift 
 excellent for low level application programming ("80% 
 efficiency") and have C as a fallback for "100% efficiency" and 
 engines/libraries.


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.


 But "easy programming" for embedded/engines/libraries is still 
 open as I think Swift won't make it, C/C++ is locked into a 
 corner and Rust have some barrier to entry issues (e.g. some 
 programmers won't get over the syntax and borrowing memory 
 management semantics).


I think Swift could go after that market, but they too will 
probably have to add C++ integration to do it.  C++ will never be 
easy, but they seem to be trying to clean up to have a better 
shot of grabbing some share there.  I agree that Rust can't get 
there, nor do they likely want to.


 Maybe not 4-5, but yes, they're over-engineering a lot of this 
 stuff and adoption will take years.


 I think it will take 2-4 years before we see compatible 
 "native" WebAsm in Safari, Firefox, Explorer and Chrome. Then 
 add 1-3 years for debugging and tooling... So actually, I think 
 2-5 years is a low estimate, maybe 3-7 years is more reasonable.


I was thinking more like 1-2 for the first iteration, and they're 
considering debugging and tooling issues right now.


 Apple might decide to delay the process to protect App Store..


It's not a significant enough source of revenue for them, I doubt 
they care.  Maybe only in the sense of having iOS exclusives, 
which is really a benefit for the iDevices.


 I have not looked at ECMAScript 7, but I have difficulty 
 believing any variant of javascript can ever beat out most of 
 those other scripting languages on the server.


 It will have performant JIT and the ability to run same code on 
 server and client.


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.


 I'm sure it will be pretty easy to recompile D2 to WebAsm 
 using ldc, as llvm will support it, so ldc can be easily 
 modified to support it.


 Well, I think emscripten had to fork clang, so it takes more 
 than just llvm. Also, you need to do it well, so you have to 
 build a new runtime etc.


I wouldn't call it a clang fork, it doesn't look like they change 
much:

https://github.com/kripken/emscripten-fastcomp-clang/commits/master

As for the runtime, have you been following WebAsm closely enough 
to know what it would require?  I doubt it will take much more 
than modifying druntime a bit and compiling to WebAsm.


 And worse: solve debugging issues. JavaScript is debuggable. 
 Code translated into JavaScript is somewhat debuggable by using 
 source maps.

 What will WebAssembly provide for debugging?

 It is easy to forget that tooling is critical and can delay 
 adoption many years.


Maybe they'll build a gdb server into the browser, which you can 
access remotely. :D


 Unlikely, did you read that Tim Bray article I linked last 
 summer?

 https://www.tbray.org/ongoing/When/201x/2014/01/01/Software-in-2014


 1. No, but I don't agree with him. Http is not so important. 
 Browsers support SPDY and HTTP/2. And websockets are coming.

 2. Functional programming is not sufficient for solving 
 concurrency issues. Reactive programming does not scale. If you 
 want concurrency, you have to look to actor programming. It 
 scales in a robust way and allows you to mix different 
 technologies/languages.

 3. No idea what he meant with storage. Scalable key-value 
 stores are commodity and a semi persistent version of it is 
 built into the browser.


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.


 4. The only way that EcmaScript7 is not going to take over on 
 mobile for regular apps is to make langauges/tooling for 
 solutions like ios/Swift much better. If it isn't much better 
 then cross platform gravity will win. So it really depends on 
 what Apple/Google want.


I think writing your business logic in a cross-platform language 

UI in the language native to the platform is the more likely 
outcome, ie back to the pre-web standard for cross-platform dev.  
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.  The 
WebAsm push may even be based on another aspect of that, to 
counter the notion that webapps cannot be efficient enough for 
mobile.


 Apple can sabotage EcmaScript7 on iOS in order to sabotage 
 cross platform apps on iOS.

 I don't think Google will sabotage it on Android as they are 
 working on Dart-on-mobile-frameworks. And Android is the bigger 
 market over time.


Yep, mobile frameworks like google's new C++/Dart-based Flutter 
shows they likely see webapps sputtering, which may also be why 
they're giving up on ChromeOS as a standalone platform:

http://flutter.io


 Any time a tech gets so bloated and complex, it's ripe to be 
 unseated by something simpler.


 Well, JavaScript isn't bloated and complex. It is the 
 layout/render/animation engine for HTML5 that is complex.


Sure, javascript is only inefficient and messy. :)


 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.


 Browser vendors will try to deprecate features instead. Google 
 is claiming that they will remove SMIL for instance.


Never even heard of it, but I wish they'd just remove SVG 
altogether. :)


 budget down.  The bloated web stack is long overdue for 
 similar disruption.


 Nope. HTML5 is massive and fully cross platform. Other 
 platforms are highly unstable. Just look at iOS. It forces 
 developers to upgrade/rewrite for strategic reasons.

 I don't want that. I don't want Apple to dictate when I have to 
 reimplement an app.


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.

On Tuesday, 5 January 2016 at 11:04:34 UTC, Ola Fosheim Grøstad 
wrote:

 Here is an overview of ES6, ES7:

 http://kangax.github.io/compat-table/es6/
 http://kangax.github.io/compat-table/es7/

 As you can see, even ES6 has features that D lacks, like 
 destructuring, and it brings ES close to existing scripting 
 languages.

 With ES7 you also get SIMD and language level async. At that 
 point only tooling will keep ES7 out of broad application 
 development.

 I can totally see ES7 + C/C++ bottom layer take over cross 
 platform app development. Compile C/C++ to WebAssembly/native 
 and build the app in ES7 (or a language close to 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?


 Only sabotage can prevent it, IMO.


Or the web stack itself going away, which is very likely.
Jan 05 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:

 I think Go's hitting its ceiling now.  It will be interesting 
 to see what Swift's ceiling is: we'll find out if and when they 
 ever get it on Android.


The graphs for Go does not show a ceiling yet, but the 
"theoretical" ceiling for Go is probably less than 25% of Java. 
Go is not so attractive for spare time use (not so fun), so I 
think Swift has a much higher ceiling if the OSS/Linux crowd 
picks up support. Swift + C seems to speak quite well to their 
needs actually.


  Of course, some would say D already hit its ceiling, ;) but a 
 rebound is sometimes possible.


A rebound is very much possible with a new major release, like a 
streamlined/polished D3 edition (just don't release it before it 
is polished, lots of people come to try D if it comes to a 3.0 , 
so it better work perfectly at 3.0.0! :-). A good strategy is to 
bring the semantics up on the 2.X line and then refurbish the 
syntax for a 3.0 release. That way you have solid internals and a 
fresh and shiny surface that will entice new and old users to try 
it out.

D probably should aim for a lower ceiling and keep focus on 
"advanced features". Go and Swift will try to stay "dumbed down", 

in-house training.


 Walter seems against ARC anyway.


In my experience on can get a long way with Unique (unique_ptr in 
C++) and dynamic arrays. Then "manual ref counting" where it is 
insufficient.


 Dunno about that, but Go cannot compete with D's  nogc.


That's right, the scope of Go is quite limited.

Swift3 probably will try to get closer to C though. Apple seems 
to be focused on making C less frequently needed.


 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.

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.


 I agree that Rust can't get there, nor do they likely want to.


Yep, Rust is kinda ML inspired. Seems to be more geared towards 
"functional" high level and memory-safe-C + unique_ptr low level. 
Which is a decent niche if they stay focused on it. They main 
benefit of Rust seems to be that it is easy to enable 
runtime-less programming. So it could take the embedded market 
over time.


 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.

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.

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!


 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.


 As for the runtime, have you been following WebAsm closely 
 enough to know what it would require?  I doubt it will take 
 much more than modifying druntime a bit and compiling to WebAsm.


No, my impression is that it currently is as limited as asm.js? 
Unfortunately, I cannot find good documentation for the asm.js 
environment. Seems like I would have to look at the emscripten 
runtime! And that is just too tedious.

Please let me know if you find/know of a reference for the asm.js 
environment, beyond the asm.js code gen.


 Maybe they'll build a gdb server into the browser, which you 
 can access remotely. :D


I think that is the NACL way, actually. I've never gone beyond 
"hello world" with NACL, so I don't know how well it worked.

But, having a built in debugger like we have for Javascript is 
most likely much much better...


 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.


 I think writing your business logic in a cross-platform 

 Swift and your UI in the language native to the platform is the 
 more likely outcome, ie back to the pre-web standard for 
 cross-platform dev.


Mm... for games. Dart was a pretty solid language. ES7 is pretty 
close to Dart. As long as Apple, Google and Microsoft backs it...


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

One solution might be to create a cool visual UI that is very 
simple and intuitive and implement it in webGL. _when_ lower tier 
mobile phones get decent GPUs. A few generations and it will be 
reality YMMV.


 Yep, mobile frameworks like google's new C++/Dart-based Flutter 
 shows they likely see webapps sputtering, which may also be why 
 they're giving up on ChromeOS as a standalone platform:


It is interesting that they are backing this. Hopefully they can 
do it in a way that forces Apple to follow suit.


 Sure, javascript is only inefficient and messy. :)


It is messy without a typed layer over it. But can be quite 
efficient if you know what not to do. And it is top notch for 
some things like dynamic regular expressions. Will destroy 
anything written in C/C++, D or Rust.

The basic skill needed is to understand what is fast and why, and 
use those fast mechanisms. Like building a regular expression 
rather than manually search using a javascript look. Or using 
typed arrays rather than javascript arrays.


 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.


 Never even heard of it, but I wish they'd just remove SVG 
 altogether. :)


Will never happen. SVG support is strong across the board:

http://caniuse.com/#feat=svg
http://caniuse.com/#feat=svg-html5
http://caniuse.com/#feat=svg-html
http://caniuse.com/#feat=svg-css
http://caniuse.com/#feat=css-animation

You can use CSS on SVG elements and to some extent CSS animate 
them. All vendors back this, even Microsoft. I recently replaced 
SVG-SMIL with CSS animations.


 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.

That's not tax, it is a monopolistic dictator state.


 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.


 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!

Critical mass, installed base and so on will keep the web stack 
alive for decades!
Jan 05 2016
parent reply Joakim <dlang joakim.fea.st> writes:
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 

 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
Jan 06 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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.


  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 

don't stand a chance in that market.

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


 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


 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?


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


 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.


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


 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.


 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.


 I don't get it: you have access to a debugger _in the 
 customer's browser_ with ES7?


All browsers have debuggers built in...


 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.

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.
Jan 06 2016
parent reply Joakim <dlang joakim.fea.st> writes:
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 

 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 

application programming, certainly not outside their enterprise 

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.
Jan 06 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
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 

 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...
Jan 07 2016
parent reply Joakim <dlang joakim.fea.st> writes:
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.
Jan 07 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 8 January 2016 at 04:10:58 UTC, Joakim wrote:


 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.


He has categorically refused to add volatile or VLA...


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


Which ones? The only one I know of are either redundant or 
involves payment. Developing for mobile is maybe 8x more 
expensive than web...


 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.


Depends on browser vendors...


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


Uhm, not sure what you mean by that. Qt, cocoa etc are more old 
fashioned...
You also have WAI requirements... Required by law!


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


I experience this once every two years. Usually fixed in less 
than a day.


 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.


Did you provide a novel solution?


 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.


You cannot rely on static IP address.


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


Statistically unlikely when you reach critical mass. The web has 
more critical mass than any other IT infrastructure.


 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.


Wont happen as long as there are business opportunities in 
creating islands. Only works if open source destroy the market. 
Ref the web.
Jan 08 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 8 January 2016 at 18:01:39 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 8 January 2016 at 04:10:58 UTC, Joakim wrote:


 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.


 He has categorically refused to add volatile or VLA...


Because he prefers other solutions for those problems.


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


 Which ones? The only one I know of are either redundant or 
 involves payment. Developing for mobile is maybe 8x more 
 expensive than web...


Snapchat has no Windows or web app, you literally can't use it on 
Windows. I've even heard of major shopping sites in developing 
markets that shut down their mobile web sites, referring all 
traffic to the mobile app instead.  Whether this is only because 
of the mobile craze or real issues they had with web dev, I don't 
know.


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


 Uhm, not sure what you mean by that. Qt, cocoa etc are more old 
 fashioned...
 You also have WAI requirements... Required by law!


So accessibility is only required of web browsers?  Sure, many 
antiquated native UI frameworks are almost as bad, but I'd guess 
that none in wide use is as bad.


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


 I experience this once every two years. Usually fixed in less 
 than a day.


I'd regularly hit such painting issues, largely because I was 
running the Dev version and then report them.  Many are weeded 
out before hitting Chrome Stable, whereas others persisted over 
many Stable releases, before magically disappearing one day, 
likely randomly fixed by some commit that introduced some other 
bug. ;)


 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.


 Did you provide a novel solution?


I haven't seen such proposed elsewhere, but you'd have to decide 
that for yourself.  In any case, since it's still using the same 
client-server approach as the web, I don't think it matters: that 
entire approach is doomed.


 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.


 You cannot rely on static IP address.


Many home desktops don't have a static IP either, the ISP usually 
cycles them every couple days between customers.  In any case, 
not a real problem with current p2p tech, which doesn't assume it.


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


 Statistically unlikely when you reach critical mass. The web 
 has more critical mass than any other IT infrastructure.


Did any companies have more critical mass than Microsoft with 
Windows and Intel with x86 chips?  Yet, they missed the largest 
computing platform of them all, the smartphone, which Apple rode 
to become the largest and most profitable company on the planet.  
You greatly overestimate the value of "mass" in this day and age.


 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.


 Wont happen as long as there are business opportunities in 
 creating islands. Only works if open source destroy the market.


That's a good point, so much is tied to business models.  The 
cloud is largely sustained by dumb VCs and large corporations 
dumping billions into it, despite Ballmer's sage point that 
nobody makes any real money there other than google.  They all 
imagine they're the next google, when really they're the next 
Dash Navigation.

Open source would definitely be a big piece of the p2p wave, as 
you could get a lot more done with less source using each, but I 
think there will be a big role for new business models too.  
Since the current cloud business models don't actually make 
money, all the new business models have to do is be profitable 
and they'll quickly kill the cloud off. :)


 Ref the web.


No idea what this means, you think the web won because it was 
open source?  It was an open standard, but it certainly was not 
open source when it won in the '90s.
Jan 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 8 January 2016 at 18:31:37 UTC, Joakim wrote:

 He has categorically refused to add volatile or VLA...


 Because he prefers other solutions for those problems.


But programmers don't. Heap allocation is not a solution to VLA. 
VLA provides a bound on execution time, malloc doesn't.


 So accessibility is only required of web browsers?  Sure, many 
 antiquated native UI frameworks are almost as bad, but I'd 
 guess that none in wide use is as bad.


No, accessibility (for blind people etc) is required for all 
general public services. The web has standards that makes this 
low overhead. But obviously, if you have an accessible web 
service, you can provide alternative non-accessible means too. 
But you do need the accessible version.


 running the Dev version and then report them.  Many are weeded 
 out before hitting Chrome Stable, whereas others persisted over 
 many Stable releases, before magically disappearing one day, 
 likely randomly fixed by some commit that introduced some other 
 bug. ;)


Ah ok. The issues I have had was only triggered when using non-OS 
fonts (webfonts).


 decide that for yourself.  In any case, since it's still using 
 the same client-server approach as the web, I don't think it 
 matters: that entire approach is doomed.


Still wishful thinking... ;) You seem to take a political stance 
on this. That's ok, but if it isn't commercial friendly it won't 
gain traction easily.


 usually cycles them every couple days between customers.  In 
 any case, not a real problem with current p2p tech, which 
 doesn't assume it.


Ok, I've never used p2p on mobile. I don't use p2p on the desktop 
anymore either. I generally avoid apps that connect to random 
servers. It makes your connection and machine more vulnerable to 
attacks.


 Did any companies have more critical mass than Microsoft with 
 Windows and Intel with x86 chips?  Yet, they missed the largest 
 computing platform of them all, the smartphone, which Apple 
 rode to become the largest and most profitable company on the 
 planet.  You greatly overestimate the value of "mass" in this 
 day and age.


Windows still has critical mass in businesses. Microsoft also 
missed the Internet, but managed somehow to dominate it 
eventually, for over a decade, with IE, and still has a dominant 
position alongside Chrome. The tail for IE and Windows is 
looooong. I even have a machine with XP still, because of 
software I have on it.

Smartphones took over the feature-phone market, not the desktop. 
Yet many people prefer feature phones still. I do. I use a tablet 
in my backpack, and a cheap robust feature phone in my jacket, it 
has 30 days battery life and is basically unbreakable (I drop it 
into the ground/pavement frequently). Smartphones are fashionable 
gadgets, but not very practical (big size, breaks easily, no 
battery life) or particularly useful. But because they are 
fashionable people try to invent use scenarios for them, thus you 
gets lots of "superfluous" apps, making them seem like a 
necessity. "You need one in order to be part of society". But 
that is rubbish.

The same goes for "you have to be on Facebook in order to be part 
of society". I got into such social media 20+ years ago, got 
bored with it 10 years ago. We had access to iPAQs with wireless 
networking 15 years ago. If you get access to tech ahead of the 
curve (like 10+ years) and the actual realization of it becomes 
rather bland... And you can just sit down and wait for it to 
taper off.

That is not true for the web. I was underimpressed with the web 
when it was introduced. Today I am impressed. It is dominating 
the desktop severely.

The enabling factor of mobile apps is not mind-blowing on the 
same level. I am under-impressed. Ipad is an excellent gaming 
platform, a decent reader and browser unit. Chat I got fed up 
with in 1992... ;)

The only big negative for web tech is the lack of a solution for 
small/micro-payments.


 Open source would definitely be a big piece of the p2p wave, as 
 you could get a lot more done with less source using each, but 
 I think there will be a big role for new business models too.


First you need to fix vulnerability issues such as DoS and 
breakin. P2P isn't viable as the general paradigm until that is 
fixed.


 No idea what this means, you think the web won because it was 
 open source?  It was an open standard, but it certainly was not 
 open source when it won in the '90s.


I think the web managed to keep an open document model because:

1. There were enough good  free widespread browsers to prevent a 
closed binary protocol from emerging.

2. The standards emerged from an open infrastructure project that 
had wide support in the academic community and therefore also 
among programmers. Meaning: society as a whole was behind it.

IE6 created issues for developers, but not for the open format, 
although the immature browser wars was far from ideal and had 
some negative effects.

One problem for new projects is that commercial interests will 
try to displace the tech before it gains widespread adoption. 
That has happened with chat. Over and over.
Jan 08 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Friday, 8 January 2016 at 19:21:30 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 8 January 2016 at 18:31:37 UTC, Joakim wrote:

 decide that for yourself.  In any case, since it's still using 
 the same client-server approach as the web, I don't think it 
 matters: that entire approach is doomed.


 Still wishful thinking... ;) You seem to take a political 
 stance on this. That's ok, but if it isn't commercial friendly 
 it won't gain traction easily.


How is it "political?"  My prediction is entirely geared around 
hardware and software realities.


 usually cycles them every couple days between customers.  In 
 any case, not a real problem with current p2p tech, which 
 doesn't assume it.


 Ok, I've never used p2p on mobile. I don't use p2p on the 
 desktop anymore either. I generally avoid apps that connect to 
 random servers. It makes your connection and machine more 
 vulnerable to attacks.


Perhaps, but not if you're just sharing data with friends over 
p2p tech, as you'd be doing most of the time.  If you're 
accessing pirated media, of course that's a different story.


 Did any companies have more critical mass than Microsoft with 
 Windows and Intel with x86 chips?  Yet, they missed the 
 largest computing platform of them all, the smartphone, which 
 Apple rode to become the largest and most profitable company 
 on the planet.  You greatly overestimate the value of "mass" 
 in this day and age.


 Windows still has critical mass in businesses. Microsoft also 
 missed the Internet, but managed somehow to dominate it 
 eventually, for over a decade, with IE, and still has a 
 dominant position alongside Chrome. The tail for IE and Windows 
 is looooong. I even have a machine with XP still, because of 
 software I have on it.


Well, we're almost a decade into the mobile wave, and Microsoft 
has not been able to leverage their "critical mass" to get more 
than 3% share.  With Apple and Google launching two-in-one 
devices recently, they're going head-on after the PC market next.


 Smartphones took over the feature-phone market, not the 
 desktop. Yet many people prefer feature phones still. I do. I 
 use a tablet in my backpack, and a cheap robust feature phone 
 in my jacket, it has 30 days battery life and is basically 
 unbreakable (I drop it into the ground/pavement frequently). 
 Smartphones are fashionable gadgets, but not very practical 
 (big size, breaks easily, no battery life) or particularly 
 useful. But because they are fashionable people try to invent 
 use scenarios for them, thus you gets lots of "superfluous" 
 apps, making them seem like a necessity. "You need one in order 
 to be part of society". But that is rubbish.


Except feature phones are not really computing devices, whereas 
smartphones now ship with ARM chips that are more powerful than 
laptop chips from 3-4 years ago, so they've been sapping the PC 
market too, whose sales have been dropping for years.  And most 
people prefer smartphones, which have been selling more than 
feature phones worldwide for a couple years now.

If you're dropping your phone all the time, don't want to charge 
it at night, and don't want to access the internet on the go, 
yes, a feature phone is better for _you_.  However, that places 
you in a _very small_ group: most everybody prefers a smartphone, 
with current feature phone sales primarily to those who cannot 
afford a smartphone.

I agree that there's a lot of hype around smartphones and you 
certainly don't need one to be part of "society," but they _are_ 
very useful.  Having an online map with my GPS location with me 
at all times, supplemented with photos and other info about all 
the local restaurants and stores nearby is a killer app.  Perhaps 
you have not tried Google Maps, but it is really worth the price 
of a smartphone, not to mention the camera and all the other 
stuff you get.


 The same goes for "you have to be on Facebook in order to be 
 part of society". I got into such social media 20+ years ago, 
 got bored with it 10 years ago. We had access to iPAQs with 
 wireless networking 15 years ago. If you get access to tech 
 ahead of the curve (like 10+ years) and the actual realization 
 of it becomes rather bland... And you can just sit down and 
 wait for it to taper off.


I have never joined a social network, not Orkut, friendster, 
twitter, any of them.  If there was a way to share photos with a 
p2p-based open standard, I'd use that though.


 That is not true for the web. I was underimpressed with the web 
 when it was introduced. Today I am impressed. It is dominating 
 the desktop severely.


What changed?


 The enabling factor of mobile apps is not mind-blowing on the 
 same level. I am under-impressed. Ipad is an excellent gaming 
 platform, a decent reader and browser unit. Chat I got fed up 
 with in 1992... ;)


It is mind-blowing when you consider how much computing power is 
in such a small device. :) Maybe you don't get around much, but 
having a mobile assistant with you at all times is great, 
particularly when visiting new areas or cities.


 The only big negative for web tech is the lack of a solution 
 for small/micro-payments.


Heh, I think micropayments will be the killer business model for 
p2p. :) I wonder if it can ever really be done for the web, 
considering all the security issues in the web stack.  That's 
another place where the complexity of the web stack kills it, all 
the security holes that pop up.


 Open source would definitely be a big piece of the p2p wave, 
 as you could get a lot more done with less source using each, 
 but I think there will be a big role for new business models 
 too.


 First you need to fix vulnerability issues such as DoS and 
 breakin. P2P isn't viable as the general paradigm until that is 
 fixed.


Has the web fixed all its vulnerabilities?  Of course not, so 
that's hardly a deal-breaker.  p2p would be easier to secure.


 No idea what this means, you think the web won because it was 
 open source?  It was an open standard, but it certainly was 
 not open source when it won in the '90s.


 I think the web managed to keep an open document model because:

 1. There were enough good  free widespread browsers to prevent 
 a closed binary protocol from emerging.

 2. The standards emerged from an open infrastructure project 
 that had wide support in the academic community and therefore 
 also among programmers. Meaning: society as a whole was behind 
 it.

 IE6 created issues for developers, but not for the open format, 
 although the immature browser wars was far from ideal and had 
 some negative effects.


You mention open formats several times, but none of that has 
anything to do with open source, which was a non-factor in the 
web browser's rise.  And IE created several issues for the open 
format, they were just worked away over time.


 One problem for new projects is that commercial interests will 
 try to displace the tech before it gains widespread adoption. 
 That has happened with chat. Over and over.


I wouldn't call it "displace" as much as co-opt, ;) as they're 
still building pretty much the same tech.  And there's nothing 
wrong with that in principle, in fact, the web would've likely 
gone nowhere if Netscape hadn't formed and driven it.  The 
problems arise when they get overly proprietary and start 
lawyering and patenting everything up, an unfortunate side effect 
of the legal system and greed.

The p2p wave will have to be driven by commercial models: open 
source is not going to do it alone, though it will play a big 
role, as it does in any big tech these days.  I don't think it'd 
be too hard to avoid the commercial mistakes of the past, however.
Jan 08 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 9 January 2016 at 04:24:05 UTC, Joakim wrote:

 How is it "political?"  My prediction is entirely geared around 
 hardware and software realities.


No, businesses don't want P2P, client-server is the ultimate 
dongle...


 _are_ very useful.  Having an online map with my GPS location 
 with me at all times, supplemented with photos and other info 
 about all the local restaurants and stores nearby is a killer 
 app.  Perhaps you have not tried Google Maps, but it is really 
 worth the price of a smartphone, not to mention the camera and 
 all the other stuff you get.


Feature phones have camera, video, facebookapp, opera mini, 
bluetooth, p2p filesharing over bluetooth...

Yes, maps are nice, but I only need it once every 2 months, so 
what I do is print one out. I grew up in Oslo, so I know the 
areas. In fact tourists frequently ask for direction still and 
norwegians too, whether they have flat battery or not. It is 
easier to do planning on a big paper map too. Google map lacks 
accuracy, paths, roadblocks/snow coditions...

As a world travelling tourist you dont want to show that you have 
money, it makes you a target for muggers. Americans often make 
this mistake and paint themselves as easy targets. Showing off an 
iphone is a mistake...

Feature phones will die when smartphones become small/robust/long 
battery life.


 That is not true for the web. I was underimpressed with the 
 web when it was introduced. Today I am impressed. It is 
 dominating the desktop severely.


 What changed?


Webapps are displacing desktop apps.


 is in such a small device. :) Maybe you don't get around much, 
 but having a mobile assistant with you at all times is great, 
 particularly when visiting new areas or cities.


Well, only in Oslo, but I know this city... And people are 
helpful if you ask.


 Heh, I think micropayments will be the killer business model 
 for p2p. :) I wonder if it can ever really be done for the web, 
 considering all the security issues in the web stack.  That's 
 another place where the complexity of the web stack kills it, 
 all the security holes that pop up.


The problem is getting people to sign up for it.


 Has the web fixed all its vulnerabilities?  Of course not, so 
 that's hardly a deal-breaker.  p2p would be easier to secure.


?


 You mention open formats several times, but none of that has 
 anything to do with open source, which was a non-factor in the 
 web browser's rise.


Are you kidding? Mosaic was critical to the raise of the web.


 wrong with that in principle, in fact, the web would've likely 
 gone nowhere if Netscape hadn't formed and driven it.


I disagree.

But something like Flash would have been in a stronger position.
Jan 09 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 9 January 2016 at 10:13:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 9 January 2016 at 04:24:05 UTC, Joakim wrote:

 How is it "political?"  My prediction is entirely geared 
 around hardware and software realities.


 No, businesses don't want P2P, client-server is the ultimate 
 dongle...


I don't think businesses care what technical architecture they're 
using.  Many have stayed away from the cloud, because they're 
understandably worried about putting their confidential data on 
somebody else's servers.

Not sure exactly what you mean by "ultimate dongle," but if you 
mean it's just plug-and-play, I'd say it's far away from that, 
though certainly better in that regard than maintaining your own 
software in-house.


 _are_ very useful.  Having an online map with my GPS location 
 with me at all times, supplemented with photos and other info 
 about all the local restaurants and stores nearby is a killer 
 app.  Perhaps you have not tried Google Maps, but it is really 
 worth the price of a smartphone, not to mention the camera and 
 all the other stuff you get.


 Feature phones have camera, video, facebookapp, opera mini, 
 bluetooth, p2p filesharing over bluetooth...


They may have some of those, but they're not very usable on a 
tiny, low-res screen.


 Yes, maps are nice, but I only need it once every 2 months, so 
 what I do is print one out. I grew up in Oslo, so I know the 
 areas. In fact tourists frequently ask for direction still and 
 norwegians too, whether they have flat battery or not. It is 
 easier to do planning on a big paper map too. Google map lacks 
 accuracy, paths, roadblocks/snow coditions...


I've used it in a couple different countries, it's surpringly 
good.  Not 100% accurate, but no map is.


 Feature phones will die when smartphones become 
 small/robust/long battery life.


They're already dying now, feature phone sales have been dropping 
for years, as smartphones take over that market:

http://www.gartner.com/newsroom/id/2996817


 That is not true for the web. I was underimpressed with the 
 web when it was introduced. Today I am impressed. It is 
 dominating the desktop severely.


 What changed?


 Webapps are displacing desktop apps.


So nothing important changed about the web technology itself, 
you're just impressed by its success?


 Heh, I think micropayments will be the killer business model 
 for p2p. :) I wonder if it can ever really be done for the 
 web, considering all the security issues in the web stack.  
 That's another place where the complexity of the web stack 
 kills it, all the security holes that pop up.


 The problem is getting people to sign up for it.


Nah, that's no problem at all, as lots of people would like to 
use it.  The problem is making it really easy to use and secure, 
like most new tech.


 Has the web fixed all its vulnerabilities?  Of course not, so 
 that's hardly a deal-breaker.  p2p would be easier to secure.


 ?


I guess you're referring to the "easier to secure" bit?  If 
you're simply sending structured messages with actual user-viewed 
data back and forth over p2p, that's much easier to secure than a 
remotely-executed programming language (javascript) and several 
other formatting languages thrown in 
(HTML/CSS/XML/dumb-web-API-of-the-day), as the web stack 
undertakes.

P2p is not inherently easier than client-server, only if done 
simply, like the way I described.


 You mention open formats several times, but none of that has 
 anything to do with open source, which was a non-factor in the 
 web browser's rise.


 Are you kidding? Mosaic was critical to the raise of the web.


The OSS Mosaic prototype was very important in spreading the idea 
in the beginning.  But it had almost no impact on the subsequent 
_rise_ through regular users, which all happened when they left 
university to form Netscape.  If they hadn't built a company to 
drive it, it would have gone nowhere, just as we see many OSS 
projects doing today.


 wrong with that in principle, in fact, the web would've likely 
 gone nowhere if Netscape hadn't formed and driven it.


 I disagree.

 But something like Flash would have been in a stronger position.


No, you'd still have been going online through proprietary 
networks like Prodigy, CompuServe, AOL, or The Microsoft Network: 
:)

https://en.wikipedia.org/wiki/MSN_Dial-up#The_Microsoft_Network

There would have been no web and no Flash on top of it without 
Netscape.
Jan 09 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 9 January 2016 at 13:43:09 UTC, Joakim wrote:

 On Saturday, 9 January 2016 at 10:13:01 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 9 January 2016 at 04:24:05 UTC, Joakim wrote:

 How is it "political?"  My prediction is entirely geared 
 around hardware and software realities.


 No, businesses don't want P2P, client-server is the ultimate 
 dongle...




Copy protection. Anti-piracy measure in hardware.


 I've used it in a couple different countries, it's surpringly 
 good.  Not 100% accurate, but no map is.


It is good enough for inner-city, but not as a pedestrian looking 
for shortcuts, going for walks/biking in the forest/mountains or 
driving in rural areas.


 They're already dying now, feature phone sales have been 
 dropping for years, as smartphones take over that market


Yes, the sales are dropping, but feature phones last longer (or 
people hand over when they get smart phone). So usage is higher 
than the sales suggest.


 So nothing important changed about the web technology itself, 
 you're just impressed by its success?


I has changed dramatically over the past 5 years.


 The OSS Mosaic prototype was very important in spreading the 
 idea in the beginning.  But it had almost no impact on the 
 subsequent _rise_ through regular users, which all happened 
 when they left university to form Netscape.  If they hadn't 
 built a company to drive it, it would have gone nowhere, just 
 as we see many OSS projects doing today.


Well, I don't think that is true. But Flash or something like it 
would probably be a lot stronger.


 No, you'd still have been going online through proprietary 
 networks like Prodigy, CompuServe, AOL, or The Microsoft 
 Network: :)


Or maybe there would have been a market for commercial browsers, 
like Opera.
Jan 09 2016
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 9 January 2016 at 14:01:20 UTC, Ola Fosheim Grøstad 
wrote:

 Or maybe there would have been a market for commercial 
 browsers, like Opera.


This timeline is quite telling:

https://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg

It is rather obvious that the web would have evolved without 
Netscape. But Internet Explorer could have become completely 
dominating, of course.
Jan 09 2016
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 9 January 2016 at 14:01:20 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 9 January 2016 at 13:43:09 UTC, Joakim wrote:

 On Saturday, 9 January 2016 at 10:13:01 UTC, Ola Fosheim 
 Grøstad wrote:

 On Saturday, 9 January 2016 at 04:24:05 UTC, Joakim wrote:

 How is it "political?"  My prediction is entirely geared 
 around hardware and software realities.


 No, businesses don't want P2P, client-server is the ultimate 
 dongle...




 Copy protection. Anti-piracy measure in hardware.


Heh, the web had none until very recently, and that's something 
most businesses don't use.


 I've used it in a couple different countries, it's surpringly 
 good.  Not 100% accurate, but no map is.


 It is good enough for inner-city, but not as a pedestrian 
 looking for shortcuts, going for walks/biking in the 
 forest/mountains or driving in rural areas.


And there's some paper map out there that has all that and is up 
to date? :)


 So nothing important changed about the web technology itself, 
 you're just impressed by its success?


 I has changed dramatically over the past 5 years.


Right, my original question was what changed in the tech so that 
you're now impressed?  Since you don't name anything, doesn't 
sound like anything in the tech itself caused the change in your 
impression.


 No, you'd still have been going online through proprietary 
 networks like Prodigy, CompuServe, AOL, or The Microsoft 
 Network: :)


 Or maybe there would have been a market for commercial 
 browsers, like Opera.


Sure, my original point was that it took the commercial backing 
of Netscape.  If it would have happened a lot later because of a 
commercial backer like Opera, the point still stands that it gets 
nowhere as an OSS project alone, without a commercial backer, 
especially back then when most people weren't online.

On Saturday, 9 January 2016 at 14:12:22 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 9 January 2016 at 14:01:20 UTC, Ola Fosheim 
 Grøstad wrote:

 Or maybe there would have been a market for commercial 
 browsers, like Opera.


 This timeline is quite telling:

 https://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg

 It is rather obvious that the web would have evolved without 
 Netscape. But Internet Explorer could have become completely 
 dominating, of course.


I'm not sure what that timeline tells you, as it leaves out 
market share.  Netscape dominated that early period, before IE 
gained steam because MS bundled it with Windows.  The fact that 
there were many other browsers with negligible share is neither 
here nor there; it was the commercial backing of Netscape that 
built the web audience, before commercially-backed IE came in and 
took it.
Jan 09 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 9 January 2016 at 16:58:15 UTC, Joakim wrote:

 On Saturday, 9 January 2016 at 14:01:20 UTC, Ola Fosheim 
 Grøstad wrote:

 Copy protection. Anti-piracy measure in hardware.


 Heh, the web had none until very recently, and that's something 
 most businesses don't use.


If you run a critical part of an application on the server, then 
piracy becomes more difficult. Key example is online games.


 And there's some paper map out there that has all that and is 
 up to date? :)


Paper and web ;)


 Right, my original question was what changed in the tech so 
 that you're now impressed?  Since you don't name anything, 
 doesn't sound like anything in the tech itself caused the 
 change in your impression.


JavaScript performance, lots of new standards implemented across 
the board, ranging from offline storage to 3D and animation apis.
Jan 09 2016
parent Joakim <dlang joakim.fea.st> writes:
On Saturday, 9 January 2016 at 17:29:34 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 9 January 2016 at 16:58:15 UTC, Joakim wrote:

 On Saturday, 9 January 2016 at 14:01:20 UTC, Ola Fosheim 
 Grøstad wrote:

 Copy protection. Anti-piracy measure in hardware.


 Heh, the web had none until very recently, and that's 
 something most businesses don't use.


 If you run a critical part of an application on the server, 
 then piracy becomes more difficult. Key example is online games.


Oh, I thought you were talking about DRM; in that sense, sure.


 Right, my original question was what changed in the tech so 
 that you're now impressed?  Since you don't name anything, 
 doesn't sound like anything in the tech itself caused the 
 change in your impression.


 JavaScript performance, lots of new standards implemented 
 across the board, ranging from offline storage to 3D and 
 animation apis.


It sounds like you like the application framework they've turned 
the web into, whereas for me, it's like constructing a rickety 
building on a deeply flawed foundation.  Time will tell which of 
us is right. :)
Jan 09 2016
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 We're talking cross-platform here, Swift isn't even in the game=C2=A0
 till they get on other platforms than OSX/iOS.
=20


There is an Ubuntu version that also works on Debian.


 [=E2=80=A6]
 Sure, COBOL is still around on some mainframe somewhere too, but=C2=A0
 almost nobody knows it exists! :D


But those that do get =C2=A3150k+ and almost all are over 60.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Jan 07 2016
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d wrote:

 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.


I'm a little surprised that there aren't more young programmers seeing that 
money and learning some COBOL. It's not a hard language.
Jan 08 2016
next sibling parent cym13 <cpicard openmailbox.org> writes:
On Friday, 8 January 2016 at 18:34:54 UTC, Walter Bright wrote:

 On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d 
 wrote:

 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.


 I'm a little surprised that there aren't more young programmers 
 seeing that money and learning some COBOL. It's not a hard 
 language.


I think younger programmers are easily influenced by two things: 
school and trends. Cobol isn't taught in school anymore (AFAIK) 
and definitely isn't cool. You don't show up to a programmer 
meeting with your sticker-full mac and your overpriced headphones 
saying you are doing COBOL. It's not just that being trendy means 
social recognition, it's also that they fear that by coding in 
COBOL they'll be stuck with it all their life while by using the 
newest technologies they can justify trying a lot of them.

At least that's how I feel things are with the younger 
programmers around me.
Jan 08 2016
prev sibling next sibling parent rsw0x <anonymous anonymous.com> writes:
On Friday, 8 January 2016 at 18:34:54 UTC, Walter Bright wrote:

 On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d 
 wrote:

 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.


 I'm a little surprised that there aren't more young programmers 
 seeing that money and learning some COBOL. It's not a hard 
 language.


The pay might be high, but the positions are limited. I'd say 
there's probably 30-50+ .NET jobs in my area for every 
COBOL/FORTRAN job.
Jan 08 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 8 January 2016 at 18:34:54 UTC, Walter Bright wrote:

 I'm a little surprised that there aren't more young programmers 
 seeing that money and learning some COBOL. It's not a hard 
 language.


Maybe he is referring to programmers that has intimate knowledge 
of the spaghetti-like application the bank uses? If they quit, 
the bank risks being shut down...

At any rate, there is only 1-2 ads that mentions Cobol here in 
Norway. So... kinda risky, but  you probably get in-house Cobol 
and spaghetti-app training. You probably don't get a raise until 
you threaten to quit after mastering the spaghetti... ;)
Jan 08 2016
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Friday, 8 January 2016 at 18:34:54 UTC, Walter Bright wrote:

 I'm a little surprised that there aren't more young programmers 
 seeing that money and learning some COBOL. It's not a hard 
 language.


I've often been tempted but would have to move at least 8 hours 
away to find any kind of employment maintaining COBOL code.
Jan 08 2016
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 1/8/16 1:34 PM, Walter Bright wrote:

 On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d wrote:

 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.


 I'm a little surprised that there aren't more young programmers seeing
 that money and learning some COBOL. It's not a hard language.


Who wants to work on systems that would use COBOL for a language?

-Steve
Jan 08 2016
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Jan 08, 2016 at 06:33:52PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:

 On 1/8/16 1:34 PM, Walter Bright wrote:

On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d wrote:

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.


I'm a little surprised that there aren't more young programmers
seeing that money and learning some COBOL. It's not a hard language.


 
 Who wants to work on systems that would use COBOL for a language?


[...]

Not me, but years ago a roommate of mine specifically went into COBOL
just so he could get job security working on COBOL-based legacy
mainframes.  I haven't kept in touch, however, so I don't know how that
actually turned out.


T

-- 
Freedom of speech: the whole world has no right *not* to hear my spouting off!
Jan 08 2016
prev sibling parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 08/01/2016 18:34, Walter Bright wrote:

 On 1/7/2016 5:32 AM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2016-01-06 at 16:52 +0000, Joakim via Digitalmars-d wrote:

 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.


 I'm a little surprised that there aren't more young programmers seeing
 that money and learning some COBOL. It's not a hard language.


First, if a developer is working in banking, they are likely to be able 
to earn a big salary regardless of language. It's common for a senior 
Java developer to earn a £150k+ salary, here in the London banking 
sector. I doubt a junior COBOL developer would earn anywhere near that 
much, the banks would still want vast COBOL experience, not just knowledge.
So yeah, lets say a COBOL job would earn you 20-30% more than an 
equivalent Java role in a bank. Would it be worth to spend 2-5 years 
working in a COBOL role for that extra money, and racking up COBOL 
legacy experience, with the risk that in some years the technology might 
become obsolete? (unlike Java, for which the development experience 
woulds till count a lot for, in other ares) Well, maybe yes, maybe no, 
hard to say. Also depends on personal preferences of the developer.


Also, the fintech sector is propping up, with a bit of luck these 
outdated banking IT system will be a thing of the past soon. See for 
example: https://getmondo.co.uk/

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Jan 11 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:

 Walter seems against ARC anyway.


Andrei does not seem to be, however.
D's GC is a failure, the amount of effort needed/given to work 
around it should be proof enough of this.
Jan 05 2016
next sibling parent reply Gerald <me me.com> writes:
On Tuesday, 5 January 2016 at 17:10:51 UTC, rsw0x wrote:

 D's GC is a failure, the amount of effort needed/given to work 
 around it should be proof enough of this.


Coming from a Java background and being an application rather 
then systems developer one thing that attracted me to D was the 
garbage collection. While D's GC implementation is not great, I'd 
hate to see it dropped. Personally I'd rather priority be given 
to improving the GC implementation rather then building manual 
allocation methods but that's just me.
Jan 05 2016
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 5 January 2016 at 17:42:15 UTC, Gerald wrote:

 On Tuesday, 5 January 2016 at 17:10:51 UTC, rsw0x wrote:

 D's GC is a failure, the amount of effort needed/given to work 
 around it should be proof enough of this.


 Coming from a Java background and being an application rather 
 then systems developer one thing that attracted me to D was the 
 garbage collection. While D's GC implementation is not great, 
 I'd hate to see it dropped. Personally I'd rather priority be 
 given to improving the GC implementation rather then building 
 manual allocation methods but that's just me.


D's GC will forever be far below anything in a managed 
environment without fundamentally altering the language.

I'd honestly be surprised if a GC heavy D application was faster 
than python.
Jan 05 2016
prev sibling parent reply Suliman <evermind live.ru> writes:
On Tuesday, 5 January 2016 at 17:10:51 UTC, rsw0x wrote:

 On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:

 Walter seems against ARC anyway.


 Andrei does not seem to be, however.
 D's GC is a failure, the amount of effort needed/given to work 
 around it should be proof enough of this.


There is no problem, to write on C if you do not need GC.
Jan 05 2016
parent rsw0x <anonymous anonymous.com> writes:
On Tuesday, 5 January 2016 at 18:02:39 UTC, Suliman wrote:

 On Tuesday, 5 January 2016 at 17:10:51 UTC, rsw0x wrote:

 On Tuesday, 5 January 2016 at 15:20:53 UTC, Joakim wrote:

 Walter seems against ARC anyway.


 Andrei does not seem to be, however.
 D's GC is a failure, the amount of effort needed/given to work 
 around it should be proof enough of this.


 There is no problem, to write on C if you do not need GC.


Then why use D? Most of the standard library and large portion of 
language features are locked out if you opt-out of the GC.
If it half-asses two things, then there's no reason to use it.
Jan 05 2016
prev sibling parent reply Bubbasaur <bubba gmail.com> writes:
On Friday, 1 January 2016 at 20:38:31 UTC, Bubbasaur wrote:

 Good news...


Well I'll stop this discussing about this list. I just posted 
this because I thought It would be good for the users.

By the way, the Jan 2016 list is out and D rose 2 positions, now 
is 21th.

Bubba.
Jan 03 2016
next sibling parent rsw0x <anonymous anonymous.com> writes:
On Sunday, 3 January 2016 at 15:13:01 UTC, Bubbasaur wrote:

 On Friday, 1 January 2016 at 20:38:31 UTC, Bubbasaur wrote:

 Good news...


 Well I'll stop this discussing about this list. I just posted 
 this because I thought It would be good for the users.

 By the way, the Jan 2016 list is out and D rose 2 positions, 
 now is 21th.

 Bubba.


D being in the top 20 would be very good, reliable Tiobe or not. 
A lot of people do look at Tiobe and it would get D some much 
needed exposure.
Jan 03 2016
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 3 January 2016 at 15:13:01 UTC, Bubbasaur wrote:

 On Friday, 1 January 2016 at 20:38:31 UTC, Bubbasaur wrote:

 Good news...


 Well I'll stop this discussing about this list. I just posted 
 this because I thought It would be good for the users.

 By the way, the Jan 2016 list is out and D rose 2 positions, 
 now is 21th.

 Bubba.


Bah NVM, it's always the same story with the TIOBE index, 
whatever is the language. When the fanboys of a particular 
language are happy with the position they say that's because 
"their" language is so fucking awesome, otherwise they cry 
because "TIOBE is a completly biased bag of crap".

The reality is that expect the 3 or 4 first, all the langs are 
more or a less at the same level, between 0.5 and 2 percents, and 
that's there is never great wins or major decays. Their ranking 
is only meaningful on a long scale...
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 15:34:13 UTC, Basile B. wrote:

 and that's there is never great wins or major decays. Their 
 ranking is only meaningful on a long scale...


It is only meaningful for tiobe.com's SEO ranking. Any other use 
is completely and utterly _delusional_.
Jan 03 2016
parent reply Basile B. <b2.temp gmx.com> writes:
On Sunday, 3 January 2016 at 15:38:11 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 3 January 2016 at 15:34:13 UTC, Basile B. wrote:

 and that's there is never great wins or major decays. Their 
 ranking is only meaningful on a long scale...


 It is only meaningful for tiobe.com's SEO ranking. Any other 
 use is completely and utterly _delusional_.


I just meant that nobody will ever be able to see a new industry 
standard raising from a month to another but rather on 60 
monthes...Even if artifact existed, like Go, which's been already 
mentioned.
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 18:19:27 UTC, Basile B. wrote:

 I just meant that nobody will ever be able to see a new 
 industry standard raising from a month to another but rather on 
 60 monthes...Even if artifact existed, like Go, which's been 
 already mentioned.


Yep, sure. Traditionally it has taken languages 8-10 years from 
inception to a significant market position, but I think it is 
going faster now for "small applications". Go is already quite 
old though and the trajectory has been quite clear over  the past 
2-3 years. Swift has major adoption at under 2 years. Both are in 
the"small applications" category at the moment.

CoffeeScript, TypeScript, Dart and React also are in the "small 
applications area". Takes off in 1-3 years, and can die even 
faster. I think many of these will go away when EcmaScript7 
becomes available.

Seems to be a different "industry standard" dynamic for smaller 
applications (web services, web apps, mobile apps and so on).
Jan 03 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Ok, my last dump of statistics:

This one clearly shows that people are learning Go (covers 
searches for "golang array" etc), while the interest in Java 
tutorials is falling:

https://www.google.com/trends/explore#q=golang%2C%20%22java%20tutorial%22&date=1%2F2011%2061m&cmpt=q&tz=Etc%2FGMT-1

This one clearly shows a noticable drop for "c++", with peaks at 
march and october, probably because of higher education student 
projects or something similar. But the oscillation seems to have 
the same magnitude, so maybe higher education still teach it at 
the same rate?

https://www.google.com/trends/explore#q=c%2B%2B&date=1%2F2011%2061m&cmpt=q&tz=Etc%2FGMT-1

The following search shows that "d programming language" has 
fallen significantly over the past 5 years, while "dlang" has 
been stable over the past 2 years or so. Not sure why, maybe 
reduced attention from potential new users, but stable interest 
from already invested users. Seems to fit with Github data.

https://www.google.com/trends/explore#q=%22d%20programming%20language%22%2C%20%22d%20language%22%2C%20%22d%20programming%22%2C%20dlang&date=1%2F2009%2085m&cmpt=q&tz=Etc%2FGMT-1

Seems reasonable?
Jan 03 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Sunday, 3 January 2016 at 19:35:28 UTC, Ola Fosheim Grøstad 
wrote:

 This one clearly shows a noticable drop for "c++", with peaks 
 at march and october, probably because of higher education 
 student projects or something similar. But the oscillation


Or is it conferences?
Jan 03 2016