>> 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

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

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]

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.

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

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

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