Various questions regarding pure OO (Getting set up WITHOUT an ide; Tutorials; The associated books) [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 6 years ago.

Improve this question

I've been wanting to get into a pure-OO language for a while now, but I'm put off by the fact that they all seem to demand an IDE and I can't find any good tutorials that aren't in video format.

I'm happy to use an IDE later, but I don't want to learn the language through one. What I'm looking for is a simple console interpreter or command-line compiler such as gcc, ghc, ghci and the python IDLE (yes, it's an IDE, but it's so minimalist that it may as well just be a commandline interpretter). I find that I learn a language faster, better and more comprehensively when I'm not trying to grapple with an IDE at the same time. So please, don't tell me that squeak is the only way to do it :P

I'm also looking for tutorials that are presented textually rather than visually. Again, I learn faster when I can stare at a page and read someone's sentance over and over tossing and turning it in my mind rather than having to pause a video, take it back 10 seconds, press play, do it again, and again, and again.

I'm interested in various languages with various degrees of OO-purity, and I plan to learn them all at some point. Any of the smalltalk dialects interest me, Self (an extreme prototype-oriented version of smalltalk (Very interesting, the more radical the better imo)), strongtalk, vanilla smalltalk (or some implementation which is as vanilla as you can get).

I'm interested in Eiffel as well, the code snippets I've seen make it seem very elegant and I've read that it actually was very innovative (introduced code-contracts and other such things). However I would give preference to a language from the smalltalk camp over one from the Eiffel side because Eiffel at face value seems to be a hybrid between OO and imperative programming. Similarly I'd rather avoid Scala (Hybrid OO and functional) and other hybrid languages. So no C#, Java, C++, D, python etc etc etc. I'm not dismissing these languages because I believe they are bad, it's just that I'm setting out to learn pure-OO and those languages are hybrid OO: Not really what I'm looking for.

Also, would anyone be able to recommend the official books? For smalltalk there's the "Blue book" AKA "Smalltalk-80: The Language and its Implementation". And for Eiffel there's "Eiffel: The Language". I ask because in my experience you can pick up so much by reading books written by the author of the language (see K&R the C programming language), and by reading books in general.

So yes, my questions: What pure-OO language would be good to start off with? How would I go about learning it without having to use an IDE? And is there an associated book written by the language author(s)?

Answer 1

As someone who has went through process of learning Smalltalk (at least to a decent degree), I can say that you are taking harder and riskier path, in a sense that some things may take much longer to clear up, or never actually do.

But, if you insist, you can download GNU Smalltalk, for which no GUI is a norm. It also contains all sources of the system written in Smalltalk in a chunk format and you can open your text editor on them and enjoy while slowly reading through the guts of the system.

You could also startup any other Smalltalk, like Pharo, and just stick with a workspace window - this is your equivalent of command line interpreter.

Pharo also includes ProfStef quick interactive tutorial on Smalltalk, which combines text instructions and evaluating Smalltalk expressions.

As for reading, there is Pharo By Example - free book that you can browse, download or buy hardcopy.

There is also a collection of free books in which I would recommend "Smalltalk-80: The Language and its Implementation" By Adele Goldberg and David Robson, if you are interested in the innards and detail of the language.

Late David N. Smith Smalltalk FAQ is also exelent resource.

So, there you go. And take advice, and give in to the Smalltalk IDE as soon as possible, since it makes understanding of Smalltalk much, much, faster.

Answer 2

It is not helpful to learn Smalltalk as just another language. You would be missing the point entirely.

Smalltalk's graphical environment is not just an IDE. The core of the system is simply objects. The interface provides various ways to create objects and interact with them. The language is just a convenient way to create messages to the objects. It is secondary to the objects themselves.

In other OO languages, you write your program, then you run it, which creates objects in memory. Not so in Smalltalk. You create objects in memory (e.g. class objects) and then send messages to e.g. add methods. But a class object is only created once, not every time you "run your program".

There is no such thing as "your program", in fact. There is no "main". It's just a world of objects, some longer-lived, some temporary. In fact, in the system there are objects that were created 30 years ago. Literally. The objects are just frozen to disk as a memory dump (a file which we call "image") and unfrozen later (possibly on a different machine).

That image, the world of objects, is the primary artifact in Smalltalk. There is a sources file, yes, but that's just a database of text snippets to not take up so much RAM. You cannot edit this file by hand (objects in the image use absolute file offsets into the sources file). You cannot re-create the system from the sources file - the system was bootstrapped a long time ago and from then on only modified.

It's true that superficially the Smalltalk GUI looks just like another IDE. No coincidence - Eclipse was originally written by Smalltalkers in Smalltalk. But there is the crucial difference that in regular IDEs you just manipulate text files. A text editor is a valid alternative for that. In Smalltalk, the GUI manipulates objects in memory. A text editor can not do that.

And as for what Smalltalk to use, I would recommend Squeak. Very friendly community, very nice environment, and subscribing to the original Smalltalk vision of creating a great personal computing environment for everyone.

Answer 3

Richard Gabriel gave a talk recently about a paradigm shift that occurred in the programming language community in the early 90s. He claims that most experts today are incapable of understanding many of the papers from the 80s. He has evidence to back this up. This was the first time he gave the talk, and he expects to give it many times, so I imagine that many parts of the talk will change. At first, he described this paradigm shift as engineering -> science, but then he described it as system -> language. I think that describing it as a shift from systems thinking to language thinking is a better description.

Richard Gabriel is a Lisp guy. (I'm a Smalltalk guy). Lisp is like Smalltalk in that there isn't a clear boundary between the language and the library that it uses. Arithmetic and control flow are in the libraries, not the language. (Well, Lisp has some in the language and some in the libraries, while Smalltalk has it all in the libraries, except that the compiler cheats and hard codes some of them, so there isn't really much difference in the end.) In Lisp, a program is an S-expression, and editing programs is editing S-expressions. In Smalltalk, a program is a collection of objects, and editing programs is editing objects. When you are programming, you are building a system, and you program with the system.

System thinking is different from language thinking. Language thinkers want a precise description of a language. They want a book that describes the whole thing, or (if they are academics) they want a formal semantics for the language. But system thinkers know that as soon as they start to use the system, it will change. They want to understand how the system works, but are prepared to look at the system itself to figure out the details.

These are two ways of thinking, and there are advantages and disadvantages of each. Smalltalk is a wonderful example of systems thinking. I think all software developers should know at least one system that exemplifies systems thinking. Lisp is good. Forth is another old example. Naturally, I think that Smalltalk is great and am happy to help people learn it but I think the importance of learning systems thinking is more important than the particular system you learn.

Unfortunately, learning a system is harder than learning a language. You have to do more than just learn the syntax, you have to learn the libraries, the patterns of naming and of coding, and usually the tools. (Which, if this is a system, are extensible.) That is one of the advantages of language thinking. But systems thinking has long-term advantages, because once you taylor the system to your needs then you can become very productive.

Answer 4

To lean smalltalk syntax, you need to read ONE page of text (see Syntax section on wiki http://en.wikipedia.org/wiki/Smalltalk). Now, to learn a smalltalk libraries and how to use them, you need to use browser not the text editor, otherwise your will just waste a lot of time.

I think that it is like factor of 10 difference in time, between trying to understand some code by reading in textual format and navigating it using browser and! debugger.

In smalltalk system a living objects could tell a lot about themselves and help you learn how to use them much faster than if you look at it as a static chunks of text, because you won't grasp the idea at all.

Answer 5

I've been playing with Squeak Smalltalk (and its close cousins, Pharo and Cuis) for a while now. There's no better way to learn Smalltalk than by using the system already provided.

I've devised a series of short youtube tutorials ranging in length from 50 seconds to 15 minutes that show how to take advantage of Squeak's ultra-cool features within a few minutes of first starting the system.

In fact, the very first line of code demos the OOP-ness of Squeak. Squeak from the very start

Answer 6

Python is a pure OOP . Actually this is an easy mistake that newcomers make when they come to python.

Python like smalltalk follows the mantra "Everything is an object". So everything inside python is an object, including built-in types. The difference is that python unlike smalltalk and Java does not force OOP as it allows procedural programming. And this is the trap, it easy to assume that makes python less OOP , but being a snake, is so devlish that does not tell you that even functions are objects ;)

http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch10s04.html

Going back to smalltalk its IDE is the huge deal here, contrary what other smalltalker may believe. If you like me are heavily disappointed with how non flexible IDEs are you are going to love Squeak's IDE. The IDE goes a great deal making easy to navigate through all the libraries and making you understand what , where and why , something happens. I cant see the benefit of using a text editor. But you can, with file ins and file outs. But doing so you cripple smalltalk into becoming as efficient as other programming languages ;)

I am only studying squeak and pharo for a week now but even for me as a beginner the benefits of the IDE is obvious from the first minute.

The fact that code is fragmented into easy to digest methods, those methods grouped into protocols , protocols grouped to our familiar Classes and Classes grouped to packages. Hence the code is so well organized that I never feel lost, everything belongs somewhere, everything is just a click away, everything is inspectable, browseable , you just select right click and sends you there. And it shows you exactly the code you need rarely more than 10 lines long. This is the IDE. Why would you prefer a text editor that will expose to information that you don't need , don't care and is likely to confuse you ?

Then everything is inside a single image , not a collection of files, your code, your libraries, system libraries , even the language itself. Everything is at your grasp, waiting for you, begging you to test, modify it, use it and abuse it. You are part of the language and the language is part of your, if something does not fit your thinking, change it. This is the IDE. Why you want to go back to the disconnected way of files and folders ?

Then you are start being afraid with all this power, all this flexibility its not unlikely that you will do something that could completely destroy the language and the libraries. Its possible , mistakes can and will happen. Again the IDE jumps in offering you a hand of help, every change is stored in a local cvs system, every change is categorized, stored and monitored any time. No lousy undos and any kind of other nonsense . What you get is old , mature well tested version control. You can change back exactly what you want any time, nothing is lost, no mistake is irreversible.

And if you don't trust you hard driver , the vcs extends online to squeaksource . And does it let you at the mercy of command line ? Hell no . You are offered the simple yet efficient Monticello browser , which will make sure you install and unistall with no conflicts .

And of course you don't want your software to have bugs , do you ? Unit Testing tool is offered to make sure your code is reliable , stable and does exactly what you want how you want it. Again a beautiful yet brilliant GUI is utilized to make complicate tasks a button away.

And because none is perfect , there will be time you will come against the dreadful error. Are you left alone ? You guessed right , a tool again is offered. The debugger. You don't need to call it, you don't need to setup it , you don't even need to figure out how it works. Like all other tools, is simple in design yet sophisticated. Not only it will spot the error , not only will tell you what you did wrong , not only will navigate through back to most basic language elements that trigger the error offering a unique perspective on how exactly the language behave like nothing I have seen before, it also allows you to do live coding. Live coding is the ability to code a program while its code runs. Isn't that impressive and infinitely useful ?

Finally , maybe you are one of those people impossible to please, maybe you still find flaws , omissions and thinks you simple don't like. The IDE is written in smalltalk , smalltalk is written in smalltalk , and the IDE can edit itself and the language, there is nothing you can't change besides some very basic functionality of the language and the VM that is compiled C. And you will guess right if you think you can use all the above tools to do exactly that.

And the tools don't stop here , smalltalk might be not that popular as other languages but it has been here for a very long time and it has some very enthusiastic programmers that love to contribute. And frankly with such an amazing IDE and such a well designed language , while with other languages contributing to them might seem a challenge, in case of smalltalk the challenge is to resist the temptation not to contribute as the IDE makes it so easy.

By the time others still code you will finish your code and actually understand what have you done and why. Thats not a small thing at all . I wish Python had such a good IDE or any other language. But the only thing that comes abit close, from my experience , is Delphi. And even in the case of Delphi I still prefer squeak and pharo.

What I find annoying about other IDEs is that they are not IDES at all, they are nothing more than glorified editors, locked, non flexible , non editable (Unless you are willing to use another programming language and navigate through tons of source code) . Squeak , Pharo and all other smalltalk dialects offer a real elegant IDE offering you really useful tools. Other IDEs better take a deep a look at smalltalk and really understand what it means to be an IDE.

Saying all those good things, smalltalk is far from perfect. And I think its biggest weakness and flaw is lack of some enjoyable and useful documentation that can help beginners jump in head first. Squeak By Example as well Pharo By Example has been a big disappointment for me. They both are still two extremely important books that provide a extremely valuable insight in both platforms , but the quality of documentation is from mediocre to bad at times. The main reason is both books follow a non noob friendly approach. First they send you deep diving in the IDE , introducing you from chapter 1 , to debugger and even unit testing !!! For me this a big mistake, and even though I am far from new to programming had to struggle to follow up what was explained. Then the book itself , lets a lot of unanswered questions. For example the explanation of instance vs class variables is not enough, I would prefer several example that not only show the how but also the why . Several areas of the book are also full of gaps or just hard to follow.

My life got a lot easier when I found this link http://stephane.ducasse.free.fr/FreeBooks.html and from there I downloaded "Smalltalk by Example" which unlike the other book not only it does what it says in the title but makes no assumption on who you are and what you know. I can only highly recommend it. I read that the other books there that are offered freely are very good as well, I will certainly download and read all of them eventually.

Alot of help has been also #squeak at irc.freenode.net, people there has been answering my questions and helping me understand.

Squeak wiki, is ok but not enough, its also not very well organised, and I dont like that comments and discussions appear inside the wiki documentation. So documentation generally can be abit of a struggle for the begginer and certainly Smalltalk IS NOT AN EASY programming language to learn. I hear many smalltalkers say otherwise and I could not disagree more, when I compare smalltalk with python is like night and day. BUT ! Once understand smalltalk , it become much easier to program in it then any other programming language I have learned so far, and I have learned most of them. So in the end I think Smalltalk is a clear win , I also love the FFI library that lets you call any C library with ease, which unleashes serious power for smalltalk.

I dont think you need to learn the language first and then the IDE, its actually a very bad idea for the simple fact that the IDE helps you understand the language and its libraries and any type of code in it. Language and IDE is like brother and sister, yin and yang.

Answer 7

Well, if you decide to learn Eiffel a good book would be "Object-Oriented Software Construction" by Betrand Meyer (he created the Eiffel programming language).

The book provides great insight into object-oriented design using Eiffel. In my humble opinion is one of the best OO books around.