While I enjoyed reading The GNU Extension Language, a case for using Guile (a Scheme implementation) as GNU's extension language, I couldn't help but think: oh, if it was only that simple. If only you could make a reasoned and intelligent argument and that would make it so. But alas, when programming languages are involved, inevitably, these things boil down to a popularity contest. And one thing Scheme doesn't have going for it is Popularity.
So, what should the Scheme and Guile community do? While I love the evangelism involved in getting out there and spreading the word about how powerful a language Scheme is, that's never enough. Part of me thinks that the best option is to embrace JavaScript - with first class functions, and mostly lexical scoping, it's kinda-sorta a Scheme with a more user friendly interface. Maybe there's a possibility of growing JavaScript in a way that it's even more Scheme like (like, say, having better support for tail calls). Maybe it's the ideal stepping stone to Scheme?
But, realistically, that's going to leave most Scheme fans wanting far more. No, I think there's a better and more likely to succeed approach.
Consider The Gimp - one would think that it would be nearly the ultimate Scheme success story. The project itself is successful, and Scheme has been embedded in it from the beginning. Heck, it even has a slick name for the Scheme add on: Script-Fu. How can you not get excited about that?
But, whenever I write some Script-Fu I'm underwhelmed by the resources out there. And I'm well aware of perl-fu and python-fu - as alternative programming environments for The Gimp. Like I said, it always boils down to a popularity contest.
And you can't exactly blame programmers for not embracing Scheme: much of the Script-Fu scheme code out there is written in poor style (oh, to see Scheme code indented like C code - my eyes, my eyes!). Additionally, the Scheme API is low level. The difference between programming in Perl or Scheme, when you're effectively calling C functions, isn't really that dramatic. Unless, of course, you already know Perl/C/Python/etc. - in which case, you're going to gravitate to the language that looks familiar to you.
To me, the solution to convincing the world to use Guile, and Scheme in general, is contained in the above two paragraphs. For example, to make Scheme truly popular in The Gimp I think the Scheme community needs to do only two things:
Perl, Python, JavaScript win because they are familiar and have huge libraries backing them up. Scheme doesn't have those things going for it, so it's going to need to be clever - it's going to win because you can be the most efficient in it. When Guile can offer that, then everything else will fall into place.
I originally learned about Andy's paper through Lambda-The-Ultimate.
So, what should the Scheme and Guile community do? While I love the evangelism involved in getting out there and spreading the word about how powerful a language Scheme is, that's never enough. Part of me thinks that the best option is to embrace JavaScript - with first class functions, and mostly lexical scoping, it's kinda-sorta a Scheme with a more user friendly interface. Maybe there's a possibility of growing JavaScript in a way that it's even more Scheme like (like, say, having better support for tail calls). Maybe it's the ideal stepping stone to Scheme?
But, realistically, that's going to leave most Scheme fans wanting far more. No, I think there's a better and more likely to succeed approach.
Consider The Gimp - one would think that it would be nearly the ultimate Scheme success story. The project itself is successful, and Scheme has been embedded in it from the beginning. Heck, it even has a slick name for the Scheme add on: Script-Fu. How can you not get excited about that?
But, whenever I write some Script-Fu I'm underwhelmed by the resources out there. And I'm well aware of perl-fu and python-fu - as alternative programming environments for The Gimp. Like I said, it always boils down to a popularity contest.
And you can't exactly blame programmers for not embracing Scheme: much of the Script-Fu scheme code out there is written in poor style (oh, to see Scheme code indented like C code - my eyes, my eyes!). Additionally, the Scheme API is low level. The difference between programming in Perl or Scheme, when you're effectively calling C functions, isn't really that dramatic. Unless, of course, you already know Perl/C/Python/etc. - in which case, you're going to gravitate to the language that looks familiar to you.
To me, the solution to convincing the world to use Guile, and Scheme in general, is contained in the above two paragraphs. For example, to make Scheme truly popular in The Gimp I think the Scheme community needs to do only two things:
- Don't stop by delivering the low level C style API. Go beyond that and deliver a high level API, one that uses all the cool features that are highlighted in Andy Wingo's post on Guile. Don't just talk about how macros can dramatically change the life of a programmer, make some that do. Don't just talk about how call-with-current-continuation can add new looping constructs to a language, create some.
- Make sure there's plenty of high quality examples available. Perhaps reviewing and improving the plugins that users submit.
Perl, Python, JavaScript win because they are familiar and have huge libraries backing them up. Scheme doesn't have those things going for it, so it's going to need to be clever - it's going to win because you can be the most efficient in it. When Guile can offer that, then everything else will fall into place.
I originally learned about Andy's paper through Lambda-The-Ultimate.
Script-Fu has some unexplicable things, like car spam, some places require "(car )", others don't. It makes writing scripts tiresome, because it seems to be a random rule that just adds noise.
ReplyDelete@anonymous - I believe all gimp functions return a list, which means you're constantly car'ing stuff. I'd often forget this, and find debugging it to be painful.
ReplyDeleteIn some ways, I suppose it's a clean way to implement the C api (you can return multiple values). But mostly, it's just annoying and confusing.
It's the perfect example where a higher level API is missing.
Grant - that's a fine idea, but it's probably only worth the effort if there's some specific capability Racket is going to offer that TinyScheme (I believe The Gimp scheme impl) doesn't.
ReplyDeleteNot quite sure what that would be.
Yeah, switching from [ThisScheme] to [ThatScheme] is only going to set the world on fire if...
ReplyDeletea) There's something compellingly better about [ThatScheme], and
b) One builds a high-level Schemey library that is compellingly preferable to other APIs for programming the capability.
Of course, since b) is about abstraction, and isn't intrinsic to [ThatScheme], a) is, at best optional, and, rather more likely, a distraction from what would be *really* helpful.
Christopher -
ReplyDeleteCan you expand more on what you mean by "is about abstraction, and isn't intrinsic to [ThatScheme]"?
I'm not quite following you there.
Thanks,
Ben
I think you are better off trying to push Javascript to be more Scheme like. I think that the thing most Lisp lovers miss is that the syntax just doesn't appeal visually to most people. It seems foreign and strange, all those parenthesis in odd places. I love the whole concept of it and have read quite a bit about Lisp, but in the end I never like coding in it b/c my eyes start to cross. I can't follow the code easily.
ReplyDelete