Per the roadmap I laid out the other day, I'm making a concerted effort to work on my meager Smalltalk knowledge. One of the best ways to cement knowledge is to pass it on, so I thought I'd make a little video showing some of the stuff I've been impressed with so far. In this video I TDD a method, with an emphasis on some of the development aids that the Pharo environment is able to offer.

For more on Pharo Smalltalk, check out:

 

Published by Avdi Grimm

24 Comments

  1. Woah! Great screencast. While basic, it gets at the heart of the power of a live, dynamic, turtles-all-the-way down computing environment.

    Tip: If you use #assert:#equals: instead of #assert:, when the debugger pops up, you will get a nice error message saying what was expected and what the actual value was.

    Feel free to get in touch on the users mailing list as you continue your exploration. We are always available to help 🙂 Also, definitely keep us posted if you make any more screencasts or blog posts!

    Reply
  2. So way beyond cool!

    How ironic that there are still 2 camps left over from the 70s we are all trying to get back to.

    On one hand you have vim/emacs. On the other you have lisp/smalltalk.

    I tend to go for a more lispy, functional style of Ruby, but I am always drawn into messages and other smalltalk idioms when you or Sandi are doing your thang.

    This is the year for me to dig more into smalltalk and purist OO. Thanks for the share!

    Still loving Ruby….

    Reply
  3. Wow! Everything there was pretty cool, but when you searched the documentation “by example”, I literally shouted, “No way!”, alone here in my office. That’s such a brilliant idea. I’m sure it could be done with Ruby, albeit slowly with a naïve implementation. How fast is Pharo compared to Ruby generally?

    Reply
    • I don’t know the answer to that. I suspect “very fast”, because a ton of research has gone into optimizing Ruby VMs, and Pharo has been under development for a long time. But I really don’t know.

      Reply
    • One of our VM experts said “the ruby interpreter and CPython are around 20x slower than [Pharo’s VM]” [1], but that because all of our tools run on top of it, this speed is required – a VM several times slower would quickly become unusable. Going forward, there is currently work being done that should lead to well over a 2x speedup in the near future.

      http://forum.world.st/Making-a-Slower-VM-tp4742391p4742410.html

      Reply
    • If only Avdi had clicked on the search result in that Finder and expanded it, you’d see that this is not a search in some documentation. The search results are the actual methods that deliver the results. You can browse the implementations of all methods that would convert ‘hello world’ to ‘HELLO WORLD’ right in the Finder. How cool is that?

      So believe me, the coolness of this feature has only been scratched at the surface.

      I’ve been using Smalltalk professionally for almost 20 years now, and I am really impressed by how much clever tooling Pharo has added onto the highly reflective capabilities of Smalltalk. I really enjoy being highly productive using the tools available, but some of the tricksshown in this video lift you to another level.

      Reply
    • I also yelled “No way!” lol

      Reply
  4. Great presentation, simple and straight to the point the way I like it.

    One thing about the debugger that may not be obvious to you or other people is that when you make an error in Pharo (this probably applies for all smalltalks out there) the error does not kill your code. It wont exit or crash your running application. As matter of fact it does not even kill the method that caused the error. It keep the method alive, that means you can use the debugger to inspect the method , the arguments it has been passed, its temporary (local) variable and of course all the current state of class and instance variable not just for that object that the method belongs too but all objects. For people people familiar with lisp there should be familiar with this features, called “live coding”, since Smalltalk has “stolen” it from Lisp with the difference here is that Pharo is based on it.

    That basically means that you code your application while it runs and it will never crash and burn whatever the errors you cause unless your crash the Pharo VM, but of course you will have to do something really weird or come across a nasty bug to crash the VM.

    I explain the debugger in one of my video tutorials you have linked (Dimitris Chloupis) .

    I am coming from Python not Ruby and Pharo has not made me hate but rather fall in love with coding once more. I still love Python though I mainly code in Pharo, but I use now Pharo as scripting language for Python. Its great when one can combine his/her favorite languages together on a project.

    About Pharo speed, I think its not a concern as speed is not a concern for the average Python coder. Most Python libraries are written in C and the Python VM will freeze anything is doing to give priority to execution of C code . Thus libraries like numpy that cpython coders can use are blazzing fast even by C standards. With Pharo one has a similar if not same situation.

    Reply
    • Glad you liked it!

      The ability to continue from an error after fixing it in the debugger was something I had wanted to show, but I just didn’t get around to it. I actually wrote a Ruby version of that capability a long time ago, which a lot of people got a kick out of 🙂

      Reply
      • I am very interested how you can do this in Ruby, because I tried to do it in CPython and I has been unsuccessful . Apart from Lisp (Common Lisp is what I have used) I have not bee able to do live coding with another programming language. You got a video that demostrate this or some link ?

        Reply
        • The Github project is called “hammertime”. Ruby, being inspired by lisp and Smalltalk, is fundamentally more dynamic than Python. One of the ways that exhibits is that #raise is just another method and can be overridden to do first stuff like pop up a prompt.

          Reply
        • My project was just a proof of concept, but I believe you can do similar stuff in Pry (possibly using plugins). In general Pry contains a lot of examples of the sort of live stuff you can do in Ruby.

          Reply
  5. Hi Avdi,

    Sean noted your post the Pharo mail list. You’ve captured very well what I like about Pharo. Your attitude “a bit weird compared to other languages, but hey we’re learning a new thing” is just what is needed. Smalltalk be a step to far for some.

    Now fresh eyes are valuable to the Pharo community, since familiarity can make us unconsciously step around problems without noticing them – like missing a wobbly stop on a garden path. Drop by the [pharo-users] mail-list if you have any questions or insights to improve things for newcomers.

    cheers -ben

    http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-April/094971.html

    Reply
  6. Wow, this is brilliant!

    The last time I looked at Pharo, I got hopelessly lost in the IDE and couldn’t understand why anyone would want that environment over good old text files and the terminal. Now I know. 😉

    Reply
  7. Hi,terrific post.
    For completeness, you can adjust the method straight in the debugger as well. You don’t need to go to the browser. The advantage being that you still have the context of the test to evaluate against so you can inspect or walk through the correction without having to run all tests again. The debugger is to fix the test itself. Running all tests is to check for unexpected side effects.
    Cheers,
    Leo

    Reply
  8. Nice post 🙂
    By the way, you don’t need to go to the browser to correct the failed method. You can just do it in the debugger and accept. Pharo will ask to revert in the stack to the start of the method you corrected. The advantage is that you’ll still be working in the context of the test, so it’s easy to inspect or step through to verify if you actually fixed the test.
    Work in the debugger to fix the test, then use the test runner to check for side effects in the other tests.
    Have fun with Smalltalk!
    Leo.

    Reply
  9. Told ya! Smalltalk (specially Pharo) is so frigging awesome. 😀

    Reply
  10. Going through the Pharo tutorial was very interesting. Thanks for posting this!

    Reply
  11. That title is a a little heavy on hyperbole. 🙂 It should say ‘In which I make you hate your Ruby dev environment in 7 minutes’, like the way you ended the video. I don’t hate ruby after watching this.

    Pharo looks pretty useful though. I 100% agree w/ your opening statement as well.

    Reply
  12. […] Well, if you’ve worked in Smalltalk you definitely know what I’m talking about. […]

    Reply
  13. […] Well, if you’ve worked in Smalltalk you definitely know what I’m talking about. […]

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *