D adoption prerequisites

[Yigal Chripun]

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