Self-interest April 2001

self-interest@lists.selflanguage.org

13 participants
16 discussions

simple object model (was: [self-interest] selfing Self)
by Jecel Assumpcao Jr 03 Jun '01

03 Jun '01

I am sending a copy of this to the self-interest list. I hope you don't mind. On Friday 30 March 2001 04:39, Uladzimir Liashkevich wrote: > Let me join the discussion. This is a very interesting topic to me. > When I first read about Smalltalk I thought that it is the greatest > language ever. Then I discovered some difficulties with the language, > for example absense of multiple inharitance causes strange > inharitance trees like Object -> ReadStream -> ReadWriteStream. My favorite example is String, which can't decide if it should be a Magnitude or a Collection... > When I read about Self, I felt the same as in the case of Smalltalk. > Later I discovered the absense of some needful possibilities. One of > them is constructing objects on the fly. One cannot write something > like this: (| x:Y: = (| :aX. :aY | ^(| x <- aX. y <- aY |) ) |). While this doesn't work because slot initializers ("aX" and "aY" in this case) are always evaluated in the context of the lobby object, you can get the same results with: (| x:Y: = (| :aX. :aY. new | new: (| x. y. parent* = traits clonable |) copy. new x: aX. new y: aY. new) |) The reason I used 'copy' above is that I am supposing that you don't want successive calls to this method to always return the exact same object, but just the same kind of object. If that is the case but you don't want the new object to be clonable, we could use the '_Clone' primitive instead of 'copy' and eliminate 'parent*'. If you wanted 'x' and 'y' to be constant slots in the new object (you didn't show that in your example) then things do get much more complicated. It is still possible to do this using mirrors, however. But I was indeed trying to make this kind of thing simpler. > So > now I'm in process of thinking out a more flexible but yet powerful > language. By now I have implemented two experimental versions of > Self. But I need something different. Me too, but more in the spirit of Self than the Self-inspired languages of the early 1990s. > > Like a simple object model: objects are just flat association lists > > (I'll use Lisp notation below) - > > > > (x 3 y 4) > > flat list has an array structure rather than linked list? By "flat" I meant compared to this form of association list: ((x 3) (y 4)) But it is a *very* interesting question if these should be arrays or linked lists - Lists: + can be shared as the continuation (CDR) of several other lists + can be scanned using a single pointer - since you can point into the "middle" of a list there are many aliasing problems - can't be indexed into + can be as space efficient as arrays with special encoding + easy to split and put together Arrays: - need three items for scanning: base, index and size + no need to waste more than one virtual address per array + access to any element is equally fast It is easy to convert one into the other when you need to do some kind of processing for which the normal format is not very good. > Do you want to use the same semantics for a objects, arrays and > hashes? Like, (1 2 3) - array, (x 3 y 4) - object or hash? > Please describe that semantics a bit more. Every object is a list, but there are lists which are not formatted objects (the code examples below, for instance). So I must treat (1 2 3) as an object which does not explicitly list the messages it understands. In fact, the object "1" has this problem as well, but at least the number objects have special tags so they don't look like they might be a regular object. I am still figuring this out. > > append '(z 9) '(x 3 y 4) > > Is this a message-sending construction? What is the receiver? No, this was a pseudo Lisp functional notation. This would be more proper '(z 9) append: '(x 3 y 4) though the problem above shows itself here: how does the '(z 9) object understand the 'append:' message? We would have to force it to be treated as a plain list, which is getting into the reflective level and similar to requesting a mirror for an object in Self. This needs some careful design. > How to distinguish objects and methods? I am thinking of making methods internally be objects that have a special <code> "slot" ... factorial: (n 0 <code> (n < 1 ifTrue:False: 1 '(n * factorial: n-1) ) ) .... I have other ideas for blocks than quoted lists, but this will do for now. Hmmm... if instead of "<code>" I used "|" then this would look more like Smalltalk... Note that though the argument "n" has a default value of 0, it will be replaced once this code object is cloned to create a context object. > Did you get rid off keyworded selectors like a:B:C:? I used one in the above example, but at the low level the keywords aren't spread among the arguments. In a higher level graphical editor I would expect you to be able to write something like n < 1 ifTrue: 1 False: [n * factorial: n - 1] My idea is that the arguments would be underlined, but that is hard to show using ASCII in this email. > > [these nested lists can act as both "maps" and parents] > > Really good fresh idea. > It seems that all slots are assignable, doesn't it? That is something to be fixed. The implemenation must be able to tell what is changable and what is (normally, at least) constant. In the NeoLogo implemenation where these ideas came from you could write make "x 10 and simply change the value of the x "slot". It would be better to do the same thing by sending a message instead x: 10 and you could have the Self rule that unless there is a "x:" method then "x" is a constant slot. I don't know what the best way to handle assignments is. I have always felt that assignments and argument replacement should be somehow related. Kyle doesn't like the fact that assignment slots must be in the same objects as their data slots in Self (they can't be moved into the parent objects, for example). > The first challenge is to invent such system, then it can be > optimized. Remember that many people doubted that Self can be > implemented efficiently... Right, we can always hope that history will repeat itself. On the other hand, there are many examples of interesting ideas that nobody ever figured out how to do reasonably well. Dynamic parent slots in Self are an example (actually, I did figure out a way to do it but haven't tried it yet). -- Jecel

4 7

Re: [self-interest] OO future (was: An OO history)
by cramakrishnan＠acm.org 27 Apr '01

27 Apr '01

Jecel Assumpcao Jr writes: > On Monday 23 April 2001 17:05, Steve Dekorte wrote: > > On Tuesday, April 17, 2001, at 11:33 AM, Jecel Assumpcao Jr wrote: > > > [...] I have found it nearly > > > impossible to change people's minds, to "covert" them... > > > > Right, that's the problem I'm getting at. It seems there's so many > > great technologies/ideas that sit on the shelf because inventors > > don't understand marketing. It's been said that in engineering there > > are no technical problems, only people problems. For those of us that > > want to see the innovations of Smalltalk and Self in widespread use, > > our biggest problem isn't technological. It's figuring out how to get > > people to use new technologies. > > Easy: get everyone around them to use them. Most people go with the > crowd. Obviously, this leads to a recursive bootstrap problem :-( This kind of phenomena was studid by philosophers of science like Thomas Kuhn and Paul Feyerabend. They argue that it takes time for innovations to be accepted by the larger community not because the community is filled with morons, but because it is filled with people who are very adept at working in their world-view. To these people, the innovations are not valuable because they have so much invested in the old way of doing things. For example, though the heliocentric view of planetary motion was a more elegant way to explain the motion of the planets, the geocentric was actually more accurate with respect observations in Galeleo's time. It was able to account for things that could not be explained until Einstein (the precession of Mars or something like that...). In the most pessimistic, Kuhn observed that many new scientific theories are not adopted by the peers of the creators. It is rather the next generation or people with different backgrounds who bring about the adoption of the new theory. These people never developed a facility with the old way of doing things and are less reluctant to change. I don't know the histroy of ideas in computer science -- does this accurately describe e.g., the adoption of relational vs. navigational/hierarchical databases. I'm reminded of Alan Key's barb about Java being dangerous because it makes new ideas look like old ones. Perhaps that's also why Java has been so quickly adopted. > To solve this problem, I am targetting schools which want to look more > modern than the others. If all students in a class get a new computer > on the same day, then they will be using what everyone around them is > using without any of them having to be the "early adopter". That's a good approach. My plan is to target people who want and need to use programming as a tool, but who don't know much programming. In particular, I want to go after computer musicians. MAX/MSP is a programming environment that many are familiar with and it has a Self 4-like user-interface. However, many tasks that should be easy are cumbersome in it. SuperCollider, on the other hand is a Smalltalk-like language for making music. It's very powerful, but more difficult for people to get into (partially because it doesn't have things that make Smalltalk so nice -- like debuggers and browsers). I think an approach that combines the best of these two using Self has a chance to get adopted. > > But if it were your goal is to change the > > world(in your case it isn't), > > Actually, it is. In fact, I intend to change it twice in a row just so > that nobody can claim I just got lucky. For me, just the fact that I can run Self and Smalltalk on my Macintosh Powerbook and that we are here discussing them is an outstading success for all these things. - sekhar -- C. Ramakrishnan cramakrishnan(a)acm.org

2 1

New release of Cel - Ver. 0.7
by Dru Nelson 26 Apr '01

26 Apr '01

Small blurb.... Dru Nelson San Mateo, California http://www.redwoodsoft.com/cel/ Apr. 23, 2001 - Release 0.7 Runtime: MAJOR: Added floating point number support MAJOR: Bug fix with large memory processes Integer - more methods Arrays - more methods, mathematical 'set' methods Strings - comparison methods, CSV (comma separated value) conversion method 'splitCSV:', 'findLast:', as well as 'at:', and 'removeAt:' methods Boolean - printing Scripts can now have '#!/usr/local/bin/cel' in the first line so they can be standalone shell executables Reflection/meta-methods 'hasSlot:', 'getSlot:', 'removeSlot:' The 'perform:' and 'perform:With:' methods were added Larger buffer for environment, argv conversion (helpful for CGI) Better handling of nil VM: added setStackAt() Bug in passthru methods in blocks fixed Bug in code generator fixed for empty objects and blocks Other small bug fixes Kits: DateTime - added more conversion routines from strings OS - raw OS methods for file reading and file locking FileIO - methods for file object reading and file locking HTTPClient - small fixes HTML - small kit to render html pages CGI - small kit to deal with the CGI API SleepyCat - created kit with cursors Parallel - created kit for running methods in parallel (this kits holds more specific kits) ParallelProcess - specific kit that runs methods in parallel processes (the granularity is at the process level) Other: More samples and tests Dru Nelson San Mateo, California

2 2

OO future (was: An OO history)
by Jecel Assumpcao Jr 24 Apr '01

24 Apr '01

On Monday 23 April 2001 17:05, Steve Dekorte wrote: > On Tuesday, April 17, 2001, at 11:33 AM, Jecel Assumpcao Jr wrote: > > [...] I have found it nearly > > impossible to change people's minds, to "covert" them... > > Right, that's the problem I'm getting at. It seems there's so many > great technologies/ideas that sit on the shelf because inventors > don't understand marketing. It's been said that in engineering there > are no technical problems, only people problems. For those of us that > want to see the innovations of Smalltalk and Self in widespread use, > our biggest problem isn't technological. It's figuring out how to get > people to use new technologies. Easy: get everyone around them to use them. Most people go with the crowd. Obviously, this leads to a recursive bootstrap problem :-( To solve this problem, I am targetting schools which want to look more modern than the others. If all students in a class get a new computer on the same day, then they will be using what everyone around them is using without any of them having to be the "early adopter". > >> In my experience, most developers find Smalltalk style code very > >> difficult to read. > > > > That is very interesting to know. What is their background, in > > general? > > C, C++, Java or JavaScript. (I think most developers have such a > background.) I would have expected that. Many people from a Wirth language background can't read C derived languages. See Oberon and Delphi fans for example. This is silly - everyone should be required to write 3 good programs in APL and 4 in Lisp before being allowed to call themselves programmers... > That's a good point. But then you have to ask, why where those > choices made > by Netscape or Sun, etc? Since I have to, "why were those choices made by Netscape and Sun?" I suppose you mean a C-like syntax for Java? Everybody was doing it then (see Renderman and others from those days) just as everyone was doing Pascal looking languages the previous decade. It made sense for Sun, as a Unix shop. It made sense for Netscape, which probably wrote all its code in C. But I bet if Java had been Python-like and Sun and Netscape had pushed it, it would be almost as popular as it is now. Just a guess, of course. > > The problem with your theory is that many innovations work much > > better together than in isolation. > > I think it depends on your market. If you're after the .01% of > developers that are into neat new things, then packaging more neat > new things makes sense. I mean like: persistent objects and capability based security. Adding just one of these to system is far from half as good as adding both at the same time. I am talking about synergy. > But if it were your goal is to change the > world(in your case it isn't), Actually, it is. In fact, I intend to change it twice in a row just so that nobody can claim I just got lucky. > you may be after the wrong market. It > might inspire the folks who do change things, but those changes may > only be accepted in a piece meal way anyways and not in order of > importance. But consider a person's first computer - there is no possibility of a piece meal change. > As examples consider the Alto vs the Mac or the Newton vs. the Palm. Alto - cost over $20k and Xerox never tried to sell it. Mac - $2500 Newton - every time a model dropped below $1000 it was eliminated. Jobs killed it because it reminded him of Sculley. Palm - $400 and lower and the batteries lasted a long time And Dru Nelson asked: > What about the Mac vs. the PC? I guess that would support Steve's thesis: the Mac was a whole change and the PC reached the status of a Mac-clone in a piece meal fashion. -- Jecel

1 0

Re: [self-interest] Re: An OO history
by Dru Nelson 24 Apr '01

24 Apr '01

What about the Mac vs. the PC? Dru Nelson San Mateo, California On Mon, 23 Apr 2001, Steve Dekorte wrote: > > As examples consider the Alto vs the Mac or the Newton vs. the Palm. > > Steve

1 0

Re: [self-interest] Re: An OO history
by Jecel Assumpcao Jr 23 Apr '01

23 Apr '01

On Monday 16 April 2001 19:57, Steve Dekorte wrote: > Jecel Assumpcao Jr wrote: > > Not, ironically enough, the two "tinySelf" implementations I did. > > Interesting, what was your primary goal? I had two goals - to study how a parallel version of Self could be made compatible with the sequential one and to move as much of the implementation as possible into Self. The "tiny" was there just in case somebody complained that something was missing :-) > > Define "people". [...] > 10% of the developers in one of the top 5 application spaces - > desktop, web, servers, embedded, OS Ok, my point was that this varies with time. The same people who are 40% of the developers in some area today could be just 6% in that same area in five years (if the area is not growing, it probably isn't worth me worrying about it). I have found it nearly impossible to change people's minds, to "covert" them. So I focus on the newcomers knowing that some day they will be the majority. Of course, these newcomers usually look to the people I am ignoring for advice and direction :-( > In my experience, most developers find Smalltalk style code very > difficult to read. That is very interesting to know. What is their background, in general? > If this is true, then you have to be very careful about prioritizing > which innovations you choose to visibly employ if you care about > making something that "changes the world". I would say that neither Java nor JavaScript were accepted because of what they were (unlike Perl or Python) but because of who was pushing them (Netscape, in both instances). The same thing will make C# have its place in the sun no matter what. The problem with your theory is that many innovations work much better together than in isolation. -- Jecel

2 1

Re: Re: An OO history
by John Hinsley 17 Apr '01

17 Apr '01

Steve Dekorte <steve(a)dekorte.com> wrote > In my experience, most developers find Smalltalk style code very > difficult to read. I think it depends on where they're coming from. I can imagine an experienced C or C++ programmer looking at Smalltalk code and finding it completely incomprehensible, just as an experienced Perl programmer would find Python a mystery. But I'd maintain that if we use the nearest we can find to an objective viewpoint (that of a complete neophyte) then they would find the cleaner coding of Smalltalk or Python (and the more directly OO nature of either) a big advantage. And, then again, Smalltalk is so wonderfully reflective, which is a notion that seems to confuse a lot of people coming from C or Java. Historically it seems to have been particulary successful with kids. John -- ****************************************************************************** Marx: "Why do Anarchists only drink herbal tea?" Proudhon: "Because all proper tea is theft." ******************************************************************************

2 1

Re: [self-interest] Re: An OO history
by Jecel Assumpcao Jr 17 Apr '01

17 Apr '01

Steve Dekorte wrote: > I think a "Little Self" that was as "small" and at least as fast as > the common web scripting languages(Python, Perl) would give the > language it's best shot at getting widespread use. I guess that may > have never been a goal of the original Self project, but it seems to > me that it is the shared goal of all these other Self > implementations. Not, ironically enough, the two "tinySelf" implementations I did. But I do like small stuff (not as fanatically as Chuck Moore who feels any program must fit in 1K) and will send a separate email to this list with my current idea for an object model suitable for little implementations. > > Language elements in general, but syntax most of all, are a matter > > of taste, so it makes no sense to talk about making it better or > > worse. > > It does if you value people choosing to use the language. Define "people". I can claim the C-like syntax in Java has cause many people to reject it in favor of the more Pascal-like Delphi, and I would be correct. For people who are starting out or have a C background, this isn't a problem at all. > Syntax seems to have been a barrier to the general use of the most > technically advanced high level languages (Lisp and Smalltalk). Would > we have had to wait 20 years to see things like garbage collection > used in a mainstream language if these languages hadn't been so > ambitious? I would say that Beta is the language that has suffered the most due to its syntax. Lisp has certainly turned away many people with its parenthesis and attracted others. Given the people in those two groups, I would say it was a net gain for the language. I am not away of people who really have had problems with the Smalltlak syntax. > It's interesting that the two languages of the web are split on > their adoption of these two innovations of Self - JavaScript got a > proto object model and Java got some of the compiler technology. Was JavaScript influenced by Self at all? I meant like NewtonScript was. -- Jecel

2 1

simple object model
by Jecel Assumpcao Jr 17 Apr '01

17 Apr '01

I am still thinking about a simple object model. I am working at a low level, like the C++ structures in Self 4.1.2, and not a high level language object model like in Self or Smalltalk. The idea is to be able to build these high level models using what I am proposing and the application programmer wouldn't have to be aware of this. Another detail is that the simple text representation I will use in this email is obviously missing a lots of stuff (I will only use simple literal values instead of complex expressions) but that is ok since it is supposed to be created by tools instead of directly typed in. ---------------------- An object has three parts: ( <indexed values> | <named values> | <helper objects> ) These will be explained below, but I should first mention that any of these parts can be missing. A very simple vector object, for example, might have nothing but the indexed values: ( 1 1 2 3 5 8 13 21 | | ) is a vector with 8 indexed values, accessed with indexes 0 through 7. The trailing "|" separators can be omitted in cases like this: ( 1 1 2 3 5 8 13 21 ) is exactly the same object. The "helper objects" supply the names for the "named values" in their indexed values section - here is the classic 2d point: ( | 3 4 | ( 'x' 'y' ) ) It has one helper object that is a simple 2 element vector. The point itself doesn't have any indexed values, and the name of the first named value (3) is taken from the first indexed value of the helper object ('x'). The helper objects can be more complex than this, however: ( | 3 4 | ( 'x' 'y' | 3.14 <some code> | ( 'pi' '+' ) ) ) Too much like Lisp? :-) Sorry - a drawing would be much more understandable. Aligning the indexed values of the helper objects with the named values of the "main" object also helps a little: ( | 3 4 | ( 'x' 'y' | 3.14 <some code> | ( 'pi' '+' ) ) ) Still very much like Lisp.... and it would be much more complicated if I showed what <some code> was really like. Anyway, the whole point is that the look up algorithm recurses into the helper objects when looking for a name, so that the point in the example can understand the messages 'x', 'y', 'pi' and '+'. In this simple model everything is made of the same kind of stuff, yet it can be used to emulate Self, the various Smalltalks, NewtonScript and probably other interesting languages as well. This is simple enough that small implementations can be created, though I am more interested in high performance ones. One more example - if there are no helper objects but the object does have named values, then it is used as its own helper object: ( 'x' 'y' | 3 4 ) So very simple objects can be self describing. The advantage of the first point example is that it only takes up 3 words when cloned, while this one takes up 4. I said this was a low level thing. -- Jecel

1 0

Re: [self-interest] Re: An OO history
by Samantha Atkins 15 Apr '01

15 Apr '01

Steve Dekorte wrote: > > Interesting, what's the smallest Self could be squeezed into and still > be useful? > Would a 100K version be possible than ran as fast as other scripting > languages like Python? The Ruby scripting language has become very > popular as a web scripting language despite the fact that it uses a > Smalltalk like syntax. Maybe Self could become a popular scripting > language if it was less monolithic. > > Ruby does not use a "Smalltalk-like syntax". - samantha

4 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest April 2001