Joerg F. Wittenberger wrote:
Brandon Van Every wrote:
Chicken wouldn't have half the eggs it does if the non-Chicken
Scheme community had taken that position. Fortunately for us,
they did not.
Which half? My world is OpenGL and C FFIs. I don't see any
interloper eggs helping out here. It's one thing if your task is pure
Scheme, quite another if your task is OS interfacing.
Brandon, please don't take things personal. Don't downplay others
contributions just because you don't know yet where you might need
them.
This conversation does remind me that I haven't properly looked about
for Scheme-based OpenGL windowing toolkits. I don't recall any from
previous searches, other than SDL bindings, but it has been awhile since
I looked.
So let me tell you something: a chicken specific gui toolkit, which
somehow wraps opengl and that it - that's something I don't have time
for.
Right, but that's all that 3D OpenGL game developers need.
Collaboration isn't always beneficial, especially in the abstract. We
only need to get a simple job done. It's also a mostly Chicken-specific
job, binding to low level OS interfaces. You want to do something much
more complicated and far reaching. The complication of your job, far
outweighs the resources you're offering to do the job. So from my
standpoint it is a loss. There is no benefit in worrying about the
greater Scheme community for this particular task.
Once we have our base layer working, and it matures, then presumably
people will be writing much more pure Scheme code on top of it. Then
maybe it is worth it to someone to refactor for other Schemes. Or maybe
it isn't. There's always this question of *labor*. Who will extend and
maintain the code? People don't just grow on trees to do all these
porting and maintenance jobs. In fact, most people don't like
maintaining "other people's code." Attracting and keeping labor is a
community formation problem. Strategically, I think Chicken is far
better off trying to pull people into its fold, than trying to work with
the Scheme community at large. That may sound like a matter of
religion, but Chicken is tangible. Scheme isn't, when you're talking
about OS-specific stuff.
What in 3D-land would really bind up a community? I think a high
quality 3D engine would. I think also, such an engine would inevitably
have to succeed with 1 Scheme, in this case Chicken, before even
remotely considering the possibility of porting it to other Schemes.
The bar for success in a 3D engine is very, very high. Everyone and
their mother's uncle has a 3D engine out there. What matters is if
someone ships several commercial games with the engine. As you can
imagine, by that time the engine is a *big* project. Porting it to
another Scheme is a *huge* refactoring effort. Probably unjustifiable,
and probably uninteresting to most people out there.
However I've got the feeling that there where some persons, who
listened, who - at least partially - agreed with my concerns.
Listening and agreeing is one thing. Hammering out workable specs that
address multiple people's concerns, and actually cutting code, is quite
another. I have low expectations for you uber-GUI guys, frankly.
You're all brilliant, you've all got wonderful ideas. But first you're
going to get distracted by a lot of design stuff. Then some people are
going to drop out, because the problem isn't interesting to them
anymore, it's too much work, financial priorities rear their ugly heads,
the design strategy isn't meeting their goals, or whatever. Then what
you're going to actually get done, is either 1 binding to 1 extant
toolkit, or 1 "from scratch" uber-simple toolkit. You may get part of a
2nd binding done, as proof of the backend concept. But it won't be very
good because you won't have labor that's interested in doing the job.
This is the elephant in the room about deferring problems through
backends: those backends will never get done. You'll end up with 1 "de
facto" backend.
Show Me The Labor.
I wish you all the success with the gui toolkit. If you are
interested, I might take some time to review you design.
For clarity: Thu, John, and myself are not working on the kind of GUI
toolkit you're talking about. We're not doing widgets. We're just
putting OpenGL windows up on a screen, so that game developers can get
started with something productive. We're not going to try to make
events invisible to the programmer. We will facilitate a developer who
wants his own control over event loops, callbacks, and other event
passing mechanisms. Game developers usually hate it when the toolkit
gets in the way of how they want to do the event handling stuff.
Ergo, there's going to be precious little design to comment on. That's
why the job is doable with 3 people. More than doable. Our decisions
amount to, should we write this mostly from scratch, stealing platform
specific snippets from CPW and/or GLFW? Or should we bind SDL? Or is
there an OpenGL toolkit for another Scheme that we've overlooked?
Just post it
to the chicken list when you feel ready to take discuss questions.
I'll comment on if I feel it's not wasting my time.
I'm going to assume you meant well with that last comment. In a similar
vein, we're not worried about people's comments. 3 people is more than
enough to design *and implement* such a simple project. We'd of course
welcome anyone who wants to actually bang out code. Not all problems
are design and infrastructure: we'll need demos, tutorials, and a
webpage also.
Cheers,
Brandon Van Every
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
