On Jan 4, 2008, at 2:53 AM, why the lucky stiff wrote:
On Thu, Jan 03, 2008 at 11:49:27PM -0500, Mark Baran wrote:
Anyway, so far I have only two gripes with shoes. I'm developing
on Mac
and I was wondering why the launcher exists. Code that I load any
other
way except through the file dialog effective becomes unreachable and
orphaned; I unfortunately have to murder the process and scuff my
shoes so
to speak with a killall -9.
Oh, hey, glad to have you, Mark.
I have this same gripe with Shoes and I think we're all pretty sick
of this bug. I want to call this thing from the commandline! The
problem is in Shoes.app/Contents/MacOS. If you change the line
"<string>shoes</string>" to "<string>shoes-bin</string>", then the
commandline works but the file open dialog is dead.
This would be the perfect place for a gem version of shoes. Hobbyist
programmers are more likely to use the cli. Avoiding the hideousness
of MacOS's ugly program startup routines is one glorious benefit to
packaging Shoes as a gem, independent of the MacOS ecosystem.
I could really use some help cracking this one. I've tried using
LSEnvironment to set all the environment variables: no good. OSX
has been an extremely frustrating environment!
I think the VLC people have solved this on Mac, but their clivlc has
stopped working on my new fancy Leopard OS. I'm going to look at
their solution anyway and see what hacks they played and if any are
useful with regard to Shoes. Hopefully, there the solution lies,
though you might have already barked up this tree.
Secondly, is there a really pressing reason why this hasn't been
packaged
as a RubyGem, even if to only be served locally from why's repo and
not
generally distributed yet.
Well, I really only have two reasons for writing Shoes: (1) to
act as the new runtime for Hackety Hack and (2) as an experimental
programming platform for beginners. I don't think Shoes appeals at
all to GUI programmers or to the marketplace. I don't even use the
acronym GUI anywhere in Shoes docs or materials.
I want Shoes to get in the hands of hobbyists and kids!! (I hope all
of you do as well?)
I think RubyGems is a fine thing, but I'd lose alot of my advantage
if I packed Shoes as a gem.
* The Shoes installer includes Ruby, the Shoes stuff, and any other
libraries I want to pre-package (sqlite3 and hpricot).
* The installer is a single download of ~3MB. Most Ruby installers
are already much bigger than this. (Recent Win32 installers are
23 MB!!)
* The .shy format (compressed Shoes apps) couldn't have a file
association through RubyGems.
* I will be merging sandbox soon, which will require a custom build
of Ruby and prohibit use of RubyGems prior to loading Shoes.
I don't see both distribution channels mutually exclusive. For those
of us with a Ruby installation already, the Gem provides an easy way
to manage the library, while the installer seems as though it will be
antiquated by Hackety Hack. I can see the Shoes platform as having a
sightly wider appeal than just to absolute beginners, and this is
really asset. Shoes could be Rails of GUI design: fast, well
designed, and attractive to every programmer who needs to hack up a
quick little project for a friend or two.
A beginner's only toolkit is likely to detract from its overall
appeal: a new programmer would prefer to invest his or her time into
a platform into which they can grow. The label of "beginner's only"
is likely to be more of detriment: nobody wants to be a beginner
forever! Ease of use and ultimate utility should be complements
rather than supplements.
One of the best was I can see for primping Hackety Hack to students is
to make sure that some really cool apps are part of Hackety Hack from
the very beginning, stuff even kids can't help but want to abuse. To
enable this avenue of growth, Shoes could be presented to a certain
audience as the desktop equivalent of Rails, allowing for rapid
application design and fun at the same time. Wouldn't it be really
very cool if they could start extending real programs from the start?
That would open the Hackety Hack door to a whole other side of the
programming world, the pragmatists.
Sandbox itself could have multiple uses as well. Although I know it's
probably being deployed to making programming safer and more stable
for the next generation, it sounds like a great way to build and
design plugins too. I don't really see the shy format being a
limitation. Wouldn't the shy format simply be data for shoes, an
argument you can pass to the command line? Sure, there should be a
repo of shy programs but they should be managed by a special manager
within shoes.
It would be nice to make Shoes a better Scheme than Scheme, an
incredibly good teaching platform, yet a decent platform for actually
making stuff of happen too! I'm all for it. The gripe all my friends
who are forced to learn Scheme for college is that they have no exit
strategy: once finished with scheme, they feel they have nowhere else
to play with programming, and like the tuba in their garage, slowly
give up what really is a powerful skill. I would love to see Hackety
Hack to avoid this pitfall.
I totally welcome arguments to my approach, especially since I'm
becoming increasingly convinced that Shoes' independence is a huge
strength. I previously was okay with doing a gem, but I think it
would hurt the project, you know?
You can still load gems through Shoes (esp. using the `fetch_gem`
stuff that's in lib/shoes/cache.rb which I developed for Balloon)
and I hope to have a shoes-gem command which will install a gem into
your Shoes distro.
_why
Mark Baran
