www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - One more question - an untapped audience.

reply "Steve Teale" <steve.teale britseyeview.com> writes:
What can be done to capture the attention of young people in the 
developing world?

Probably the most effective thing would be if it were possible to 
edit, compile, and run D programs on a cheap Android ARM phone.

Is this within the bounds of possibility?

There are millions of unemployed, bored, restless, and ambitious 
young men out there, who have saved their all to buy a cheap 
smartphone.

Any other ideas?

Steve
Feb 10 2014
next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?

 Probably the most effective thing would be if it were possible 
 to edit, compile, and run D programs on a cheap Android ARM 
 phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to buy 
 a cheap smartphone.

 Any other ideas?

 Steve


A D compiler that targets JVM or Dalvik directly is my personal 
dream...
Feb 10 2014
next sibling parent reply "MattCoder" <somekindofmonster email.com.br> writes:
On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 A D compiler that targets JVM or Dalvik directly is my personal 
 dream...


Mine too!
Feb 10 2014
parent "Chris" <wendlec tcd.ie> writes:
On Monday, 10 February 2014 at 19:40:46 UTC, MattCoder wrote:

 On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 A D compiler that targets JVM or Dalvik directly is my 
 personal dream...


 Mine too!


Same here. Mobile platforms are immensely important. If you can't 
cater for them, people will soon ask questions (users don't 
understand why xyz is not available for mobiles, and they don't 
need to). So the lack of support for ARM and the like is really a 
big big drawback.
One of the applications we are developing will need a web based 
solution for mobile phones, tablets etc. It would be nicer, and 
users will finally want an app they can install locally without 
having to refer to the "cloud" (mind you, the network is not 
always available).
I think the importance of this cannot be underestimated, and 
coming back to the point, this will put young people off, because 
a lot of young people are into (mobile) app development.
Feb 10 2014
prev sibling next sibling parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?

 Probably the most effective thing would be if it were possible 
 to edit, compile, and run D programs on a cheap Android ARM 
 phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to buy 
 a cheap smartphone.

 Any other ideas?

 Steve


 A D compiler that targets JVM or Dalvik directly is my personal 
 dream...


That's kind of what I was going for when I was working on my
transcompiler a while back. Something that goes directly from d
source to Dalcik would be so amazing though...
Feb 11 2014
parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Wednesday, 12 February 2014 at 04:42:47 UTC, Jeremy DeHaan
wrote:

 On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?

 Probably the most effective thing would be if it were 
 possible to edit, compile, and run D programs on a cheap 
 Android ARM phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to 
 buy a cheap smartphone.

 Any other ideas?

 Steve


 A D compiler that targets JVM or Dalvik directly is my 
 personal dream...


 That's kind of what I was going for when I was working on my
 transcompiler a while back. Something that goes directly from d
 source to Dalcik would be so amazing though...


err..Dalvik
Feb 11 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 12.02.2014 05:43, schrieb Jeremy DeHaan:

 On Wednesday, 12 February 2014 at 04:42:47 UTC, Jeremy DeHaan
 wrote:

 On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in the
 developing world?

 Probably the most effective thing would be if it were possible to
 edit, compile, and run D programs on a cheap Android ARM phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and ambitious
 young men out there, who have saved their all to buy a cheap
 smartphone.

 Any other ideas?

 Steve


 A D compiler that targets JVM or Dalvik directly is my personal dream...


 That's kind of what I was going for when I was working on my
 transcompiler a while back. Something that goes directly from d
 source to Dalcik would be so amazing though...


 err..Dalvik


Dalvik was replaced by ART for new Android versions
Feb 12 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 2/12/2014 11:26 AM, Paulo Pinto wrote:

 Dalvik was replaced by ART for new Android versions


I thought ART was still just included secondary thing that developers 
*can* use, but mainly just as a developer preview, and that Dalvik was 
still the default.
Feb 13 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 February 2014 at 14:03:43 UTC, Nick Sabalausky 
wrote:

 On 2/12/2014 11:26 AM, Paulo Pinto wrote:

 Dalvik was replaced by ART for new Android versions


 I thought ART was still just included secondary thing that 
 developers *can* use, but mainly just as a developer preview, 
 and that Dalvik was still the default.


In the commercial versions you are correct.

However, Dalvik has been replaced already for whatever might be 
the future Android release.

https://android.googlesource.com/platform%2Fbuild/+/08d410f53249c18d752f56a881ed2335403080d4

--
Paulo
Feb 13 2014
prev sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:


clip

 Steve


 A D compiler that targets JVM or Dalvik directly is my personal 
 dream...


I have no idea how hard this would be, but since D has a 
front-end to the GNU compiler collection GDC, and the GNU 
compiler collection has a backend (presumably) that generated 
Java byte-code, would it be possible to use the GDC front end and 
GCJ backend to do D -> JVM?
Feb 19 2014
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 19 February 2014 17:16, Craig Dillabaugh <cdillaba cg.scs.carleton.ca> wrote:

 On Monday, 10 February 2014 at 18:14:26 UTC, Dejan Lekic wrote:

 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:


 clip


 Steve



 A D compiler that targets JVM or Dalvik directly is my personal dream...



 I have no idea how hard this would be, but since D has a front-end to the
 GNU compiler collection GDC, and the GNU compiler collection has a backend
 (presumably) that generated Java byte-code, would it be possible to use the
 GDC front end and GCJ backend to do D -> JVM?


Ah, no. That is not the case.  GCJ is a native Java compiler.  No
bytecode going on here...

There is JNI support in g++ -> gcj.  It's just a question of whether
or not we want to add this to gdc (would involve changes to the
dfrontend).
Feb 19 2014
prev sibling next sibling parent reply "Tofu Ninja" <emmons0 purdue.edu> writes:
On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?

 Probably the most effective thing would be if it were possible 
 to edit, compile, and run D programs on a cheap Android ARM 
 phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to buy 
 a cheap smartphone.

 Any other ideas?

 Steve


I am only 20 and am still in university so I feel like I can 
answer this with at least my own experiences. Personally I think 
D would capture the attention of more young people if it was 
simply easier to use. The first "real" language I really got into 

it was so flipin easy to learn and get started. All I had to do 
to set it up was download Visual Studio and I was done... period 
... The documentation was fantastic and everything was named in 
very intuitive ways. Most of the time when I was learning I would 
just ctrl+space and start scrolling through the auto-complete 
reading the documentation of all the functions right there in 
visual studio. It was soooooo easy. In my opinion the biggest 
thing holding D back by a long shot is the tooling and 
documentation... it is simply terrible. But thats just my opinion 
so I don't want anyone taking offense.

Also something that would help get younger people into D was if 

in my opinion they are both so popular because their std lib is 
so large. Younger people don't like to have to deal with non 
standard libraries as they just make it so much more difficult to 
do things especially as they are still trying to learn.

The lack of a real GUI library is also a hindrance. Young people 
like to see results on the screen other than just text. That is 
why web and mobile development is so popular with young people.

tldr; Tools suck, documentation sucks, std lib is small and no 
std GUI lib...
Feb 10 2014
next sibling parent "Francesco Cattoglio" <francesco.cattoglio gmail.com> writes:
On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote:

 tldr; Tools suck, documentation sucks, std lib is small and no 
 std GUI lib...


I do agree to a certain degree.
std lib is not really that small, but sure it is never enough.
Lack of std GUI lib, I honestly I'm perfectly fine with it.
Tools on the other hand, do suck. The only way I could debug my 
prototype code involving std.concurrency and some OpenGL code was 
learning to use GDB from the command line, because GUI debuggers 
would fail horribly. Editors are so-so, compiler-as-a-library 
needs some extra time before work on it starts.

Documentation is just not good enough. Perhaps I can start doing 
some pulls for the docs, since I'm still a n00b of the language 
but at least not a complete beginner anymore.

Thanks God we have at least DUB.
BTW: we really need to get a BIG link to dub package registry in 
the home page, or at least on the side bar.
Feb 10 2014
prev sibling next sibling parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 10 Feb 2014 11:03:19 -0800, Tofu Ninja <emmons0 purdue.edu> wrote:


 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in the  
 developing world?

 Probably the most effective thing would be if it were possible to edit,  
 compile, and run D programs on a cheap Android ARM phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and ambitious young  
 men out there, who have saved their all to buy a cheap smartphone.

 Any other ideas?

 Steve


 I am only 20 and am still in university so I feel like I can answer this  
 with at least my own experiences. Personally I think D would capture the  
 attention of more young people if it was simply easier to use. The first  

 think the main reason is that it was so flipin easy to learn and get  
 started. All I had to do to set it up was download Visual Studio and I  
 was done... period ... The documentation was fantastic and everything  
 was named in very intuitive ways. Most of the time when I was learning I  
 would just ctrl+space and start scrolling through the auto-complete  
 reading the documentation of all the functions right there in visual  
 studio. It was soooooo easy. In my opinion the biggest thing holding D  
 back by a long shot is the tooling and documentation... it is simply  
 terrible. But thats just my opinion so I don't want anyone taking  
 offense.

 Also something that would help get younger people into D was if the std  

 they are both so popular because their std lib is so large. Younger  
 people don't like to have to deal with non standard libraries as they  
 just make it so much more difficult to do things especially as they are  
 still trying to learn.

 The lack of a real GUI library is also a hindrance. Young people like to  
 see results on the screen other than just text. That is why web and  
 mobile development is so popular with young people.

 tldr; Tools suck, documentation sucks, std lib is small and no std GUI  
 lib...


I wholeheartedly agree with this sentiment, although I am a little older  

want to get up everyday and write code. It is fantastically easy to learn,  
you can write code that does useful things very quickly. Download the IDE,  
install, write 50 lines and you've got a tool that does useful work, even  
if trivial.

And the .NET Framework or Java Frameworks. I know that the linux-heads  
scoff at the idea of shipping a large standard library, "Download the  
library that works best for you" they cry! Well, that answer is  
unacceptable for newbies, mostly because they don't actually know which  
library will work for them, or with D, or on the operating system they are  
using. Big standard libraries provide a new user with all the tools that  
they need to write many programs. This isn't to say that the standard  
library needs to include everything one might need to build any app every.  
I still use third-party libraries. I just don't use them to fill in common  
functionality. For example, I have a library that provides special types  
of inputboxes, but WPF (a big part of the .NET Framework) provides a  
generic inputbox. Then we use EntityFramework, .NET provides the generic  
interface that is used by EntityFramework, LINQ, but EF itself extends the  
framework in specialized ways. The framework should absolutely include as  
many general tools as possible.

Not having an IDE is more tangential, but no less important. Here we have  
two integrations with popular IDE's, Visual Studio and Mono. However,  
these integrations suffer from the lack of tooling for D. DMD can't be  
used as libary, so these integrations have had to produce their own  
parsing engines and they are always behind DMD itself so they never parse  
the current DMD language quite correctly. This means that you can't turn  

used to. D's integration with IDE's is similar to the situation with IDE  
integration for C++. Yes D is easier to parse than C++, but since we can't  
use the canonical parser, we don't have any parsers that match D in it's  
current form so the AST's are almost always broken or plain incorrect.

Building a new IDE won't solve this problem. Here we need to focus on  
building better tools for D, turning DMD itself into a library or  
Compiler-as-a-Service in the current lingo, since libraries are now  
"services". D needs to make great strides in tooling to be relevant, we  
need first-class debugging, and they need to support more than the  
terminal. We need D as library, we need better IDE integrations. We need a  
broader standard library. We need more bindings for existing libraries. We  
need more new libraries (like the Aurora library I am working on).

But most importantly we need to stop whining about the problems and start  
doing something about them. There are plenty of projects in these areas  
that are being run by a single person that could use any help. For  
example, I know that Rainer Schutze of VisualD fame is quite open to pull  
requests. If you use a library from a language other than D and have a D  
binding for it, get it in Deimos.

Let's all do something that moves the state of D forward.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 10 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 10 February 2014 at 20:32:03 UTC, Adam Wilson wrote:

 I wholeheartedly agree with this sentiment, although I am a 
 little older and got my start in a combination of VB6 and C++98.


Same for me when I first started learning to program. I did a VB6 
course in highschool, followed by a Java course, as well as 
teaching myself C++ on my own to hack on my Nintendo DS. Looking 
back, good tutorials were the biggest help. I didn't know 
anything about anything, and I don't know if I would ever have 
been able to figure out C++ without sites like cplusplus.com. 
Bartosz Milewski's C++ in Action book was a huge help too. I'm 
glad he decided to publish it for free on the web.


 And the .NET Framework or Java Frameworks. I know that the 
 linux-heads scoff at the idea of shipping a large standard 
 library, "Download the library that works best for you" they 
 cry! Well, that answer is unacceptable for newbies, mostly 
 because they don't actually know which library will work for 
 them, or with D, or on the operating system they are using. Big 
 standard libraries provide a new user with all the tools that 
 they need to write many programs. This isn't to say that the 
 standard library needs to include everything one might need to 
 build any app every. I still use third-party libraries. I just 
 don't use them to fill in common functionality. For example, I 
 have a library that provides special types of inputboxes, but 
 WPF (a big part of the .NET Framework) provides a generic 
 inputbox. Then we use EntityFramework, .NET provides the 
 generic interface that is used by EntityFramework, LINQ, but EF 
 itself extends the framework in specialized ways. The framework 
 should absolutely include as many general tools as possible.


I absolutely agree with that. Phobos should strive to be as 
"batteries included" as possible while minimizing (ideally 
eliminating) third party dependencies.


 Building a new IDE won't solve this problem. Here we need to 
 focus on building better tools for D, turning DMD itself into a 
 library or Compiler-as-a-Service in the current lingo, since 
 libraries are now "services". D needs to make great strides in 
 tooling to be relevant, we need first-class debugging, and they 
 need to support more than the terminal. We need D as library, 
 we need better IDE integrations. We need a broader standard 
 library. We need more bindings for existing libraries. We need 
 more new libraries (like the Aurora library I am working on).

 But most importantly we need to stop whining about the problems 
 and start doing something about them. There are plenty of 
 projects in these areas that are being run by a single person 
 that could use any help. For example, I know that Rainer 
 Schutze of VisualD fame is quite open to pull requests. If you 
 use a library from a language other than D and have a D binding 
 for it, get it in Deimos.



at work, and Visual Studio makes refactoring and code generation 
near-effortless. I agree with Walter that we definitely shouldn't 
need an IDE to use D, but there is no competition when it comes 
to the productivity that a good IDE enables.
Feb 10 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Adam Wilson"  wrote in message news:op.xa21zpux707hn8 invictus.hra.local...
Building a new IDE won't solve this problem. Here we need to focus on

 building better tools for D, turning DMD itself into a library or 
 Compiler-as-a-Service in the current lingo, since libraries are now 
 "services". D needs to make great strides in tooling to be relevant, we 
 need first-class debugging, and they need to support more than the 
 terminal. We need D as library, we need better IDE integrations.


I don't know if you've been following recent activity on the compiler, but 
we are finally making progress in this direction.  One of the things on my 
todo list (after the switch to D is complete) is to start making the 
lexer/parser usable outside the compiler.


 We need a  broader standard library. We need more bindings for
 existing libraries. We need more new libraries (like the Aurora library
 I am working on).


I'm starting to think phobos should not exist in its current form, and it 
should just be a set of 'officially blessed' dub packages that meet certain 
usefulness, API, performance and stability criteria.
Feb 10 2014
parent reply "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 10 Feb 2014 19:58:04 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:


 "Adam Wilson"  wrote in message  
 news:op.xa21zpux707hn8 invictus.hra.local...
 Building a new IDE won't solve this problem. Here we need to focus on

 building better tools for D, turning DMD itself into a library or  
 Compiler-as-a-Service in the current lingo, since libraries are now  
 "services". D needs to make great strides in tooling to be relevant, we  
 need first-class debugging, and they need to support more than the  
 terminal. We need D as library, we need better IDE integrations.


 I don't know if you've been following recent activity on the compiler,  
 but we are finally making progress in this direction.  One of the things  
 on my todo list (after the switch to D is complete) is to start making  
 the lexer/parser usable outside the compiler.


To be honest I haven't been following it closely as I've been buried in  
work projects and Aurora. It would be awesome if that came sometime later  
this year. We badly need those capabilities, and I imagine that hacking on  
the compiler itself will get much easier when it's converted to D.


 We need a  broader standard library. We need more bindings for
 existing libraries. We need more new libraries (like the Aurora library
 I am working on).


 I'm starting to think phobos should not exist in its current form, and  
 it should just be a set of 'officially blessed' dub packages that meet  
 certain usefulness, API, performance and stability criteria.


I don't know if I can express how strongly I disagree with that sentiment.  
I don't use dub, I don't really want to use dub, and I am virtually  
certain that the whole concept of using dub is a going to make newbie  
acceptance much more difficult. D is supposed to make life easier, not  
harder.

DUB is great if you're an experienced linux dev. But for somebody just  
getting started, especially those coming from other languages with  
standard libraries (aka, all of them) the idea of having to use a package  
manager to do anything is completely backwards. We need to be reducing our  
project setup times, not increasing them by making people download the  
same 10 packages for every project they start. People want to download a  
language and start writing code. Not faff about with getting the right  
package configuration just to write some output to the console.

It is also very helpful to have a standardized set of capabilities that I  
can rely on existing at a minimum in all configurations. This is critical  
in a code-generation context when you are building code for an unknown  
environment where the only certain capabilities you have are the stdlib  
and any libraries you provide. And yes, I have a code generation project  
planned for D later this year that is very important to my company.  
Killing the standard library would effectively cancel that project and end  
my involvement in D, as we can't convert to D without this code-gen  
project. I make this point not to try to hold D hostage to myself, D  
should never be held hostage by the needs of any one entity, but that  
having a stdlib available by default is extremely useful in certain cases  
and by removing it you make those cases exponentially more difficult if  
not impossible to achieve.

If anything Phobos needs to get bigger and increase the coverage standard  
available functionality. We can talk about improvements to reduce module  
dependencies, and improve layout, design, and code quality, but none of  
those are sufficient reasons in my mind to through out the idea of a  
stdlib altogether.

The only way I could accept that is if D integrated DUB directly into it's  
source code and downloaded and installed packages silently in the  
background when one of the imports matches a DUB package import. But I  
don't see that happening anytime soon.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 10 2014
next sibling parent reply "Mike Parker" <aldacron gmail.com> writes:
On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:


 I don't know if I can express how strongly I disagree with that 
 sentiment. I don't use dub, I don't really want to use dub, and 
 I am virtually certain that the whole concept of using dub is a 
 going to make newbie acceptance much more difficult. D is 
 supposed to make life easier, not harder.

 DUB is great if you're an experienced linux dev. But for 
 somebody just getting started, especially those coming from 
 other languages with standard libraries (aka, all of them) the 
 idea of having to use a package manager to do anything is 
 completely backwards. We need to be reducing our project setup 
 times, not increasing them by making people download the same 
 10 packages for every project they start. People want to 
 download a language and start writing code. Not faff about with 
 getting the right package configuration just to write some 
 output to the console.


You're greatly underestimating just how easy dub makes developing 
with D. I'm by no means a Linux dev. My life has been lived on 
Windows. But I use dub exclusively now and would love to see it 
packaged with DMD and become the de facto way to get D libraries. 
If Phobos were to be broken into a set of dub packages, even 
better.

Setting up a package.json for a new project is extremely easy. 
Once it's done you can copy it around for future projects with 
minor changes. Compilation, in its simplest form, then becomes:

dub build

And all the libraries you need are automatically pulled down. 
Then they are available for any other projects that need them. It 
doesn't get any easier than that.

Plus, once all of the D IDEs get support for it worked out, you 
then have one universal project configuration tool. No more need 
to provide build scripts, make files, Visual Studio solutions, 
MonoD projects, or whatever else. No matter your choice of text 
editor/IDE, one configuration file rules them all.

Ultimately, this would make it much, much easier to get started 
with D. So far, my experience in using dub with Derelict has 
suggested this to be true. I still get people asking for help 
with using Derelict 3 without dub, often because they don't know 
how to configure the import path or the linker in their IDE, or 
don't understand what it even means (and, apparently, have failed 
to read any documentation on the subject). I've gotten *zero* 
compile/link issues about building with dub. Maybe that just 
means the newbies aren't using dub, or that they aren't reporting 
their problems to me, but I suspect it's because dub is easy.
Feb 10 2014
next sibling parent "Adam Wilson" <flyboynw gmail.com> writes:
On Mon, 10 Feb 2014 21:03:28 -0800, Mike Parker <aldacron gmail.com> wrote:


 On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:


 I don't know if I can express how strongly I disagree with that  
 sentiment. I don't use dub, I don't really want to use dub, and I am  
 virtually certain that the whole concept of using dub is a going to  
 make newbie acceptance much more difficult. D is supposed to make life  
 easier, not harder.

 DUB is great if you're an experienced linux dev. But for somebody just  
 getting started, especially those coming from other languages with  
 standard libraries (aka, all of them) the idea of having to use a  
 package manager to do anything is completely backwards. We need to be  
 reducing our project setup times, not increasing them by making people  
 download the same 10 packages for every project they start. People want  
 to download a language and start writing code. Not faff about with  
 getting the right package configuration just to write some output to  
 the console.


 You're greatly underestimating just how easy dub makes developing with  
 D. I'm by no means a Linux dev. My life has been lived on Windows. But I  
 use dub exclusively now and would love to see it packaged with DMD and  
 become the de facto way to get D libraries. If Phobos were to be broken  
 into a set of dub packages, even better.

 Setting up a package.json for a new project is extremely easy. Once it's  
 done you can copy it around for future projects with minor changes.  
 Compilation, in its simplest form, then becomes:

 dub build

 And all the libraries you need are automatically pulled down. Then they  
 are available for any other projects that need them. It doesn't get any  
 easier than that.

 Plus, once all of the D IDEs get support for it worked out, you then  
 have one universal project configuration tool. No more need to provide  
 build scripts, make files, Visual Studio solutions, MonoD projects, or  
 whatever else. No matter your choice of text editor/IDE, one  
 configuration file rules them all.

 Ultimately, this would make it much, much easier to get started with D.  
 So far, my experience in using dub with Derelict has suggested this to  
 be true. I still get people asking for help with using Derelict 3  
 without dub, often because they don't know how to configure the import  
 path or the linker in their IDE, or don't understand what it even means  
 (and, apparently, have failed to read any documentation on the subject).  
 I've gotten *zero* compile/link issues about building with dub. Maybe  
 that just means the newbies aren't using dub, or that they aren't  
 reporting their problems to me, but I suspect it's because dub is easy.


Well, I can be wrong. I fully admit to not having any experience with it.  
But that doesn't answer my other problem. :-)

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator
Feb 10 2014
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Tuesday, 11 February 2014 at 05:03:29 UTC, Mike Parker wrote:

 You're greatly underestimating just how easy dub makes 
 developing with D.


I have to say that dub is a great tool. I remember the times when 
I had to copy files to /usr/bin/ etc. and would still wonder why 
the compiler complained. I started using dub a few months ago 
(when I started a vibe.d project) and it helps me a lot. I moved 
the project to a new machine, just ran $ dub and it compiled and 
ran, out of the box.

Back to the original point, i.e. what's important for newbies 
(some of it has already been said):

1. ease of use:
     download, install, type away.
2. tutorials:
     a. show how things work in D, the most common cases first 
(e.g. string handling, (assoc) arrays, saving to file, useful 
real world examples)
     b. show how things should be done correctly (there's nothing 
worse than having to figure out yourself and then refactor your 
code, because nobody told you how to do it correctly or in an 
optimized way).
     c. the newbie should be able to get going and be productive 
without an in depth understanding of the philosophy behind every 
language feature. That comes later, more or less automatically.
3. documentation:
     More examples. The Cocoa API reference is very good in this 
respect. It shows trivial things like opening a file dialog. 
Trivial but it's good to have something you can just copy for 
starters, without having to figure out what else to import and 
all that kind of stuff that only holds you up.

I cannot say anything about IDE support, because I haven't used 
D+IDE yet. But some analyzing tools would be nice, e.g. "variable 
declaration is shadowing global variable", "unused import".

The most important thing for newbies, either new to the language 
or new to programming, is "instant gratification". If it compiles 
and works, people are more likely to be enthusiastic about it. 
Give them useful examples and use cases and they will begin to 
see how useful programming is and start thinking about 
applications, however trivial they may be, they can write 
themselves for their own personal use (a little clock, a 
calculator for VAT ...) In this way they will start to think as 
both developer and user, add features, go ever deeper into 
programming. Creating useful things, that's what it's all about, 
isn't it?
Feb 11 2014
parent reply "Steve Teale" <steve.teale britseyeview.com> writes:
On Tuesday, 11 February 2014 at 11:00:18 UTC, Chris wrote:

 On Tuesday, 11 February 2014 at 05:03:29 UTC, Mike Parker wrote:


 The most important thing for newbies, either new to the 
 language or new to programming, is "instant gratification". If 
 it compiles and works, people are more likely to be 
 enthusiastic about it. Give them useful examples and use cases 
 and they will begin to see how useful programming is and start 
 thinking about applications, however trivial they may be, they 
 can write themselves for their own personal use (a little 
 clock, a calculator for VAT ...) In this way they will start to 
 think as both developer and user, add features, go ever deeper 
 into programming. Creating useful things, that's what it's all 
 about, isn't it?


Thanks for your last paragraph. That's what I was talking about.



 Feb 11 2014



  parent reply "Dicebot" <public dicebot.lv>  writes:


On Tuesday, 11 February 2014 at 17:40:29 UTC, Steve Teale wrote:

 On Tuesday, 11 February 2014 at 11:00:18 UTC, Chris wrote:

 On Tuesday, 11 February 2014 at 05:03:29 UTC, Mike Parker 
 wrote:


 The most important thing for newbies, either new to the 
 language or new to programming, is "instant gratification". If 
 it compiles and works, people are more likely to be 
 enthusiastic about it. Give them useful examples and use cases 
 and they will begin to see how useful programming is and start 
 thinking about applications, however trivial they may be, they 
 can write themselves for their own personal use (a little 
 clock, a calculator for VAT ...) In this way they will start 
 to think as both developer and user, add features, go ever 
 deeper into programming. Creating useful things, that's what 
 it's all about, isn't it?


 Thanks for your last paragraph. That's what I was talking about.


Well this is pretty much why I got confused by initial question - 
it does not have much to do with D itself. It would have fitted 
more some kind of educational psychology newsgroup or something 
like that. Language specifics don't have much impact here, it is 
something that students start to recognise only after they have 
been deep into programming for some time already.



 Feb 11 2014



  parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


Probably noting to do with D, but if D were to get into the 
appropriate place firs , then ...



 Feb 13 2014



prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


 "Adam Wilson"  wrote in message 
 news:op.xa3n27el707hn8 invictus.hra.local...



 To be honest I haven't been following it closely as I've been buried in 
 work projects and Aurora. It would be awesome if that came sometime later 
 this year. We badly need those capabilities, and I imagine that hacking on 
 the compiler itself will get much easier when it's converted to D.


No guarantees.


 I don't know if I can express how strongly I disagree with that sentiment. 
 I don't use dub, I don't really want to use dub, and I am virtually 
 certain that the whole concept of using dub is a going to make newbie 
 acceptance much more difficult. D is supposed to make life easier, not 
 harder.


As Mike Parker said, that doesn't match my experience, and it seems to work 
for python/ruby/etc


 DUB is great if you're an experienced linux dev. But for somebody just 
 getting started, especially those coming from other languages with 
 standard libraries (aka, all of them) the idea of having to use a package 
 manager to do anything is completely backwards. We need to be reducing our 
 project setup times, not increasing them by making people download the 
 same 10 packages for every project they start. People want to download a 
 language and start writing code. Not faff about with getting the right 
 package configuration just to write some output to the console.


The situation you describe sounds bad, but I'm not sure that's the situation 
with dub.  Obviously I don't want us to move to a worse situation.


 It is also very helpful to have a standardized set of capabilities that I 
 can rely on existing at a minimum in all configurations. This is critical 
 in a code-generation context when you are building code for an unknown 
 environment where the only certain capabilities you have are the stdlib 
 and any libraries you provide. And yes, I have a code generation project 
 planned for D later this year that is very important to my company. 
 Killing the standard library would effectively cancel that project and end 
 my involvement in D, as we can't convert to D without this code-gen 
 project. I make this point not to try to hold D hostage to myself, D 
 should never be held hostage by the needs of any one entity, but that 
 having a stdlib available by default is extremely useful in certain cases 
 and by removing it you make those cases exponentially more difficult if 
 not impossible to achieve.


I don't understand this at all.  We wouldn't stop shipping phobos with the 
compiler, it would just be in the format of a dub repo/several dub repos 
instead of it's own thing.


 If anything Phobos needs to get bigger and increase the coverage standard 
 available functionality. We can talk about improvements to reduce module 
 dependencies, and improve layout, design, and code quality, but none of 
 those are sufficient reasons in my mind to through out the idea of a 
 stdlib altogether.


Maybe I should have said it differently.  I don't want to throw out the 
_concept_ of phobos, just normalize it a little with the concept of 
third-party packages.  Phobos would still be officially supported, 
regression tested, code reviewed etc

My hope is that this would improve the quality and quantity of phobos, 
because third-party modules meeting the high standards could be moved into 
phobos, and unmaintained or obsolete modules could be moved out without 
horrific breakage.


 The only way I could accept that is if D integrated DUB directly into it's 
 source code and downloaded and installed packages silently in the 
 background when one of the imports matches a DUB package import. But I 
 don't see that happening anytime soon.


I can certainly imagine a world where `rdmd proj.d` will automagically fetch 
dub packages for you. 



 Feb 10 2014



  parent reply "Adam Wilson" <flyboynw gmail.com>  writes:


On Mon, 10 Feb 2014 22:07:50 -0800, Daniel Murphy  
<yebbliesnospam gmail.com> wrote:


 "Adam Wilson"  wrote in message  
 news:op.xa3n27el707hn8 invictus.hra.local...



 To be honest I haven't been following it closely as I've been buried in  
 work projects and Aurora. It would be awesome if that came sometime  
 later this year. We badly need those capabilities, and I imagine that  
 hacking on the compiler itself will get much easier when it's converted  
 to D.


 No guarantees.


 I don't know if I can express how strongly I disagree with that  
 sentiment. I don't use dub, I don't really want to use dub, and I am  
 virtually certain that the whole concept of using dub is a going to  
 make newbie acceptance much more difficult. D is supposed to make life  
 easier, not harder.


 As Mike Parker said, that doesn't match my experience, and it seems to  
 work for python/ruby/etc


 DUB is great if you're an experienced linux dev. But for somebody just  
 getting started, especially those coming from other languages with  
 standard libraries (aka, all of them) the idea of having to use a  
 package manager to do anything is completely backwards. We need to be  
 reducing our project setup times, not increasing them by making people  
 download the same 10 packages for every project they start. People want  
 to download a language and start writing code. Not faff about with  
 getting the right package configuration just to write some output to  
 the console.


 The situation you describe sounds bad, but I'm not sure that's the  
 situation with dub.  Obviously I don't want us to move to a worse  
 situation.


 It is also very helpful to have a standardized set of capabilities that  
 I can rely on existing at a minimum in all configurations. This is  
 critical in a code-generation context when you are building code for an  
 unknown environment where the only certain capabilities you have are  
 the stdlib and any libraries you provide. And yes, I have a code  
 generation project planned for D later this year that is very important  
 to my company. Killing the standard library would effectively cancel  
 that project and end my involvement in D, as we can't convert to D  
 without this code-gen project. I make this point not to try to hold D  
 hostage to myself, D should never be held hostage by the needs of any  
 one entity, but that having a stdlib available by default is extremely  
 useful in certain cases and by removing it you make those cases  
 exponentially more difficult if not impossible to achieve.


 I don't understand this at all.  We wouldn't stop shipping phobos with  
 the compiler, it would just be in the format of a dub repo/several dub  
 repos instead of it's own thing.


I suppose as long as it's available by default that's OK.


 If anything Phobos needs to get bigger and increase the coverage  
 standard available functionality. We can talk about improvements to  
 reduce module dependencies, and improve layout, design, and code  
 quality, but none of those are sufficient reasons in my mind to through  
 out the idea of a stdlib altogether.


 Maybe I should have said it differently.  I don't want to throw out the  
 _concept_ of phobos, just normalize it a little with the concept of  
 third-party packages.  Phobos would still be officially supported,  
 regression tested, code reviewed etc

 My hope is that this would improve the quality and quantity of phobos,  
 because third-party modules meeting the high standards could be moved  
 into phobos, and unmaintained or obsolete modules could be moved out  
 without horrific breakage.


 The only way I could accept that is if D integrated DUB directly into  
 it's source code and downloaded and installed packages silently in the  
 background when one of the imports matches a DUB package import. But I  
 don't see that happening anytime soon.


 I can certainly imagine a world where `rdmd proj.d` will automagically  
 fetch dub packages for you.


That'd be quite good actually. :-) Although at this point I don't see much  
advantage, either way.

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator



 Feb 10 2014



  parent  Marco Leise <Marco.Leise gmx.de>  writes:


Am Mon, 10 Feb 2014 23:06:51 -0800
schrieb "Adam Wilson" <flyboynw gmail.com>:


 I don't understand this at all.  We wouldn't stop shipping phobos with  
 the compiler, it would just be in the format of a dub repo/several dub  
 repos instead of it's own thing.


 
 I suppose as long as it's available by default that's OK.


Using dub is one way that works for one group of people.

For me the ideal situation that I strive to achieve is that it
is dead simple to install any D application using the Linux
package manager.
Thereby it should not matter if the app is 32-bit only, only
compiles with GDC or must use a static Phobos lib opposed to
the shared one. The package manager pulls in the correct
Phobos dependency in the required version and keeps track of
the installed files for a later uninstall when they are no
longer needed. Just as it works for any other popular Linux
app.

Then again if all you need is a quick setup for playing with
DMD and external libraries in your home directory, dub is
ideal.

-- 
Marco



 Feb 17 2014



prev sibling next sibling parent  "ed" <growlercab gmail.com>  writes:


On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:

[snip]


 If anything Phobos needs to get bigger and increase the 
 coverage standard available functionality. We can talk about 
 improvements to reduce module dependencies, and improve layout, 
 design, and code quality, but none of those are sufficient 
 reasons in my mind to through out the idea of a stdlib 
 altogether.


I disagree to some extent. I don't want to see Phobos, the core 
stdlib get bigger. But I do want to see the official module list 
grow.

I'd love to have opt-in officially endorsed, D-dev reviewed and 
supported modules for things like sqlite/db access, xml, gui, 
gfx, SciD etc. etc. Whether via dub or tarball, I'm easy.

I dislike package managers but DUB is simple to use and works 
reasonably well. If it were adopted as "the" package system for 
official D modules I would have no problem.

A dub GUI would be an interesting side project...I might have to 
have a hack at that. Anyone else working on one?

Cheers,
ed



 Feb 10 2014



prev sibling  parent  "ponce" <contact gam3sfrommars.fr>  writes:


On Tuesday, 11 February 2014 at 04:29:22 UTC, Adam Wilson wrote:

 I don't know if I can express how strongly I disagree with that 
 sentiment. I don't use dub, I don't really want to use dub, and 
 I am virtually certain that the whole concept of using dub is a 
 going to make newbie acceptance much more difficult. D is 
 supposed to make life easier, not harder.

 DUB is great if you're an experienced linux dev. But for 
 somebody just getting started, especially those coming from 
 other languages with standard libraries (aka, all of them) the 
 idea of having to use a package manager to do anything is 
 completely backwards. We need to be reducing our project setup 
 times, not increasing them by making people download the same 
 10 packages for every project they start. People want to 
 download a language and start writing code. Not faff about with 
 getting the right package configuration just to write some 
 output to the console.


Well if you only need some output to the console then sure, you 
don't necessarily need DUB.
A fresh programmer can still download VisualD and create a 
project since that will seem simpler at first.

But DUB does make life a lot easier. Not needing to care about 
import/source paths is a huge gain. Being able to discover new 
libraries and integrate them in seconds is a lot better than what 
it was before using a package manager.

The C++ way of providing zillions build systems is frankly a real 
impediment to code sharing.



 Feb 11 2014



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com>  writes:


On 10/02/2014 20:32, Adam Wilson wrote:

 Not having an IDE is more tangential, but no less important. Here we
 have two integrations with popular IDE's, Visual Studio and Mono.
 However, these integrations suffer from the lack of tooling for D. DMD
 can't be used as libary, so these integrations have had to produce their
 own parsing engines and they are always behind DMD itself so they never
 parse the current DMD language quite correctly. This means that you

 have become used to. D's integration with IDE's is similar to the
 situation with IDE integration for C++. Yes D is easier to parse than
 C++, but since we can't use the canonical parser, we don't have any
 parsers that match D in it's current form so the AST's are almost always
 broken or plain incorrect.

 Building a new IDE won't solve this problem. Here we need to focus on
 building better tools for D, turning DMD itself into a library or
 Compiler-as-a-Service in the current lingo, since libraries are now
 "services". D needs to make great strides in tooling to be relevant, we
 need first-class debugging, and they need to support more than the
 terminal. We need D as library, we need better IDE integrations. We need
 a broader standard library. We need more bindings for existing
 libraries. We need more new libraries (like the Aurora library I am
 working on).


Once you have a complete D parser (as all the major D IDEs have now), 
it's easy to keep it up to date, since the new language syntaxes are 
few, and easy to implement.
The real problem is semantic analysis (anything from code completion, to 
error/warning reporting, etc.). That's the hard thing to implement (as 
it's so extensive), to keep up to date, and to be full-feature and not 
just limited.

There is not a chance in hell DMD would sucessfully be adapted for these 
purposes. Maybe as fork, but not as the main stream. Even as a fork I 
hardly see it happening (The Descent IDE went with this route but it the 
semantic engine was buggy and quickly became very hard to maintain.) The 
reasons are manyfold and I'm not going into detail, but suffice to say a 
semantic engine for an IDE needs to be prepared to run in an 
interactive/deamon mode to have a decent performance, not in batch (run 
once) mode like a compiler. This adds several constraints and 
requirements to the semantic engine architecture, something that DMD is 
not prepared to. It would take a large engineering effort to adapt it to 
that, and crucially, Walter would have to be involved, but he has his 
hands full already.

A better approach for the D situation, is having a semantic engine done 
from scratch, adapted for IDE use. With that in mind, a project like DCD 
is very interesting and promising, although still a significant effort.

--
Bruno Medeiros



 Feb 12 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Bruno Medeiros"  wrote in message news:ldfpa7$27s3$1 digitalmars.com...


 There is not a chance in hell DMD would sucessfully be adapted for these 
 purposes. Maybe as fork, but not as the main stream. Even as a fork I 
 hardly see it happening (The Descent IDE went with this route but it the 
 semantic engine was buggy and quickly became very hard to maintain.) The 
 reasons are manyfold and I'm not going into detail, but suffice to say a 
 semantic engine for an IDE needs to be prepared to run in an 
 interactive/deamon mode to have a decent performance, not in batch (run 
 once) mode like a compiler. This adds several constraints and requirements 
 to the semantic engine architecture, something that DMD is not prepared 
 to. It would take a large engineering effort to adapt it to that, and 
 crucially, Walter would have to be involved, but he has his hands full 
 already.


I disagree, this is 'the plan'.  Please, go into detail, I would love to 
find out about any roadblocks I've overlooked now rather than later. 



 Feb 12 2014



  parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com>  writes:


On 12/02/2014 13:35, Daniel Murphy wrote:

 "Bruno Medeiros"  wrote in message news:ldfpa7$27s3$1 digitalmars.com...


 There is not a chance in hell DMD would sucessfully be adapted for
 these purposes. Maybe as fork, but not as the main stream. Even as a
 fork I hardly see it happening (The Descent IDE went with this route
 but it the semantic engine was buggy and quickly became very hard to
 maintain.) The reasons are manyfold and I'm not going into detail, but
 suffice to say a semantic engine for an IDE needs to be prepared to
 run in an interactive/deamon mode to have a decent performance, not in
 batch (run once) mode like a compiler. This adds several constraints
 and requirements to the semantic engine architecture, something that
 DMD is not prepared to. It would take a large engineering effort to
 adapt it to that, and crucially, Walter would have to be involved, but
 he has his hands full already.




Well, I need to revise my statements because, upon further thought, I 
dont find them entirely accurate.
I was thinking of the use case of making DMD an interactive semantic 
engine deamon, which I still think would take a miracle to get there 
(whilst at the same time having a decent measure of quality, that is).

But I understand now your idea is different, you just want to expose the 
current compiler functionality as a *library*, and let other 
users/programs use it as they see fit, correct? A deamon engine could 
then be built on top (or the compiler library embedded directly in 
IDE/tool code), but that would be a task for someone else.

Now, that goal (compiler as library) I do believe to be feasible, but 
still incredible hard (again, if you want to have something of quality 
that is). For example, the compiler library functionality needs to be 
prepared to be re-used within the same session. This means you need to 
do proper memory management, you can't just allocate blindly and assume 
its fine because the code is running under a compiler program which will 
then terminate once it's run once. From what I've heard some time ago, 
DMD code does nearly no memory management. Maybe this has changed in the 
meanwhile and the situation improved drastically (or a D port would 
bring in the GC and deal with this problem that way - but then we'd need 
the D port for that).
There is other minutiae of functionality which is also important (for 
example, good parser error recovery, with sensible AST and source ranges 
in the result nodes, etc.)

But anyways, those are secondary points actually. What I think is really 
crucial, is that we don't have a main-stream compiler in D. When DMD 
gets ported to D, and the main development of DMD happens there, in the 
D version, then I'll believe a reasonable compiler-as-library could happen.


 I disagree, this is 'the plan'.  Please, go into detail, I would love to
 find out about any roadblocks I've overlooked now rather than later.


What do you mean, are you going to invest a lot of work on that?



 Feb 19 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Bruno Medeiros"  wrote in message news:le2i5p$28g5$1 digitalmars.com...


 [snip]


I know that a lot of work needs to be done before the frontend is ready to 
be efficiently used as a library, but that doesn't make it impossible.


 But anyways, those are secondary points actually. What I think is really 
 crucial, is that we don't have a main-stream compiler in D. When DMD gets 
 ported to D, and the main development of DMD happens there, in the D 
 version, then I'll believe a reasonable compiler-as-library could happen.


I think you may have missed something!  This is coming in the near future.


I have been working on automatically converting the DMD fronted to D since 
dconf (and before).  I've produced working compilers on win32, linux32, and 
linux64, with the other platforms currently lacking only because I don't 
have a box set up for them.

The only outstanding work for dmd is fixing layout and commenting/formatting 
issues in the generated source, which I am slowly getting through.

I expect any issues encountered with the other platforms to be minor, and 
hopefully switching gdc and ldc will be fairly painless too.

I'm hoping 2.066 will be the first D-based dmd release and work on the C++ 
source will cease immediately after that.

https://github.com/D-Programming-Language/dmd/pull/1980
https://github.com/yebblies/magicport2.git


  > I disagree, this is 'the plan'.  Please, go into detail, I would love 
 to
  > find out about any roadblocks I've overlooked now rather than later.

 What do you mean, are you going to invest a lot of work on that?


I already have!

"git log --merges | grep "\[DDMD\]" | wc -l" shows 217 merged pull requests 
tagged as DDMD, and there were quite a few before I started tagging them.

Converting to D is the first step to getting compiler-as-a-library from dmd. 



 Feb 19 2014



 next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 19 February 2014 16:03, Daniel Murphy <yebbliesnospam gmail.com> wrote:

 "Bruno Medeiros"  wrote in message news:le2i5p$28g5$1 digitalmars.com...


 [snip]



 I know that a lot of work needs to be done before the frontend is ready to
 be efficiently used as a library, but that doesn't make it impossible.



 But anyways, those are secondary points actually. What I think is really
 crucial, is that we don't have a main-stream compiler in D. When DMD gets
 ported to D, and the main development of DMD happens there, in the D
 version, then I'll believe a reasonable compiler-as-library could happen.



 I think you may have missed something!  This is coming in the near future.


 I have been working on automatically converting the DMD fronted to D since
 dconf (and before).  I've produced working compilers on win32, linux32, and
 linux64, with the other platforms currently lacking only because I don't
 have a box set up for them.

 The only outstanding work for dmd is fixing layout and commenting/formatting
 issues in the generated source, which I am slowly getting through.

 I expect any issues encountered with the other platforms to be minor, and
 hopefully switching gdc and ldc will be fairly painless too.


Once you get past the 6 months spent re-writing 70% of the existing
gdc and ldc glue code. ;)



 Feb 19 2014



 next sibling parent  "Steve Teale" <steve.teale britseyeview.com>  writes:


On Wednesday, 19 February 2014 at 17:22:37 UTC, Iain Buclaw wrote:

 I expect any issues encountered with the other platforms to be 
 minor, and
 hopefully switching gdc and ldc will be fairly painless too.


 Once you get past the 6 months spent re-writing 70% of the 
 existing
 gdc and ldc glue code. ;)


Iain, there are two groups of programmers. One says "That should 
be quite straightforward." The other says "That sounds like a lot 
of work."

My experience in the software industry suggests that it is 
usually the latter group that gets the job done!

Steve



 Feb 19 2014



prev sibling  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Iain Buclaw"  wrote in message 
news:mailman.190.1392830556.6445.digitalmars-d puremagic.com...


 Once you get past the 6 months spent re-writing 70% of the existing
 gdc and ldc glue code. ;)


As the person who re-wrote the dmd glue code, I can assure you it's not 
really that bad.  Worst case, you could even defer those updates by adding 
the virtual functions back into the ast classes. 



 Feb 19 2014



prev sibling  parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com>  writes:


On 19/02/2014 16:03, Daniel Murphy wrote:

 "Bruno Medeiros"  wrote in message news:le2i5p$28g5$1 digitalmars.com...


 [snip]


 I know that a lot of work needs to be done before the frontend is ready
 to be efficiently used as a library, but that doesn't make it impossible.


 But anyways, those are secondary points actually. What I think is
 really crucial, is that we don't have a main-stream compiler in D.
 When DMD gets ported to D, and the main development of DMD happens
 there, in the D version, then I'll believe a reasonable
 compiler-as-library could happen.


 I think you may have missed something!  This is coming in the near future.


 I have been working on automatically converting the DMD fronted to D
 since dconf (and before).  I've produced working compilers on win32,
 linux32, and linux64, with the other platforms currently lacking only
 because I don't have a box set up for them.

 The only outstanding work for dmd is fixing layout and
 commenting/formatting issues in the generated source, which I am slowly
 getting through.

 I expect any issues encountered with the other platforms to be minor,
 and hopefully switching gdc and ldc will be fairly painless too.

 I'm hoping 2.066 will be the first D-based dmd release and work on the
 C++ source will cease immediately after that.


I'm glad to hear that, that sounds very promising. Especially since 
dogfooding the compiler has great importance that goes beyond just the 
compiler-as-a-library goal.

I think DMD will get there eventually, but... you think it will come as 
soon as the DMD 2.066 release already?? As in, the official DMD, not a 
fork. Walter and Andrei have said they are on board with that?

Also, Ian raises a good point, what will happen to GDC and LDC once that 
switch happens? They are both very important projects to be left hanging 
in the rain.
-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros



 Feb 19 2014



 next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 19 February 2014 18:12, Bruno Medeiros <brunodomedeiros+dng gmail.com> wrote:

 On 19/02/2014 16:03, Daniel Murphy wrote:

 "Bruno Medeiros"  wrote in message news:le2i5p$28g5$1 digitalmars.com...


 [snip]



 I know that a lot of work needs to be done before the frontend is ready
 to be efficiently used as a library, but that doesn't make it impossible.


 But anyways, those are secondary points actually. What I think is
 really crucial, is that we don't have a main-stream compiler in D.
 When DMD gets ported to D, and the main development of DMD happens
 there, in the D version, then I'll believe a reasonable
 compiler-as-library could happen.



 I think you may have missed something!  This is coming in the near future.


 I have been working on automatically converting the DMD fronted to D
 since dconf (and before).  I've produced working compilers on win32,
 linux32, and linux64, with the other platforms currently lacking only
 because I don't have a box set up for them.

 The only outstanding work for dmd is fixing layout and
 commenting/formatting issues in the generated source, which I am slowly
 getting through.

 I expect any issues encountered with the other platforms to be minor,
 and hopefully switching gdc and ldc will be fairly painless too.

 I'm hoping 2.066 will be the first D-based dmd release and work on the
 C++ source will cease immediately after that.



 I'm glad to hear that, that sounds very promising. Especially since
 dogfooding the compiler has great importance that goes beyond just the
 compiler-as-a-library goal.

 I think DMD will get there eventually, but... you think it will come as soon
 as the DMD 2.066 release already?? As in, the official DMD, not a fork.
 Walter and Andrei have said they are on board with that?

 Also, Ian raises a good point, what will happen to GDC and LDC once that
 switch happens? They are both very important projects to be left hanging in
 the rain.


Someone can feel free to go through all Visitor-related pulls and
merge them down to GDC ahead of merging the next release itself.  That
alone would relieve 90% of the god awful pain the next two releases
will bring - not that any of the 2.060 series releases were any
pleasant.

Regards
Iain.



 Feb 19 2014



  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Iain Buclaw"  wrote in message 
news:mailman.195.1392842840.6445.digitalmars-d puremagic.com...


 Someone can feel free to go through all Visitor-related pulls and
 merge them down to GDC ahead of merging the next release itself.  That
 alone would relieve 90% of the god awful pain the next two releases
 will bring - not that any of the 2.060 series releases were any
 pleasant.


This will be my focus after DDMD is finished. 



 Feb 19 2014



  parent reply Iain Buclaw <ibuclaw gdcproject.org>  writes:


On 20 February 2014 03:13, Daniel Murphy <yebbliesnospam gmail.com> wrote:

 "Iain Buclaw"  wrote in message
 news:mailman.195.1392842840.6445.digitalmars-d puremagic.com...



 Someone can feel free to go through all Visitor-related pulls and
 merge them down to GDC ahead of merging the next release itself.  That
 alone would relieve 90% of the god awful pain the next two releases
 will bring - not that any of the 2.060 series releases were any
 pleasant.



 This will be my focus after DDMD is finished.


If that is an offer to raise pulls to GDC for all your changes, I
humbling accept anything.  Though I hope you don't mind if I insist on
GCC coding conventions. :o)

http://gcc.gnu.org/codingconventions.html#Cxx_Conventions



 Feb 20 2014



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Iain Buclaw"  wrote in message 
news:mailman.196.1392884595.6445.digitalmars-d puremagic.com...


 This will be my focus after DDMD is finished.


 If that is an offer to raise pulls to GDC for all your changes, I
 humbling accept anything.  Though I hope you don't mind if I insist on
 GCC coding conventions. :o)


We can't switch until gdc and ldc are ready, so I assume me working on 
merging the visitor stuff to gdc/ldc will help speed things along.


 http://gcc.gnu.org/codingconventions.html#Cxx_Conventions


Fun fun. 



 Feb 20 2014



prev sibling  parent reply "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Bruno Medeiros"  wrote in message news:le2s5q$2i0u$1 digitalmars.com...


 I think DMD will get there eventually, but... you think it will come as 
 soon as the DMD 2.066 release already?? As in, the official DMD, not a 
 fork. Walter and Andrei have said they are on board with that?


The exact details of the switch need to be worked out, but Walter and Andrei 
are on board.  We're looking at at least a couple of months until the next 
release, which should be plenty of time to finalize this.  No guarantees of 
course, we all still have to agree on a way to do it.


 Also, Ian raises a good point, what will happen to GDC and LDC once that 
 switch happens? They are both very important projects to be left hanging 
 in the rain.


The switch will only happen once all three compilers are ready.  Automatic 
conversion will let us test and release official D versions of DMD in 
parallel without the sources getting out of sync. 



 Feb 19 2014



  parent  "Paulo Pinto" <pjmlp progtools.org>  writes:


On Thursday, 20 February 2014 at 03:11:17 UTC, Daniel Murphy 
wrote:

 "Bruno Medeiros"  wrote in message 
 news:le2s5q$2i0u$1 digitalmars.com...


 I think DMD will get there eventually, but... you think it 
 will come as soon as the DMD 2.066 release already?? As in, 
 the official DMD, not a fork. Walter and Andrei have said they 
 are on board with that?


 The exact details of the switch need to be worked out, but 
 Walter and Andrei are on board.  We're looking at at least a 
 couple of months until the next release, which should be plenty 
 of time to finalize this.  No guarantees of course, we all 
 still have to agree on a way to do it.


 Also, Ian raises a good point, what will happen to GDC and LDC 
 once that switch happens? They are both very important 
 projects to be left hanging in the rain.


 The switch will only happen once all three compilers are ready.
  Automatic conversion will let us test and release official D 
 versions of DMD in parallel without the sources getting out of 
 sync.


Congratulations on the work achieved thus far. :)



 Feb 20 2014



prev sibling next sibling parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote:


 I am only 20 and am still in university so I feel like I can 
 answer this with at least my own experiences. Personally I 
 think D would capture the attention of more young people if it 
 was simply easier to use. The first "real" language I really 



You hijacked my topic and converted it into the usual arguments 
about lack of infrastructure for D.

I'm talking about guys and girls who don't have a computer, let 

succeeded in getting rooted. So is your answer that they should 
just use Java?


and is easy to use. Get out of the wood and see the trees!

I'm at the other end of my life, with a long view of history. We 
should do our bit to help to bring civilization and reason (back) 


A more relevant criticism would be that people who only know say 
Swahili won't be able to find out about and use D anyway - Java 
either. Sadly my Swahili is not up to it.

Sorry, but you asked for it ;=)

Steve



 Feb 11 2014



 next sibling parent reply "Joakim" <joakim airpost.net>  writes:


On Tuesday, 11 February 2014 at 17:37:17 UTC, Steve Teale wrote:

 You hijacked my topic and converted it into the usual arguments 
 about lack of infrastructure for D.

 I'm talking about guys and girls who don't have a computer, let 

 succeeded in getting rooted. So is your answer that they should 
 just use Java?


 language, and is easy to use. Get out of the wood and see the 
 trees!

 I'm at the other end of my life, with a long view of history. 
 We should do our bit to help to bring civilization and reason 


 A more relevant criticism would be that people who only know 
 say Swahili won't be able to find out about and use D anyway - 
 Java either. Sadly my Swahili is not up to it.


Well, that's the problem, it was kind of a silly question to 
begin with.  How many Swahili people even have a smartphone, as 
opposed to a feature phone?  What percentage of them would be 
able to grasp the concept of rooting, let alone execute it?

I suppose if we were to humor the question, as it's always 
possible that the next John Carmack is out there somewhere, 
here's what I'd suggest.  You can get an Android smartphone for 
as cheap as $50-100 these days.  I'd pick one up that worked with 
a bluetooth keyboard, as programming on the touch keyboard on 
your small phone screen is paramount to torture. ;) Then, you 
have two options:

1) Download an ssh client app and buy access to a FreeBSD or 
linux VPS, which you can get for as cheap as $5/month.  This 
might require a credit card or paypal account, not sure how tough 
those are to get in the developing world.  You can then ssh into 
the VPS, download dmd or any other compiler, and code to your 
heart's content, albeit with some annoying lag from developing 
over the network.

2) Root your smartphone and install all the necessary development 
software, which I'm not sure even exists, as most devs 
cross-compile to Android.

Both seem kind of far-fetched.  You need a certain basic level of 
knowledge, wealth, and leisure time to get into programming, 
which many in the developing world don't have.  But if they 
really went after it, the VPS option is probably the best bet, at 
a cost of about $100 up front plus $5/month for hosting.



 Feb 11 2014



  parent  "Chris" <wendlec tcd.ie>  writes:


On Tuesday, 11 February 2014 at 20:12:16 UTC, Joakim wrote:

 On Tuesday, 11 February 2014 at 17:37:17 UTC, Steve Teale wrote:

 You hijacked my topic and converted it into the usual 
 arguments about lack of infrastructure for D.

 I'm talking about guys and girls who don't have a computer, 

 they succeeded in getting rooted. So is your answer that they 
 should just use Java?


 language, and is easy to use. Get out of the wood and see the 
 trees!

 I'm at the other end of my life, with a long view of history. 
 We should do our bit to help to bring civilization and reason 


 A more relevant criticism would be that people who only know 
 say Swahili won't be able to find out about and use D anyway - 
 Java either. Sadly my Swahili is not up to it.


 Well, that's the problem, it was kind of a silly question to 
 begin with.  How many Swahili people even have a smartphone, as 
 opposed to a feature phone?  What percentage of them would be 
 able to grasp the concept of rooting, let alone execute it?

 I suppose if we were to humor the question, as it's always 
 possible that the next John Carmack is out there somewhere, 
 here's what I'd suggest.  You can get an Android smartphone for 
 as cheap as $50-100 these days.  I'd pick one up that worked 
 with a bluetooth keyboard, as programming on the touch keyboard 
 on your small phone screen is paramount to torture. ;) Then, 
 you have two options:

 1) Download an ssh client app and buy access to a FreeBSD or 
 linux VPS, which you can get for as cheap as $5/month.  This 
 might require a credit card or paypal account, not sure how 
 tough those are to get in the developing world.  You can then 
 ssh into the VPS, download dmd or any other compiler, and code 
 to your heart's content, albeit with some annoying lag from 
 developing over the network.

 2) Root your smartphone and install all the necessary 
 development software, which I'm not sure even exists, as most 
 devs cross-compile to Android.

 Both seem kind of far-fetched.  You need a certain basic level 
 of knowledge, wealth, and leisure time to get into programming, 
 which many in the developing world don't have.  But if they 
 really went after it, the VPS option is probably the best bet, 
 at a cost of about $100 up front plus $5/month for hosting.


I suggest Raspberry Pi:

http://www.raspberrypi.org/

It was especially designed for the "developing world" (whatever 
that means! A lot of structures and laws in Europe go back to the 
Middle Ages!) It is about £40~50. I saw one, a tiny little thing 
but very powerful.

We send all our electronic rubbish to Africa. Instead of sending 
it there as rubbish poluting the environment and ruining the 
locals' health, we should give them to the people so they have 
something to work with. A lot of devices still work, but they are 
"outdated".



 Feb 12 2014



prev sibling  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Tuesday, 11 February 2014 at 17:37:17 UTC, Steve Teale wrote:

 On Monday, 10 February 2014 at 19:03:22 UTC, Tofu Ninja wrote:


 I am only 20 and am still in university so I feel like I can 
 answer this with at least my own experiences. Personally I 
 think D would capture the attention of more young people if it 
 was simply easier to use. The first "real" language I really 



 You hijacked my topic and converted it into the usual arguments 
 about lack of infrastructure for D.

 I'm talking about guys and girls who don't have a computer, let 

 succeeded in getting rooted. So is your answer that they should 
 just use Java?


 language, and is easy to use. Get out of the wood and see the 
 trees!

 I'm at the other end of my life, with a long view of history. 
 We should do our bit to help to bring civilization and reason 


 A more relevant criticism would be that people who only know 
 say Swahili won't be able to find out about and use D anyway - 
 Java either. Sadly my Swahili is not up to it.

 Sorry, but you asked for it ;=)

 Steve


Oh I am sorry, by developing world I thought you were talking 
about the world of developers, why are you interested in getting 
D to the developing world? Seems kinda odd...



 Feb 11 2014



  parent reply "Steve Teale" <steve.teale britseyeview.com>  writes:


On Wednesday, 12 February 2014 at 02:43:36 UTC, Tofu Ninja wrote:

 Steve


 Oh I am sorry, by developing world I thought you were talking 
 about the world of developers, why are you interested in 
 getting D to the developing world? Seems kinda odd...


Because if we can't get those young men into something with 
intellectual content, we're going to be back in the dark ages 
before we know it.

I just happen to think D is a great language!



 Feb 13 2014



  parent reply "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 13 February 2014 at 15:58:44 UTC, Steve Teale wrote:


 I just happen to think D is a great language!


Thats not even up for debate, D IS GREAT! The problem is just 
convincing the rest of the world that it is, but thus is the task 
of the lucky few who have seen the light.

Jokes aside, I don't think making it possible to write D on a 
smartphone would help get D(or any language for that matter) into 
the hands of kids in the developing world. Today you can by a 
laptop now for the same price of a midrange smartphone with much 
more power. Though the smartphone has the advantage of the 
internet which is essentially required to do anything programing 
wise but it is certainly possible get the internet elsewhere. 
Although if we are talking about a developing country then I 
suppose they might not have the infrastructure to support 
landline.

In reality I think there are many other more difficult barriers 
to learning to program in a developing country. For one it is 
basically required to know english to become a proficient 
programer(almost all documentation is written in english). It 
requires ample amounts of free time and regular access to a 
computer with an internet connection, I don't think a smart phone 
would cut it. Also I think the cultivation "intellectual" skills 
require an environment that allows you to not have to worry about 
basic needs and just focus on developing the skill.



 Feb 13 2014



 next sibling parent reply "Sean Kelly" <sean invisibleduck.org>  writes:


For learning to program, I almost feel like getting a sandbox set 
up on the web would be better. The MIT project Scratch, for 
example, is fantastic for teaching programming. Unless you're 
talking about teaching in locations without internet 
connectivity, which is an entirely different problem.



 Feb 13 2014



  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 13 February 2014 at 17:12:47 UTC, Sean Kelly wrote:

 For learning to program, I almost feel like getting a sandbox 
 set up on the web would be better. The MIT project Scratch, for 
 example, is fantastic for teaching programming. Unless you're 
 talking about teaching in locations without internet 
 connectivity, which is an entirely different problem.


That is what I was thinking, I feel like a little while ago 
someone posted a link to an online D compiler and IDE (maybe it 
was in cloud9), but I can't find it now and I remember it not 
being complete(maybe it only had highlighting and no compile or 
something like that... don't really remember).



 Feb 13 2014



prev sibling  parent  "Tofu Ninja" <emmons0 purdue.edu>  writes:


On Thursday, 13 February 2014 at 16:40:12 UTC, Tofu Ninja wrote:

 On Thursday, 13 February 2014 at 15:58:44 UTC, Steve Teale 
 wrote:


 I just happen to think D is a great language!


 Thats not even up for debate, D IS GREAT! The problem is just 
 convincing the rest of the world that it is, but thus is the 
 task of the lucky few who have seen the light.

 Jokes aside, I don't think making it possible to write D on a 
 smartphone would help get D(or any language for that matter) 
 into the hands of kids in the developing world. Today you can 
 by a laptop now for the same price of a midrange smartphone 
 with much more power. Though the smartphone has the advantage 
 of the internet which is essentially required to do anything 
 programing wise but it is certainly possible get the internet 
 elsewhere. Although if we are talking about a developing 
 country then I suppose they might not have the infrastructure 
 to support landline.

 In reality I think there are many other more difficult barriers 
 to learning to program in a developing country. For one it is 
 basically required to know english to become a proficient 
 programer(almost all documentation is written in english). It 
 requires ample amounts of free time and regular access to a 
 computer with an internet connection, I don't think a smart 
 phone would cut it. Also I think the cultivation "intellectual" 
 skills require an environment that allows you to not have to 
 worry about basic needs and just focus on developing the skill.


wouldn't*
wouldn't help get D into the hands of kids

small typo that kinda changes what I was trying to say...



 Feb 13 2014



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 11 February 2014 05:03, Tofu Ninja <emmons0 purdue.edu> wrote:


 On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:


 What can be done to capture the attention of young people in the
 developing world?

 Probably the most effective thing would be if it were possible to edit,
 compile, and run D programs on a cheap Android ARM phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and ambitious young
 men out there, who have saved their all to buy a cheap smartphone.

 Any other ideas?

 Steve


 I am only 20 and am still in university so I feel like I can answer this
 with at least my own experiences. Personally I think D would capture the
 attention of more young people if it was simply easier to use. The first

 the main reason is that it was so flipin easy to learn and get started. All
 I had to do to set it up was download Visual Studio and I was done...
 period ... The documentation was fantastic and everything was named in very
 intuitive ways. Most of the time when I was learning I would just
 ctrl+space and start scrolling through the auto-complete reading the
 documentation of all the functions right there in visual studio. It was
 soooooo easy. In my opinion the biggest thing holding D back by a long shot
 is the tooling and documentation... it is simply terrible. But thats just
 my opinion so I don't want anyone taking offense.


Oh... my... god...

+ulong.max!

This is like music to my ears! :)
I've been banging on about the importance of this stuff forever, and so
frequently get dismissed as being lazy or irrelevant.


Also something that would help get younger people into D was if the std lib


 both so popular because their std lib is so large. Younger people don't
 like to have to deal with non standard libraries as they just make it so
 much more difficult to do things especially as they are still trying to
 learn.

 The lack of a real GUI library is also a hindrance. Young people like to
 see results on the screen other than just text. That is why web and mobile
 development is so popular with young people.

 tldr; Tools suck, documentation sucks, std lib is small and no std GUI
 lib...


It's great to hear it directly from the sort of people that I always refer
to when I talk about this stuff! :)

Fortunately, it has been recognised that tooling must be made a central
focus.
Small steps like VisualD being moved to dlang.org, bundled with the DMD
installer, issues tracking in the main bugtracker, etc.
This is ideally intended to improve visibility of tooling related issues.

What we really lack though, is a couple more Rainer and Alexander's. Worth
their weight in gold!

The other major hurdle is a proper parser usable for tooling. Many are
trying to reinvent the wheel, and nothing short of the DMD front-end itself
is really capable of properly parsing D code.
The biggest missing component I'm aware of is this
DMD-frontend-as-a-library idea that is always being discussed, but never
seems to be happening. If I had to nominate a single critical goal for the
ecosystem for 2014, that would be it.



 Feb 11 2014



 next sibling parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.16.1392169704.6445.digitalmars-d puremagic.com...
On 11 February 2014 05:03, Tofu Ninja <emmons0 purdue.edu> wrote:


 The other major hurdle is a proper parser usable for tooling. Many are 
 trying to reinvent the wheel, and nothing short of the DMD front-end 
 itself is really capable of properly parsing D code.
 The biggest missing component I'm aware of is this 
 DMD-frontend-as-a-library idea that is always being discussed, but never 
 seems to be happening. If I had to nominate a single critical goal for the 
 ecosystem for 2014, that would be it.


DDMD first, then libDMD.  Patience. 



 Feb 11 2014



prev sibling  parent  "Jakob Ovrum" <jakobovrum gmail.com>  writes:


On Wednesday, 12 February 2014 at 01:48:24 UTC, Manu wrote:

 The other major hurdle is a proper parser usable for tooling. 
 Many are
 trying to reinvent the wheel, and nothing short of the DMD 
 front-end itself
 is really capable of properly parsing D code.
 The biggest missing component I'm aware of is this
 DMD-frontend-as-a-library idea that is always being discussed, 
 but never
 seems to be happening. If I had to nominate a single critical 
 goal for the
 ecosystem for 2014, that would be it.


To be precise, it's not the parsing that is the issue. Creating a 
fully compliant (with many updates to the spec needed along the 
way) and robust parser is not particularly hard and is happening 
with stuff like SDC, and more recently, DScanner.

It is the semantic analysis that needs a *proper* engine such as 
that of a compiler, in which case DMD's front-end and SDC are the 
only real options, not the best-effort, good-enough crap is 
currently used by IDEs.

The best we can manage with the current approach is something 
close to what Visual Studio has for C++, but not quite even at 
that level (because D's generic additions and CTFE mix things up 
further), and even then it would be years away in terms of 
development time.



 Feb 12 2014



prev sibling next sibling parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?

 Probably the most effective thing would be if it were possible 
 to edit, compile, and run D programs on a cheap Android ARM 
 phone.

 Is this within the bounds of possibility?

 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to buy 
 a cheap smartphone.

 Any other ideas?

 Steve


Don't forget the young women :)
But yes, good ARM and android support would be awesome, although 
native code isn't exactly something that's heavily encouraged on 
android unfortunately.

As an aside: Africa is heavily dominated by smartphones, due to 
the relative ease of building a mobile infrastructure v.s. a 
landline based model, as well as good resilience to 
poor/unreliable power supply.



 Feb 10 2014



prev sibling next sibling parent  "Dicebot" <public dicebot.lv>  writes:


On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wrote:

 What can be done to capture the attention of young people in 
 the developing world?


What young people and how young exactly? It is a very varying 
crowd..



 Feb 10 2014



prev sibling  parent reply Marco Leise <Marco.Leise gmx.de>  writes:


Am Mon, 10 Feb 2014 18:11:37 +0000
schrieb "Steve Teale" <steve.teale britseyeview.com>:


 What can be done to capture the attention of young people in the 
 developing world?
 
 Probably the most effective thing would be if it were possible to 
 edit, compile, and run D programs on a cheap Android ARM phone.
 
 Is this within the bounds of possibility?
 
 There are millions of unemployed, bored, restless, and ambitious 
 young men out there, who have saved their all to buy a cheap 
 smartphone.
 
 Any other ideas?
 
 Steve


How did you get started?

My first language had these properties:

- it was pre-installed on my PC
- it was powering a game I played
- it was dead simple with good error detection
- I/O, audio, graphics was part of the language

It was QBasic on MS-DOS. Later with Windows 3.1 I switched to
Delphi. The feature set and my usage patterns grew:

- the basic DOS graphics got replaced with window backdrops
  and "bitmap buttons", sound was provided with
  SndPlaySound("some.wav").
- The internet became a new I/O source and I queried a forum
  for new posts, a server for new Counter-Strike maps etc.

During this transition me and a friend from school tried stuff
for fun, like exchanging disks with encoded messages that
could be opened with our "secret network" software, for which
we split up the work. The motivation was still much about
making it look and sound cool and surpassing each other with
fancy ideas and proving that they could be implemented.

I only came to D after I switched to Linux and dropped Delphi.
By that time I wrote server code in Delphi and Java
professionally and fancy graphics was no longer a priority.

I don't think D fills the QBasic niche quite so well and to be
in the Delphi spot requires a much more ready to use
environment with everything included. And by that I mean

builder, graphics and sound. (Which is much easier if your
only target is Win32 :p)

-- 
Marco



 Feb 17 2014



  parent  "John Colvin" <john.loughran.colvin gmail.com>  writes:


On Tuesday, 18 February 2014 at 06:39:51 UTC, Marco Leise wrote:

 Am Mon, 10 Feb 2014 18:11:37 +0000
 schrieb "Steve Teale" <steve.teale britseyeview.com>:


 What can be done to capture the attention of young people in 
 the developing world?
 
 Probably the most effective thing would be if it were possible 
 to edit, compile, and run D programs on a cheap Android ARM 
 phone.
 
 Is this within the bounds of possibility?
 
 There are millions of unemployed, bored, restless, and 
 ambitious young men out there, who have saved their all to buy 
 a cheap smartphone.
 
 Any other ideas?
 
 Steve


 How did you get started?

 My first language had these properties:

 - it was pre-installed on my PC
 - it was powering a game I played
 - it was dead simple with good error detection
 - I/O, audio, graphics was part of the language

 It was QBasic on MS-DOS. Later with Windows 3.1 I switched to
 Delphi. The feature set and my usage patterns grew:

 - the basic DOS graphics got replaced with window backdrops
   and "bitmap buttons", sound was provided with
   SndPlaySound("some.wav").
 - The internet became a new I/O source and I queried a forum
   for new posts, a server for new Counter-Strike maps etc.

 During this transition me and a friend from school tried stuff
 for fun, like exchanging disks with encoded messages that
 could be opened with our "secret network" software, for which
 we split up the work. The motivation was still much about
 making it look and sound cool and surpassing each other with
 fancy ideas and proving that they could be implemented.

 I only came to D after I switched to Linux and dropped Delphi.
 By that time I wrote server code in Delphi and Java
 professionally and fancy graphics was no longer a priority.

 I don't think D fills the QBasic niche quite so well and to be
 in the Delphi spot requires a much more ready to use
 environment with everything included. And by that I mean

 builder, graphics and sound. (Which is much easier if your
 only target is Win32 :p)


Is there any good data on how programmers started out?

My experience was very different: I bought K&R, read it cover to 
cover while trying out the examples, then tried to write a math 
library, only tools involved: gedit and gcc.



 Feb 20 2014