6 ms·

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 th

• steveeq1 7y ago
  You can, it's called "erlang".
  • jacquesm 7y ago
    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.
• senderista 7y ago
  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.
  • inertiatic 7y ago
    It should be easy to implement on a modern IDE, right? I think intellij exposes a setting for example.
  • simias 7y ago
    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.
    • Matt3o12_ 7y ago
      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.
      • simias 7y ago
        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.
    • mpweiher 7y ago
      Hmm...the argument names seen in the method don't leak in Smalltalk. They do in Swift's attempt at a keyword syntax.
    • hnick 7y ago
      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.
  • edflsafoiewq 7y ago
    There are some difficulties to solve around how higher-order functions should work.
  • estebank 7y ago
    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.
    • madhadron 7y ago
      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.
    • coldtea 7y ago
      >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?
• xwowsersx 7y ago
  Have an example comparing?
  • cwp 7y ago
    Smalltalk: bank move: 100 from: checkingAccount to: savingsAccount Java: bank.move(100, checkingAccount, savingsAccount)
    • htk 7y ago
      Looks similar to Objective C. Verbose but clearer.
      • bitwize 7y ago
        Objective-C's method call syntax is modelled on Smalltalk's.
      • catoc 7y ago
        Isn't Objective-C Smalltalk married to C?
        • saagarjha 7y ago
          Pretty much.
    • zozbot234 7y ago
      Isn't this just mixfix syntax? It's simply a matter of convenience and perhaps idiomatic convention.
    • cessor 7y ago
      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/ 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.
• rrwright 7y ago
  Akka is what you’re looking for: https://akka.io/ https://akka.io/ It is very deliberately inspired by Erlang and used widely in JVM applications.
  • pjmlp 7y ago
    With Akka.NET as the .NET counterpart.
  • smabie 7y ago
    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.
  • kitd 7y ago
    Thanks, I've used Akka. I was thinking more about the messaging style than the "actors-on-JVM" thing.
• skybrian 7y ago
  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.