6 ms·

I think if you're overly using dynamic scoping in clojure you are probably doing it very wrong. I used clojure professionally for a number of years and I can't

• mrkeen 2y ago
  Parent's not talking about dynamic scoping in clojure. It's a comparison to designed to elicit a reaction, e.g. "probably doing it very wrong". I.e. if you're not tracking ownership in new-lang, you're probably doing it very wrong.
  • j-pb 2y ago
    It's not a comparison to bash non-ownership as "very wrong", but arguing that lexical scope and ownership are literally the equivalent things. Lexical scope allows you to reason about scope on a syntactical level. Take this code: let x = 5; fn foo(): return x \* 2 fn bar(): let x = 10 return foo() fn baz(): let x = "hello world!" return foo() bar() With lexical scope, you can look at `foo` and you know immediately what it returns, the behaviour of the function is completely local to it and is a syntactical property of the program. With lexical scope you just don't know what's returned, for all you know x might not even be a number, but could be any type that just happens to be brought into scope. Ownership is similar, in that you make the existence of a value a local property. If a 'thing' is inside a variable then you can move it somewhere else, but it also means that it is no longer in that variable. And that tracking of where what is, is a syntactical property, just like with lexical scope. Clojure has software transactional memory. With ownership it wouldn't need half of the machinery (only that for rollback): let blocked_accounts = Set() let account_bob = new ExclusiveBankAccount(200) let account_alice = new ExclusiveBankAccount(600) // ExclusiveBankAccount cannot be copied or cloned fn transfer(source_acc, target_acc, ammount): if source_acc.deduce(amount.copy()): target_acc.deposit(amount.copy()) fn block(acc): let acc_identifier = acc.identifier.copy() // identifiers can be copied and are not exclusive blocked_accounts.put(acc) return acc_identifier fn unblock(acc): return blocked_accounts.take(acc) fn do_invalid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) block(bad_account) transfer(bad_account, good_account) // <- this will fail because bad_account was moved by the block function and no longer exists here, it's invalid syntactically fn do_valid_stuff(): let good_account = new ExclusiveBankAccount(200) let bad_account = new ExclusiveBankAccount(200) let ident = block(bad_account) let restored_account = unblock(ident) transfer(restored_account, good_account, 100) The above code makes sure that: - you can only transfer funds between two accounts in a thread safe way - you can only transfer funds between accounts that are not blocked Simply by not allowing something like this on a syntactical level you get a much cleaner understanding of what your code does. After a while you're wondering why we allowed anything else in the first place. let x = thing(); let y = x; // the thing is moved from x to y here print(x) The fact that automatic memory management falls out of this is almost accidental, if you can track where a value is at any given time, you can also track the references to it, and the resources it uses. But that is not what truly makes it amazing, the fact that you can mentally think about digital objects as if they were physical objects is.
    • mrkeen 2y ago
      Oh right. Enlightening! It's interesting you mention STM. That's one of the reasons I only dabble in Rust instead of switching over to it completely. In do_invalid_stuff(), block(bad_account) transfer(bad_account, good_account) // <- this will fail This can only be determined syntactically if you and the compiler agree to stay on a single thread, right? I would expect STM to be the thing which safely bridges across threads - since it will realistically a customer will call transfer() but a bank manager will call block().
      • vlovich123 2y ago
        > This can only be determined syntactically if you and the compiler agree to stay on a single thread, right? No. This will fail because in block the ownership of bad_account is lost. You’d need block(&bad_account) or block(&mut bad_account) to pass a reference while letting the transfer succeed. The only way the transfer would succeed silently like that is if Account implemented Copy (the compiler would automatically inject block(bad_account.clone())). This has nothing to do with threading (which Rust would still have protection mechanisms for). It would work identically if the block and transfer were member methods (i.e. bad_account.block(); good_account.transfer_from(bad_account)) since even member methods can be declared to be requiring ownership.
        • mrkeen 2y ago
          > This has nothing to do with threading Right, but all the promises of the type system have to lead to a first-class multi-threading experience at some point. The safest concurrent program isn't a single-threaded program.
          • vlovich123 2y ago
            It doesn’t automatically solve every possible problem for you just like something like Lean doesn’t prevent you from writing buggy proofs. I’d argue it does lead to a first-class multi-threading experience within the systems programming domain it’s targeting. Even outside systems programming it can be quite surprisingly good and most incorrect code fails to compile to begin with. Is there a language that in your opinion offers a better multi-threading experience?