Hacker News Reader

Comment by agumonkey | Hacker News Reader

smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception).

make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls

smalltalk simplicity lies in that the metamodel is actually human reasoning friendly, even while dynamic, you have a clear picture of what's gonna happen in case of errors etc. It didn't please visual age users, which called smalltalk messagenotunderstoodlang but I believe it was due to the wrong viewpoint.

View on HN

> metamodel is actually human reasoning friendly

There's so much power in being able to think about a language (or your application) without having to always dig into the code.

"smalltalk cutest feature is the named parameter syntax trick..."

  make-range from: 10 to: 20 calss (make-range.from:to 10 20) or something similar. Free nanodsls

For the uninitiated among us, what does that do and what's so magic about it?

So the example would be:

   1 to: 10.

Sends the "to:" message to the number 1 with the parameter 10. Returns a range representing the numbers from 1 to 10. You can then iterate that range with by sending it the "do:" message with a block argument.

   1 to: 10 do:[ :i |  <do something with i> ].

And so on. Looks a lot like syntax for a for-loop, but is just message sends to collections with keyword syntax. Every type of collection implements do: (and collect:, select:, reject: etc.) Conditionals work the same way:

   1 > 0 ifTrue: [ <do something here> ]

Sends the ifTrue: message to the result of 1 >0. This will be the true object, which is the sole instance of the True class (subclass of Boolean). The True class defines ifTrue: so that it executes the block. Conversely, the False class defines ifTrue: so that it does nothing, ignoring the block.

The fact that what is usually syntax is just message sends means that you can define your own messaging protocols in libraries that also look like syntax.

Dan Ingalls explains: https://youtu.be/P2mh92d-T3Y?t=574

Also, the Grace language expands on this concept by allowing effectively regular expressions of these keyword parameters. Really quite nifty.

Found the paper on generalized method names in Grace:

From APIs to languages: generalising method names

https://dl.acm.org/citation.cfm?doid=2936313.2816708

pdf: https://michael.homer.nz/Publications/DLS2015/paper.pdf

morning paper: https://blog.acolyer.org/2015/11/09/from-apis-to-languages-g...

Sorry to "well actually" you, but

    1 to: 10 do:[ :i |  <do something with i> ].

would be a single message `to:do:`, not a chain of messages.

well actually-actually :-),

   (1 to: 10) do: [ :i | Transcript show: i ; cr].

also works in Pharo. Both are valid because:

"to:do:" is a message understood by the Number class

"to:" is a message also understood by the Number class that yields an Interval object, which understands the "do:" message.

> well actually-actually :-),

I didn't say you could not build a message chain to do that, only that to:do: as shown in mpweiher's original comment is a single message ;)

Yeah. My reply was more meant to show off more Smalltalk to pmoriarty and others that to one-up everyone :-)

Yes, I left that detail out for pedagogical purposes.

As the other respondent wrote, it still works the same way but with parentheses, and the to:do: exists as a convenience.

In Objective-Smalltalk[1], I added | so you can do this without parenthesis:

   (1 to:10) do: [ :i | stdout println:i. ].

can become:

   1 to:10 | do: [ :i | stdout println:i ].

This is nice when you are constructing a statement interactively, for example on a command line and don't want to go back. It also makes things less convoluted when the chain gets longer. It also "fixes" the asymmetry that chaining works with unary messages but not with keyword messages.

Of course, the whole thing becomes even more elegant, IMHO, with a Higher Order Message (HOM)[2]:

   stdout do println: (1 to:10) each.

YMMV.

[1] http://objective.st/

[2] https://en.wikipedia.org/wiki/Higher_order_message

It's keywords as sentences. It basically allows a function signature to be spelled out as a sentence with infix operators. These days you can see the lineage of smalltalk in keyword arguments. For example, python vs. smalltalk:

    obj.do_thing("string", with_factor=8, log_to=logger)

    obj do_thing: "string" with_factor: 8 log_to: logger

One of those reads as a sentence a little better. But to be fair python learned this from languages that had already taken this idea from smalltalk.

Like most older languages smalltalk's implementation is more powerful than the bastardization that other languages learned from it. Library interfaces in smalltalk are built around this syntax feature. Note how the function call looks the same as the keyword argument. This shared syntax makes the language read better. It makes function calls and keywords look like a normal infix language (e.g. the math expressions in most languages). Where parens are used like any other infix language (rather than be overloaded for function calls):

    (obj do_thing: "string" with_factor: 8) log_to: logger

would then call ".log_to(logger)" on the result of the parenthesized expression. The same way in (2 + 4) * 5 multiplies the result of the parens by 5. A single syntax structure for all these concepts - rather than mixing multiple syntax - allows it to express new ideas in the same syntax as everything else. Like lisp does.

In Smalltalk, the 'keywords' are actually part of the method name; when you say '1 to: 10 do: [ ... ]', you're not calling to: on 1 (which is an entirely different method) with a keyword argument, you're calling to:do:.

> This shared syntax makes the language read better. It makes function calls and keywords look like a normal infix language (e.g. the math expressions in most languages).

Ironically, since Smalltalk also applies this uniformity to arithmetic operators, they don't behave how most people would expect: a + b * c - d is executed like (((a + b) * c) - d).

Yea I was eliding some points to try and explain it better.

You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to`, when calling this method you could do `makeRange(from: 0, to:10)`.

That’s a fairly trivial example but it demonstrates how readability is improved. You can imagine how this becomes even more useful with methods that take many parameters.

An interesting document to look at regarding this is Swift’s guidelines on naming methods.

> makeRange(from: 0, to:10) [..] Swift’s guidelines on naming methods.

The syntax you show is Swift, which is a weird mash-up of C/C++ style function call/method call syntax with keywords jammed into them. To me, actual Smalltalk syntax is just so much cleaner:

   0 to: 10.

It manages the "reads like english" trick without trying to be english-like or natural-language-like. (See Applescript for the disaster that results from that: "Many of the current problems in AppleScript can be traced to the use of syntax based on natural language" http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf).

AppleScript may be the only read-only programming language in existence.

Depending on your definition of programming language, that crown might actually go to HAGGIS. It's an "educational" programming language which is not executable (or intended to be). It's possibly the worst idea in the history of computing, and that it is taught to anyone is (IMO) a public offense.

https://en.wikipedia.org/wiki/HAGGIS

"ah, scary, close tab!"

I get that vibe from Inform 7: the famous Dijkstra’s algorithm reads like English, but I'd have no idea how to write such a program.

Inform7 is mostly for text adventures. I'm sure it's not bad if you give it a go as many people with little to no coding experience write expansive text games using it.

I am still waiting for the combination of Perl and Applescript.

You have to write it in Applescript, but you get to read it only in transliterated Perl.

"You can put the parameter names in method calls, which makes for much more readable code. Like a makeRange method may take parameters `from` and `to` ... That’s a fairly trivial example but it demonstrates how readability is improved."

Is that something like keyword arguments in Lisp?

Except Smalltalk keywords can't be reordered or omitted. It's more like you put the arguments in the middle of the method name, like a kind of mixfix notation.

The method name would be "rangeFrom:to:withStep:" and that means you call it exactly like that, with arguments after the colon.

Objective C is the same.

> smalltalk cutest feature is the named parameter syntax trick (I don't like tricks but let's make an exception).

And yet, Smalltalk got it wrong by making all the parameter names mandatory, which leads to sources that are much more verbose than they need to be.

The correct approach to this is to make parameter names optional, so they're only used when disambiguation is necessary to clarify the intent of the code.

> by making all the parameter names mandatory

For example?

In smalltalk the parameter names aren't mandatory in the sense of many other languages.

They are actually part of the method name.

robot put: thing in: container.

And

robot put: thing on: shelf.

Are two separate messages that are both understood by the robot instance - "put: in:" vs "put: on:"

I asked hota_mazi to provide an example which demonstrated what they were talking about, to explain why they said "Smalltalk got it wrong by making all the parameter names mandatory".

Are you hota_mazi ?

In languages where parameter names are optional, you can say

    foo(1, 1, create = true)

This is the best of both worlds, allowing you to only name parameters when there can be ambiguity (for example when the function takes two int parameters and both mean very different things).

Smalltalk forces you to always name your parameters, which leads to overly verbose source files.

I don't think any of us know what:

    foo(1, 1, create = true)

:is supposed to do.

Please show a meaningful example so we can see whether the Smalltalk is overly verbose or your alternative is overly ambiguous.

I tried to pick up an example as generic as possible so you could understand my general point instead of focusing on this specific example, and you choose to focus on this specific example. <sigh>.

How about this:

     createWindowAtCoordinates(10, 10, redraw = true)

     createWindowAtCoordinates(x = 10, y = 10, redraw = true)

Regardless of how you feel about this specific example, surely you can agree that it's not always necessary to specify all the parameter by names?

So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood.

However (the specifics always matter) if we're assuming that, and we're bothered about verbosity then why say:

    createWindowAtCoordinates(10, 10, redraw = true)

:instead of assuming that it will be understand that the window will be created at a point:

    createWindowAt(10, 10, redraw = true)

:and something more like a Smalltalk method send:

    Window new openAt: 10@10 redraw: true

:where we've used the x then y convention, and a binary message @, to create a point (without mandatory parameter names).

> So you mean that in this case we might assume the conventional order x coordinate first and y coordinate second would be understood

... and again, you focus on the specific example and completely miss my more general point.

I'll give this one more try: I prefer a language that gives me the option of specifying the parameters names over one that forces me to always specify them.

> … you focus on the specific example…

That's the only way we can see whether what you claim makes sense.

> … which leads to sources that are much more verbose than they need to be.

We can see that for the example you provided, the Smalltalk style need not be "much more verbose" than the alternative you provided.

Using positional arguments will be a little more concise than using keyword arguments, but only a little.

Reply on news.ycombinator.com