Another issue - minor this time - is that the hierarchy in section 4.1 -
Random Numbers - is not indented in the HTML.
--
View this message in context:
http://n2.nabble.com/Ann-Self-Handbook-tp3739644p3848999.html
Sent from the Self mailing list archive at Nabble.com.

Thanks, this is a great help.

I find that section 3.1 (World Organisation) produces an Oops.. This link
appears to be broken page recently.

Regards,

Rob

--- In self-interest@yahoogroups.com, Russell Allen <mail@...> wrote:
>
>  From the Blog
(http://blog.selflanguage.org/2009/09/29/announcing-the-self-handbook/
> ):
> Documentation is at the heart of any successful open source project
> and, as Self wakes from its slumbers, documentation is vital to
> providing a way for interested people to learn and participate.
>
> Self has a number of manuals, as well as important published papers,
> but these have been available only as pdf.
>
> Three of these manuals (the Programmers Reference Manual, the
> Programming Environment Manual and the Morphic Manual) have been
> turned into HTML and combined into the new Self Handbook, which is
> available to read on line at http://docs.selflanguage.org.
>
> This is quite comprehensive—in pdf form it is at the moment around 140
> pages.
>
> Read and enjoy!
>
> Russell
>

I was looking at the schedule for upcoming talks in the EE380 class at
Stanford and noticed that David Ungar is scheduled (with an as yet
untitled talk) for September 30:

http://www.stanford.edu/class/ee380/

Perhaps this should be mentioned in the blog so that people who are
close by but don't read this list can attend?

-- Jecel

I just saw this in James Robertson's blog (and also in
comp.lang.smalltalk):

http://www.cincomsmalltalk.com/blog/blogView?entry=3429931130

The next Toronto Smalltalk User's Group[1] meeting will have a
presentation about Self by Adam Spitz - the meeting is on Monday,
September 14, at this location:

     Northwater Capital (directions[2])
     Bay Wellington Tower, 47th floor
     181 Bay Street
     Toronto ON
     M5J 2T3

[1] http://smalltalk.toronto.on.ca/
[2] http://smalltalk.toronto.on.ca/location.htm

-- Jecel

Hi All,

I've made the first Know Your Prototypes - Know Your Self video for the video
blog of the same name. It's viewable at the "community" section of
http://www.smalltalktelevision.com

Chris

Russell!

> I'm intrigued - do you have a goal or are you just trying to see how
> far you can bend Self before it breaks? :)


Well, obviously my curiosity is killing me! Apart from that, I'm
evaluating ideas for a version control system, where the different
forks can live side by side.  I was looking at Smalltalk Changeboxes
and similar approaches. In Squeak, virtualizing method calls requires
hooking into the compiler. In Self, in theory, it would be as easy as
exchanging the lobby.

> if I were doing this I would maybe try making the changes to the
> Self files and rebuilding the snapshot.

Thanks so much for the insight! Umm, I assume I find the Self files in
the source tarball? I'll see if I can do that.

cheers,

Niko

*** Stack Overflow!!
#0 (/Users/russellallen/self/release/../objects/core/errorHandling.self:316): undefinedSelector:Receiver:Type:Delegatee:MethodHolder:Arguments: = ( | self* = <0>. :sel = 'reflect:'. :rec = <0>. :msgType = 'implicitSelf'. :del = nil. :mh = nil. :args = <1>. |  
            forwardSend: 'undefined' Selector: sel Receiver: rec Type: msgType
              Delegatee: del MethodHolder: mh Arguments: args 
              IfSucceed: [|:res| ^res ].
            suspendAndTrace: 
                (((((processErrors undefinedSelector copy
                    receiver:     rec)
                    selector:     sel)
                    type:         msgType)
                    delegatee:    del)
                    methodHolder: mh)
                    arguments:    args.
            errorContinueValue )


#1 (<error>:1): reflect: = ( | self* = <0>. :arg1 = <0>. delegatee = nil. selector = 'reflect:'. | 
"undefined selector error;
this method was automatically generated by the VM."
 )


#2 (/Users/russellallen/self/release/../objects/core/errorHandling.self:238): forwardSend:Selector:Receiver:Type:Delegatee:MethodHolder:Arguments:IfSucceed: = ( | self* = <0>. :prefix = 'undefined'. :sel = 'reflect:'. :rec = <0>. :msgType = 'implicitSelf'. :del = nil. :mh = nil. :args = <2>. :blk = <3>. postfix = 'Selector:Type:Delegatee:MethodHolder:Arguments:'. selector <- 'undefinedSelector:Type:Delegatee:MethodHolder:Arguments:' "''". |  
            selector: (prefix, postfix) canonicalize.
            ((reflect: rec) lookupKey: selector) isEmpty ifFalse: [
                | performDecl = (|
                    canFail = false.
                    acceptSelector: s = (
                        "This is for the type inferencer."
                        'Selector:Type:Delegatee:MethodHolder:Arguments:' 
                        isSuffixOf: s.
                      ).
                  |). |
                blk value: 
                    rec _Perform: selector
                        With: sel With: msgType With: del With: mh With: args
            ] )

etc... etc...

Hi, so I did this. I added two slots to the lobby:

alternaLobby <- clone
undefinedSelector: sel Type: t Delegatee: d MethodHolder: h Arguments:
a = ( sel sendTo: alternaLobby WithArguments: a)

Then, I wanted to remove all other slots from the lobby. Removing
traits works fine, but removing globals or defaultBehaviour crashes
the VM. How do I find out why it crashed?

cheers,

Niko

On Fri, Aug 07, 2009 at 11:43:07AM -0700, Steve Dekorte wrote:
> Not all human languages are a tangle of special cases. Turkish, for
> example, is completely phonetic and this allows children learning it
> to become completely fluent years earlier. It also eliminates spelling
> mistakes and significantly increases typing speeds (there is a reason
> why stenotypes are phonetic).

Many languages have phonetic spelling systems - English seems to be a large
exception in that regard.  I suspect that Turkish spelling in the Latin-based
form is especially regular because it was developed rather recently (81 years
ago).

Funny that you mention Turkish, BTW, since it's the language I use when trying
to explain to people/system administrators/programmers that case insensitivity
is tricky.  Case insensitivity works well in English, but even something as
simple as capitalizing "windows" if you're on a Turkish system can result in
problems.  Turkish has both a dotted-i and an undotted-i - the lower case
dotted-i upper cases into an upper case dotted-i (which is thus different from
the "normal" English upper case I) and the upper case undotted-i lower cases
into a undotted-i (which is thus different from the "normal" English lower
case i).  Thus on a Turkish system, upper casing "windows" may not result in
"WINDOWS".  See http://en.wikipedia.org/wiki/Turkish_dotted_and_dotless_I for
some more information.  ;)


> > The latter is supposedly much cleaner, but notice that
> > many more people speak the former.
>
> English speakers also outnumber Turkish speakers, but I'd be highly
> skeptical of the argument that the language features are the cause of
> this difference.

True, but I doubt there are any perfectly regular human languages that weren't
"invented."


> Btw, I've noticed a tendency for discussions of unnecessary complexity
> vs. simplicity to ultimately devolve into the more human vs. less
> human argument. But who is it who gets to define that which humans
> should aspire to? Are gothic gargoyles on the sides of cathedrals
> truly "more human" than the architecture Frank Lloyd Wright? Which
> humanity do you want to belong to?

I'm not advocating that Perl is more beautiful than Self by any stretch of the
imagination.  But Perl does have a history of inclusion, a tendency to adopt
"ivory tower" concepts (closures being an obvious example, and I posit C::P as
another example), and in this respect it may resemble English - ugly, but an
expansive vocabulary enriched by the inclusion of many foreign works and
concepts (even if they are brutally mispronounced).


--Toby Ovod-Everett

My experience teaching Smalltalk and Self has been very similar to
Mario's.

Most tutorials I have seen don't mention that the basic control
structures are just message passing instead of built-in. That is
something people don't need to learn right away, but it can be exciting
for people experienced in other languages and then these people want to
share with everyone by writing a tutorial that does go into that.

A more traditional path will make the student take ifTrue:, while:  and
do: as given and will never see any other control structures at all. The
difficulties I have seen are: ifTrue: comes after the boolean expression
and that the first expression must be a block for while: but not for
ifTrue: (things are far worse for and: and or: where one side has to be
a block and the other shouldn't be one!!). I would have thought that do:
might be complicated since you get blocks with arguments which have a
slightly awkward syntax, but in general people find that less confusing
than the details of "for" in C.

By far the biggest complication in Smalltalk-80 is the "class/instance"
button in the browser. People will think that they are following
instructions exactly but will end up adding their method to the wrong
"side". The resulting errors will be really, really confusing. Self
neatly avoids that, but I think with the proper tools the situation
could be better even in Smalltalk-80.

About simplicity itself, Steve Jobs had some very interesting comments
in an interview in Byte magazine when the Mac came out in 1984. He
showed the Mac motherboard beside a IBM CGA video board and noticed how
much more complex the latter was even though it did far less. He said
that projects tend to start out simple because the people don't yet know
all the problems there are in practice. By the time it actually works,
it will be a lot more complicated. He said most projects end there and
ship the product, but if you could keep on going and learning still more
you would get to the point where you could build something even simpler
than the first design but which actually works even better than the
complicated one. I think this describes the history very well:
Smalltalk-72....-76....-80 and then -86 (a.k.a. Self).

Another thing I like to say about simplicity is that there are two
kinds: painful and joyful. Imagine the simplest possible paint program.
You might move the blinking cursor to the next pixel by pressing "space"
and change the color under the cursor by pressing "tab". Get what I mean
by "painful" yet? If space moves in the opposite direction to where you
want to go, you will need to press it as many times as there are pixels
to get where you want. But there is no drawing that can be made with any
other tool that can't also be made with this one! If we were to step
back from absolute simplicity (do I need to quote Einstein?) by allowing
movement in four directions using the arrow keys, the usability of the
program would increase dramatically. But on rare occasions things become
more usable when they are made simpler rather than added to (do I need
to quote Exupery?), and that is what I mean by joyful simplicity.

The math side of language designers makes them long for universals. But
I hope you can see that replacing if/then/else, for, while, until and so
on with just if and goto is an example of painful simplicity? To me,
replacing temporary variables, instance variables, class variables,
class instance variables, pool variables and global variables with slots
and parents is an example of joyful simplicity. Replacing built-in
control structures with blocks, non local returns and _Restart (Self) or
blocks and recursion (Smalltalk-80) adds a little bit of pain (in the
form of the awkwardness I reported above) but is otherwise pretty much
neutral. It is a refactoring that will only start to matter when you are
pretty deep into the language.

Some ideas about how Self could be simpler can be found in:

http://www.merlintec.com:8080/software/11

-- Jecel

On 2009-08-06, at 10:23 PM, Toby Ovod-Everett wrote:
> Anyway, one way to get at the core of the Perl vs. Self dichotomy
> (although
> one of things I'm pointing out above is that it's possible to have
> Self-like
> semantics in Perl due to the flexibility built into Perl) might be
> to think
> about natural languages vs. designed languages - i.e. English vs.
> Lojban.  The
> first is ugly and messy and full of all sorts of weirdness.

Not all human languages are a tangle of special cases. Turkish, for
example, is completely phonetic and this allows children learning it
to become completely fluent years earlier. It also eliminates spelling
mistakes and significantly increases typing speeds (there is a reason
why stenotypes are phonetic).

> The latter is supposedly much cleaner, but notice that
> many more people speak the former.

English speakers also outnumber Turkish speakers, but I'd be highly
skeptical of the argument that the language features are the cause of
this difference.

Btw, I've noticed a tendency for discussions of unnecessary complexity
vs. simplicity to ultimately devolve into the more human vs. less
human argument. But who is it who gets to define that which humans
should aspire to? Are gothic gargoyles on the sides of cathedrals
truly "more human" than the architecture Frank Lloyd Wright? Which
humanity do you want to belong to?

And coming in very late in the game...

2009/8/5 brassplume <brassplume@...>:
> I'd like to point out something about the idea that Self is the language of
simplicity.
> On the home page it says "The Power Of Simplicty".
[...]
> PHP and Perl are simple languages. Not Self. You can be a crap programmer and
> do lots of useful CRUD things with those languages.

Your argument is that the correct definition of a simple language is,
"A language with which casual programmers can accomplish useful
results." And by that metric PHP and Perl are simpler than Self.

Fair enough. But this kind of simplicity is not a function of language
design; it is a function of the available libraries and example code.
Case in point, I recently had to write a small script, which I ended
up doing in Python. I'd never programmed in Python before, I usually
do these sorts of things in Ruby, but I happened to find some code
that was a good starting point, and it was in Python. If I had found
sample code in Perl, I would have done it in Perl.

The applicable definition of simple is always context dependent. It
doesn't make sense to argue that there is only one appropriate
definition. Is AWK simpler than SQL? It depends. If you want to
process a text file, yes. If you want to process rows in a database,
no. If you are comparing semantics, than no. If you are comparing
syntax, then maybe.

Perl and PHP were created to solve particular problems and make it
easier to get certain tasks done. The design of these languages, and
especially the built-in libraries and mode of interaction with the
language, is determined by these pragmatic considerations. This is a
perfectly reasonable motivation for creating a language.

Practical utility is, however, not the only virtue. Self was created
to explore certain issues in language design. What is the minimum
necessary for a useful object-oriented language? Can it be made
efficient? What kind of development environment is necessary to
support this language?

This is also a valuable undertaking, and the claim, "the power of
simplicity," should be evaluated in this context.

- sekhar

--
C. Ramakrishnan           cramakrishnan@...
Illposed Software           http://www.illposed.com

On Thu, Aug 06, 2009 at 12:37:33PM -0700, Steve Dekorte wrote:
> One of the two languages mentioned that was supposed to be simpler was
> "Perl". Do you really think that someone can learn Perl (get their
> head around the bevy of different semantic and syntactical constructs
> they will come across) faster than Smalltalk?
>
> I know people that programmed in Perl for years and couldn't make
> heads or tails out of their own code when coming back to it after 6
> months. I've never heard of this happening with Smalltalk.

Unless they wrote it using Class::Prototyped in Perl ;)

Just sticking up for Perl a smidgin - I do 99% of my programming in Perl, even
if sometimes I wish I lived in a world where I did 99% of my programming in
Self (I, for better or worse, do Win32 system administration, including an
aggressive focus on managing workstations, which pretty much means I need a
language that plays well with Win32, which Perl does and I've been coding
aggressively in it for 13+ years, which makes it hard to change).

But if you're ever stuck in Perl and miss Self, take a look at
Class::Prototyped.  http://search.cpan.org/dist/Class-Prototyped/
I'd been missing Self when I wrote Class::SelfMethods, and then Ned Konz wrote
C::P, and then some serious lightbulbs went off in my head and the two of us
ended up in a coding frenzy that resulted in major redesign and the result was
very Self-like semantics with Perlish syntax.  And then he moved on to Squeak,
and I kept maintaining, including adding some aspect-ish like stuff (although
I didn't know and still don't know much about AOP).


Anyway, one way to get at the core of the Perl vs. Self dichotomy (although
one of things I'm pointing out above is that it's possible to have Self-like
semantics in Perl due to the flexibility built into Perl) might be to think
about natural languages vs. designed languages - i.e. English vs. Lojban.  The
first is ugly and messy and full of all sorts of weirdness.  The latter is
supposedly much cleaner, but notice that many more people speak the former.


--Toby Ovod-Everett

On 2009-08-06, at 6:46 AM, Niko Schwarz wrote:
> A smalltalk loop like
>
> #(1 2 3 4) do: [:el | Transcript show: el]
>
> needs the reader and programmer to understand two separate things.
> What a loop is, AND what a block is.


> Now you may say that I could just ignore the block magic and treat the
> syntax as magic, just like Java folks do. But Smalltalk won't let me.
> Blocks are built deep into the system, and you need to grasp them to
> get your head around to why the bevy of different iterators you will
> come across works.

Other languages have "blocks of code" which enclose the area within
loops and conditions, have locals and access to the external scope and
are basically the same thing except that they can't be passed by
reference.

One of the two languages mentioned that was supposed to be simpler was
"Perl". Do you really think that someone can learn Perl (get their
head around the bevy of different semantic and syntactical constructs
they will come across) faster than Smalltalk?

I know people that programmed in Perl for years and couldn't make
heads or tails out of their own code when coming back to it after 6
months. I've never heard of this happening with Smalltalk.

It seems to me that the difference is that Perl is ubiquitous, so when
people have such problems, they assume it's their fault and not that
of the tool - just as MS Windows users do.

- Steve

Whoa. I was afraid to come back to this thread, as I figured that post of mine
would be bad news. I thought last night "Well, even if they find that post
asinine, that was a distinction I had to make for myself."

I guess it's safe to say that post hit a bit of a nerve, and people found it
somewhat useful.

It's all Adam's fault. He came to the Toronto Smalltalk Users Group, and now I
feel as though Self is a missing piece in a bridge between Smalltalk and
JavaScript. I don't need you to agree with that, but I think that my thinking
that will be useful to your community. Here's why.

I have a burgeoning web enterprise called Smalltalk Television. It's a host for
Seaside images and videos on introductory Smalltalk. I need a way to promote it.
What I plan to do is make an ongoing video blog called Know Your Prototypes -
Know Your Self. The Smalltalk videos are private. The Self videos starting at
the end of the month will be free and will invite feedback from Self, Io and
prototype languages and the JavaScript crowd I'll be promoting it to.

The aim will be to raise awareness about Smalltalk Television in a useful way to
the JavaScript world. In my bones, like I said, I feel Self is the missing link
I've been looking for, the tool that goes just so in my set of tools.

I don't want to get ugly after making what I imagine is a basically a good first
impression, but this is about to happen, whether you like it or not. The first
video goes up before ESUG starts, as I know a guy doing a presentation there,
who'll be pointing to my site http://www.smalltalktelevision.com as a model for
marketing.

So... come, watch the video, then comment on the ST Google Group. If you think
it's wrong - great, explain why. Your corrections will provide me with fodder
for the next biweekly video blog post.

And no, I'm not much of a programmer. But I'm a good game show host. :)


Chris

Hi!


On 06.08.2009, at 00:12, Steve Dekorte wrote:

> "The control structures are built in and obvious"
>
> How are they any more obvious?
>

I don't mean to speak for brassblume, but I would like to answer.

A smalltalk loop like

#(1 2 3 4) do: [:el | Transcript show: el]

needs the reader and programmer to understand two separate things.
What a loop is, AND what a block is.

Now you may say that I could just ignore the block magic and treat the
syntax as magic, just like Java folks do. But Smalltalk won't let me.
Blocks are built deep into the system, and you need to grasp them to
get your head around to why the bevy of different iterators you will
come across works.

Also, I could imagine that novices don't necessarily appreciate that
"everything is the same!", as I told them with wet eyes about the
beauty of Smalltalk. Everything is an object is a thing of beauty. But
as a novice, you are analyzing, and at least it doesn't HELP that
message sending and looping are entwined, and in fact look exactly the
same.

In Java you can easily recognize loops. They come with a "do," a
"while," or a "for." In Self not so much.

I suspect that the uniformity of Lisp is a reason why people find it
difficult. You get lots of power from that uniformity, but it also
confuses you by not letting you easily distinguish between separate
concepts.

cheers,

Niko

 

Here's a question I've wondered about for a while.

I don't have any formal teaching experience at all, but in my experiences as a student, watching other students around me try to learn object-oriented programming, it seemed to me like one of the major stumbling blocks was the difference between an object and an instance and a class. ("No, typing Car doesn't get you an actual car - it gets you the Car *class*. To get a car object, you have to *instantiate* the class.") So I always thought that it ought to be easier for a beginner to learn Self than Smalltalk. But I've never had a classroom full of beginners to try it out on. I'd be very interested to hear the experiences of people who've actually tried teaching Self, especially to people who've never programmed before.

Mind you, I'm still not quite satisfied with the way that a Self "class" is made up of two different boxes on the screen (prototype + traits). But Smalltalk has the same problem (instance + class), and I've never managed to figure out a way to get rid of it. I'm guessing the two-box problem is one of those carpet-bump issues. But at least we don't have to worry about what class a class is an instance of...

Adam

--- In self-interest@yahoogroups.com, Michael Latta <lattam@...> wrote:
>
> The value in a system like Self, and Smalltalk, and Ruby, is the value
> to the expert user. To a programer that has mastered the language,
> the flexibility, ability to extend the language, and to implement new
> abstractions, are what make a language system stand out. With image
> based programming there is also the ease of access to the objects and
> internals that far exceeds most memory based programming
> environments. But, again mostly those benefit the experienced user.
>
> Michael

Here's a question I've wondered about for a while.

I don't have any formal teaching experience at all, but in my experiences as a
student, watching other students around me try to learn object-oriented
programming, it seemed to me like one of the major stumbling blocks was the
difference between an object and an instance and a class. ("No, typing Car
doesn't get you an actual car - it gets you the Car *class*. To get a car
object, you have to *instantiate* the class.") So I always thought that it ought
to be easier for a beginner to learn Self than Smalltalk. But I've never had a
classroom full of beginners to try it out on. I'd be very interested to hear the
experiences of people who've actually tried teaching Self, especially to people
who've never programmed before.

Mind you, I'm still not quite satisfied with the way that a Self "class" is made
up of two different boxes on the screen (prototype + traits). But Smalltalk has
the same problem (instance + class), and I've never managed to figure out a way
to get rid of it. I'm guessing the two-box problem is one of those carpet-bump
issues. But at least we don't have to worry about what class a class is an
instance of...


Adam



--- In self-interest@yahoogroups.com, Michael Latta <lattam@...> wrote:
>
> The value in a system like Self, and Smalltalk, and Ruby, is the value
> to the expert user.  To a programer that has mastered the language,
> the flexibility, ability to extend the language, and to implement new
> abstractions, are what make a language system stand out.  With image
> based programming there is also the ease of access to the objects and
> internals that far exceeds most memory based programming
> environments.  But, again mostly those benefit the experienced user.
>
> Michael

I would say that a big part is more about documentation than language
design for the beginner.  If Smalltalk/Self/Objective-C had
documentation that approached the problem of learning step-wise and
covered all the basics rather than the concepts, it might be less of
an issue for beginners to learn them.  When control structures are
built-in they get documented.  When they are in a library they are
often left for the programmer to discover.  This is not always the
case, but certainly contributes to the problem.

Michael




On Aug 5, 2009, at 4:12 PM, Steve Dekorte wrote:

>
> On 2009-08-05, at 7:31 AM, brassplume wrote:
>> PHP and Perl are simple languages. Not Self. You can be a crap
>> programmer and do lots of useful CRUD things with those languages.
>> Semantically the are complicated. And ultimately they're limiting
>> because of that. The control structures are built in and obvious. In
>> Self, Smalltalk, or Lisp, you need to bring a lot of knowledge to
>> either build your own or see how somebody added objects/classes to
>> do that.
>
>
> "The control structures are built in and obvious"
>
> How are they any more obvious?
>
> FWIW, I've noticed that there is an inverse correlation between a
> person's sensitivity to negatives of X and the popularity of X among
> their peers and that this effect is so powerful that it is often
> confused with objective judgement.
>
> For example, a window's developer friend of mine who happily deals
> with the complexity of C++ templates (which are Turing complete!)
> claimed he was unable to wrap his head around Objective-C 's infix
> message syntax. Had Microsoft used Objective-C, I suspect his opinion
> of what is obvious would be quiet different.
>
> I can see the evolutionary benefit of this mental trait for getting
> groups of individuals to cooperate but blindness to it's influence is
> IMO the largest barrier to human social, political and technological
> progress.
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

> FWIW, I've noticed that there is an inverse correlation between a
> person's sensitivity to negatives of X and the popularity of X among
> their peers and that this effect is so powerful that it is often
> confused with objective judgement.
>
> For example, a window's developer friend of mine who happily deals
> with the complexity of C++ templates (which are Turing complete!)
> claimed he was unable to wrap his head around Objective-C 's infix
> message syntax. Had Microsoft used Objective-C, I suspect his opinion
> of what is obvious would be quiet different.
>
> I can see the evolutionary benefit of this mental trait for getting
> groups of individuals to cooperate but blindness to it's influence is
> IMO the largest barrier to human social, political and technological
> progress.
>

This couldn't be said in a nicer way.

Regards,
Alexandre

>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On 2009-08-05, at 7:31 AM, brassplume wrote:
> PHP and Perl are simple languages. Not Self. You can be a crap
> programmer and do lots of useful CRUD things with those languages.
> Semantically the are complicated. And ultimately they're limiting
> because of that. The control structures are built in and obvious. In
> Self, Smalltalk, or Lisp, you need to bring a lot of knowledge to
> either build your own or see how somebody added objects/classes to
> do that.


"The control structures are built in and obvious"

How are they any more obvious?

FWIW, I've noticed that there is an inverse correlation between a
person's sensitivity to negatives of X and the popularity of X among
their peers and that this effect is so powerful that it is often
confused with objective judgement.

For example, a window's developer friend of mine who happily deals
with the complexity of C++ templates (which are Turing complete!)
claimed he was unable to wrap his head around Objective-C 's infix
message syntax. Had Microsoft used Objective-C, I suspect his opinion
of what is obvious would be quiet different.

I can see the evolutionary benefit of this mental trait for getting
groups of individuals to cooperate but blindness to it's influence is
IMO the largest barrier to human social, political and technological
progress.

No question having an interactive interpreter is useful for a novice
to experiment.  Where image based systems excel is when a paused
system can be explored programmatically. Being able to bounce between
running the system and exploring the objects is where image based
systems really excel.  Being able to use code to walk object graphs
while the main execution is paused is something the current crop of
IDEs fall short.  In my experience the masters of the language are the
ones with loaded workspaces full of magic incantations that save them
lots of time and "magically" expose the system they are working on in
ways a novice would not think to use.  Slogging through object
inspectors in Java IDEs is not the same as debugging a Smalltalk or
Self system by a long shot.  A novice Smalltalk or Self user however
will mostly drive the exploration manually.

Michael





On Aug 5, 2009, at 3:25 PM, Niko Schwarz wrote:

> Hi Michael,
>
> On 05.08.2009, at 23:13, Michael Latta wrote:
>
>>  With image
>> based programming there is also the ease of access to the objects and
>> internals that far exceeds most memory based programming
>> environments.  But, again mostly those benefit the experienced user.
>
> Now, are you sure that is the case? Because from my tries of teaching
> people smalltalk, I recall that blocks and the fact that you could
> look up the definition of ifTrue: did not help. But what did help was
> the ability to test an whose class we had just defined in a workspace.
> And then we tried out the inspector of an object, and after some
> confusion, I believe that was helpful, too (although the workspace
> might have been better).
>
> cheers,
>
> Niko
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hi Michael,

On 05.08.2009, at 23:13, Michael Latta wrote:

>   With image
> based programming there is also the ease of access to the objects and
> internals that far exceeds most memory based programming
> environments.  But, again mostly those benefit the experienced user.

Now, are you sure that is the case? Because from my tries of teaching
people smalltalk, I recall that blocks and the fact that you could
look up the definition of ifTrue: did not help. But what did help was
the ability to test an whose class we had just defined in a workspace.
And then we tried out the inspector of an object, and after some
confusion, I believe that was helpful, too (although the workspace
might have been better).

cheers,

Niko

I agree with the distinction being raised.

No matter the language there are basic things that must be learned to
build a working program.  It does not matter whether the thing learned
is built-in or from a library.  Collections, control structures,
variables, computation, etc.  A simple language that must be extended
to implement all these basics is no easier to learn than one that has
them all baked in.  And unless well documented from a learner's point
of view, it could be much harder.

The value in a system like Self, and Smalltalk, and Ruby, is the value
to the expert user.  To a programer that has mastered the language,
the flexibility, ability to extend the language, and to implement new
abstractions, are what make a language system stand out.  With image
based programming there is also the ease of access to the objects and
internals that far exceeds most memory based programming
environments.  But, again mostly those benefit the experienced user.

Michael





On Aug 5, 2009, at 1:46 PM, Niko Schwarz wrote:

> Can I digress very briefly on this matter?
>
> The natural numbers are actually constructed very simply and
> beautifully. Or can be constructed, I should say. You start by just
> sets, and define the empty set to be zero. Then you allow a set to
> contain other sets. So we define 1 to be the set that contains 0. Now
> we we define for each number, that the next number is the set
> containing all its predecessors.
>
> That is a beautiful definition, and the building blocks are simple: We
> need only an empty set and sets that contain other sets. And we get
> meaningful, elegant definitions for things like "smaller
> than" (through set inclusion, in this example).
>
> What I want to say is: Simple building blocks don't necessarily lead
> to a simple system. Knowing this, in mathematical writing, I am
> sometimes tempted to write n when I mean the set {1,…n-1}. Because I
> know it's defined to be this way. But then I realize that that would
> be queer, that the majority of the mathematicians has a very different
> mental model of natural numbers. Natural numbers are these things that
> define the quantities of finite sets. You ADD them, sometimes
> multiply, and they fit quite nicely into the Range of real numbers,
> rather isolated.
>
> Now, you could argue that it is because that's how we get used to
> natural numbers. That's how we use them every day, if it were just
> taught differently, they would enjoy set tricks more. And I would
> reply that New Math failed: http://www.youtube.com/watch?
> v=tx5KDyvlG3Q.
>
> Because, you see, building systems bottom-up makes them conceptually
> beautiful, powerful, sophisticated, and without rough edges. But they
> also ensure that things that are fundamental to the user are really
> quite involved concepts in your system. I mean, it does irritate
> mathematicians if you use "element of" and mean "smaller than" on
> natural numbers. Eventhough it is, in a sense, a fundamentally
> equivalent thing.
>
> The point I am getting to is, a system like Self might be beautifully
> simple, because the design principles can be taught in less than a
> minute. But the newbie does not NEED the design principles, he needs a
> for loop. Now, given Self, he has to learn two things: the for loop
> AND the design principles.
>
> I quite understand where the OP is coming from. I've taught a few
> friends smalltalk, and I was ASTONISHED to see how long it took to get
> people to grasp it. Not at all less time than Java, I would estimate.
> Despite the fact that Smalltalk is, conceptually, a lot easier than
> Java.
>
> Systems like Self are very easy for people like us. We know the for
> loop concept, the closure concept, and the accessor concept. Self has
> an elegant way to implement these, so for US Self is heaven. A good
> computer scientist can probably learn Self in a day, because he knows
> all the concepts already. For US, it really boils down to only
> understanding the few fundamental principles of Self, and the rest
> follows easily.
>
> Maybe to wrap up, just as a case in point: in the parameterized
> complexity field of mathematics, which develops algorithms in large
> quantities, the usual pseudo-code for algorithmsis is imperative.
>
> So, my point would be that there is a certain simplicity in Pascal,
> that you cannot find in Self. Pascal offers a syntax piece for each
> core concept that you really need to know. And not more. Not even a
> break statement.
>
> cheers,
>
> Niko
>
>
>
> On 05.08.2009, at 20:46, Jeremiah S. Junken wrote:
>
>> It may have something to do with familiarity. Self and IO are both
>> extremely simple, and for people familiar with either one, learning
>> the other is fairly simple -- but for people who have not started
>> out with something like Smalltalk, or a functional language, it's
>> definitely a bit of an alien landscape with a learning curve
>>
>> There's conceptual simplicity and practical simplicity -- the latter
>> has a lot to do with familiarity.
>>
>> My 2 cents in debased currency.
>>
>> On Wed, 2009-08-05 at 10:59 -0700, Randy Smith wrote:
>>
>>
>>> I'm pleased you say "I agree that the language it simple -
>>> semantically" as that was the intended claim. Maybe we should put
>>> that in the title, but it makes it little clunky sounding.
>>>
>> [snip]
>> [snip -- pwd vs. self ]
>>>
>>> I suppose the larger question might be: Every language is like a
>>> carpet with a complexity bump that can be moved around from place to
>>> place but never flattened out. Are some language carpets
>>> intrinsically
>>> less bumpy?
>>>
>>> --Randy
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Can I digress very briefly on this matter?

The natural numbers are actually constructed very simply and
beautifully. Or can be constructed, I should say. You start by just
sets, and define the empty set to be zero. Then you allow a set to
contain other sets. So we define 1 to be the set that contains 0. Now
we we define for each number, that the next number is the set
containing all its predecessors.

That is a beautiful definition, and the building blocks are simple: We
need only an empty set and sets that contain other sets. And we get
meaningful, elegant definitions for things like "smaller
than" (through set inclusion, in this example).

What I want to say is: Simple building blocks don't necessarily lead
to a simple system. Knowing this, in mathematical writing, I am
sometimes tempted to write n when I mean the set {1,…n-1}. Because I
know it's defined to be this way. But then I realize that that would
be queer, that the majority of the mathematicians has a very different
mental model of natural numbers. Natural numbers are these things that
define the quantities of finite sets. You ADD them, sometimes
multiply, and they fit quite nicely into the Range of real numbers,
rather isolated.

Now, you could argue that it is because that's how we get used to
natural numbers. That's how we use them every day, if it were just
taught differently, they would enjoy set tricks more. And I would
reply that New Math failed: http://www.youtube.com/watch?v=tx5KDyvlG3Q.

Because, you see, building systems bottom-up makes them conceptually
beautiful, powerful, sophisticated, and without rough edges. But they
also ensure that things that are fundamental to the user are really
quite involved concepts in your system. I mean, it does irritate
mathematicians if you use "element of" and mean "smaller than" on
natural numbers. Eventhough it is, in a sense, a fundamentally
equivalent thing.

The point I am getting to is, a system like Self might be beautifully
simple, because the design principles can be taught in less than a
minute. But the newbie does not NEED the design principles, he needs a
for loop. Now, given Self, he has to learn two things: the for loop
AND the design principles.

I quite understand where the OP is coming from. I've taught a few
friends smalltalk, and I was ASTONISHED to see how long it took to get
people to grasp it. Not at all less time than Java, I would estimate.
Despite the fact that Smalltalk is, conceptually, a lot easier than
Java.

Systems like Self are very easy for people like us. We know the for
loop concept, the closure concept, and the accessor concept. Self has
an elegant way to implement these, so for US Self is heaven. A good
computer scientist can probably learn Self in a day, because he knows
all the concepts already. For US, it really boils down to only
understanding the few fundamental principles of Self, and the rest
follows easily.

Maybe to wrap up, just as a case in point: in the parameterized
complexity field of mathematics, which develops algorithms in large
quantities, the usual pseudo-code for algorithmsis is imperative.

So, my point would be that there is a certain simplicity in Pascal,
that you cannot find in Self. Pascal offers a syntax piece for each
core concept that you really need to know. And not more. Not even a
break statement.

cheers,

Niko



On 05.08.2009, at 20:46, Jeremiah S. Junken wrote:

> It may have something to do with familiarity. Self and IO are both
> extremely simple, and for people familiar with either one, learning
> the other is fairly simple -- but for people who have not started
> out with something like Smalltalk, or a functional language, it's
> definitely a bit of an alien landscape with a learning curve
>
> There's conceptual simplicity and practical simplicity -- the latter
> has a lot to do with familiarity.
>
> My 2 cents in debased currency.
>
> On Wed, 2009-08-05 at 10:59 -0700, Randy Smith wrote:
>
>
>> I'm pleased you say "I agree that the language it simple -
>> semantically" as that was the intended claim. Maybe we should put
>> that in the title, but it makes it little clunky sounding.
>>
> [snip]
> [snip -- pwd vs. self ]
>>
>> I suppose the larger question might be: Every language is like a
>> carpet with a complexity bump that can be moved around from place to
>> place but never flattened out. Are some language carpets
>> intrinsically
>> less bumpy?
>>
>> --Randy
>
>
>
>