Derived from SmalltalkLanguage
, borrows ideas from CommonLispObjectSystem
. A couple of its big features are PrototypeBased MultipleDispatch
(a trait it shares with CecilLanguage
It's still in a very early stage, but already it shows a lot of promise, and if you're a language geek like me, I highly recommend downloading the latest tarball, reading through the docs and source, and lurking on the #slate channel on FreeNode
. -- TimMoore
I like it just for the slogan: "Less talk, more rock." --NickBensema
Anyone have details on how lookup is done?
That's described in LeeSalzman?'s thesis: http://tunes.org/~eihrul/pmd.pdf
The semantics guide is pretty skimpy. And what about that other good stuff like keyword parameter passing?
Smalltalk-style syntax is already very similar to KeywordParameterPassing, even though the order of parameters is fixed. See "Keyword Messages" at http://slate.tunes.org/syntax.html .
And does Slate implement a proper message eating Nil, or Smalltalk's exception throwing Nil?
See comments at NullIsBenign for why a "message eating Nil" would be a bad idea.
I find it very interesting that Slate's method definitions look quite a bit like HaskellLanguage
's pattern-matching function definitions. Are object-oriented and functional programming converging? Could they by chance be equivalent
when developed to the extreme? I already find it very interesting that SmalltalkLanguage
use a lot of the same idioms (using closures as the
element of structure). -- MatthiasBenkard?
I have found that object-oriented code that uses TellDontAsk
is not very different in style from PurelyFunctional
code using monads. The OO code calculates values functionally, because the value objects are immutable, and then pushes calculated values out to other objects through polymorphic interfaces. The monadic functional code calculates values functionally and then pushes calculated values to other monadic computations through lambda abstractions which are therefore polymorphic.
Both functional and OO advocates a few common architectural good practices:
- Separating stateful computation from stateless calculation
- Encapsulating stateless calculations inside stateful computational components
- Making stateful computations communicate through polymorphic connections
- Minimising the amount of stateful computation