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
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 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
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 was C#(about 5-6 years ago) and I 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 lib was a little bit more expansive. Look at java and c# 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 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 "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
prev sibling 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 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
 can't turn on the really cool features that we in the C#/Java community
 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 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 "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
prev sibling 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 "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 "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 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 "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
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 "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 "real" language I really got into was C#(about 5-6 years ago) and I 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 lib was a little bit more expansive. Look at java and c# 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...

I wholeheartedly agree with this sentiment, although I am a little older and got my start in a combination of VB6 and C++98. But C# is what made me 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 on the really cool features that we in the C#/Java community 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). 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
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 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.

I've come to agree that good IDE integration is a must. I use C# 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 "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 "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
prev sibling next sibling parent "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
prev sibling 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 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 next sibling parent "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
prev sibling next 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 next sibling parent "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
prev sibling next sibling parent "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 
 got into was C#(about 5-6 years ago) and I think the main

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 alone C#. They just have a cheap smart phone that maybe they succeeded in getting rooted. So is your answer that they should just use Java? And yes, the C# library is excellent, but D is a better 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 (back) to the world, not just tell people 'use C#'. 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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 
 alone C#. They just have a cheap smart phone that maybe they 
 succeeded in getting rooted. So is your answer that they should 
 just use Java?

 And yes, the C# library is excellent, but D is a better 
 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 
 (back) to the world, not just tell people 'use C#'.

 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.

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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2903cec644e04f22bc3ac
Content-Type: text/plain; charset=UTF-8

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 "real" language I really got into was C#(about 5-6 years ago) and I 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.

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
 was a little bit more expansive. Look at java and c# 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...

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. --001a11c2903cec644e04f22bc3ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 1 February 2014 05:03, Tofu Ninja <span dir=3D"ltr">&lt;<a href=3D"mailto:e= mmons0 purdue.edu" target=3D"_blank">emmons0 purdue.edu</a>&gt;</span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s= olid;padding-left:1ex"> <div class=3D"">On Monday, 10 February 2014 at 18:11:38 UTC, Steve Teale wr= ote:<br> </div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2= 04);border-left-style:solid;padding-left:1ex"> What can be done to capture the attention of young people in the developing= world?<br> <br> Probably the most effective thing would be if it were possible to edit, com= pile, and run D programs on a cheap Android ARM phone.<br> <br> Is this within the bounds of possibility?<br> <br> There are millions of unemployed, bored, restless, and ambitious young men = out there, who have saved their all to buy a cheap smartphone.<br> <br> Any other ideas?<br> <br> Steve<br> </blockquote> <br></div></div> I am only 20 and am still in university so I feel like I can answer this wi= th at least my own experiences. Personally I think D would capture the atte= ntion of more young people if it was simply easier to use. The first &quot;= real&quot; language I really got into was C#(about 5-6 years ago) and I thi= nk 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... p= eriod ... The documentation was fantastic and everything was named in very = intuitive ways. Most of the time when I was learning I would just ctrl+spac= e and start scrolling through the auto-complete reading the documentation o= f all the functions right there in visual studio. It was soooooo easy. In m= y opinion the biggest thing holding D back by a long shot is the tooling an= d documentation... it is simply terrible. But thats just my opinion so I do= n&#39;t want anyone taking offense.<br> </blockquote><div><br></div><div>Oh... my... god...<br></div><div><br></div=
<div>+ulong.max!<br></div><div><br></div><div>This is like music to my ear=

forever, and so frequently get dismissed as being lazy or irrelevant.<br> </div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20= 4,204,204);border-left-style:solid;padding-left:1ex"> Also something that would help get younger people into D was if the std lib= was a little bit more expansive. Look at java and c# in my opinion they ar= e both so popular because their std lib is so large. Younger people don&#39= ;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 le= arn.<br> <br> The lack of a real GUI library is also a hindrance. Young people like to se= e results on the screen other than just text. That is why web and mobile de= velopment is so popular with young people.<br> <br> tldr; Tools suck, documentation sucks, std lib is small and no std GUI lib.= ..<br> </blockquote></div><br></div><div class=3D"gmail_extra">It&#39;s great to h= ear it directly from the sort of people that I always refer to when I talk = about this stuff! :)</div><div class=3D"gmail_extra"><br></div><div class= =3D"gmail_extra"> Fortunately, it has been recognised that tooling must be made a central foc= us.</div><div class=3D"gmail_extra">Small steps like VisualD being moved to= <a href=3D"http://dlang.org">dlang.org</a>, bundled with the DMD installer= , issues tracking in the main bugtracker, etc.</div> <div class=3D"gmail_extra">This is ideally intended to improve visibility o= f tooling related issues.</div><div class=3D"gmail_extra"><br></div><div cl= ass=3D"gmail_extra">What we really lack though, is a couple more Rainer and= Alexander&#39;s. Worth their weight in gold!</div> <div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The other m= ajor hurdle is a proper parser usable for tooling. Many are trying to reinv= ent the wheel, and nothing short of the DMD front-end itself is really capa= ble of properly parsing D code.</div> <div class=3D"gmail_extra">The biggest missing component I&#39;m aware of i= s this DMD-frontend-as-a-library idea that is always being discussed, but n= ever seems to be happening. If I had to nominate a single critical goal for= the ecosystem for 2014, that would be it.</div> </div> --001a11c2903cec644e04f22bc3ac--
Feb 11 2014
prev sibling next sibling parent "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 
 got into was C#(about 5-6 years ago) and I think the main

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 alone C#. They just have a cheap smart phone that maybe they succeeded in getting rooted. So is your answer that they should just use Java? And yes, the C# library is excellent, but D is a better 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 (back) to the world, not just tell people 'use C#'. 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

about the world of developers, why are you interested in getting D to the developing world? Seems kinda odd...
Feb 11 2014
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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, 
 let alone C#. They just have a cheap smart phone that maybe 
 they succeeded in getting rooted. So is your answer that they 
 should just use Java?

 And yes, the C# library is excellent, but D is a better 
 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 
 (back) to the world, not just tell people 'use C#'.

 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.

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 next 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 "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 next sibling 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 "Steve Teale" <steve.teale britseyeview.com> writes:
On Wednesday, 12 February 2014 at 02:43:36 UTC, Tofu Ninja wrote:
 Steve

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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 next sibling 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 next sibling parent 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 VisualBasic/C#/Delphi like IDE with accessible help, GUI builder, graphics and sound. (Which is much easier if your only target is Win32 :p) -- Marco
Feb 17 2014
prev sibling next sibling 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 "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:

 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
prev sibling next sibling parent 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
prev sibling 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 next sibling 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 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
prev sibling next sibling parent 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
prev sibling next sibling 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 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 VisualBasic/C#/Delphi like IDE with accessible help, GUI 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