Scheme Is Love(msdn.microsoft.com)
msdn.microsoft.com
Scheme Is Love
http://msdn.microsoft.com/en-us/magazine/cc163729.aspx
21 comments
An utterly commonplace article in itself, but to see this written by Don Box is surreal.
I feel like some qualification is in order. I can't make any excuses for SOAP (maybe someone else wants to take that up), but COM, at its core, is indeed a simple and dare I even say elegant technology. COM is alive and well on Windows, because it still serves a basic need (cross-language binary interop) and it does so well.
The problem is that COM just couldn't stay simple -- the basic idea of querying an object for reference-counted interfaces was quickly buried under incomprehensible layers of pUnkOuter and IMoniker and apartment states and OLE activation sites and god knows what other stuff that you have to know about but doesn't help you getting work done.
I've seen people who can get carried away adding layers of stuff to something simple and beautiful without ever realizing that it stopped being simple and beautiful quite a while ago, because they still understand everything. Boiling frog design, if you will. I don't know Don Box well enough to tell if he's one of those people, but COM and related technologies seem to have seen a lot of that crowd.
The problem is that COM just couldn't stay simple -- the basic idea of querying an object for reference-counted interfaces was quickly buried under incomprehensible layers of pUnkOuter and IMoniker and apartment states and OLE activation sites and god knows what other stuff that you have to know about but doesn't help you getting work done.
I've seen people who can get carried away adding layers of stuff to something simple and beautiful without ever realizing that it stopped being simple and beautiful quite a while ago, because they still understand everything. Boiling frog design, if you will. I don't know Don Box well enough to tell if he's one of those people, but COM and related technologies seem to have seen a lot of that crowd.
It appears he was of that crowd:
http://news.ycombinator.com/item?id=335734
http://news.ycombinator.com/item?id=335734
I'd never heard of him before, so I looked him up:
http://en.wikipedia.org/wiki/Don_Box
I did like the article though, even though there wasn't much to it. One of these days when I have some time, I'm going to write a LISP/Scheme compiler for .NET/CLR...my goal is to get Arc running on .NET, specifically for IIS7 since it has better support for MVC applications.
http://en.wikipedia.org/wiki/Don_Box
I did like the article though, even though there wasn't much to it. One of these days when I have some time, I'm going to write a LISP/Scheme compiler for .NET/CLR...my goal is to get Arc running on .NET, specifically for IIS7 since it has better support for MVC applications.
There was also a port of an interpreted scheme written in Java that someone brought to C# -- I think it was floating around as ".NET Lisp" or "Lisp.NET"; NOT the 'example' Lisp 1 that someone wrote in the earliest days of the CLR, but a straight port of the Java project.
I used it myself once; snuck it into a project to run an admin interface for one of those crappy CRM's you're always being asked to make as a Code Monkey (it was just a little embedded language and user-interface element that let admins drag-and-drop "listers" and filters for various types of data, embedding them at will within the articles that they wrote -- I couldn't have imagined trying to write something like that for ASP.NET, so I lisped it, and I believe it's still humming along, for years now: a homebrew DSL parsed and executed by a pre-alpha interpreted lisp sitting at the heart of a .NET 1.1 application. Never a hiccup, and being admin-only, performance wasn't a concern; the end-result was compiled to a canonical XML format, which most .Net coders have no problem writing XSL for).
The project was being maintained on SourceForge by a really bright guy (from Australia afair); he'd added Arc-style lets and a nice little parser (for evaluating quoted infix expressions)
I remember trying to look it up a couple of years ago, to forward it to a friend still stuck in .netland, but it had disappeared; maybe someone here knows more.
I used it myself once; snuck it into a project to run an admin interface for one of those crappy CRM's you're always being asked to make as a Code Monkey (it was just a little embedded language and user-interface element that let admins drag-and-drop "listers" and filters for various types of data, embedding them at will within the articles that they wrote -- I couldn't have imagined trying to write something like that for ASP.NET, so I lisped it, and I believe it's still humming along, for years now: a homebrew DSL parsed and executed by a pre-alpha interpreted lisp sitting at the heart of a .NET 1.1 application. Never a hiccup, and being admin-only, performance wasn't a concern; the end-result was compiled to a canonical XML format, which most .Net coders have no problem writing XSL for).
The project was being maintained on SourceForge by a really bright guy (from Australia afair); he'd added Arc-style lets and a nice little parser (for evaluating quoted infix expressions)
I remember trying to look it up a couple of years ago, to forward it to a friend still stuck in .netland, but it had disappeared; maybe someone here knows more.
More on Don: http://www.microsoft.com/presspass/exec/de/Box/default.mspx
FWIW, being a Distinguished Engineer is a big deal. The guy running my team is a DE and he's probably the brightest person I've met at Microsoft...I consider myself fortunate to work for him. I've met people who've been full time (I'm an intern) for a few years and never met a DE.
FWIW, being a Distinguished Engineer is a big deal. The guy running my team is a DE and he's probably the brightest person I've met at Microsoft...I consider myself fortunate to work for him. I've met people who've been full time (I'm an intern) for a few years and never met a DE.
There is a Scheme implementation called IronScheme that runs on .Net: http://www.codeplex.com/IronScheme
Oh cool, I'll take a look!
I love Scheme.
I ported Peter Norvig's JScheme to C#. I also ported JScheme to Python and Ruby to learn the basics of programming in those languages.
I wish Rich Hickey had kept working on the C# version of Clojure.
I would love to check out your port of Arc to .NET once it's ready.
I ported Peter Norvig's JScheme to C#. I also ported JScheme to Python and Ruby to learn the basics of programming in those languages.
I wish Rich Hickey had kept working on the C# version of Clojure.
I would love to check out your port of Arc to .NET once it's ready.
I don't think it is possible to implement continuations on top of the CLR.
Sure it is. They're already using it with F#
What I meant was that the CLR does not support continuations of the type that makes call/cc possible, which is required to implement scheme.
It seems that IronScheme (Scheme on CLR) haven't found a solution for this issue: http://ironscheme.codeplex.com/WorkItem/View.aspx?WorkItemId...
I may be wrong since I dont know F#, but I suspect continuations on F# is more limited than call/cc.
It seems that IronScheme (Scheme on CLR) haven't found a solution for this issue: http://ironscheme.codeplex.com/WorkItem/View.aspx?WorkItemId...
I may be wrong since I dont know F#, but I suspect continuations on F# is more limited than call/cc.
Isn't this basically what the 'yield' keyword does in C# (for enumerating values)? If not, can someone explain the difference?
... Heh, no, yield isn't the same as a continuation.
Yield, for iterators at least, is basically just calling a function that you've passed in.
In Ruby (and now C#) and many other languages, there's what appears to be syntactic sugar around this idiom, and especially in C# it's a bear to follow what's happening because of the sea of syntax.
But all that's really happening is, you pass in an anonymous function, and when the iterator calls yield(x), it calls that anonymous function with x.
In C#, you're saying
Yield for iterators is just sugar around an anonymous function.
Continuations are a whole other bag o worms. (edit: originally invented as a powerful memory-wasting device, some people now find them almost useful ;) ).
Yield, for iterators at least, is basically just calling a function that you've passed in.
In Ruby (and now C#) and many other languages, there's what appears to be syntactic sugar around this idiom, and especially in C# it's a bear to follow what's happening because of the sea of syntax.
But all that's really happening is, you pass in an anonymous function, and when the iterator calls yield(x), it calls that anonymous function with x.
In C#, you're saying
okay, for this foreach doodle with a variable i, HereIsAnInterator(initialized) {
but you can imagine this whole block as
a function that gets called with i
every time yield() is called.
}
Yield for iterators is just sugar around an anonymous function.
Continuations are a whole other bag o worms. (edit: originally invented as a powerful memory-wasting device, some people now find them almost useful ;) ).
That may be one way to implement iterators, but it's nothing like the method C# actually uses. See e.g. the series starting at http://blogs.msdn.com/ericlippert/archive/2009/07/09/iterato...
:P Look, I felt dirty enough just reading the C# code for an idiomatic usage of an iterator ...
Obviously, in a compiled language that you control, you could take that block and turn its contents into a method of a class for speed.
Conceptually, much easier to understand the base case: that you're passing in an anonymous function.
In ruby, since they let you pass blocks around as objects, suddenly, poof, you can understand and implement ruby's iteration, just by learning about blocks and seeing a snippet of code.
I like how, when they're talking about how to handle ITERATION, they say "we thought about coroutines; we thought about continuations; we settled on what we've got now" ... thinking about how I'd do it in CL (if I were writing a library to make iterator-style programming more friendly, perhaps as a macro), I have to say I wouldn't have immediately thought of using either of those. :P
Of course, I suppose for their target market, features that let you "roll your own x", for almost any x, are far too dangerous to allow. Ugh.
C# code makes mr_luc sad.
Obviously, in a compiled language that you control, you could take that block and turn its contents into a method of a class for speed.
Conceptually, much easier to understand the base case: that you're passing in an anonymous function.
In ruby, since they let you pass blocks around as objects, suddenly, poof, you can understand and implement ruby's iteration, just by learning about blocks and seeing a snippet of code.
I like how, when they're talking about how to handle ITERATION, they say "we thought about coroutines; we thought about continuations; we settled on what we've got now" ... thinking about how I'd do it in CL (if I were writing a library to make iterator-style programming more friendly, perhaps as a macro), I have to say I wouldn't have immediately thought of using either of those. :P
Of course, I suppose for their target market, features that let you "roll your own x", for almost any x, are far too dangerous to allow. Ugh.
C# code makes mr_luc sad.
yield could be implemented with continuations, but in C# it is implemented by turning the function into a class.
An utterly commonplace article in itself, but to see this written by Don Box is surreal.
I fully agree. http://news.ycombinator.com/item?id=335734
I fully agree. http://news.ycombinator.com/item?id=335734
That was pretty much my reaction.