Seasoned Smalltalker

I suppose what I mean is someone who has internalized the Smalltalk language and culture enough that they conceptualize their code in Smalltalk, in the same way that a person fluent in a natural language "thinks" in that language (as opposed to thinking in another language, then translating). Since I've been reading and writing Smalltalk for 17 years (and Lisp for 25), sheer time accounts for some of this as well. I suspect, however, that someone could become a SeasonedSmalltalker (according to this definition) in as little as six to twelve months.

For example, although I "know" CeePlusPlus, I think in SmalltalkLanguage, then translate to C++ (when I have to). Consequently, I find that I'm much less proficient at coding in C++. I also have a tendency to think in Lisp, and in fact I carry around a program language grouping sort of like RomanceLanguage that includes Lisp, Smalltalk, Forth, and Postscript. These are environments that place most of their semantics in the environment (instead of in the syntax).

I therefore describe myself as a SeasonedSmalltalker. Sometimes this is a great advantage; other times its an enormous burden.

-- TomStambaugh

Good analogy to natural language. I find that when I speak JavaLanguage I speak it with a SmalltalkAccent. It makes it difficult for me to sometimes talk about Java to those who speak with a CplusPlusAccent? because we say the same things, but the meaning is subtly different. It's like MarkTwain's quote "Britain and the United States are two countries separated by a common language". -- KyleBrown

Curious, I've found that once you think in C, you never go back. Hacking in Squeak, I think, "oh, that's a primitive method, implemented by the VM in C..." and I imagine messages represented in the VM by little structs, and selectors are in a hashtable and have unique 'int's assigned and get called.

Funny also because I played around with CecilLanguage the other day and thought to myself, "This is awesome! The whole language is only three C hashtables..." (object symbols -> object; method signatures -> method, field (signature) -> slot).

I've never actually seen under the hood of a Smalltalk or Cecil implementation. It's just how I think.

(I suppose, to be pedantic, I'm not thinking in terms of plain C, I'm thinking in terms of patterns of language implementation in C that I know from poking around many Open Source language implementations.)

--JasonFelice

It can get worse. If you are fluent in AssemblyLanguage and have built suffiently complex systems with it, then you often think about higher languages just in terms of their implentation. Like: Oh, that virtual method is just a doubly indirect jump over the method table reached from the this-pointer.

Just don't get too carried away by this simplicity. A friend used to depreciate higher level languages "because they are just syntactic sugar" for this or that memory structure. But this discounts the emergent properties of suffiently advanced syntactic sugar. The typing savings alone allow to write much complexer code in much less time.

No wonder you had these thoughts after you learned C: C is more low level (HighLevelAssemblyLanguage?) and allows to express these structures, which are abstracted away and unavalable in e.g. SmallTalk.

But beware: Even if some language feature can be implemented in the way you think, it need not. There may be optimizations (which can of course be explained in assembly) which are non-trivial and/or non-obvious (like whole-program transformations, unrolling, dynamic constant propagation, JIT, ...).

-- GunnarZarncke

Damn, I feel stupid. I really don't have anything to contribute to this. I try to peek under the hood with what I do, but I just don't have the frame of reference. Which sucks. Lack of formal education does have its drawbacks. [ScottNeumann]

It happens to me often to have hard times trying to understand abstract concepts from high level languages, and this is maybe because I wrote a lot of 680x0 codes and C codes... When we talk about messages, virtual methods, or whatever else... I must see what's going in the "low level" to catch the idea... and then I discover that doing so, I can't catch the idea, but just an implementation of the idea. I like SmalltalkLanguage more than other languages since I am almost able to imagine how it could be implemented. I've used this light to reduce to one common factor languages like JavaLanguage, CeeSharpLanguage (and SmalltalkLanguage of course)... so that to people saying "C# is better than Java" I answer "they are the same" stuff, meaning that they could reach the same functionalities even if in a different syntax (the idea behind is a virtual machine)... The real difference is given by the environment. Anyway the syntax is important too, it could make clearer or simpler to express an algorithm. For some reason, I dislike C# (and I don't like too much Java), and I am an happy Smalltalk newcomer (through GnuSmalltalk), and I liked ObjectiveCee too -- MauroPanigada

CategorySmalltalk