Personal Notes

Space dedicated for storing personal notes about the current reading material.

Reading Material

1. Squeak By Example

http://paginas.fe.up.pt/~ei10125/squeakbyexample.pdf\

** References from this document **

• Sherman R. Alpert, Kyle Brown and Bobby Woolf: The Design Patterns Smalltalk Companion. Addison Wesley, 1998, ISBN 0–201–18462–1
• Kent Beck: Smalltalk Best Practice Patterns. Prentice-Hall, 1997
• Kent Beck: Test Driven Development: By Example. Addison-Wesley, 2003, ISBN 0–321–14653–0
• Erich Gamma et al.: Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Mass.: Addison Wesley, 1995, ISBN 0–201–63361–2–(3)
• Adele Goldberg and David Robson: Smalltalk 80: the Language and its Implementation. Reading, Mass.: AddisonWesley, May 1983, ISBN 0–201–13688–0
• Wilf LaLonde and John Pugh: Inside Smalltalk: Volume 1. Prentice Hall, 1990, ISBN 0–13–468414–1
• Alec Sharp: Smalltalk by Example. McGraw-Hill, 1997 hURL: http://stephane.ducasse.free.fr/FreeBooks/ByExample/i
• Bobby Woolf: Null Object. In Robert Martin, Dirk Riehle and Frank Buschmann, editors: Pattern Languages of Program Design 3. AddisonWesley, 1998, 5–18

The Squeak Programming Environment

One of the unique features of Smalltalk is that while you are programming, you are living in a world of live objects, not in a world of static program text.
This makes it possible to get very rapid feedback while programming, which makes you more productive. There are two tools that let you look at, and indeed change, live objects: the inspector and the explorer.

Squeak Tools

• Browser: The central development tool. You will use it to create, define, and organize your classes and methods. Using it you can also navigate through all the library classes. Unlike other environments where the source code is stored in separate files, in Smalltalk all classes and methods are contained in the image.
• Message Names: This tool is used to look at all of the methods with a particular selector, or with a selector containing a substring.
• Method Finder: This tool will also let you find methods, but according to what they do as well as what they are called.
• The Monticello Browser: The starting point for loading code from, and saving code in, Monticello packages.
• Process Browser: Provides a view on all of the processes (threads) executing in Smalltalk.
• Test Runner: Tool that lets you run and debug SUnit tests.
• Transcript: Window on the Transcript output stream, which is useful for writing log messages.
• Workspace: Window into which you can type input. It can be used for any purpose, but is most often used for typing Smalltalk expressions and executing them as do its.

2. Squeak System Documentation

http://wiki.squeak.org/squeak/1924

3. Scalide Project Documentation

Not much was found on this subject... Need to search more.

** Known Issues: ** Standard out does not display in the result boxes for the interpreter, instead it is placed in the command line where the interpreter was started from. In a future version I plan to add a console window and attempt to associate output with the command that generated it, if anyone wants it.
Deeper explanation the primary problem with including the output of a print command there is that it is not routed directly through the interpreter and so it becomes pretty difficult to determine which command generated the std::out in most circumstances.
There are some novel work arounds that I have read about on the web and I will look into them and see if I can come up with a solution. As long as the prints are not placed on a different thread it should be possible to associate them with the correct command, however if that does not happen then there could be issues, and results could start to appear garbled.
There is no way to delete cells. This will be fixed in an upcoming release, probably with the keyboard shortcut ctrl+del.
The interpreter hangs sometimes, please post issues when this happens and I will look into it. In the mean time i suggest that you restart with ctrl+r or Interpreter > Restart. and re-evaluate the cells you need to get back to the execution state that you previously were at.

4. IDE's and Dynamic Languages

http://www.sauria.com/blog/2008/07/20/ides-and-dynamic-languages/

Today when you say dynamic languages, people assume that you are talking about Ruby, Python, Groovy, Javascript, PHP, or Perl, with a number of other languages also entering the mix. The truth is that the intellectual forbears of these languages, Lisp and Smalltalk, were invented about 30 years ago or so

They were written in dynamic languages, for use on dynamic languages. They did not include some of the most maligned features of “modern” IDE’s, such as bloat or wizards that spew out pages of autogenerated boilerplate code. People that actually have used these systems were highly productive on them.

Stephen asserts that he’s talked to lots of dynamic language developers and that they don’t use IDE’s. He cites the Rails committers usage of Textmate as proof that IDE’s are not being used. I guess it depends what an IDE is. Textmate includes automatic syntax verification and code completion, which are not really features that have anything to do with edit text, and both of which require some understanding of what a program means in order to do their job. I’d call those IDE features. The ability to perform semantic manipulations on programs is the essence of what I think an IDE is. Maybe we should just say “good tools” instead of IDE, since a number of people that I’ve talked to seem to think that in order to be an IDE, the tool has to be huge, written in Java, and include feature for generating reams of boiler plate code

Flaws: Textmate (and other text editors) do not provide features like “find all uses of an identifier” or the ability to refactor ones code.

I believe that sufficiently powerful tools will also be adopted if they can consistently deliver higher degrees of productivity. The lack (or perceived lack, depending on your point of view) of good tools is a barrier to the adoption of dynamic languages.

Flaws: Most of the available tools for Python had problems of one kind or another, including slowness, instability, unreliability and lack of refactoring tools.

Key to Success ?: Deliver tools that understand programs at a semantic level and which use that knowledge to reliably refactor dynamic languages using a substantial number of the refactorings in the book “Refactoring: Improving the Design of Existing Code” (Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts).

5. Dynamic Languages and IDEs: What’s the Market?

http://redmonk.com/sogrady/2008/07/09/dynamic_language_ides/

Virtually every major IDE of consequence, from Eclipse to Microsoft to NetBeans has understood for years now that dynamic languages are not the first choice, but the only choice for large swaths of their target audience. The days of single language IDEs are likely, for all intents and purposes, over.

While I’m not sure if it’s still true, as it once was, that the entire Rails committer team is using TextMate – a text editor – the lesson stands: many dynamic language developers prefer the simplicity of a text editor. One might conclude from this that it’s been an absence of choice: the IDEs, after all, have only added dynamic language support over the past few years. And it’s certainly possible that that is more than a mere contributing factor to the relative unpopularity of IDEs with dynamic language development communities.

6. Eclips-ing Ruby

http://redmonk.com/sogrady/2006/01/19/eclips-ing-ruby/

Thanks to Eclipse’s Portage like Update Manager, one has only to add the RDT site into the system,[1] click a couple of boxes and it’s installed and running. After that, you need only to tell Eclipse where your Ruby interpreter is located, and you’re ready to develop. The combination of Eclipse and RDT was able to seamlessly import the folder of toy programs created during tutorials, and run them flawlessly. Nothing extraordinary there, but it beats the basic text editor approach I had been using.

• Eclipse is Pretty Snappy: As I mention briefly above and one Eclipse oriented vendor admitted this morning, the issue in pitching Eclipse towards some types of developers – i.e. Ajax or Ruby advocates – is the overhead. Most of these folks are used to working with something less complex than a fully-featured Java IDE, and get concerned that Eclipse may be overkill.
• Update Manager System: Eclipse is far from the only development tool with such a feature – and it’s far from new, but I can’t tell you how nice it is to be able to manage your plugins and additions via the IDE itself (this is particularly true as the user of a Linux distro that provides a similar capability).
  No longer is it necessary to download and untar a package, drop it in the appropriate directory, and remind the application to recognize its presence: it’s a couple of clicks and you’re done.
• Ruby Development in Eclipse is Definitely Possible: I can’t speak to the distance between the RDT and its commercial competitors, either because I haven’t spent enough time with them or I just haven’t seen them yet, but with respect to simplistic Ruby development – code, test, debug – I see no reason that you couldn’t be productive in this environment. It’s not going to do for you what Eclipse might for Java development, but it covers at least the basics.

7. IDEs for dynamic languages

• Komodo 7
• Visual Studio for Python
• Eclipse
• NetBeans
• JetBrains
• Aptana
• intelliJ IDEA

http://programmers.stackexchange.com/questions/131561/ides-for-dynamic-languages-how-far-can-you-get "Essentially impossible" in a theoretical, absolutist sense? Sure. In a practical sense? Not really. There are many ways to infer type for dynamic languages, statically (http://matt.might.net/articles/implementation-of-kcfa-and-0cfa/, http://decomp.ulb.ac.be/roelwuyts/smalltalk/roeltyper/), at run time (http://c2.com/cgi/wiki?PolymorphicInlineCaches), and other methods, like using a programmer's recent history - "How Program History Can Improve Code Completion".

REPL's

Major language environments and associated REPLs:

• C does not have a built-in REPL, but third-party REPLs exist, like c-repl and ccons.
• C++ does not have a built-in REPL, but third-party REPLs exist, like cint.
• C# does not have built-in REPL but has an implementation in Mono through CsharpRepl. To some extent REPL can also be imitated in LINQPad free interactive utility. The Microsoft Roslyn CTP contains a C# REPL which can be accessed through Visual Studio (View > Other Windows > C# Interactive Window).
• Clojure, a recent Lisp dialect, provides a REPL.
• CoffeeScript provides a REPL with mutli-line input support and syntax-highlighted output (coffee).
• Common Lisp, most implementations have built-in REPLs.
• Emacs Lisp, the Emacs editor features a REPL for elisp called ielm
• Erlang provides a REPL (erl).
• F# has a REPL in the form of a command called fsi (F# interactive).
• Falcon has an interactive mode by running falcon -i.
• Frink has a built-in REPL. The command-line version provides a REPL interface if no input file is given, and the default GUIs provide a REPL or more traditional programming mode.
• Groovy has a built-in REPL ([1]), as well as a graphical console, which can run locally or on the web (http://groovyconsole.appspot.com/).
• Haskell has at least two implementations provide REPL functionality. The Glasgow Haskell Compiler provides ghci and the Hugs interpreter is often used by beginners as a Haskell REPL.
• Java does not have a built-in REPL, but has a pure Java implementation in BeanShell. It can also be driven via scripting languages ported to the Java platform like Jython or Groovy. There is a Java REPL implementation in DrJava accessible from the Interactions pane and in JGrasp IDE [2].
• A JavaScript REPL is provided by Node.js, Rhino, and in the browser using JSConsole.
• Lua has an optional REPL.
• MATLAB, Mathematica, Sage (mathematics software) and other computer algebra systems are mainly accessed through REPL which allow for the evaluation of mathematical expressions and invocation of system commands.
• OCaml has a built-in REPL (called a toplevel system in OCaml terminology), via the command ocaml. You can also build a customized REPL with custom code preloaded using the ocamlmktop utility.
• Perl provides a REPL via the module Devel::REPL, also Perl Console.
• PHP's command-line interface has an interactive mode, which you can run by doing php -a (assuming php is your PHP-CLI executable, not PHP-CGI), but it does not load library functions by default. There is also phpsh, which has tab completion and other features.
• Prolog, a logic programming language, by default, boots into a REPL interface.
• Python has a built-in REPL and a more enhanced version in IPython.
• R statistical programming language, by default, boots into a REPL interface.
• Ruby's standard library contains a module called IRB which stands for Interactive Ruby Shell which provides a REPL. The standard Ruby distribution packages a standalone utility called irb which simply spawns an IRB instance. Even more powerful than irb is PRY, which can be easily installed as a gem.
• Scala (a language on the JVM) provides a REPL; start it at the command line by typing "scala" (as opposed to scalac, the compiler).
• Scheme, most implementations have built-in REPLs.
• Smalltalk, many implementations also have a command line REPL built in. All Smalltalks with a GUI also have the "workspace" built in which is a more advanced form of the REPL where you select code and "do it" or "print it" or "inspect it" to evaluate the code. Files can also be loaded using the stream-fileIn operation.
• SuperCollider, a language for sound synthesis, analysis and algorithmic composition.
• Windows PowerShell, part of Microsoft Windows, provides a REPL.