tag:blogger.com,1999:blog-4351297767743049123.post7288853038345401779..comments2022-08-04T05:56:14.887-04:00Comments on Alan Knight's blog: Some nice words for SmalltalkAlan Knighthttp://www.blogger.com/profile/18208736951543256794noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-4351297767743049123.post-33120746566004120652011-12-13T22:09:26.763-05:002011-12-13T22:09:26.763-05:00Pattern matching in functional programming is a re...Pattern matching in functional programming is a really powerful and expressive language feature, which I came to fully appreciate only when coding in Erlang and Haskell. You become dissatisfied with most languages that have case statements after playing with pattern matching for, say, five minutes. The code is so much easier to understand once you grok what's going on both syntactically and, more importantly, semantically, it's outrageous.<br /><br />Similarly, you become dissatisfied with most languages' syntax for method calling when you grasp Smalltalk's message-passing syntax and semantics. Suddenly, Objective-C makes sense. I never thought that could happen. ;)<br /><br />My ideal language would bring the best ideas from Erlang and Smalltalk together. Erlang's weakness -- data abstraction -- is Smalltalk's strength, and vice versa. Smalltalk lacks Erlang's process-oriented philosophy of fault-tolerance (and supervision), concurrency and parallelism. I suppose strictly speaking pattern matching in Smalltalk is unnecessary, as there are better idioms in Smalltalk for dealing with complex choices than case statements. <br /><br />But the idea I was trying to convey is that there must be some ideal way to blend functional and object-oriented paradigms that preserves elegance and comprehension in the code. To my delight, Smalltalk blocks have much in common with the lambda calculus functional programming really taught me to appreciate. But I wish I could count on it on multi-core machines or distributed environments like I can count on Erlang.<br /><br />F# and Scala are going in that 'hybrid' direction, but IMHO retaining to many of the bad features of both mainstream variants of those syntaxes. Mozart-Oz is an intriguing if obscure language that attempts to do this not just with OO and functional programming, but more ambitiously with several additional paradigms to boot. Unfortunately its syntax reminds me of Tcl, which always makes me want to take a shower for some reason. But I learned a lot studying it and owe my 'multi-paradigm' perspective to it.<br /><br />What I guess I was trying to convey in retrospect was simply that pattern matching opened my mind to better syntax than I had previously known for doing what I was normally doing in procedural and quasi-OO code in C++/Delphi/et al. Similarly, Smalltalk's syntax has been liberating my mind to think differently about how I solve problems in software design in-the-large. I'm embarrassed (just a little) to admit that I hardly knew what OO was about using the 'other' OO languages. Hence, I have experienced with Smalltalk a similarly positive association that I had with pattern matching when I first got the concept.<br /><br />I love the 'Aha' moments I've had so far, anyway. :)bobcalcohttps://www.blogger.com/profile/04230520603539406899noreply@blogger.comtag:blogger.com,1999:blog-4351297767743049123.post-78452503063994219992011-12-07T14:35:51.509-05:002011-12-07T14:35:51.509-05:00Hmm. I really need to bump up the priority on the ...Hmm. I really need to bump up the priority on the to-do list item of looking at OMeta more seriously. Alex Warth's talk on it at Smalltalk Solutions a few years back was extremely good, but I've never gotten around to following up.Alan Knighthttps://www.blogger.com/profile/18208736951543256794noreply@blogger.comtag:blogger.com,1999:blog-4351297767743049123.post-71089988544292118592011-12-07T06:59:31.840-05:002011-12-07T06:59:31.840-05:00It's only difficult to reconcile with opaque o...It's only difficult to reconcile with opaque objects until you realise that an opaque object may freely represent itself any way it likes.<br /><br />OMeta, for instance, allows one to pattern match against objects, and objects permit themselves to be pattern matched against by exposing a stream-like interface.<br /><br />Another name for pattern matching is destructuring. When a language supports it - like in Clojure - it permits lucid and terse code; code rather more lucid than case statements or visitors.<br /><br />What puzzles me is why noone just skips pattern matching in favour of unification (which is a _bidirectional_ pattern match). It's not much work to implement, and you get pattern matching for free!Frank Sheararhttps://www.blogger.com/profile/14057698907433585997noreply@blogger.comtag:blogger.com,1999:blog-4351297767743049123.post-87235063181800161222011-12-06T13:36:52.417-05:002011-12-06T13:36:52.417-05:00Thanks. A nice explanation. And yes, it does seem ...Thanks. A nice explanation. And yes, it does seem rather difficult to reconcile with having opaque objects.Alan Knighthttps://www.blogger.com/profile/18208736951543256794noreply@blogger.comtag:blogger.com,1999:blog-4351297767743049123.post-77061611838999027832011-12-05T17:50:29.318-05:002011-12-05T17:50:29.318-05:00Pattern matching is just syntactic sugar for case ...Pattern matching is just syntactic sugar for case statements, but in this case it's a über powered version of the case statement, one we can use to go deep inside a data structure without caring for the paths. In a sense pattern matching is the antithesis of OO, you must know about the object's structure and it's components' structures deeply in order to use them, but when used in functional programming they provide very clean ways to slice and dice a value.Daniel Yokomizohttps://www.blogger.com/profile/12528969103424062002noreply@blogger.com