Sean Kelly wrote:
> It's original aim was to be a complete replacement, but a lack of community participation changed the focus a bit. 

Don't take it as lack of interest! Maybe it's just that not everyone felt comfortable submitting their code (because theirs "wasn't up to par", or whatever other personal reason). The existing Ares code does set the ante pretty high, after all.

(Additionally, of course, there was the "marketing mishap" of presenting it as a one-man project, whereupon maybe some potential contributors may have felt that their code would be subsumed. (Not intentionally, but as  a result of the process.)

> Ares is now really just a minimal framework on top of which a
> standard library may be built.

Now that does sound cool!

It follows, that there should be a project (on dsource, for example), that aims to build the "end programmer API" on top of Ares.

I can't wait to hear about it!

---

Being "a minimal framework on top of which [...]" is actually an excellent position for a library: this gives the freedom for the original developer to fine tune the lib till it is not only rock solid, but diamond solid.

Since this also (IMHO) implies that it is not for the regular programmer (rather it would be for the "library writers"), one could even assume additional freedom, (e.g.) using harder to understand APIs if they can bring a more coherent, efficient, or elegant structure to Ares, skip lots of the "user-land" functions (which, of course bring usability and ease, but many of which are 20% additional utility at 80% of the effort), thus giving more time to do the "right stuff, and do it right".

The Ares-client libraries [meant to be used by the regular programmer] could then take care of the many-and-mundane-to-write APIs that make a library "complete" or "mature", as seen from the receiving end.

---

OT: this reminds me of a joke, that I personally don't even find a joke:

"When in doubt, insert a new abstraction layer!"

John Reimer wrote:
> Lionello Lunesu  
>> I'd prefer sourceforge, where it will be seen by more people.
>>
>> dsource is nice and has certainly done a lot for D, but it makes us look  like some sort of cult.
> 
> What?!!!

LOL!

I'm not entirely sure he doesn't have a point.

(At least partially.)

John Reimer wrote:
> On Tue, 17 Oct 2006 03:04:32 -0700, Jari-Matti Mäkelä <jmjmak@utu.fi.invalid> wrote:
> 
>> John Reimer wrote:
>>> As a GUI framework,
>>> however, SWT seems comprehensive and powerful.  It's just not a
>>> well-recognized or an easily learned solution.
>>
>> The only programs using SWT that I know of are Eclipse and Azureus. They're both slower than anything I've ever seen (including most of the Swing using programs). It takes a forever to start either of them, changing tabs/perspectives is just like watching a slide show and writing text has an average lag of 1-2 seconds. Maybe it's because I'm only running a 2.x GHz AMD with 1 GB of RAM and a KDE desktop, but IMHO apps on my old PC (Pentium 100, 32 of RAM, Win98/X11+Fluxbox) are way more responsive than any SWT app on the newer box.
> 
> 
> Perhaps... but I don't find the Win32 DWT port that way at all.  It's
> quite snappy. :)
> And my experiences with Eclipse are quite contrary to yours as well.

There was at least some discussion in Slashdot over two years ago:

http://developers.slashdot.org/comments.pl?sid=92172&threshold=1&commentsort=0&mode=thread&cid=7929925

"First off, SWT only performes well on windows, and stack on top of that that the principal native abstractions are taylored to a win32 environment. Based off of that it is easy to see how SWT performes quite nicely on Windows.

Elsewhere it sucks. MacOS, GTK, photon, Motif. Even porrly writeen swing programs outperform on those platforms."


IMO it's a bit sad to see that SWT has sucked on everything else but Windows for a very long time now. I personally do not want to support anything related to GTK or SWT because they're technically very low quality. I know many companies embrace SWT because the license is quite liberal, but still it's a sign of apathetic 'Eat shit' attitude to force clients to use stuff that makes their computers vomit in order to save a few hundreds of bucks in licensing costs.

Maybe in the future they'll release SWT under EPL and QT will be available under GPL 3.0 (huge maybe) - then it might become possible to use QT as a backend for SWT and DWT. IANAL, these licensing things are hard to understand.

For the time being Harmonia is IMHO the best alternative as an official GUI library. I will start using it immediately after it is ported to Linux.

Georg Wrede schrieb:
> I think an API competition should definitely be in two stages:
> 
>  - compete on the most useful and best spec
>  - then compete on the most elegant implementations of the winning spec

Sounds reasonable to me.

Nils

Georg Wrede wrote:
> Kristian wrote:
>> So maybe we should have contents on APIs first. When we got the base  structure right, we can make competitions on parts (e.g. functions,  classes) that should be efficient, or hard to implement. Bulk (trivial)  stuff can be implemented outside the competitions later. Also, API  implementations should include documentation.
> 
> I think an API competition should definitely be in two stages:
> 
>  - compete on the most useful and best spec
>  - then compete on the most elegant implementations of the winning spec

Design, then code, is the development approach that everyone advocates. It's also the approach nobody uses <g>. Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.

Walter Bright wrote:

> Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.

Who is 'we' in this case?

Following your statement a very tiny set of coworkers might avoid desaster.

But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.

Karen Lanrap wrote:
> Walter Bright wrote:
> 
>> Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.
> 
> Who is 'we' in this case?
> 
> Following your statement a very tiny set of coworkers might avoid desaster.
> 
> But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.
> 
> 
> 

Iterations are always done.
Even in big companies. *We* always try to start to plan ahead. But in
each phase a needed "redoing" of the previous phase is a possible. It
might just be that you do understand the domain better after spending a
year in it. You gain new insights, your scope changes, ...
Do you know *1* project where no backtracking was ever needed?
True, in a truely big project the planning ahead is much more
elaborated. Like is the cost for backtracking on some assumptions or
chosen solution.

roel

Karen Lanrap wrote:
> Walter Bright wrote:
> 
>> Design/code/design/code... iteratively is the real process.
>> There's a good reason for that - too often when implementing a
>> design we discover that the design won't work or could at least
>> be improved. 
> 
> Who is 'we' in this case?
> 
> Following your statement a very tiny set of coworkers might avoid desaster.
> 
> But your habits of evolving the D programming language make it hard to believe that under such management principles a project of about 1000 man years would come to success.

This sounds like a troll it's so far off base.

I only know of one "official" software design methodology and it's called "the waterfall model".  And the key point is that you have many different kinds of iterations between the different stages of software development:

from requirements
     to design
        to implementation
           to testing
              to delivery
                 to maintenance.

You generally flow down the steps from top to bottom, but at *any* stage you can get loops back up higher.  And in particular, you're never in just one stage.  Things can be happening in every stage simultaneously.  After delivery you frequently get feedback from your customer telling you that what you designed doesn't actually meet their requirements (often because their original requirements were too vague and they didn't actually know what they wanted either) --> back to requirements gathering.  Or testing reveals a bug --> back to implementation (of that one part).  Implementing the fix reveals a design flaw --> back to design (of that one part), etc.

Or maybe we just misunderstood you?

--bb

Walter Bright wrote:
> Georg Wrede wrote:
>> Kristian wrote:
>>> So maybe we should have contents on APIs first. When we got the base  structure right, we can make competitions on parts (e.g. functions,  classes) that should be efficient, or hard to implement. Bulk (trivial)  stuff can be implemented outside the competitions later. Also, API  implementations should include documentation.
>>
>> I think an API competition should definitely be in two stages:
>>
>>  - compete on the most useful and best spec
>>  - then compete on the most elegant implementations of the winning spec

I see two more stages preceding your two:
  -- gather proposals for cool and useful libraries & pick one
  -- gathering requirements for selected proposals (nothing formal, just  discussion on the list to see what people who might use it want out of it, like "I want to be able to connect gui fields to a database backend")

> Design, then code, is the development approach that everyone advocates. It's also the approach nobody uses <g>. Design/code/design/code... iteratively is the real process. There's a good reason for that - too often when implementing a design we discover that the design won't work or could at least be improved.

So in that case, just don't require that people stick to the spec in stage 2.  The spec competition gets the ideas out there, and gives the community a chance to give feedback on them.  If the process is any good then the writer of the implementation will need pretty darn good justification for diverging from the spec.  Otherwise people will just say "the spec's way was better".

Sounds cool.  But it seems like a huge waste of coding talent to have everyone concentrate on one particular library and then throw away N-1 out of N of the implementations resulting.  Why not get the list of proposals then say the competition is just to come up with an implementation of the best and most useful thing on that list, period.

Regardless of who wins, the range and variety of code that gets written that way will likely exceed that from a race-to-write-lib-x competition.

--bb

Lionello Lunesu wrote:

> Unknown W. Brackets wrote:
>> If it can't be put in sourceforge, surely it could be put into a versioning repository (svn, cvs, etc.) of some sort.
>> 
>> Since it seems like digitalmars.com has a fairly reasonable hosting arrangement, this might even be possible using the current server and hosting company.
>> 
>> I think this has come up before, and Walter wasn't really interested in that.  I've really found version control systems as being a huge way to improve software quality and developer cooperation, though (even if only Walter had write access.)
>> 
>> -[Unknown]
> 
> I'd prefer sourceforge, where it will be seen by more people.
> 
> dsource is nice and has certainly done a lot for D, but it makes us look like some sort of cult.
> 
> L.

I guess more non-D people might come by for projects at sourceforge, but then a project there don't get visibility until activity grows (and among the 1 million projects there, some have quite a lot of activity).

I totally disagree with the other statement.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi