Hacker News Reader

Comment by kitd | Hacker News Reader

The way messages are constructed in Smalltalk is one of its delightful features. It seems so obvious to 'template' a message with the replaceable parts being the parameters. Typical methods a la C++ or Java look so clumsy in comparison.

It would be nice if there was a way to construct something similar around actor-based systems on the JVM.

View on HN

I’m very disappointed when I see new languages (cough Rust) not even consider named arguments. The added readability at call sites just seems like a no-brainer to me.

It should be easy to implement on a modern IDE, right? I think intellij exposes a setting for example.

The only counter-argument I've heard was that it has the consequence of making the argument name part of the API (i.e. changing the name would be a breaking change, so all parameter names of exported functions "leak" into the public interface). That always seemed like a very minor drawback to me, I too would appreciate to have named arguments in Rust.

It seems more like a feature to me. Sometimes parameters change slightly and you will never notice it until you re-read the docs. So if the change is explicit I can go look at it during compile time and not be surprised by it during runtime.

Of course there are occasions where the name is unfortunate (typo, ambiguous name or incorrect term) but the docs could mention it and it would not be the end of the world.

I agree, although I haven't done enough work with languages using named parameters to really judge how inconvenient they can become in practice.

It seems like most naming issues could be alleviated by allowing the developer to provide aliases, this way you can change the preferred parameter name while still keeping the old one around for backward compatibility.

Hmm...the argument names seen in the method don't leak in Smalltalk.

They do in Swift's attempt at a keyword syntax.

I think it's better than the alternative too.

You always have some concept of the API leak into the consumer. You either remember explicit names, or remember their positional pseudo-names 'first', 'second', 'third' etc. Unnamed arguments bring up more issues such as ordering consistency (see: PHP's many notorious cases), deprecation leaving 'holes' in argument lists, etc.

In Perl and many other languages we just provide a hash (aka dict) of key/value pairs. This lets the functions decide how to handle breaking changes which involves some annoying boilerplate but overall works fairly well. It's nicer with proper language support though.

There are some difficulties to solve around how higher-order functions should work.

The pattern in rust is to use enums and structs instead. Design patterns are always needed when the language doesn't support a given construct but once it's usefulness is established language designers incorporate to (the same or other) language.

The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder. This has been remediated with patterns in Python 2 and explicit design in Python 3 by incorporating named only parameters so that you can't call them with both positional or named args.

This isn't quite what the OP is referring to. In Smalltalk, all arguments are named all the time, including positional arguments. Object methods aren't named separately from their parameters. They are only their set of named arguments, i.e.,

So say I have a BankAccount class. In Python I would write a method to transfer to another account

def transfer(this, to, amount): ...

and invoke it as

account.transfer(other_account, 500)

In Smalltalk I would write

transferTo: account amount: n [ ... ]

and invoke it as

account transferTo: other_account amount: 500.

So it's not quite named arguments. It's that there isn't a distinction between name of function, argument name, and positional parameters. It just doesn't map to the function notation typical from mathematics.

>The problem with named parameters as seen in Python is that then the name of the parameters become part of your APIs contract, making changes to your API harder.

Huh? How are APIs with mere positional parameters easier to change and more transparent to the callers when changed?

Named arguments in Smalltalk always seemed a bit clunky to me because the order of the keyword arguments still matters. You have to write the keywords, but you don't get any flexibility over their order, just like positional arguments. I suppose you get used to it, but it seems annoying and not very scalable to having messages with many optional arguments. Languages that support true named arguments don't have this restriction.

Akka is what you’re looking for: https://akka.io/

It is very deliberately inspired by Erlang and used widely in JVM applications.

With Akka.NET as the .NET counterpart.

While Akka is great, it’s nowhere near as powerful as Erlang. Most notably, the inability to have a blocking actor yield control significantly changes the actor model (for the worse). Instead of being able to use messages like async function calls, you have to keep a lot of internal state managing all the actors you still haven’t gotten messages back from. This creates a lot of messiness and greatly complicates things. For example you can’t write something like:

foobar = send(actorA, GetDbVal(foo)) + send(actorB, GetDbVal(bar))

Instead you would need to construct some sort of mutable dictionary that keeps track of when it got both messages and when it does, have the actor finally add the stuff together. It’s not always so bad, but when you have actors that are interacting with a lot of other actors and querying many different resources, it becomes a problem. Akka tries to mitigate this problem with the state change function become(), which allows you to build a FSM to handle state transitions. While this helps a lot, it’s not a panacea.

I think I read somewhere that true multi-tasking is in the works for the JVM, so this hopefully won’t always be a problem. As it stands, it’s probably the biggest limitation of the platform atm.

Thanks, I've used Akka. I was thinking more about the messaging style than the "actors-on-JVM" thing.

Have an example comparing?

Smalltalk:

    bank move: 100 from: checkingAccount to: savingsAccount

Java:

    bank.move(100, checkingAccount, savingsAccount)

Looks similar to Objective C. Verbose but clearer.

Objective-C's method call syntax is modelled on Smalltalk's.

Isn't Objective-C Smalltalk married to C?

Pretty much.

Isn't this just mixfix syntax? It's simply a matter of convenience and perhaps idiomatic convention.

Also Java:

bank.move(new Amount(100), new FromAccount(checkingAccount), new ToAccount(savingsAccount));

If you are really trying, you will be able to convey enough information so that your fellow programmer. will understand what you are trying to accomplish. Unfortunately, in practice, even Java Experts will convey to you that this style is wrong, classes and objects are " too expensive", primitive values are fine, and that this is too verbose.*

I learned about this style from Yegor Bugayenko's Book "Elegant Objects", go check it out. https://www.elegantobjects.org/

*) Yes, Java is verbose; not trying to defend that. I am very happy about keyword arguments in Python, for example. But, as soon as you have classes, ctors, objects, you can use them to add rich semantics into your code. Works with functional languages and other, better typesystems, too.

Is there an explanation that doesn’t require buying a $40 book? I searched the site and couldn’t find anything

Of course you can, but you can't simply hand-wave away the verbosity. What a language makes easy is usually more important than what it makes possible.

In Python, adding from=from_account, to=to_account to clarify a call is basically free; you don't have to change the callee and you don't have to change any other call sites.

> What a language makes easy is usually more important than what it makes possible.

very well said

I wouldn't write it either way. I would write something like bank.processTransfer(new Transfer(100, checkingAccount, savingsAccount)) where the transfer object is immutable.

Cool, but the SmallTalk example requires a lot less squinting which is nice.

I think you don't have enough factories.

bank.move(new Amount(100), AccountChannelFactory.create(AccountChannelFactory.CHECKING_CHANNEL, checkingAccount), AccountChannelFactory.create(AccountChannelFactory.SAVINGS_CHANNEL, savingsAccount));

IntelliJ has a option called "Inlay Hints" that would display the Java example like this, with the parameter names dimmed slightly:

  bank.move( move: 100, from: checkingAccount, to: savingsAccount )

This option is also available for many of the other languages supported by the various JetBrains IDEs.

I hate those and always turn them off haha

IMO the java is more readable. Parenthesis clearly delimit the scope of the function call. How would smalltalk handle nested function calls?

Think like arithmetic. 2 times: (3 plus: 4).

You can use parenthesis around any expression, as in most languages. eg something like:

    bank balanceOf: (bank findAccount: #savings)

However, parens aren't necessary when a nested message takes no arguments, or uses a binary selector. eg:

    bank withdraw: 3 + 4 from: user checkingAccount

There are 3 messages here.

    1. 3 + 4 (execute method + with argument 4)
    2. user checkingAccount (getter with no arguments)
    3. bank withdraw: <result of #1> from: <result of #2>

Nice

Python:

    bank.move(100, from=checkingAccount, to=savingsAccount)

You can, it's called "erlang".

Erlang is not running on top of the JVM but on top of its own VM (BEAM).

There have been some attempts to get Erlang running on the JVM but so far none that really made it worth adopting, and frankly I don't see how you could do it without losing everything that makes Erlang/OTP special.

Reply on news.ycombinator.com