An explanation re Erlang GUI project
Fri Mar 28 05:09:45 CET 2003
The reason I've become increasingly critical of Jay's approach is
because I like it, and I don't want to see it go down the garden path.
Why is development on TUNES so slow? Because TUNES is a Useful, Not
Expedient, System. 'Nuff said. It will quite possibly never
I don't want to see the same thing happen to an Erlang GUI.
Two things can kill a project: developing too quickly and developing too
slowly. The former way, you run yourself into a dead end by having
code that works - sort of - but is unmaintainable, and breaks
mysteriously on every new change. The latter way, you run yourself down
the garden path, where you never write any worthwhile code because you
can never settle on a design that's good enough.
Plenty are the languages with which you can crank out code, and plenty
are the languages with which you can write beautiful code. Rare is the
language with which you can crank out beautiful code...
I guess what I'm saying is that if tomorrow someone were to go and
prototype their impression of a simplified version of Jay's level 1
(z-ordering, clipping, with stubs for alpha) using OpenGL as level 0, I
wouldn't shed any tears. A prototype would provide feedback, which is
looking more and more needful, as it would lead to more informed choices
as to the project's direction, which could in turn provide momentum
towards actually producing a finished product. In the absence of
feedback, it's too easy to get stuck daydreaming. Plus there are
certain estimations I'd like to make, such as, what kind of performance
would be desirable for running the thing decently? All the nice
features aside, that's probably the most important factor - no one wants
to run a GUI that's a dog, no matter how usable it is.
Unfortunately I know next to nothing about OpenGL and, not being a
graphics programmer, I get the impression that I'd have a lot to learn
if I wanted to give it a shot.
More information about the erlang-questions