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
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
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
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
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
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
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
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
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
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% 4 C# 4.707% -0.34% 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
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
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
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
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%
 4	C#	4.707%	-0.34%
 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 trending for last month. Let's take entry #20 for each of the top languages (number of stars) as an attempt to not favour languages with a few popular applications: #20 for Java: lfkdsk / JustWeEngine: 463 stars #20 for C:openresty / lua-nginx-module: 253 stars #20 for C++: dmlc / xgboost: 228 stars #20 for C#: FNA-XNA / FNA: 114 stars #20 for Python: levlaz / braindump: 507 stars #20 for PHP: octobercms / october: 172 stars #20 for Visual Basic: arc42 / arc42-template: 0 stars #20 for JavaScript: mbostock / d3: 1039 stars #20 for Ruby: kilimchoi / engineering-blogs: 184 stars Then let's move to Swift, Objective-C, Go, Rust, Nim and D: #20 for Swift: Carthage / Carthage: 335 stars #20 for Objective-C: postmates / PMKVObserver: 256 stars #20 for Go: influxdb / influxdb: 239 stars #20 for Rust: arthurprs / floki: 36 stars #20 for D: Hackerpilot / DCD: 0 stars #20 for Nimrod: micklat / NimBorg: 0 stars 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
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
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
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
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
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
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
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
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
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 numbers were similar at #20 of the monthly trend so I don't think 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
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
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 numbers were similar at #20 of the monthly trend so I don't 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 several more miscategorized like that, look at #22 in the above 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 javascript in 2015 than any one of Java, C, C#, or C++? I doubt 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
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 
 several more miscategorized like that, look at #22 in the above 
 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 
 javascript in 2015 than any one of Java, C, C#, or C++?  I 
 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
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 
 several more miscategorized like that, look at #22 in the 
 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
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
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
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
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
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 like D, AoT-compiled Java/C#, or maybe eventually 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. 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
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", like Java and C# to remain attractive to businesses that want low 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 
 language like D, AoT-compiled Java/C#, or maybe eventually 
 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
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 
 down", like Java and C# to remain attractive to businesses that 
 want low in-house training.
Swift is dumbed down? I'm surprised you started off by saying that 80%/GC is the big market, but now believe D should be "advanced."
 Swift3 probably will try to get closer to C though. Apple seems 
 to be focused on making C less frequently needed.
So they too will try to straddle both horses!
 Straddling both those horses appears to be the plan, taking 
 D's strength in 80%/GC and crossing over into low-level engine 
 dev with  nogc and C++ integration.  Rather than splitting the 
 domains as you say Apple wants to, by complementing Swift with 
 C, I think the plan with D is to offer one language that does 
 both, ie a general-purpose low- to mid-level language.
Well... not sure how that works out. High risk! Hardware is changing too. Runtimes/semantics can easily become obsolete (inefficient) on new platforms. A reason to keep standard libraries light. Keeping things simple is good... Better to have 2 simple languages than 1 big. Then you can replace 1 component when the environment changes.
Traditionally, it's been C and C++. I could see D providing a lighter version that went after C, especially in embedded, while the current version competes with C++.
 The situation for Apple is a bit different since they control 
 both hardware and software. Meaning, they can build in their 
 own Swift2Metal compiler if they want to...

 I think Swift could go after that market, but they too will 
 probably have to add C++ integration to do it.
C++ is not big on the official iOS and OS-X frameworks. You essentially have Objective-C and C as the legacy platform and Swift and Metal with Objective-C compatible runtime as the modern platform. Objective-C++ is really only for binding to portable code from other platforms.
We're talking cross-platform here, Swift isn't even in the game till they get on other platforms than OSX/iOS.
 It's not a significant enough source of revenue for them, I 
 doubt they care.
$100 per developer per platform + 30% is a pretty hefty charge. I don't trust the current Apple CEO... Steve Jobs was more "hacker" oriented IMO.
Yeah, but do they break 5% of yearly revenue on that? Probably not, it's some small portion of the little purple chunk showing Services revenue in this chart: http://www.asymco.com/2015/08/26/much-bigger-than-hollywood/ That's why I don't think they care. They just do it because they're disciplined about extracting money where they can. They're not trying to maximize it by killing competition, especially because such anti-competitive moves could spook devs and maybe even some users, which might affect the all-important iPhone cash cow.
 Profit margins on hardware will drop as Android hardware become 
 commoditized. This is a typical trend. Margins go down over 
 time if you avoid monopolies and requirements stay the same. 
 And battery life and physical size limits requirements.
This is happening to some extent to Android OEMs but not to the iPhone, which has maintained its margins while selling millions more every year. Apple does it by continually staying at the top of the performance heap, with their in-house designed custom ARM cores blowing away the benchmarks year after year and paying top dollar for the best components, like cameras, flash storage, and fingerprint sensors.
 So, iPhone is a gold-mine today, but more like a copper-mine  
 in 10 years? I guess flexible and unbreakable plastic phones 
 could be the next step, foldable LCDs are here already. 
 Popularity of fashion items are kinda bell-shaped (or 
 something). 10 years ago BIG SUVs were fashionable. Right now 
 Teslas are fashionable here in Norway... Just for show off, I 
 think. :-/ Kinda like JavaScript frameworks!
People have been predicting Apple's downfall for years, while they grew to become the largest company on earth! Of course, they have to level off and fall eventually, but who knows when?
 The v8 compiler has certainly helped javascript on the server, 
 but like I said, practically every language will be able to 
 run the same code with WebAsm, and they'll have a _lot_ more 
 code already running on the server.
Well. I think we will see legacy applications wrapped up in suitable containers and stuck into the cloud in maintenance mode while new projects go new routes. Fast interconnects (local networking) and fast compute nodes makes it possible to continue development in a new language and integrate software across machines... I think.
Maybe, but I don't see them willingly choosing javascript. :)
 You can email him and take those issues up with him.  I was 
 only linking it for the conclusion, that the current 
 client-side dev experience sucks and is likely to be disrupted.
My experience is that the client side dev experience is improving greatly year by year! Both in general and as far as cross browser compatibility is concerned. Safari is one step behind, but... IE is moving. Microsoft is actually cooperating with Google. I think they are better than Chrome in some aspects now. Mozilla developer network and caniuse.com is your friend.
Glad you like it, but many devs disagree with you.
 The web stack is so tough to deal with, especially because all 
 the different browser incompatibilities kill the 
 cross-platform story, that it's fading fast on mobile.
[...]
 A big part of that is the popular and mostly dumb reasoning 
 that a web app's UI is not really "native" to mobile, but 
 whether dumb or not, that widespread perception hurts webapps 
 on mobile.
Right, it is problematic on mobile not because of cross browser issues, but because the vendors have deliberately created completely different look and feel on their platforms. And that sucks for most apps, because they are dominated by UI code...
I think most users are used to the web being different or don't care about the "look and feel."
 But it won't be unseated. Modern HTML5 has critical mass. 
 WebGL might be unseated.
Heh, I don't think either has gotten very far yet.
WebGL support is close to usable. HTML5 is dominant.
So "dominant" that Facebook ditched their HTML5 mobile app for native and Snapchat doesn't even have a webapp! HTML5 may now be fairly ubiquitously _implemented_ in current browsers, but you greatly overestimate how many devs are using it or want to.
 Well, at least we agree that it's massive. :) iOS will always 
 have the Apple tax, but as long as it's the leading mobile app 
 platform by revenue, which I hear it still is by a significant 
 margin, that's a tax most devs are willing to pay.
The tax is not the problem. The problem is that they dictate deprecation and removal. So when you update to the next version of iOS you might have to rewrite more of your app than you care for. Like... next year maybe they will ban using assembly code in your app.
I wasn't talking about Apple's revenue cut as a tax, I was referring to their policies that you referred to earlier as their tax.
 That's not tax, it is a monopolistic dictator state.
Many people enjoy living in Dubai or Saudi Arabia. ;) I could never live in those places, but they seem to stomach it.
 Why would you bother with ES7 if you could just code it all in 
 most any language of your choice and compile to WebAsm?
Convenience. If I don't need speed it is much much more convenient to be able to use the REPL and debugger on a live application/web app. Scenario: customer calls in and reports a problem with the app. ES7 solution: I look at the app in the debugger and do some "poking" on live data to figure out what the problem is. Then I can quickly call back and say how fast I can fix the issue. AoT solution: I have to fire up a local environment with a debugger and then try to replicate the problem that might not show up for some weird border line reason.
I don't get it: you have access to a debugger _in the customer's browser_ with ES7?
 Or the web stack itself going away, which is very likely.
I'm not sure if you are serious or joking... I mean, the web stack is not going away in my life time. I am barely been able to get rid of IE9!
Dead serious, let me quote you Bray's conclusion again: "On the client, I just totally don’t know. Historical periods featuring rococo engineering outbursts of colorful duplicative complexity usually end up converging on something simpler that hits the right 80/20 points. But if that’s what’s coming, it’s not coming from any direction I’m looking, so color me baffled. Maybe we’re stuck with clients-in-triplicate for the long haul." Every time this happens over the previous decades, something simpler comes along and 80/20s the past bloated tech. The web is _long_ overdue for this. They're finally trying to clean it up a bit, with the recent HTTP/2 and WebAsm moves, but it isn't enough.
 Critical mass, installed base and so on will keep the web stack 
 alive for decades!
Sure, COBOL is still around on some mainframe somewhere too, but almost nobody knows it exists! :D
Jan 06
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 Java, C#, Go, Swift and a slew of others. Without tooling you 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
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 have Java, C#, Go, Swift and a slew of others. Without tooling you don't stand a chance in that market.
D aimed for the niche right below that, with higher efficiency, that Swift is now also going after. It turns out that efficiency matters, which is why Java and C# never made much headway in application programming, certainly not outside their enterprise niches, ie consumers don't use Java/C# apps, and are now both AoT-compiled on mobile.
 And really, if you want to compete with C, you can't really be 
 in that market. Do it well, or not at all.
C is so old and outdated that you could wrap up both. It may be harder, but it can be done. C++ certainly took some share from C over the years, D could do even better with a lighter runtime. D hasn't really focused on that yet, but I think Walter wants to one day.
 Swift3 probably will try to get closer to C though. Apple 
 seems to be focused on making C less frequently needed.
So they too will try to straddle both horses!
No, they aim for ABI stability and portability. No concurrency features. https://github.com/apple/swift-evolution
Not sure how ABI stability/portability hurts that, but is Swift going after C or not? You seem to say they are, then they aren't. Going after lower-level code that would use C is the other horse you mentioned, so if they are, they're trying to straddle both.
 Traditionally, it's been C and C++.  I could see D providing a 
 lighter version that went after C, especially in embedded, 
 while the current version competes with C++.
With at different team?
Walter is the team. :) He's done embedded work before, he's aware of the challenges.
 We're talking cross-platform here, Swift isn't even in the 
 game till they get on other platforms than OSX/iOS.
But who are using D for cross platform development today? Isn't Linux the primary platform in real world use (i.e. deployment)?
I don't know, and probably. But D runs well on all the major desktop/server platforms and soon the two major mobile platforms, not to mention upcoming platforms like wearables and smart TVs, which D devs are currently testing. Get back to me when Swift can say that.
 more every year.  Apple does it by continually staying at the 
 top of the performance heap, with their in-house designed 
 custom ARM cores blowing away the benchmarks year after year
I don't really think consumers know what they buy, but people tend to want the same UI experience... so switching over takes time.
The latest iPhone always blows away any Android phone on measures of UI lag. Users don't know what makes a phone fast- the components mentioned before, along with not using Java and its GC-caused lag for your apps- but they can see when it is.
 Maybe, but I don't see them willingly choosing javascript. :)
They'll be forced to. Managers will choose whatever readymades carry name recognition... ;^) Java, .NET, node.js, Angular...
And with javascript losing its browser monopoly, it will slide down that list. :)
 I think most users are used to the web being different or 
 don't care about the "look and feel."
Most users probably don't care, but people who spec mobile apps put it into the requirements.
Which is why I said it's dumb, because most users don't actually care about that. One of the biggest herd behaviours I've seen in recent years is the crazy drive to build mobile apps to replace perfectly functional webapps, whose CSS UI could be simply redone for mobile too. Unless you have a compelling reason to be mobile-first, many are just wasting money.
 So "dominant" that Facebook ditched their HTML5 mobile app for 
 native and Snapchat doesn't even have a webapp!  HTML5 may now 
 be fairly ubiquitously _implemented_ in current browsers, but 
 you greatly overestimate how many devs are using it or want to.
Not sure what you mean, Facebook invest a lot of money into web tech like React. If anything Facebook is heavily pushing WebApps by funding the frameworks that enables it.
Perhaps you haven't heard, but the original Facebook mobile app was simply their HTML5 site bundled on mobile, then they switched to native years ago for efficiency: https://facebook.com/notes/facebook-engineering/under-the-hood-rebuilding-facebook-for-ios/10151036091753920 They may still use and release legacy HTML5 frameworks, ;) as that's where they started, but almost half of their users now only use the native mobile apps, and that mobile-only user share keeps growing: http://venturebeat.com/2015/07/29/nearly-half-of-facebooks-users-only-access-the-service-on-mobile/ Others have followed them in ditching HTML5.
 I don't get it: you have access to a debugger _in the 
 customer's browser_ with ES7?
All browsers have debuggers built in...
I wouldn't know as Chrome is all I use in recent years, and I thought that was the only browser that always came with one. In any case, your point is still unclear: why would WebAsm not have the same browser support?
 Every time this happens over the previous decades, something 
 simpler comes along and 80/20s the past bloated tech.  The web 
 is _long_ overdue for this.  They're finally trying to clean 
 it up a bit, with the recent HTTP/2 and WebAsm moves, but it 
 isn't enough.
I don't see HTTP/2 and WebAsm as a big thing. It is just another step to make web a more solid cross platform deployment platform.
They cannot fix the real problem, the baroque architectural pasta of HTMl/CSS/DOM, but those moves make those two components much more efficient, which certainly helps.
 I don't spend much time on compatibility tweaks anymore. I 
 don't mind spending 1% on cross platform. That's actually 
 pretty impressive. Try to get there with native apps on 5 
 platforms: Linux, OS-X, Windows, Android, iOS... Impossible.
It can be done, but it's not actually what I'm suggesting. I think there will be some new cross-platform approach that takes over the web's spot. I've suggested a re-architecting of the web approach before, to focus on efficiency and extreme simplicity of graphical layout in the client: http://forum.dlang.org/post/dqddjhccpmxhgcssqtol forum.dlang.org I used to want to work on that approach, but I now actually think that entire client-server model is outdated. I suspect what's coming is more of a p2p approach, where smartphones simply pass data to each other, then construct UIs customized for the user out of the data they want to see. That's my guess, but whatever it is, it will kill the web.
Jan 06
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 
 enterprise niches, ie consumers don't use Java/C# apps, and are 
 now both AoT-compiled on mobile.
Java demands lots of memory, but Java is suitable for consumer applications on new machines. The problem with consumer devices is that the majority of users are on the low end.
 from C over the years, D could do even better with a lighter 
 runtime.  D hasn't really focused on that yet, but I think 
 Walter wants to one day.
That would be a nice change of direction. I think the core language shouldn't require a runtime at all. But... probably too late for D.
 Not sure how ABI stability/portability hurts that, but is Swift 
 going after C or not?  You seem to say they are, then they 
 aren't.
No, they are not going after C, but making it less necessary to drop down to C from Swift. If they have a fixed ABI then you can FFI Swift functions?
 Perhaps you haven't heard, but the original Facebook mobile app 
 was simply their HTML5 site bundled on mobile, then they 
 switched to native years ago for efficiency:
I don't know much about it, but I've heard that Facebook have serious internal software development process problems resulting in bloat across the board. Just a rumour. I thought that implied to their mobile apps too? (I don't use it.)
 They may still use and release legacy HTML5 frameworks, ;) as 
 that's where they started, but almost half of their users now 
 only use the native mobile apps, and that mobile-only user 
 share keeps growing:
Ok, well, Facebook and other juggernauts can afford to develop their apps on all kinds of platforms (from scratch even).
 In any case, your point is still unclear: why would WebAsm not 
 have the same browser support?
We'll see, but less motivation (demand) is my guess. Webasm is unreadable, runs as machine language and you don't have type info?
 They cannot fix the real problem, the baroque architectural 
 pasta of HTMl/CSS/DOM, but those moves make those two 
 components much more efficient, which certainly helps.
I don't really think the DOM is baroque. It is like a scene graph. The only really bad thing about it is that you set css values as strings. It could use a redesign, but it is more flexible than regular GUI libraries (which are rather ugly and tedious).
 over the web's spot.  I've suggested a re-architecting of the 
 web approach before, to focus on efficiency and extreme 
 simplicity of graphical layout in the client:
There are 3 approaches for "re-architecting" gui-style components in the web DOM: 1. The approach taken by React which is to have a virtual DOM (a pure javascript DOM). 2. The approach taken by Angular which is to have special HTML-style attributes for templating functionality (like for-loops) and use observers (track change events). 3. The approach taken by Web Components using shadow DOM (invisible sub-DOM under custom elements/nodes).
 think that entire client-server model is outdated.  I suspect 
 what's coming is more of a p2p approach, where smartphones 
 simply pass data to each other
Smartphones support p2p? That's new to me. I thought they were deliberately limited to servers.
 then construct UIs customized for the user out of the data they 
 want to see.  That's my guess, but whatever it is, it will kill 
 the web.
No, it will not kill the web. Nothing can kill the web... you want it, but it ain't happenin'. That approach is what modern javascript frameworks is supposed to support! The web is further down that path than GUI libs. Angular2 is basically a client side templating system, and so is web components...
Jan 07
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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