mattjones

The problem, at MIT and elsewhere, is that hackers don't like hacking Scheme enough. Python has more libraries than Scheme now, but that's not the main thing that made more people use it. People use it because they prefer the language. This is something that Sussman and others at MIT should be trying to understand, but it doesn't strike me that they are trying to understand it. They're just saying "Python has a better robotics library -- oh well!" as if this were something completely random that they have no control over. That doesn't seem like the sort of attitude that produced Scheme in the first place.

My point of contention with the comment I replied to is the idea that fixing the problem is a question of writing more libraries for Scheme. Writing or interfacing to libraries for numerics, 3D graphics, etc. is a trivial task compared to making a language hackers love.

Now, maybe hackers' distaste for Scheme is Scheme's fault, or maybe it's hackers'; but in any case, the issue is with the core language, not the libraries. And based on my personal experience with Scheme I would say that enough of the fault lies on Scheme's side that it's worth fixing.

What made them popular was the design of the core languages. I started using Ruby because it was faster to type and easier to remember how to do things than Perl, not because it had more libraries, which it didn't.

The problem with Scheme is that the core language isn't terse enough, and so it gives the impression that it will be hard to do things. And that's correct. Scheme requires much more typing and is harder to remember than Ruby.

Consider:

Ruby:

  h = {}
  h[:foo] = "hi"
  h[:foo] #=> "hi"
  h[:bar] #=> nil

  (define h (make-hash-table))
  (hash-table-set! h 'foo "hi")
  (hash-table-ref h 'foo) ;; "hi"
  (hash-table-ref/default h 'bar #f) ;; #f

This isn't a Lisp problem, it's a Scheme one. A Lisp with a better core and enough users would get lots of libraries eventually, just like any language.

I think Scheme is good for teaching though, and would rather learn it in a course than Python.

There are other ways to be aware of your self besides through some complex optical phenomenon. For example, an animal might be aware of whether it can fit through that hole, jump up to that ledge, kill that enemy, or stand on that branch without breaking it. It might be aware of whether other creatures are able to see it inside its hideout, or if its cubs are hurt by its bite. "Self" is a rather broad and subtle thing.

I don't know how similar the mental processes of drawing and programming are. But what I do know is that the state I'm in when I'm drawing feels the same as the state I'm in when I'm programming. When I'm deep into either, I often remark to myself how relaxing it feels.

If painting didn't feel like programming to you, maybe it was because you weren't good at it. When comparing hackers to painters, it only makes sense to compare people who are good at hacking to people who are good at painting. Doing something you're not good at involves so many hurdles and complications that are unique to the novice that all you're getting is noise. If you'd been drawing for as long as you've been able to hold a pencil, PG's thesis might not seem so bollocks.

I disagree vehemently. I myself have started using Ramaze, and like it better than Rails. In any case, it's more important to me to know Ruby well than a particular framework.

It's like asking, "Why are Arctic foxes (Alopex lagopus) not very popular on the African savanna?" Because they didn't evolve in response to the demands of that environment. The bat-eared fox, Otocyon megalotis, did.

The differences between Alopex and Otocyon aren't so massive that they seem like totally different kinds of animals. But it would be tricky to predict exactly what they should be, and develop the right kind of fox in a lab. Some adaptations are obvious (thick fur), other less so (specialized circulatory system). I suspect the same is true for programming languages. It's tricky to determine exactly what makes Scheme better suited to the classroom than to developing general applications. Perhaps the best way to solve the problem is the way PG is doing it with Arc, which is to take a very young, malleable dialect of Lisp and plunk it down in the environment to which you want it to become well adapted, and then continue development in response to the demands you encounter.

These things would make great pack animals. When you go hiking, you'll be able to toss your gear into one of these things and have it trot along behind you. You'll be able to take more risks because robots will be able to rescue you from tight places. If you get tired or sick, you'll be able to ride them.

It's funny to think that the streets of San Francisco in 2100 might superficially look like a town in a developing country. ("Oh, those aren't mules in the street, they're robots.")

Say there exists a class called Errors in some Ruby library. It doesn't have an each() method, but I'd like it to. Nobody would complain if I wrote a function each_error() which took an Errors object as an argument. Reopening the Errors class and giving it an each() method is the way you do that in Ruby, and it's not really any more dangerous.

Whatever backend your persistence system uses, you'll probably always want to take advantage of tools that are geared to that. If it happens to use flat files, there will probably be situations where you'll want to use grep, or cp, or cat. If it happens to use an RDBMS, there will probably be situations where you'll want to use SQL. I imagine this will be the case for a long time.

So far, I've been dubious of query-generating ORMs (except for basic CRUD), but I'm guessing that that's partly because they've been awkward. They've been getting better though. And I think the quality of the SQL-generating abstractions, and the languages they're written in, makes a big difference. If the abstraction is less powerful than SQL it will be annoying. If it's more powerful it won't be.

How could it be more powerful? By being written in a powerful language; by starting with a low-level, comprehensive mapping to SQL expressions and then using the power of the programming language to build up from there. I know that some Lisp packages offer such mappings, but I don't know much about working with them. It would be interesting to have a play though.

I've noticed that the more time I spend here, the less tolerance I have for other sites. So while I spend more time here than I used to, I spend much less time on other, less relevant sites than I used to. The time I have to do work is actually the same or greater.

This kind of perspective (chromatic's) is a problem. The thing is, programming languages with the property that you can build powerful abstractions and still keep the program comprehensible and maintainable almost certainly will be closely coupled with some areas of mathematics. Things with such powerful and peculiar properties usually are.

It doesn't mean that the thing in question can only appeal to math geeks. One thing you can do with Scheme's abstraction power is build abstractions that do not seem especially mathematical.