OpenEuphoria

Widgets-R-Us

• Posted by David Cuny <dcuny at DSS.CA.GOV> Apr 16, 1998
• 986 views

------ =_NextPart_000_01BD695C.22FDAD80
Content-Transfer-Encoding: quoted-printable

Jiri wrote:

> one of about a thousand Euphorians...=20
> attempting to devise a simple system of widgets.

Let's see. How many people does that make *currently* working on a DOS =
set of widgets?

1. Jiri
2. Irv
3. Jeff
4. David <- that's me 

And then there are the people who have posted their toolkits in the =
past:

5. Rod Damona
6. Jim Lacovara
7. Matthew Whitehead
8. Graeme Burke
9. Daniel Berstein
10. Mike Fowler

Looks like there could be a group project here.


Negatives
----------

1. Each toolkit sets out to solve a slightly different problem, so there =
may not be agreement on what problem is being solved.

2. Each programmer (rightly) feels that they have the best approach. =
After all, it's the best tool to solve their particular problem.

3. Project coordination is a difficult thing to manage, especially over =
the internet. And it's easy for feelings to get tweaked.

4. Each person has probably devoted a fair amount of work to their own =
toolkits, and is "just about ready" to release it.

5. Failure for a project of this complexity is a real possibility.

Positives
----------
1. As the "official" Euphoria DOS interface, people would use it. As it =
stands now, there are a number of different tools available, but few =
people seem to be using them.

2. People could add to the widget set because:

   A. It would be well documented.
   B. The interfaces would be well known.
   C. It would, by necessity, be modular.

3. More input often leads to a better design. Some of the best Euphoria =
coders are duplicating effort here, working on the same type of problem.

4. People could specialize in what they wanted to do, and leave the =
"boring stuff" to people who liked to implement that kind of thing.


Comments?

-- David Cuny

PS: Of course, since the project would be split into so many small =
files, it would help if there were some namespace tool to help avoid =
collision of routine names...

------ =_NextPart_000_01BD695C.22FDAD80