Hi there,
I got interested in Smalltalk because of Redline project, but I am having a hard time trying to learn it. This project is planning to spent some effort on documentation, tutorials etc? My problem is that what work on one distribution does not work on another, and it is not clear to me what is the correct basic mechanism (despite the fact that it involves message passing) to do something. How do I create a new class, how do I add methods to it, how to create instance variables, how to instantiate a new object populating these variables and so on. I am still not sure, for example, of the correct mechanism to create a new class, I think I saw three ways already. Most documentation is coupled to some environment, or distribution, and although I understand that smalltalk is more of an environment than a language, I don't understand why the different parts of that environment, been one of them the language, can't be taught separately in consistent way, i.e., so that what I learn can be used in all distributions. What is the basic Smalltalk, that something that works in all Smalltalk implementations? I can't find this, and it is making the process of learning very difficult and frustrating, at least for me. Or maybe I am doing something wrong, but I really don't know more where to look in order to learn Smalltalk. :( []s, Vitor |
Hi Victor,
Redline will help - give us some time to organise some information. - James Sent from Hyperspace. On 10/12/2012, at 8:21 AM, Vitor Cruz <[hidden email]> wrote: > Hi there, > > I got interested in Smalltalk because of Redline project, but I am having a hard time trying to learn it. This project is planning to spent some effort on documentation, tutorials etc? > > My problem is that what work on one distribution does not work on another, and it is not clear to me what is the correct basic mechanism (despite the fact that it involves message passing) to do something. How do I create a new class, how do I add methods to it, how to create instance variables, how to instantiate a new object populating these variables and so on. I am still not sure, for example, of the correct mechanism to create a new class, I think I saw three ways already. Most documentation is coupled to some environment, or distribution, and although I understand that smalltalk is more of an environment than a language, I don't understand why the different parts of that environment, been one of them the language, can't be taught separately in consistent way, i.e., so that what I learn can be used in all distributions. What is the basic Smalltalk, that something that works in all Smalltalk implementations? I can't find this, and it is making the process of learning very difficult and frustrating, at least for me. Or maybe I am doing something wrong, but I really don't know more where to look in order to learn Smalltalk. :( > > []s, > Vitor |
In reply to this post by Vitor Medina Cruz
Victor,
In most Smalltalks, you use the development environment to help you create classes and methods. Redline will likely be different (unless you use the IntelliJ plugin), as is GNU Smalltalk. Because all Smalltalks tend to differ in their environment, it makes this first step a little more difficult, as you're finding.
In most Smalltalks, you have a tool called the "Browser" that generally provides menu choices or similar for creating classes and methods, or at the very least a code pane with a template to fill in. These tools/templates do simply result in message sends, but they help you by providing the correct messages to send, etc.
To create instance variables, you define them within the class definition message. To instantiate a class and populate its instance variables, there are many ways you can do that, like in most languages. One common way comes from Kent Beck's Smalltalk Best Practice Patterns. I'll use a simply 2-D Point class below as an example, though Point is typically already defined in most or all Smalltalks.
* Define the Point class using the browser. Give it two instance variables, x and y. * On the "class side" of Point (typically chosen by some kind of tab selector that will show at least Instance and Class), define the following method:
x: xValue y: yValue ^self new setX: xValue y: yValue * On the "instance side" of Point, define the following method: setX: xValue y: yValue
x := xValue. y := yValue You will also want to define other methods for Point instances depending on your domain. You can then use your new Point class in other code, or in a workspace (which is somewhat analogous to a REPL loop in other languages):
myPoint := Point x: 2 y: 5. There are actually quite a few introductory screencasts available for a number of different Smalltalks. Google for "Smalltalk screencast" and you'll find a bunch.
I'll be the first to admit that Smalltalk has a bit of a steep learning curve at the beginning, but it's worth climbing that curve, because it will change the way you write code forever (in a good way), even if you never get to use it "for real".
If my explanation above just raises more questions for you, feel free to ask more questions. I'll do my best to answer them as I can. My answers will typically not be Redline-specific, because I haven't had time to try it out lately, and so what I know about it will be dated and likely wrong.
Randy On Sun, Dec 9, 2012 at 1:21 PM, Vitor Cruz <[hidden email]> wrote: Hi there, Randy Coulman [hidden email] Twitter: @randycoulman |
In reply to this post by Vitor Medina Cruz
A resource I think is particularly insightful is the learn-as-you-do "Learn Smalltalk with Profstef":
HTH, Les |
James
Nice! Les Yes, I already learned with Profstef, and the problem remains, what I learned from ProofStef seemed to me very much tied to ProfStef, and I had difficulties to replicate somethings I learned there on Redline and GnuSmalltalk. Also, many things ProfSef teach I had already see on others textbooks and articles. Randy " Because all Smalltalks tend to differ in their environment, it makes this first step a little more difficult, as you're finding." I think that it is even worse, it make Smalltalk a much more less compelling language to learn :( . It seams that Smalltaks are made of several feuds, and it is not clear how or if those can talk with each other, or what is the basic set of "things" that every feud has. I fell like I have to learn a lot of accidental aspects of the Smalltalk environment (like IDEs, browsers etc) before I can understand the interesting essential aspects (Image, dynamic creation of classes, keywords, objects and messages etc) "I'll be the first to admit that Smalltalk has a bit of a steep learning curve at the beginning, but it's worth climbing that curve, because it will change the way you write code forever (in a good way), even if you never get to use it "for real"." Yes, but I really think that this had not to be like this. I learned the basics of the language and the design principles in less than an afternoon, and I got amazed on how so little and easily understandable concepts could offer so much power (or, at least, it is very easy to envision the power of the language). But when it gets operational, i.e., when I started to try more things out with more advanced constructs to see what I really could do with the language, I got stuck by the reasons already exposed. I think it is just a matter of how Smalltalk is exposed that makes it have a steep learning curve, I might be wrong, but that is my feeling :) Thanks for the responses, Vitor On Tuesday, December 11, 2012 1:47:46 AM UTC-2, Les Hazlewood wrote: A resource I think is particularly insightful is the learn-as-you-do "Learn Smalltalk with Profstef": |
We need a prof Stephanie does redline - will look into it Sent from Hyperspace.
|
In reply to this post by Vitor Medina Cruz
On Sunday, December 9, 2012 2:21:34 PM UTC-7, Vitor Cruz wrote:
Hi there, Hi Vitor, One of the main problems you run into between more traditional image based Smalltalk implementations (Pharo, Squeak, Visualworks,etc.) and Redline, is that the other implementations are not meant to be programmed declaratively, but through the IDE. Redline is declarative so as to take advantage of the tools that modern programmers are familiar with and leverage those tools whenever possible. As you mention, everything in Smalltalk is predicated on message passing; here is a concrete example from Pharo compared to Redline: Creating a class in Pharo:
so the message subclass:instanceVariableNames:classVariableNames:poolDictionaries:category is defined on the "Class" class, and in the normal course of things you can just change the value of #NameOfSubclass to your own class name, change the category and accept it in the IDE. That creates a class. That is very verbose, and would be painful if you had type that in every time you wanted a class... in my mind like java's public static final void main(String[] args) line noise. So Redline, on the other hand, makes quite a bit easier to deal with:
This says: create a subclass of Object called MyCoolClass. Also, in the Pharo IDE, there are buttons on the system browser to switch between the class side and instance side of a class to look at class methods (static methods in java) or instance methods, respectively. In Redline, you define whether is method is a class method or an instance method by having a "+" or "-" as the beginning of a method definition. For example:
creates an instance method for the class that can only be called on an instance of the class, but:
could only be called on the Class itself, and would return a new instance of MyCoolClass. Ask more questions, and I'll try to answer them :) (*disclaimer - I'm brand new to Redline, but not to Smalltalk. Please point out any errors in my explanations!) - Brian |
> so the message
> subclass:instanceVariableNames:classVariableNames:poolDictionaries:category > is defined on the "Class" class, and in the normal course of things you can > just change the value of #NameOfSubclass to your own class name, change the > category and accept it in the IDE. That creates a class. That is very > verbose, and would be painful if you had type that in every time you wanted > a class... in my mind like java's public static final void main(String[] > args) line noise. So Redline, on the other hand, makes quite a bit easier > to deal with: > > Object < #MyCoolClass. It should be noted here that '<' is still a message to the Object class: it is just a convenience message that in turn calls the more traditional subclass:instanceVariableNames:... message. Here's the '<' implementation: - < name ^ self subclass: name instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' classInstanceVariableNames: ''. This illustrates one of the many beautiful things about Smalltalk: the '<' message isn't a Redline-specific syntax operator for example; it's just a convenience message that you can use to make your life easier. If you want to write Smalltalk-80-standard subclass definitions, you can use the more verbose message, or you can choose the less verbose Redline '<' message - it's up to you. Cheers, Les P.S. On a side note, my preference would actually be to have another convenience message, just 'subclass', e.g.: - subclass: name ^ self subclass: name instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' classInstanceVariableNames: ''. So you could do: Object subclass: #Foo ... I prefer this because it is more readable, more inline with Smalltalk tendencies for natural language usage and less confusing to new people: The '<' character is often interpreted by most as 'less than' or 'pipe into'. The more non-intuitive operators there are, the less 'Smalltalky' it is IMO. |
Hi Les, please can you add #subclass: and issue a pull request?
Then you can write classes the way you describe without adding methods to Object at runtime. Adding #subclass: and some other variations is on the Todo list. - James Sent from Hyperspace. On 29/12/2012, at 5:33 AM, Les Hazlewood <[hidden email]> wrote: >> so the message >> subclass:instanceVariableNames:classVariableNames:poolDictionaries:category >> is defined on the "Class" class, and in the normal course of things you can >> just change the value of #NameOfSubclass to your own class name, change the >> category and accept it in the IDE. That creates a class. That is very >> verbose, and would be painful if you had type that in every time you wanted >> a class... in my mind like java's public static final void main(String[] >> args) line noise. So Redline, on the other hand, makes quite a bit easier >> to deal with: >> >> Object < #MyCoolClass. > > It should be noted here that '<' is still a message to the Object > class: it is just a convenience message that in turn calls the more > traditional subclass:instanceVariableNames:... message. > > Here's the '<' implementation: > > - < name > ^ self subclass: name instanceVariableNames: '' > classVariableNames: '' poolDictionaries: '' > classInstanceVariableNames: ''. > > This illustrates one of the many beautiful things about Smalltalk: the > '<' message isn't a Redline-specific syntax operator for example; it's > just a convenience message that you can use to make your life easier. > > If you want to write Smalltalk-80-standard subclass definitions, you > can use the more verbose message, or you can choose the less verbose > Redline '<' message - it's up to you. > > Cheers, > > Les > > P.S. On a side note, my preference would actually be to have another > convenience message, just 'subclass', e.g.: > > - subclass: name > ^ self subclass: name instanceVariableNames: '' > classVariableNames: '' poolDictionaries: '' > classInstanceVariableNames: ''. > > So you could do: > > Object subclass: #Foo > ... > > I prefer this because it is more readable, more inline with Smalltalk > tendencies for natural language usage and less confusing to new > people: The '<' character is often interpreted by most as 'less than' > or 'pipe into'. The more non-intuitive operators there are, the less > 'Smalltalky' it is IMO. |
In reply to this post by Brian Brown-5
Brain - great response - thank you.
On Sat, Dec 29, 2012 at 4:33 AM, Brian Brown <[hidden email]> wrote:
|
In reply to this post by James Ladd
Sure thing James - I'd be happy to.
Cheers, Les On Fri, Dec 28, 2012 at 12:22 PM, James Ladd <[hidden email]> wrote: > Hi Les, please can you add #subclass: and issue a pull request? > Then you can write classes the way you describe without adding methods to Object at runtime. > Adding #subclass: and some other variations is on the Todo list. > - James > > Sent from Hyperspace. > > On 29/12/2012, at 5:33 AM, Les Hazlewood <[hidden email]> wrote: > >>> so the message >>> subclass:instanceVariableNames:classVariableNames:poolDictionaries:category >>> is defined on the "Class" class, and in the normal course of things you can >>> just change the value of #NameOfSubclass to your own class name, change the >>> category and accept it in the IDE. That creates a class. That is very >>> verbose, and would be painful if you had type that in every time you wanted >>> a class... in my mind like java's public static final void main(String[] >>> args) line noise. So Redline, on the other hand, makes quite a bit easier >>> to deal with: >>> >>> Object < #MyCoolClass. >> >> It should be noted here that '<' is still a message to the Object >> class: it is just a convenience message that in turn calls the more >> traditional subclass:instanceVariableNames:... message. >> >> Here's the '<' implementation: >> >> - < name >> ^ self subclass: name instanceVariableNames: '' >> classVariableNames: '' poolDictionaries: '' >> classInstanceVariableNames: ''. >> >> This illustrates one of the many beautiful things about Smalltalk: the >> '<' message isn't a Redline-specific syntax operator for example; it's >> just a convenience message that you can use to make your life easier. >> >> If you want to write Smalltalk-80-standard subclass definitions, you >> can use the more verbose message, or you can choose the less verbose >> Redline '<' message - it's up to you. >> >> Cheers, >> >> Les >> >> P.S. On a side note, my preference would actually be to have another >> convenience message, just 'subclass', e.g.: >> >> - subclass: name >> ^ self subclass: name instanceVariableNames: '' >> classVariableNames: '' poolDictionaries: '' >> classInstanceVariableNames: ''. >> >> So you could do: >> >> Object subclass: #Foo >> ... >> >> I prefer this because it is more readable, more inline with Smalltalk >> tendencies for natural language usage and less confusing to new >> people: The '<' character is often interpreted by most as 'less than' >> or 'pipe into'. The more non-intuitive operators there are, the less >> 'Smalltalky' it is IMO. |
Just sent the pull request.
On Fri, Dec 28, 2012 at 3:32 PM, Les Hazlewood <[hidden email]> wrote: > Sure thing James - I'd be happy to. > > Cheers, > > Les > > On Fri, Dec 28, 2012 at 12:22 PM, James Ladd <[hidden email]> wrote: >> Hi Les, please can you add #subclass: and issue a pull request? >> Then you can write classes the way you describe without adding methods to Object at runtime. >> Adding #subclass: and some other variations is on the Todo list. >> - James >> >> Sent from Hyperspace. >> >> On 29/12/2012, at 5:33 AM, Les Hazlewood <[hidden email]> wrote: >> >>>> so the message >>>> subclass:instanceVariableNames:classVariableNames:poolDictionaries:category >>>> is defined on the "Class" class, and in the normal course of things you can >>>> just change the value of #NameOfSubclass to your own class name, change the >>>> category and accept it in the IDE. That creates a class. That is very >>>> verbose, and would be painful if you had type that in every time you wanted >>>> a class... in my mind like java's public static final void main(String[] >>>> args) line noise. So Redline, on the other hand, makes quite a bit easier >>>> to deal with: >>>> >>>> Object < #MyCoolClass. >>> >>> It should be noted here that '<' is still a message to the Object >>> class: it is just a convenience message that in turn calls the more >>> traditional subclass:instanceVariableNames:... message. >>> >>> Here's the '<' implementation: >>> >>> - < name >>> ^ self subclass: name instanceVariableNames: '' >>> classVariableNames: '' poolDictionaries: '' >>> classInstanceVariableNames: ''. >>> >>> This illustrates one of the many beautiful things about Smalltalk: the >>> '<' message isn't a Redline-specific syntax operator for example; it's >>> just a convenience message that you can use to make your life easier. >>> >>> If you want to write Smalltalk-80-standard subclass definitions, you >>> can use the more verbose message, or you can choose the less verbose >>> Redline '<' message - it's up to you. >>> >>> Cheers, >>> >>> Les >>> >>> P.S. On a side note, my preference would actually be to have another >>> convenience message, just 'subclass', e.g.: >>> >>> - subclass: name >>> ^ self subclass: name instanceVariableNames: '' >>> classVariableNames: '' poolDictionaries: '' >>> classInstanceVariableNames: ''. >>> >>> So you could do: >>> >>> Object subclass: #Foo >>> ... >>> >>> I prefer this because it is more readable, more inline with Smalltalk >>> tendencies for natural language usage and less confusing to new >>> people: The '<' character is often interpreted by most as 'less than' >>> or 'pipe into'. The more non-intuitive operators there are, the less >>> 'Smalltalky' it is IMO. |
In reply to this post by Brian Brown-5
Thanks Brian
Some questions: How do I define instance or class variables using '<' ? I saw some class implementations, but I didn't understand them very well. Let's see Array.st, for instance: " Redline Smalltalk, Copyright (c) James C. Ladd. All rights reserved. See LICENSE in the root of this distribution " ArrayedCollection < #Array. + new: sizeRequested <primitive: 221> - add: newObject self shouldNotImplement. It seams that + and - are not messages sent to the newly created Array, I would expect something like this: ArrayedCollection < #Array. Array + new: sizeRequested <primitive: 221> Array - add: newObject self shouldNotImplement. But that is also strange (the message does not fell right here). It seams that method definition do not comply to the message passing mechanism, and I don't understand exactly how it work. Can someone explain it? How do I put this all together and run in redline Smalltalk? I tried to put the class and method definition in a st file and run with stic but that didn't work. There is no reference, book, tutorial or article that explains Smalltalk language untied from the environment that you can point out to me? []s, Vitor PS: I agree that subclass: is better than <. :) On Friday, December 28, 2012 3:33:26 PM UTC-2, Brian Brown wrote: On Sunday, December 9, 2012 2:21:34 PM UTC-7, Vitor Cruz wrote:Hi there, |
Hi Vitor, answers inline below
On Saturday, December 29, 2012 7:07:07 AM UTC-7, Vitor Cruz wrote: Thanks Brian Like so:
This is the example you find in InstVarParent.st in the examples folder.
No, they are not - they are the definition of the methods on the array class, just like a class definition in a .java file. To create an instance of the Array class you would do something like (I haven't tested it):
It seems you are confusing design time and run time. These definitions in the files get evaluated when a program that is running references them. If you run a file, like:
.... nothing happens that you can see. If you add a "-v" before the "-s", you'll see a ridiculous amount of output; all the work that is going on. But why do we see nothing with running ArrayTest? Because it only defines a class and methods, meant to be instantiated and run by someone else. In this case, it's going to be:
This will output the following:
So ArrayTest is run as part of that. If you take a look at target/redline-deploy/examples/st/redline/TestRunner.st, you can see how it runs the code in ArrayTest.st - and you will follow the bouncing ball and look at TestSuite.st in the same folder to see the meat of the code. Please notice that classInstanceVariableNames and poolDictionaries aren't implemented yet. As a matter of fact, there are a lot of things that aren't implemented yet, and that is what the major push for Redline is at the moment; getting the core stuff implemented. This means you may be frustrated trying to work with Redline for the time being.
For now, make a folder a folder redline-deploy/examples/st/vitor and put your files in there. Then run them like:
for the st file redline-deploy/examples/st/vitor/MyTest.st
No, not really. If you look around, you can see quite a view versions of Smalltalk, but most of them have the environment and an image file, so the tutorials and such are geared toward that. This is one of the things that makes it hard for developers to adopt Smalltalk - not only do you have to learn new syntax, libraries, etc, you also have to adapt to strange environment and learn about System Browsers, Transcripts, Workspaces, do-its, etc. If you just want to get familiar with Smalltalk, then play with Pharo and use all the great resources they have available. Most importantly the two books reference here: http://www.pharo-project.org/documentation/tutorials-books Don't get me wrong, I'm not trying to scare you away, just keep in mind that this project is not mature compared to other Smalltalks I've mentioned. Hope that helps, - Brian
|
Hey Brian - Great explanation - You write very well.
Hey Vitor - In a traditional environment like say Pharo Smalltalk you don't see a full Smalltalk class in one view unless you file it out into a file. That file looks very different too. The idea of -/+ was to make defining a methods simple and not to have distracting noise around it. For example if you browsed the 'yourself' method in Pharo you would see something like the following as the method source. yourself ^ self To make this as similar as possible Redline we added -/+ to indicate if the method is an instance method '-' or a class method '+'. The 'yourself' method above looks like this in Redline: - yourself ^ self. It is my style to put a '.' at the end of the expression although it is not necessary. When the source file if preprocessed the methods are turned into the following: Object atSelector: #yourself put: [ ^ self. ]. You are welcome to do this in your own source files. Note if 'yourself' were a class method then the above would be: Object class atSelector: #yourself put: .... - James. On Sun, Dec 30, 2012 at 6:05 AM, Brian Brown <[hidden email]> wrote: Hi Vitor, answers inline below |
Hi,
Sorry the delay. "It seams that + and - are not messages sent to the newly created Array, I would expect something like this: No, they are not - they are the definition of the methods on the array class, just like a class definition in a .java file. Hey Vitor - In a traditional environment like say Pharo Smalltalk you don't see a full Smalltalk class in one view unless you file it out into a file. That file looks very different too. The idea of -/+ was to make defining a methods simple and not to have distracting noise around it." So, this is not Samlltalk, it is Redline syntax, right? Why do you see the necessity of this once you have a Smalltalk construct for this? Object atSelector: #myselector put: [ ^ self. ]. Do you think people coming from Java, for example, will understand it better? And, even if you do see the need to such thing, why not use the language itself to accomplish this? "No, not really. If you look around, you can see quite a view versions of Smalltalk, but most of them have the environment and an image file, so the tutorials and such are geared toward that. This is one of the things that makes it hard for developers to adopt Smalltalk - not only do you have to learn new syntax, libraries, etc, you also have to adapt to strange environment and learn about System Browsers, Transcripts, Workspaces, do-its, etc. " Yes. It is very frustrating because one of the arguments of the language is to have few rules so that people can better use and understand it. I totally agree, and the first tutorials I read (very focused on the language) were very simple to understand and I started to imagine all the things I could do with the language, and then... I had to deal with the IDEs and all of its rules and uninteresting things that get in the way.... "If you just want to get familiar with Smalltalk, then play with Pharo and use all the great resources they have available. Most importantly the two books reference here: http://www.pharo-project.org/documentation/tutorials-books" I had already, but I didn't went too far. I decided not to learn one of this IDEs because I think this is not going anywhere (and frankly, it bored me). I turned into GNUSmalltalk and Redline because I think they are in a better route and that I have more chance to learn what I think is more essential about Smalltalk. :) On Saturday, December 29, 2012 7:08:47 PM UTC-2, jamesl wrote: Hey Brian - Great explanation - You write very well. |
>> So, this is not Samlltalk, it is Redline syntax, right? Why do you see
the necessity of this once you have a Smalltalk construct for this?
Object atSelector: #myselector put: [ ^ self. ]. Yes it is Redline syntax. However you can use the form above if you wish. Both of which are more succinct that the 'chunk file format' of other Smalltalks. >> Do you think people coming from Java, for example, will understand it better? And, even if you do see the need to such thing, why not use the language itself to accomplish this? I think that people from other backgrounds will understand it better. I also think that those Smalltalkers used to the Smalltalk environment will appreciate that to write a class in a single file they don't have to work harder, just add a -/+ Again - you can write in the style you wish. Redline will use a minimal amount of shorthand. For example, we no longer have "import: 'thing'", we now use "self import: 'thing'" to make sure it is more Smalltalk like. The method definitions however will use the short hand. - James. On Mon, Jan 21, 2013 at 9:03 AM, Vitor Cruz <[hidden email]> wrote: Hi, |
>> So, this is not Samlltalk, it is Redline syntax, right? Why do you see the necessity of this once you have a Smalltalk construct for this? Ok, the only thing that confused me was that I could not understand those shorthands as methods definitions for the newly created class. For example, in Java I have: class MyClass{ //method definition goes here } It is pretty clear that the method belongs to the class. In Smalltalk it looked like loose things in the code. Eventually I decided that they were methods definitions for the class, but it was not clear to me how they where related. When I use those redline shorhands it means that the file has the meaning of a class? So, I cannot do thigs like defining two classes in a file using - and +? Again - you can write in the style you wish. Redline will use a minimal amount of shorthand. - James.-- |
Ah I see.
There was a blog post of some other mention of the file format. That is where it was made clear that -/+ were method definitions. The convention is to not define more than one class in a file. So the shorthand works where you follow this convention. However, you can define more than one class in a file using the non-shorthand syntax. - James. On Sun, Jan 27, 2013 at 4:04 AM, Vitor Cruz <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |