Posts Tagged ‘Smalltalk’

Web Development: Reinventing the Flat Tire

April 29th, 2014 2 comments

The Dynabook is the holy grail of computing. It is the platonic ideal of a computer, whose purpose is “to provide computer support for the creative spirit in everyone” (Design Principles Behind Smalltalk). Yeah! I want my creative spirit unleashed :) Are you with me?!

But how do we get there?

We attack from both sides at once:

  • Education – have computing be as natural as pencil and paper from a young age. And we mean individual creation, not the dependent-consumer model of the iPad, where you can do only what other developers implement, and Apple approves. While the iPad looks like the illustrations from the original Dynabook paper, it is actually the Anti-Dynabook. Much like places in the U.S. that have kept the original Native American names after stealing the land, it adopts the form while betraying the meaning
  • Distillation – if we’re going to invent the future, we need to understand where we are now. Unfortunately, if you wrote the code of the average computing system (i.e. the OS plus and office suite) in books, they would stack the height of the Empire State Building. People (especially old people) feel stupid because they don’t understand computers. I feel compassion for them, but still have to chuckle and say, “don’t worry, neither do the developers at [Microsoft/Apple/Ubuntu]“. If Leonardo Da Vinci were a Microsoft engineer, he would not be able to understand how windows works. Computing in its present form is beyond human potential to understand!

This post will briefly look at the second point, distillation, as it applies to web development.

Why Simplicity Matters

We each have a limited amount of mental RAM, or working memory, with which to create. Less is available, the more complex and indirect our technology stack is…

See we’re here already. It’s assumed that you need to have a “stack” – WAMP, LAMP – an operating system, a database, programming language layered on top, often with a run-compile cycle, probably with tools (e.g. the compiler) written in another language, often glorified text editors as IDEs.

We must reduce the cognitive burden of the technology so that there is enough mental RAM left over to create.

The Vision

If you go back to the original intentions of Morphic from the Self world, the vision was:

  1. Find – physically, visually, find an object (notice, it’s not “find a class”) that looks like/behaves like I want
  2. Copy – again physically, visually, directly, by clicking the original object and dragging the copy away
  3. Tweak – the object directly, not in desiccated file form in a text editor, until it does what I want it to do.
The Reality

This is totally lost in even the best web workflow:

  1. Find - say a Bootstrap template
  2. Copy – find all the necessary HTML and CSS files, which might take a bit of investigation into where they all live
  3. Tweak – If it didn’t seem too bad yet, this is where the wheels really fall off. Edit the raw HTML and CSS files, then if you’re really trendy, click refresh on the browser window you have open parallel to your coding window and see things refresh. WTH?! Where did the objects go? You just cut your extremely limited mental RAM at least in half by working with your objects (forms, buttons, links) in the equivalent of web assembly language, and repeatedly switching contexts.
“Not As Bad” Is the New Better

You say, “I’m tired of programming in assembly in a text editor! Viva la Revolution! Instead of settling for a language piled on top of the manure heap, I’m going to use a live, dynamic environment like Amber or Seaside“. Well kudos! If the Dynabook was our ideal of 100% efficiency and most web technologies are 10%, you’re now at 30%, so you can whip the heck out of your competition.

But, and just indulge me here for a second, what if we’re not satisfied with being the one-eyed man in the land of the blind? What if we were interested in going beyond what’s better exploring what’s possible?

Even writing HTML with a nice DSL in Amber or Seaside, is a non-WYSIWYG run-compile-like cycle. It’s more like programming with punch cards than the live, direct universe hinted at by Self, Sketchpad, Squeak/Pharo, and Croquet.

Hints at What’s Possible

Ivan Sutherland had WYSIWYG (among other things, like constraint solvers) down with Sketchpad in 1963.

Morphic was another powerful attempt. In a Morphic system, if my code editor doesn’t work the way I want, I can drill down into it – without leaving my uniform dynamic environment of live objects – and make it so (theoretically, this is becoming less true with e.g. Spec, which hides the live objects under layers of hopefully-cross-ui-platform-compatibility *).

Here’s a good example of my initial excitement about Morphic. One of my first favorite examples of using Pharo was that creating a new repository in the Monticello Browser (a version control GUI tool) always started with IIRC the image (current) directory, and I have a folder under which all my local repos live. I brought up halos on the “new repository” button, then on the Settings browser, connected the two together, and submitted the fix in a few minutes with 0 context switches… and I was hooked on Smalltalk.

Of course, Smalltalk is just a step on the path toward the Dynabook, albeit the top step to date! To really blow your mind, check out VPRI’s work to build a complete computing system in 20,000 lines of code – about the size of a good novel! Here’s the original NSF proposal and the last published annual status report (still waiting on the final one)

* One of the funny (or sad) thing is that people keep developing UI Builders for Morphic – that’s what Morphic is. The question isn’t how to layer tool-centric crap on top, but how to directly play with the Morphs themselves (remember flaps?) until you have what you want, and then reify that. It wouldn’t be so hard (at least for geometry and layout) to implement “aMorphThatIBuiltViaDirectManipulation reifyAs: #MyCoolMorphSubclass”.

The Challenge

How do we interact with a cool Bootstrap login form as I did with the Browser above – directly, as a live object? How do we dig in to the web, find the live objects, and bend them to our vision, without leaving our live, dynamic, open, turtles-all-the-way-down system? I would love to live in that world.

Code Club: The Dynabook Vision Alive and Well

March 13th, 2013 1 comment

This video reminds me of those great stories about kids at PARC… They are using Scratch to teach children how to use their Dynabooks :)

From the teachers (Alan Kay has obviously developed a mind control device):

“We’d like the outcome of Code Club to be a whole generation that understands… how to make [computers] do what they want, so they can create their own tools and their own games”

“I really wanted to get the kids… learning how to make things work, [rather] than just being consumers”

From a student:

“It’s really good for learning… before we were just… moving around, but… now we know how to make proper games”

“Our mission… to give every child in the UK the chance to learn to code.

It is our aim to have a Code Club in 25% of primary schools in the UK by the end of 2014″

Metacello: Conditional Loading

February 1st, 2013 No comments


The most frequent use case I have is for pending bug fixes. Imagine this… you find a bug in Pharo that you need fixed to progress on your project, so you fix it. Now, you’ll need the fix to be present anywhere your project is loaded, so what do you do while waiting for the fix to be integrated? You’re obviously not about to manually file in changesets when you have a powerful tool like Metacello! And anyway, you don’t want to have to edit the scripts for your continuous integration server.


I’ve found two ways I like to handle this scenario. I’ll show the (slightly) easier one first.

Method #1 – #customProjectAttributes

This is the method to use for Monticello packages

1. Make sure your configuration has #customProjectAttributes

Depending on the version of Metacello that was used to create your ConfigurationOfMyProject, you may have to add this method (which is easy enough).

In ConfigurationOfMyProject>>project, if you see the following two statements:

	"Construct Metacello project"
	constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self.
	project := constructor project.

Change them to the following:

	project := MetacelloMCProject new projectAttributes: self customProjectAttributes. 
	constructor := (Smalltalk at: #MetacelloVersionConstructor) on: self project: project.
2. Define your custom attributes

#customProjectAttributes will return a collection of symbols that will be added to the Metacello platform symbols e.g. #’squeak4.4′ or #’pharo2.0.x’. The following is for the bug fix example we discussed earlier. The general process is a) declare a condition that let’s you know the fix hasn’t been applied in this image (e.g. a class is not present or DNU a message), and if true, add an attribute declaring that (e.g. #’PharoIssue6300′, as below).

	| requiresPharoFix6300 requiresPharoFix6382 attributes |
	attributes := OrderedCollection new.
	requiresPharoFix6300 := (Morph canUnderstand: #hasKeymapCategoryNamed:) not.
	requiresPharoFix6300 ifTrue: [ attributes add: #'PharoIssue6300' ].
	^ attributes.
3. Finally, add fixes to your baseline

With this method, they must be packaged with Monticello. See method #2 below if you have to use changesets or .st files

	spec for: #'PharoIssue6300' do: [
	spec package: 'SLICE-Issue-6300-Detach-keymaping-shortcuts' with: [
		spec repository: '' ].
	spec package: 'VimPharo' with: [ spec requires: #'SLICE-Issue-6300-Detach-keymaping-shortcuts' ] ].


Method #2 – #preLoadDoIt:

This is the method to use for changesets or .st files

1. Add a #preLoadDoIt: to your baseline

For example:

	spec for: #'common' do: [
		spec blessing: #'baseline'.
		spec preLoadDoIt: #preLoad.
2. Define your callback

This method is going to look much like #customProjectAttributes in method #1. The main difference is, since Metacello can not handle file-ins, you will load the code right in this method instead of delegating, as in the following example:

	| shouldFixIssue7294 |
	shouldFixIssue7294 := (EventHandler canUnderstand: #keyStrokeRecipient) not.
	shouldFixIssue7294 ifTrue: [ '/path/to/issue7294.cs' asFileReference fileIn. ].


So when would you want to use method #2? For one, you may already have a changeset handy. But the other reason is time decay. In Pharo, for example, because of the rapid pace of development, the package you fixed may have another fix applied first. Now, loading your version may silently replace those changes (this is what happens in the MC browser, I assume Metcello works the same way). I’m actually still figuring out the tradeoffs here for myself. For now, I default to method #1 unless I have a specific reason for #2.


So there you have a simple pattern to conditionally load packages or code files in a Metacello configuration

Hope it helps!

Categories: Pharo, Squeak Tags: , , ,

Smalltalk: Extending the Kernel

January 28th, 2013 No comments


Many time I wish I could send a non-existent message to an object that’s part of the built-in Smalltalk library.

For example:

	^ $" asString, self, $" asString.


Simple Case: Project-specific Extensions

In Pharo, I can store this method in a package different from the one of the class in question. This is called an “extension method” and the implementation is currently a bit of a hack… You put the method in a protocol that starts with an asterisk followed by the package name. Thus, for the example above, if my project was packaged in MyPackage, I could package the method with it like this…

Screen Shot 2013-01-28 at 10.24.02 AM

For methods that are project-specific, this is all we need (although hopefully now that Pharo is working on first-class packages, it would be great if we could have both a protocol and specify an extension). However, the method above really has nothing to do with a particular project. It seems generally useful; and indeed, I find myself using it over and over.

Generally Useful Extensions

In these cases, it doesn’t work to package the method with the project that uses it, because if more than one of these projects are loaded into the same image, one method will override the other, creating a mess in Monticello. So I’ve been experimenting with two approaches.

The naive way would be to package all such methods in one package, e.g. “PharoExtensions”. This is the first thing I tried, but I was a bit uncomfortable with the all-or-nothing idea – that I’d have to load every extension I’ve ever created to use just one.

The most flexible tack is to package each method individually. The method above could be in the “StringSurroundedByDoubleQuotes” package. This way, one could load the method without effecting any other parts of the system. However, a package is a bit heavy-weight for just one method.

A Compromise

The current idea I’ve been playing with is to mirror the existing package structure of Pharo. For the above, String lives in “Collections-Strings”, so I tack on a standard suffix, making it “Collections-StringsSpd”. Now, we can load extensions for only the packages we are using, without having a confusing mess of ClassNameMethodName packages.



Categories: Smalltalk Tags:

Applescript to change genres in iTunes

May 12th, 2010 No comments

There is this awesome programming language in which the entire system (down to the graphics libraries, window system, and compiler) is available to you to reinvent, opening the possibility of truly open computing.

Obviously, I’m talking about Smalltalk. But if you are too afraid to give MS and Apple the bird for not learning (or wanting to learn?) the computing lessons of the 1970′s, there is another option which lets you bend almost any Mac application to your will, breaking it from the chains of presumptuous software giants who think you should work the way they design instead of vice versa.

I’m speaking, of course, of Ruby, lol. If you’re doing any serious Applescript development, ditch Applescript altogether, and check out the rb-appscript library.  It allows you to do anything you can do in Applescript, in a non-ambiguous way, with the power of a full programming language behind you – trust me, it’s the heaven where Applescript will go when it finally dies.

However, if you’re doing something simple and common, especially in a very scriptable application like iTunes, sometimes it’s easier to just crank up AppleScript Editor and hack out a one-liner.

Thus this very simple script to change the genres of iTunes tracks, which I used to fix things like some tracks in the “rock” genre and others in the “Rock” genre.

tell application "iTunes"
  set tracks_to_fix to file tracks of playlist "Music" of source "Library" whose genre ends with "ock"
  set genre of tracks_to_fix to "Rock"
end tell

Why Apple and Microsoft can’t touch Squeak Smalltalk

April 27th, 2010 2 comments

Life in Mac / Windows

Software is hard… and buggy.  We all know that.  Unfortunately, in mainstream systems, there’s very little we can do about it, except maybe file a bug that disappears into the bureaucracy of a major corporation, probably never to be heard from again.

The Squeak Life

I’m using an application called ScriptManager to keep some simple notes.  Here’s a little screenshot:

Now as software is wont to do, as soon as I went to save a profound (and long) note, an error occurred:

“What the heck is that!?” you say.  “I can get cryptic error messages quite easily in Windows, thank you very much.”  Except, this is no ordinary error message – it’s a debugger opened on the application’s code, so I can see exactly what went wrong.  I can do this because all code – from the lowest level graphics and file libraries, to whole applications – is available to me to change as I please.  And it’s all in the same simple, revolutionary (old) language – Smalltalk.  I don’t have to chase the application’s C++ to the libraries’ C to… well what difference does it make – I would’ve given up already.

But in Squeak, within 2 minutes, I had fixed the error and recovered my note.

You see, by flipping through the call stack, the debugger showed me exactly which object had gone south.  I was able to open and inspect this object in another tool:

It was immediately obvious that a nil entry had been stored in a set, which is not allowed.  Right in the tool, I was able to delete the key:

And I was back on track – no work lost!  How does that compare to your last error in OS X or Windows?

n.b. I was using a variant of Squeak called Pharo.  All this info applies to all versions of Squeak.

Categories: Smalltalk Tags: ,

BDD in Squeak Smalltalk: An exploration

April 27th, 2010 4 comments

Coming from Ruby, I’m obsessed with Behavior Driven Development.  The community (e.g. Rspec, Cucumber) is alive, and there is a body of practices to follow.

Since TDD was born in Smalltalk, I expected to find the same energy and guidance in Squeak.  Squeak represents the most profound, empowering environment I’ve ever seen (I will never go back to C, C++, or even Ruby – which misses the boat by not being a living system).  However, the testing situation seems frozen in the early days.

My intention is to create do a series of experiments, which will lead to BDD best-practices in Squeak.  My vision is code that is pulled into existence by what matters to its users, that is easy to understand, and easy to change.

I’ll keep you posted…

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip