Lambda the Ultimate

I think that by 'keyword syntax', he means that in Smalltalk you pass parameter by name not by position like in other language i.e
my_function arg:foo instead of my_function(foo).

It's too bad that this syntax isn't more widespread:
- it's more readable
- it helps avoiding mistakes when calling functions (the famous memset error).

There are different techniques for building DSELs, so I don't think this is the right question: there isn't one set of essential features one must have in order to build DSELs.

sciomako: ..."keyword syntax" which makes it easy to implement (embedded) DSL.

Sounds like that might be metonymy, with "keyword syntax" somehow intending to mean "message passing", which is a runtime behavior that's not syntax specific.

In Smalltalk, selectors (method names) with colons in them are called keyword messages (in contrast to unary and binary messages), but all methods are invoked by message passing and nothing is really different about keyword messages, except more than one method argument with keywords interspersed between args.

But I don't see how message passing makes it easier to implement embedded DSL either ... except that message passing is a very hands-off style of communication which doesn't over-specify what a receiver will do in response. You could easily embed a language using message passing in a runtime, because it won't constrain much -- it would be like posting events, which most apps and servers handle anyway (from the OS or from connections, or whatever).

But embedding doesn't imply anything about a DSL (domain specific language) unless the domain is the app into which you embedded the language, and then you're really just talking about an embedded language ... maybe any embedded language is necessarily specific to the domain of an app it lives inside, in order for there to be bindings for the language in the execution context. (For example, JavaScript as an embedded language tends to be domain specific to the browser context in which it runs, so it can interact with the DOM and browser, etc.)

I suppose I should listen to the interview, but I have a slow connection at the moment.

Smalltalk keyword messages are not true named parameters, in that order argument matters. If I implement a class and provide a method called doThis: toThat:, then the following works:

myObject doThis: oneObject doThat: anotherObject

But the following does not:

myObject doThat: anotherObject doThis: oneObject

Unless doThat: doThis: is also defined, the latter invokation returns #doesNotUnderstand. It is possible to simulate true keyword arguments by providing multiple versions--the boolean classes True and False both provide methods ifTrue: ifFalse: and ifFalse: ifTrue:, which behave as expected, but you have to write that sort of thing yourself. There's no requirement that two similarily-named methods behave identically; and extending this trick to n-ary argument methods will require n! different versions--hardly scaleable.