Before I answer this I should say, that I have always agreed 100% with Gilads' point on static. On his blog I questioned whether the elimination of static, was just another way of reducing coupling, to which Gilad responded that yes this is true, but that coupling was a general term and that he preferred to be specific. I think this is the root of my discomfort. By being specific, I fear that a lot of normal programmers will miss the point.
Most programmers do not understand the importance of coupling and cohesion, and most do not understand that objects are just one approach to reducing coupling and increasing cohesion amongst abstractions. Functional programming is yet another approach. The underlying problem is the same, and as old as computer science itself. In fact the whole static thing is merely a failure in abstraction. We have no way of declaring a suitable cohesive abstraction, so we make things static and have them coupled to everything. Just like dodgy globals in C when you can't think of a better way.
So what Gilad has done in Newspeak is to provide a new way of defining loosely coupled, cohesive abstractions that are larger than a single class, removing the need for dodgy globals (static). This isn't reducing the programmers freedom, rather it is replacing a rather poor default mechanism, with a more precise way of defining exactly what you want. If you wanted to you could still create "dodgy globals" in Newspeak, but you would need to define a "global" abstraction first. There is no default "global" name space in Newspeak, which is as it should be.
So this is the issue, new and improved mechanisms are fine, as long as the pilots understand why? With OO programming, lots of programmers understand the "what", but very few understand the "why". This is how languages like Java can claim to be Object Orientated whilst only delivering on half the story. It is also why many (most?) Java programmers are happy programming in a procedural style in blissful ignorance.
With Smalltalk, it gave very little scope for misunderstanding, because there was only one way to do things. You were constrained to think in Objects. Newspeak has this same property, and by replacing static with a better mechanism it will force developers to think about higher level abstractions and name spaces, rather than defaulting to static.
I guess it isn't Gilads job, but there is a big education task needed if languages like Newspeak are to ever take off. Most people don't get the basic concepts behind OO and Smalltalk, whilst Gilad is ramping things up to the next level by borrowing from Self and Beta. My education is only partial. I have read about slots in Self and they make sense. I didn't think of them as a way of defining immutable functions though, and as a way of eliminating state. The elimination of state, similar to the elimination of static is yet another way of reducing coupling. If nothing changes, then any dependent abstraction can't be adversely effected by unsuspected side effects. This intuitively makes sense.
So Gilad prefers:
identifier = letter, (letter | digit) star.
(Immutable)Over:
identifier ::= letter, (letter | digit) star.
(Mutable)In both examples identifier is a slot. This means that identifier is a method, that answers the value of the given expression. There are no instance variables in Newspeak. In the first example identifier is immutable, in the second it is mutable. In this presentation at Lang.NET Gilad makes the point that if you remove the ::= operator from Newspeak, then Newspeak becomes a purely functional language with no state.
What are the implications of this? Well this is where I hit the bounds of my education. I think I'm going to need to take a look at a purely functional language like Haskell and get to grips with Nomads before I can comment further. Even with a vehicle as powerful as Newspeak, the limiting factor on success is still the pilot :)
4 comments:
Nomads ?
did you mean Monads ?
(or was it an intentional "word-play" ?)
Brgds
Hi Pascal,
No it was an honest mistake :) I came across the term yesterday.
What are the advantages of a language like Haskell? I know removing state helps with verification and concurrent programming, but beyond this what are the other benefits? Especially when it comes to re-useable abstractions?
Thanks in advance,
Paul.
Avoiding side effects does have an advantage in regards to reusable abstractions. Side effects create an implicit temporal coupling - a coupling based on time. With side effects, if action A happens before action B then the result is different than if they occur in the opposite order.
With purely functional code dependencies like that are no longer implicit. You can still have a similar form of coupling, but the coupling must be because function A passes a value to function B.
Monads, especially with Haskell and Scala style sugar, make certain patterns of functional interaction syntactically lightweight and let you program as if you had side effects with limited scope.
If you want to learn about monads, dig in to Haskell but skip IO until you understand more limited monads like List, Maybe, and State. Or, if OO is more your style, then I've got some articles on monads in Scala: http://james-iry.blogspot.com/2007/09/monads-are-elephants-part-1.html
Hi James,
Temporal coupling, it makes sense. Hence the need for Monads in instances where temporal coupling can't be avoided.
Thanks for the link, I'm working my way through your tutorial.
Cheers,
Paul.
Post a Comment