mine was C, which was a step up from 6502 assembly language. I read about Lisp while reading about programming languages in general. I theorized that I would like Smalltalk and dislike Lisp. Then I had the opportunity to write code with both and discovered that while I was trying to grok Smalltalk, Lisp took over my brain and all my subsequent programming thoughts were in Lisp.

6502 assembly is kind of nice. System/370 is even nicer (except there's no stack).

I used to be convinced that C++ was the finest language in the world, too. I pity people who still think that way.

Mine was FORTH. My brain only seems truly susceptible to invasion by languages with user-defined first-class entities.

The reason many good programs gravitate to C++ is because they are looking for the most powerful and "hardcore" programming experience- The obvious assumption is that such a language would be at least somewhat popular. But unfortunately it's not- because *lisp* is the most powerfull language, and unfortunately it remains wildly obscure, by any reasonable measure.

I used to count that there were something like seven different ways in C++ for one class method to frob the internal variables of another class. (Friends and stuff like that.) And there were very good reasons just why you had to be able to do so in C++ that I had never realized I was missing until then.

In comparison, SmallTalk had no means of doing so and nor did (as best I recall) did Flavors.

So yes, clearly C++ is a much more powerful, oop language.

Hmm. I clicked POST, waited, and discovered that my post seems to have vanished in a puff of greasy black smoke.

How long ago did you learn Lisp?

I had a brief encounter with Lisp in an AI class, and I loved the language. My first encounter with something Lispish was Emacs-Lisp, but I didn't hack anything complicated enough to make me realise its power; I did, though, like lambda-expressions. Oh, yeah, and I like Tcl, too, which can be Lispish.

I liked C++ ten years ago because I thought it gave me the power to do about anything I wanted at the machine level, but I could use classes as an architectural framework. But then I started teaching C++ programming, and I found it to be very difficult to explain. I thought the difficulty was O-O until I learned Smalltalk, and I realized that C++ just had a lot of design weirdness.

When Java came out, I thought it would be the best of both worlds combination of C++ and Smalltalk. But now I find it tedious, especially after learning Python. Now I'm finally learning Scheme, and I think the Lisp family will be my favorite.

"... for one class method to frob the internal variables of another class..."

When I took OO programming I was taught that frobbing internal variable of another class is bad practice. The reason is this. Suppose I have a thermostat class that uses degrees Celsius all the way through. Some other class generates an instance and starts frobbing the desired-temperature field. Now tomorrow I decide that I want to internally represent the value in Kelvin. I will have to change code in classes other than the thermostat class in order to change an internal representation in the thermostat class. That is horrible.

Solution (we used Java in that class) was to make a get() and set() method for every field that you might want to get() and set(), and declare the fields private so no direct frobbing was allowed. Problem was that this required a lot of typing. We were being graded on it, so we just did it, but I don't think the average poorly-paid pro would take the trouble; good modular design is rarely a concern _right now_.

In flavors, this problem was circumvented. You could pass some keyword to your class definition and it would generate get and set methods for all your fields automagically. That entails virtually no work "right now", but if you ever internally change to Kelvin, or Fahrenheit, or Rankin, or Joules of thermal energy per particle, you can override the get and set method and still provide the same interface.

Jaap commented, "We were being graded on it, so we just did it, but I don't think the average poorly-paid pro would take the trouble; good modular design is rarely a concern _right now_."

Guess it depends where you are. Neglecting to build in proper encapsulation would you a serious talking-to on my team.

My favorite before Lisp was Ruby. It has a lot of dynamic features like block iterators and it was an easy leap from C/Java idioms. Even so, Ruby is not nearly as clean or as pleasant to use as Lisp in my opinion.

I don't know where the average pro is poorly paid. Or at least so poorly paid that they shouldn't do their job correctly. Seems like if someone is going to hire a programmer they would want the programmer to do the job right. Otherwise, the self-respecting programmer should move on.

Maybe I was being a little cynical. What I meant to say is that chances are greater that programmers will actually do the proper encapsulation in flavors, because it can do it automagically in the 90% of cases where the Java code identically reads

void setFoo(Footype foo) { thefoo = foo; },

and only needs to be hand coded in the 10% of cases where the Java code reads something like

void setFoo(Footype foo) { thefoo = foo.twiddle();}