I believe there are at least 4 steps that we need to take for D adoption.

1) First of all, D should be true "next generation" language :)
That's Walter's task. We discuss proposals here, at digitalmars.D

2) Next-generation de facto D GUI library
Reality is, most programms are GUI-based, not console ones.
That's why we need GUI library, one that would fulfill /all/ the use cases.
One that is easy, fast, extensible, cross-platform etc.
I'll give my detailed view on it in a separate thread later.
Should be discussed on digitalmars.DWT or a new one

3) Open-source Tools! Next-generation IDE is the goal.
a) D Parser.
b) D compiler, based on D Parser.
c) D intellisense, based on D Parser. Pluggable, customizable.
d) D debugger.
e) IDE that makes use of D intellisense D debugger and D compiler.
One with refactoring, CTFE from within IDE, template debugging, etc.
Should be discussed on digitalmars.IDE

And the biggest one:
4) Standardization. Both standard library and language itself.
All we have now is Phobos and Tango. None of them are in no way standard.
What we have is Implementation. Instead, we need Interfaces, Prototypes and
Rationale. The same goes for a language itself.
I'll give my detailed view on it in a separate thread.
Should be discussed on digitalmars.DTL or a new one

Your opinion?

Koroskin Denis wrote:
> 3) Open-source Tools! Next-generation IDE is the goal.

This is the only one I can comment on. With regards to Descent (there are other D IDEs out there that are very good as well), Ary has implemented all of the following:

> a) D Parser.
> b) D compiler, based on D Parser.

Check, check. The compiler doesn't generate code, but it does a full background compile to resolve types and bindings, which is needed for autocomplete and go-to-definition as well as some other things.

> c) D intellisense, based on D Parser. Pluggable, customizable.

Good intellisense needs semantic information, so actually needs a full front-end compile, not just a parse tree. Descent's has this. There are a few other D IDEs that just use the parse trees, but that still provides serviceable autocomplete for most purposes.

> d) D debugger.

Descent doesn't have its own debugger, but integrates GDB and DDBG. I want to add ZeroBugs support soon.

> e) IDE that makes use of D intellisense D debugger and D compiler.
> One with refactoring, CTFE from within IDE, template debugging, etc.
> Should be discussed on digitalmars.IDE

Well, it's in progress ;-P!

Count the number of GUI programs you use in a day.  For me, it's quite a few... perhaps a dozen.  And you're right so far - distinct console programs I directly run, on a usual day, is probably less (grep, svn, and mysql my calculator mainly.)

Now, count the number of different websites you visit in a day (the majority of which are likely dynamic.)  How does that number compare? Are these not programs?

Food for thought.

-[Unknown]


Koroskin Denis wrote:
> Reality is, most programms are GUI-based, not console ones.

Koroskin Denis wrote:
> I believe there are at least 4 steps that we need to take for D adoption.
> 
> 1) First of all, D should be true "next generation" language :)
> That's Walter's task. We discuss proposals here, at digitalmars.D
> 
> 2) Next-generation de facto D GUI library
> Reality is, most programms are GUI-based, not console ones.
> That's why we need GUI library, one that would fulfill /all/ the use cases.
> One that is easy, fast, extensible, cross-platform etc.
> I'll give my detailed view on it in a separate thread later.
> Should be discussed on digitalmars.DWT or a new one
> 
> 3) Open-source Tools! Next-generation IDE is the goal.

> a) D Parser.

Perhaps a library for reading D source code. and outputting in
A) XML format.
B) Compiler Format(I know compiler is not just one format)
C) Documentation format.
D) Modular for any other format neccessary

> b) D compiler, based on D Parser.
> c) D intellisense, based on D Parser. Pluggable, customizable.
> d) D debugger.
> e) IDE that makes use of D intellisense D debugger and D compiler.
> One with refactoring, CTFE from within IDE, template debugging, etc.
> Should be discussed on digitalmars.IDE
> 
> And the biggest one:
> 4) Standardization. Both standard library and language itself.
> All we have now is Phobos and Tango. None of them are in no way standard.
> What we have is Implementation. Instead, we need Interfaces, Prototypes and
> Rationale. The same goes for a language itself.
> I'll give my detailed view on it in a separate thread.
> Should be discussed on digitalmars.DTL or a new one
> 
> Your opinion?

On Sat, 19 Apr 2008 02:36:20 +0400, Unknown W. Brackets <unknown@simplemachines.org> wrote:

> Count the number of GUI programs you use in a day.  For me, it's quite a few... perhaps a dozen.  And you're right so far - distinct console programs I directly run, on a usual day, is probably less (grep, svn, and mysql my calculator mainly.)
>
> Now, count the number of different websites you visit in a day (the majority of which are likely dynamic.)  How does that number compare? Are these not programs?
>
> Food for thought.
>
> -[Unknown]
>
>
> Koroskin Denis wrote:
>> Reality is, most programms are GUI-based, not console ones.

Right! We just don't develop these in D (for now). It will be possible, too,
once needed functionality (cookies, sessions, mysql connections, etc) gets
its way into D Standard Library.

Speak for yourself.  I do web-based stuff in D already.

We just need a good library that properly exposes them, you're right.  I don't know that this has to be *the* standard library, but it must be *a* standard library.... e.g. "std.xyz", "web.xyz", "gui.xyz" would be fine.

My point is only that the problem is not *only* with GUI.

-[Unknown]


Koroskin Denis wrote:
> On Sat, 19 Apr 2008 02:36:20 +0400, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> 
>> Count the number of GUI programs you use in a day.  For me, it's quite a few... perhaps a dozen.  And you're right so far - distinct console programs I directly run, on a usual day, is probably less (grep, svn, and mysql my calculator mainly.)
>>
>> Now, count the number of different websites you visit in a day (the majority of which are likely dynamic.)  How does that number compare? Are these not programs?
>>
>> Food for thought.
>>
>> -[Unknown]
>>
>>
>> Koroskin Denis wrote:
>>> Reality is, most programms are GUI-based, not console ones.
> 
> Right! We just don't develop these in D (for now). It will be possible, too,
> once needed functionality (cookies, sessions, mysql connections, etc) gets
> its way into D Standard Library.

Unknown W. Brackets wrote:
> Count the number of GUI programs you use in a day.  For me, it's quite a few... perhaps a dozen.  And you're right so far - distinct console programs I directly run, on a usual day, is probably less (grep, svn, and mysql my calculator mainly.)
>
> Now, count the number of different websites you visit in a day (the majority of which are likely dynamic.)  How does that number compare? Are these not programs?
>
> Food for thought.
>
> -[Unknown]
Although you describe correctly the current situation, I must disagree that this situation is something we should strive towards. webapps are an abomination since they're a pile of hacks and band aids over a model that simply was never ment to be used in that way. It's like automobile companies will start adding features for cars so they would be usable on railroads. Since railroads are not suited for many small vehicles no matter what the feature would provide it will still remain somewhat strange and awkward to use.

to address the OP:
what D needs to become mainstream is: (ordered by importance IMO)
1) A well defined process for standardization like RFCs (like JAVA's JCP
or python's PEP)
2) the above would lead to a proper standard library instead of the
current Tango vs. Phobos situation.
3) using (1) a GUI API should be defined such as to provide built-in
remoting procedures (similar to Adobe Air) with a defined C interface
(that's trivial in D) so that any language can be used via bindings with
the D library, in order to write real internet applications without
requiring a browser to run in. This means we need to have the GUI lib
run on the client side and transparently to the user (as much as
possible) communicates with a server side library (also with a C
interface) that is used by the server side business logic.
basically what I want is for thing like Gmail to become real "native"
applications with native GUI without a need for the unnecessary browser
chrome which frankly does not make any sense. (back button is broken,
for example)
The main difference from proprietary solutions like Air (except the
proprietary part) is that Air is built so that webapps would be able to
run on the desktop whereas I propose the opposite where desktop apps
would run in the Internet cloud (and this functionality would be
provided by the free D GUI toolkit instead of requiring advanced
programming skills from the programmers).

What do you think?
--Yigal

Perhaps that's true about the way you design web-based software, and I'm sorry if it is... but if you think they can be made elegantly you're really missing out on a large part of programming.

As for making programs more internet-ready, this is definitely useful. Of the programs I use daily, almost every single one of them has internet logic tied into it - browser, email, updates, ftp, rss news, live help, etc.

Of course, most desktop applications are intended to be used without necessary internet.  It would be ridiculous to write an archive extractor which:

1. Uploaded the archive, in full, to a remoting server.
2. Asked the server to extract it (on a queue.)
3. Polled for completion and progress updates.
4. Downloaded the resulting files.
5. Presented the user with the result.

If anything's worthy of www.thedailywtf.com, that would be.

Also, there's no need or gain really to making all of these things expose a C interface.  The trouble there is you lose things like templates, proper strings, etc.  I would hate to deal with such an API in D, and so it would have to have a wrapper.  But why?

Running on the "internet cloud" and doing remoting is not difficult. Writing an API for that would be easy.

However, if you think Google would've ever written their Gmail as a desktop client, that's just silly.  There are so many reasons they would never do that as their only/primary interface.  If you want Gmail on your desktop, take a look at Mozilla Prism.

Also, they've made the back button work, make sure you're using a modern browser.

-[Unknown]


Yigal Chripun wrote:
> Unknown W. Brackets wrote:
>> Count the number of GUI programs you use in a day.  For me, it's quite
>> a few... perhaps a dozen.  And you're right so far - distinct console
>> programs I directly run, on a usual day, is probably less (grep, svn,
>> and mysql my calculator mainly.)
>>
>> Now, count the number of different websites you visit in a day (the
>> majority of which are likely dynamic.)  How does that number compare?
>> Are these not programs?
>>
>> Food for thought.
>>
>> -[Unknown]
> Although you describe correctly the current situation, I must disagree
> that this situation is something we should strive towards. webapps are
> an abomination since they're a pile of hacks and band aids over a model
> that simply was never ment to be used in that way. It's like automobile
> companies will start adding features for cars so they would be usable on
> railroads. Since railroads are not suited for many small vehicles no
> matter what the feature would provide it will still remain somewhat
> strange and awkward to use.
> 
> to address the OP:
> what D needs to become mainstream is: (ordered by importance IMO)
> 1) A well defined process for standardization like RFCs (like JAVA's JCP
> or python's PEP)
> 2) the above would lead to a proper standard library instead of the
> current Tango vs. Phobos situation.
> 3) using (1) a GUI API should be defined such as to provide built-in
> remoting procedures (similar to Adobe Air) with a defined C interface
> (that's trivial in D) so that any language can be used via bindings with
> the D library, in order to write real internet applications without
> requiring a browser to run in. This means we need to have the GUI lib
> run on the client side and transparently to the user (as much as
> possible) communicates with a server side library (also with a C
> interface) that is used by the server side business logic.
> basically what I want is for thing like Gmail to become real "native"
> applications with native GUI without a need for the unnecessary browser
> chrome which frankly does not make any sense. (back button is broken,
> for example)
> The main difference from proprietary solutions like Air (except the
> proprietary part) is that Air is built so that webapps would be able to
> run on the desktop whereas I propose the opposite where desktop apps
> would run in the Internet cloud (and this functionality would be
> provided by the free D GUI toolkit instead of requiring advanced
> programming skills from the programmers).
> 
> What do you think?
> --Yigal

Unknown W. Brackets wrote:
> Perhaps that's true about the way you design web-based software, and I'm sorry if it is... but if you think they can be made elegantly you're really missing out on a large part of programming.
> 
> As for making programs more internet-ready, this is definitely useful. Of the programs I use daily, almost every single one of them has internet logic tied into it - browser, email, updates, ftp, rss news, live help, etc.
> 
> Of course, most desktop applications are intended to be used without necessary internet.  It would be ridiculous to write an archive extractor which:
> 
> 1. Uploaded the archive, in full, to a remoting server.
> 2. Asked the server to extract it (on a queue.)
> 3. Polled for completion and progress updates.
> 4. Downloaded the resulting files.
> 5. Presented the user with the result.
> 
> If anything's worthy of www.thedailywtf.com, that would be.

I agree. of course that would be silly. The point is to enable the
programmer to easily add internet capabilities via standard APIs and
protocols _when_the_programmer_needs_that_. If all you write is an
archive extractor by all means, just ignore the Internet-Connectivity API.
for this to work, when you do need to write a client-server program like
Gmail, the only thing you'd need to do is call a connectMe method in you
main or something to that affect, and the same GUI code you've
previously written would start magically remote calls to a server side
business logic instead of running locally.
Ideally, you could take a regular desktop application add a little
snippet of code to its initialization and it'll become client-server or
even p2p without you needing to manually serialize, deserialize and
manage the whole thing.
the other thing would be, easy installation/deployment: you click a link
in your browser and a native Gmail windows is automagically
installed/deployed/updated on the client side. the next time, you'd have
an icon in your start menu, so you wouldn't even need to find that link
in the browser.


> 
> Also, there's no need or gain really to making all of these things expose a C interface.  The trouble there is you lose things like templates, proper strings, etc.  I would hate to deal with such an API in D, and so it would have to have a wrapper.  But why?

again, the C interface is optional. If you write you code in D than use
the D API with all its neat features. The C interface is needed to make
the platform truly open. If you prefer writing your code in any other
language just use the freely available D library with you favorite
language's bindings and a C interface enables this since C is the lowest
common denominator. The Air platform for example requires me to write
flex code [or javascript with html which is wrong for real applications
IMO] and it's proprietary by nature.
a good example of this is GTK - it has bindings for many languages and
as such is very popular. compare the spread of GTK use vs other C++
based toolkits that are probably more advanced and better designed.

> 
> Running on the "internet cloud" and doing remoting is not difficult. Writing an API for that would be easy.
> 
> However, if you think Google would've ever written their Gmail as a desktop client, that's just silly.  There are so many reasons they would never do that as their only/primary interface.  If you want Gmail on your desktop, take a look at Mozilla Prism.

Mozilla prism is the exact opposite of what I'm proposing. Gmail [and
most other Google products] is written in Java. Google uses a
code-generator to produce Javascript, so even today they write it as a
desktop application. I'm sure that if you could provide the proper
conditions [i.e. a non proprietary solution based on open standards that
allows you to deploy your application automatically as described above]
the would consider to use this solution. Btw, google also provides a
gmail client for cellphones also written in Java.
Also, google wouldn't move all their code base to D just to use one
library, but if that D library had Java bindings that they could use
than this would be a different story all together.
> 
> Also, they've made the back button work, make sure you're using a modern browser.
> 
> -[Unknown]

of course the back button was just an example. the browser chrome still
doesn't make any sense. should I be able to bookmark a page in Gmail?
what if i deleted the message, than I'd get a dangling bookmark that
points nowhere?
Personally, I Prefer Thunderbird to read my Gmail and it provides a much
better and more intuitive UI.

--Yigal

Please see my comments embedded below.

-[Unknown]


Yigal Chripun wrote:
> I agree. of course that would be silly. The point is to enable the
> programmer to easily add internet capabilities via standard APIs and
> protocols _when_the_programmer_needs_that_. If all you write is an
> archive extractor by all means, just ignore the Internet-Connectivity API.
> for this to work, when you do need to write a client-server program like
> Gmail, the only thing you'd need to do is call a connectMe method in you
> main or something to that affect, and the same GUI code you've
> previously written would start magically remote calls to a server side
> business logic instead of running locally.
> Ideally, you could take a regular desktop application add a little
> snippet of code to its initialization and it'll become client-server or
> even p2p without you needing to manually serialize, deserialize and
> manage the whole thing.
> the other thing would be, easy installation/deployment: you click a link
> in your browser and a native Gmail windows is automagically
> installed/deployed/updated on the client side. the next time, you'd have
> an icon in your start menu, so you wouldn't even need to find that link
> in the browser.

You'd be surprised by how much of this is already possible by using Mozilla Prism.  I know you say below that it's the opposite of what you're proposing, but it really isn't..  the major point of this being not to try to change people who aren't going to change, but instead help people who need to do things that are complicated now.

Gmail will likely use offline storage in the near future to be available even when you aren't connected to the internet.  The standards have a switch that will flip and change everything (easily for Gmail) exactly as you say.

A lot of this takes a different mindset, though, is really what I want to say.  Writing a webapp, and making it work offline, is easy because the mindset is there.  Making it "offline-able" can be done fairly automatically in many ways, because the endpoints are clear.

In contrast, making a local-only program suddently network aware, especially in a static language, is nowhere close to as simple.  Mainly because the programmer would have to have written it with the right mindset.

In any case, I totally agree that networking, remoting, soap, etc. protocols should be made easily consumable by D programs in a standard fashion.


> again, the C interface is optional. If you write you code in D than use
> the D API with all its neat features. The C interface is needed to make
> the platform truly open. If you prefer writing your code in any other
> language just use the freely available D library with you favorite
> language's bindings and a C interface enables this since C is the lowest
> common denominator.

Okay, this is grounds for a totally separate project.  I think limiting yourself to C compatibility would really make things worlds harder and more rigid (why I use D...), and so inevitably that's outside D's realm - IMHO.

> The Air platform for example requires me to write
> flex code [or javascript with html which is wrong for real applications
> IMO] and it's proprietary by nature.

Thunderbird (which you note you like) and Firefox run very much using XUL and JavaScript.  XUL is quite similar to HTML.  This is popular because it's much easier and lower-cost, higher-maintenance than dealing with the C/C++ for the same thing.

This is a realm where D can step in, but changing the world takes time.  Anyway, it probably can't replace the blissful ease of putting layouts together using XML and stylesheets - rather possibly leverage it to compile down to D.

> a good example of this is GTK - it has bindings for many languages and
> as such is very popular. compare the spread of GTK use vs other C++
> based toolkits that are probably more advanced and better designed.

Again, separate project.  This is no longer a "D adoption" idea, but rather a grander one.  I agree that GTK and other toolkits all have good and bad points, measures of popularity, and many are a pain to use.

Honestly, I find XUL (which I really like) to be much much easier, and given xulrunner's support for GTK/Win32/Cocoa, fairly cross platform as well.

But none of this really helps D, imho.  It might be more productive to say, D should leverage XUL.  D should leverage a toolkit (written most likely by another party with time to devote to it) that is as you say. D should leverage GTK.

> Gmail [and
> most other Google products] is written in Java. Google uses a
> code-generator to produce Javascript, so even today they write it as a
> desktop application. I'm sure that if you could provide the proper
> conditions [i.e. a non proprietary solution based on open standards that
> allows you to deploy your application automatically as described above]
> the would consider to use this solution. Btw, google also provides a
> gmail client for cellphones also written in Java.

Actually, Gmail uses python for a lot of their projects too.  I don't know that its written in Java, but it probably is.

Obviously, the gmail backend is written in something than is communicated with via IMAP.  I have an iPhone with fine support for Gmail as well - and that's written in Objective C.

But the actual full interface, with all its settings and odds-and-ends, is implemented using quite a lot of JavaScript and such.  Whether this is generated by backend (e.g. XSLT and such) or not, it really doesn't matter.  This represents a lot of work from them.  In other words:

 - it represents a lot of work, no matter how you cook your eggs.
 - it could completely ruin their ad setup.
 - it ruins their "software as a service" model in a lot of ways (google apps.)
 - it represents more work to be as portable across operating systems, assuming an imperfect (read: human-made) gui toolkit.
 - it isn't as "cool".
 - it competes with Thunderbird, and other similar apps, which I doubt they are interested in.

Offline storage, etc., will likely work much better for them.


> Also, google wouldn't move all their code base to D just to use one
> library, but if that D library had Java bindings that they could use
> than this would be a different story all together.

Okay.  How does this help D?  I really don't care about Google or Java bindings or some imaginary impossible to build GUI toolkit.  I care about D.  So how does this benefit, or even affect, D?

>> Also, they've made the back button work, make sure you're using a modern
>> browser.
>>
>> -[Unknown]
> 
> of course the back button was just an example. the browser chrome still
> doesn't make any sense. should I be able to bookmark a page in Gmail?

Yes, that should work.

> what if i deleted the message, than I'd get a dangling bookmark that
> points nowhere?

This can happen with file shortcuts and symlinks.

> Personally, I Prefer Thunderbird to read my Gmail and it provides a much
> better and more intuitive UI.

I use it too.  It has a bunch of big reworks needed in its core, but that's beside the point isn't it?

I know a lot of people (business associates, clients, etc.) who use Gmail exclusively.  They love it, use it from multiple computers, and can't stand other clients.

Hate webapps or not, you need to understand... some people will describe their computer as a means to getting on the internet.  With things like Google Docs, you might be surprised at how little *some* people will use computers for, other than a web browser.

Whatever is done with gui apps, no one can deny that server-side apps have a lot of weight right now.  Word processors, mail clients and servers, tax software, asset management, ecommerce, contact management, task management, a lot is moving to the web.  Many firms are finding they need to develop a web-based version of their GUI software (my company has contracts open for this currently.)

D cannot ignore this.

Last - take another look at my archive extraction example.  Change your perspective.  Think about it as a server-side app.  Think about the remoting happening on a couple hundred cheap boxes (exactly like Google uses.)  Think about the source being a task manager that flags broken servers and reassigns tasks (again exactly like Google does.)  Now think about processing 100 reasonably large archives per second.

Suddenly this ridiculous example I gave, for GUI, doesn't (or at least shouldn't) seem anywhere close to as silly.

It requires a different mindset.  D cannot afford to ignore this either.

-[Unknown]