• Koroskin Denis (25/25) Apr 18 2008 I believe there are at least 4 steps that we need to take for D adoption...
• Robert Fraser (14/22) Apr 18 2008 This is the only one I can comment on. With regards to Descent (there
• Unknown W. Brackets (10/11) Apr 18 2008 Count the number of GUI programs you use in a day. For me, it's quite a...
• Koroskin Denis (6/17) Apr 18 2008 Right! We just don't develop these in D (for now). It will be possible, ...
• Unknown W. Brackets (7/31) Apr 18 2008 Speak for yourself. I do web-based stuff in D already.
• Paul Findlay (14/19) Apr 19 2008 Exactly. Can I quote someone from the sendero project: "[t]he allure beh...
• Unknown W. Brackets (10/32) Apr 19 2008 More importantly, whimsical dreams mean nothing against experience.
• Yigal Chripun (35/44) Apr 19 2008 Although you describe correctly the current situation, I must disagree
• Unknown W. Brackets (30/79) Apr 19 2008 Perhaps that's true about the way you design web-based software, and I'm...
• Yigal Chripun (48/86) Apr 19 2008 I agree. of course that would be silly. The point is to enable the
• Unknown W. Brackets (94/146) Apr 19 2008 Please see my comments embedded below.
• Yigal Chripun (52/241) Apr 20 2008 I didn't mean that we need to limit ourselves to C compatibility, rather
• Roald Ribe (5/18) Apr 20 2008 You are describing Java / Webstart...
• Yigal Chripun (16/37) Apr 20 2008 a) I've described the general concept, not a specific implementation.I'm
• Hans W. Uhlig (6/36) Apr 18 2008 Perhaps a library for reading D source code. and outputting in
• Scott S. McCoy (6/14) Apr 20 2008 I totally agree here.
• Lars Ivar Igesund (28/45) Apr 20 2008 Most such mistakes will not be identifiable until after implementation a...

"Koroskin Denis" <2korden gmail.com> writes:

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?

Robert Fraser <fraserofthenight gmail.com> writes:

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!

"Unknown W. Brackets" <unknown simplemachines.org> writes:

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" <2korden gmail.com> writes:

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" <unknown simplemachines.org> writes:

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.

Paul Findlay <r.lph50+d gmail.com> writes:

 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.

Exactly. Can I quote someone from the sendero project: "[t]he allure behind
a framework is that it will accomplish some sort of magic which makes
developing an application so much easier".

What I don't get is this, "we just need this and then we will get this
result" as if adding features to D (language semantics or libraries) is
deterministic. Already enthusiasts can do whatever they like (even if not
from scratch, D links to C - and then every language through that torturous
route :) ) what should be brought to the discussion is what can be done to
increase the chances of successful development with D (which is
probabilistic in nature). For me, bringing useful libraries to the table
like the Tango guys, Christopher E. Miller (with DFL) etc. have done, or
even half hacked upon work, is much more useful than a laundry list of
features.

 - Paul

"Unknown W. Brackets" <unknown simplemachines.org> writes:

More importantly, whimsical dreams mean nothing against experience. 
What we need is to foray into the things we need - and then build them 
so everyone has them.

But isn't that what programming is (on a grander scale)?

It's true that libraries aren't everything - tools help a bunch too, as 
do whimsical dreams.  But I think libraries drive languages, personally. 
  If I were to use a language other than the one I use now - that's why 
I'd do it... not because of its features or even syntax...

-[Unknown]


Paul Findlay wrote:
 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.

 Exactly. Can I quote someone from the sendero project: "[t]he allure behind
 a framework is that it will accomplish some sort of magic which makes
 developing an application so much easier".
 
 What I don't get is this, "we just need this and then we will get this
 result" as if adding features to D (language semantics or libraries) is
 deterministic. Already enthusiasts can do whatever they like (even if not
 from scratch, D links to C - and then every language through that torturous
 route :) ) what should be brought to the discussion is what can be done to
 increase the chances of successful development with D (which is
 probabilistic in nature). For me, bringing useful libraries to the table
 like the Tango guys, Christopher E. Miller (with DFL) etc. have done, or
 even half hacked upon work, is much more useful than a laundry list of
 features.
 
  - Paul

Yigal Chripun <yigal100 gmail.com> writes:

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" <unknown simplemachines.org> writes:

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

Yigal Chripun <yigal100 gmail.com> writes:

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

"Unknown W. Brackets" <unknown simplemachines.org> writes:

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]

Yigal Chripun <yigal100 gmail.com> writes:

Unknown W. Brackets wrote:
 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.
 

I didn't mean that we need to limit ourselves to C compatibility, rather
provide an optional C wrapper to the D library which other languages
could use to create bindings.

 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.

using a markup language to design the GUI which then gets compiled to D
is a good idea and indeed we can leverage existing formats like
XUL/MXML/XAML. What I specifically am against is mis-using HTML for that
purpose since HTML is a language to describe documents and not apps.
 
 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.

I agree with this point, as said above.
 
 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.
 

I mentioned GTK only for the fact that many languages have bindings for
it which makes it almost a de-facto standard. I'm not proposing writing
such bindings but rather make it easy for developers who use other
languages to develop those bindings for themselves. GTK developers do
not maintain the various bindings. D for example has a gtkD project
maintained by D developers. This is one of the currently main toolkits
used in D [along with DWT]. D doesn't have QT support currently and
probably wouldn't have it in the near future either...
This ease of creating bindings is good for D since it'll spread the use
of this library and hence familiarity with D.
look at Ruby - it's a very nice language. but only when RoR was invented
Ruby gained a big surge in popularity and acceptance and I'm sure many
RoR developers that now feel comfortable with RoR and Ruby will consider
using Ruby for other projects as well.

D would benefit greatly from such a killer application that would bring
many new developers to D.

 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.

The above is exactly my point. if your code is D only no one will use it
no matter how great it is since they already have large codebases and
it'll take a lot of work and money to rewrite everything for D. Thus,
bindings for other languages provide a bridge for other developers to
start experimenting with D without throwing away what they already have.
At first they'll just use an already compiled D library with their
language bindings and as soon as they need to add features to it, or
just curious to look under the hood they'll see how great D is.
 
 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?
 

see above.

 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.

that's exactly my point. I want to provide these companies an easier
route to web presence with compiled language instead of fighting
javascript that works differently on each browser. The benefit for the
users would be a richer interface with all the same benefits webapps
currently provide.
When you use Gmail, the browser downloads the interface component which
is a javascript script and than runs it. The same would happen with my
proposal, only in my proposal that would be either already a compiled D
component or a D source file that would be compiled on the fly.
just like you currently need a client runtime to run that javascript UI
component [The web browser] you'll need a run-time component to run D
code. this can be done the same way Adobe did with AIR - if you do not
have it it'll be automatically downloaded with the first program you try
to run. if you have an older version it can be automatically updated.
all you need to use Gmail is navigate to the right URL, conversely all
you need to run an Air app (if you haven't installed it) is navigate to
the right URL/click a link. This doesn't need to affect your working
habits as a user.

 
 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]

Roald Ribe <rr.nospam nospam.teikom.no> writes:

Yigal Chripun wrote:
 When you use Gmail, the browser downloads the interface component which
 is a javascript script and than runs it. The same would happen with my
 proposal, only in my proposal that would be either already a compiled D
 component or a D source file that would be compiled on the fly.
 just like you currently need a client runtime to run that javascript UI
 component [The web browser] you'll need a run-time component to run D
 code. this can be done the same way Adobe did with AIR - if you do not
 have it it'll be automatically downloaded with the first program you try
 to run. if you have an older version it can be automatically updated.
 all you need to use Gmail is navigate to the right URL, conversely all
 you need to run an Air app (if you haven't installed it) is navigate to
 the right URL/click a link. This doesn't need to affect your working
 habits as a user.

You are describing Java / Webstart...
*A lot* of catch up to do...

And in Java they have security with signed applications.

Roald

Yigal Chripun <yigal100 gmail.com> writes:

Roald Ribe wrote:
 Yigal Chripun wrote:
 When you use Gmail, the browser downloads the interface component which
 is a javascript script and than runs it. The same would happen with my
 proposal, only in my proposal that would be either already a compiled D
 component or a D source file that would be compiled on the fly.
 just like you currently need a client runtime to run that javascript UI
 component [The web browser] you'll need a run-time component to run D
 code. this can be done the same way Adobe did with AIR - if you do not
 have it it'll be automatically downloaded with the first program you try
 to run. if you have an older version it can be automatically updated.
 all you need to use Gmail is navigate to the right URL, conversely all
 you need to run an Air app (if you haven't installed it) is navigate to
 the right URL/click a link. This doesn't need to affect your working
 habits as a user.

 
 You are describing Java / Webstart...
 *A lot* of catch up to do...
 
 And in Java they have security with signed applications.
 
 Roald

a) I've described the general concept, not a specific implementation.I'm
well aware of Java's implementation but it hasn't caught up because of
several major flows in its design. Adobe's Air seems at first somewhat
better, but it has its own flaws too like the no-right click allowed
issue (have they fixed this already?)
I can list other similar implementations: Adobe Air, Mozilla Prism,
gravityzoo, and newio [you can find all of then via Google].
b) the whole idea of signed applications is flawed IMO. It's no
replacement to proper security. just like I would want my image viewer
to only show images and ask for permission to access anything else, I
would want my RIA to ask for permission for specific questionable
actions instead of demanding full trust and complete access to my system
to work. in that regard, Adobe did a much better job by actually
defining what an Air app can and can't do without permission.

-- Yigal

"Hans W. Uhlig" <huhlig gmail.com> writes:

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?

"Scott S. McCoy" <tag cpan.org> writes:

On Sat, 2008-04-19 at 01:58 +0400, Koroskin Denis wrote:
 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

I totally agree here.

A standardized general library, is incredibly useful for any proramming
language.  But great care has to be taken in creating such a thing.
Since the mistakes end up outliving everyone involved with it's
inception.

Lars Ivar Igesund <larsivar igesund.net> writes:

Scott S. McCoy wrote:

 
 On Sat, 2008-04-19 at 01:58 +0400, Koroskin Denis wrote:
 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

 
 I totally agree here.
 
 A standardized general library, is incredibly useful for any proramming
 language.  But great care has to be taken in creating such a thing.
 Since the mistakes end up outliving everyone involved with it's
 inception.

Most such mistakes will not be identifiable until after implementation and
usage has begun (which is my main gripe with the OP) - however,
standardization is important to various degrees.

Standardization is alpha and omega when it comes to definition of what is
needed for software to interconnect, typically data formats and protocols.

Standardization is important for interfaces as they more easily allows for
3rd party plugins.

Standardization is nice to have for API's as it reduce the work load for the
users.

Since standardization only has a relative importance for API's - you tend
not to find all that many standards in that area - as opposed to for
interfaces. The reason is that it is fairly rare, except for possibly the
most basic of functionality, that one API fits them all - and thus
alternatives doing it this way or that way - will always pop up around the
standards available. In programming, standard API's (especially in relation
to standard libraries) mostly only serve to keep the number of external
compile time dependencies down - and even that seems to become less
important these days with the relative ease with which dependencies can be
automatically downloaded (I don't say that D necessarily have this
perfectly honed yet.)

In conclusion, trying to standardize an API is good - but believing that you
will be able to find the perfect one up front is totally unrealistic.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango