Self-interest August 2009

self-interest@lists.selflanguage.org

13 participants
6 discussions

Funny thing when removing globals* slot from the lobby
by Niko Schwarz 15 Aug '09

15 Aug '09

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

2 3

KYP-KYS #1
by brassplume 15 Aug '09

15 Aug '09

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

2 1

Our two weapons are fear and surprise...and..
by brassplume 09 Aug '09

09 Aug '09

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". I think that's like saying "All the flavour of regular beer with half the calories." It's kind of a misrepresentation. I agree that the language it simple - semantically. But it's common to my point of view that languages that are semantically simple are: 1) capable of sophistication; 2) require a programmer to bring more knowledge and understanding of design. Lisp and Smalltalk are semantically simple. Their sophistication and the sophistication required of the programmer is in inverse relationship to that. 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. If you believe Self is the language of simpilicty you either: 1) Have lost all touch with what it means to be a beginner; or, 2) You are way too close to the language to see how it looks to people who program with other tools. I used to play a RPG called Paranoia. On the back cover is a message from the evil master computer: "You are in error. No one is screaming. Thank you for your cooperation." The way you describe Self reminds me of that. :p Chris

11 18

Re:Our two weapons are fear and surprise...and..
by Mario Wolczko 08 Aug '09

08 Aug '09

Weighing in a day late, as I only get the digest version... > If you believe Self is the language of simpilicty you either: 1) > Have lost all touch with what it means to be a beginner; or, 2) You > are way too close to the language to see how it looks to people who > program with other tools. I could not disagree more, and I have ample supporting data to prove my point. A long time ago (1987-1993), I taught Smalltalk to a large number of people (hundreds, in groups of ten). Experience levels varied from beginner (ie did not know any programming at all) to wizened graybeard. The beginners had the least problem with Smalltalk. As experience level increased, generally speaking difficulty increased, because too much mental energy was expended on either (a) trying to understand Smalltalk concepts in terms of the familiar ones of location, address, pointer, etc, or (b) trying to figure out how the implementation worked from first principles, or (c) [related to (b)] why it could never be efficient and hence would always be a toy and their jobs as C/S3/assembler/.. programmers were secure. There were exceptions, of course, but this trend was clear. When I left that position to join the Self group, my successors took on the task of using Self (UI1!) in place of Smalltalk to introduce object-oriented programming, and the data suggested that for beginners indeed the learning process was smoother. (I say "suggested" because the classes ran only a few times - not enough to draw statistically valid conclusions - but the anecdotal and numerical evidence was fairly convincing.) That's not to say that either system is simple. The point is that through a process of gradual disclosure the typical person can become an effective programmer, and they rarely encounter insurmountable obstacles, or have shocking surprises (with some notable exceptions, such as the metaclass hierarchy in Smalltalk). -Mario

2 1

LK thread continued
by brassplume 05 Aug '09

05 Aug '09

Hi Adam, Thank you for addressing my questions. "The way I usually think about it, classes are a fine idea; it's just the idea that "every object is an instance of a class" that causes trouble. The value of prototypes isn't that you suddenly organize your entire code base in this whole new completely-different way; it's that the core of the system becomes simpler and more flexible and easier to learn. That flexibility lets you use some fun new organizational patterns, but the good old "class" pattern is still an important one." You can't add flexibility without adding complexity. That's an axiom of language design. The more simple the language, the more responsibility is foisted on the programmer. The flexibility comes because you've put the Squeak methods on surfboards: they can go anywhere. And the emphasis on inheritance is by FAR a bigger deal and responsibility for the programmer. It offers huge possibilities such as multiple inheritance, but, again, that puts more emphasis on the programmer. I think learning Self will expose me to a toolkit that will teach me not only to be a better programmer, but why people are so confused when they try to use JavaScript. Implementing classical inheritance in JavaScript sucks ( http://javascript.crockford.com/protoypal.html ) and if JavaScript programmers could understand "Organizing Programs Without Classes", they'd be far less confused. Chris

1 0

Keeping several versions around
by Niko Schwarz 04 Aug '09

04 Aug '09

Hi! I am interested in keeping several versions of code living side by side in the same image. There is an implementation in Smalltalk, but I'd like to know if this could be done more elegantly using Self. The Smalltalk implementation is called Changeboxes, http://scg.unibe.ch/archive/papers/Denk07cChangeboxes.pdf. It essentially works by hooking into the compiler and then, upon every method compilation, NOT pushing the Class onto the stack, but rather a level of indirection which finds the correct version of the class. The idea is essentially the following. Imagine you just built a feature, and it works, let's say you just implemented Exponentiation using a while loop, that just multiplies a number with itself a given number of times. It works. But you find it slow. Now, you fork, and keep the old version around. You change the method, right there, you don't make a new method, you CHANGE the old one. But still, you keep the old one around. And then you run them side by side. The currently active branch might be the sped up algorithm, but you can still access the main trunk, so now you benchmark the two, and see if they yield the same results: [2 raisedTo: 100 ] timeToRunAndResult [[2 raisedTo:100] inBranch: #main] timeToRunAndResult So, how would you implement this version change with only little performance penalty? How does the lookup process work anyway and how can I hook into it? All the best, Niko raisedToThe: anInteger |res| res := 1. anInteger timesRepeat: [ res = res * self] ^ but it is slow. Now you fork, and keep the working version around, both for examination

3 4

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 August 2009