Skip to main content

Smalltalk Challenge: Post 10 - Conclusions

So here I am, more than 20 hours with Smalltalk and 10 blog posts about my experiences as required by the terms of my challenge. Josh said he chose Smalltalk for me because of the language's history of helping giving rise to object-oriented programming, which he thinks I hate. (For the record I don't hate OO; I hate the awkwardness and complexity its over-zealous application inflicts.) But I think secretly he was hoping it would endear me to Java in the same way as I was hoping OCaml would help him see past Java. Smalltalk gave me a newfound respect, not for OO, but for the language's innovations and lasting influence. If anything in relation to current-day OO practices, my experience confirmed how botched OO adoption has been given what it was intended to be. Regardless, while I don't think I'll be using Smalltalk in the foreseeable future, it was definitely fun to explore and gave me a lot of things to think about.

Smalltalk isn't a popular "mainstream" language like Java or PHP, but it was highly influential on many of them. It's a language that hasn't been afraid to try bold, new ideas. Other languages adopted its innovations; some did so successfully, others not so much. Will new innovations from Smalltalk and its community be just as influential in the future? I can't help but think that if Squeak has successfully abandoned the MVC architecture in favor of Morphic, maybe the days of MVC web frameworks such as Struts, Zend Framework, and Rails are numbered.

Message passing is a key concept in Smalltalk and provides the flexibility of duck typing. But late/dynamic binding prohibits many compiler-time optimizations that could otherwise be performed on statically-compiled code. Is there continued benefit to such an approach now that we're inundated with so many dynamic languages that have (or at least seem to emulate reasonably well) direct invocation, and thus better performance, such as Lua and JavaScript? Perhaps a greater benefit could be realized if message passing was handled asynchronously.

In Smalltalk, everything is an object. Even basic language constructs such as if-statements and while loops have been distilled down to objects and message passing. I respect Kay for intentionally taking an extreme position to force new ways of looking at things, though I believe the "everything is a" mindset can lead to awkward perceptions. The human mind is adept at categorizing things into different classifications exactly because not everything is the same. Ruby claims everything is an object too, which is misleading because it still has basic language constructs. I wonder where the sweet spot between abstraction and reality is, and in what ways can programming languages more accurately reflect how we view the world so we don't end up with with shimmed, over-architectured, spaghetti code.

Overall I found the core concepts of Smalltalk pretty easy to learn (since there are so few), and it was fun to write Smalltalk code and explore objects and Morphs in Squeak's environment. I encourage others who may not be familiar with Smalltalk to spend a little time with it as I did. I can't say it made me a better programmer, but in some sense it made me a better person because I now have a better understanding of history and a lot of things to think about.

Comments

Popular posts from this blog

Writing a Minimal PSR-0 Autoloader

An excellent overview of autoloading in PHP and the PSR-0 standard was written by Hari K T over at PHPMaster.com , and it's definitely worth the read. But maybe you don't like some of the bloated, heavier autoloader offerings provided by various PHP frameworks, or maybe you just like to roll your own solutions. Is it possible to roll your own minimal loader and still be compliant? First, let's look at what PSR-0 mandates, taken directly from the standards document on GitHub : A fully-qualified namespace and class must have the following structure \<Vendor Name>\(<Namespace>\)*<Class Name> Each namespace must have a top-level namespace ("Vendor Name"). Each namespace can have as many sub-namespaces as it wishes. Each namespace separator is converted to a DIRECTORY_SEPARATOR when loading from the file system. Each "_" character in the CLASS NAME is converted to a DIRECTORY_SEPARATOR . The "_" character has no special

Composing Music with PHP

I’m not an expert on probability theory, artificial intelligence, and machine learning. And even my Music 201 class from years ago has been long forgotten. But if you’ll indulge me for the next 10 minutes, I think you’ll find that even just a little knowledge can yield impressive results if creatively woven together. I’d like to share with you how to teach PHP to compose music. Here’s an example: You’re looking at a melody generated by PHP. It’s not the most memorable, but it’s not unpleasant either. And surprisingly, the code to generate such sequences is rather brief. So what’s going on? The script calculates a probability map of melodic intervals and applies a Markov process to generate a new sequence. In friendlier terms, musical data is analyzed by a script to learn which intervals make up pleasing melodies. It then creates a new composition by selecting pitches based on the possibilities it’s observed. . Standing on Shoulders Composition doesn’t happen in a vacuum. Bach wa

Learning Prolog

I'm not quite sure exactly I was searching for, but somehow I serendipitously stumbled upon the site learnprolognow.org a few months ago. It's the home for an introductory Prolog programming course. Logic programming offers an interesting way to think about your problems; I've been doing so much procedural and object-oriented programming in the past decade that it really took effort to think at a higher level! I found the most interesting features to be definite clause grammars (DCG), and unification. Difference lists are very powerful and Prolog's DCG syntax makes it easy to work with them. Specifying a grammar such as: s(s(NP,VP)) --> np(NP,X,Y,subject), vp(VP,X,Y). np(np(DET,NBAR,PP),X,Y,_) --> det(DET,X), nbar(NBAR,X,Y), pp(PP). np(np(DET,NBAR),X,Y,_) --> det(DET,X), nbar(NBAR,X,Y). np(np(PRO),X,Y,Z) --> pro(PRO,X,Y,Z). vp(vp(V),X,Y) --> v(V,X,Y). vp(vp(V,NP),X,Y) --> v(V,X,Y), np(NP,_,_,object). nbar(nbar(JP),X,3) --> jp(JP,X). pp(pp(PREP,N