Arc Forumnew | comments | leaders | submitlogin
Musings on Language Design
17 points by CatDancer 6135 days ago | 10 comments
I'm 40 years old, and I've been programming since I was 8. (Which always makes me wonder how should I reply to the question "how many years experience do you have"... saying "32" does seem like cheating ^_^, yet any other reference point I might choose is also arbitrary).

How good a programmer am I? At one point I was actually able to measure this... following an emotionally wrenching and exhausting startup failure, which also left me buried in Visa credit card debt, I went to work for Visa for a while. It was a soothing experience, I worked in my little cubicle and wrote Java code to design patterns... and in that environment, I was three times as productive as anyone else working there. (After a while Visa had paid off my Visa credit card debt, I had recovered my emotional equilibrium, and I left).

Now, I'm pretty sure anyone reading this forum would have been as productive as I was, if not more productive (assuming that they had like me suffered some kind of life trauma so that they wouldn't have immediately run away screaming). Comparing me to an "average" programmer working in the bowels of a large company, I was demonstratively, measurably three times better than average. Compare me to programmers who hang out on a language design forum... I am probably at most average, probably below average. (I have yet to grok the Y combinator, for example).

If you are still reading, I give this background to provide some context for my remarks. I've tried both Haskell and Scheme for real-life projects. Both projects were a failure, despite my having invested a serious amount of time reading all the available books and documentation I could find, hanging out in forums and asking questions, reading research articles by Oleg Kiselyov... The project using Haskell failed because I spent all my time wrestling with the type system, and the project using Scheme failed because I spent all my time wrestling with writing hygienic macros.

This does not make these "bad" languages. I use lots of products that were made by people smarter than me who built them using systems that I don't know how to use. I am holding in my hand a pen made out of a plastic that I could spend a year learning chemistry and probably still not be able to make without generating some kind of poisonous chlorine gas and killing myself. I can imagine that I might be very happy if I were using an operating system written using a provably correct type system, even if I'm not smart enough to write such code myself.

Yesterday I wrote a (very small) program in Arc, which in turn is a fairly thin wrapper around the powerful engine of MzScheme. This makes me happy, since now I'm able to use those powerful features of MzScheme, even though I'm not smart enough for it to be practical to write my own Scheme code which uses them directly.

People complain that Arc0 lacks features needed to write good libraries. No doubt Arc will get those features sooner or later, as various people write Arc programs and want to publish libraries and start implementing the needed features to be able to do so. But, just for the sake of argument, what if Arc was a bad language for writing libraries in? What if that wasn't the point of Arc?

I mean,

  arc> (let self "me me me!"
         (each x '(a b c)
           (prn self)))
  #<procedure: self>
  #<procedure: self>
  #<procedure: self>
  nil
  arc>
bad, right? No self-respecting library would be publishing a macro that trashed my lexical environment. (This particular interaction might get fixed in the future in one way or another, so the details aren't important, this is just for just for illustration).

I write Perl applications which make use of many of the excellent Perl libraries available in CPAN. Some of those Perl libraries are wrappers around C++ libraries when the C++ library was the best library available for the task. In one case the only working library available was a Java library, so I did most of the work in Perl code which called out to a tiny Java program I wrote which called the Java library.

Do I want to be writing code in C++ or Java? No. Am I happy that I can make use of good libraries that happen to be written in C++ or Java? Yes.

I am happy to be able to use Perl to call a C++ library. Writing that library in Perl might be a bad idea (for performance reasons or whatever), but I don't care, because I can call it from Perl anyway.

If Arc were able to call out to Perl libraries (in the same way that Perl can wrap C++ libraries)... and, while I'm putting together my fantasy wish-list, was able to call the best libraries in Scheme, Haskell, Ruby, Python, Java, C++... :-) I think I'd probably be happier writing my applications in Arc. I find myself reasonably productive in Perl, but I do get frustrated with being able to do Lisp-ish things only rather awkwardly. I think I might be a little more productive in Ruby, but I haven't seen enough of an advantage to get me to switch. (I might for a new project).

I am not, of course, actually proposing that we don't worry about features that would be needed in Arc to enable writing good Arc libraries. Still, when I think about the things that attract me to Arc, it's not being able to write libraries in Arc that I care about so much, as the thought of writing programs in Arc. Scripting, if you will.



4 points by bayareaguy 6134 days ago | link

I can sympathize with you somewhat. I like lisp but I'm not a deep lisper. Personally I'd would like it more if it could play nice with Python modules. But that sort of thing is not where the real Arc "action" is at the moment.

Arc takes lisp in a new direction. The right thing to be doing now is not to get buried in details like foreign function interfaces but instead to see where pg's ideas lead. From what I can tell he's doing the same sort of thing Roger Hui and Arthur Whitney did when they took APL in the direction of J and Kx respectively - they let go of a few old things in order to make new ideas fit in better.

The theme of this party is succinctness. Let's all see how well that works out. How low can you go?

-----

3 points by mst 6131 days ago | link

It occurs to me that you could get away with most of that just by getting to perl, since perl can already call Python, Java etc. through the Inline:: modules.

And, for bonus points, somebody's already bolted perl into mzscheme -

http://search.cpan.org/~autrijus/Language-MzScheme-0.09/scri...

so all we actually need to do is to find a way to expose -that- into arc.

-----

1 point by CatDancer 6131 days ago | link

Very cool! I'll look into that. Ah, written by Audrey Tang, why am I not surprised :-)

I had been planning to call Perl in a subprocess, but this of course will be much more fun (if it works).

I'll be particularly wanting to know how it interacts with MzScheme threads...

-----

1 point by mst 6129 days ago | link

If you do have a go, mail me at mst -> shadowcat.co.uk, I know a bit about the perl side of things and my first CPAN release was fixups to Guile.pm so I'd be interested to help you.

-----

1 point by CatDancer 6129 days ago | link

Hmm, Language::MzScheme isn't compiling against MzScheme v352. The documentation says it works with MzScheme v200 or greater, so I suspect it might not have made the transition to the v300 series.

-----

1 point by dido 6134 days ago | link

Arc, is, for the moment, written on top of MzScheme. that presents a bit of a problem, because writing extensions to Arc entails first writing an extension to MzScheme and then writing some glue to allow the extension to be used from within Arc. This is a bit of a mess. It would be nice if C extensions could be created for Arc directly, but that would probably entail the development of a standalone Arc built on C code somehow (either directly or via a technique similar to how they built Scheme48). Ruby took this approach, and it is at present so easy to write a C extension to Ruby, almost as easy as actually writing Ruby code, that it puts most other scripting languages' extension mechanisms to shame (cough...cough...Perl).

By the way, being able to call the best libraries written in other languages also means that you wind up thinking in those languages as well, rather than in Arc. My experience comes from Ruby, and in many cases a Ruby library written with Ruby's idioms in mind, wrapping an underlying library written in C, trumps a library wrapper written by means of an automated tool such as SWIG any day of the week. The same would probably be true of Arc as well, once this aspect comes to pass.

-----

1 point by lg 6134 days ago | link

I notice the Arc source is littered with a few references to Scheme 48, specifically things not working in it. But if that got fixed, then you'd have access to C libraries, because IIRC Scheme 48 was built to interface well with C.

-----

1 point by randallsquared 6134 days ago | link

The only thing that seems to affect, going by comments, is the conversion from characters to integers and vice versa. If that's the only actual problem, there are only about ten places in the Arc code that need some replacement fix.

-----

1 point by Flatlander 6134 days ago | link

Since MzScheme has also a dynamic FFI it shouldn't be hard to write an extension (in Scheme) that would provide FFI primitives to the Arc side.

-----

1 point by dpawson 6134 days ago | link

Since Arc is described as a scratchpad language, the more interesting 'extension' I'd like to see would be to OS features, in the same way that Guile naturally wraps such items.

-----