Benjohn Barnes wrote:
Benjohn Barnes wrote:
20 years ago, the subject line would have drawn me a line across one
of my screen's diagonals. Ruby is awesomely more powerful than BBC
BASIC, but why no trivial graphics support?
Because there is no trivial way to make graphics facilities
platform-independent. You may notice that Ruby has native libraries
graphic interfaces, but these are also not platform-independent.
those graphic interfaces, you can make drawings, but you then
the program anywhere but on the original platform (with some
It may not be trivial, but it's hardly difficult. There must be
dozens of Ruby modules that have varying implementation by platform
(sockets, for example)?
Yes, but sockets don't compare well with a graphic interface. Sockets talk
to the network, which all environments want to do in the same way. Graphic
interfaces talk to the hardware and the OS, which have less in common with
each other than sockets do.
Ruby itself pulls the feat of quite nicely
too. Note that I'm not talking about taking full control of graphics
hardware and exploiting all features. It's just really basic drawing
support that would be good.
And it exists, and you can easily write a drawing program, but it won't be
My two requirements are that it should be really easy to draw, and it
should be possible to do so interactively (from irb).
Well, "irb" has a special purpose, and being a user interface for a
program isn't the purpose.
I'm not suggesting that irb needs changing. I'm suggesting that the
design of the graphics API I'm hoping for should be "irb friendly",
which I believe it will be if well designed.
I gather that you want is user friendliness, and you have hit upon irb's
friendliness as an example for immediacy of results. You appear to want
your user to be able to enter instructions interactively and see the
results drawn. For this, "eval" would do nicely, better than irb, because
the latter has a rather specialized purpose. But this doesn't address the
more important issue of graphic interface.
Thus, using irb, I
should be able to issue a commands and see the result. I shouldn't
have to create contexts and windows, program up call backs, cache my
drawing commands somewhere ready for a re-paint and string the lot
But yes, you would have to do that, at least once. You would have to so that
because, apart from Logo, there are few ready-built graphic facilities such
as you are describing. You would have to write the program, then you would
have to integrate a graphic interface. And in the worst case, you would
have to perform the second step for each platform of interest.
I've not even found something that merely works on the Mac, yet alone
This addresses the state of the art. A suitable "bicycle" analog is Ruby as
we find it today, which is quite remarkable in and of itself. But from my
perspective as a computer programmer in 2006, you are actually asking for a
I apologise if I sound exasperated Paul, and thank you for replying.
It's not like I'm asking for a flying car here though: I just want my
This is why computer programming hasn't withered away as a profession, even
though some might argue that it should.
On 9 Sep 2006, at 09:20, Paul Lutus wrote: