D adoption prerequisites

[Unknown W. Brackets]

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]